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 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.
- SAP Managed Tags:
7 Comments
