ABAP-OO Workflow for PO-release

[Kjetil Kilhavn]

On Thursday 17 April 2008 06:04:05 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.
This is interesting (well, anything from a SAP employee who has proven insight 
previously is interesting - but this was particularly interesting).

I have very little experience with ABAP Objects used in workflow, but by 
following the steps in your excellent seven step tutorial published as 
weblogs on SDN the creation of a workflow-enabled class was no sweat. The 
only problem I ran into was adding messages to the workflow log where I was 
not able to add messages after completion of a work item to log what the user 
had done (specifically I wanted to log information about individual items 
approved in an ALV report with information about whether the following DB 
update was successful or not).
Anyway, my small two-step workflow uses a class, and there is an event with 
parameters raised to start it. Works perfectly as far as I can tell. 

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.

In the project I am currently working for there is a lot of additional 
functionality added to the BUS2012 and BUS2081 objects through delegated 
subtypes (yes, unfortunately they insisted on parking Logistics Invoices). 
Actually I have also subtyped other object types such as e.g. USR01 where I 
have added a ZIsDialogUser attribute to be able to add conditions etc with 
ease - avoiding having to check everything in methods.

You are recommending that we create classes not only for non-existing business 
objects, but also to extend a business object with additional functionality? 
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.

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.
-- 
Kjetil Kilhavn (+47 40220607)
Blue Consulting AS (http://www.bluec.no/)