SAP BUSINESS WORK FLOW

SAP Business Workflow - Introduction

With SAP Business Workflow® in Release 3.0, SAP AG provides an efficient cross-application tool enabling integrated electronic management of business processes.

SAP Business Workflow and Application Scenarios
Aim and Purpose of this Documentation
Basic Concepts
Customizing


SAP Business Workflow and Application Scenarios

SAP Business Workflow is a solution which has been integrated fully in the R/3 System and which enables customer-specific business process flows to be coordinated and controlled on a cross-application and cross-workplace basis. SAP Business Workflow therefore enhances "ready-made" application software.


The SAP Business Workflow definition environment is available in order to represent business processes in a simple manner and to be able to respond to changing external conditions quickly during ongoing operation by flexibly adapting the business processes which have already been implemented.


A number of SAP applications support Workflow Management by SAP Business Workflow. In many situations you can therefore use workflow scenarios which have already been configured. These can either be implemented without any changes or they can be used for your business processes with minimal adjustments. These workflow scenarios reduce implementation time significantly and are optimally adjusted to the respective application functions.


The workflow scenarios are integrated in IDES (International Demonstration and Education System). It is possible to run the business processes of a model company in this fully configured system.


What is a workflow scenario?

The term "workflow scenario" describes the whole range of options which are available for supporting workflow functionality in an application. The workflow scenarios can be divided into three categories:

• Creation of events

Events are created to report status changes undergone by an application object and to allow a reaction to be made to these. You can respond to these events in a flexible and customer-specific way without the standard part of the application needing to be modified. You will generally use such events as triggering events for customer-specific customer tasks or workflow tasks.


The triggering of these events is often not activated in the standard version, but depends on the customizing settings.
You can find further information in the application scenario documentation.

• Provision of standard tasks

Standard tasks contain a task description and a connection to the application logic via business object methods. Before a standard task can be used productively, you must assign it to its possible agents.


The standard tasks provided by SAP are generally used as steps in a workflow template. They are available as "modules" which you can use for your own developments.


If a workflow scenario only involves one standard task, it can usually be regarded as a minimal solution for showing the connection between application functionality and SAP Business Workflow. For differentiated workflow management, this standard task should be replaced by a customer-specific workflow task.


You can find further information in the application scenario documentation.

• Preparation of workflow templates

Workflow templates contain complete process descriptions comprising several steps.
In the cases where workflow templates describe business processes which occur in exactly the same way in your company, or in the cases where changes to the workflow template are not advisable for technical reasons, the workflow templates supplied by SAP can be used productively without any changes needing to be made. It may however be necessary to make some customizing settings.


In any other case, you can use the workflow templates as the basis for your own developments. The existing process structures of the business application components, which are often represented in a transaction, are generally not replaced. SAP Business Workflow is located as an integration level "above" the standard business functions and uses the existing transactions, function modules, and reports.


Aim and Purpose of this Documentation

This documentation describes the workflow scenarios which can be found in the standard version. The contents of the individual chapters are all structured in the same way:

• In the business background you find out which business processes are supported by workflow scenarios, which employees are involved, and what advantages and benefits can be derived from using the workflow system.

This information is sufficient if you are interested in an initial overview of the options available.

• A more detailed presentation of the processes is provided in the description of the technical background of the respective scenarios. Here you learn in detail what steps were carried out by SAP in order to represent the business process in the system.

You are familiarized with the object types which form the basis of the scenario and you find out which standard tasks are defined to describe the activities which need to be performed, which roles are resolved, and which events are used. The structure of the workflow template used and its interface and container are described in greater detail.


This information is particularly useful if you are planning to enhance and modify the scenario.
This section is not available or is very brief if no enhancements are planned or appropriate.

• To adapt the scenario to the specific features of your company, settings need to be made which are described in the section Preparation and Customizing.

The settings described need to be made specifically for the scenario and are generally additional to SAP Business Workflow customizing.

• The use of the scenario and the connection to application functionality are described in the last section of the respective chapter.

This documentation is not meant to replace the SAP Business Workflow manual.
For information on using and calling the individual components of SAP Business Workflow and to take advantage of the full functionality in your enhancements and own developments, refer to the SAP Business Workflow manual. There is a link to the document in the menu line for this page.


