Multiple agents per one work item in workflow

[Former Member]

Hi, I've got a workflow multiline element which contains user id's. Currently all the agents in the multiline element are being sent the workitem, however the first agent to execute the workitem removes it from the other agent's inboxes. I've got the multiline element in the 'Other' tab of the step and I've tried using the multiline element index in the agent assignment of the step, i.e. '&REVIEWERS[&_WF_PARFOREACH_INDEX&]&'. What am I forgetting?

Thanks in advance,

Kevin

[Former Member]

Hi Kevin,

this is a standard feature of workflow. When you send out a work item to a pool of people a single person can then reserve the work item after which the others won't see it any more.

Normally the reservation would result in the task getting completed, but people can also replace (=release) the processing after which everyone sees it again.

Or is there an error that the work item does not reach all receivers in the first place?

Best regards,

Mikko

[Former Member]

Hi Mikko, thanks for your help but I thought the whole point of using the 'Other' tab was that it wouldn't allow the user to reserve the work item regardless of work item id, otherwise one could simply use the multiline element as the agent in the step and it will deliver the same effect. I've gone through the SWEL trace and there doesn't seem to be anything in error. In this case I have the same workitem being issued to 3 different agents and each workitem has it's own workitem id, as expected. However when the first user completes it the workitem is removed from the other's inboxes. It could be that I'm completing the workitem by raising an event through a custom object. The object key does not contain the workitem id, maybe this is the problem.

Thanks for your help anyway,

Kevin

[Former Member]

Hi Kevin,

sorry for reading your question through a bit too quickly.. But your right, yes, the dynamic table parallel function should behave exactly in the way you describe it.

If you don't have any end conditions defined on the steps Other-tab, then I believe the reason is that the tasks are asynchronous and the same event is catched by all the work items as you suggested. Could you run the event trace to see if this is the case?

-Mikko

[Former Member]

No worries Mikko, I always do the same. On the 'Other' tab there doesn't appear to be any other options available other than just entering the multiline element. This is the situation. This step in question calls a task which in turn calls an interactive bsp through a custom method of a custom object. The user completes the workitem by raising a custom event of the same ojbect. This event is one of the terminating events of the task. It could be the that the custom ojbect key does not contain any reference to the workitem id. I checked the asynchronous flag and I believe because this task is not a background task I have much choice to alter it. However I'm not sure now if that isn't somehow the problem or the lack of a workitem id in the object key.

Kevin

[Former Member]

Hi,

the end condition is then probably only available in was 6.40 onwards..

If the event is raised for an object, no work item id is needed in the object key. Have you checked what happens behind the scenes in the event trace when an event is raised? Do all the tasks pick up the same event?

-Mikko

[Former Member]

Yes that's exactly what's happening, I just don't know how to stop it. Sorry I'm on 4.7/620 by the way.

Kevin

[Former Member]

Ok then I'm a bit confused.. It could be something with the way the bsp application calls back the work item that makes all the work items respond to the event or something as you were informed on sap-wug.

Have you tried to test this separately using a simple user dialog task and leave the bsp out of it?

-Mikko

[Former Member]

Hi Mikko, the BSP simply calls a method which raises an event. This event is listed as a terminating event with the task. If I raise the event independently I get the same result. The object key does not contain any reference to the work item id. So what I think is happening is that when the event is raised it is ignoring the 'n' amount of work item ids and terminating the task regardless of work item ids. I tried incorporating the work item id in the object key. This prevented all of them from being terminated at once but it also prevented them from being completely terminated, in other words they would just hang there in 'STARTED' status.

Kevin

Kevin

[Former Member]

Hi Kevin,

sorry for the delay.. I'm sorry I can't help you much with the terminating events, I'm afraid there's something with them which isn't that compatible with the dynamic parallel processing or defining an event to terminate only a single work item. But I could be wrong, of course.

I think in general that if the BSP is there to terminate specific, predefined work items, a better option would be to pass it the work item ID and then use the URL callback mechanism, SAP_WAPI_WORKITEM_COMPLETE or equivalent to do the completion. Do you have any possibilities of changing the BSP if the events won't start working?

-Mikko