Did you know SAP has one of the world's most powerful workflow engines built

into its core basis system?

SAP Workflow is a set of tools used to design, develop and implement workflows in SAP based on events that occur
on various business objects. Based on an object oriented concept of Objects (Business Objects / Classes ) SAP
Workflow can fully automate all Enterprise workflow requirements.
SAP Workflow can be used when working with different Applications or Programs : Mobility , Webdynpro ABAP ,
CRM , SRM , BSP , SCM & many different modules.
BASIC SAP GUI NAVIGATION
Workflow terminology
Use of workflow and workflow templates
Difference between mail & workitem
Basic Customizing settings in the SAP Business Workflow system
Inboxes:
Possible inboxes for work items
Defining substitutes
Processing work items
AGENTS
Agent Assignment
o Possible Agents , Responsible Agents , Excluded Agents
o Recipient
o Actual Agents
o Assigning Multiple Agents Per Work Item
o Deadline & Notification Agents
o Agent Assignment Using Organizational Structure
The Basic Organizational Plan
The Extended Organizational Plan
Doing Without an Organizational Plan
o Agent Assignment Using TASK Group
BUILDING AND USING WORKFLOW
Defining workflows using the Workflow Builder
Binding Matrix
Enhancing business objects with the Business Object Builder
Defining business process steps: task definition
Data definition and containers
Dynamic agent determination at runtime
Triggering workflows with events
Triggering events in the system
Deadline monitoring
Workflow Wizards
Options for ad-hoc processing
WORKFLOW PROGRAMMING
Business Object Builder: defining and implementing your own BOR objects
Data flow and new containers
Agent determination rules
Rule Basics
Testing & Simulating Rules
Responsibility Rules with multiple criteria and Secondary priorities
Agent Determination using SAP Organizational Data
Function Modules as rules
Programming exits at step and workflow level
Event generation by programming

o Check function modules
o Receiver type function modules
o Receiver function modules
Runtime system:

o Structure
o Performance
o Administration
BUSINESS OBJECTS
Creating Custom Business Objects
Extending BO Types Via Delegation
Debugging background methods in Workflow
Business Object Components
o Adding Interface
o Creating Key Fields , Methods , Events
o Common Business Object Types Used with Many Workflow Scenarios
SELFITEM
WF_TASK
SYSTEM
USR01 , USER
o Methods:
Synchronous methods
Asynchronous methods
Foreground Methods
Background Methods
Secondary Methods
Before Methods
After Methods
ABAP CLASSES : OO-ABAP IN WORKFLOW Preqrequisite :( OO ABAP)
Definition and implementation of ABAP-OO classes for use in the workflow
Definition of attributes
Definition of methods and error handling
Definition of events
Triggering ABAP-OO events
Using ABAP-OO classes in workflow processes
Difference between ABAP Classes & Business Objects
UTILITY Classes in Workflow

o
Creating Utility Class
Workflow Interface IF_WORKFLOW : BI_PERSISTENT , BI_OBJECT
Using Utility Class in a TASK
Functional Methods
Deadline monitoring using Utility Classes
Business Classes in Workflow
o
Difference between Utility & Business Classes
Implementing& Usage of Local Persistent Object Reference
Implementing ABAP class objects
Event handling using class CL_SWF_EVT_EVENT
Handling Exceptions using CX_BO, CX_BO_APPLICATION classes
ADVANCED WORKFLOW DESIGN TECHNIQUES
Step Conditions
Step Condition : Create Work Item
Step Condition : Complete Work Item
Step Condition : Completion Execution
Implement Table Driven Dynamic Parallel Processing
Implement a FORK
Notify recipients Via EMAIL that a Deadline Missed
Skip Work Item If Deadline Missed
Scheduling background Job for Deadline Monitoring
Parallel Processing
Reusing Workflows as Sub Workflow
Deadline Reactions : Standard Escalations , Modeled Escalations
Modeled Deadline Escalations
Binding
Blocks & Local Workflow
Ad-hoc Features & Review Work Item
EVENTS AND BUSINESS INTERFAECS
Introduction to events
Event linkage Table & Search For Events
Evaluation and Maintenance of Type Linkages with Process Flow
Triggering Events
Start Conditions For workflows
Terminating Event
Workflow Header Events
Parked Events , Event Queues
Raising Events From Business Application
Raising Events Via Classes
Raising Events Via Status Changes
Raising Events Via Change Documents
Raising Events Via Message Control
Raising Events Via HR Info type
Raising Events Via BTE
Raising Events Via calling a workflow API
Raising Events Via Implicit Enhancement Points
WORKFLOW DIAGNOSTICS
Diagnosis Logs

