ABAP-OO Workflow for PO-release

Sat May 10 01:21:40 EDT 2008

Hi Florin,
Thanks for the input.
Couple of comments:
Regarding check/receiver FMs, are you sure you're using the newer version?
Based on something named "...CHECK_FB2" or something like that. Actually
I'm not 100% sure I understand what you're saying....
The 'bad sides' sound like bugs, would suggest reporting the first one for
sure.
I've used ZIF_ interfaces without a problem on a 620 system. Though I
later abandoned the idea of using interfaces for different reasons
relating to 620 limitations.
Events are one of the lesser-developed areas of workflow classes. Log it
with OSS...

Cheers,
Mike

On Thu, May 8, 2008 7:50 am, Florin Wach wrote:
> Hi Folk,
>
> this is a first feedback of what's up with ABAP PO-Workflow:
>
> The good side:
> - 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. This is much more
> convenient.
> - Passing a kind-of an object into an existing workflow (previously
> "subtyping with system-wide delegation" works, including polymorphism (see
> also "bad side")
> - Event creation through change documents with OO-events works fine (ECC
> 700)
>
> The not-so-good-side:
> - Event coupling with BOR objects needs some care but then can be used
> fine
> - Some additional work is involved, when there's no existing object to
> derive from to be used in the workflow
> - 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)
>
>
> The bad side:
> - 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)
> - 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_
> - Events inherited from superclasses that do not start with CL_ are not
> recognized at all (though methods and attributes do)
>
>
> So, that's for a quick feedback. More thumbs up than down.
>
> Best wishes,
> Florin
>
> -------- Original-Nachricht --------
>> Datum: Tue, 22 Apr 2008 12:12:58 +0800
>> Von: "Dart, Jocelyn" <jocelyn.dart at sap.com>
>> An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>
>> Betreff: RE: ABAP-OO Workflow for PO-release
>
>> Mike,
>> The equivalent of "Create subtype" for ABAP OO classes, is to create
>> your
>> class and then in the Properties tab nominate your Superclass.
>>
>> Delegation is unnecessary because narrowing/widening cast means you can
>> move between parent and child freely.
>> Regards,
>> Jocelyn
>>
>> ________________________________
>>
>> From: sap-wug-bounces at mit.edu on behalf of Mike Pokraka
>> Sent: Mon 21/04/2008 9:20 PM
>> To: SAP Workflow Users' Group
>> Subject: Re: ABAP-OO Workflow for PO-release
>>
>>
>>
>> On Fri, April 18, 2008 7:56 am, Kjetil Kilhavn wrote:
>> > This is interesting (well, anything from a SAP employee who has proven
>> OK I may not be a SAP Employee so take my input with a grain of salt..
>>
>> > However, I have assumed that for existing BOR objects it would be
>> easier
>> to
>> > implement additional methods (and redefine methods) in a BOR object
>> type
>> which would then be delegated to.
>> >
>> It's a little more work to create the class up front - there's no
>> "Create
>> Subclass" button. But once that's in place I find it easier to add
>> additional methods. See my other post to Sherie.
>>
>>
>> > Would you recommend that even for a small change such as the
>> additional
>> attribute I've added to USR01?
>> > Such a strategy would mean the workflow becomes a mixture of tasks
>> using
>> BOR
>> > objects and class objects.
>> >
>> Yes, and yes. Actually in many cases I've done away with the BORs
>> because
>> it's a 10 minute job to add the two or three BOR components I actually
>> need into my class. The icing on the cake is being able to bind
>> _WI_ACTUAL_AGENT via functional method straight into an instance of
>> ZCL_WF_USER.
>>
>> > I see you recommend adding an attribute to the class to reference the
>> BOR
>> > object when needed. Would you recommend also adding a class object
>> reference
>> > as an attribute to a delegated BOR object type - or how would you
>> approach
>> > the need for crossing from one object type to the other.
>> Unfortunately it only works one way - BORs can't have class attributes.
>> Usually I end up working with both, which is not really a big issue.
>>
>> > --
>> > Kjetil Kilhavn (+47 40220607)
>> > Blue Consulting AS (http://www.bluec.no/)
>> > _______________________________________________
>> > 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
>