Skip to Content
Technical Articles

Discover approval level in MM Flexible Workflow agent determination BAdI

Introduction

Hi and welcome to my next SAP Community blog post.

Recently I had an opportunity to work on SAP Flexible Workflow for Purchase Order approvals.

Flexible Workflow is a Fiori integrated solution for creation of document approval processes. Its main strength, ease of use, comes from little or zero need for programming interference. Basic scenarios can be created using configuration only. If you have a more complex situation, you can use one of the available BAdIs – for example the MMPUR_WORKFLOW_AGENTS_V2 BAdI, which allows for customer specific approval step agent determination logic.

Approval Step Agent Determination Options

Options for approval step agent determination

This blog post first appeared on the Int4 blog.

The issue of missing approval level

At the first glance, the BAdI seems like a perfect solution for implementation of a complex agent determination logic. It consists of a single method called GET_APPROVERS, which is populated with basic information about the document, for which the scenario was triggered.

Agent Determination BADI Parameters

GET_APPROVERS method parameters

  • As you can see, there is the BusinessObject parameter, which will tell you whether it’s a Purchase Order, Purchase Requisition or other document.
  • There are document and item numbers in the PurchasingDocument and PurchasingDocumentItem parameters respectively.
  • There is the WorkflowScenario, which will provide you with the ID of the scenario, for which the determination has been triggered.

 

More information about the BAdI and its parameters can be found in the SAP OSS note #2646400. In the same note you can also read that the information about the current step (level) is available in the BAdI from the 2008 release only and only for Purchase Requisition and Central Purchase Requisition documents.

Why is the level information so important?

To be able to correctly determine the agents for the approval step, you need to know for which level the BAdI was executed. In a static scenario, where all approval steps are triggered, you can achieve this by simply counting the previous approvers, contained in the PreviousApproverList parameter. However, in case of two or more non-obligatory approval steps, or an obligatory step after a non-obligatory one, the PreviousApproverList count will give incorrect results. Consider the example as shown in the image below:

Flexible Workflow Scenario Comparison

Comparison of two Flexible Workflow scenarios

Scenario B shows that the level calculated based on PreviousApproverList will be untrue (3 instead of 4). This may cause assignment of an incorrect agent and faulty workflow processing.

Approval level calculation

Fortunately, you can calculate the current approval level with the information that is available in the system during the BAdI execution.

This information consists of two parts:

  • XML with the details of Flexible Workflow and its flow so far – it contains information about the steps (ACTIVITY) that have been processed (COMPLETED) or skipped (SKIPPED) before the BAdI execution.

Flexible Workflow Process Flow XML

Flexible Workflow process flow XML

  • Workflow log – it contains information about the steps that were skipped just before the BAdI execution.

Skipped Steps in Workflow Log

Information about skipped steps in Workflow log

You can use PurchasingDocument and WorkflowScenario parameters to obtain the first part. Method GET_WORKFLOW_INSTANCES of class CL_SWF_FLEX_DEF_FACTORY will return a list of Flexible Workflow instances executed for the document. The last instance executed (the one with the highest WORKFLOW_ID) is what you should be looking for. You then need to parse its XML and count the steps.

The second part is more tricky. Theoretically, there is the standard function module SWW_WI_LOG_GET_BUFFER that you can use to read the Workflow log. However, this function removes messages of the same type that were triggered in the same second, which makes it useless in this case.

Workflow Log Buffer Function

Function to read Workflow log buffer

To avoid this, you can use a FIELD-SYMBOL and direct Workflow log buffer assignment, which will give you access to all messages stored in the buffer.

Below you can find the whole logic with the method interface:

Step Count Method Interface

The parameters of the approval level calculation method

