ABAP-OO Workflow Rule Resolution

Mike Gambier madgambler at hotmail.com
Thu Sep 11 04:26:16 EDT 2008


Florin,
 
That's precisely my point. I think SAP have missed a trick here in relying on the old SWCONT container construct everywhere. The fact that they haven't touched their old FMs is probably more to do with backwards compatibility rather than backwards thinking I'm sure. But frankly I'm staggered that they haven't extended their containers to offer a construct that can actually cope with class instances as well as BOR object instances and flat elements all in one place.
 
The only problem with ABAP_PARMBIND that trips a lot of poeple up is the local definition of types and data variables that end up being freed in the call stack thereby invalidating the container entries. But, apart from this limitation they are extremely verstaile.
 
Surely ABAP_PARMBIND lends itself to the 'new' ABAP-OO Workflow engine? To my mind they were made for each other.
 
Mike GT> Date: Thu, 11 Sep 2008 09:00:13 +0200> From: florin.wach at gmx.net> Subject: Re: RE: ABAP-OO Workflow Rule Resolution> To: sap-wug at mit.edu> > ...because it isn't passed to the function module of the rule resolution> (see function module RH_GET_ACTORS lines 158ff)> * execute function to resolve actor without evaluation path> > CALL FUNCTION exec_fname> TABLES> ac_container = actor_container> actor_tab = actor_tab> EXCEPTIONS> OTHERS = 1.> > > > -------- Original-Nachricht --------> > Datum: Wed, 10 Sep 2008 15:51:40 +0000> > Von: Mike Gambier <madgambler at hotmail.com>> > An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>> > Betreff: RE: ABAP-OO Workflow Rule Resolution> > > > > Florin,> > > > Any reason why a container based on ABAP_PARMBIND_TAB couldn't be used> > here instead?> > > > Mike GT> Date: Wed, 10 Sep 2008 16:14:52 +0200> From: florin.wach at gmx.net>> > Subject: ABAP-OO Workflow Rule Resolution> To: sap-wug at mit.edu> > Hi> > Wuggies,> > I have just stumbled over an issue with the rule resolution by> > "function module" using ABAP-OO, as the container is not passed as a reference> > to IF_SWF_CNT_CONTAINER nor as a persistent XML-reference (as the check and> > receiver function modules do). So there's currently a small GAP.> > > The> > requirement was, to pass the persistent object reference (structure> > SIBFLPOR) and/or the object instance (TYPE REF TO ---type---) to the role-container> > (AC_CONTAINER).> > The straightforward(?) solution was:> - Create a> > container element "LPOR" with struct-reference to type SIBFLPOR> - Create a> > public attribute MS_LPOR and assign this in the binding to the rule> > (Releasable->MS_LPOR --> LPOR)> > A little bit of a suprise was, that the binding> > checks returns with an error, saying that that assignment is just incompatible.> > That was true in the way, that the instance-attribute MS_LPOR was treated> > as it was a TYPE-REF-TO definition. So the only eligible target type for the> > binding was a TYPE-REF-TO definition.> > However. I have changed the> > container stuff and now having a new element RELEASALBE with a TYPE-REF-TO> > definition and within the dataflow I just pass the _wi_object_id itself. Now the> > binding checks is fine.> > On runtime now, the following coding will /not/> > work, to retrieve the object instance:> > DATA: releasable TYPE REF TO> > Z_CL_RELEASABLE.> swc_get_element ac_container 'Releasable' releasable.> >> > Because the "new" ABAP-OO elements are passed in a way, that the old> > BOR-container macros cannot work with.> > On the other hand, the rule interface does> > not (!) provide the ac_container as an object referring to> > IF_SWF_CNT_CONTAINER (or something like this).> > So this is, how it works:> > Create a> > new import parameter (optional, pass-value) for future use:>> > ACTOR_CONTAINER_OO TYPE REF TO IF_SWF_CNT_CONTAINER Container: Implementing Class> > > "...> > further in coding> > * The ABAP-OO container object is currently not> > designed by SAP. This> * part is not yet fully compatible to the new> > ABAP-OO-Workflow.> * Therefore we will help ourself here and create it backwards from>> > * the BOR-container.> * If the interface is correctly(!) used in the> > future, then we will> * also use, what the standard gives us.> IF> > actor_container_oo IS INITIAL.> CALL METHOD> > CL_SWF_CNT_CONTAINER=>IF_SWF_CNT_CONVERSION~CREATE_FROM_BOR_CONTAINER> EXPORTING> values = ac_container[]> RECEIVING>> > container = actor_container_oo.> ENDIF.> > DATA: releasable_oo TYPE REF TO> > Z_CL_RELEASABLE.> swf_get_element actor_container_oo 'Releasable'> > lo_releasable.> "no it's fine :-)> IF NOT sy-subrc EQ 0.> "Handle exceptions here>> > ENDIF.> > > > Take care,> Florin>> > _______________________________________________> SAP-WUG mailing list> SAP-WUG at mit.edu>> > http://mailman.mit.edu/mailman/listinfo/sap-wug> > _________________________________________________________________> > Make a mini you and download it into Windows Live Messenger> > http://clk.atdmt.com/UKM/go/111354029/direct/01/> _______________________________________________> SAP-WUG mailing list> SAP-WUG at mit.edu> http://mailman.mit.edu/mailman/listinfo/sap-wug
_________________________________________________________________
Make a mini you and download it into Windows Live Messenger
http://clk.atdmt.com/UKM/go/111354029/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20080911/34ea4ed9/attachment.htm


More information about the SAP-WUG mailing list