Stream: workflow
Topic: Workflow Communication Patterns
Emmanuel Helm (Jul 29 2016 at 09:33):
I am currently working with @Reinhard Egelkraut, @Karl Holzer and @Oliver Krauss on the diagrams for the Workflow Communication Patterns. We tried and took the textual descriptions literally and came to find some loose ends (this leads to confusing/very complex diagrams, see attached whiteboard photo).
In Option C, Step 3, the filler can post the event resource to any “alternate intermediary” system. How can the placer know where to look for this resource?
Alternatively – from the filler’s point of view, is this alternate intermediary system for example the placer’s FHIR server?
Lloyd McKenzie (Jul 29 2016 at 14:05):
The intermediary would be some agreed workflow coordination system - both placer and filler would need to know about it in advance
Reinhard Egelkraut (Aug 01 2016 at 19:35):
@Lloyd McKenzie the intermediary itself is clear, what we didn't fully understand was (in Option C, step3):
"the filler POSTs an 'event' resource (e.g. MedicationDispense, DiagosticReport, Encounter, etc.) to the appropriate resource endpoint on either its own system, the same intermediary as the request was placed on or some alternate intermediary"
-> the last part of the sentence would mean that the placer POSTs the request to an intermediary A and the filler POSTs the event to an different/alternate intermediary B, without informing the placer (at least that's what the current description says). Hence the questions from @Emmanuel Helm. Or did we get something wrong?
Lloyd McKenzie (Aug 02 2016 at 02:19):
It doesn't really matter where the Event lives because where the Task lives is known - and the Task will be updated to point to the event on whatever server it's stored on.
Paul Knapp (Aug 02 2016 at 06:34):
@Lloyd McKenzie: Why do you say that the intermediary must be known to the receiver and sender in advance - many intermediaries are only known to one end and indistiguishable from that end by the other end. Often your visibility only extends to the party you directly connect to.
Lloyd McKenzie (Aug 02 2016 at 14:02):
@Paul Knapp If we're dealing with REST situations (non-routing), then the system where the Task is posted by the placer must be known to the filler in order for them to look for it. The messaging scenario is addressed separately and it doesn't require mutual knowledge of respective endpoints. In the RESTful space, you can also have a cascade of responsibility where the "filler" that looks to the first task spawns other tasks that are then visible to subsequent downstream systems. That sort of chaining is treated as distinct fulfillment where the filler becomes the placer in a separate fulfillment action.
Paul Knapp (Aug 02 2016 at 17:44):
Oh, this isn't a communication intermediary, its a Task Server - an endpoint. Agreed, all parties must be aware of servers which provide them services. Nothing to do with REST really.
Reinhard Egelkraut (Aug 03 2016 at 14:37):
Ok thanks for the clarification.
I checked once again the description of Option C and although the "placer and filler would need to know all involved systems in advance" information is not part of the steps itself, it is mentioned in the limitations section of Option C:
-> "Placer and fulfiller must know where to poll for content - this could be a large number of Systems"
so this should work
Last updated: Apr 12 2022 at 19:14 UTC