Basic Concepts

A few conceptual details which are required to understand the documentation are described below. This description is intended to familiarize you with the basic concepts involved and is therefore not an introduction to working with the system.

Area Menu SAP Business Workflow (Development)

All definition tools can be accessed from the area menu SAP Business Workflow (Development). You can reach this area menu from the R/3 initial screen via Tools ® Business Engineering ® Business Workflow ® Development.

Object Orientation in SAP Business Workflow
Integration of Organizational Management
Workflow Definition
Tasks
Roles
Executing Tasks
Workflow Execution: SAP Business Workflow Runtime System
Central Access Point for a User: Integrated Inbox
Binding and Container


Object Orientation in SAP Business Workflow

A workflow is generally used when business objects (business application objects), such as an invoice, material, or customer, are to be processed in the system over several steps and when this processing is to be followed actively until it has been completed. Options must therefore be available in the workflow system for

• naming objects,
• creating and processing objects (executing methods),
• evaluating attributes of objects (reading attributes) and
• responding to events (status changes of objects).

It is therefore appropriate that the interface between the workflow management system and the applications is based on object-oriented principles. Besides the business logic of the R/3 System, other applications on desktops or in other application systems (appropriately encapsulated) are therefore accessible to SAP Business Workflow.

Object Types and Objects

An object type refers to a generic object description which is created at definition time. This description includes the definition of the key fields required to uniquely identify an object of this type and the specification of the methods, attributes, and events of this object type..

An object is the specific instance of an object type which has been assigned values.

Modifying Object Types - Inheritance and Delegation

It is necessary to extend an object type rather than creating a new object type whenever you want to create additional components for an object type which are not provided in the standard version and at the same time need to ensure that productive scenarios with the original SAP object type remain operational.


Since you may not change the object types provided by SAP, create a new object type as the sub-type of the original object type which will then inherit its components and their implementation. Then modify this object type and make it the delegation type of the super type. All calls to the "old" delegating object type (super type) are redirected to the delegation type (sub-type) so that its definition is read and executed (delegation).

Business Object Repository

A directory of all object types defined in the SAP System is managed in the business object repository. These object types are each assigned to a business application component.
In addition to the business object types, the business object repository also contains structural object types, such as company code, plant, or sales organization, and technical object types, such as text, note, work item, or archived document. Customers can define their own object types.


Object types and their elements can be found quickly by accessing this business object repository with the appropriate search functions (either via the component hierarchy or with a generic search using parts of a name).

Methods

A method refers to an operation which can be performed on an object.
A method generally refers to ABAP/4 functionality which is already available (function module, transaction, dialog module, ...) and is called via an interface determined mainly by the method name and method parameters. The actual implementation of the method therefore remains abstract. It is not visible externally and does not need to be known to the calling program of the method.

Synchronous and Asynchronous Methods

Methods can be subdivided as follows depending on their response characteristics:

• synchronous methods

Synchronous object methods assume process control for the duration of their execution and report back to the calling program once they have been executed.

• asynchronous methods

Asynchronous methods do not report back to the calling program directly after their execution. The response is made via events which are used to report the processing results of the methods.

Synchronous and asynchronous methods can be distinguished according to the way in which they are used in single-step tasks: A single-step task which refers to an asynchronous method must be completed by an event.

Method Parameters

Parameters are used to exchange information between the calling program of a method and the method.
Parameters of a method are values which are either passed to the method at runtime (import parameters) or are returned from the method (export parameters). When the parameters are defined, the interface of the method call is also defined. A method need not necessarily have parameters; many methods can be used without parameters.

Method Result

The result of a method is different to the export parameters. Possible values for the result can be fixed or contained in a check table. They are therefore known in a workflow definition and can be taken into account during process modeling. The various follow-up steps can be modeled in a workflow definition according to the results. A method can only ever have one result, although there is no limit to the number of export parameters.

A method need not necessarily have a result.

Method Exceptions

In the same way, exceptions (cancellation by user, object to be processed does not exist, etc.) of a method can also be defined and taken into account in a workflow definition.

