SAP Business Workflow

Index

/conversion/tmp/scratch/400998411.doc Page 1
 Introduction 03

SAP Business Workplace 05

Basic settings 06

Business objects 08

Organizational structure 13

Workflow and Tasks 17

Containers 25

Object programming 28

Expansion / Delegation of objects 31

Roles: Rules for defining responsibilities 34

Deadline monitoring 37

Workflow monitoring (log) 39

/conversion/tmp/scratch/400998411.doc Page 2
Introduction

SAP Business Workflow is a tool used to integrate functionalities and

to complement the understanding of the processes of the R/3 system. This is conceived through the combination
deprocesses with the users involved together with the information regarding the
process. The use of workflow facilitates the management of electronic processes, as it encompasses
a series of activities that usually occur in the same way, involving several people or
departments, where a high degree of coordination is required.

Users benefit from simpler and faster access to information,

less effort with administrative tasks and also due to the ease of learning and
understanding of processes. From a managerial point of view, there is a gain in the control of
information, deadlines, service levels, and costs of the process, due to the control that the tool
enables monitoring processes that previously required external control outside the system
R/3.

The workflow can be used to assist in the progress of processes, due to

possibility of combining activities from different applications within the same process,
where all necessary information is sent directly to the end user
facilitating the execution of your tasks.

The following will present the main elements used in the development and in
workflow process maintenance

Business Objects (Object): Each process within R/3 has a central element.
which in turn has its characteristics. Within the workflow, these elements are
represented through objects, where the objects can represent a material, a
purchase order, an invoice or other key elements within a process.

Tasks: Generally, the processes are composed of several activities to be

executed in a certain order. These activities are interpreted as tasks
within a workflow process. These tasks can be used to access a
transaction, run a program in the background, obtain information to be used
during the process and other functionalities.

Methods: This is one of the elements that make up objects, each object has its
own methods. The method consists of an ABAP code that is triggered through the
workflow tasks. All tasks require a method to be
identified the ABAP program code to be executed, that is, the method identifies the
action to be taken on a certain task, such as, for example, the release of a
purchase order.

/conversion/tmp/scratch/400998411.doc Page 3
 Attributes: This is another one of the elements that make up objects, just like methods,
each object has its attributes. The attributes are characteristics of the objects, which can
to be accessed by the workflow at runtime to obtain, for example, the unit of
measure of a material or the cost centers of an order.

Organizational Structure: In order for tasks to be forwarded to users, it is

it is necessary to identify the possible agents for the task. These possible agents can
to be separated by organization, center, department according to the need of the
process. This separation is carried out through the use of organizational structures,
where we can separate user groups, and thus use these groups together
with the tasks.

Containers: From the beginning to the end of the processing of a workflow, the
Information used by workflow tasks is stored in memory areas.
called containers. These areas are necessary for the exchange to take place.
to share information between tasks and also to store the results of processes
performed in the background.

/conversion/tmp/scratch/400998411.doc Page 4
SAP Business Workplace

The SAP Business Workplace is the communication tool used within the system.
R/3 to send and view messages or execute workflow tasks. This tool can be
acessada através da transaçãoSBWPe possui características muito parecidas com programas de
email as can be seen in the figure below:

The 'Inbox' is where all documents and workflow tasks are located.
There are subfolders that allow dividing items between documents (non-executable messages) and
workflow(executable messages). Inside the workflow folder, there are other folders that are
used to separate workflow messages, where they can be easily identified
messages grouped by task, messages that are overdue and others
messages. To view a message, simply select it and its information will appear in
lower right frame.

For the received documents, they can be deleted from the inbox, where after
to select the document, just click the trash can button.

For workflow messages, they will only be removed from the inbox after execution.
These messages can be executed by double-clicking, or selected as
desired messages by pressing the execute button.

/conversion/tmp/scratch/400998411.doc Page 5
Basic Settings

In order for the workflow to be used correctly, it is necessary to execute the customizing.
to set up the communication interfaces and some characteristics
referring to new workflows created and jobs used. This customizing is done through the
The SWU3e transaction must be performed for all clients who require the use of the workflow.
Below is the customizing transaction screen of the workflow:

When the transaction is accessed for the first time, it is very likely that all the items related
to the "Execution Time Workflow System" and "Development Environment"
"Workflows" will not be customized. To speed up the process, it can be
by using the 'Automatic Customization' button, thus 80% of the necessary customization is performed.
automatically, leaving only a few items to be customized. If problems occur
with automatic customizing a log will be displayed with the error messages found
during customization.

/conversion/tmp/scratch/400998411.doc Page 6
 To verify if the workflow can already be used, execute a first
teste, através do botão “Testar Destino RFC”. Ao executar este teste,
the following message should appear:

If the message above is displayed, it may be performed

another test through the button "Run Workflow Verification"
where a message will be directed to the inbox of your SAP Business Workplace.
After clicking the button, a screen will appear informing that it is available in the inbox.
a user decision task and some information about the test result and how
proceed to finalize it. Just click on the symbol to access your box
entry in SAP Business Workplace.

If the tests carried out do not show any problems, the environment will already be ready for
execute workflows and forward your tasks to the responsible parties involved in the process. In case
opposite, check the messages of automatic customizing and see which items did not have
success, thus trying to configure separately the items that had problems.

/conversion/tmp/scratch/400998411.doc Page 7
Business Objects

