Skip to Content
author's profile photo Former Member
Former Member

Anyway to change the req.status container in wf?

Dear all workflow expert,

Anyone knows how to change the req.status so that i can do a 2 level approval or anyone can suggest me a way to do it apart from what i did below?

Thanks

Regards,

Bryan

**************************************************************************************************************

I am in trying to customize the the standard leave request WF 12300111 to a 2 level approval and therefore i copy this wf out to customize it. I created one of the step to change the Req.status container back to the status "SENT" so that the second approval can approve it.

What i do was i bind the Req.status to a container i created in a task (cus_req_sta) and the task is tie to my customize BOR object. Then i bind this cus_req_sta to my method parameter in the BOR object and i have the follwing code in my bor method.

BEGIN_METHOD ZLEVREQ CHANGING CONTAINER.

DATA:

LEAVESTA TYPE PTREQ_HEADER-STATUS.

V_LEAVESTA TYPE PTREQ_HEADER-STATUS.

SWC_GET_ELEMENT CONTAINER 'cus_req_sta' V_LEAVESTA

V_LEAVESTA = 'SENT'.

SWC_SET_ELEMENT CONTAINER 'cus_req_sta' V_LEAVESTA

END_METHOD.

After i change the value in the method, i bind it back from the method to my task and then from task to the workflow. Everything is fine untill the step to pass the value (sent) from task to workflow. It seems that it does not allow me to pass back the value to Req.status container in the workflow. The Req.status does not updated at all.

The req.status parameter setting is set to import and export when i browse it in the main screen (before entering to the workflow builder). However when i am doing the binding for task back to the workflow (after i drag and drop the req.status and double click on it), it shows the check box for import and export parameter settings is not check.

Anyone have idea? Please help me.....Points will be rewards.....Thanks

Regards,

Bryan

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Jun 09, 2008 at 08:08 AM

    Hi Bryan,

    just to verify the task->workflow container binding: are you trying to bind a simple task container element to the workflow container element Request (class type CL_PT_REQ_WF_ATTRIBS) attributes?

    If yes, that won't work since you can't dynamically change an object instances attributes with workflow bindings at runtime (because that would in general make the class instance inconsistent and not depicting the real class instance).

    What you need to do is to change the leave request status instead of just faking the change in the workflow. How to accomplish this: replace the coding you have in the background step method to change the leave request status. An example code for changing the request status is given in class CL_PT_REQ_WF_ATTRIBS method APPROVE.

    So to reset the status to SENT, just call method cl_pt_req_badi=>initiate_state_transition with im_event = cl_pt_req_const=>c_reqtrans_send and you've changed the document status.

    Hope this helps,

    -Mikko

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Hi Brian,

      yes, the standard leave request approval application picks up all leave requests with status SENT from the approvers subordinate employee list. Resetting the status to SENT after the first approval will thus keep the leave request displayed on the first approvers approval list.

      I haven't found a way around this "feature" myself. What we've done instead is to create our own copy of the approval application, pass it the work item ID and make the custom application then retrieve the leave request details for approval (without any annoying second worklists on the leave request approval application).

      Of course the most elegant way would be to incorporate a new status for the second approval, adjust the std application to read/write that status as well, but I didn't see that as a feasible option because of major work in the time management business logic.

      So in summary, statuses won't help you with the second level approvals and the problem of the leave request approval showing up on the first approvers screen. What I suggest instead is to use another approval tool in the second approval and leave the status as approved from the first approval. The second approval would then be done either as a user decision on the UWL or in a custom web application. The approval result would then just be stored in the workflow as a selected outcome.

      Hope this helps,

      -Mikko

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.