Attributes

An attribute describes a property or characteristic of an object.
Attributes can be used to formulate conditions in the workflow definition. The object attributes are read or determined from the database at runtime and are used to control the workflow. An object attribute can return

• the value of a field in the ABAP/4 Dictionary (database field attribute)
• an object reference to an object which is defined in the business object repository. Object attributes which return an object reference therefore allow the attributes of this referenced object to be accessed.
• a value which is not determined until database contents are calculated and/or evaluated at runtime (virtual attribute).

Events

An event publishes the occurrence of a status change of an object ("text deleted", "invoice posted", "material created", ...) system-wide.


Events should always be seen in connection with the object they are "reporting" on. The events belonging to an object are therefore specified in the object type definition.


Events are published without the application, the event creator, knowing whether a receiver is interested in this event and whether it will respond. Potential receivers of an event are listed in the event receiver linkage table, where receivers can make and remove their entries as required. This allows the events created to be responded to flexibly.

Events and SAP Business Workflow

Events are used in the SAP Business Workflow environment,

• to start tasks (multistep tasks and single-step tasks). The events are therefore defined as the triggering events of the respective tasks.
• to complete single-step tasks which refer to an asynchronous object method. The events are therefore defined as the terminating events of the respective single-step tasks.

Event Parameters

Events are linked to runtime-dependent data (event parameters) which is available to the event receiver and can be used for event-driven control and communication mechanisms.

Event Generation

Event generation is not part of the object type definition in the narrow sense. However, for customer-specific event generation to occur, the relevant events must be added to the object type definition.


If the events which are created in the standard version when particular conditions are met are not sufficient, you have the option of ensuring that additional events are generated without carrying out programming work. It is therefore possible to generate events where this is not supported by SAP in the standard version. There are basically four ways in which events can be generated:

• Generate events by calling a function module
• Generate events for status changes
• Generate events when change documents are written
• Generate events via Message Control

While event generation as the result of calling the provided function module requires programming knowledge and experience, the last three options can be used without changing the program code of an application. These procedures take advantage of the fact that data consistency and security is ensured by the application when a change document is written, status management activated, or a message sent.


The generation of events entered for the individual object types in the business object repository is ensured by SAP.

Event Generation Log

All events generated correctly are logged in the event log irrespective of whether receivers are available. The event log is only written if the logging has been switched on. To do this, select Utilities ® Event log ® On/off from the area menu SAP Business Workflow (Development).


The event log created can be displayed from the area menu SAP Business Workflow (Development) via Utilities ® Event log ®
Display.

See also:
Working with Objects


Integration of Organizational Management

The company-specific organizational plan describes the organizational assignment of an employee. This allows the responsibility of employees for performing individual business activities to be defined in the form of activity profiles.


The organizational plan is part of the PD component "Organization and Planning". It is client-dependent. An organizational plan which was created for personnel management purposes (or is still to be created) can be used in SAP Business Workflow without any changes provided the workflow functionality and the personnel management application use the same client.


In each client you will however generally (only) represent the sub-areas and organizational structures of your company in which you also coordinate business processes using SAP Business Workflow.


This assignment is used to find the "correct" agents and allows tasks to be assigned actively by the workflow management system. Transparency of the business processes and responsibilities is achieved. Changes can be made to the organizational structure of the company without changes needing to be made directly to the SAP Business Workflow definitions or programming performed in an application.

To create an individual activity profile for a user in a modular way and without redundancy, it is necessary to describe the organizational assignment of this user in the company-specific organizational plan.

Organizational Structure and Organizational Units

An organizational plan is described by the organizational units available in the company. These organizational units are generally linked together in a hierarchical reporting structure, but can also be created in isolation.


Organizational units are organizational sub-areas in a company (departments, project teams, groups) which have been created for business purposes.

Staff Assignments

Staff assignments are maintained for each organizational unit. The appropriate positions are assigned to the organizational unit. A position is derived from a describing job and is generally occupied by a user.

Jobs

Jobs are areas of activity within a company which are described by tasks or business application components and are often created across organizational units.

Positions