The main element within a workflow is the Business object (objects), as it enables...
From him, we can obtain information about the main element addressed within a process.
Objects are composed of information that can be accessed through a unique key
that identifies your instance. The characteristics of the objects are filled in at runtime
from the moment they receive the instance to be handled, that is, it is informed the
object identification so that the information can be accessed. The objects are
visualized and edited through transaction SWO1, as shown in the screen below:

Objects can be searched (F4) according to their description or also according to the
application, by pressing the "SAP Applications" button, where you can be
select the desired module and thus locate the desired object
according to the figure below.

/conversion/tmp/scratch/400998411.doc Page 8
Once the desired object is found, simply display it so that its elements can be viewed.
Within each object we find the following elements: Interfaces, Key Fields, Attributes,
Methods and Events, as shown in the figure below.

/conversion/tmp/scratch/400998411.doc Page 9
 Observing the previous figure, we can identify that the key field of the displayed object is the
material number and below are its attributes. With a double click on the field
key or attribute, we can display its definition (figures below), and with that one can observe
a reference is made to the data dictionary to identify the source of the information. The
mesmo ocorre com os atributos, pois eles estão relacionados com o campo chave e também são
associated with the data dictionary.

The methods contain the necessary functionalities to execute the tasks of the workflow.
during the process. Selecting one of the methods and clicking the button will display the code
ABAP that will be executed when using the method in a task. All object has
a program where its methods are defined. The methods are declared
through the commands BEGIN_METHOD and END_METHOD, therefore, it is common when
We are viewing or editing a method where the declarations of others are found.
methods.

Events are notification statements that the system sends based on changes in
status of the object, that is, an event can notify that a material has been modified or that an order
The purchase was released. Events are used as "triggers" to kick off the workflow and with
this will execute a sequence of tasks whenever an event occurs in the system. Events
they can also be used to end a workflow, as a certain action in the system
can mean the cancellation of a process, such as the elimination of a request for
purchases that are in the approval process through the workflow. In the case of the displayed object in
In the previous example, we can observe the eventCreated that is triggered by the system whenever
a material is created.

/conversion/tmp/scratch/400998411.doc Page 10
 To detect the events that occurred in the system and to know which event should be used.
to trigger a workflow, there are transactions that allow tracking the events that occurred to
execute a certain transaction. Before trying to detect the event, the must be identified.
transaction where one wishes to start the workflow and then tracking begins. Below follows the
procedure to check events in the R/3 system.

1- Through the SWELS transaction, event tracking is enabled.

2- Enter the transaction MM01 (for example) and execute it until the end, in the same way as
the user would be working normally in the system.
3- After the transaction MM01 is completed, tracking must be disabled.
of events through the transaction SWELS.
4- To verify the events that occurred in the system, use transaction SWEL. If any
The event occurred during the execution of the transaction MM01 (for example) will be displayed.
a list as per the screen below:

In the above screen, it can be observed that during the creation of the material, two were triggered.
events, ViewCreatedeCreated. Along with the event, we can also observe the object
BUS1001006 which should be used in defining the workflow.

/conversion/tmp/scratch/400998411.doc Page 11
Objects can be tested to verify their methods and attributes, thus
avoiding later errors when used together with the
workflow. To test an object, it is necessary to provide its code and click
on the 'Test' button.

A screen will be displayed with some methods and attributes that may be available even if the
the object is not instantiated, but in order to carry out more complete tests, it is
I need to inform the instance of the object by clicking the 'Instance' button and providing the
data for the key field of the object.

As soon as a valid instance for the object is informed, its attributes are filled.
and the methods become available for execution, as displayed on the screen below.

To test the existing methods in an object, it is necessary to enter the ABAP code and place a
break-point at the beginning of the method so that information can be passed that is provided
by the workflow and so in debug mode, the method can be debugged and thus
identify possible errors.

/conversion/tmp/scratch/400998411.doc Page 12
Organizational Structure

Organizational structures are used to assist in the management of positions and

responsibilities assigned to all users of the company or to a group of users of a
determined area of the company. Together with the workflow, the organizational structures are
fundamental for task distribution according to the roles assigned to users, where
an already defined organizational structure can be used by the HR department or they use
structures specifically created to meet the workflow processes. Structures
organizational ones are divided into:

Organizational Units and Sub-Organizational Units

Organizational Units are used at the highest level within a structure

organizational. It is generally attributed to an organizational unit something that identifies the
higher level, either the company or the name of the process that will use the structure. Sub-
units are used to define departments within organizational units,
that is, a subdivision for large organizational structures.

Positions

Positions are used to create divisions within organizational units, and to

positions are associated with users respectively according to their
responsabilidades. Por exemplo, dentro da unidade organizacional de vendas, podemos
create multiple positions for each sales region, and associate users with each position.

Cargoes

Positions are used as a characteristic assigned to the positions, that is,

cited in the example of positions, we can have a position for the sales region of
SP, a position for the sales region of SC and a position for the regional of
sales of PR. Although they are distinct positions, each one has its users.
assigned responsible parties, we can assign them all the position of Salespeople.
need to send a message to a specific regional, we must
inform in the workflow to which position the message should be forwarded. With that, the
the workflow will forward the message to the inbox of all users who
are associated with the indicated position. If it is necessary to forward a message to
for all sales regions, we must indicate in the workflow the position ofSalespeopleas
message recipient, that is, the message will be forwarded to all
positions that have the attribute the SalesPerson and with that the message will be
forwarded to all users associated with the selected positions in accordance with
your position.

Users

Users are used to define the people who are part of the responsible team.
assigned to the positions of the organizational structure. A user can be assigned to a
or more positions within the organizational structure.

