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.
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.
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:
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
- Workflow log – it contains information about the steps that were skipped just before the BAdI execution.
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.
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:
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 'CANCELLED'. " Edit 2023-08-11
lv_xml_steps = 0. " If step was cancelled, then a new WF was created, steps should be counted from the start
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.
Edit 2023-08-11
I've noticed that it's possible to have more than one WF execution assigned to a single PO. This happens when a WF is cancelled before it can be finished, e.g.: the PO is changed when it is in the process of approval.
In this case the WF instance is divided into so called blocks, where each of the blocks is a separate execution of the WF. Only the last execution is active, but the information about activities of the previous executions is contained in the XML and influences the step counter.
Hence the additional check on LV_RUNTIME_STATUS = CANCELLED, which clears the step counter just before activities from the next WF block are processed.
- SAP Managed Tags:
21 Comments
