Terminating Event to Event Queue due to Work Item Lock

Question

I have a dialog workflow task based on an asynchronous method defined with a terminating event.  When the user executes the work item, the method generates the terminating event (via a V2 change document) but the work item is enqueued (locked) by the same user (locked when they execute the work item from SBWP) and therefore the terminating event goes into error and is placed in the event queue.  The background job which processes the event queue does not redeliver the event so it stays in the event queue and the work item fails to complete.  Other than dequeing the work item lock myself with a function call how do I get around this catch 22?

Answer 1

Hello Martin,
Actually, the locking happens whether I have the task as asynchronous or synchronous.  The problem is the timing. If the user does not release the lock (by backing out of the dialog which is executed) prior to the terminating event attempting to enqueue and complete the work item then the event goes into error and is inserted into the event queue (and lingers there indefinitely, almost). Another issue with the asynchronous approach is that even if the user backs out of the dialog before the event actually attempts to complete the work item they will still see the work item in the inbox unless they click the refresh button when they get back to the inbox. 
I have changed the task to synchronous but here is my scenario and another question.
The process being workflowed is the approval of service entrysheets (similar to an invoice if you are not familiar with External Services).  In our process, there are a large number of documents being created and requiring approval by particular approvers.  It is a normal scenario for an approver to have, lets say 25 documents in his inbox awaiting approval. It was not practical for him to have to navigate back and forth between his inbox and the approval task screen.  Therefore, I give the users the option of (when executing a work item) having all the documents in his in-box (for this particular task) be presented in an approval list screen.  They can then do a mass approval of the 25 documents with 1 click and 1 navigation.  This list screen is also available to be executed outside workflow via a tcode.  So, when the user executes the mass approval (either from the inbox or outside workflow) the work items are terminated via the terminating event assigned to the approval task.
A couple of issues remaining:
1) Given my example of 25 work items (user executes 1 work item from in-box
and I displayed all 25) being approved, when the user returns to the in-box, the 24
items remain in his inbox until he clicks the refresh button since these were not actually "executed" from the workflow engines point of view.  However, these were terminated successfully because they were not "locked".
<b>Question:</b> Is there a way (user exit?) to trigger the inbox refresh automatically.
2) Now, the issue with the actual work item which the user executes from the inbox.  As I mentioned, the work item is locked as soon as the user executes it and is not released until they back out of the dialog or logoff.  So, here is what happens:  If the terminating event is sent before the lock is released the event is sent to the event queue.  If they then back out back to the in-box, its OK since I put some code in the SWO1 object type program (rememeber, its now synchronous) which will determine if they did the approval/rejection and the work item will complete and the event in the event queue will be deleted the next time the Event Queue Background job runs (it deletes any events for work items already in COMPLETED status). However, lets say they simply log off rather than backing up to the in-box or they don't do anything and are eventually logged off by timeout. In this case the code in the object type program to determine if the approval/rejection was done does not get executed (control does not return to the object type program) and the work item remains in "STARTED" status and remains in the users inbox and the event is in the event queue. So, now we have a work item that should be completed still sitting in the users in-box and the terminating event in the event queue. So the next time the user goes to their inbox the work item is still there.  The interesting thing is that though this may be confusing to the user, if they then attempt to execute the work item, they will get a message: "Work item currently being completed by event" (Message SWF_RUN 644) and the event sitting in the event queue gets redelivered and completes the work item.  To alleviate this problem I was thinking of adding a call to SAP_WAPI_WORKITEM_COMPLETE in the approval list screen after they do the approval but I'm guessing it wont work since it probably will try to enqueue the work item and it will still be locked. 
Hopefully you haven't nodded off reading this rambling note...
Thank you,
Bob