/conversion/tmp/scratch/400998411.doc Page 13
 In the figure below, we can observe an example of an organizational structure and the
use of the elements mentioned earlier. Note that there is an organizational unit
the principal that represents the company and two organizational sub-units were created that
represent the sales department and the purchasing department. Within each sub-
units, positions were created to identify the divisions of each department,
as can be seen in the sales organizational sub-unit where there is a position for
each sales region. In the case of sales positions, they were assigned the role of
Each position is associated with a user.

To create organizational structures, the transaction PPOCE is used. After the structure
it was created, it is possible to modify it through the transaction PPOME. When accessing the transaction to create
organizational structures, the first thing that should be done is to provide the basic data for
creation of the organizational unit, that is, to provide an abbreviation and its description.

/conversion/tmp/scratch/400998411.doc Page 14
 To create sub-organizational units or positions, right-click on the
organizational unit and select the option Create. Then select the option Unit
Organizational Position (see figure below) and provide the basic data of the sub-unit
organizational or position to be created.

To create the position, its basic data must be provided, that is, abbreviation.
the description (see figure below). The position is not mandatory and can be assigned at the time of
creation of the position, or later in a modification. The same applies to the attribute
Head of their own organizational unit , as this will indicate if the position is reserved for
coordinators, supervisors of the organizational unit. The use of this attribute enables the
quick identification of key users within an organizational unit through
rules used by the workflow for defining responsibilities. For better understanding
see the chapter that addresses the rules for defining responsibilities.

To create positions, the menu Process -> Create Positions must be accessed. A
a canvas to inform the abbreviation and description of the position (see figure below). The positions must be
created before the positions so that at the moment of creating the position the role is already associated,
but it can also be created later and then modify the position to associate the created position.

/conversion/tmp/scratch/400998411.doc Page 15
 To insert users into the created positions, right-click on the position.
desired, and select the Assign option. A screen (figure below) will be displayed to select the type
of assignment, where the User type title should be selected.

When selecting the assignment of a Title of type User, a screen will be displayed to
user search in R/3 where one or more users can be selected for the position.

To remove any attribution, click on the desired element, click with the button
right-click and select the options Delete -> Assignment. Depending on the object
selected, it is possible to undo the assignment by removing the selected element, through the
opçõesEliminar -> Objeto.

/conversion/tmp/scratch/400998411.doc Page 16
Workflow and Tasks

Tasks are the main point in defining a workflow, as it is through them that the
Information is accessed and made available to the user, enabling their interaction with the
process. It is through the tasks that we define what will be done, when and who will execute it.
a specific action within the workflow processes. What should be executed by the task is
defined through the association of existing methods in the objects. Who will carry out the tasks is
determined through the association of possible agents for its execution. When it will be done is
determined by the association of events of the objects with the definition of the workflow, since a
event means a status change of a certain object and this status change of the
An object can be defined as a starting condition for the workflow. The figure below illustrates the
necessary associations for the functioning of tasks and workflow.

Definition of the
Object Workflow
Organizational Structure
Events When? Start
Organizational Unit

Cargo
Method What? Task 1
Position

User ID

Task 2 Who? Rule

Film

In the workflow, there are two types of tasks, single-step tasks and tasks
multi-step (workflow) composed of several single-step tasks. The definition of a workflow is
considered as a task because in the definition of a workflow it is possible to make the call
from another workflow as a task to be executed during the process. Single-step tasks are
classificadas como tarefa standard (TS) e o workflow é classificado como modelo de workflow
(WS).

The definition of the workflow is composed of several steps, where these steps can contain
a task to be executed or simply being a decision step or other types of steps
that do not require a task to be executed, such as a conditional step (IF).

To associate a task with a workflow step, there are two types of tasks that can be
be used: dialogue tasks or background tasks. Dialogue tasks are tasks that must
to be performed by a user, that is, a task is sent to the user where it is necessary to
manual activation for its execution. Background tasks are tasks that do not require
activation of a user, that is, they are executed in the background and at the end of their execution
they can or cannot return data to the workflow.

/conversion/tmp/scratch/400998411.doc Page 17
 To create or modify a workflow model or a task, access must be obtained
the transaction PFTC. For workflow, select the type of task Workflow Model and for tasks
Standard Task is used. There are already several examples for tasks and workflow models.
standard applications for the various modules of the R/3 system, because it depends on the need
a standard workflow can be used or if the standard does not meet the need for
complete, we can use a standard workflow (copy) as a basis for defining a new one
workflow. To consult the standard workflows, we can use the search by the process name or
through the research on the application structure, as shown in the figure below.

In this way, it is possible to verify workflow models and predefined tasks accordingly.
with the application. For workflow developments, it is common to verify the process with the
user, identifying the transactions used, triggering events and possible events
terminators to later research standard workflow models and find one that can
address the needs of the process. If no workflow model is found
standard that meets the process needs, it is also possible to create a new workflow.

The main element for starting the development of a new workflow is the object and its
trigger event. Once the object is identified (see in Business Objects) we should use this
object from the beginning to the end of the workflow definition, where this object and its elements must be
used in all steps of the workflow.

/conversion/tmp/scratch/400998411.doc Page 18
 Na definição de um modelo de workflow, existem algumas informações obrigatórias que
must be informed before starting the graphic editor. It is necessary to fill in the fields of
abbreviation and designation (see figure below) in the Basic Data folder. There is also the folder
Description where a more detailed text about the workflow can be inserted, describing the
main points addressed in the process.

In the trigger events folder, we must specify what the event will be that will initiate the
workflow (see figure below) according to the object used, where one or more can be defined
more events to trigger the workflow.

