Documente Academic
Documente Profesional
Documente Cultură
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
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.
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.
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).
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.
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.
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 customerspecific 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.
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.
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.
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
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).
Standard tasks are client-independent and are defined without a period of validity.
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
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 singlestep tasks have been designed as separate "modules" which can be used as often as required. A singlestep 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.
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).
Documentation
For details on maintaining roles, refer to the chapter Roles in the SAP Business Workflow documentation. Useful information on specifying and determining agents can be found in the section Agents of Work Items - Concepts and Procedures in the SAP Business Workflow documentation.
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.
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.
The integrated inbox is therefore the most important interface for a user in his daily work.
Documentation
For further details, refer to the chapter Runtime System: Work Items and Integrated Inbox in the SAP Business Workflow documentation.
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.
Documentation
Further information can be found in the chapter Container and Binding of the SAP Business Workflow documentation.
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).
Documentation
Further information can be found in the chapter Settings, Customizing, and Authorization of the SAP Business Workflow documentation.