Explaining Flexible Workflow

Flexible workflow is a new extension to SAP Business Workflow coded especially for S/4HANA needs. You can think of it as a new hybrid engine and new user-interface to workflow usage and design.

The goals for Flexible Workflow, dictated by S/4HANA‘s simplification approach, were:

1. A business process expert can create and maintain simple workflows, such as sequential approvals, without the need to hand the task over to the IT department. Simple enough to do without training, and with guidance to avoid mistakes.

2. The business process expert can do this directly from their own domain, without trespassing on other domains. The tile to maintain such approval workflows is delivered as part of the applications role catalogue and accessible from the user ‘s SAP Fiori Launchpad.

3. The flexible workflow needs vary from application to application. But the symmetry of how this is presented needs to be preserved. So that there is common ground between an engineer using flexible workflow in Product Lifecycle Management (PLM) to create a one-off ad-hoc collaboration workflow (to be used with a change record), and an administrative approval workflow in procurement.

The approach is to:

• Embrace the SAP Fiori UI.

• Use a wizard-based instead of a graphical designer (UX studies showed that even the standards-based BPMN modelers are too complex for typical business domain experts).

• Focus on the 80% straight-through path, rather than the exception handling (which is taken care of by the flexible workflow engine).

The example in the figure illustrates the principles of Flexible Workflow. The Business User creates a new approval flow using the wizard without programming or a complex graphical view on the flow details. The workflow is a two-step approval (4-eyes), which is only used for purchase requisitions for employees ordering Notebook, where the value exceeds 2000€.

Clearly only simple processes can be modeled in this way, but experience shows that in a lot of use-cases other parts of the process are static. And could typically be handled with a combination of SAP built-in logic (code) and customizing.

The outer ring is illustrating what IT Department & Developer are responsible for and business has no influence on.

The inner part is flexible (soft); ready for: "Approval flows"; "Business is responsible for".

Think of a typical business process as a boiled candy with a soft center.

There is no need to keep all parts of the process flexible. Most of a process is static and does not change (check existing business workflows), but the core needs to be flexible to change. So rather than creating large complex flows to control the complete process end-to-end, it is much more efficient to have the static parts of the process automated by application logic (code) and customizing, and keep the inner part - the approval procedure - flexible.

This is the ethos of flexible workflows. A workflow scenario is developed as a combination of code and customizing together with the flexible artifacts: activities; roles; deadline-handling; conditions, that the business expert can string together flexibly and simply.

The outer ring is what the IT Department & Developer are responsible for and business has no influence on.

The inner part is flexible and Business is responsible for.

So perhaps some cases are automatically approved and other need a three-step approval. But once the decision is reached, the document is always released (outer core).

SAP Business Workflow needs to be enabled on the development system. The easiest way to do this is by executing the automatic customizing on the system.

More detail is provided in Unit 1, Introduction, Lesson 1, Explaining Workflow at SAP and in SAP S/4HANA, of this training.

• Special authorizations are needed to execute the automatic customizing. Normally, this action is done by the system administrators.

• Red crosses does not necessarily mean that the system is incorrectly configured.

• You can check the customizing of the workflow runtime by executing the verification workflow.

The following are the required authorizations:

Scenario Definition

To execute the Scenario Editor, you need the authorization to call the transaction SWDD_SCENARIO. In the test environment, the transaction code SWUS is checked. To deliver the scenario, you need the authorizations to create transport requests.

Scenario Activation

Authorization to do changes in maintenance view V_SWF_FLEX_SCACT.

The Manage Workflows editor retrieves and changes data of the back-end system by OData service SWF_FLEX_DEF_SRV, which checks the authorizations of the user with authorization object S_WFFLXDEF.

For the implementation and configuration of the Manage Workflows app, follow the description you can find in the SAP Help Portal: https://help.sap.com/viewer/b4367b1cec3243c4989f0ff3d727c4ab/7.5.9/en-US/1f469487cf9a49d7971c94a90c4c025f.html area.