/conversion/tmp/scratch/400998411.doc Page 19
To visualize the graphical definition of the workflow, simply activate the workflow builder, which is the tool.
used to visualize and edit the definition of the steps used during
the workflow process. Clicking on the Workflow Builder button will display
the graphic design of the process (figure below). On the right are displayed all the existing steps in
workflow chart at the top and the elements of the workflow container at the bottom. To
the center shows the workflow chart with the steps organized and logically connected accordingly
with the process and it is in this location where we really edit the workflow. On the left, it is possible
observe a macro view of the entire flow.

Com o editor gráfico do workflow é possível copiar, recortar, colar e também criar novos
steps within the flow. In certain cases, it is possible to create tasks from the creation of a step of the
activityType, where it is mandatory to inform a task. As in an ABAP program it is possible
perform a consistency check of the data and the workflow must also be activated before
its use.

The graph displays the triggering events as initial steps of the workflow and
also the execution of the workflow as the start of the process. This occurs because in certain cases it does not
automatically triggered events are found by the system and in this way we can
execute the workflow directly without the use of events, using the function
SWW_WI_START_SIMPLE in user exits. In these cases, events can also be used.
but it is also necessary to use the SWE_EVENT_CREATE function in user exits,
triggering the event defined in the workflow as the triggering event.

/conversion/tmp/scratch/400998411.doc Page 20
 In defining the steps of the workflow, various types of steps can be inserted, where it is
It is possible to use object attributes in conditional steps (IF) or in repetition steps (loop).
Below is a list of the main types of steps used in the definition of a
workflow.

Activity This type of step is used to perform processing through the call of
methods of the object used by the workflow. This is the only type of step of
workflow where it is mandatory to provide a task, as it is through the task that will be
executed the method where the ABAP code used to extract is associated
information or make the call to transactions that should be executed by
user.

Condition This type of step works like an IF and uses elements from the container of
workflow to set up the logical condition that will determine the next step to be taken
executed.

Multiple Condition This type of step works like a CASE and uses elements of
workflow container to set up the logical conditions that
they will determine the next step to be executed.

Event Generator This type of step is used to generate events from a workflow,
that is, it is possible to start another workflow by calling a
event.

Wait for Event This type of step is used to wait for system events.
It is usually used together with a Parallel Section step.
to wait for closing events.

Container Operation This type of step is used to manipulate the content of

elements of the workflow container.

User Decision With this type of step, it is possible to forward a task with
conditions for the user to decide what should be done within the
process. According to the user's response, it is possible
determine different paths to be taken within the
workflow.

Loop (until) Loop (while) These types of steps are used to create loops of
repetition within the workflow, where elements are used
to create the conditions for repetition, and inside
the steps to be taken are inserted into the loop
executed.

Parallel Section This type of step is used to create processing sections in

parallel, where the number of sections in parallel and in each one is informed
in the created sections it is possible to insert steps to be executed
simultaneously.

Send Email With this type of step it is possible to forward messages to the
SAP Business Workplace or to an email address of the
Internet.

/conversion/tmp/scratch/400998411.doc Page 21
 To view the features of any step of the workflow graph, simply click
twice over the desired step and then your information will be displayed. In the example below,
the characteristics of a step of type Activity are being displayed in the Control folder
we can observe that there is a task (TS00008319) associated with the workflow step that will
a função deProcessar a Nota de QM. Para cada tipo de passo é necessário informar a sua
denomination and whenever possible, also fill in the exit denomination so that it remains
easier visualization and understanding of the workflow design.

It can be observed that the person responsible for processing is assigned through a
function. This function is known as a rule (role), as it is defined by the parameters passed to the
function, the users responsible for the task to be performed will be determined. To define the
responsible for processing a task, we can use an organizational unit,
position, role or ultimately inform the user's login directly. It is not convenient
use the direct association with a user as responsible for the task, as there being the
Need to change the responsible person, it will be necessary to modify the workflow definition. The best
The way is to use the elements of an organizational structure, for example, to indicate a
position. When a position is assigned in the field of responsibility for processing, all the
users who belong to the position are determined as possible agents to execute the
task and will receive the task in their inbox. The same happens when we use a
organizational unit where all users assigned to the positions associated with the unit
indicated organizational will be possible agents responsible for executing the task. When using
a position, all the roles that have as a characteristic the indicated position will have their users
selected as potential agents responsible for carrying out the task.

/conversion/tmp/scratch/400998411.doc Page 22
 To create a task, there are some mandatory information that we need to fill out,
such as abbreviation, designation and method used by the task (see figure below). There exists
also the campoTexto of Work Item which is the text related to the title of the message displayed for the
user in SAP Business Workplace.

In the description folder, the descriptive text of the task is inserted, displayed in the body of the message.
in the SAP Business Workplace. It is possible to insert in both the title and the body of the message.
variables that will be replaced at runtime according to the attributes of the object or
according to the task container elements. An example of used variables can be the
code and the description of the material, as each message can be assigned a material
different.

The use of these variables is important so that the task becomes more objective and easier to
understand, because this way we can convey the maximum amount of information about the process, with
this facilitates decision-making at the moment of executing tasks in the workflow.

In the definition of a workflow model, there is also the Work Item text field, where
It is also possible to use variables that will be replaced at runtime. In the definition
In workflow, it is important to use variables in the text of work items to make it easier.
identification of the process when there is a need to check the workflow logs, as one
the same workflow can be executed numerous times throughout the day and if there is nothing that
being able to differentiate each executed process makes it very difficult to locate specific items that may
have presented problems during its execution.

