PR Workflow wf pur rejo WS65400029 - Rejecting Agent in Container

[Former Member]

We launched Workflow wf_req_rel_c and wf_pur_rejo WS65400029 successfully. But we have one additional request: to inform the Agent of WS65400029 about who has rejected the PR. This means the actual Agent of wf_req_rel_c is requested to be displayed in workitem text of wf_pur_rejo. The Problems starts with the fact that this are two different Workflows with no shared Container. We had different ideas to solve the issue, but None of them did really work: a) to propagate the Container element 'actual_agent' via Parameter of Event BUS2105 - Rejection_Start - but there are no visible Parameters in this Event - We could think about creating a ZBUS2105, add a Parameter to the Event and delegate to this Bus Class. b1) to write a "Bypass" table ZCA_SW_ACT_AGENT in program Exit of workflow wf_req_rel_c - we suceeded so far b2) to read this table in a data flow using a Business class in workflow wf_pur_rejo %ZCL_WF_USER.GET_REJ_AGENT(OBJID=&REQUISITONHEA DER.NUMBER&)% - we did not succeed with this issue since this is running in tRFC I have no idea how to debug this data flow method call We find the Agent for wf_pur_rejo by reading the last but one entry in this Bypass table - this works fine. This is the last Person who released the highest release Level before being rejected. c) to read the Container of the "Father workitem" using the data field 'WorkitemFather' in the Container of wf_pur_rejo. Is there a class (e.g. CL_SWF_CNT_* ) to read the external Container: Please help to find an idea to solve this Problem with Minimum effort. Best thanks in advance Dieter

[pokrakam · Accepted solution]

@Ronen - I don't know so much about paragraphs, maybe they are overrated and Dieter is ahead of his time, so I'm going to give it a go. @Dieter, my approach would be to read the last rejection, which can be done with function module SAP_WAPI_WORKITEMS_TO_OBJECT. This will get you all the tasks that have worked on the PR. From here it's a simple matter of applying a bit of logic to the results: Filter them by the task ID to get the approval work items, get the latest by date to make sure you have the right one, and if you wanted to take it one step further you could even read the outcome to ensure the last decision was indeed a rejection. One of the result fields should be the actual agent who completed the work item. Hope that helps, Mike

[Former Member · Accepted solution]

Thanks a lot to both Ronen and Mike. Sorry for the inconvenience with the paragraphs. Obviously I had some struggle with the Editor and lost them when sending the message.

Please allow two additional questions:

where would you call the function module SAP_WAPI_WORKITEMS_TO_OBJECT:

In a method called in a data flow Operation?

in an additional workflow step of type "Container Operation" - calling a method?

in an additional step calling a Task with a short method reading and writing Container?

Or is there another Approach which I missed and could be easier to implement?

How is it possible to debug this coding? As far as I saw this external second workflow wf_pur_rejo is called via tRFC? Should I set "Block sending tRFC" in Debugger Settings and debug it from tx SM58?

@Ronen: I thought about the possibility of Delegation but I doubt if I can propagate the Container element ACTUAL_AGENT to the Parameters of Event REJECTION_START without modifying the code where the Event is triggered? In SWO1 I can't find any parameter on this event - except the implicit object PR.  Or will it be transferred just by identity of field names?

Thanks a lot indeed

Dieter

[pokrakam · Accepted solution]

You don't mention whether you tried the simplest option: _WF_INITIATOR of the rejection flow?

If the rejection is done in dialog, this should be the rejecting user. If it is done by decision and background task (more secure), then it will be WF_BATCH.

To your questions: I would use a container operation rather than binding (Datenfluss), for the simple reason that it is a business-relevant activity and a container operation makes it more visible. Something technical like getting a user's full name is OK to do in binding.

re. debugging, this should be easily testable standalone. e.g. your example %ZCL_WF_USER.GET_REJ_AGENT(OBJID=&REQUISITONHEADER.NUMBER&)%, look at the value of &REQUISITONHEADER.NUMBER& in the log and test the method with that.

Small design comment: I don't quite agree this should be a static method of a user class (but of course it's fine for testing). If anything it would belong to a requisition class, preferably with an instance.

Thus &REQUISITION.GET_REJ_AGENT( )& would return an instance of ZCL_WF_USER.

Regards,

Mike

[Former Member · Accepted solution]

@Mike:

Regarding your question about _WF_INITIATOR: As far as I could see in container in protocol this field contains not the rejection agent but the first agent - the person who created the PR initially.

But anyway - the solution is working fine by using a data flow method call.

Thanks a lot indeed

Dieter

[ronen_weisz]

How about creating a an attribute for BUS2105 (by delegation) to display the agent who rejected the task? you can find the workitems related to the PR in table sww_wi2obj and then reading the actual agent from table swwwihead or by using FM 'sap_wapi_workitems_to_object'.

P.S

kindly use paragraphs.