Workflow Log
Diagnosis Transaction
Event Trace
RFC Log

Debugging Workflow
WORKFLOW ADMINISTRATION
Error Resolution
Techniques To Resolve Runtime Errors
o Basic Settings For Error Monitoring
o Finding & Fixing Work Items
o Diagnosis Of Workflows with Error
o Work Item Selection & Work Item Frequency
o Work Item Display : Standard & Technical View
o Resolving Agent Determination Errors
Fixing work Item With No Agents Or Wrong Agents
Preventing Agent Determination Problems From Recurring
Resolve Buffering Errors

PRACTICAL EXAMPLES DONE IN CLASS ROOM .

First we learn handling Business Scenario with standard object Type for Business Partner Creation
Business scenario handling terminating events, asynchronous method, building relationships between different object
types, Binding Matrix, suppressing possible step outcomes with custom object type. This one example will make sure
any development in workflow you can complete easily without any trouble. This is a complete custom application
Business Scenario with Standard Object type and delegation of subtype using deadline monitoring
Macro creation & use at design time and runtime.
Macro Reporting
Real Time Workflow Project Scenario on Sales Pricing: This project topic Covers all real time based Development ,
Configuration , Negative & Positive Testing

ADVANCE TOPICS : Prerequisite :( OO ABAP & WEBDYNPRO ABAP)

Workflow with UWL
Web flow connector settings
Webdynpro ABAP Application using different Workflow APIs
Inbound & Outbound Plug configuration for UWL
Net weaver Portal Integration And settings For UWL
UWL validations
Customizing the Workflow Template using XML generation in Portal
Standard settings for workitems related UWL in backend.
9. Adv. Configuration using portal wizard
10. Workflow with BRF+