/conversion/tmp/scratch/400998411.doc Page 23
 So that dialogue tasks are directed to their respective responsible parties,
there are two ways to associate the possible agents. When editing the task, access the
menu options Additional Data -> Assignment of Responsibilities -> Update. At this moment
a screen (fig. below) will be displayed for the assignments of the possible responsible agents
execution of the task.

To make direct associations with the task, the buttons must be used.
used for the creation and elimination of assignments of those responsible for processing. From
From here it is possible to inform one of the elements used in organizational structures to define
the responsible parties for the task. To use the association of elements of organizational structures
In the characteristics of the task within the definition of the workflow, it is necessary to modify the
task characteristic, by clicking the button and selecting the General Task option, as per screen
below. From this moment on, the associations of those responsible for
task processing may be carried out within the definition of
workflow.

/conversion/tmp/scratch/400998411.doc Page 24
Containers

Containers are memory areas used for exchanging information during the
processing of a workflow. These memory areas are formed by defined elements of
agreement with references made to fields of the data dictionary or objects. This exchange of
Information is necessary for the execution of tasks and other steps defined in the workflow.
There are five types of containers that can be used, they are:

- Workflow Container
It is the main container used in a workflow process, as the information
remain stored in it from the beginning to the end of the process, thus being able to distribute
information for all the steps contained in the workflow definition.

- Task Container
It is used to exchange information with the workflow container and the
container of the method. Through the task container, it is possible to receive and send
information for the workflow container, as it is through it that the information is
sent to the method and after the processing of the method the result of
processing can be returned to the workflow container. The elements of this
containers are initialized every time the task is completed, thus the area of
memory used by the task is always ready for new processing within
do workflow.

- Event Container
It is used to send information about the triggered event to the workflow, thereby it is
possible to send information to the workflow about the object being processed
at that moment.

- Method Container
It is used to exchange information with the task container, as it is through it that
the information is received and sent to the task container after the
processing of the ABAP code contained in the object's method.

- Role Container (rules)

It is used to receive information from the workflow container, as it is through it that
the rule for defining responsibilities will receive the necessary information to define
Which agents will be responsible for carrying out the task.

/conversion/tmp/scratch/400998411.doc Page 25
To create elements inside the aforementioned containers, click the Container button to
que sejam exibidos os elementos do container. Ao acessar os elementos do
workflow or task containers, we can observe that there are some
Standard elements created automatically, as these elements are used internally.
through the workflow and can also be used by us, depending on the need. These
Standard elements can be easily identified, as they all contain the character '_' in
start of the element name, such as the element of the workflow_WF_Initiator container
created to store the user ID of the person who was using the transaction that triggered the
workflow.

To create a new element within a container, click on the Create button and provide the
data of the element (see figure below), that is, the name of the element, characteristics and
data category reference.

In addition to the name and description, we must specify in the characteristics whether the element will
receive information (Import), if the element is going to send data to another container
(Export), if this element is mandatory and finally if it is a multi-line element (table).

As a reference for data category, we can define an element of the dictionary of

data or a category of object. This definition serves only to determine the size of the
information that will be stored in the container element, such as in the case of
It is necessary to store information with 40 characters; we can provide as a reference to
table MAKT and the field MAKTX. Although the field is intended to store the description of a
material, within the workflow we can store anything inside this element, and not
necessarily the description of a material, as the table and the field provided are just one
reference for the size and type of information that will be stored.

/conversion/tmp/scratch/400998411.doc Page 26
 The exchange of information within a workflow is called Binding for each type.
In the container, there are binding directions carried out during processing (fig. below). This
Information exchange is only allowed between elements that have the same category reference.
of data.

Container Container
Workflow Task

Event Container Container Role Container Method

The binding between the workflow container and the task container can be observed by clicking on the
data flow button that is in the characteristics control folder
step, where a screen will be displayed (figure below) with the elements of each
container involved and the direction of information exchange. At the top, the flow is displayed
workflow container information for the task container and at the bottom the flow is displayed
from the task container's information to the workflow container.

Whenever an activity is added to the workflow, a binding proposal is generated, that is,
the workflow editor checks the information that the task requires and the information returned
for the task, and generates a proposal with the flow of information. This proposal can be generated
also through the Automatic Data Flow Definition button found in the features
of the step.

/conversion/tmp/scratch/400998411.doc Page 27
Object Programming

This topic will present the main commands used in programming.

methods used by the workflow tasks. These commands are used in ABAP code
together with commands already commonly used in reports and interfaces, where the main
the difference is that these commands are used to access the content of the method's container and
attributes of the object used. To check the program executed by the method, we must access the
object through the transaction SWO1 and select the desired method. After selecting the item,
click on the buttonProgram. Below is a list of the main commands and their syntax:

SWC_GET_ELEMENT CONTAINER 'Element' v_Variable.

This command is used to obtain information contained in the method's container. Always
that a task is executed, the information that the task received from the container of
workflow, are passed from the task container to the method container. Through this
it is possible to access the container information of the method according to the
name of the informed element. The name of the container element must be placed between
single quotes and the variable must be created with the same type as the container element
so that information is not lost.

SWC_SET_ELEMENT CONTAINER 'Element' v_Variable.

This command is used to send information to the method's container. After the
execution of the method the information contained in its container can be returned to
the task container. Through this command, it is possible to modify the content of a
container element of the method according to the name of the specified element. The name
the element of the container must be placed in single quotes and the variable must be
created with the same type of the container element so that they are not lost
information.

