Have you heard about persistent and runtime references? What do they mean? Why do SAP requires both persistent and runtime reference? How do they affect the way we program the workflow? If you have these questions in your mind then you should continue reading this blog.   *What is persistent and runtime object references?*   In workflow runtime, BOR objects are represented by SWC_OBJECT variables. However, in order to save object references in the database and transport them beyond session limits, persistent object reference variables of the ABAP type SWOTOBJID are used.

  *Why do SAP requires both persistent and runtime reference?*   The workflow system stores object references in the container. These object references must be saved in the database whenever there is a context change (switch from one step to the next). This mechanism ensures the workflow can be restarted in case of server down or system crash using transaction SWPC. For this purpose, the workflow system converts the object references in the container from the runtime representation (blue areas) to the persistent representation (green areas) and back again, as required.

BOR /Application Runtime SWC_OBJECT

Persistent object reference WF/Class SWOTOBJID

http://www.itpsap.com/blog/2014/08/20/using-abap-oo-in-your-custom-workflow-part-1/

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 aren’t 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.

Advantage of ABAP OO on BOR:

There are a number of benefits of moving from the BOR to ABAP OO:

ABAP OO code can be maintained by any ABAP programmer and does not require a

specialist workflow programmer.

ABAP OO code can be used in workflow and non-workflow programs by non-workflow

programmers

Improved coding support features such as forward navigation, proper separation and

identification of different attribute types

Improved clarity (as a result of enforced coding standards – e.g. TABLES statements and

internal tables without header lines are not allowed)

Utility functions are quicker to develop in ABAP OO

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 examples as

well as how to create events and start workflows using ABAP OO.

http://www.itpsap.com/blog/2014/08/20/abap-oo-in-your-custom-workflow-part-2/

Using ABAP Object Oriented Coding in your Custom WorkflowIn 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 with

IF_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.  The BI_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.

So that an instance can be created, a CONSTRUCTOR method (or SUPERCONSTRUCTOR if using

static classes) must be created. This will be used by BI_PERSISTENT~FIND_BY_LPOR to convert from

the workflow business object reference to the ABAP Class instance.

Examples of ABAP Classes for workflow are:

• Class CL_SWF_FORMABSENC (6.40 and above)

• Any class implementing IF_WORKFLOW (Where-used list on interface IF_WORKFLOW)

Once the interface has been added, you need to open each method inherited from IF_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 LPOR methods, 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 event START_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 like

SWE_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 method GET_EVENT_CONTAINER to return

the definition from the event, and/or SET_EVENT_CONTAINER to populate the event container

parameters.

 

 

 Now enter the below code in REGISTER_EMPLOYEE method.

REGISTER_EMPLOYEE

method REGISTER_EMPLOYEE.

* Data DeclarationsDATA: lv_objtype    TYPE sibftypeid,lv_event            TYPE sibfevent,lv_objkey           TYPE sibfinstid,lr_event_parameters TYPE REF TO if_swf_ifs_parameter_container,lv_param_name       TYPE swfdname,lv_id               TYPE char10.

* Setting values of Event Namelv_objtype = 'ZCL_WF_DEMO'. " Your Class Namelv_event   = 'REGISTER'.  " Event Name.

* Instantiate an empty event containerCALL METHOD cl_swf_evt_event=>get_event_container

EXPORTINGim_objcateg  = cl_swf_evt_event=>mc_objcateg_clim_objtype   = lv_objtypeim_event     = lv_eventRECEIVINGre_reference = lr_event_parameters.

* Set up the name/value pair to be added to the containerlv_param_name  = 'EMPID'.  " parameter name of the event

REGISTER_EMPLOYEE

lv_id          = i_empid.

* Add the name/value pair to the event conainerTRY.CALL METHOD lr_event_parameters->setEXPORTINGname  = lv_param_namevalue = lv_id.

CATCH cx_swf_cnt_cont_access_denied .CATCH cx_swf_cnt_elem_access_denied .CATCH cx_swf_cnt_elem_not_found .CATCH cx_swf_cnt_elem_type_conflict .CATCH cx_swf_cnt_unit_type_conflict .CATCH cx_swf_cnt_elem_def_invalid .CATCH cx_swf_cnt_container .ENDTRY.

* Raise the event passing the prepared event containerTRY.CALL METHOD cl_swf_evt_event=>raiseEXPORTINGim_objcateg        = cl_swf_evt_event=>mc_objcateg_clim_objtype         = lv_objtypeim_event           = lv_eventim_objkey          = lv_objkeyim_event_container = lr_event_parameters.CATCH cx_swf_evt_invalid_objtype .CATCH cx_swf_evt_invalid_event .ENDTRY.

COMMIT WORK.  

endmethod.

 

 

 

 

 

 

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 aren’t 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.

 http://www.itpsap.com/blog/2014/08/20/abap-oo-in-your-custom-workflow-part-3/

ABAP Object Oriented Coding and Workflow BOR IntegrationIn 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 &TricksLastly 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.