Feedback of ABAP-OO Workflow Implementation

[Alon Raskin]

It would be interesting to hear from anyone else who has used OO in WF if they had the same experience...

Alon Raskin
e: araskin at 3i-consulting.com

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Florin Wach (gmx)
Sent: Monday, June 30, 2008 4:50 PM
To: SAP Workflow Users' Group
Subject: Re: Feedback of ABAP-OO Workflow Implementation

It takes about 10 sec. for the workflow instance to be created (instead of
3).
The background work items are processed more slowly, etc.
It just seems, that everything is a tick slower :-)

----- Original Message -----
From: "Alon Raskin" <araskin at 3i-consulting.com>
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Sent: Monday, June 30, 2008 9:11 PM
Subject: RE: Feedback of ABAP-OO Workflow Implementation


> In what way was the performance poor?
>
> Alon Raskin
> e: araskin at 3i-consulting.com
> p: +1 800 405 8605
>
> ________________________________________
> From: sap-wug-bounces at mit.edu [sap-wug-bounces at mit.edu] On Behalf Of
> Florin Wach [florin.wach at gmx.net]
> Sent: Monday, June 30, 2008 8:45 AM
> To: SAP Workflow Users' Group
> Subject: Feedback of ABAP-OO Workflow Implementation
>
> 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
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug