Skip to Content

Capture Workflow Container Values

Business Scenario:


The SAP system must record all the intermediate values of different variables in a Workflow process. Standard SAP Workflow report does not provide all the Workflow and Task container values in a single row. It is necessary to store these variables for the purpose of detailed reporting and auditing.

This document provides a custom solution for capturing run time container values in a Purchase Requisition release workflow.

Purchase Requisition Release Workflow example


For the purpose of demo, consider Standard Purchase Req. Release Workflow – WS20000077. A new activity step with a dialog task ‘Request Rejection Reason’ has been added to the outcome ‘Release Refused’. This task prompts the Reviewer to provide a Rejection / Refusal Reason.

/wp-content/uploads/2013/07/1_249172.jpg      

This new container variable ‘Rejection Reason’ is not available for End Users within any standard Workflow report.

/wp-content/uploads/2013/07/2_249188.jpg

The container values can be captured by implementing Programming exit in to a sample database table as shown below.

/wp-content/uploads/2013/07/3_249189.jpg

Implement Workflow Programming Exit


  • Call Transaction ‘SE24’ – Class Builder and enter a Z class object type name ‘ZCL_PR_WORKITEM_EXIT’ and click ‘Create’

/wp-content/uploads/2013/07/4_249192.jpg

  • On the Subsequent popup – enter a description for the class.

/wp-content/uploads/2013/07/5_249193.jpg

  • Choose instantiation type as ‘Public’ since we want all components of this class to be accessible within the Workflow. Click ‘Save’.
  • Next go to Interfaces tab and enter Interface name as ‘IF_SWF_IFS_WORKITEM_EXIT’

/wp-content/uploads/2013/07/6_249194.jpg

  • Since class ‘ZCL_PR_WORKITEM_EXIT’ is implementing interface ‘IF_SWF_IFS_WORKITEM_EXIT’, the method EVENT_RAISED of the interface gets automatically available to this class.

/wp-content/uploads/2013/07/7_249195.jpg

  • Double click on the method – ‘IF_SWF_IFS_WORKITEM_EXIT~EVENT_RAISED’ and write the following code:

METHOD if_swf_ifs_workitem_exit~event_raised.

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

* This exit is called by the workflow system at different stages of work item

* processing e.g. before creation, before execution, after execution etc.

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

* Data Declaration

  DATA: ls_wihead             TYPE swr_wihdr.

*       Workflow Container object

  DATA: l_wf_cont             TYPE REF TO if_swf_ifs_parameter_container,

*       Task Container object

        l_wi_cont             TYPE REF TO if_swf_ifs_parameter_container.

  DATA :

        ls_pr_wf_values       TYPE zpr_wf_values,

        l_value               TYPE string,

        l_rej_reason          TYPE zrej_reason.

* Fetch Current Work Item Header

  ls_wihead = im_workitem_context->get_header( ).

* Skip This exit if the Work item status is ERROR

  CHECK ls_wihead-wi_stat NE swfco_wi_status_error

  AND   ls_wihead-wi_stat NE swfco_wi_status_excpcaught

  AND   ls_wihead-wi_stat NE swfco_wi_status_excphandlr.

* Fetch Workflow Container

  l_wf_cont = im_workitem_context->get_wf_container( ).

* Fetch Work Item Container

  l_wi_cont = im_workitem_context->get_wi_container( ).

* Check for current Event

  CASE im_event_name.

*   Event ‘State Changed’ indicates that the Work Item now has a new processing status

    WHEN swrco_event_state_changed.

*     The ‘Rejection Reason’ will be available in Work Item container only after Execution of Work item

      IF ls_wihead-wi_stat = swfco_wi_status_completed. ” STATUS – COMPLETED

        CLEAR l_value.

        CALL METHOD l_wi_cont->get

          EXPORTING

            name  = ‘RejectionReason’

          IMPORTING

            value = l_value.

        WRITE l_value TO ls_pr_wf_values-rej_reason.