• The development group responsible for the scenario is responsible for delivering appropriate roles to enable the usage of the scenario in the Manage Workflows editor.

• Especially in cloud environments, it is mandatory to deliver these roles, because the roles cannot be defined by the customers.

Running Workflows

Workflow instances can be executed by all responsible users. The responsibility is determined by the evaluation of agent rules, which are defined at the scenario.

Open the Scenario Editor, transaction SWDD_SCENARIO. The last selected scenario will be opened automatically. If there is none, an empty definition is shown. In either case, you can create a new one with the Create New Workflow toolbar function (CTRL+SHIFT+F5).

The Scenario Editor is similar to the SAP Business Workflow editor. It is divided into different areas, which will be described here in the following.

The following are explanations about the Scenario Editor:

The technical identifier, the version, and the current status of a scenario is shown. The identifier is generated by the system at first save of your scenario. For scenarios, which are not local, an object catalog entry is created with the program ID R3TR and object type PDWS and the system will ask for a transport request to which the scenario should be assigned. For test purposes, scenarios stored as local objects are also supported, but to deliver a scenario it needs to be assigned to a development package, which is transported.

• All language-dependent texts defined at a scenario can be translated to other languages, which are derived from the language vector of the development package. The mechanism is identical to the well-known behavior of other development objects like classes, reports, and so on.

• A scenario can be transported manually by creating a transport request and appending object R3TR PDWS <WFD_ID>, where WFD_ID is the ID of the scenario without the prefix WS. Example: If the ID of a scenario is WS12345678, then R3TR PDWS 12345678 should be included in a transport request.

The navigation area shows a list of all already defined steps and allows you to open the detail screen of the steps.

The container elements of a scenario are shown here, they can be opened and edited, and new container elements can be created. This view can be changed so that your own scenarios are shown by clicking on the arrow in the control at the top.

The scenario is shown in a graphical representation. The right part allows fast navigation in the graphic and zooming in or out. By double-clicking on a graphic element, the details of this step are opened.

The order of steps in flexible workflow is defined in the Manage Workflow app. Hence, the graphical model can be ignored.

In this area, the Scenario Editor displays information, warnings, or errors raised by checks of the Scenario Editor. For some of the checks, a direct navigation to the element for which a check failed is supported.

A scenario should be created in a way, which allows customers to flexibly assign predefined steps to an existing workflow definition to create, approve, or reject vacation requests of employees. In the Scenario Editor, we want to define these steps and all needed artifacts. The Business Object Repository (BOR) is integrated, as is well-known from the SAP Business Workflow editor (transaction SWDD). Therefore, we can simply use already defined BOR objects. The BOR is not part of the scope of this document.

To Create a Scenario:

1. Open the Scenario Editor with transaction code SWDD_SCENARIO.

   

2. A flexible block is already included as a step in the scenario definition. Double-click on the icon (0000000002). The first Process data tab contains information that belongs to the scenario. Most of it is not version-dependent. They represent the interface of the scenario and should never be changed later on because that can invalidate running instances or affect the start of new ones.

   

3. Specify an abbreviation and a description for the scenario.

   Note

   • Both values can be changed in the scenario basic data (CTRL+F8).

   • The name of the scenario is shown to the end user in the Manage Workflows editor, in which the customer can assign the provided steps to a workflow definition. Therefore a descriptive name should be used that customers understand the sense for which the scenario has been defined.

4. Now you can save the scenario if you want to. Next, the system will ask for the development package to which the scenario definition should be assigned.

   

   The figure shows the dialog box in which the development package for the development is assigned.

First, we assign the business object to the scenario that should be used as leading object. To do this, assign business object FORMABSENC to the container by creating a new container element.

To use the object in the Start event and its conditions later, it needs to be marked as Import element, which can be specified on the Properties tab.

