[LIKELY JUNK]Re: RE: ABAP-OO Workflow for PO-release
Florin Wach
florin.wach at gmx.net
Fri May 16 03:38:19 EDT 2008
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
More information about the SAP-WUG
mailing list