I’m currently having an issue with a flow not actually waiting for a signal response. When I run this, it runs normally and returns data but it is not waiting. When I check in the cockpit the service is still running, until it times out. How do I make the flow not return data until it either times out or the signal is caught? By return data, I mean that I call the flow with Postman and is returning data to Postman.
WaitFlowExample.bpmn (19.6 KB)
Hello,
Based on your flow and the event based gateway, one of two things will happen - either it receives the signal and executes ‘Test call event true’ or the timer expires after a minute and executes ‘Test call event false’. Whichever event occurs first will be the path taken. Maybe you want to increase the duration on the timer to give you more time to send the signal? Here is the REST API to send a signal: https://docs.camunda.org/manual/7.12/reference/rest/signal/post-signal/
Joe
Right, but when I invoke the call in postman to start the flow, it executes and appears as if it’s finished…is there something i have to do in order for the flow to not return anything to postman until it has either timed out or gotten data back?
Are you sure the process starts? I had to modify yours since I don’t have your delegates and it ran as expected. What REST API do you use to start the process flow? What do you pass in?
I believe it starts. When I start the service via a Post call with Postman, it works, but it returns data like the flow is finished, but when I go to the server it is still running.
You don’t sound that confident 
Have you tried starting it from Tasklist? I suggest a few printlns in your script tasks to ensure that it’s hitting your tasks. As I said, it runs as designed in my environment. Can you post screen shots of how you start the process in Postman? Given that you put a timer on the Event based gateway it should still be running until the timer expires or it receives a signal. Here is an example of how to start a process via REST:
That is how I am calling it, but what is happening is that it is returning data back from the rest call prior to timeout or a signal. I will see the rest response, then go to the cockpit and see that the slow is still running.
Yes, you will receive a response back from the REST API. But, since the process reaches a natural wait state which is the Event based gateway, the process won’t complete until either the timer expires or a signal is received. It’s not a response saying the process has finished, but rather acknowledgement that the process has started. The process starts and only when it hits a save point (aka natural wait state, an asynchronous continuation, etc) will it respond to the REST API call. If a process is created without any save points then the response will indicate the end of a process. And you’ll see in the response whether the process has ended or not. In our case, it will not (“ended” : false)
https://docs.camunda.org/manual/7.12/reference/rest/process-definition/post-start-process-instance/
Result
A JSON object representing the newly created process instance. Properties are:
| Name | Value | Description |
|---|---|---|
| id | String | The id of the process instance. |
| definitionId | String | The id of the process definition. |
| businessKey | String | The business key of the process instance. |
| caseInstanceId | String | The case instance id of the process instance. |
| tenantId | String | The tenant id of the process instance. |
| ended | Boolean | A flag indicating whether the instance is still running or not. |
| suspended | Boolean | A flag indicating whether the instance is suspended or not. |
| links | Object | A JSON array containing links to interact with the instance. |
| variables | Object | A JSON object containing a property for each of the latest variables. The key is the variable name, the value is a JSON object of serialized variable values with the following properties: |
| Name | Value | Description |
|---|---|---|
| value | String / Number / Boolean / Object | The variable’s value. |
| type | String | The value type of the variable. |
| valueInfo | Object | A JSON object containing additional, value-type-dependent properties. |
For variables of type Object , the following properties are returned:
-
objectTypeName: A string representation of the object’s type name. -
serializationDataFormat: The serialization format used to store the variable.
The following property can be returned for all value types:
-
transient: exposed if the value is set to true. See documentation for more informations.||
Response Codes
| Code | Media type | Description |
|---|---|---|
| 200 | application/json | Request successful. |
| 400 | application/json | The instance could not be created due to an invalid variable value, for example if the value could not be parsed to an Integer value or the passed variable type is not supported. See the Introduction for the error response format. |
| 404 | application/json | The instance could not be created due to a non existing process definition key. See the Introduction for the error response format. |
| 500 | application/json | The instance could not be created successfully. See the Introduction for the error response format. |
For more information regarding transaction boundaries, natural wait states, and asynchronous continuations see:
https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/
Ah ok. Is there a method to just have it not return anything until the signal is received or the timeout has occurred? We have some legacy stuff that checks for any response and this is kind of a mess if we can’t do that.
One way would be to end the process with a throw message event. In the code you could send a message or invoke some API to alert your legacy systems about the end of the process:
That might work. The problem is that it’s expecting a 1:1 response from this new service that we’re trying to build because the old one went away. If there was some way to make the initial flow that I posted just sit there and not return data until the signal was sent that would be ideal.
The other issue is that the legacy system is expecting the data in the response…that’s the problem. It just has a long timeout.
Ok, I tried throwing a message back, but the rest api continues to respond before the response is there. Is there some way, any way to have the process wait to send data back?
That’s the issue. The process will hit a natural wait state and respond back to the start process REST API call. It makes no difference what happens after that. You can’t use the response back from the start process REST API as a response for the data. It simply won’t work. If you insist on this approach you’ll need to have something in between that waits for the end of the process, not the response back from the start process REST API. Once the process has ended only then would you respond back to the initial call.
Ok. I understand. I have a question though…is there a way to have a boundary event called to interrupt a loop? So far I haven’t had any luck with it.WaitFlowExample.bpmn (21.5 KB)
You could try something like this. The trick here is that nothing in here has a natural wait state so the start process REST API call will wait and wait until the call in the delegate (Call java delegate NetworkService for CustID) returns. But the code in the service call has to wait for the response, not the process itself. You’re trying to wrap what should be an asynchronous interaction in a synchronous call. I’ve tried it using Thread.sleep() in the delegate and the start process REST API call in Postman will wait until everything is completed before responding. Not exactly a best practice or something I would recommend but I think it’s the behavior you want.
Is there a way in the example I gave to have that boundary event or something happen there? I understand that none of them have a natural wait state but I’m sort of creating an ersatz version there. Shouldn’t it catch the event in that case?