Feedback of ABAP-OO Workflow Implementation

Tue Jul 1 05:23:52 EDT 2008

I will keep a lookout and report back.

@Florin: This would be a perfect post to put on SDN as a Wiki, so we can
all put in our experiences...

Also see some discussions about OO vs BOR performances in here a while
back. Basically the way you implement OO has a much bigger impact on
performance than in BOR. Unfortunately due to some of the OO design you're
forced to load much more than in the BOR days - e.g. I'm doing a
BAPI_READ_WHATEVER in some of my instantiations - performance tradeoff for
stability. BOR reads tables, and in many cases doesn't read those until
much later on.

Cheers,
Mike

On Tue, July 1, 2008 1:11 am, Alon Raskin wrote:
> 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
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>