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

Dear Reader,

This is PART IV 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

Part III http://scn.sap.com/docs/DOC-39431

Business Object Builder (Tcode: SWO1)

Key Fields:

They are used to uniquely identify an instance of BO. For e.g. a BO for Travel request can

have Trip no as the key field. It’s possible to have several fields under Keyfields section. But

the total length allowed for all key fields of an object type is 70 characters. To create new Key

fields single click on Keyfield and click create icon,

A popup appears as below,

Press No in above popup. Another popup appears,

Enter Keyfield, name, description, reference table and field name for keyfield. We can also enter

a seach help and parameter name in order to search the keyfield value based on database.

Note: Subtypes derives from Supertypes are not allowed to have keyfields of their own.

Keyfield of Supertype will act as keyfield of subtype. After creating a subtype if we try to create

new key fields we will get a popup as below,

Attributes:

They are used to provide additional information about the BO. For e.g. a BO for purchase order

will have Release group, Release Strategy & Release Indicator as attributes. To create new

Attributes single click on Attribute and click create icon,

A popup appears as below,

Press No in popup. Another popup appears,

There are 2 types of Attributes,

Virtual:

Code has to be written to populate values for virtual attribute since no field content in the

database corresponds to this attribute. These attributes are generated in runtime.

Virtual attribute coding:

GET_PROPERTY Attribute CHANGING CONTAINER.

…

SWC_SET_ELEMENT CONTAINER <Attribute> <Value>.

END_PROPERTY.

Comments:

Virtual attribute coding should be written between GET_PROPERTY and END_PROPERTY.

After GET_PROPERTY write the coding logic to generate the virtual attribute. Then set the value

for the attribute using SWC_SET_ELEMENT macro for single line attributes and SWC_SET_TABLE

for multi line attributes.

Database Field:

Attribute value is determined directly from the content of a database field. No separate coding is

required. Either we can mention the attribute of type field in a table or it can be mentioned as object type.

Methods:

All ABAP code necessary for WF are written in methods.

To create a new method single click on method and click create icon,

Press No in the popup. Another popup appears,

Enter method name, short name and description. Enable Dialog checkbox if this method is a

foreground method. Disable it in case of background methods.

Foreground method:

Methods which involve user interaction are called as foreground methods. They are called in

a task and at runtime a workitem is sent to approver for action. For e.g. Assume SE11 Tcode

screen should be displayed to approver when he opens the workitem. Below code can be written

in method,

CALL TRANSACTION ‘SE11’.

Background method:

Methods which contain logic for operations to be performed in background without user interaction

are called as background methods. For e.g. Method written to find email id of employee by passing

personnel no. In this case workitem will be generated but will not be sent to inbox. Instead they will

be executed in background.

Enable synchronous checkbox for synchronous methods and disable it for asynchronous methods.

Asynchronous method:

A task that refers to an asynchronous object method MUST be defined with at least one terminating

event. If we define an asynchronous method, we must ensure that one of the terminating events is

triggered after execution of the method. At runtime, the relevant work item is only terminated if one

of the defined terminating events occurs. For e.g. Once the approver clicks approve button assume

certain database tables are updated. If the tables are updated successfully then an event UPDATED

is raised. The workitem sent to approver should be completed only if the database tables are updated

correctly and UPDATED event is raised. In this case we need to make the method asynchronous and

specify the UPDATED event as terminating event in Task level.

Synchronous method:

A task that refers to a synchronous object method CAN be defined with terminating events. At runtime,

the relevant work item is generally terminated when the synchronous method has been successfully

executed. But the work item is also terminated if one of the defined terminating events occurs.

In case the method has to return its result in a result parameter enable result parameter checkbox.

Data type for the return parameter can be specified in Result Type tab,

Note: We cannot change or delete parameters inherited with their method from a supertype.

Choose Utilities->Color Legend from Menu,

A popup appears as below,

Above popup shows the color code for the different symbols used within a BO. API Method