Using ABAP Object Oriented Coding in your Custom Workflow
SAP Business Workflow was built on an approximation of object orientated programming called the
Business Object Repository or BOR. It uses object oriented techniques which allowed developers the
ability to create copies of standard BOR objects, modify them and through inheritance allow them to be
used in place of the standard.
This was my comfort zone. I learned SAP and ABAP programming using BOR objects, creating
attributes, coding methods, and developing workflows to meet my clients needs. As a workflow
consultant I was special, as most of my ABAP friends felt intimidated by the concept of workflow and
using Business Objects. However, as I enjoyed my specialized skill, I started doing a lot more ABAP
development apart from workflow, and realized the new tools such as the ABAP workbench were much
easier to use that the Business Object editor.
When I used the Business Object Editor I felt I was going back towards my COBOL days of 72 column
limitations. How free I felt being able to write code that continued right past my visible screen. Then
came ABAP OO, and I started to realize my version of object oriented programming, was a far cry from
where SAP was heading. I was an old dog! I enjoyed the ABAP workbench, but at the same time I
intimidated by what seemed to me as a completely new programming language.
ABAP OO and Workflow The Turning Point
A couple of years ago, I was working with a Workflow consultant who I did not know, and as soon as he
was done with his first workflow I decided I would take a peak to see what level of developer was on our
team
Well, I opened the workflow, went to the triggering events, and saw an ABAP class rather than a BOR as
the triggering event. I drilled into the class, saw all of the methods, attributes, types, events, and realized
all of his tasks used this class as well. As I looked at the workflow I was immediately impressed. While I
had been relying on my use and knowledge of BOR, this Workflow consulting had taken the next step
and was using ABAP OO for everything. At that point I decided I needed to figure out how to use this
new technique, and force myself to learn using ABAP OO in this way.
Why Use ABAP OO for SAP Business Workflow?
Now that I had a mission, I had to figure out what the advantages of using ABAP OO had over BOR. As I
started investigating, reading blogs, workflow books, and looking at our current SAP system, I started to
find that SAP was using ABAP classes for many of their own workflow processes, and most of their code
base was now ABAP OO.
I kept on seeing was that the code was easily maintained by ABAP programmers without workflow
knowledge, A huge advantage! I had to think about this one. My lively hood depends on the fact that
clients need workflow specialist. But as I continued pondering this dilemma, I also came to the
conclusion that if I did not start to learn this, I would not be able to maintain the newer workflows that
utilize ABAP OO. In addition, if I could master ABAP OO I would be able to broaden my skill set and my
own marketability.
I have worked with various customers and clients over the past decade and I have noticed that most of
the workflows that I have developed arent as much about delivering decision tasks to the correct people,
but rather automating a complicated set of procedures that cross various functional areas of
responsibility. This is where ABAP OO can really help. Complex code used for common business
processes is much easier to access and reuse with classes and methods instead of the traditional BOR
Editor.
Now please do not misunderstand me. There is still a need for BOR and the use of it in SAP Business
Workflow. A lot of business processes have been built on this foundation, and to replace them with ABAP
OO would not make fiscal sense, as the cost of developing, testing, and the disruption to current
processes would be too great. So when a new requirement came along which did not have a current
workflow I could build upon, I took the plunge and built it using ABAP OO.
Now that you can have a good understanding of how SAP Business Workflow can benefit from using
ABAP OO, the next blog will get into details on how make a custom class usable in workflow as well as
how to create events and start workflows using ABAP OO.
Using ABAP Object Oriented Coding in your Custom Workflow
In the first part of this blog regarding the use of ABAP OO with SAP Workflow, I explained some of the
benefits of using ABAP OO with your custom workflows. In this part I will go into more detail about
creating an ABAP OO class and using it within a workflow. This blog does not go into great detail about
ABAP OO programming so learning some basics via other blogs or books is helpful.
Creating a class that can be used by workflow is a little more time consuming than creating a copy of a
standard SAP Business Object and delegating your new object, but once you have done it a few times it
is rather simple and allows you to utilize ABAP OO.
Using SE24 I created a class ZCLZZ_WF_DEMO_CLASS which I will use in this example to represent a
vendor. In order for workflow to be able to use this class you need to add
the interface IF_WORKFLOW. The important part of this interface is called the Local Persistent Object
Reference, which is used to convert the workflow object reference into the specific instance of the ABAP
Class, as well as the reciprocal. This transformation is handled in the two interfaces included
withIF_WORKFLOW; BI_PERSISTENT and BI_OBJECT.
The methods BI_PERSISTENT~FIND_BY_LPOR will convert the current object reference used by
workflow into instance of the ABAP Class. TheBI_PERSITENT~LPOR method will convert the ABAP
instance into the workflow instance. While this communication was handled behind the scenes with BOR
objects and workflow, a little bit of coding on your part is now needed.
Once the interface has been added, you need to open each method inherited fromIF_WORKFLOW and
activate the empty source code. As mentioned previously, the methods FIND_BY_LPOR and LPOR are
the ones we need to concentrate on.
Below is the code that I added to the CONSTRUCTOR, FIND_BY_LPOR and LPORmethods, as well as
the Class Attributes required.
Workflow Class Attributes:




Workflow Class Constructor:








Workflow Class Method FIND_BY_LPOR:







Workflow Class Method LPOR:




Next, I created a simple method DISPLAY_VENDOR which we can use in a task in our workflow for the
user to execute with an exporting parameter of RETURN to match our BAPI call