Positions can be regarded as the individual employee assignments within a company. A position is described by a job and always belongs to exactly one organizational unit.

Chief Position

One position can also be designated as the chief position of the organizational unit. This allows you to structure the positions within an organizational unit. This information is sufficient to address a work item to an employee's superior.

User/Person (Employee)

A position is held by an employee (person from HR master data management) or by a system user (user master), a position can also remain vacant.
For an agent to be determined by the workflow system, it must be possible to make an assignment between positions and system users. If a position is assigned to an employee, this employee must also be linked to his system user in the HR master data (infotype 105 Communication). Do not assign an employee and a person to a position.


Workflow Definition

The technical implementation of a business process is referred to as a workflow definition and is carried out using the graphical workflow editor. A workflow definition consists of a sequence of connected steps.
The sequence of the steps depends on the result of the preceding step. Subsequent steps are defined in the workflow definition for all possible results of a step. The possible results of a step are usually derived from the underlying business functionality and are known in the workflow definition.

Steps in a Workflow Definition

When a step is created in a workflow definition, it is first necessary to specify its type. The following need to be distinguished:

• Steps which reference business activities (activities and user decisions)
• Steps used for internal process control (condition, multiple condition, loop, ...)

The following step types need to be distinguished:

• Activity (task reference)

Reference to a task as a step within the workflow definition.
This task can be a single-step task with elementary business functionality (customer task/standard task) or a multistep task in which a workflow definition is referenced (workflow task/workflow template).


The workflow definition therefore supports "sub-workflows", comparable to a subroutine, and allows a structured procedure with hierarchy formation.

• User decision

A prompt is defined with a decision text and the current agent then asked at runtime to make an explicit decision. The decision which is made determines which follow-up step is selected.


Up to four values from the available runtime data can be included in the decision text as parameters.


• Single and multiple condition

Branching based on control information (object attributes, field values, counter, ...) from the runtime-dependent context of the workflow.

• Event creator

Creation of an event to publish the status change undergone by an object and allow appropriate reactions.

• Wait step

Waiting for an event as a step in the workflow definition.
Such an event can report that a particular document has been received, for example.

• Loop

Repeated processing of steps within the workflow definition until the termination condition defined in the respective loop statement has been reached.


The following loop types are available: UNTIL loops (with conditional check according to the loop) and WHILE loops (with preliminary conditional check and condition-dependent loop).
Graphic: Until loop
Graphic: While loop

Container operation

Operations on an individual element of the workflow container as a step within the workflow definition. Operations which can be carried out on the container element are:

• elementary arithmetic operations
• value assignments

Workflow control

Influencing the control of the workflow as a step within the workflow definition. Two commands are available for workflow control which are executed at the runtime of the workflow:

• Cancel work item
• Cancel workflow

Parallel Arrangement of Steps

Steps can be arranged as parallel processing branches. It is possible to define that only part of the parallel processing branches actually needs to be executed to continue the workflow process.


Besides this explicitly defined parallelism, dynamic parallel processing of individual tasks is also supported (table-driven parallel processing), where the number of parallel steps is determined from the number of values in the multiline table element at runtime.

See also:
Calling and Maintaining a Workflow Definition


Tasks

From an organizational perspective, tasks are the central element in the workflow system.
Tasks are used to describe a business process. These tasks may require a single step (single-step task) to be executed or several, possibly parallel, steps (multistep task).

Single-step Tasks: Customer Tasks and Standard Tasks

Customer tasks are client-dependent and have a period of validity. They are therefore integrated in organizational management with its planning and time limitation options.
Standard tasks are client-independent and are defined without a period of validity.

Single-step Tasks: Organizational Responsibility

Customer tasks and standard tasks are always assigned to their organizationally possible agents.
It may therefore be the case that several employees authorized equally on an organizational basis are offered the same task for execution. One of these employees takes on the task and processes it. This assignment principle supports automatic load distribution within work groups with the same activity profile.

Single-step Tasks: Reference to Object Method

To ensure that single-step tasks are operationally executable, the interface chosen between the workflow management system and the business application components is based on object-oriented principles where both the customer and standard tasks refer to a method of a object type defined in the business object repository.