are nothing but BAPI created as BOR methods. BO VBAP has details about Sales document

item. BUS2032 is BO for sales order. BO VBAP is accessible from BUS2032 since it has been

created as a relationship attribute,

Click on relationship attribute icon in above screen will display BO VBAP,

Methods with rose colour refer to inherited methods. White colour refers to custom methods newly

created. Red colour means that local implementation is recommended. For e.g. default methods

ExistenceCheck and Display come in red colour for which local redefinition can be done,

Events:

Events are used to trigger WF. To create an event single click on Events and click create icon,

A popup appears as below,

Enter event name, short name & description,

Testing a BO:

It’s advisable to test the methods created in BO once in SWO1 Tcode and ensure that the desired

results are obtained before integrating them in workflow tasks. To test a BO, enter BO name in SWO1

Tcode and click test button,

A screen appears as below,

Click on create instance icon highlighted above to create a BO instance. A popup appears prompting

to enter keyfield. In our case its PO no,

Click GREEN tick mark after enter the keyfield. BO instance will be generated if the keyfield exists.

Select the method to be test and click on the execute icon found against the method. If the

method has any input parameters a screen appears prompting to enter them,

There is option to debug the method by clicking on Debugging button.

Delegation:

Assume we create a custom BO called ZBUS2012. It has an event called TRIGGERWF & a method

called FINDAPPROVER. When we consume this BO in our WF we will mention the triggering event as

ZBUS2012.TRIGGERWF. While using the method in tasks we will refer as ZBUS2012. FINDAPPROVER.

In cases wherein we would like to use the standard BO in our WF rather than specifying the custom BO

we can delegate the custom BO to the standard BO. After delegation custom BO will be removed from

WF container. Assume we delegate ZBUS2012 to standard BO BUS2012. In this case we can mention

the triggering event as BUS2012.TRIGGERWF and method in task as BUS2012.FINDAPPROVER.

Although BUS2012 being a standard BO does not contain our custom event & method because of delegation

maintained it will internally call the event & method of the delegated custom BO.

How to Delegate?

Go to SWO1 Tcode. Enter the custom BO name which has to be delegated. Select Settings->Delegate

from the Menu as below,

A screen appears as below. Click EDIT (PENCIL) icon,

A popup appears as below. Pres GREEN tick mark in the popup,

New Entries button appears. Click it,

A screen appears. Enter values as below to maintain the delegate,

In Object Type field enter the name of the Std BO to which we our custom BO has to be delegated.

Enter custom BO name in Delegation type field. Enter user id of the person in person responsible field.

Save your entries. Note: At a time only 1 delegate can be maintained against an object type. For e.g. once

ZBUS2012 has been delegated to BUS2012 it’s not possible to create 1 more delegate of ZBUS2012NEW

to BUS2012.

Creating Custom BO:

Go to SWO1 Tcode. Give BOR name as ZTEST_BOR and click create icon. In the appearing popup

enter details as below,

Super Type input field is similar to specifying super class while creating our custom class. If we want

our custom BOR to inherit attributes, interfaces, key fields, methods and events from another BOR

then we can mention that BOR as super type. Object name, Name, Description are fields to identify

our BOR. Give relevant description. All our BO code will be saved in a program. Give program name

in customer namespace (Z/Y). This program helps us to manage different versions of BO methods.

Application refers to the domain/module in SAP for which we are developing this BOR. * stands for

Cross Application.

Version Management of BO Programs:

Go to SE38 Tcode, enter the name of the program. Choose Utilities->Versions->Version Management

from Menu as below,

Save the BOR in a package.

Why to save in a Package?

We can create methods in BO. Initially the status of the method will be Modelled which means

the methods are not accessible at Runtime. To make them available for usage we have to release

the methods. There are 2 statuses involved in releasing a method. First we have to change the status

from Modelled to Implemented. Implemented means method is only for test/internal use, possible unstable.

From Implemented we have to change the status to Released. Released means that the method is ready

for use. There is also a status called Obsolete. Obsolete means that this functionality is no more in use

