Why use ABAP OO with Workflow?

How do I know this is relevant to me?

ABAP OO for workflow is available on any SAP NetWeaver platform release 6.20 or above (ABAP stack of course). That includes R/3 4.7, ECC, and the latest versions of SCM, SRM, CRM, xRPM, etc. P.S. There are a couple of minor restrictions in 6.20 that are resolved in 6.40 – but we’ll deal with them later in the series.

What’s the problem with BOR (Business Object Repository)?

A little SAP/Workflow history here… SAP Business Workflow came into being in R/3 3.0C. Now for those who can remember back that far, there certainly wasn’t any such thing as ABAP OO back then (and it wouldn’t be until R/3 4.6C that ABAP OO was available in sufficient depth to support workflow handling). So the Business Object Repository was created as an intermediate, very approximate, but at least object-oriented, solution for SAP Business Workflow. Because it was never intended to be the final solution, there was a limit to how far BOR was going to go. Consequently BOR suffers from:

A very old ABAP editor and relatively feature-poor support tools

Awkward and non-obvious macro coding necessitating workflow developers to have special skills above and beyond normal ABAPers or workflow creators

Limitations for instantiation, inheritance, generic handling, and calculation of attributes

How does ABAP OO solve these problems?

Well for starters, ABAP OO is now a fully-fledged object-oriented language with comprehensive feature-rich support tools. ABAP OO also provides:

Functional methods for calculation of attributes

Proper instantiation and garbage collection

Complex inheritance options

High reusability for true generic handling of objects

What other reasons are there for using ABAP OO with workflow?

I’ve saved the best for last because ABAP OO for workflow means: Any ABAP developer who can code ABAP OO can (after reading this series) code for workflow. So now project managers and workflow creators can call on any ABAP programmer to assist with custom development for workflow – you won’t need a specially-trained workflow code-cutter any more.

Is there anything I still need to use BOR for?

There are a few areas where you might still want to use BOR objects – purely for convenience reasons.

The SELFITEM object for sending mails. This is still useful as everything, including the “Send Mail” step type, is pre-built for you. So it’s probably not worth creating an ABAP OO equivalent.

The DECISION object – for user decisions. There’s a lot of special functionality around this object for simple question/answer decisions – especially if you are using the UWL.

Generic Object Services – a lot of transactions still link to BOR objects – so it can be worth referencing the BOR object to keep the Workflow Overview feature going.

BOR events from standard transactions – a lot of transactions that have inbuilt workflow coding that raises BOR events – so it’s still handy to reference BOR objects in your ABAP OO classes for these scenarios too.

And of course there’s a fair bit of business content in provided BOR objects you might want to reuse.

Coming Attractions…

Over the coming series we’ll be discussing

Getting started… using the IF_WORKFLOW interface

Using ABAP OO methods in workflow tasks

Raising ABAP OO events for workflow

Using ABAP OO attributes in workflows and tasks

Using functional methods in workflows and tasks

Referencing BOR objects in ABAP OO classes

So there’ll soon be plenty of help to get you going. In the meantime, make sure you get involved in the Business Process Management forum.

I’m not a workflow/”webflow”, nor an OO, expert but I had wondered recently why the BOR didn’t apear to use the OO concepts that had been introduced in ABAP. So, it was great to have it pointed out that it’s now possible and a little about why the older versions of BOR weren’t so OO equiped.

Had a “development” task the other day to create material batches based on plant material creation and in the end managed to use my 4.6c workflow to do this with only about 6 lines of ABAP coding (in the end I decided I needed a little bit of code to read a change document during the event trigger and extract the plant code for the event container to pass to the worfkflow task that creates a material batch). The SAP Press book about webflow as a great help in this process, in addition to parts of the normal SAP Help.

In your blog series on ABAP OO and workfow, you mentioned some advantages of ABAP OO rather than BOR. I still got one concern on application-specific content. I check the system and find that there are many pre-defined application-specific content for workflow and BOR but not for ABAP OO. Will application-specific content will be delivered in the near future for ABAP OO part? As there are many codings already in BOR, will there be any conversion tool from BOR to ABAP OO in plan?If currently customer would like to implement workflow in ECC system only and does not have much additional coding requirements, which one you would recommend, ABAP OO or BOR?

Hi Lane, What you will find is that new systems and new workflows are now starting to use ABAP OO for workflow. For instance I have noticed HR Life and Work Events have delivered some ABAP OO for Workflow classes, and I just noticed the other day that xRPM is now doing the same. So you should hopefully see all/most future content delivered with ABAP OO.

As for existing content, as usually happens when we introduce new techniques, converting old content is slower, tends to happen on a case-by-case basis, and usually only happens when new/revised content for that area is delivered. My hope is that this blog series will speed the process up, but for some time to come I expect we will be dealing with a mix of BOR and ABAP OO.

Based on my experience in recent projects, I would definitely do all new coding in ABAP OO if you have a 6.20/6.40 or higher environment such as ECC. It’s so much quicker. For existing BOR objects you can get away with just using a delegated subtype for any extra events you want to raise (as the application that raises the events is usually tied to the BOR object), and then put any additional attributes and methods in an ABAP OO class that represents the same object.

It means that you start your workflow using a BOR object event, and then first step is to run a CREATEINSTANCE method to convert it to your ABAP OO class, but that is a relatively smally price to pay for the ease and convenience of doing the rest of your coding in ABAP OO. Especially given the advantages of being able to give the ABAP OO code to any ABAP programmer to maintain.

Later in the series I’ll show how to link your BOR object as an attribute of your ABAP OO object, which makes life easier for mixed BOR/OO scenarios.

At one site, we actually created our own event receiver function module to convert the BOR event to an ABAP OO event, which is a very neat solution but not something I’d advocate for most sites simply because the coding of the receiver function module was a little complex.

Hi Jos,you are reading my mind by coming up with this series. Exactly what I need to know as I need to know it. I’ll buy you a coffee and pick your brain sometime soon.CheersGrahamp.s. Loved the holiday snaps.