This is PART III of 4 blog series that has been drafted keeping Workflow (WF) beginners in mind to
give a better picture & right start about SAP Business Workflows.
Workflow Log (Tcode: SWI1)
Workflow Instances can be tracked, monitored & analysed via Workflow Log. Once a Workflow is
executed a workflow instance is generated. To uniquely identify workflow instances SAP generates
a unique id for each workflow instance called as Workitem ID.
There are 2 types of workitem ids. Parent workitem ID and child workitem ID,
Parent workitem ID: This ID will be helpful to track the status of entire workflow.
Child workitem ID: For every WF task (nothing but steps in workflow) a workitem ID is generated which is
called as child workitem ID. For a workflow instance there will be 1 parent workitem ID and one or more
child workitem ids depending on the no of steps inserted in WF.
There is a status associated with Parent as well as child workitem id. List of possible statuses are,
Note that the status of the Parent workitem id is dependent on the statuses of child workitem ids. In
other words the status of a workflow is dependent upon the status of its individual steps. For e.g. if a
workitem has been sent to a user for approval the overall status of the workflow will be STARTED and
the approval workitem status can be READY/SELECTED etc… Once all the steps of the workflow are
executed successfully the status of the parent workitem(Workflow) will become COMPLETED. In case
any of the WF steps run into error, the overall WF status will become ERROR.
There are several filters in SWI1 Tcode which can be used to identify workflow instances.
Filter options in SWI1
In Identification field we can specify the workitem ID(s). Note: All other filters are ignored when we filter workitems using this option.
Given below are the possible workitem types,
Given below are the possible workitem statuses,
In Other tab of an activity step/user decision step priority of workitem can be maintained,
Possible priorities are,
Workitems for which deadlines are maintained can be filtered via deadline status,
Task numbers (TS – Standard/Custom Task & WS – Workflow Task) can be specified. Task Group is
a collection of tasks. Task Groups start with prefix TG.
Creation date or a date range (From & To dates) can be used. Also Creation time or time range of
workitems can be specified.
Switch On checkbox:
If this indicator is set, the following columns are additionally available for the layout of the work item list
that will appear once execute button is clicked,
- Number of the workflow definition
- Version of the workflow definition
- System administrator for this workflow
- Agent who executed the work item
Workflow log Features:
Let us filter all workflow instances which have been created on 27.04.2012. Specify creation date &
execute the report,
Output list appears as below,
To display log for a particular WF instance select the row and click on workflow log icon as below,
Log details appears as below,
As seen above we can see the Creation date and Time for Workflow (Parent) & individual WF
steps (Child). Overall WF status, Individual WF step status have been highlighted.
Clicking on Graphical WF log icon will display a graphical overview of how WF has executed in runtime,
We can see a GREEN colour line highlighting the steps executed in workflow. Currently the
workflow is waiting for User Decision Step to be completed as seen above. Graphical WF log
- Track to overall WF status as a graphical overview
- Identify the step in which workflow is currently waiting
- Identify the path of execution of workflow. For e.g. If we have a condition step with 2 options
TRUE or FALSE then from graphical WF log we can find out easily whether workflow was processed
in TRUE /FALSE path
Choose Extras-Show Ids from Menu to display workitem ids in log,
To identify the approver to whom the current workitem is sent, click on the Agent button as below,
A popup appears as below,
Choose Agents from above popup. Another popup appears which will display the approver,
Click on Technical WF log icon,
A screen appears,
In this screen we have several features. To display the list of all errors for this WF instance
choose Goto->Error Analysis from menu,
In case of no errors this option will be greyed out as seen above. Errors will be displayed in
a popup screen informing the reason for the error and the step in which it occurred,
We have parent and child workitem containers. Parent workitem container refers to the overall
workflow container which contains all the variables created. Step workitem container refer to
workitem container only for that particular step. For e.g. In a leave request WF Parent workitem
container can contain all values like employee id, name, leave start date, end date, reason for leave,
leave type & no of days. Assume there is a step in workflow which is used to calculate the no of days
of leave. For this we will write a BO method which will take from date & to date of leave as input and
will return the no of days as output. If we see the step workitem container only values of From date,
To date & no of days will be available. Leave Type, Reason for leave etc… will not be present.
Business Object Builder (Tcode: SWO1)
Introduction: Workflows are started by events. Events are available under Business objects.
SAP has provided around 5000 standard business objects for many standard scenarios for e.g.
BUS2012 is BO (Business Object) for Purchase Order.
It’s not possible to write ABAP code directly in WF. Business Logic for WF which involves ABAP
code is written in BO methods. These methods are consumed in WF tasks. It’s possible to create
custom BO objects, inherit standard BO and extend it via custom methods & attributes & redefine
Business Object Components:
Every BO consists of below components,
Fig: BUS2012 BO in SWO1 Tcode
Interface is a collection of attribute, method definitions and event definitions for an object type
sed in a common context.
All BO (Standard & Custom) contain the standard interface IFSAP.
This interface provides an attribute ObjectType and 2 methods Display, ExistenceCheck.
It’s possible to redefine the standard code present in Display and ExistenceCheck. For
redefinition in standard BO we will require access key to make changes. For redefinition in case
of custom BO, single click on the method and click on Redefine icon as below,
This method is used to verify whether the object identified by key fields actually exists. For e.g.
for a purchase order BO the key field will be PO no. Assume user creates a BO instance for PO
no 4200000000. In this method user can write code to check whether that particular PO no exists
by checking database tables. Exception 0001 has been defined for this method. To check the same
single on the method ExistenceCheck and click Exceptions button as below,
A screen appears as below,
As seen above exception 0001 is available. If the PO no does not exist then user can raise an
exception in this method using below macro,
EXIT_RETURN 0001 sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
It’s possible to add new interfaces to BO. Single click on Interface option and click on Create icon,
A popup appears as below,
In above popup enter the name of the interface to be inserted.
Thanks for reading. Please share your valuable comments.