The full life-cycle of an event shows it's true colors. This article may help you inderstand some of the mystical manners of events. 

 The life of an event When an event is created, it has a life of it's own - until it triggers (e.g.) a workflow. This is the sequence of events that happen to an event:

1. A change document is written for which an event had been set up, once the subject of the change document as well as the change document itself has been stored on the database (tables CDHDR & CDPOS) the event is processed
2. (Only for events triggered from change documents) the Object Type of the linkage is determined (if it is not already set up) via a function module like SWE_CD_TEMPLATE_OBJTYPE_FB set up on transaction SWEC.
3. (Only for events triggered from change documents) the Event ID (name of the event) of the linkage is determined (if it is not already set up) via a function module like SWE_CD_TEMPLATE_EVENT_FB set up on transaction SWEC.
4. (Only for events triggered from change documents) the event container for the event linkage can be enriched with elements that have been defined (as parameters on the event definition, which can be found on the business object) via a function module like SWE_CD_TEMPLATE_CONTAINER_FB set up on transaction SWEC.
   
   Note: To this point all actions are about the event. From here on it's all about "event linkages" (recievers)
   
   
5. The receiver type function module is called (when it is supplied in transaction SWETYPV) - this function module determines which reciever types (E.g. workflow WS91000067) are to be linked (hardly ever used)
6. In transaction SWETYPV, the destination of a receiver can be maintained - this will effectively trigger the event on a logical RFC destination...
7. For every event linkage (read: event linked to a reciever for e.g. triggering a workflow or several workflows) a function module to check whether the event should be stopped is executed (only when it has been set up on transaction SWETYPV).
   See Check event linkage - function module
   
8. Starting conditions are checked (only when the function module for the previous step is not set up). Transaction SWB_COND holds the starting conditions for an event/workflow combination in a graphical and readable manner. The transaction also allows creating and changing start conditions.
9. (Only for events that allow event queue usage) the event is now placed in the event queue (see transaction SWEQADM).
10. Events will be processed (directly or via the batchjob behind the event queue).
11. By now the event linkage is really triggered/raised. This is done via a function module call which is set up in transaction SWETYPV as well, normally set up for function module SWW_WI_CREATE_VIA_EVENT_IBF. So effectively, via a linkage the event mechanism of workflow could be used to do anything...
12. Events always belong to a business object, for which an instance is now created. Only if the method ExistanceCheck on the business object from the event returns a valid result - can the event be processed further (errors will show in the event log)
13. (Only if the event trace is active) An entry will be added to the event trace (this is where it shows what happened to the event or why it was ignored). See transaction SWEL and SWELS
14. The workflow which is set up to trigger from this event will be started and normally the Business Object behind the event will be placed into the workflow containes (along with any other event container elements).
15. That's it - the life of the event is over...

• Prev
• Next