The next step is to create an event which we will use to start our new workflow, as well as a method to
raise the event. On the events tab I created an eventSTART_WF. I did not include any event
parameters but it is as simple as clicking on the PARAMETERS button and adding them if you need too.






Next I created a method that would raise our new event. The code for this is a little different than the
function module calls we are used to using
likeSWE_EVENT_CREATE or SAP_WAPI_CREATE_EVENT. Instead you use a call to
class CL_SWF_EVT_EVENT method RAISE or RAISE_IN_UPDATE_TASK.
If your event has parameters in an event container, call the methodGET_EVENT_CONTAINER to return
the definition from the event, and/or SET_EVENT_CONTAINER to populate the event container
parameters.










OK We are ready to use our new class in a Workflow!!
I have built a simple workflow that will start from our event defined in our ABAP OO class, as well as call a
task using our DISPLAY_VENDOR method.
From the workflow builder screen (Part of Workflow Development Tools) click on the define workflow
Triggering Events tab, and rather than selecting BOR Object Type, instead select ABAP Class as
the object category. Enter the class and the event, and bindings, binding the event object to a workflow
container defined as your class, and finally activate the event.

Next, create a task that calls the method within the class. A trick you need to know, is that after you save
the task, you need to check the Synchronous object method box










Once you have inserted the task into your workflow and activated it you can test the process from SE24
and executing the method START_WF. If everything was done correctly you will see your workflow was
started and by executing the work item in the Workflow INBOX, the vendor is displayed.
This is just a very simple example, but as you can see using ABAP OO opens up a whole new dimension
to workflow processes. As I stated in the first part of this blog, most of the workflows that I have done in
recent years arent designed to deliver the work to the right people at the right time, but rather to
automate as many processes as possible in an effort to minimize segregation of duty issues. With ABAP
OO it is much easier to incorporate complex code and access standard SAP logic.
In the next part of this blog I will go into more details about work items using ABAP OO, how to create the
equivalent of BOR attributes within the class, as well as some tips and tricks that I have learned and
continue to learn as I expand my use and knowledge of SAP Workflow using ABAP OO.
ABAP Object Oriented Coding and Workflow BOR Integration
In the first part of this blog regarding the use of ABAP OO with SAP Workflow, I explained how to use an
ABAP OO class to start a workflow as well as call one of the methods in the class from a work item. In
this final installment I will demonstrate how to instantiate an ABAP OO class from workflow, the use of
functional methods, and finally some tips I have learned while developing custom workflows using ABAP
OO.
Since BOR is still a common repository for a number of objects it is likely that you have a workflow that is
triggered by a traditional BOR event. But for our demonstration purposes you want to use a class to
handle many of the functions and rather than add these methods to the BOR. You want to utilize an
ABAP OO class.
When the workflow starts you have an instance of the BOR object which is defined by the key fields that
were instantiated and passed during the normal event creation. Now you want to instantiate the class
which you are going to utilize. Leveraging the class we developed in the previous blogs, create a
method that has in input parameter as which is the key to the class, and an export parameter that is a
type reference to your class. The method CREATE_INSTANCE is defined as static and public.






Create a New Workflow Task
Create a task using the Workflow Development Tools which calls the new method, and make sure to
indicate that it is Synchronous object method.











Next, include this task in a custom workflow. For this demonstration I created a workflow that is started
from BOR LFA1 event CREATED. Test the workflow using SWUS passing in the key to LFA1 which is
the Vendor Number. View the workflow log and container to see that you now have an instance of the
ABAP OO class which will allow you to reference the class methods and attributes.

Within a BOR object you can have different types of attributes, so that once the object is instantiated the
value is calculated.
To do the same in a class, you can create an attribute that is populated from a method that is executed
from the constructor method. I created a simple attribute VENDOR_NAME as a read only attribute. I
then created a method named READ_ATTRIBUTES which will read the name of the vendor and
populate the attribute. I placed the execution of this method into the constructor, and when the class is
instantiated the VENDOR_NAME is populated and is available to workflow.




