Feedback of ABAP-OO Workflow Implementation

[Mike Pokraka]

Found it:
http://mailman.mit.edu/pipermail/sap-wug/2008-March/thread.html
Have a look a the thread titled "Performance of OO vs BOR as used in WF"

Thanks again for the *excellent* feedback.

Cheers,
Mike


On Mon, June 30, 2008 2:45 pm, Florin Wach wrote:
> 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
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>