S/4HANA Flexible Workflows: Workflow Scenario Development and Configuration

Alan has suggested in his blogs that SAP Business Workflow Builder (SWDD) is not the recommendation anymore in S/4HANA. Workflow processes which are not spread across different systems, should make use of workflow scenario development. Alan’s blogs should give you fair idea about the reasons behind this recommendation. It is important to go through this blog and associated blogs before reading further.

There are many standard workflow scenarios available in transaction SWDD_SCENARIO / SWDD_SCENARIO_DISP, which I referred to understand S/4HANA flexible workflows. For a hands-on experience and to feel confident about a topic, it is important to develop something yourself from scratch. So, I decided to develop a simple and full custom workflow scenario and to configure it in Manage Workflows application. In this blog series, I will share the steps I followed and how simple eventually it is for business / key users to configure/change a workflow.

This workflow process is to update table entries in a custom table. Entry is created through a program and then entry goes through 2-step approvals before finally being created in custom table. Important information regarding the development:

1. Custom table is for a hypothetical user master with a few fields.
2. Business user should be able to decide the company id for which entry is created in table, at workflow level and step level. This will be achieved by creating a condition in workflow scenario.
3. For simplicity reasons, approver for both the steps would be workflow initiator. However, it is possible to define own approvers or define different rules to determine the approver.
4. First approval step is to validate the entered user data and second approval step to finally give the approval to create records in custom table.
5. We will make use of framework provided exceptions. Though, it is possible to define custom exceptions. So, no specific exception related processing is done.
6. There could be various better ways to achieve the same requirement. This blog strives to show the simplicity and steps for a flexible workflow – workflow scenario.
7. This blog just shows a very limited set of flexible workflow’s capabilities. I have seen that most of the SWDD workflow builder’s capabilities are possible in flexible workflow, with better control, handling and in much cleaner way.

System: S/4HANA 1809

Custom Table

A custom table is created with fields related to a user. There is no foreign key validation for person ID or other fields. Below table would be updated at the successful completion of workflow process:

Entry Program

A program is created to enter field values through a selection-screen. This program then raises the workflow event and passes the field values as event parameters. Event is already defined in workflow class and parameters are associated with the same event. We will see more details regarding this class in further sections:

TABLES: zcustusermast.

DATA:ls_key        TYPE pernr,

     lv_objtype    TYPE sibftypeid,
     lv_event      TYPE sibfevent,
     lv_objkey     TYPE sibfinstid,
     ls_event_data TYPE zcustusermast.

SELECTION-SCREEN: BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_person TYPE zcustusermast-person_no,
            p_first  TYPE zcustusermast-first_name,
            p_last   TYPE zcustusermast-last_name,
            p_comp   TYPE zcustusermast-company_id,
            p_cmploc TYPE zcustusermast-company_loc,
            p_bldz   TYPE zcustusermast-building_zone.
SELECTION-SCREEN: END OF BLOCK b1.

lv_objtype = 'ZCL_CUST_USER_MASTER_DEMO'.
lv_event = 'CREATED'.

*SET up the lpor instance id
lv_objkey = p_person.


*Instantiate an empty event container

DATA(lr_event_parameters) = cl_swf_evt_event=>get_event_container(
                              im_objcateg = cl_swf_evt_event=>mc_objcateg_cl
                              im_objtype  = lv_objtype
                              im_event    = lv_event ).

ls_event_data-person_no = p_person.
ls_event_data-first_name = p_first.
ls_event_data-last_name = p_last.
ls_event_data-company_id = p_comp.
ls_event_data-company_loc = p_cmploc.
ls_event_data-building_zone = p_bldz.

TRY.
    lr_event_parameters->set(
      EXPORTING
        name       =  'IS_DATA'                " Name of Parameter Whose Value Is to Be Set
        value      =  ls_event_data               " Value
    ).
  CATCH cx_swf_cnt_cont_access_denied. " Changed Access Not Allowed
  CATCH cx_swf_cnt_elem_access_denied. " Value/Unit Must Not Be Changed
  CATCH cx_swf_cnt_elem_not_found.     " Element Not in the Container
  CATCH cx_swf_cnt_elem_type_conflict. " Type Conflict Between Value and Current Parameter
  CATCH cx_swf_cnt_unit_type_conflict. " Type Conflict Between Unit and Current Parameter
  CATCH cx_swf_cnt_elem_def_invalid.   " Element Definition Is Invalid (Internal Error)
  CATCH cx_swf_cnt_container.          " Exception in the Container Service
ENDTRY.


*RAISE the event
TRY.
    CALL METHOD cl_swf_evt_event=>raise
      EXPORTING
        im_objcateg        = cl_swf_evt_event=>mc_objcateg_cl
        im_objtype         = lv_objtype
        im_event           = lv_event
        im_objkey          = lv_objkey
        im_event_container = lr_event_parameters.
  CATCH cx_swf_evt_invalid_objtype .
  CATCH cx_swf_evt_invalid_event .
ENDTRY.
COMMIT WORK.

Workflow Scenario

This is where our real workflow development starts. Create a new workflow scenario in transaction SWDD_SCENARIO. Enter Abbreviation, description details as they are free-text.

Since we are creating class- based workflow scenario, we will have to create a SE24 global class with ‘IF_WORKFLOW’ as implemented interface and implement required interface methods. We created the below class:

Also, created is the event that is being raised from entry program with associated parameters:

Process Data

Create a workflow container element with reference to workflow class. This element will be our leading object for the scenario. It is mandatory to define one leading object and this element will be accessible throughout the workflow.

Control:

By default, system proposes definition base class and runtime base class as callback classes. For our scenario, we have created class ‘ZCL_CUSTUSER_RUNTIME_DATA’ as subclass of base class ‘CL_SWF_FLEX_IFS_RUN_APPL_BASE’. We will need to implement/redefine some methods in this class, which we will cover in subsequent sections.

Activities:

We have 2 ‘User Decision’ activities, means these two activities will be available for us while configuring the workflow. We will be able to define approvers for these activities. There is possibility to define a ‘Activity’ step as well, which won’t require any processor and will be available during configuration. If activity is checked as ‘Activity for Results Processing’, it means this activity will react to an outcome and won’t be available as a step during configuration.

These activities, depending on type, will be shown as ‘Step Types’ while configuring Workflow in ‘Manage Workflow’ application.

Activity 1: Validate Data

Approver will be provided with the table record information as work item text. Defined decision texts will be provided and based on POSITIVE / NEGATIVE outcome, further steps can be triggered.

Title                – This text will be shown as subject of work item.

Decision Texts – These texts will be shown as decision options in work item.

Define the character of outcome under tab ‘Outcomes’:

‘NEGATIVE’ outcome will be shown in ‘Manage Workflow’ application while configuring the exception handling for this step.

TS00008267 is proposed as standard decision task. This task should be copied to a custom task and work item description can be defined as required.

Activity 2: Create Record

This approval step is for a final approval to create the records in table. As defined in activity 1, define the work item subject and other details. Copy the Standard decision task and change as required:

‘NEGATIVE’ outcome will be shown in ‘Manage Workflow’ application while configuring the exception handling for this step.

Conditions:

Under ‘Conditions’ tab, we define the workflow start condition or step start conditions. We are providing the condition to enter field value for ‘Company ID’ as workflow start condition or step start condition.

These conditions will be shown as ‘PRECONDITIONS’ in ‘Manage Workflow’ application.

Save, Activate and fix any errors if encountered. Workflow scenario development is almost complete. We will see the run time callback class in part 2. We will also look at Workflow configuration and test our workflow.