FIPP Events - Check FMs, and more

[Susan R. Keohan]

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/a053820c/attachment.htm