FIPP Events - Check FMs, and more

[Susan R. Keohan]

Hi Alon,
 
Thanks.  I am trying to get the doc type now (which is a property of the
object).  My previous attempts had involved trying to get the workitem ID,
then
reading the workitem container to get the container elements I wanted.
Perhaps
(and someone can feel free to correct me on this) since no workflow is yet
assigned to this event, there is no workitem to get, and this is why I had
been
failing...
 
Best regards,
Sue
 
At 10:24 AM 6/28/01 -0500, you wrote:
 
>
> Susan, (hi!!)
>
>
>
> Try the following code in the check FM. Should work
>
>
>
> Data : lv_fipp type swc_object.
>
> Swc_get_element event_container '_EVT_OBJECT' lv_fipp.
>
>
>
>
>
> You should now have the object which the event was raised for.
>
>
>
> If this doesn't work then we have a problem. I am doing this in 4.6c and it
> seems fine. How is the event raised? Can you see the Object ID in the event
> log?
>
>
>
> Regards,
>
> Alon Raskin
>
> Workflow Advisor - Soliance
>
>
>
> -----Original Message-----
>> From: Susan R. Keohan [mailto:skeohan at MIT.EDU]
> Sent: June 28 2001 10:16
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: FIPP Events - Check FMs, and more
>
>
>
> Hello Workflow-ers,
>
> We are running on 4.6c.  We have three workflows which should get kicked off
> when an FI parked document (Object FIPP, event CREATED) is created.
> Currently, we use check function modules to allow the correct workflow to
> start based on document type.  However, based on recent mail to this list on
> this topic, I have decided to implement a Receiver Type FM - essentially the
> same code, but packaged into one receiver FM.
>
> My question is this...  I use an import from memory to get the document (the
> export to memory is done in a user-exit) , then, if that fails, I try to
read
> the  container, and if that fails, I try to read the database using the
event
> object.  When testing, I can make the container read and the database read
> methods work.  However, in real life, only the import from memory succeeds.
> So, why do the container read and the database read fail ?  What are the
> implications if I rely strictly on the import from memory to retrieve the
> document number ?
>
> Many of the other SAP-delivered Check FMs and Receiver Type FMs get the data
> necessary by reading the event container, then calling SWW_WI_CONTAINER_READ
> (an example of  ME_REL_CHECK_EVENT_PARAM follows, and I do know that this FM
> is not related to FIPP).
>
>   swc_get_element event_container evt_receiver_id wi_id.
>   if sy-subrc ne 0.
>     raise container_error.
>   endif.
>
> ** Get the workitem container
> call function 'SWW_WI_CONTAINER_READ'
>      exporting
>           wi_id                    = wi_id
>      tables
>           wi_container             = wi_container
>      exceptions
>           container_does_not_exist = 01.
>
>   if sy-subrc ne 0.
>     raise container_error.
>   endif.
>
> ** Get the release code from the workitem container.
> swc_get_element wi_container 'RELEASECODE' wi_release_code.
>
> Any insight into this phenomenom will be appreciated. Of course, I want to
> build the most robust receiver type FM possible. That's why I have used the
> three methods described above, but if two of them always fail, I may as well
> not implement them.
>
> Cheers,
> Sue
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20010628/bca0e558/attachment.htm