ABAP-OO Workflow for PO-release

Dart, Jocelyn jocelyn.dart at sap.com
Fri Apr 18 01:51:21 EDT 2008


Hi Mike, 

Good feedback.  Please complain about LSO and poor quality practice, and BSVW. 

HR has become very existentialist I agree but they are doing good things in those very complex utility classes. I'd suggest you ask for inclusion of workflow eventing in the new HR Infotype Mapper/Adapter  Framework as that supports PA30, APIs and standard/custom infotypees equally - rather than worry about SWEHR*.

Re... "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." 
Yes that's what I meant - I trigger BOR and then instantiate OO in the workflow - but if I need additional events I then add them to the OO class, e.g. for re-evaluation of agents.  

I have also had at least one large customer write their own event receiver functions to convert a BOR event trigger to start workflows with an ABAP OO event and it works quite nicely.    But not something I would do at more modest sites. 


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 7:39 PM
To: SAP Workflow Users' Group
Subject: 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




More information about the SAP-WUG mailing list