Who missed deadline?

[Former Member]

Business requirement - Send escalation mails to different levels of the manager based on how many days a work item is past due. For example in a parallel processing workflow, agent A, B, C were chosen to do approval. If agent C forwarded work item to agent D, escalation mail should go to D's supervisor instead of C's supervisor when deadline is missed.

Problem - How do I capture the actual agent after a work item was forwarded(although I can see it obviously in workflow log). I found function modules available to use but they all require work item ID as input parameter. The issue I had was I won't be able to get work item ID until work item is executed(through binding). I also tried to use "Method Before work item EXECUTION" but I did not see information I want populated in workflow container.

Could anyone please share your thoughts how this problem can be solved?

Thank you,

Merta

[Former Member · Accepted solution]

Hi Merta,

I think you have to determine the active WI based on the workflow WI. You could for example implement it on the FLOWITEM (delegated) subtype.

Regards,

Michal

[sudhindra_chandrashekar]

Hi,

Under the container element _Workitem of that particular step there is a container element called WorkitemActualAgent. This looks like the Last actual agent who had the workitem in his name and also you have an element called WorkitemForwarderBy. I guess you can bind them from the task container to the workflow container and then check them.

Hope this helps,

Sudhi

Message was edited by:

Sudhindra Chandrashekar

[Former Member]

Hi Sudhi,

The issue was those elements will not set until work item is executed.

Regards,

Merta

[Former Member]

Hi Merta,

This is a tough one. Can't use the original agent determination because C has forwarded to D.

What you can do is this.

Use FM RH_WI_ORGTASK_READ passing in the workitem ID of the dialog workitem for which the deadline was reached. This will be the element _WORKITEM.WorkitemID in your step container (this is where you get the Workitem ID before the item is executed).

The function will return a table containing two entries - one for C and one for D. But C has the value 'X' in the field NO_SEL which means they are not relevant for selection. You can therefore use the returned agent D to determine your escalation.

Regards

Gareth

[Former Member]

Hi Gareth,

How can I use that FM in this particular decision step? You said to use that FM when deadline was reached - I assumed you meant to use "modeled" deadline. Again I am still stuck at where could I capture _WORKITEM.WorkitemID in the step container before the step is executed to pass it to the new method I created with this FM? I don't think you meant to customize the Decision.Process method with this FM.... Could you please tell me what I missed?

I got an idea from your reply by trying Modeled deadline. I thought I can use dummy method in the outcome branch when deadline is reached to get parent ID(what I am after). My simple test workflow is like this: workflow start (ID 331288) -> Specify agent ->(ID 331289) -> Approval (ID 331290 ) -> Dummy (ID 331291). Surprising the parent WI ID of 331291 is not 331290 but 331288. I also test it with FM "SWW_WI_FIND_FATHER_WIS" and get the same result. This is so strange .... Do you know why?

Thanks again,

Merta

Message was edited by:

Merta Her

Message was edited by:

Merta Her

[Former Member]

Hi Merta,

I was thinking of placing the function call in a modelled deadline step after passing the workitem ID to a new container element as you tried. The issue you have note is because the parent is the overall flow (the type F item) which is used to determine which overall workflow instance the WI in question belongs to.

You could take the parent WI and then read SWWWIDEADL for the deadline type you are using and this will give you the correct WI in the field WI_ID.

Regards

Gareth

[Former Member]

Hi Merta,

How did you go getting the WI from SWWWIDEADL in the modelled deadline? I had a chat with some colleagues about this last night and another idea put forward was to take the WI of the Flow (Parent WI), and read from SWWWIHEAD all child WIs based on this as a creator which are dialog and referring to your task.

My only problem with this is what happens if you have more than one item in DL state.

Anyway, it could be an option is the SWWWIDEADL can't be used (but I think it can).

Regards

Gareth

[Former Member]

Hi Gareth,

I did more searches and studies yesterday for FMs . This is the approach I will try - after getting workflow WI ID( top one) , I will use FM "SAP_WAPI_GET_DEPENDENT_WIS" to get its dependents then filter them by right task number with FM "SWP_WORKFLOW_HEAD_READ" to get those instances I try to locate.

I felt what I want to do sounds so simple but the approach I had now is not straight forward at all. If I use the example in my second mail, WI ID 331291 was spawn( I hope this is the right way to "described" it as it's generated when the deadline is reached) from WI IS 331290, I just don't get it why it's so cumbersome to retrieve it.

I hope you could give me an idea in my original approach in this issue - have you ever used "Method Before work item EXECUTION" in method tab? I created a method with FM "SWE_WI_GET_FROM_REQUESTER"( the FM to get current WI) and used in the decision step. It did not work at all however it's tested fine by itself.

Thank you again for your help.

Merta

[Former Member]

Hi Merta,

The only time I have used method Before Execution is to demonstrate its operation. Because one of the objectives I have in workflow development is ease of troubleshooting I have not used it for a live customer site. But that is not to say it would not be OK in this case, but I have doubts as to whether the child workitems would be returned as a dependant WI as I can't see how it has been created and the WI tables updated before execution.

Hmm I 'll have to have a think about this one.

Regards

Gareth

[Former Member]

Hi Gareth,

I had little bit confusion in escalation process. can you give me the guide line for my requirement

If the person responsible(A) does not respond within 3 days, the request will be escalated up one level to the manager(B) of the person responsible(A) through workflow. If the manager(B) does not respond after 3 days, the request will be sent back to workflow initiator.

how to forward work item when dead missed.

currently i am tryoing with latest end tab with modeled. i set the 3 days time in tab and included one process con control with obselute. then here i strucked up.

in obselute branch which task i have to include to forward to superior.

is it the correct way .. if wrong correct me

[Former Member]

Hi ABAPER_REQ

Sorry to take so long to reply. This is basically how I do it:

Before the loop find the initial manager (A) and pass to element AGENT (type swf_actor)

Place the following in a loop until approved (flag element to control):

• Approval (or any dialog) - agent=AGENT. Modelled DL set to 3 days. On approval set flag to exit loop.

• On deadline, calculate new AGENT, set approval step to obsolete. Thus loop again.

And so on. You must remember to have the obsolete outcome modelled for your approval step so we pass through the loop.

One common problem - It is worth creating a fork based on AGENT=WF_Initiator to allow the initiator to get a dialog allowing them to select a new approver, without them having the ability to actually approve the workflow.

Regards

Gareth

[Former Member]

Hi gareth,

Thanks for ur reply.

I also tried same thing. i am getting one error.Do you have idea on this.

"No succesor defined for node XXXX and Result cancelled by the user. WL 411

I am not clear about the fork you mentioned in common problem. can you please explain me little bit more.

Thanks,

sri harsha.M

[Former Member]

Hi Sri Harsha.M

The successor error is most likely caused by the way your modelled process is ending. Please refer to this <a href="http://help.sap.com/saphelp_47x200/helpdata/en/c5/e4b97e453d11d189430000e829fbbd/frameset.htm">Help Document</a> to review your build.

What I meant by the common problem is that, if at the end of an escalation process, the original creator is the agent, then is may not be appropriate for them to approve the item which they initially had to send for approval. Thus I put in a condition that, where the agent is the initiator, they do not get the approval task, they get a new dialog allowing them to select a new approver to restart the process.

Regards

Gareth