Workflow Recipe for Passionate Starters – Part III (Spice up!!)

Dear Reader,

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.

Part I http://scn.sap.com/community/bpm/business-workflow/blog/2012/05/18/workflow-recipe-for-passionate-starters–part-i-spice-up

Part II http://scn.sap.com/community/bpm/business-workflow/blog/2012/05/18/workflow-recipe-for-passionate-starters–part-ii-spice-up

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

Identification:

In Identification field we can specify the workitem ID(s). Note: All other filters are ignored when we filter workitems using this option.

Type:

Given below are the possible workitem types,

Status:

Given below are the possible workitem statuses,

Priority:

In Other tab of an activity step/user decision step priority of workitem can be maintained,

Possible priorities are,

Deadline Status:

Workitems for which deadlines are maintained can be filtered via deadline status,

Task/Task Group:

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/Time:

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

help to,

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

For e.g.

Workitem container:

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

standard methods.

Business Object Components:

Every BO consists of below components,

Fig: BUS2012 BO in SWO1 Tcode

Interfaces:

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,

ExistenceCheck Method:

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.