Feedback of ABAP-OO Workflow Implementation

[Florin Wach]

Hi again, Wuggies,

this is the second feedback of what's up with ABAP-OO Workflow. In generally it's still the same as with my very first feedback, but as I have encountered some other smaller issues, I'd like to summarize this now and finish this issue:

Overview:
Good:
1) Background tasks can be replaced by container opertaion (if feasable).
2) "System wide delegation" has been well transformed into object oriented...
3) ABAP-OO Integration into Event creation
4) Use a method to process an event
5) Implementation with ABAP classes

Not-so-good:
1) Event couplings
2) Implementation from scratch
3) Not well-defined interfaces
4) Performance is low
5) Modeled result exception is complicated to implemented, plus a little buggy

Bad:
1) Workflow builder dumps
2) Interfaces are not supported by Workflow runtime system
3) Again: Derivation and events makes problems
4) Program errors during conditions or container operation are not logged


-------------------------------------------------------------

The GOOD side:

1) Background tasks can be replaced by container opertaion (if feasable).

   Background tasks that previously had to calculate or evaluate something to put that back into container variables can now be eliminated with Object methods, having a "returning" parameter and use them in a container operation. This is much more convenient.


2) "System wide delegation" has been well transformed into object oriented class hierarchy.

   Passing a kind-of an object into an existing workflow (previously "subtyping with system-wide delegation" works, including polymorphism (see also "bad side")


3) ABAP-OO Integration into Event creation through change documents (and event linkages)
   Event creation through change documents with OO-events works fine (ECC 700).


4) Use a method to process an event

   There's a new receiver type, using a class method (instead of a function module). This could be a very nice feature, though I haven't use it, yet.


5) Implementation with ABAP classes

   And finally, when starting to implement with ABAP Object classes, you'll start to structurize your solution much better (as you really have to), and, as many previous functionality from Business Objects is not (yet) implemented in the SAP Standard, you have the opportunity, to re-code the whole stuff. Which can be delightful.



The NOT-SO-GOOD side:

1) Event couplings

   Event coupling with BOR objects needs some care but then can be used fine


2) Implementation from scratch

   Additional work is involved, when there's no existing object to derive from to be used in the workflow. Do not underestimate this issue, as it easily can blow up your given budget by a 100%. On the outcome, you'll have a nice new solution w/o curious relics.


3) Not well-defined interfaces

   In Check/Receiver type function modules the object instance is passed based on a different structure than the instance constructor requires (well, basically there isn't an object instance passed at all, but only a static reference). Also, I wonder, why not an instance in the form of TYPE REF TO IF_WORKFLOW is passed.


4) Performance is low

This was probably the most suprising issue, that I have experienced that the workflow runtime is /significantly/ slower than when using the business object implementation. Every step seems to me to use double time. The most expensive action seems to be the first workflow instantiation.


5) Modeled result exception is complicated to implemented, plus a little buggy

With the business object's method you could define exceptions for a method and mark them as System, Application or Temporary exceptions. Each single exception gave a new outcome in the workflow builder, and you can activate this single by single.
The ABAP-Objects implementation uses exception classes, where you have one base class for each kind of exception type. You can either use the generic ones, or you have to create a new subclass of the correct super class, implement the message that shall be shown in the detailed log, etc. So for each new exception, you'll need to implement a whole new class. Whew, that's much effort.
Furthermore, if you have several different exceptions (e.g. based on all the same super class, such as "Temporary") the different outcomes are not processed. They're just all "Temporary".


The BAD side:

1) Workflow builder dumps

   When changing the referenced object type in a task or workflow container or when changing an interface/class within the same session, the workflow builders tends to short dumps. (but it's recoverable). When working with the Object Navigator (SE80) I always edit workflow patterns by using a right click and choose "Display in new window". This way, the class definitions are loaded anew.


2) Interfaces are not supported by Workflow runtime system

   Methods, attributes and events inherited from Interface are not recognized at all (workflow builder, runtime system, event coupling), when the interface's name does not start with IF_. This is a big showstopper that gives restrictions to the Object Model Design. So you have to get back to the design of having a single super-class, that includes all necessary functions from the interfaces (that you'd use instead).
This is described in SAP Note #971513


3) Again: Derivation and events makes problems

   Events inherited from superclasses that do not start with CL_ are not recognized at all (though methods and attributes do). So here's some class-definition inspection missing.
This is described in SAP Note #971513


4) Program errors during conditions or container operation are not logged

While it is very nice to use function methods (with a "returning" element), and assign the result to a container element or use that as a comparison base in a condition, it dies silently, when there's an exception during the processing of the method. Just all exceptions are catched generically and there's no result logged in the workflow detail log. So if the result of such an operation is "empty", you just don't know, what has happend and what's going wrong, unless you deeply debug.


-----------------------------------------------------------------------

Summary

So finally the bad-sides are not /that/ bad, not to use the ABAP-OO Workflow. If you know them, you can find workarounds for them. A more drawback is the restriction to the class design that you have, when working with the integration here. For all of the rest, it's very fine to use, so I would everyone encourage to gather more experiences using ABAP-OO Workflow.

Thanks to Jocelyn to share the ABAP OO implementation guidline (see threads here in the WUG) and many others that gave feedback here or helped in certain situations with the implementation.

Have fun, take care.
   Florin