The leading object can now be selected on the Process Data tab. This marks the container element from scenario context as leading object. A scenario can only have one leading object.

• Business objects defined either in the BOR repository or as ABAP OO objects implementing standard interface IF_WORKFLOW can be used here.

• In this document, we will not explain how to define and implement a business object using the BOR repository or as ABAP OO class with IF_WORKFLOW, because this is not related to the Scenario Editor.

The leading object defines the interface of the scenario and should never be changed after activation and transport of a scenario.

To automate the creation of instances for the scenario, start events of a scenario can be defined on  the Process data tab or Start Events of the Basic Data (CTRL+F8). For a BOR object, choose category BO and select the BOR object and the event via the value help.

• Start events can be defined for business objects (BO) or ABAP classes (CL).

• Start events are part of the scenario interface and should never be changed or deleted later.

Activate the start condition and define the binding, which is normally automatically suggested by the system or can be generated.

If the start depends on special attributes of a business object, a start condition can be defined.

This is how the start event will look at the end.

Runtime events can be used to change the behavior of a running process instance from outside.

A workflow event is a registration for a business object event. Commonly, it is an event of the leading object. Workflow events are active with the start of the workflow instance and will be deleted when the workflow has reached a final state. The instance linkage can be checked in SWE3.

When an event was raised on an object instance, all currently running instances that were started with the same object instance are affected. Commonly, there is a 1:1 relationship between object instance and workflow instance, but it can be 1:n.

How to use: Select a container element of type object (leading object) and define the action (receiver type). More than one event can trigger same action. The following actions can be maintained in the scenario definition:

Cancel Workflow

For example, the workflow listens for the WITHDRAWN_FROM_APPROVAL event of the corresponding leading object instance. If a request was withdrawn, the workflow instance will be cancelled automatically because it makes no sense to process further.

Restart Workflow

For example, the leading object was changed outside of the process. The change invalidates all granted approvals. The corresponding process must be restarted. The runtime will cancel all active task instances and redo the evaluation of the start conditions and will include the found workflow in the running workflow instance. As result, the business user will see all the tasks that were executed in the history.

Now, we can start defining the artifacts of the flexible block.

You can set a meaningful name of the flexible block on the Control tab. This name is relevant for developers, not for customers, who will not check the scenario definition in the back end. Also, own application classes can be assigned for the definition and runtime environment.

• By default, the system suggests using class CL_SWF_FLEX_IFS_DEF_APPL_BASE for the Definition Data and CL_SWF_FLEX_IFS_RUN_APPL_BASE for the Runtime Data. These classes should be used if no special application logic is needed.

• CL_SWF_FLEX_SCENARIO_BASE and CL_SWF_FLEX_RUN_APPL_BASE have been deprecated, but still supported.

• Definition data implementations have to derive from CL_SWF_FLEX_IFS_DEF_APPL_BASE and methods interface IF_SWF_FLEX_IFS_DEF_APPL_BASE can be redefined.

• The supported methods are:

