Terminating Event to Event Queue due to Work Item Lock

[Former Member]

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?

[KKilhavn]

When you write "when the user executes the work item", do you mean "when the user completes execution of the work item", or "when the user starts execution of the work item", or even "during the user's execution of the work item"?

The terminating event should at least not be created until the user completes the execution, i.e. leaves the method that is executed. Since you're writing it is via a V2 change document it really doesn't happen until (after) the user completes execution, when the commit is taking place. If that is too soon you have a problem...

Customer code with commit statement in the method? Remove it and that should do the trick. If not, hmmmmmm................

[Former Member]

The lock occurs by the workflow engine immediately upon execution of the work item. The V2 update is triggered by SAP standard code in BAPI_ENTRYSHEET_RELEASE so I can't control when the commit takes place.

[martin_nooteboom]

Hi Bob,

I think the problem is in using a asynchronous task in dialog. Is there anyway to make the method (and thus the task) synchronous? If not you should try and find a way to make the task a background one.

If you could give a bit more information on the method and scenario, maybe someone could give you some hints.

Regards,

Martin

[Former Member]

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

[martin_nooteboom]

Hi Bob,

To assure you I didn't nod off while reading your reply ;-).

The problem is I don't think I could be of any help unfortunately. I don't know of a way to force a refresh of the inbox, I did a little checking but couldn't find anything.

Regarding your second point, You could try adding a call to SAP_WAPI_(SET_)WORKITEM_COMPLETE(D). If it returns that the workitem is locked you could try dequeing it first. It is not the most elegant solution I think but it might work.

Regards,

Martin

[Former Member]

Hi Bob

What version are you on? What is the BO? Have you extended a standard object ? Where is the terminating event getting triggered?

If I understood correctly, you have 2 issues -

1. Workitem lock

2. Inbox refresh

My immediate suggestion would be Advance with Dialog for the multiple approvals but I guess you may have already checked this out.

Also, with the list you present to the users, are you able to trigger the terminating events for those that the user has taken action on, outside the BO Method, within the dialog program itself after the method has finished?

I checked and there are no user exits in SBWP/SO01 for a 46c system....

Regards

Ravi

[Former Member]

Hello Ravi,

The standard business object is BUS2091 which I extended. The terminating event is triggered via a change document which is created by an update done by bapi_entrysheet_release. The sequence of events is: ZBUS2091 Method Approve executes a Z program which presents the user with one or more Service Entrysheets for Approval. The Z Program calls bapi_entrysheet_release which generates the change document in a V2 Update, this change document triggers the terminating event (so the answer to your question is no, I cant control the timing of th terminating event).

We are on ECC6. The advance with dialog option doesn't really fit our process.

You are correct regarding the 2 issues: The inbox refresh is not really that much of a bother. I am really more concerned with the lock.

I did try to dequeue the work item using DEQUEUE_E_WORKITEM after the bapi_entrysheet_release call but that did not release the lock.

Thank You,

Bob

[pokrakam]

Hi Bob,

My memory may be tricking me but I think the locking behaviour is influenced by the method type. Put your report into a transaction and change the method into a transaction (method properties -> ABAP tab). Better still, create the method from scratch, add your params and and let it generate the call transaction statement. Transactions shouldn't lock the WI for the same reasons you are experiencing.

If not try one of the others. Or better still: treat it as a great excuse/opportunity to dive into ABAP Classes

Cheers,

Mike

[Former Member]

Hello Mike,

First of all, let me say that I thoroughly enjoyed your presentations at Teched Vegas and Boston.

I tried your suggestion of changing the method (abap tab) to transaction and it does not change the fact that the work item gets locked.

What I did try was to dequeue the lock using FM DEQUEUE_E_WORKITEM which I wasn't too crazy about and it would not release the lock.

So figuring that what I need is to hold the terminating event from delivery until the

work item is dequeued I configured a Check Function Module in SWE3 for

Object Type BUS2091, Event RELEASED (the terminating event) and Receiver Type WORKITEM. In the Check Function Module I put some code which attempts to enqueue the work item by calling ENQUEUE_E_WORKITEM. If it can be enqueued then I exit thereby delivering the event. If it cannot be enqueued then I wait X seconds and try again (loop). Well, it works.... almost. Unfortunateley, the Check Function Module must be called by the workflow engine single threaded (one event at a time waiting for each check function module to fiunxhe executing) as opposed to concurrently because if it gets invoked against a locked workitem it is not called again (for other triggered events) until the other execution completes.

Regards,

Bob

[pokrakam]

Hi Bob,

Thanks, glad that at least someone was paying attention

That still sounds like it shuold not be necessary. I vaguely remember having a problem with locks where the terminating event wouldn't touch the workitem because it was locked but would complete the workflow (we also had a wait for event in a parallel branch). The error monitoring job comes along within the next 20 minutes and clears these up. They were happy with addressing this via user training.

To be honest, I've occasionally resorted to using synchronous methods for some situations and waiting for the update to complete. Not best practice and not usually a recommended route, but if it's more stable than the standard behaviour then who am I to argue? This is essentially what BAPIs do (my first choice - even before a transaction).

Cheers,

Mike

[Former Member]

Hello Mike,

I noticed that the event queue retry parameter was set to zero so I adjusted that to 20 and now rather than getting queued with an error status requiring manual delivery its placed in the event queue in ready status and will redeliver automatically for the next 20 executions of the event background job which runs every minute and will be delievered successfully as soon as the user releases the lock.

As far as the automatic refresh of the Workflow Inbox each time the user navigates back to it I will probably open another thread for that one and open a problem report with SAP. It seems to me that the inbox should be refreshed each time control returns to it and not just on initial entry when excuting SBWP.

Happy Holidays and thank you very much for taking the time to offer your assistance.

Regards,

Bob

[pokrakam]

Hello Bob,

Thanks for the feedback, let us know what SAP come back with because this is an old problem. I suspect that this is not something that can be solved though, because the whole point behind asynchronous events is that they are asynchronous... in other words control returns back to the inbox independent of the termination of the work item. I suspect that internally the inbox does actually refresh, but the termination of the work item happens afterwards.

It would seem logical that returning to the inbox is quicker than termination of the work item, since the user dialogue all happens in the same session whereas the terminating event gets raised by RFC, processed by the event manager and passed on to the work item.

Thanks, happy holidays too,

Mike

[Former Member]

Hi Bob,

Can you please tell me the SAP Transaction for mass approval of workitems from a particular task.

Thanks,

Sean

[Former Member]

Hi Sean,

Actually, the transaction that I was referring to for mass approvals is a custom transaction. In the object type method for the workflow task I find all the work items for that task in the users in-box (not just the work item bneing executed) and the associated object keys (in this case Service Entrysheet Number) and then pass these keys to the custom program which will then display all the Service Entrysheets for mass approval. Not what you were looking for but maybe something you could try.

Regards,

Bob

[martin_nooteboom]

Hi Sean,

Actually you should post your question in a new thread and refer to this thread (with a link for instance). This would make it easier for people with similar questions to find your question (and answers).

Now regarding your question, there is an option for mass approval. Under Settings -> Workflow Settings -> Personal Settings you have an option to set "Transfer of Execution to Other Workitems Possible". When you set this you could select multiple workitems from your inbox (same underlying task) and execute. After the first the system will ask if you want to perform the same action for the other tasks. This will work best for decision tasks, and it depends on the type of task if it will work at all.

Regards,

Martin.