and has been replaced. Note that obsolete old functionality will still be supported up to 2 releases. If we

do not save the BO in package we will get an error message as below when we try to change the status

to Released,

While releasing a BO we need to first release the BO and then its components like

Keyfield/Attribute/Method/Event. If we try to release the components before releasing BO we will get a

message as below,

Condition based Workflow Triggering:

Start conditions & Check FM are 2 options to trigger WF only if some criteria are met.

Receiver FM:

This FM is called to start the workflow if the event attached with the workflow occurs or if the Check FM

(explained below) terminates without an exception.

Check FM:

This is called before receiver FM. In case of complex conditions and database access using select queries

we opt for check FM. We can check whether our complex condition in Check FM is met or not. If it’s not

met then raise an exception which will stop the workflow from triggering.

Start Conditions:

Start Conditions are used if the condition checked is simple expression for e.g. Trigger WF only if

plant = 1000 or employee age > 50 & designation not equal to ‘SUPERVISOR’. WF will not trigger

if the Start conditions are not met.

Example for Check FM:

It’s mandatory to ensure that the interface of the custom check FM is same as the Standard Check FM.

As a practice copy the Standard check FM for e.g. SWB_CHECK_FB_START_COND_EVAL to a

custom FM.

Go to SE37. Enter FM name as SWB_CHECK_FB_START_COND_EVAL. Click on copy icon. A

popup appears as below,

Enter a custom function group and a custom FM name.

Code for above custom FM,

FUNCTION ZCHECKFM1.

*”———————————————————————-

*”*”Local interface:

*” IMPORTING

*” VALUE(OBJTYPE) LIKE SWETYPECOU-OBJTYPE

*” VALUE(OBJKEY) LIKE SWEINSTCOU-OBJKEY

*” VALUE(EVENT) LIKE SWETYPECOU-EVENT

*” VALUE(RECTYPE) LIKE SWETYPECOU-RECTYPE

*” TABLES

*” EVENT_CONTAINER STRUCTURE SWCONT

*” EXCEPTIONS

*” ERROR_EVENT_CONTAINER_EMPTY

*” ERROR_CONDITION_NOT_FOUND

*” ERROR_CONVERTING_CURRENCY

*” ERROR_EVALUATING_CONDITION

*” CONDITION_EVALUATES_TO_FALSE

*”———————————————————————-

data: lv_bukrs type bukrs.

Comments:

Data Declaration

select single bukrs from ekko into lv_bukrs where ebeln = OBJKEY.

Comments:

BUS2012 is the BO used to trigger WF as its a workflow for Purchase Order Release.

Keyfield of the BO is Purchase Order no. OBJKEY field consists of PO no. We are fetching

the value of company code from EKKO table by passing the OBJKEY(PO no).

if lv_bukrs eq ‘CEBM’.

MESSAGE E304(W8)

RAISING condition_evaluates_to_false.

endif.

ENDFUNCTION.

Comments:

Check if the company code is equal to ‘CEBM’. If yes then raise exception condition_evaluates_to_false

and do not trigger workflow. For any other company code exception will not be raised and workflow will

be triggered. Note: We have complete access to Event container in a Check FM. Event container access

refers to BO name, Event name, BO Keyfield, parameters in event container and the Workflow is supposed

to be triggered (Import parameter – RECTYPE ).

After creating above FM we have to assign the same in SWE2 Tcode against our BO & event as below,

We can know whether check FM resulted in exception or not from event trace SWEL Tcode. Trigger

the WF and go to SWEL Tcode. In case of exception in check FM a screen (SWEL Tcode) appears

as below,

Double click above item to see more details,

Containers & Binding in Depth:

I am extremely delighted to share the WIKI post by my ever inspiring Master whom I adore a lot,

Refer link: http://wiki.sdn.sap.com/wiki/display/ABAP/Binding+Definition+in+Workflow about

Containers & Binding in depth.

Thanks for reading. Please share your valuable comments.