• Supported Messages for Redefining Methods

  Method	Remark	Can be Redefined
  GET_REUSABLE_STEPS	Returns the steps, which can be used	Yes
  GET_REUSABLE_AGENT_RULE_DETAIL	Returns details to an agent rule	Yes
  GET_REUSABLE_CONDITIONS	Returns the conditions, which can be used	Yes
  GET_REUSABLE_CONDITION_DETAIL	Returns details to a condition	Yes
  GET_REUSABLE_AGENT_RULES	Returns the agent rules, which can be used	Yes
  GET_ID	Returns workflow template ID	No	WS77400599
  GET_VERSION	Returns workflow template version	No	0000
  GET_ISOLA	Returns ISO language	No	EN
  GET_DESCRIPTION	Returns description of scenario	Yes
  GET_SUBJECT	Returns subject of scenario	Yes
  GET_HEADER_DATA	Returns scenario header data	No
  GET_STREAM	Returns XML representation of the scenario	No
  GET_NAMESPACE	Returns scenario namespace	Yes
  GET_LANGUAGE_ORDER	Returns language vector	No
  GET_PROPERTIES	Returns a list of properties that can be assigned to artifacts within a workflow, that is, a phase property to an activity must be redefined in scenario-specific subclass; default implementation in the base class will return an empty list	Yes	see implementation in CL_SWF_FLEX_DEMO_SCN_FORMABS
  GET_TYPE_DETAILS	Returns information about OData services to be used by the modeling application as value help for entering values for condition parameters	Yes	see implementation in CL_SWX_EPM_PO_FLEX_SCN
  GET_PEOPLE_PICKER_DETAILS	Returns information about OData service to be used by the modeling application as value help for users that are explicitly assigned to a step	Yes	see implementation in CL_SWX_EPM_PO_FLEX_SCN
  GET_STAGES	Returns stages, which can be used in the scenario	Yes
  GET_TEMPLATEPICKER	Link to OData service returning the value help to the scenario templates	No

• In general, implementations must ensure that text properties like SUBJECT and DESCRIPTION are returned in the actual logon language, SY-LANGU, as these properties are supposed to be displayed in the Manage Workflow app, while ID is a language-independent stable identifier for the individual artifact. When redefining a base class method, it is recommended to always call the base class implementation via SUPER and modify its results by adding entries or modifying/deleting them where applicable.

  For details of the interface methods and parameters, check the interface documentation of the ABAP workbench.

• Own runtime data implementations have to derive from CL_SWF_FLEX_RUN_APPL_BASE and should implement interface IF_SWF_FLEX_RUN_APPL. The supported methods are:

  Supported Methods for Own Runtime Data Implementations

  Method	Remark
  GET_APPL_CONDITION_EXECUTION	Condition evaluation is done by the application. An object reference needs to be returned implementing the EVALUATE method of interface IF_SWF_FLEX_RUN_CONDITION
  GET_APPL_AGENT_RULE_EXECUTION	Application owned agent rule evaluation. An object needs to be returned implementing the EVALUATE method of interface IF_SWF_FLEX_RUN_AGENT_RULE
  MITIGATE_START_COND_EVALUATION	Application implements mitigation if no workflow is found to be started
  MITIGATE_AGENT_RULE_EVALUATION	Application returns the responsible agents for a step if no agents for an activity are found
  RESULT_CALLBACK	Application can react on the workflow completion

When starting the scenario, the runtime of the flexible workflow will evaluate the start conditions of the defined workflow templates. If no conditions apply for any workflow and also no active sap-delivered workflow is found, no workflow is started. If the application shall react to this use case, the checkbox Confirmation Obligatory has to be checked by the developer. Additionally, in the result callback MITIGATE_AGENT_RULE_EVALUATION of the provided scenario runtime class, where the application programmatically reacts to the use case, returning parameter RV_RESOLVED has to be set to X (true), to indicate to the engine that the mitigation was handled successfully. Otherwise, the workflow instance will go into error.

Each flexible artifact consists of a:

• Unique name 

• Short text

• Description

An activity defines an action that can be executed by a user or in the background. Activities can be used later to define the workflow in the Manage Workflows editor. The sequence of the activities at the scenario is not important. Every activity has general data like a name, a short text, and description. In addition, the activity type, activity (ID), and corresponding task will be shown.

The following types of an activity are currently supported:

• Activity

• User decision

• Extension

Further explanations:

Activity

An activity is a common workflow activity based on a task.

User decision

The (generic) user decision is a special case of an activity. It is used to define a set of alternatives. At runtime, the user can choose one of them to make a decision that influences the process flow.

Extension

Over an Extension Step it is possible to call a workflow in SAP Workflow Management on BTP.

The unique name is a technical identifier that will not be translated. It is used to get access to the artifact in exits and callback calls. The short text and the description are translatable and are shown to customers in the Manage Workflows editor.

