Can a Service Task Behave Like a Receive Task?


We want to send our workflow into a wait state if the outcome of a REST call to an external API (ServiceTask GetVMO) has a particular result.

One solution is to use a Receive Task as shown in my simple test :-

receiver_task_test.v2.bpmn (10.0 KB)

Here GetVMO makes an external call to some REST API and if the response is null or an empty list, we set an internal variable (hasVmoCoverage) to “no”. This then diverts the workflow into the receive task. The workflow will wait until we send an appropriate signal, then move back to GetVMO and re-run the task.

The concern with the approach is that I would have to add extra components (the exclusive gateway and the receive task) to my production BPM diagram. As my workflow already contains some 100+ tasks and gateways, this would mean a lot of changes to the BPM structure.
I wonder if its possible to avoid structural changes to my BPM?

Is it possible for my Service Task (GetVMO) to be changed so that it can behave like a Receive Task based on a condition?. In other words, when GetVMO is called, it will execute my Java code, call the external REST API, check the response and go into a waiting state. When a signal is sent to wake-up the workflow, the GetVMO task is re-executed so that the call to the external REST API is made again.

Is such a behaviour possible from a ServiceTask?


How about something a little more minimalistic


when you eval the http response, if there is a the vmo converage issue then you throw a “BPMN Error” and then wait for the message.

If you are preforming this http call all over your BPMN, you could think of something like this:


Hi @davekant,

The asynchronous service task pattern could be useful for you.



Thankyou Stephen, this is a very useful recipe and works for me.
This link provides further information: