ABAP-OO Workflow for PO-release

Mon Apr 21 08:47:00 EDT 2008

Follow-Up Regarding BOR, GOS and event couplings

Hi,
we've now decided to go through the ABAP-OO development for the redesign. But we'll also make use of the ABAP-OO-events. For that purpose I've written a re-routing receiver function module that just passes all the events from the BOR to the same event in the ABAP-class (as given in the field "receiver type".

Furthermore I have added the old-fashioned BOR-instance as an event parameter and used that in the dataflow to the workflow instance. And suprise suprise, it just pops up in the GOS-Services as associated workflow w/o extra coding (in the dataflow) or extra workflow step(s).

***** Thanks for all the helpful and valuable feedback! It's very much appreciated!

Best wishes,
   Florin

-------- Original-Nachricht --------
> Datum: Thu, 17 Apr 2008 10:38:50 +0100 (BST)
> Von: "Mike Pokraka" <wug at workflowconnections.com>
> An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>
> Betreff: Re: ABAP-OO Workflow for PO-release

> Hi Jocelyn,
> 
> Thanks for a great piece of input!
> 
> Some feedback, ideas and comments:
> 
> Concerning status management/BSVV, this is an issue. HR also suffers from
> the same limitation with the SWEHR* transactions.
> 
> Regarding abandoning BOR events, I still don't think it's really
> worthwhile to muck about with class events *if*: there's an existing BOR
> event you can use as is, *and* you need GOS anyway (which is quite often
> the case).
> With OO, you'd end up instantiating BOR->OO->BOR when your WF starts.
> Easier to just trigger via BOR and only instantiate BOR->OO during your WF
> trigger.
> 
> I've been playing with the GOS BAdIs to address this but so far it's been
> more trouble than it's worth, especially since instantiating the class can
> even be done without an additional WF step by using a functional method.
> Other ideas I've had are to develop a generic programmed binding which
> will replicate a BOR to a class instance during the trigger.
> 
> Regarding HR/HCM... their use of OO is a bit weird. Some, like the leave
> request classes, are not really 'business classes' but more like utility
> classes which you've got to tunnel through to retrieve the real business
> data. Getting the leave request start date is a right pain - and don't get
> me started on the 'final' flag.
> 
> And whilst some of HR started to use classes, beware LSO which has gone
> the opposite way. Not only have they made heavy use of BOR, but also
> applied a boatload of bad practices along the way (copying objects instead
> of subtyping, GetWhatever *methods* instead of attributes...). It does
> make me worry about SAP's QA processes :-)
> 
> Cheers,
> Mike
> 
> 
> On Thu, April 17, 2008 5:04 am, Dart, Jocelyn wrote:
> > Hi Florin,
> >
> > Look this is the practical way to do it... based on my experiences at
> > several customers to date....
> >
> > 1. Use BOR objects ONLY for GOS and for Events where you can't get away
> > from BOR because either:
> > a) The application calls the event directly, or
> > b) The events are being raised via status management (and by the way we
> > are trying to get this sorted - so please complain about the lack of an
> > ABAP Class option in BSVW via the official channels)
> >
> >
> **************************************************************************************************
> > ALSO WUG FOLKS - please let me know if you have similarly come up
> against
> > the problem of trying to raise ABAP Class events for status management.
> > I'm hopeful we can get this resolved like we did the substitution BADIs
> if
> > we can show enough customers care.
> >
> **************************************************************************************************
> >
> > 2. Where you are stuck with a BOR event by all means start the workflow
> > with the BOR event - throw the BOR instance into the workflow container
> > for GOS and then straight after than instantiate the ABAP OO class and
> > carry on with that.  For terminating events you can then pass both the
> > ABAP OO and BOR instances to your task and then you can listen for both
> > BOR and ABAP OO events - again a practical approach.
> >
> > 3. Where you can work with ABAP OO but just want a BOR link for GOS -
> just
> > create the BOR reference as an attribute of your ABAP OO class and pass
> it
> > to your workflow container for GOS.
> >
> > 4. If you need polymorphism you *** CAN *** use the binding to do
> > narrowing and widening cast between generic / specific classes.   Just
> > press the arrow button in the binding to get to the options.
> >
> > ********************************************************
> > If you want to be able to use an interface in a task, again please keep
> > raising it via official channels.
> > ********************************************************
> >
> > 5. If you are looking for examples, HR/HCM is where they have really got
> > going creating some proper ABAP OO workflow classes although I'm seeing
> it
> > happening in other areas such as RPM and cProjects.  So it's all just a
> > matter of time - but no don't expect existing transactions to be changed
> > based on the "ain't-broke-don't-fix-it" rule.
> >
> >
> > 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 Mike Pokraka
> > Sent: Thursday, 17 April 2008 1:36 AM
> > To: SAP Workflow Users' Group
> > Subject: [LIKELY JUNK]Re: ABAP-OO Workflow for PO-release
> >
> > Not really worthwhile if you need GOS. In that case you'll end up
> > reinstanitating a BOR inside your WF which is kinda backward considering
> > you started off with a perfectly useable BO. Plus you have an added RFC
> > call in between. (Actually my recent question here about event linkage
> was
> > in a similar context).
> >
> >
> > On Wed, April 16, 2008 3:35 pm, Florin Wach (gmx) wrote:
> >> Hi again,
> >>
> >> thanks for your feedback!
> >>
> >> I thought of re-routing the event by a receiver function module to get
> >> the
> >> actual OO-event in place. I'll implement a generic one that'll cover
> >> that
> >> one. I just wanted to be sure, not to oversee a huge part about
> >> eventening
> >> &
> >> OO that had made this part of development obsolete.
> >>
> >> Thanks again,
> >>    Florin
> >>
> >>
> >> ----- Original Message -----
> >> From: "Mike Pokraka" <wug at workflowconnections.com>
> >> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >> Sent: Wednesday, April 16, 2008 3:21 PM
> >> Subject: RE: ABAP-OO Workflow for PO-release
> >>
> >>
> >> Dunno, I argued with polymorphism on a 620 system, but haven't really
> >> had
> >> a need for it since.
> >> All I can say is I'm having a nightmare working with BOR objects at the
> >> moment. To be fair, this is partly due to some incredibly daft design
> by
> >> SAP.
> >>
> >>
> >> On Wed, April 16, 2008 12:51 pm, Alon Raskin wrote:
> >>> Mike, any sign of polymorphism support in the WF builder yet?
> >>> That was the main reason I steered away from OO in WF to this date.
> >>> Without this I really donâ?Tt that there is so much to gain using OO
> in
> >>> WF.
> >>>
> >>> Alon Raskin
> >>> e: araskin at 3i-consulting.com
> >>> p: +1 800 405 8605
> >>> c: +1 207 409 4983
> >>> f:  +1 806 403-4983
> >>>
> >>> Put SAP in your Pocket
> >>> http://www.themobileworkplace.com
> >>> -----Original Message-----
> >>> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> >>> Behalf
> >>> Of Mike Pokraka
> >>> Sent: Wednesday, April 16, 2008 6:47 AM
> >>> To: SAP Workflow Users' Group
> >>> Subject: Re: ABAP-OO Workflow for PO-release
> >>>
> >>> Hi Florin,
> >>>
> >>> Events are probably the least developed part of WF-OO and have a
> couple
> >>> of
> >>> areas where they are not 100% supported even in the latest greatest
> >>> version.
> >>>
> >>> Nevertheless, this is completely irrelevant to your question and by no
> >>> means a reason not to go down this route.
> >>>
> >>> Events are raised by the app. Having a new type of event doesn't mean
> >>> the
> >>> po will automatically raise it, it is still BUS2012 (and probably
> >>> always
> >>> will be). Think of it as having a new BO (e.g. PURCHORD) available to
> >>> represent a PO. In other words there is no translation.
> >>>
> >>> It's annoying that you will still need to work with BOs for the
> >>> eventing
> >>> part, but there are two alternatives:
> >>> * Trigger your WF from the event and instantiate a class object in the
> >>> first step of your WF. This is quick and simple and works well.
> >>> * Use a custom receiver to forward the event to your class.
> >>>
> >>> The second option is only really useful if you need to massage event
> >>> info
> >>> along the way. The problem is that e.g. ME23N's GOS will still look
> for
> >>> BUS2012, so you will still need a BUS2012 in your WF as a container
> >>> element.
> >>>
> >>> Stick with OO. I am currently on my first project in years where I'm
> >>> forced to use BOR and it's not nice. I would violate posting
> guidelines
> >>> if
> >>> I said what I really think :-)
> >>>
> >>> Have fun,
> >>> Mike
> >>>
> >>>
> >>> On Wed, April 16, 2008 10:25 am, Florin Wach wrote:
> >>>> Hi folk,
> >>>>
> >>>> I have the great opportunity to make a complete re-design of a
> >>>> workflow
> >>>> implementation for the release procedure of purchase orders (that one
> >>>> that
> >>>> is about release-codes, etc.)
> >>>>
> >>>> I remember some previous postings that generally say that it's a very
> >>>> nice
> >>>> thing to make (more) use of ABAP-OO classes and such and read through
> >>>> the
> >>>> white paper "ABAP OO for SAP Business Workflow (including 6.40)"
> >>>> written
> >>>> by Jocelyn Dart
> >>>>
> <https://wiki.sdn.sap.com/wiki/display/HOME/2.+Design+and+Development#2.DesignandDevelopment-HowcanIuseABAPOOClassesinWorkflow%3F>
> >>>> as found in the FAQ-Wiki within the SDN:
> >>>>
> <https://wiki.sdn.sap.com/wiki/display/HOME/SAP+Business+Workflow+FAQ>
> >>>>
> >>>> I stumbled over something that says in chapter 6:
> >>>> "Events of ABAP Classes are used in workflow in a similar way to BOR
> >>>> events. When including an event of an ABAP Class in an event linkage,
> >>>> the
> >>>> following differences are noticeable:
> >>>> Ã¢â,¬Â¢ The Ã¢â,¬Å"Object CategoryÃ¢â,¬Â must be
> set to Ã¢â,¬Å"ABAP
> >>>> ClassÃ¢â,¬Â
> >>>> Ã¢â,¬Â¢ The ABAP Class name is specified as the
> Ã¢â,¬Å"Object
> >>>> TypeÃ¢â,¬Â
> >>>> The event linkage acts as an event handler for the ABAP Class event.
> >>>> To call events from programs use the class CL_SWF_EVT_EVENT.
> >>>> ThereÃ¢â,¬â"¢s
> >>>> also an interface for adding event parameters Ã¢â,¬â?o check the
> SAP
> >>>> Library
> >>>> help."
> >>>>
> >>>> Now I wonder, what the standard transactions are doing here, as the
> >>>> events
> >>>> for the Business Object BUS2012.ReleaseStepCreated (the most
> important
> >>>> one) and BUS2012.Released are called within those transactions.
> >>>>
> >>>> I have rummaged through the classes via the reference of the
> interface
> >>>> IF_WORKFLOW, but it seems that there could be something available for
> >>>> purchase requisitions, but I didn't find anything about purchase
> >>>> orders.
> >>>> Apparently I didn't find pretty much ABAP-OO classes at all.
> >>>>
> >>>> ===QUESTION===
> >>>> Q: How are (SAP Standard) events from Business-Object-Types
> translated
> >>>> into ABAP-OO events?  (Including any parameters passed, which then
> can
> >>>> be
> >>>> used in the event type linkage)
> >>>>
> >>>>
> >>>> Best regards,
> >>>>    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
> >>
> >> _______________________________________________
> >> 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