SAP WORK FLOW SCENARIOS

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.


• 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.

Neither this documentation nor any part of it may be copied or reproduced in any form or by any means or translated into another language, without the prior consent of SAP AG.

Basic Concepts

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

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.