[LIKELY JUNK]Re: RE: ABAP-OO Workflow for PO-release

Mike Pokraka wug at workflowconnections.com
Fri May 16 09:51:35 EDT 2008 

Hi Forin,

Functional methods do the job very nicely for instantiation. I use a
utility class with a singleton instance - as Jocelyn described - to do
class instantiation in container operation or even during binding (e.g.
binding a WF agent to a user class instance).

Cheers,
Mike

On Fri, May 16, 2008 8:38 am, Florin Wach wrote:
> Ho,
>
> I found out that it worked with one class, while it didn't worked with
> another.
> Mayhaps there's a problem when returning a "Type Ref To" instead of a more
> simple type (e.g. table types worked fine).
> Both classes were not instantiated before, so that shouldn't be the cause
> of it.
>
> As I'm using a task now for instantiation (and time is running short in
> the project), I'll stick to that ;-)
>
> Thanks Jocelyn.
>
> Florin
>
> -------- Original-Nachricht --------
>> Datum: Fri, 16 May 2008 13:01:41 +0800
>> Von: "Dart, Jocelyn" <jocelyn.dart at sap.com>
>> An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>
>> Betreff: RE: [LIKELY JUNK]Re: RE: ABAP-OO Workflow for PO-release
>
>> Florin,
>> Hmmmm....
>>
>> Even with a static method call you still have to have a valid handle for
>> the class.  The problem with static method calls from within expressions
>> is often the handle has not yet been generated.   The workflow task
>> takes care of the handle for you which is why it works there.
>>
>> I have used a form of singleton instantiation for utility classes with
>> static methods by using Initial Values in the relevant workflow
>> container element to make sure the handle is created on workflow
>> creation.  Something to try perhaps.
>>
>>
>> Regards,
>> Jocelyn Dart
>> Senior Consultant
>> SAP Australia Pty Ltd.
>> Level 1/168 Walker St.
>> North Sydney
>> NSW, 2060
>> Australia
>> T   +61 412 390 267
>> M   + 61 412 390 267
>> E   jocelyn.dart at sap.com
>> http://www.sap.com
>>
>> The information contained in or attached to this electronic transmission
>> is confidential and may be legally privileged. It is intended only for
>> the person or entity to which it is addressed. If you are not the
>> intended recipient, you are hereby notified that any distribution,
>> copying, review, retransmission, dissemination or other use of this
>> electronic transmission or the information contained in it is strictly
>> prohibited. If you have received this electronic transmission in error,
>> please immediately contact the sender to arrange for the return of the
>> original documents.
>> Electronic transmission cannot be guaranteed to be secure and
>> accordingly, the sender does not accept liability for any such data
>> corruption, interception, unauthorized amendment, viruses, delays or the
>> consequences thereof.
>> Any views expressed in this electronic transmission are those of the
>> individual sender, except where the message states otherwise and the
>> sender is authorized to state them to be the views of SAP AG or any of
>> its subsidiaries. SAP AG, its subsidiaries, and their directors,
>> officers and employees make no representation nor accept any liability
>> for the accuracy or completeness of the views or information contained
>> herein. Please be aware that the furnishing of any pricing information/
>> business proposal herein is indicative only, is subject to change and
>> shall not be construed as an offer or as constituting a binding
>> agreement on the part of SAP AG or any of its subsidiaries to enter into
>> any relationship, unless otherwise expressly stated.
>>
>>
>> -----Original Message-----
>> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
>> Of Florin Wach
>> Sent: Thursday, 15 May 2008 11:29 PM
>> To: SAP Workflow Users' Group
>> Subject: [LIKELY JUNK]Re: RE: ABAP-OO Workflow for PO-release
>>
>> Hi Mike,
>>
>>
>> ------ Check/Receiver FM for ABAP OO-Workflow
>>
>> the new interface, well, at least it's a newer one has the following
>> interface (for event/check receiver-FM):
>>
>> *"     VALUE(SENDER) TYPE  SIBFLPORB
>> *"     VALUE(EVENT) TYPE  SIBFEVENT
>> *"     VALUE(RECTYPE) TYPE  SWFERECTYP
>> *"     VALUE(HANDLER) TYPE  SIBFLPORB
>> *"     VALUE(EXCEPTIONS_ALLOWED) TYPE  SWEFLAGS-EXC_OK DEFAULT SPACE
>> *"     VALUE(XML_SIZE) TYPE  SWF_XMLSIZ
>> *"     VALUE(EVENT_CONTAINER) TYPE  SWF_XMLCNT
>>
>> This looks kind of a compatible :-) interface to OO. Just that there's
>> no TYPE REF TO IF_WORKFLOW or something is passed as an instance.
>>
>> Also the event_container is not passed as ABAP OO. Use the following
>> code for instantiation:
>>
>>    DATA: container         TYPE REF TO if_swf_cnt_container.
>>    container = cl_swf_cnt_container=>create_from_XML(
>>                       XML_Table         = event_container
>>                       XML_Rendered_Size = XML_Size ).
>>
>>
>> --------- Interfaces
>> Well, I have received OSS-Note #971513 Enhancement concept in SAP
>> Business Workflow
>>
>> This note says basically: There's something missing, but we don't tell
>> you, what exactly  :-)
>>
>>
>>
>> --------- Further restrictions found
>>
>> Static object methods cannot be used as expressions in container
>> operations.
>> The matchode list them correctly and the syntax check is okay, but the
>> function just isn't executed.
>> The problem is, that instead of using the   Instance->method() form, you
>> had to use  ObjectType=>method()  form. And I guess, that this part is
>> just missing.
>>
>> Calling static methods (e.g.  get_instance() ) within a workflow task
>> works correctly!
>>
>>
>> The workflow wizard "Create object instance" cannot work with ABAP OO
>> classes.
>>
>>
>>
>>
>>
>>
>>
>> -------- Original-Nachricht --------
>> > Datum: Sat, 10 May 2008 06:21:40 +0100 (BST)
>> > Von: "Mike Pokraka" <wug at workflowconnections.com>
>> > An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>
>> > Betreff: Re: RE: ABAP-OO Workflow for PO-release
>>
>> > 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
>> > >
>> >
>> >
>> > _______________________________________________
>> > 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
>

More information about the SAP-WUG mailing list