We had a problem that 2 or more workflow instances (of the same custom workflow) were created simultaneously (almost parallel) because of a batch program. We thought of a solution involving the event queue.
We added the starting events of the WF to the event queue so when 2 or more instances of the same WF were created or changed, all of them will go to the event queue and then they were going to be released sequentially from there.
In order to finish all the "old" workflow instances that are in the event queue (we only need to keep the last one created) we are triggering an event at the beginning of the workflow and waiting for the same event in one of the branches of the workflow, so when the next WF instace is released from the event queue, it will trigger the event and the previous WF intance will be finished (because it's waiting for that event to ocurr to logically delete the WF).
The problem is that when the first WF instance receives the event triggered from the second WF instance, it's
showing an error in that wait step and the WF won't finish (ir remains in process).
The error is the following:
Work item 000001508048 locked by user WF-BATCH (enqueue error)
Message no. WL605
After 20 minutes the first workflow instance is finished, but it should have been finished 20 minutes earlier.
Do you know where could be the problem here?
My first question is that isn't there any other solution found than using this event queue trick with waiting for event step? I can see that is already causing problems and it might cause problems also in the future. I believe that in a "happy day scenario" it will work, but what if the event queue is turned off or something like that? This could happen in production some day.
For example, do you have possibility to change the batch job to change the even creation logic? If yes, then there could be better ideas to fix your problem.
In case that you already thought every possible solution, and you want to continue with the one implemented now, you could try the following:
In the WF builder, go to the header (=the hat" button), open the Version-dependent tab and there open the "Events" tab. You can define your cancellation event there, and select "cancel workflow" in the receiver type. => When this event is triggered, your WF will be cancelled. Now you don't need the separate branch with wait for event step n your workflow to cancel it. I am not sure if this will solve your problem - you might get the same error message (which I don't really understand what is causing that), but at least it is worth to try. And in case it is more modern WF design.
"We had a problem that 2 or more workflow instances (of the same custom workflow) were created simultaneously (almost parallel) because of a batch program. We thought of a solution involving the event queue."
I don't understand - why is this a problem? Is it that you don't want multiple workflow instances running at the same time, or are you getting identical workflows started for the exact same scenario and you'd rather have just one?
Hi- I would suggest below way for controlling multiple WF instance issue instead of event queue
Create one task as the 1st step in WF and the task needs to check already active WF instance exists. If yes, then export a variable to WF container and validate this variable and close the 2nd WF instance
So only 1st WF instance will continue. You can use FM- SAP_WAPI_WORKITEM_OBJCT to get active WF for a specific instance
First check what is executing by the workflow.
You background task may take 20 min to execute the code.
Are you executing any background job through workflow ?
then this may be your problem.
Please check the below link to execute the background job through workflow.
Thanks and regards,