SWC_GET_TABLE CONTAINER 'Element' t_InternalTable.

This command is used to obtain information contained in the method's container, but
with a difference compared to the commands presented earlier, it is used
only for container elements that have in their characteristics the storage of
multiple lines of information (characteristic of multiple lines must be marked). Through
from this command it is possible to access the information of the container of the method according to
the name of the provided element and store it in an internal table. The name of the element
the container should be placed in single quotes and the internal table should be created with
the same structure of the container element so that information is not lost.

SWC_SET_TABLE CONTAINER 'Element' t_InternalTable.

This command is used to send information to the method's container, but with
one difference in relation to the commands presented earlier is that only
for elements of the container that have in their characteristics the storage of multiple
information lines (the characteristic of several lines must be marked). Through this
It is possible to modify the content of an element in the container of the method of
according to the name of the specified element. The name of the container element must be
placed in single quotes and the internal table must be created with the same structure as the
container element so that information is not lost.

/conversion/tmp/scratch/400998411.doc Page 28
 SWC_GET_PROPERTY SELF 'Attribute' v_variable (or) t_InternalTable.

This command is used to obtain information regarding the object where the method is.
being processed, that is, whenever a method is executed through a task of
workflow means that the object already has a valid instance and that its attributes are
filled with their respective information. One example is the object BUS1001006, which
it is the object used for materials, where its instance is the material code (field
key). Once this object is instantiated, it is possible to access its attributes within
of the method used the above command. The attribute name must be in single quotes
and using a variable or an internal table to receive the information accordingly
with the desired attribute. To use an internal variable or table, we must create
the com has the same reference as the attribute of the object was created so that they are not
lost information.

Below is a practical example of using these commands, where the information

are obtained through the method's container and the object's attribute, and in the end, the information
selected are sent to the method's container. This example could be applied in the
use of a background task that utilizes the object BUS1001006 to obtain the description of
material.

BEGIN_METHOD example CHANGING CONTAINER.

DATA: v_texto(60) TYPE c, Text to return to the container

v_matnr LIKE mara-matnr, Material Code
v_maktx LIKE matk-maktx, Material Description
v_mines LIKE mara-meins. Unit of Measure of the Material

Obtains the material code through the container of the method.

SWC_GET_ELEMENT CONTAINER 'Material' v_matnr.

Select the material description

SELECT SINGLE maktx INTO v_maktx
FROM maktx
WHERE matnr = v_matnr
AND spras EQ 'PT'.

Gets the unit of measure of the material through the object's attribute.
SWC_GET_PROPERTY SELF 'BaseUnitOfMeasure' v_meins.

Mount the text to be sent

Material: v_maktx comercializado em v_meins
INTO v_texto SEPARATED BY SPACE.

Send text to the container of the method

SWC_SET_ELEMENT CONTAINER 'Text' v_text.

END_METHOD.

The file path provided seems to be a temporary document file. Please provide the actual text or content you would likePage
to be29
translated.
 For methods used in dialogue tasks, that is, the task is forwarded to a
the user executes it, we can use the call of a transaction, a report, BAPI or another type
of processing that requires user interaction. Similarly to the commands
The examples presented earlier are also used to obtain information used
in the call of a transaction and can be used to return the result of the processing
carried out.

When we use, for example, the call of a transaction in a dialogue task,

When executing the workflow, the ABAP code is run in the background until the transaction call.
At the moment the transaction is executed, the user responsible for the task must carry out the
necessary actions, where he will have control over the processing until the transaction is completed.
At the moment the transaction is closed, the processing of the method continues to be carried out.
in the background by the workflow and only when the method is completed the workflow task is
considered as completed. An example that can be observed to verify a method
que utiliza a chamada de uma transação é o métodoCreatedo objeto BUS2078, onde é executada
the QM01 transaction.

/conversion/tmp/scratch/400998411.doc Page 30
Expansion / Delegation of Objects

As we can see in the topics covered earlier, methods, attributes and

events are directly related to the workflow and its tasks. When we are
developing a new workflow or a new task, we use the characteristics of an object
standard, however the need to add more information to the workflow always arises.
(new attributes) or perform a transaction that was not foreseen in the definition of an object
standard (new methods).

We can create our own attributes, methods, and events within an object, but not
we can do this in the standard object, as the standard objects work like programs and
are only changed in case of corrections (application of a note). In these cases, we must do
a "copy" of the standard object and then create the necessary items to complete the functionality
of the object according to our need.

To make this copy, we use transaction SWO1 where we provide the object that we will use and
So we create a 'copy' by clicking the Subinfotipo button. At this moment it will be
created a new object that will have exactly the same characteristics as the object
standard informed in the transaction. Fill in the necessary fields (see fig. below) so that it is
the creation of the new object has been made.

Upon confirmation, a new object will be created where we can create new features.
necessary to complete the development of the workflow and its tasks. This object may be
accessed through the SWO1 transaction, providing your name and selecting the display mode
or modification. Whenever we create a new object or a new characteristic within the object
the symbol appears next to the object or the new item created. This symbol represents that the item
The issue is in a Modelled status, which means it is still under development.
Once its development is complete, before using it we must change its status.
released, as only with the status of released will it be possible to use it.

To modify the object's status, we must select the options from the menu Process ->
Modif. Release Status -> Object Category -> Implemented. At this moment the symbol that
it appears next to the object will disappear and then it will be ready to be released through the
menu options Process -> Modify Release Status -> Object Category -> Released. When releasing
the object will appear the symbol indicating that the object is ready for use.