The creation of a new artifact follows a two-step approach. First, the general data will be entered in a pop-up. In the second step, the specific data for activity, condition, or agent rule can be entered.

To create a new activity, press the Create button. Enter the general data in the pop-up. Please note that the unique name cannot be changed after the pop-up is confirmed. On the pop-up, you can decide which activity type will be created. For a user decision, a generic task will be used. If you want to create an activity, you can enter or select a task here. Otherwise, an activity with a placeholder will be generated. After confirming the pop-up, you jump into the next screen.

For a generic user decision, the possible decisions and the outcome of the decisions can be defined. The decision texts are end-user-relevant and translatable.

The figure shows where IDs for possible outcomes of a step are entered.

Generic user decisions commonly provide a static set of decision options. But applications need to hide or change decision options at runtime (per work item) depending on runtime data (for example, hide the Approve button in case of amount higher than x). For this, we provide a program exit for user decisions. The developer of this application has to create an ABAP-class, implementing the interface IF_SWF_WORKITEM_EXIT. The class name has to be set into class field on the Program exit tab.

At runtime, the IF_SWF_IFS_WORKITEM_EXIT~EVENT_RAISED method will be called for different events while work item execution. To change decision options, event BEF_DECI (constant SWFCO_EVENT_BEFORE_DECISION) is used. Via IM_WORKITEM_CONTEXT, the developer gets access to a lot of runtime data (for example, workflow container). Method GET_DECISION_ALTS returns a table of static decision alternatives. To set the modified list, you can use method SET_DECISION_ALTS.

Example: class CL_SWH_T_DECISION_EXIT of workflow definition WS77400143.

After creation, you return to the activities overview. You can jump into the activity via the Activity button or clicking on the unique name. You can't change the unique name because it is an incompatible change of the scenario, but you can copy an activity. If you delete one or more lines, the activities will be deleted as well. Please note that this will be an incompatible change, so store it as a new version.

To unassign an activity, use the context menu (function Remove and Delete Activity) on the Activities column.

The short text and description may have 255 characters. Because the ALV grid can handle only 128 characters, longer texts will be maintained in a pop-up.

Some activities are used for managing an exception within the process flow. An exception can be every outcome of a step; commonly, it will be a NEGATIVE outcome. These special activities cannot be included in the normal process flow, but in an exceptional case only. You can set the property during creation of an activity. The flag is displayed next to the Task column.

On the Properties tab of an activity or user decision, you'll find the setting under sap.bc.bmt.wfm.flex.outcome.activity.

The flexible conditions for the scenario can be defined here. Customers can decide, in the Manage Workflows editor, which of these conditions will be used during runtime. If the condition should be evaluated at workflow start the Start Condition flag has to be set. Parameters that should be used in the condition can be maintained via the Parameter button. Conditions have a language-dependent short text and description. The short text of the Condition and the Parameters will be shown in the selection UIs of the SAP Fiori apps and components. The description is now only documentation, but might be exposed to one of the SAP Fiori front ends at a later point in time.

In our example, we want to support different conditions. Depending on the number of absence days, other responsible employees have to confirm. For example, the manager for a short absence or the HR department (and maybe additionally by the manager) for a long vacation. The following screenshots show how to define the manager approval with a special parameter. We start by defining the condition by clicking on the Create button.

Enter a unique name, short text, and description. Then, set the Start Condition flag and define a new parameter, which can be set by workflow start, for example, by the application triggering the workflow, and which will be used in the condition.

First we define the parameter specifying the absence hours on which the start condition should be evaluated.

• If needed, You can create several parameters (currently a maximum of two is supported).

• Create only parameters that are really needed.

• Start conditions can use importing and changing parameters of the workflow container only.

• If the input is required, set the Mandatory flag.

• Only parameters defined with data elements referring one of the domains XSDBOOLEAN, BOOLE, XFLAG, or XFELD will be exposed as Boolean.