*       Also fetch Release code from Workflow container

        CLEAR l_value.

        CALL METHOD l_wf_cont->get

          EXPORTING

            name  = ‘ReleaseCode’

          IMPORTING

            value = l_value.

        WRITE l_value TO ls_pr_wf_values-REL_CODE.

*       Store Rejection date and time

        MOVE :

             sy-datum               TO ls_pr_wf_values-rej_date,

             sy-uzeit               TO ls_pr_wf_values-rej_time..

*       Store Reviewer name

        CLEAR l_value.

        MOVE ls_wihead-wi_aagent  TO ls_pr_wf_values-reviewer.

*       Store Purchase Req.number from new task variable – Purchase Req.

        CLEAR l_value.

        CALL METHOD l_wi_cont->get

          EXPORTING

            name  = ‘PurchaseReq’

          IMPORTING

            value = l_value.

        WRITE l_value TO ls_pr_wf_values-banfn.

*       Update the PR Workflow values table

        MODIFY zpr_wf_values FROM ls_pr_wf_values.

*       Do not write COMMIT statement in this Program Exit

*       The database table will be committed along with Workflow internal

*       COMMIT

      ENDIF.

    WHEN OTHERS.

  ENDCASE.

       ENDMETHOD.

  • Save and Activate Class ZCL_PR_WORKITEM_EXIT
  • Double click on the new task ‘Request Rejection Reason’ and go to tab ‘Program Exits’ and specify the newly create class ZCL_PR_WORKITEM_EXIT

/wp-content/uploads/2013/07/8_249196.jpg

  • Save and Activate Workflow template.

Working DEMO


  • Reviewer of Purchase Requisition hits the Reject Button

/wp-content/uploads/2013/07/9_249197.jpg

  • Reviewer is prompted to enter the Rejection Reason

/wp-content/uploads/2013/07/10_249198.jpg

  • Custom table ZPR_WF_VALUES now contains the runtime container values.

/wp-content/uploads/2013/07/11_249199.jpg

9 Comments
You must be Logged on to comment or reply to a post.
    • In case we require a detailed report of all run time workflow values for the entire year, calling function SAP_WAPI_READ_CONTAINER thousands of time may not be an efficient solution. So this is just an alternate method.

      • Tammy – is it possible you are anticipating a performance problem that hasn’t happened yet? Probably best to use SAP_WAPI_READ_CONTAINER first – see how it performs, and avoid more drastic measures such as switching back to the old non-XML handling as a last resort.

        Just a thought.

        Jocelyn

        • Jocelyn,

          I agree with you. But from a development perspective, I would try to avoid any function being called thousands of times in a loop ( OR loop within a loop for N level approval). Yes – it would be in anticipation of a problem – which may or may not happen depending on the volume and frequency of the audit report.

          There is one another caveat – Many Workflow Container variables (like status) assume different values at different stages in the workflow process. So they may get over written multiple times. During a month end, SAP_WAPI_READ_CONTAINER will provide the final value of that variable and not the interim values.

          Tanmay

  • Hi Tammay,

    my requirement is same .

    please help me how you get that popup to enter rejection reason when user click on reject

    Release Button .

    please help me.

    • Hi Phanikumar,

      You can extend Business object BUS2105 and add a custom method –  RequestRejReason. Within this method – you can use function ‘POPUP_GET_VALUES’ to obtain Rejection reason from the Reviewer. You can then include this method as a task within the workflow – Refusal branch. Let me know if you need more details.

      Tanmay

  • Hi Tanmay,

    Thanks for your replay.

    In the above example the popup for rejection reason is appearing when user reject PR in ME59 tcode using workflow.

    if we use POPUP_GET_VALUES function module it may appear after closing or rejection of PR in ME59 using workflow .

    my requirement is  for PO release.

    so i copied standard workflow WS20000075.in that TASK TS20000166 which will call method SINGLERELEASE . so i am thinking that this method will call ME29 for PO release .

    please guide me it is right or wrong.

    please help.

    Thanks.