We are creating process instance as part of API call, when we receive the call, we start the process instance and as part of response, we’ll send the next user task as part of that response.
So before sending the response all the service tasks will be executed and execution will be moved to user task.
But intermittently, zeebe broker is not activating the user task handler after completing the service tasks. Execution is moving forward and response is sent back without User task details. We have created zeebeClient with default configurations
What does this mean, specifically - as pseudocode?
For example: “we post a message to an interrupting boundary message event catch”, “one of the service tasks reads something from a database table and causes a conditional event to branch in the workflow”, etc…
You can consider this workflow, when the process instance is started, after executing the first service task, execution will be in user task “Scan bill Receipt”.
So as part of create process instance API call, we should send the Scan Bill Receipt User task name as part of response.
In some cases, broker is not activating the User task after completing 2nd service task, due to that reason we are not able to send User task info as part of response.
So you start the process instance with a create process instance API call
You said: “So as part of create process instance API call, we should send the Scan Bill Receipt User task name as part of response”
Do you mean that you send the user task name as part of the variable payload in the create process instance API request?
I also don’t understand this part:
When you say “we are not able to send User task info as part of response”, you are referring to the response to what?
With the gRPC API, your application send requests to the gateway, and the gateway sends responses to your application.
So, I can’t understand what response you are referring to. Could you please be exactly specific?
For example:
“In the application code for the worker servicing jobs for the first service task, named here ‘Initialize Receipt Audit’, in the CompleteJob API call in we send a variable payload in the request body with a variable named userTaskName, with a string value that is the name of the user task.”
Hi @jwulf ,
This is the sequence of steps which happens.
Create Process API will be called.
Process instance for the corresponding Process definition will be started using newCreateInstanceCommand by passing the variables.
Once the Process instance is started, Zeebe engine will start executing the service tasks.
We want the execution to be synchronous here, once all the service task is completed, it’ll move to user task.
In User task handler we are storing task details and we’ll get to know User task is Scan bill receipt…(Here we are not completing the user task, we are just storing).
After this we’ll send the response back to Client with Process instance key of newly created instance and User task which is activated. In this case it’ll be Scan bill Receipt.
We have User task completion API. There the request will include Process instance key and User task Name(Scan bill receipt).
Update API request:
host/v1/update/
Body -
{
“processInstanceKey” : “12345”,
“variables” : {} // this variables are sent which will be used for next service tasks or user tasks.
}
Once we receive the API call, using the details we have stored in UserTask Handler, we’ll take Task ID from that.
Using Operate and Task List API we are marking the User task as complete.
Here we are facing the issue in Step 5.
Intermittently, Zeebe broker is not activating the User task when the execution of process instance is moved to User task handler. So for that reason we are not able to send the User Task name back as part of API response.
It sounds like you are trying to rebuild the “Camunda 7 Tasklist” in Camunda 8.
The problem is that Task Assignment is a POLL based process, not a PUSH based process. Tasks don’t exist until the prior task is complete, and the engine has time to process it.
I’ve tried to diagram how I’ve read what you’re understanding is.
If I have understood correctly that you are trying to rebuild the Tasklist, your application code will need to poll the Zeebe engine (same as the Zeebe workers do) looking for User Tasks. Since there may or may not be user tasks, the engine cannot push to your application the name of the next user task.
Maybe I’ve completely missed what you’re trying to do. But if you create a workflow document that shows what you’re trying to do, we might be ale to help you better.
I think @GotnOGuts is on to something. It looks like you are approaching C8 thinking it operates like C7.
When you create a process instance the way that you are, you immediately get back a process instance key, but nothing has happened yet, other than the start event.
You can either await the entire process or get back the instance key the moment it is started. Nothing in between.
Your only read access to intermediate states of the workflow is in worker code, or via listening to the exporter stream.
The Operate API gives you some exporter-stream related functions.
Sorry for the delayed response, your understanding is correct.
I’m trying to build the solution which gives the User task details back as part of response when custom create Process API is called(which starts Process instance ) and update Process(Which completes the User task)
Whenever I start the workflow, Service task Initialize App should be executed and Process instance state should reach the Login Screen User task and then I can send the response back to UI saying the Active User task is Login Screen, so that UI can paint the screen based on User task ID.
I’ll capture Login details as part of login screen User task and that is validated in Validate User Service task.
If validation is successful then it’ll send Active task As Home Screen, so that UI will now show Home screen page.
Since Zeebe is asynchronous and works based on polling, this behaviour can’t be achieved.
Please help if this details can be captured as part of create instance command and during completed User task command response?
So now you’ve identified at least 3 participants (or pools) to be modeled:
User
Your Custom UI Software
Camunda
So rewrite your model showing the interactions as 3 pools. You’ll learn a lot by doing that.
“Login Screen” is not an activity (or action to be completed), it’s a machine state
Similarly, “Home Screen” is not an activity, it’s a machine state.
What I’ve seen you looking for is something like this:
Take a step back and remember that a Process Instance is meant to be modeled technology independently… The user interaction could be paper-based forms, email, or an App. What is the PROCESS (Not your APP) meant to accomplish?
@Naveen_KS hello,
did you implement this solution? if yes, can you assist me with how to do so?
how to start the process and how to complete the receive tasks through the code?
