FIPP Events - Check FMs, and more

[R Tannert]

Sue,
 
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.
 
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.
 
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?
 
Rob
 
 
>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/a11adffd/attachment.htm