Why use Object Oriented ABAP 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.