METHOD calculate_current_level.
  DATA:
    lv_xml_steps   TYPE i,
    lv_log_steps   TYPE i,
    lv_scenario_id TYPE swd_wfd_id,
    lv_object_id   TYPE sibfboriid,
    ls_message     TYPE swf_t100ms.
 
  FIELD-SYMBOLS:
    <lt_log_buffer> TYPE swlloghist_t.
 
  rv_step = 0.
 
  lv_object_id = iv_purchase_order.
  lv_scenario_id = iv_workflow_scenario.
 
  DATA(lo_wf_inst) = cl_swf_flex_def_factory=>wf_inst_handler( ).
  DATA(lt_instances) = lo_wf_inst->get_workflow_instances(
    EXPORTING
      iv_scenario_id = lv_scenario_id
      iv_appl_obj_id = lv_object_id
      iv_is_draft    = abap_false
      iv_context     = || ).
 
  SORT lt_instances BY workflow_id DESCENDING.
  READ TABLE lt_instances REFERENCE INTO DATA(ld_instance) INDEX 1.
  IF sy-subrc <> 0.
    RAISE EXCEPTION TYPE cx_swf_flex_ifs_exception.
  ENDIF.
 
  DATA(lo_ixml) = cl_ixml=>create( ).
  DATA(lo_stream_factory) = lo_ixml->create_stream_factory( ).
  DATA(lo_document) = lo_ixml->create_document( ).
 
  " parse xml-data into dom
  IF lo_ixml->create_parser(
    document = lo_document
    stream_factory = lo_stream_factory
    istream = lo_stream_factory->create_istream_xstring( string = ld_instance->xmlresource ) )->parse( ) <> 0.
 
    RAISE EXCEPTION TYPE cx_swf_flex_ifs_exception.
  ENDIF.
 
  " iterate dom and count steps
  DATA(lo_process_flows_itr) = lo_document->create_iterator( ).
  lo_process_flows_itr->set_filter( lo_document->create_filter_name_ns( name = 'processFlow' ) ).
 
  DATA(lo_process_flow) = lo_process_flows_itr->get_next( ).
  WHILE lo_process_flow IS BOUND.
    DATA(lo_activities_itr) = lo_process_flow->create_iterator( ).
    lo_activities_itr->set_filter( lo_document->create_filter_name_ns( name = 'activity' ) ).
 
    DATA(lo_activity) = lo_activities_itr->get_next( ).
    WHILE lo_activity IS BOUND.
      DATA(lo_attributes) = lo_activity->get_attributes( ).
      DATA(lo_runtime_status) = lo_attributes->get_named_item_ns( name = 'runtimeStatus' ).
      DATA(lv_runtime_status) = lo_runtime_status->get_value( ).
 
      CASE lv_runtime_status.
        WHEN 'COMPLETED' OR 'SKIPPED'.
          lv_xml_steps = lv_xml_steps + 1.
        WHEN OTHERS.
          " do nothing
      ENDCASE.
 
      lo_activity = lo_activities_itr->get_next( ).
    ENDWHILE.
 
    lo_process_flow = lo_process_flows_itr->get_next( ).
  ENDWHILE.
 
  " get message from WF log's buffer
  ASSIGN ('(SAPLSWWL)LOG_BUFFER[]') TO <lt_log_buffer>.
  IF sy-subrc = 0.

    " count how many steps have been skipped
    " because of preconditions
    LOOP AT <lt_log_buffer> TRANSPORTING NO FIELDS
      WHERE wi_id = ld_instance->workflow_id
        AND meth_user = sy-uname
        AND workarea = 'SWF_FLEX_RUN'
        AND message = '005'.
 
      lv_log_steps = lv_log_steps + 1.
    ENDLOOP.
  ENDIF.
 
  rv_step = lv_xml_steps + lv_log_steps.
 
  " There were &1 (&2/&3) steps before Agent Determination BAdI
  MESSAGE s007(ym) WITH rv_step lv_xml_steps lv_log_steps INTO DATA(lv_message).
  MOVE-CORRESPONDING sy TO ls_message.
 
  CALL FUNCTION 'SWW_WI_LOG_WRITE_SUCCESS'
    EXPORTING
      do_commit   = abap_false
      fb_name     = 'Agent Determination BAdI'
      wi_id       = ld_instance->workflow_id
      log_message = ls_message.
 
  " add 1 for current step
  rv_step = rv_step + 1.
ENDMETHOD.

Summary

Even though the current approval level isn’t always necessary for agent determination, there are cases where the determination would be flawed without it. Fortunately, it is possible to calculate it with the use of the Workflow log and its processing history.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.