• Length restrictions or decimal places are not supported by the XML conversion.

• Validation will only allow values from min_int to max_int  (-2147483648 to 2147483647).

• Currently, the following conversions are supported:

  Supported Conversions

  ABAP Type	XSD Data Type
  N	xs:integer
  I	xs:integer
  s	xs:integer
  b	xs:integer
  P	xs:integer
  8	xs:integer
  a	xs:integer
  e	xs:integer
  F	xs:integer
  D	xs:date
  T	xs:time
  C	xs:string
  C (domains XSDBOOLEAN, SWFXST_BOOLEAN, XFLAG, XFELD, BOOLE)	xs:boolean
  all others	xs:string

• Parameter values mapped to an xs:string will be converted to uppercase if lowercase is not set to true in the domain and no value help is attached to the parameter.

Now we have defined the parameter and can use it in the condition. To do so, press the Condition button in the grid. The container on the right side will show our business object and the new parameter, AbsenceHours. By double-clicking on the corresponding container elements we can define the expressions. Additionally, we can specify the operator for the condition.

• Combining several conditions is supported by logical operators and parentheses.

• Filtering on parameters and constants can be combined in conditions.

In the Scenario Editor, you have two ways to define a value help for condition parameter:

• Parameter container pop-up

• Value help tab

On the Parameter container pop-up, you can define a value help by using the Help button. If no value help yet exists, it is grey and you can then define it from here. After you have entered a value help, or if the value help for the typename already exists, the button has a green icon. Then you can display (but no longer change) value help settings via the Help button.

The Value help tab is used to maintain value help definition. For each typename that is used by a condition parameter, you'll automatically get an entry here. Define the service path, entity, and property to activate a value help for the typename.

Additionally start conditions can be defined at the start events of the scenario.

Customers can add their own condition fields in ABAP for key users. Enhancement spot SWF_PROCESS_WORKFLOW_CONDITION has been provided for this purpose. It contains BAdI implementations SWF_WORKFLOW_CONDITION_DEF and SWF_WORKFLOW_CONDITION_EVAL.

BAdI implementation SWF_WORKFLOW_CONDITION_DEF is based on interface IF_SWF_FLEX_IFS_CONDITION_DEF with method GET_CONDITIONS by which conditions can be added. The method, constants, and types are documented by ABAP doc.

BAdI implementation SWF_WORKFLOW_CONDITION_EVAL is basing on interface IF_SWF_FLEX_IFS_CONDITION_EVAL with method EVALUATE_CONDITION, which will be called to evaluate the values for customer owned conditions. The method, constants, and types are documented by ABAP doc.

• IF_SWF_FLEX_IFS_CONDITION_EVAL~EVALUATE_CONDITION will be called only for conditions that have been added by IF_SWF_FLEX_IFS_CONDITION_DEF~GET_CONDITIONS.

• For conditions added by IF_SWF_FLEX_IFS_CONDITION_DEF~GET_CONDITIONS, an evaluation by IF_SWF_FLEX_IFS_CONDITION_EVAL~EVALUATE_CONDITION is mandatory.

• The framework ensures that logical operators (AND/OR) are correctly taken into account.

The customer must be enabled by the application to create the enhancement implementation (in the Custom Fields and Logic app of the extensibility framework). For this, the developer of the application has to add the BAdI to their corresponding business context.

The value help for people picker can be defined on the Value help tab. There is an item predefined for people picker. The setting is valid for the whole scenario, so it can be defined only once here. You activate the value help by entering service path, entity, and property.

The standard agent rules for the workflow initiator, the manager of the workflow initiator, and the workflow system administrator are predefined automatically. Agent rules that are not needed for the scenario can be deleted. You can find them in the Agent Rules tab.

For all rules, the binding needs to be defined. This can be done manually or, more comfortably, it can be automatically generated by pressing the Generate button.

When you close the details of the flexible block, the model of the scenario is shown, as in this screenshot.