To create new elements in an object, it is necessary to select what type of element is to be created.
created, positioning the cursor over Attributes, Methods or Events and then clicking on
Create button.

/conversion/tmp/scratch/400998411.doc Page 31
 Ao criar um novo atributo, devemos informar se o atributo será criado com base de campos
from the data dictionary. If the creation is confirmed through fields of the data dictionary,
a screen will appear to indicate which table will be used as a reference and then it must be
selected the desired field. If you do not use the creation of the attribute through fields of
data dictionary, a screen will be displayed (figure below) for the information to be provided.
characteristics of the attribute.

Ao criar um novo método, devemos informar se o método será criado baseado em um

function module with model. If the creation of the method from a function is selected
the steps for creating the method where the parameters will be displayed must be followed
necessary for calling the function within the method, and thus the code of the will be generated
method with the function call. If the method is not created based on a function model
(recommended) a screen will be displayed (Fig. below) to fill in the characteristics
of the method, such as method name, designation, and brief description. At this moment
We also define whether the method will be used in background tasks or dialog tasks, marking or
unchecking the flagDialog.

/conversion/tmp/scratch/400998411.doc Page 32
 When creating a new event, we must fill in a screen (Fig. below) with the characteristics
of the event, such as event name, designation, and brief description. After creating the method, the
The only thing that needs to be done is your release for use. This method must be activated.
through the ABAP code of a program or through a workflow using the step of
typeEvent Generator.

To use any element created in an object, it is necessary to modify its

status to released, as all elements are created with modeled status. To modify
the status of an object element must select the options from the menu Process ->
Modif. Status Release -> Component of Object Category -> Implemented. At this moment the
the symbol that appears next to the object element will disappear and then it will be ready to
be released through the menu options Process -> Modify Release Status -> Component of
Object Category -> Released. Upon releasing the element, the symbol will appear. indicating that
the object is ready for use.

Whenever a modification is made to an object, this object must be generated so that the
your new version is available for use. This generation of the object must be done
through the button Generate is in the toolbar of transaction SWO1.

In defining a workflow and its tasks, we must always use the same object from the
from start to finish. Thus, we should always use the standard object, as it already contains
all standard elements are incorporated and it is also possible to view the created elements
in an object created through a 'subinfotype'. The visualization of the new elements created in the
"copy" of the object is possible through the delegation made between the standard object and its sub-in-type.
This delegation is made through the first screen of transaction SWO1 by accessing the menu options.
Options -> Delegation -> InEverySystem. The table where all are registered will be displayed.
delegations between system objects and a new record regarding the delegation should be included
of the created object, where the fields will be filled with the names of the objects involved and the
responsible for the delegation. See example below.

Once the delegation between the objects has been recorded, as per the example above, all
elements that are created and are in released status in the ZBUS2078 object may be
used through the object BUS2078, thereby facilitating the use of the objects and their
elements.

/conversion/tmp/scratch/400998411.doc Page 33
Roles: Rules for Defining Responsibilities

As mentioned in the previous topics, those responsible for the execution of a

tasks can be obtained through the elements of an organizational structure or through
a rule. We use rules to define who is responsible for executing a task in cases
where it is not possible to specify an element of the organizational structure, as in certain cases the
approvers may vary according to cost centers, amount of the document to be
approved or group of goods among other examples where a rule is applied for definition
of those responsible.

The rule for defining those responsible is assigned with the characteristics of the step of
workflow activity and must be inserted in the area of those responsible for processing,
selecting the type of responsible as Function and informing the standard function to be used
(see figure below). There are some standard functions ready for use, where it should be
verificada a regra aplicada para seleção de responsáveis e identificar se alguma delas atende as
task needs.

For the rules of defining responsibilities, information exchange is also used.

between the workflow container and the function container, in the same way that the information is
sent to the task container. Through the Data Flow button this exchange of information
can be defined or modified for the rule used by the task.

/conversion/tmp/scratch/400998411.doc Page 34
 We can also develop our own rules through the transaction PFAC.
(Standard Functions) where we can create a new function. When creating a new function, we must
provide your basic data, such as abbreviation, denomination, and description of the created rule
(figure below). In the function, the elements of the container must be created according to the
necessary information for the selection of those responsible and it must also be associated with a
function module where the processing for the selection of those responsible is actually done. This
function module can be created through transaction SE37 and must have in its definition the
tables AC_CONTAINER of type SWCONT and ACTOR_TAB of type SWHACTOR. The table
AC_CONTAINER will store the data related to the rule's container in the ACTOR_TAB table.
the selected responsible parties are inserted by the function.

This function module contains the ABAP code executed to read tables
where can the information used to select the responsible persons for the task be accessed.
Within this function module, we use the command below to obtain the information from
the container of the rule and the ABAP commands that are normally used can also be used in
a function module. This command works in the same way as the command used inside
two methods to read the information from the method container.

SWC_GET_ELEMENT AC_CONTAINER 'Element' v_variable.

/conversion/tmp/scratch/400998411.doc Page 35
 To return the data to the workflow, the ACTOR_TAB table must be filled out.
where records related to an organizational unit, position or fill it can be inserted
with a relationship of users. In the OTYPE field of the table, we inform the type of element that
is being used, where we can use U for users, S for positions, and O for units
organizational. The OBJID field is filled with the identification according to the type of
element used, that is, for users we use the UserId, for positions or units
For organizational purposes, we should use its ID (OBJID), which can be obtained by reading the table.
HRP1000 where the information about organizational structures is located.

Once the ACTORS_TAB table is filled, its records are automatically

