FIPP Events - Check FMs, and more

Susan R. Keohan skeohan at MIT.EDU
Fri Jun 29 11:08:00 EDT 2001


Thanks Michael.  I have no problem adding the container element
DocumentType to
the workflow, but haven't yet been able to fill the container element before
triggering the event.  That part seems to be a little sticky.  The event is
raised by PP_WF_EVENT, which is called after our user exit
(EXIT_SAPLF051_002).
 
At any rate, my imports from memory do work, and quite reliably, so I am still
curious if any of our gurus out there want to weigh in on the merits (or lack
of) of relying on this method (exporting and importing from memory) to obtain
the document information .vs. event/workitem container reads...
 
Regards,
Sue
 
At 06:29 PM 6/28/01 +0200, you wrote:
>
> What element do you want to read from a container?
> In case of ME_REL_CHECK_EVENT_PARAM special element _EVT_RECEIVER_ID is
read.
>
> A receiver in that case is a workitem so a receiver ID is a workitem ID.
That
> is why system
> can read from workitem container.
>
> If you want to pass the data using container (e.g. to pass a document type)
> you should
> create a new container element for an event and fill that container element
> before you trigger your event. Then you can read the container element in
> your check FM.
>>
>> -----Original Message-----
>>> From: Susan R. Keohan [mailto:skeohan at MIT.EDU]
>> Sent: 28 czerwca 2001 17: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/20010629/b1bccad0/attachment.htm


More information about the SAP-WUG mailing list