Flowable Callback Approach

Flowable Engine
1

Hi Members,

I have following scenarios on which I need your advice or if you could point me to appropriate examples, that will be great. I am evaluating how some order flows could work using flowable engine.

  1. The bpm workflow process in one of the tasks calls an external system. The external system responds with acknowledgement synchronously. Few seconds (max few minutes) later, external system sends success or error response on the callback URL (http transport) provided in request. How do I trigger the waiting receive task on receiving the callback request? The callback url should have the process instance id & step id? Should I be using flowable event registry? It should also be possible to inject the response parameters from the callback payload into execution context. Or is there any other recommended approach.
  1. The second scenario is similiar to first except that it runs over a period of few days as it is related to delivery of goods. The logistics system communicates on http transport layer with predefined payload. Also, the system sends intermediate statuses like being packaged, shipped, on the way, delivered, customer not at home - try 1, retrying delivery, failed to deliver, etc. During each inbound intermediate shipment message, we have to send messages to customer notifying the status. Once the end state is reached (delivery complete / delivery failed) appropriate action needs to be taken (go to next step / trigger fallout). Using again event registry triggering a separate process flow wherein the customer notifications are sent out? On end state, having separate listeners to trigger the main flow based on delivery status? The callback url should have the process instance id & step id?

Look forward to hear one’s views. Thank you.

2
  1. You can model this by having a wait state (e.g. receive task) after the external system call. You indeed would need to send the processInstanceId or executionId to the external system so it can callback to the proper instance.

Using the event registry is another option indeed, if your using a queuing solution.

Lastly, another alternative could be to look into triggerable tasks (https://flowable.com/open-source/docs/bpmn/ch07b-BPMN-Constructs/#triggerable), that have this pattern built-in.

  1. This use case feels more naturally expressed by a case model, where you have multiple types of events coming in (at undefined points in time), with consequences attached to it. CMMN also supports the event registry, so that would be fitting nicely.

Using the event registry would allow you to correlate on something else than process/execution id (e.g. business specific data).