transferred to the workflow task and then the responsible parties are assigned to the task accordingly
with its content.

/conversion/tmp/scratch/400998411.doc Page 36
Deadline Monitoring

Within the workflow, it is possible to set and monitor deadlines for the execution of your
tasks. Through deadline monitoring, the workflow system can automatically send
notifications or execute scheduled actions, as soon as the deadline for execution of a
task. This deadline monitoring is configured within the characteristics of the step of the type
Workflow activity. When accessing the task characteristics (double-clicking on the task)
workflow graph), select the folder where the information is entered.
monitoring (figure below).

To define the deadline for executing a task, we can set the amount in
minutes, hours, days, weeks, months, and years that should be counted from the date/time of
reference. For reference date/time there are three options to define it: Generation of the Work Item,
Workflow Generation or Printing. When defining that the reference will be based on the generation of the work
item means that the date the task was assigned to the person responsible will be used. If
reference for based on the generation of the workflow, means that the date the workflow will be used
It has started, meaning the deadline begins to count from the start of the process. The print option
it means that the reference date/time will be provided through container elements of
workflow. For this, we must create elements in the workflow that are used exclusively.
for the definition of the reference date for deadline control and before the task is
Forwarded, it is necessary to define the values for these container elements.

Once the reference date/time and the execution time of the task are defined, we must
define what will be done if the deadline is met. There are two options for possible actions.
in case of expiration of the deadline. We can send a notification or trigger other tasks
(background or dialogue).

Para encaminhar a notificação, na pastaExibirTextoinforme qual será o destinatário da

mensagem e o texto da mensagem. Para o destinatário da mensagem utilizamos os mesmos
elements assigned to the field responsible for carrying out a task, that is, it can be
assigned an organizational unit, position, user, or a rule. To create the text, there is a
the blue link will automatically take you to the screen where the displayed text should be entered when
for meeting the deadline of the task.

/conversion/tmp/scratch/400998411.doc Page 37
 Whenever a notification regarding the deadline of the task is forwarded, the user who
if you have your task overdue, you will notice that overdue tasks also appear in the sub
workflow folder for Late Entries. The task remains available for execution in the folder.
workflow, but by selecting the overdue entries folder the user can only view
the tasks that are past their deadline.

In order for other tasks to be executed if the deadline is reached, we must inform
The output name of the pastaModelado. Once the output name is provided, it will be
an additional branch was created below the task indicating where the flow will go if it is
the deadline for the task has expired (figure below). In this case, the task will also be displayed in the subfolder
the workflow of Delayed Entries. As shown in the figure below, we can observe that in
At a certain point in the workflow, the task 'Display Material' was created, where an output was generated if the
deadline for the task to be achieved. If the task is completed on time, the flow
it will continue normally through the exit indicated as Displayed Material. On the right branch
(Deadline Reached) the steps to be taken must be inserted in case the deadline is
reached and after executing these steps the flow will return to the delayed task.

/conversion/tmp/scratch/400998411.doc Page 38
Workflow Monitoring (Log)

Whenever a workflow is executed, its information remains stored in

tables within the workflow system. The information from each process executed in the workflow is
identified in these tables through an identification key called Work Item. Each
a step of a workflow receives an identification (work item) thereby generating a history of all
the steps taken in the process.

Through these tables, it is possible to access the information of each executed workflow and
with this identify possible failures in data exchange between tasks and the workflow or verify
what actions were taken during the process and who carried out the necessary tasks.

To access this information we must use the transaction SWI2_FREQ, where

we can select the period to be analyzed, the type of task to be researched, and we can
also specify which task will be selected (figure below).

/conversion/tmp/scratch/400998411.doc Page 39
 After executing the transaction, a screen will be displayed with all the tasks executed.
according to the data on the home screen (figure below). The tasks that have the prefix TS are tasks
standard e the tasks with the WS prefix are workflow templates. The last column on the right indicates the
number of times the task has been executed. To view the executions of each task,
just double-click on the desired line.

By selecting one of the rows to view the occurrences of the task, it is possible to identify
what was processed each time the task is executed. This identification is done through the text
from the task (work item title), which is defined in the task characteristics. In the example below,
we can verify that among the six executions of the task, one was related to materialXCAPAZe
the other five regarding the material P100. At this moment, the person responsible can be seen
by processing, generation date and task status.

For viewing a slightly more detailed log, we must select one of the
lines in the presented table and click on the Workflow Log button. At this point, it will be displayed
all tasks executed or ready for execution related to the workflow process of
selected task. In the workflow log screen (figure below), tasks are displayed accordingly.
with your execution order and through this screen we can access the information sent to
user, such as task texts and characteristics of the tasks performed, by clicking on the
presented tasks.

/conversion/tmp/scratch/400998411.doc Page 40
 From the workflow log screen, it is possible to access more detailed information.
pressing the button of Technical Details List where we can view the information of
each step of the workflow. In the list of technical details (figure below) we can identify the user
that executed the tasks, date and time of execution, container data of the tasks at each step
among other information.

The list of technical details is a dynamic list that presents a series of links where
podemos acessar as informações de acordo com o local onde clicamos com o mouse. Através do
symbol we can access the container information of each task. Through the symbol
we can verify the users responsible for carrying out a task that has not yet been completed
closed.

There are other tools to analyze the processing of a workflow, among them
here are the transactions:

SWI2_DEAD - Log of Work Items with overdue deadlines

SWI2_DURA - Work Items according to processing duration

/conversion/tmp/scratch/400998411.doc Page 41