An alternative to an attribute would be a functional method. These would be an approximate equivalent
to virtual attributes for a BOR object. The added value here is that you can pass in parameters to use
during the method, and you can call these methods again and again when you need to rather than only
executing the code when the class is instantiated.
I created a method to get the list of user ids assigned to a particular work center. I then created a simple
task that passed in the value of the work center and returned the users assigned.



Experience Matters.. Tips &Tricks
Lastly I wanted to share an issue that I ran into while using ABAP OO with a new custom workflow that I
had created. When I first learned workflow I was taught to develop the method first, then a task that calls
the method and finally insert the task into the workflow. This would allow the system to automatically
generate the container elements required at each step so that I only defined them once at the method
level. I still use this practice today, but while developing my first ABAP OO based workflow I had used a
method from a class where the return parameter was typed using begin of instead of a data dictionary
type.






So when I went to create the task to call the new method it automatically created the data element with a
definition as below.














This worked in development and tested just fine. The issue was when we transported the workflow and
class to the QA environment, the transport failed with a return code of 12. After several attempts to fix it, I
finally discovered that the workflow was unable to generate because it could not find the type
CLASS=ZCLZZ_WF_DEMO_CLASSTYP which was truncated. In order to fix it I had to create a
structure that matched the definition to use as the type and it transported successfully.
Final thoughts
Using ABAP OO with my workflows has been a learning experience, which has allowed me to enhance
my knowledge of ABAP OO as well as workflow as more SAP developed workflows go down this
route. As I stated in the first part of this series, I have been comfortable using BOR for many years, and
had to step outside my comfort zone in order to try using ABAP OO. It was not an easy first step, but as
with any new skill, the more you do it the easier and better you become.

ABAP Classes in Workflow
By Anwesha Bhattacharya , Capgemini India from Link

1. ABAP Classes and Business Workflow:
We can use ABAP classes in the definition and runtime components of SAP WebFlow Engine in the
same way as object types defined in the Business object Repository (BOR).
Before proceeding further we need to know where to create and maintain ABAP Classes and ABAP
Interfaces.
2. What is Class Builder and its purpose?
The Class Builder allows us to create and maintain global ABAP classes and interfaces. Both of
these object types, like global data types, are defined in the ABAP Repository, thus composing a central
class library. Together, they form a central class library and are visible throughout the system. We can
display existing classes and interfaces in the class library using the Class Browser.
We can define local classes as well as global classes. They are defined locally in programs, function
groups or as auxiliary classes of global classes of the class pools. Local classes are only visible within the
defining module.

ABAP classes are processed using the Class Builder.

3. How to reach Class Builder?
To reach the initial screen of the Class Builder, choose Development Class Builder from the initial
screen of the ABAP Workbench or enter transaction code SE24.

4. How does it integrate?
The Class Builder allows us to create Web development objects within the ABAP Workbench. We can
use the Class Browser to display and maintain existing global object types from the class library.
The diagram below illustrates the architecture of the Class Builder and the relationships between its
components (including the Class Browser)

From here, we can either display the contents of the class library or edit a class using the Class
Editor. Once we have defined an object type, we can implement its methods. From the initial screen or
the Class Editor, we can also access the Class Builders test environment. We can define the object types
immediately after implementing the method in the ABAP Editor. It is also possible to access the test
environment from the initial screen or Class Editor.
5. How to use the Class Builder?
Use the Class Builder to:
Display an overview (in the Class Browser) of global object types and their relationships.
Maintain existing global classes or interfaces.
Create new global classes and interfaces.
Implement inheritance between global classes.
Create compound interfaces.
Create and specify the attributes, methods, and events of global classes and interfaces.
Define internal types in classes.
Implement methods.
Redefine methods.
Maintain local auxiliary classes.
Test classes or interfaces in a simulated runtime environment.
6. What are the constraints?
We cannot define object types on the basis of graphical object modeling.
7. Note before creating global classes and interfaces:
Global classes and interfaces that we create in the Class Builder are stored in the class library and
administered by the R/3 Repository: they therefore have the same namespace as all other
Repository objects. It is therefore necessary to have naming conventions for object types and their
components and to use them uniformly within program development.
8. Naming Conventions in ABAP Objects:
The following naming convention has been conceived for use within the SAP namespace. If we do not
observe the naming conventions for object types (classes and interfaces), conflicts will occur when the
system creates persistent classes, since it will be unable to generate the necessary co-classes.
9. Conventions for Object Types:
Class in the class library
CL_<class name>