The activity which is to be performed with a single-step task is therefore not only specified as a verbal description but also as a software implementation by the reference to an object method.
Single-step tasks describe the link to the application functionality and ensure that it can be executed.

Multistep Tasks: Workflow Tasks and Workflow Templates

From a business perspective, workflow tasks and workflow templates both comprise a complete process description.

Workflow Tasks

When a customer defines a workflow task, he implements his specific business process and therefore technically represents the operational structure.
A workflow template can be used as the basis for defining a workflow task.

Workflow Templates

A number of SAP applications support Workflow Management by SAP Business Workflow. The workflows defined in these applications are supplied as workflow templates by SAP in the standard version.

See also:
Defining Tasks

Executing Tasks

A task (multistep task or single-step task) can basically be

• triggered by an event
• started in dialog
• referenced as an activity in a workflow definition

Executing Single-step Tasks

It will not always be necessary to execute a comprehensive workflow definition consisting of several steps in order to process a business process. A single step in the form of a single-step task will often provide the required functionality.


In accordance with the modularization principles put into practice by SAP Business Workflow, the single-step tasks have been designed as separate "modules" which can be used as often as required. A single-step task must only be defined once by an employee with the appropriate information and then assigned to the person or group of persons who can and should process it as possible agents.


Single-step tasks can then be used multiply in workflow definitions or as single steps without modification or knowledge of their internal processes.

Tasks as Steps in Workflow Definitions

Since tasks are subdivided into two categories, an activity can refer to

• a single-step task (customer task/standard task)

This single-step task is represented by a work item at runtime which

- appears as a dialog work item in the integrated inboxes of the selected agents if the processing requires user interaction
- is processed directly by the system as a background work item if dialog is not required

• a multistep task (workflow task/workflow template)

The activity therefore refers indirectly to a workflow definition and forms a subworkflow, comparable to a subroutine, within the workflow definition.

See also:
Details: Executing Tasks

Roles

A role is used to describe a feature, characteristic, or authority of an employee determined according to business criteria.


Role cost center administrator
Role material administrator
Role customer service representative
Role person responsible for development class
Role user's superior

A role is used to specify an agent when the set of possible agents which is known at definition time is too large or unspecific. Roles are used to restrict the number of possible agents of a single-step task in a specific case. The role is resolved using parameters which are not available until runtime in the context of the processed application object or the context of the calling workflow.


Such a role resolution only allows the number of possible agents to be restricted. Each single-step task must therefore be assigned to its possible agents or classified as a general task.

If such an assignment does not exist, a single-step task cannot be processed despite the fact that role resolution has been performed. The agents found on the basis of the role resolution and which constitute a subset of the possible agents are referred to as selected agents (or recipients).




Workflow Execution: SAP Business Workflow Runtime System

The SAP Business Workflow runtime system consists of logical units referred to as "workflow manager", "work item manager", and "event manager".

Workflow Manager

Any number of workflows can be derived from a workflow definition as runtime instances.
The workflow manager is responsible for controlling and managing the process. By evaluating conditions with object attributes and taking into account the results of individual steps, it determines which steps are to be processed next.

Work Item Manager

Each workflow consists of a sequence of work items which represent the individual steps of a workflow definition at the runtime of the workflow. These work items are executed by human agents ("dialog work items") or by the system in the background ("background work items").


Dialog work items can only be executed by employees who are organizationally responsible for their processing ("possible agents").
Managing the execution of individual work items, including assignment to agents and deadline monitoring, is the task of the work item manager.

Role Resolution at Runtime

Differentiated agent determination ("role resolution") is supported on the basis of information which is not available until runtime.
Determining agents using role resolution restricts the number of organizationally possible agents according to business criteria. Information from the workflow context which is not available until runtime is incorporated in the role resolution.

Deadline Monitoring by the Runtime System

The runtime system allows deadlines to be monitored for the execution of work items and the workflow overall. As SAP Business Workflow functionality, deadline monitoring is independent of application functionality.
Deadlines ("requested start", "latest end") are always set relative to a reference point. this reference point can

• be the start time of a workflow or work item
• a date which is derived from the application context when the specific workflow instance is executed

Secondary Methods

