How do I know I'm ready for this?
This is number 7 in a series of blogs on ABAP OO for workflow, so you it would be a really good idea to make sure you have worked through the first 6 blogs. The examples we'll use here continue on from those we used in the earlier blogs.
Here's the list of the earlier blogs:
- Why use ABAP OO with Workflow?
- Getting started with ABAP OO for Workflow ... using the IF_WORKFLOW interface
- Using ABAP OO with Workflow Tasks
- Raising ABAP OO events for Workflow
- Using ABAP OO attributes in Workflows and Tasks
- Using functional methods in Workflows and Tasks
Which is better ABAP OO or BOR?
Clearly ABAP OO is far superior to BOR - much quicker for development, much more flexible, much less specialized - but if you are still asking this question now might be good time to go back and read the first blog "Why Use ABAP OO with Workflow?"
Why would you need to use BOR and ABAP OO together?
The main reason for using BOR and ABAP OO together is to access provided SAP business objects for the content. Although newer workflows are now being written using ABAP OO for Workflow - such as Leave Request/Cancellation, and HR Admin Services forms - much of the existing content was originally written using BOR and has not yet been converted to ABAP OO. Whether BOR content is ever converted to ABAP OO depends on the priorities of the specific development area so you should NOT wait for old content to be converted.
A secondary reason is because even though you are mainly working in ABAP OO you still want to raise events using a technique that does not yet support ABAP OO for Workflow. E.g. Status management events do not provide an ABAP OO option as yet (SAP NetWeaver 7.00 - July 2007).
How do you access a BOR object from an ABAP OO class?
The best approach is to access the BOR object as an attribute of your ABAP OO class. For our ZCL_PLANT example we have been using in the previous blogs, there is an older equivalent BOR object BUS0008. To link the BOR object to our ZCL_PLANT class we need to:
- Create a constant with a prefilled type for the BOR object
- Create an attribute for our BOR object
- Fill the attribute value at runtime with the key of the BOR instance
- Reference the BOR object in our workflows/tasks
A constant is just an attribute of a class with the level "Constant" (instead of "Instance" or "Static"). The prefilled type can be created in a number of ways - you could use a type-pool or just use a direct entry type. A type-pool has the advantage of allowing you to collect all such prefilled types into one place, however for our example a direct entry type is adequate.
Here you see the constant C_BO_BUS0008 as an attribute of the example class ZCL_PLANT. By pressing the "Direct Type Entry" button we see the initial code: constants C_BO_BUS0008 value . "#EC NOTEXT
We need to change this to match the structure of the dictionary type SIBFLPORB but with the category always set to "BO" (BOR object) and the type always set to "BUS0008" (our chosen BOR object type). Of course the instance is left empty as we will not know the key value of our BOR object until runtime. CONSTANTS: BEGIN OF c_bo_bus0008, instid TYPE sibfboriid VALUE IS INITIAL, typeid TYPE sibftypeid VALUE 'BUS0008', catid TYPE sibfcatid VALUE 'BO', END OF c_bo_bus0008.
The attribute must use the dictionary type SIBFLPORB. Use your constant as the initial value of your attribute.
Note: This initial value is critical to using the BOR object in workflows and tasks. Without it, workflows and tasks will not be able to guarantee what BOR type will be available at runtime, and will therefore only be able to access the generic attributes/methods of the root BOR object OBJECT, instead of the attributes/methods of the chosen BOR object type.
Referencing the BOR object in your workflows and tasks is just the same as referencing an attribute of an ABAP OO for Workflow object. So this is the easy part.
Do I still need to use BOR macros in ABAP OO classes?
You will still need to use BOR macros in your ABAP OO classes if and only if you want to call BOR attributes and methods in your ABAP OO methods.
If you need to do this then make sure you include the BOR macro definitions in your class by putting the special include program <cntn02> in the "Macros" section of your ABAP OO class. You can then use the usual workflow macros such as swc_get_property and swc_call_method in your ABAP OO methods. Note: I'm not going to discuss the use of these macros here - there's plenty of existing material and tutorials in the SAP Library help, in published books on SAP Workflow and in SDN blogs and forums.
Should I extend & delegate BOR objects - or do all my extensions in ABAP OO?
Having worked with both BOR and ABAP OO for Workflow for some time now, my strong recommendation would be to do all extensions in ABAP OO. The only exception to this is additional events on BOR objects if you are stuck with using BOR objects for eventing.
I have even found it quicker and more effective to rewrite some of the provided SAP content in ABAP OO rather than use the existing content. For example the EMPLOYEET and BUS1065 employee objects both use HR Structural Authorizations, which is often more of a hindrance than a help in workflows where workflow heavily controls access to the data anyway. So I have often created my own ZCL_EMPLOYEE class to provide equivalent functionality using function module BAPI_EMPLOYEE_GETDATA to extract the necessary employee details, and which gives the option of bypassing the HR Structural Authorizations where appropriate.
What do I do about existing workflows based on BOR?
There's no need to convert existing workflows as such. However if you need to create a new workflow or make extensive changes to an existing workflow I would strongly recommend you consider converting to ABAP OO.
If you are part of an upgrade project this is always a good time to consider reworking from BOR to ABAP OO, if only to widen the pool of developers able to maintain code called by your workflow - as of course any ABAP OO developer can work with ABAP OO for workflow.