Interfaces in the class library
IF_<interface name>

Local classes in programs
(recommendation)
LCL_<class name>

Local interfaces in programs
(recommendation)
LIF_<interface name>

10. Conventions for Components:
Method name
<method name>

Events
<event name>

Local type definitions within a class
(recommendation)
TY_<type name>

Data definitions (variables)
<variable name>

Data definitions (constants)
(recommendation)
CO_<constant name>

11. Local Conventions within Methods:
For parameters:
IMPORTING parameters IM_<parameter name>
EXPORTING parameters EX_<parameter name>
CHANGING parameters CH_<parameter name>
RESULT RE_<result>
12. Using ABAP Classes in Workflow:
Within the SAP WebFlow Engine we can use ABAP classes that support the IF_WORKFLOW interface.
Classes that have implemented the IF_WORKFLOW interface are recognized as workflow-enabled in the
Class Builder.
13. How to create ABAP Classes that support IF_WORKFLOW interface?
Go to transaction SE24 and create a customized class.

Next the pop up appears where we need to mention the detail as follows:

Save it and the class is created.
Now the class is to implement IF_WORKFLOW interface. For this go to the tab
and declare the IF_WORKFLOW as the interface there and press Enter; two sub-interfaces
appear: BI_OBJECT andBI_PERSISTENT. Save the Class.

The ZCL_TEST class now contains the existing methods of IF_WORKFLOW
interface.

14. Lights on Key Attributes and Attributes:
The key attributes are used to define the object key. There can also be other defined attributes other
than key attributes. The SAP WebFlow Engine can access all public attributes of a class.
Key Attributes:
In the Class Builder there is an additional column Key Attributes on the tab page as shown
below:

We need to check this box when we are defining any attribute as the Key Attribute.
All key fields must be character-type fields (elementary types: CHAR, NUMC) and have a defined length.
The maximum length allowed for all key fields is 32 characters. The length of the key field for the
persistent display is 32 characters.
In the case of persistent ABAP objects we can use the GUID, which is generated automatically by the
object manager when an instance is created.
Attributes:
In addition to all the other data types that the Class Builder supports, we can also define attributes with
reference to an object from the Business Object Repository (BOR). To do this, we have to use the
structureSWOTOBJIDas the data type. The BOR object is determined using the corresponding value.
To assign a BOR object instance to an attribute we need to use the corresponding BOR macros.
Normally, this is implemented within the CONSTRUCTOR of a class.
To use the BOR macros in a class, two INCLUDES must be included.
Include <CNTN03>contains the local types
Include <CNTN02>contains the BOR macros
An example to show how to define Attributes and Key Attributes:

15. Why IF_WORKFLOW Interface?
The IF_WORKFLOW interface is necessary when using an ABAP class within the SAP WebFlow Engine. The
interface contains methods that allow the object to be used within the SAP WebFlow Engine.
The SAP WebFlow Engine handles all objects generically. Objects have to be saved in the event of a
context change. Therefore, it is necessary to convert object references in such a way that they can be
saved persistently. Conversely, we have to be able to generate the corresponding instance of an ABAP
class from the persistently saved key.
There are also a number of SAP WebFlow Engine components, for example, the Workflow Log that can
display objects. In this case the object has to provide corresponding functions.
The IF_WORKFLOW interface puts a logical parenthesis round the BI_PERSISTENT(instance
management) and BI_OBJECT (object behavior) interfaces. The IF_WORKFLOWinterface contains the
following methods:
BI_PERSISTENT~FIND_BY_LPOR
BI_PERSISTENT~LPOR
BI_PERSISTENT~REFRESH
BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE
BI_OBJECT~EXECUTE_DEFAULT_METHOD
BI_OBJECT~RELEASE
A class that implements the IF_WORKFLOW interface can be used in any workflow. The class
is automatically released for use in workflows when the interface is implemented. Therefore, we
can only make compatible changes to a class after implementation (we cannot delete attributes,
change types or delete methods). There is no where-used list to show which workflows the class
is used in.
Internal classes of an application should not implement the IF_WORKFLOW interface, since
this could mean that each method of the class is used in the workflow. Therefore, we should
encapsulate the workflow functions in another class that calls the selected methods of the internal
class.
Each method of the IF_WORKFLOW Interface as mentioned earlier has its distinct
functionality, which is discussed below.
16. BI_PERSISTENT~FIND_BY_LPOR Method:
If we want to convert a persistent saved display of an object into an instance of the corresponding ABAP
class, SAP Webflow Engine calls the BI_PERSISTENT~FIND_BY_LPOR method.
Features:
The method parameter LPOR is the persistent object reference and is of SIBFLPOR structure type. A
reference of BI_PERSISTENT type is returned.

The following table shows the components of the SIBFLPOR structure:

Field Description
CATID Describes the object type ( CL for ABAP classes)
TYPEID ABAP class name
INSTID Object key. The key is limited to 32 characters.

We can implement this method in several ways. In the case of persistent classes we can create the ABAP
object instance using the generated classes. In the case of individual persistence management we have
to implement the individual actions (such as creating an instance, performing an existence check,
entering public attributes, and so on) manually within the class.

Instance management takes place automatically in the case of persistent classes. In the case of
individual persistence management we also have to carry out instance management by class. The SAP
WebFlow Engine does not provide any instance management. We must therefore implement our own
instance management in the case of individual persistence management.

The FIND_BY_LPOR method should always return the same instance if the following problems are to be
avoided:
Inconsistency in the data display
Instance data being overwritten by another instance
Locking conflicts
There is an implementation example in the CL_SWF_FORMABSENC demo class.

17. BI_PERSISTENT~LPOR Method:
The BI_PERSISTENT~LPOR method is the counterpart to the BI_PERSISTENT~FIND_BY_LPOR method. It
provides the persistent display for an existing instance of an ABAP object.
Features:
The method returns the persistent display of an object reference as a SIBFLPOR type structure as
described earlier.
There is a close relationship between the BI_PERSISTENT~FIND_BY_LPOR method and
theBI_PERSISTENT~LPOR method. If we call the BI_PERSISTENT~FIND_BY_LPOR method first and then
theBI_PERSISTENT~LPOR method, the BI_PERSISTENT~LPOR method must return the same value as was
previously used to call the BI_PERSISTENT~FIND_BY_LPOR method.
There are also several ways of implementing this method in this case. There is an implementation
example in the CL_SWF_FORMABSENC demo class.

18. BI_PERSISTENT~REFRESH Method:
SAP WebFlow Engine calls the BI_PERSISTENT~REFRESH method when the system has to ensure that all
values of an object are valid or that they agree exactly with the persistent display of the object.
Features:
The method implementation depends on the internal organization of the class. We can check the object
instance data in the database, if necessary.
If we do not need the method in our class, then we need only to carry out a dummy implementation
(without further coding) to avoid program errors when the system calls the method.
There is an implementation example in the CL_SWF_FORMABSENC demo class.

19. BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE Method:
The BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE method returns the display name of the object.
Features:
We can display references to process objects or process step objects at different positions within
the SAP WebFlow Engine (for example, in Business Workplace and in Workflow Log). The object key is
normally displayed here. If, for example, we want to display a descriptive text instead, the
BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE method has to return the corresponding value.
If the method does not contain implementation or does not return a value, the object key is displayed.
If we do not need the method in our class, then we need only to carry out a dummy implementation
(without further coding) to avoid program errors when the system calls the method.
There is an implementation example in the CL_SWF_FORMABSENC demo class.