Additional information which is required for processing a work item can be displayed in parallel in an additional window using the secondary methods of a step. This information may be, for example, original documents which have already been entered.
Other examples could include the original invoice when approving an invoice, drawings for assessing a material change, or applicant documents for setting an applicant status.

Event Manager

Status changes of application objects are published system-wide using events. Events are identified by the object type on which they are "reporting" and by their names. Events and their event parameters contain information from the context in which they are generated.


The reactions which are to take place when an event occurs are defined outside the standard application. The "receiver" of the event can be any suitable function module provided by SAP, the customer, or an external supplier.


Events can start tasks (single-step and multistep tasks) or reactivate workflows which are already in progress and waiting for specific events.
The event receiver linkage is therefore based on a publish and subscribe approach:

• The event is generated and therefore made known to the event manager (publish)

The object creating the event does not need to know which are the potential "receivers" of the event.

• Potential receivers enter themselves in an event receiver linkage table (subscribe)

The event manager checks the entries in the linkage table and carries out the assignment.


Central Access Point for a User: Integrated Inbox

The list of "jobs" to be dealt with by an employee, his work list, is displayed and managed in the integrated inbox of the SAP System.

Work Items and Mails in a Common Inbox

In addition to the work list, the documents in the SAPoffice inbox list (e-mail, Internet mail, and fax) are also displayed in the integrated inbox. It is therefore significantly easier for an employee to access the information important to him.
It is no longer necessary to access different information channels, nor therefore to log on to different systems and use different dialogs and interfaces.

Processing Work Items

The work items (the individual activities in the work list) can be processed directly from the integrated inbox of the R/3 System. This means that the appropriate applications are started directly with a double-click and provided with the necessary data.
The integrated inbox is therefore the most important interface for a user in his daily work.

Immediate Start of Follow-up Work Items

When a work item is executed it may be the case that the same employee can process the next work item within this same process. If this is the case, the business application of the second work item is started immediately without the user having to take the "roundabout way" via the integrated inbox.

Task Description: Intelligent Instruction

Workflow should also support inexperienced and occasional users of a system optimally. Part of the task description is therefore a textual task description. The integration with business objects allows case-specific data to be inserted into the text as object attributes.


Using the same technique, notifications can be generated on an event-driven basis and sent via e-mail to persons within or outside the company, or faxed or simply printed.

Documentation

For further details, refer to the chapter Runtime System: Work Items and Integrated Inbox in the SAP Business Workflow documentation.


Binding and Container

The exchange of information between the individual components of the workflow system is based on standardized rules which are specified in the binding definition.

Containers

Containers, with their table-like structures, are used to contain values (constants) and object references for control purposes for the workflow process and execution of work items.


If the object reference is known, it is always possible to access the attributes of the referenced object (for reading)! It is generally sufficient if object references are the only control information in the container. Redundant storage of information is therefore avoided.


Each of the components

• object method (method parameter container)
• single-step task (task container)
• multistep task (workflow container)
• role (role parameter container)
• event (event parameter container)

has a container whose elements are defined and described with a data type reference.
Each multistep task (and therefore each workflow definition) has exactly one workflow container in which the information is stored which is important for controlling the workflow. This includes, in particular, the reference to the object processed with this workflow and the user name of the initiator of the workflow.


The important information held in the container of a single-step task (task container) includes the reference to the object to be processed and the user name of the current agent after the task has been executed.

Binding

Information is exchanged between the individual containers according to the assignment rules specified in the binding definition.


The binding definitions within a workflow definition between the workflow container and the task containers of the individual steps are of central importance. The object reference to the object to be processed must generally be passed from the workflow container to the task containers.




Customizing

A number of settings need to be maintained in customizing so that the workflow system functions correctly. You can make these standard settings for the workflow system "at the touch of a button". You can find the relevant activity in the Implementation Guide in the Global settings section. Detailed maintenance of the individual customizing activities (which can be found in the component Workflow Management) is then generally not required.


The customizing consistency check allows you to check that you have performed the necessary customizing in your system. To do this, choose Utilities ® Consistency test ® Customizing in the area menu SAP Business Workflow (Development).