Workflow in SAP: classic and flexible

What workflow is

A workflow delivers each piece of work, in the right order, to the person who has to do it, with the information they need. The typical example is an approval: a purchase order is created, the system sends it to the person responsible, who approves or rejects it, and the process continues one way or the other.

The work is split into tasks. Each time the workflow reaches a task it creates a work item and sends it to the inbox of the agents who must do it. Workflows usually start with an event, such as "order created" or "invoice blocked".

Flexible workflow uses the same engine as classic workflow underneath: the work items are the same and they look the same in SWI1. What changes is who defines the process and how.

The basic concepts

Preparing the system

Before using workflows in a client you have to do their basic setup. Transaction SWU3 (automatic workflow customizing) checks it and does almost all of it by itself: it shows each point in green or red.

1. Run SWU3 and click "Perform automatic workflow customizing". An administrator with the right authorizations does this.
2. Check the RFC destination WORKFLOW_LOCAL_<client> in SM59: it is the connection the system uses to run the workflow steps.
3. Check that the system user WF-BATCH exists; background steps run with it.
4. Test that everything works with the sample workflow that SWU3 itself offers.

In S/4HANA, flexible workflow also needs the scenarios of each area (purchasing, supplier invoices…) to be activated, and the My Inbox app (F0862) to be set up; that is where users receive their tasks.

A classic workflow with the Workflow Builder

The Workflow Builder (SWDD) draws the process as a diagram of steps. These are the most used:

1. In SWO1 choose the business object (or create a Z subtype if you need your own method or event). In new code you can use an ABAP class with the IF_WORKFLOW interface.
2. In PFTC create the standard tasks: the method they run, their possible agents and their terminating events.
3. In SWDD create the template: the container, the steps and the agent determination of each one.
4. In the basic data of the template set the triggering event and its binding, and activate the linkage (it is also shown in SWE2).
5. Activate the template and test it with SWUS (start a workflow) or by raising the event with SWUE.

When you change a workflow that is already in use, create a new version: running workflows continue with the version they started with.

Starting a workflow from ABAP

The recommended way is to raise an event and let the event linkage start the workflow: the program does not depend on the workflow, and the workflow can be switched on or off without touching the code. For a BOR object, use the function SAP_WAPI_CREATE_EVENT:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
DATA lt_contenedor TYPE STANDARD TABLE OF swr_cont WITH EMPTY KEY.
DATA lv_retorno    TYPE sy-subrc.

" Data the workflow needs (optional)
lt_contenedor = VALUE #( ( element = 'RELEASECODE' value = lv_codigo_liberacion ) ).

CALL FUNCTION 'SAP_WAPI_CREATE_EVENT'
  EXPORTING
    object_type     = 'BUS2012'          " purchase order
    object_key      = lv_ebeln
    event           = 'RELEASED'
  IMPORTING
    return_code     = lv_retorno
  TABLES
    input_container = lt_contenedor.

IF lv_retorno <> 0.
  MESSAGE 'The event could not be raised' TYPE 'E'.
ENDIF.

If the object is an ABAP class with the IF_WORKFLOW interface, the event is declared in the class and raised with CL_SWF_EVT_EVENT=>RAISE, stating that the object type is a class:

1
2
3
4
5
6
7
8
9
10
TRY.
    cl_swf_evt_event=>raise(
      im_objcateg = cl_swf_evt_event=>mc_objcateg_cl   " ABAP class (BOR: mc_objcateg_bor)
      im_objtype  = 'ZCL_WF_SOLICITUD'
      im_event    = 'APROBADA'
      im_objkey   = CONV #( lv_id_solicitud ) ).
    COMMIT WORK.   " the event is raised on commit
  CATCH cx_swf_evt_invalid_objtype cx_swf_evt_invalid_event INTO DATA(lx_error).
    MESSAGE lx_error TYPE 'E'.
ENDTRY.

Use the SAP_WAPI_* functions, which are the interface meant for customers, not the internal workflow functions and tables. They replace old functions such as SWE_EVENT_CREATE.

Flexible workflow in S/4HANA

In S/4HANA, SAP changed the approach: the workflow is no longer defined by the technical team but by the process expert, in a Fiori app. Instead of one big workflow with many branches, you create several small workflows, each with its own start condition.

1. Activate the scenario of the process you want to automate (the documentation of each area says which one).
2. Open the area's Manage Workflows app and create a new workflow.
3. Define the start condition: for example, orders over 10,000 euros.
4. Add the steps and who approves each one.
5. Order the workflows by priority: the first one whose condition is met is used.
6. Activate it and test it with a real document.

In S/4HANA Cloud you can configure workflows with SAP's scenarios, but only on-premise can you develop new scenarios.

Monitoring and administration

Do not use transaction SWWL (mass deletion of work items) in production: it really deletes them, with no way back.

Common problems

Good practices

• Raise events instead of starting the workflow directly: the program and the workflow stay decoupled.
• Think of all the events that must end the process: approved, rejected, changed, deleted…
• Include the event linkages (SWE2) in a transport request.
• Define deadlines with the factory calendar, so that holidays do not count.
• In S/4HANA, for approvals of standard documents, first check whether there is a flexible workflow scenario before building a classic one.