Setting Priority for Workitems Dynamically in SAP Workflow

[Former Member]

Table of Contents

1.. Document Objective. 3

1.1   Introduction. 3

1.2   Audience. 3

1.3   Scope  3

2.. Document Detail 4

2.1   Static method. 4

2.2   Dynamic Method. 6

1.    Document Objective

1.1 Introduction

Often we have a requirement in workflow to specify priority of a workitem. Priority of a workitem decided the importance of the workitem for user and workflow engine route the same into the user’s inbox with the given priority. Priority comes from 1 to 10 ranges where 1 denotes the highest priority and user receives a popup as soon as workitem with priority one reaches to his inbox and 10 denotes the lowest priority workitem.

Screen shot of inbox displaying priorities column.

By default SAP Workflow sends all the workitem with priority 5 that is medium. This document describes the ways by which we can assign priority to a workflow/workitem.

For example: In a business scenario, where down payment process is implemented through workflow and every request raised needs to be approved by finance manager. But depending on the request priority as well as month date (1 to 30) , the escalation time , and the workitem priority should be different so that approver can choose critical request first and then others. Critical request can be escalate earlier than the normal one.

1.2 Audience

This document targets all the SAP Workflow technical and functional consultants.

1.3 Scope

The scope of this document covers the coding tricks and methods to implement the requirement of assigning priority to a workitem statically or dynamically. We will take a simple example workflow (Demo) to explain how we can set priority to a workitem and implement the functionality. Workitem container has a priority field with it but manipulating that variable by binding or assignment is not allowed so we need to below described methods.

2.    Document Detail

For assigning priority to a particular workitem in workflow, we can follow any method out of these 2, depending on our requirements.

• Static method
• Dynamic method

2.1    Static method

By this method as the name suggest , we can assing priority of a whole workflow (not the workitem individually). Before stating the workflow , there is a field in workflow container that can be populated in binding with event with the desired priority and then the workitems that comes under the same workflow will have the priority of the parent workflow.

We can assign this priority when binding it with event.

But this assignment will change the priority of whole workflow and every dialog task in this workflow. Like in this example below.First we are trying to assign priority to the workflow binding directly and check the user decision task priority. Testing the workflow directly and assigning the priority value as “1”.

Check the inbox of other user to see the high priority workitem.

Inbox view of the workitem.

Advantages of this method

1. Very easy to implement.

2. If we have only static priority throughout the workflow , this is very good option.

3. If workflow design is already dividing the workflow in subworkflows for displog workitems then this is the right approach to follow as every subworkflow can have different priority.

Disadvantages of this method

1. Static priority will prevent any other normal workitem in the workflow to have defualt priority or different priority.

2. Once set , you cannot modify thepriority of workflow. It will be always the priority you set in the starting.

3. As it can set only in starting of a workflow / sub workflow , it is not being decided by runtime values of the workflow.

2.2    Dynamic Method

This method is more dynamic than the previous one. To understand this , first we need to know that in workflow , there is not method to set priority of a workitem at runtime before generating it. There are function modules but all of them can set the priority or change the priority after creation of the workitem but not before as all of them take workitem ID as input. If you go to any task container , there is a task container variable , but we cannot modify it by assigning values in binding , hence workflow itself is working on static priority assignment at the time of workitem creation.

This solution is working reverse side as first the workitem will be created and just after the workitem creation we will get the container of the workitem for any run time values for deciding priority and change the workitem priority.

2.2.1 Implementation in class

For this method implementation , we need to develop a class that will inherit the interface for Workflow as well as workflow exit like this.

IF_SWF_IFS_WORKITEM_EXIT is a interface that we must specify in this Z class as it will provide many standard events that we are going to explain furthur.

The class will now contain many attributes that are inherited from the interface.

These are basically event that are associated to the workitem. These events are internal to workflow and are not available outside the workflow. Like AFTER_CREATE event will get trigger after the creation of workitem.

These are the methods that are available in the class by the interface to implement.

In this the very first method EVENT_RAISED is the method , which is getting triggered whenever these events are happening. We need to make implementation of this method.

In the method , we can write this code.

METHOD if_swf_ifs_workitem_exit~event_raised.
DATA :  wiid TYPE sww_wiid,
lo_wihandle TYPE REF TO if_swf_run_wim_internal,
lo_container TYPE REF TO if_swf_cnt_container,
lv_wiid TYPE sww_wiid,
lv_priority TYPE swwwihead-wi_prio.

*Here check for event : these are workflow internal events
CASE im_event_name.
WHEN if_swf_ifs_workitem_exit~c_evttyp_after_create.

CALL METHOD im_workitem_context->get_workitem_id
RECEIVING
re_workitem = wiid.

*   Get container and value
TRY.
lo_wihandle = cl_swf_run_wim_factory=>find_by_wiid( lv_wiid ).
lo_container = lo_wihandle->get_wi_container( ).
CATCH cx_swf_run_wim.
ENDTRY.
*   Read container
TRY.
lo_container->element_get(
EXPORTING
name             = 'PRIO_VALUE'
IMPORTING
value            = lv_priority ).
CATCH cx_swf_tst_introspection_error.
CATCH cx_swf_cnt_container.

ENDTRY.
*You Can implement any condition based on the workitem container and decide the *priority
*Change the priority of workitem just after the creation and before delivering to the inbox
CALL FUNCTION 'SWW_WI_PRIORITY_CHANGE'
EXPORTING
priority         = lv_priority
wi_id            = wiid
EXCEPTIONS
no_authorization = 1
invalid_type     = 2
update_failed    = 3
invalid_status   = 4
OTHERS           = 5.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.

ENDCASE.

ENDMETHOD.

2.2.2 Implementation in workflow

Now we need to make use of this class in workflow. In the task , there is a tab called “Program Exit”. This is the tab that will take a class which is related to the workflow internal events and inherits the interface for the exit.

Now , whenever this workitem will comes into the flow, these internal events mentioned in the class will get triggered and the default method will get triggered for each event where we already put our code on “After_Create” event for the workitem.

Now testing the working.

Now check the inbox.

Inbox view of the workitem

Advantages of this method

1. It can handle very complex scenarios like multiple dialog tasks with multiple priorities.
2. It is dependent on the different class so separate from workflow logic.
3. Flexibility as many events are avaiable to perform the different tasks.

Disadvantages of this method

1. Unexpected error handling is difficult in case of dump in class etc.