BPT Race Condition

BPT Race Condition


Hi there,

I have a case like this:

t0: the automatic activity call (consume) external web service "your web service" (locates in remote server)

t1: i want to wait the server call back "my web service"; before that i need to wait (wait activity)

t2: if my web service is called, then i want that wait activity to be closed from the "my web service"

Unfortunately, when i call the external web service (t0) and then my web service is called back, the process is still in waiting state. This is because the wait activity - in the ready state where i record the activity id - is not yet executed. I mean there is a race condition: close activity is called from "my web service", but the onReady callback is not committed yet.


and thank you


All the logic inside the automatic activity has been executed by the end of that same automatic activity, you don't need to wait for the call of the webservice, because if that activity is executed, the call already has been done.

This is why, you are having the described scenario by you, you can't close the wait inside your internal webservice, because the process is not there yet.

I am not sure what you are trying to achieve with your scenario, but you need to re-think your approach.

Hope it clarifies your question,

Best regards

Daniel Martins

Hi Box,

If you want to keep your "wait for async" operation logic in your process without many bells & whistles, you can probably just use the "Close On" property on the Wait action, waiting on an entity update from a record that you already created (and is perhaps already associated with that process, and where you will perhaps store some sort of result from the callback). 

Then instead of trying to close the Wait activity on your webservice directly, you would instead update that entity (with the callback result probably?), triggering the Wait activity to close, and your process to continue.

As for the race condition that you can still have on this scenario, you would have to check before putting the system WAITING on the entity update, IF the entity has already been updated.

Not sure if this will work for you though.

Best regards,

Hi Sirs,

Thank you for the replies. 

The Case is like this:

# I use external entity..so cannot use entity action in the callback.

t0: I consume external web service that locates in a remote server inside the automatic activity....to signal the remote that "Now you can consume my web service"

t1: then i want to wait (wait activity) the remote server to consume "my  web service"

In the callback onReady, I create a record in database to store the activityID (Wait Activity ID).

In the "my service" i call system action to close that Wait activity.. by fetching the Wait Activity ID as an argument to the closeActivity(activityID).

Unfortunately, before the Wait Activity ID get recorded, the  "my  web service" has been called and when fetching the database, the Wait Activity ID has not been there, so the wait activity is not close. The end state will be Waiting in the Wait activity - not i want- i hope it will be end state. 



Hey Box,

Indeed, if you are calling your external webservice in a previous activity, it is not viable to use the Wait Activity ID on "MyWebService", because of the race condition aforementioned.

This is why i suggested you have a simple entity to control the process. Let's say something like this:

Where ProcessId can be a foreign key from the Process table set to "Delete" (as Delete Rule)

Then before you do the "Async Call" you create a record on that table (InitCallback) using the current process id. Your process would be something like this:

You then pass the ProcessId (or whatever id you want to use to the External Web Service)

On your external web service you do launch whatever process or tasks you have to, and then when calling back your web service you use the ProcessId (or other key), as long as in your web service you are handling that.

The important part is that you update that specific CallbackResult record associated with the Wait activity.

Like I said this is just a suggestion, you can achieve this same behavior using other methods. 

Let me know if this serves your purpose.

Best regards,


Hi, Tiago,

Thank you for the reply. 

#I am thinking to use onReady callback, and 

# then i do commit a record before launching an asynchronous external web service. 

# This way, i think the race condition is solved as the Wait activity exists and its record is committed before the "external web service" call back "internal web service" that close the wait activity using system action close_activity.

# The asynchronous external web service call is achieved by putting it in a separate process, and launch it by just dragging that (sub) process.