20. BI_OBJECT~EXECUTE_DEFAULT_METHOD Method:
The BI_OBJECT~EXECUTE_DEFAULT_METHOD method is the standard method for the object. This
method is executed when, for example, we call the object in Business Workplace.
Features:
We can display process objects or process step objects at different positions within the SAP WebFlow
Engine(for example, in Business Workplace and in Workflow Log). The SAP WebFlow Engine calls the
BI_OBJECT~EXECUTE_DEFAULT_METHOD method.
If we do not need the method in our class, then we need only to carry out a dummy implementation
(without further coding) to avoid program errors when the system calls the method.
There is an implementation example in the CL_SWF_FORMABSENC demo class.

21. BI_OBJECT~RELEASE Method:
The system indicates that the reference to the instance is no longer needed by using
theBI_OBJECT~RELEASE method. This means we can delete the reference from instance management.
Once the last reference has been deleted from instance management, the GARBAGE COLLECTOR can
release the corresponding memory area.
Features:
If we do not need the method in our class, then we need only to carry out a dummy implementation
(without further coding) to avoid program errors when the system calls the method.
There is an implementation example in the CL_SWF_FORMABSENC demo class.

22. How to use ABAP Classes in Process Steps of Business Workflow?
In process steps we can use methods and attributes of ABAP classes in the same way as methods and
attributes of Business Object Repository (BOR) objects. We can call these methods in the process
context.
Features:
While using the ABAP Classes in the Process Steps the methods may contain dialogs, they can be
synchronous or asynchronous; they may appear in the workflow log, and so on.
In general, we can use any method that is implemented as a public method. The method can be
implemented in the class itself, in one of the super classes of the class, or by way of an interface.
The maximum permitted length for methods that are implemented by way of an interface, for
exampleIF_WORKFLOW~FIND_BY_LPOR, is 30 characters. If the method name is too long, we can
choose a shorter name for the method by defining an alias. If the method is implemented in the class or
in a super class, the name of the method cannot be longer than 30 characters, so this limitation does not
apply.
Parameters:
We can assign values from the workflow container to the method parameters. Conversely, export
parameters can be entered as workflow container values. The following overview shows how the
individual types can be used as parameters:
Simple types (string, integer, and so on)
Data Dictionary types (structures, tables, complex types)
References to objects from the Business Object Repository
References to ABAP classes (supporting the IF_WORKFLOW interface)
We can transfer method parameters that represent a persistent object (IF_WORKFLOW or BOR Object)
in the following ways:
ABAP classes (with IF_WORKFLOW interface)
TYPE SIBFLPORB
Object is transferred using the persistent display
TYPE REF TO <Class name>
Object is transferred as object reference
BOR objects
TYPE SIBFLPORB
Object is transferred using the persistent display
TYPE SWOTOBJID
Object is transferred using the persistent display; this display is only valid for BOR objects
TYPE SWC_OBJECT
Object is transferred as object reference
Exceptions:
The SAP WebFlow Engine can deal with exceptions that are triggered by the methods. It
differentiates between application exceptions and temporary exceptions. The two exception categories
are differentiated by the exception in the class hierarchy or by naming conventions. In the case of a
temporary exception, the SAP WebFlow Engine attempts to execute the method again. In the case of
a permanent error the status for the workflow is set to error.
Class-Based Exceptions:
To create a temporary exception, we can use, for example, the CX_BO_TEMPORARY class or a
corresponding subclass. It can be helpful to trigger an exception for dialog methods when the user
cancels the dialog. Here, for example, we could trigger the CX_BO_ACTION_CANCELED exception
(subclass of theCX_BO_TEMPORARY class).
Exceptions Not Based on Class:
We can also trigger exceptions not based on class. The SAP WebFlow Engine can differentiate between
the two exception categories (temporary and permanent) by the name. If the exception begins with
TMP or TEMP, it is a temporary exception; otherwise it is a permanent exception.

http://sapabap.iteye.com/blog