<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: FIPP Events - Check FMs, and
more</title></head><body>
<div>Sue,</div>
<div><br></div>
<div>I'm definitely not a guru, but I'll weigh in anyway. It
seems to me you're doing the best and safest thing you can do under
the circumstances. The memory you're using is local to the
transaction, so it's safer than using parameter IDs. Your
receiver type FM is called (by SWE_EVENT_CREATE, in fact) in the same
context as your customer exit, so you can rely on the fact that the
memory variable you populate in the exit is available in the receiver
type FM.</div>
<div><br></div>
<div>The main problem with the FIPP and BSEG events is that the events
are raised before the corresponding documents are stored in the
database, so receiver type FMs and check FMs don't have access to the
documents you need to evaluate. The only other thing I can think
to do here would be to use a receiver FM to decide which workflow to
initiate and call SWW_WI_START_SIMPLE to initiate the workflow
instance. I use this technique in cases where I may either issue
an automatic approval or initiate a workflow instance depending on
circumstances. But in your case, where you're simply deciding
which workflow to initiate, I think your receiver type FM is the right
thing to do.</div>
<div><br></div>
<div>In the case of ME_REL_CHECK_EVENT_PARAM which you cited, this FM
is called only for terminating events for an existing workitem, so it
works fine there. In your case where you're initiating a
workflow, no workitem exists yet, so the workitem container read
cannot work. You did say you got both the database read and
container read to work in testing. I'd like to assume that was
outside the context of your receiver type FM. If not, how did
you do that?</div>
<div><br></div>
<div>Rob</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>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="-1" color="#0000FF"></font>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF">What element do you want to read from a
container?</font><br>
<font size="-1" color="#0000FF">In case of ME_REL_CHECK_EVENT_PARAM
special element _EVT_RECEIVER_ID is read.</font><br>
<font size="-1" 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="-1" color="#0000FF">can read from workitem
container.</font><br>
<font color="#000000"><br>
</font><font face="Arial" size="-1" color="#0000FF">If you want to
pass the data using container (e.g. to pass a document type) you
should</font><br>
<font size="-1" color="#0000FF">create a new container element for an
event and fill that container element</font><br>
<font size="-1" color="#0000FF">before you trigger your event. Then
you can read the container element in your check FM.</font><br>
<blockquote>
<blockquote><font face="Tahoma" size="-1"><br>
-----Original Message-----<br>
From: Susan R. Keohan [mailto:skeohan@MIT.EDU]<br>
Sent: 28 czerwca 2001 17:16<br>
To: SAP-WUG@MITVMA.MIT.EDU<br>
Subject: FIPP Events - Check FMs, and more<br>
<br>
</font><font face="Tahoma"><br>
Hello Workflow-ers,<br>
<br>
<br>
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>
<br>
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 ? </font></blockquote>
<blockquote><font face="Tahoma"><br>
<br>
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 size="-1"><br>
swc_get_element event_container evt_receiver_id wi_id.<br>
if sy-subrc ne 0.<br>
raise container_error.<br>
endif.<br>
<br>
<font face="Tahoma" color="#0000FF"><br>
** Get the workitem container</font><font face="Tahoma"><br>
call function 'SWW_WI_CONTAINER_READ'<br>
exporting<br>
wi_id <span
></span> =
wi_id<br>
tables<br>
wi_container <span
></span> = wi_container<br>
exceptions<br>
container_does_not_exist = 01.<br>
<br>
<br>
if sy-subrc ne 0.<br>
raise container_error.<br>
endif.<br>
<br>
<font color="#0000FF"><br>
** Get the release code from the workitem container.</font><br>
swc_get_element wi_container 'RELEASECODE' wi_release_code.<br>
<br>
<br>
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>
<br>
Cheers,<br>
Sue</font></font></blockquote>
</blockquote>
</blockquote>
</blockquote>
<div><br></div>
</body>
</html>