FIPP Events - Check FMs, and more

["Klemba, Michał"]

Sue,
You should add the parameter ('DocumentType) to your object event (during
runtime it means you have additional EVENT container element) and fill EVENT
container uppon document creation (program it in your user exit). Refer to
following code (you should put something like that into your user exit).
 
 
*   INCLUDE ZX...
...
swc_container event_container.
...
swc_create_container event_container.
...
swc_set_element event_container 'DocumentType' uexit_variable-doctype.
...
 
CALL FUNCTION 'SWE_EVENT_CREATE_FOR_UPD_TASK'
   EXPORTING
      objtype              = i_objtype
      objkey               = i_objkey
      event                = 'my_event'
   TABLES
      event_container      = event_container
   EXCEPTIONS
      OTHERS               = 1.
 
 
Cheers,
Michal
 
-----Original Message-----
From: Susan R. Keohan [mailto:skeohan at MIT.EDU]
Sent: 29 czerwca 2001 17:08
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: FIPP Events - Check FMs, and more
 
 
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> 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/20010702/24122718/attachment.htm