ABAP-OO Workflow for PO-release
Florin Wach
florin.wach at gmx.net
Thu May 15 09:29:07 EDT 2008
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
More information about the SAP-WUG
mailing list