<html>
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).<br>
<br>
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... <br>
<br>
Regards,<br>
Sue<br>
<br>
At 06:29 PM 6/28/01 +0200, you wrote: <br>
<font face="arial" size=2 color="#0000FF"><blockquote type=cite cite>What
element do you want to read from a container?</font><br>
<font size=2 color="#0000FF">In case of ME_REL_CHECK_EVENT_PARAM special
element _EVT_RECEIVER_ID is read. </font><br>
<font size=2 color="#0000FF">A receiver in that case is a workitem so a
receiver ID is a workitem ID. That is why system </font><br>
<font size=2 color="#0000FF">can read from workitem
container.</font><br>
<font size=3 color="#000000"> <br>
</font><font face="arial" size=2 color="#0000FF">If you want to pass the
data using container (e.g. to pass a document type) you should
</font><br>
<font size=2 color="#0000FF">create a new container element for an event
and fill that container element </font><br>
<font size=2 color="#0000FF">before you trigger your event. Then you can
read the container element in your check
FM.</font><blockquote><font face="tahoma" size=2>
<dl>
<dd>-----Original Message-----<font size=2>
<dd>From:</b><font size=2> Susan R. Keohan
[<a href="mailto:skeohan@MIT.EDU" eudora="autourl"><font size=2>mailto:skeohan@MIT.EDU</a><font size=2>]<font size=2>
<dd>Sent:</b><font size=2> 28 czerwca 2001 17:16<font size=2>
<dd>To:</b><font size=2> SAP-WUG@MITVMA.MIT.EDU<font size=2>
<dd>Subject:</b><font size=2> FIPP Events - Check FMs, and more<br>
<br>
</font><font size=3>
<dd>Hello Workflow-ers,<br>
<br>
<dd>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.<br>
<br>
<dd>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 ? <br>
<br>
<dd>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).<br>
<br>
</font><font face="Arial Monospaced for SAP, Helvetica">
<dd> swc_get_element event_container evt_receiver_id wi_id.
<dd> if sy-subrc ne 0.
<dd> raise container_error.
<dd> endif.<br>
<br>
</font><font color="#0000FF">
<dd>** Get the workitem container</font>
<dd>call function 'SWW_WI_CONTAINER_READ'
<dd> exporting
<dd>
wi_id
= wi_id
<dd> tables
<dd>
wi_container
= wi_container
<dd> exceptions
<dd>
container_does_not_exist = 01.<br>
<br>
<dd> if sy-subrc ne 0.
<dd> raise container_error.
<dd> endif.<br>
<br>
<font color="#0000FF">
<dd>** Get the release code from the workitem container.</font>
<dd>swc_get_element wi_container 'RELEASECODE' wi_release_code.<br>
<br>
<dd>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.<br>
<br>
<dd>Cheers,
<dd>Sue</blockquote><br>
<br>
</dl></html>