Creation of Events by Calling a Function Module

You must ensure that the event is triggered when the status change occurs. It may be necessary to trigger the event using a function module in your program.

Prerequisites

Note that events say something about object status changes that have actually occurred. Therefore ensure that the event is not created until the relevant status change has taken place. For this, the function module for creating an event should be called in the same logical unit of work (LUW) as the one in which the status change is made.

Features

You can create events from application or system programs by calling one of the relevant function modules SWE_EVENT_CREATE or SAP_WAPI_CREATE_EVENT.

For the following special cases, there are other function modules, which actually use the functionality of the above function module internally:

SWE_EVENT_CREATE_IN_UPD_TASK
This function module makes it possible to create events in an update task. In contrast to the function module SWE_EVENT_CREATE, it can be called with the addition of IN UPDATE TASK.
SWE_EVENT_CREATE_FOR_UPD_TASK
The event is created in the update task. (The function module is not called with the addition of IN UPDATE TASK).

If a task in which an object is created is to use the creation of this event as a terminating event, the workflow system uses the workflow requester. This means that the event Object created can be used as a terminating event, although the object does not yet exist when the task is started. To enable the workflow system to use the workflow requester without errors, the function module should be called as the last function module before COMMIT WORK.

When the function module SWE_EVENT_CREATE is called, the following operations are performed synchronously at first:

Find requester
If an event is created by an application that is executed as an asynchronous object method within a workflow, the work item that called this method can be established via internal queries.
Determine all supertypes of the triggering object type
The type linkage is not only taken into account for the triggering object type itself, but also for all supertypes of this object type.

Example
A type linkage is entered for an event of the object type person.

If this event is created by the subtype applicant, the type linkage of the person should also be evaluated.

End of the example.

The evaluation of the linkage tables taking into account the import parameters of the function module for determining a possible receiver follows.

Note Note

It is not possible to state whether the receivers were called successfully.

For more information, see Evaluation and Maintenance of Type Linkages.

End of the note.

Activities

Caution Caution

Ensure that you first write the database changes, then call the function module, and finally carry out a COMMIT WORK. If you perform these activities in a different order, it can lead to object data not existing in the container, or having incorrect content.

End of the caution.

Call the function module SWE_EVENT_CREATE or one of its modified versions mentioned above in a program of your application. The function module has the following interface (selection):

Import Parameter
`OBJTYPE`	`SWETYPECOU-OBJTYPE`	Type of the triggering object.
`OBJKEY`	`SWEINSTCOU-OBJKEY`	Concatenated, object type-specific key of the triggering object. The reference to the triggering object is created internally from this information and written to the event container under the element ID `_Evt_Object`.
`EVENT`	`SWETYPECOU-EVENT`	Event Name The event must be defined for the triggering object type.
Export Parameter
`EVENT_ID`	`SWEDUMEVID-EVTID`	The event number has a value other than zero if the event manager could establish one or more receiver function modules. Note It is not possible to state whether the receivers were called successfully. If no receiver could be established, zero is returned as the event number. End of the note.
Table Parameter
`EVENT_CONTAINER`	`SWCONT`	Persistent event container of the event. You only pass the event container if you have defined event parameters in addition to the predefined elements. The container you pass to the function module is filled with the relevant data in the event-creating application and then contains only the event parameters you defined. When the function module is executed, the predefined elements (object reference, creation time, creator, and so on) are added to the event container.

Note Note

Since the asynchronous RFC for calling the receiver function module is not triggered until after the next COMMIT WORK, you must initiate the command COMMIT WORK in your application after the function module for creating an event is called in order for the events to actually be created.

The database commit performed automatically with a screen change does not trigger the asynchronous RFC.

End of the note.

Event Parameter

If the event that you want to create has other event parameters defined in addition to the event parameters defined by the system, you must carry out the following before the function module is called:

Declare the event container
Initialize the event container
Assign values to the event container

Macro instructions are available for carrying out these steps. For more information, see Macro Instructions for Processing a Container.

The container is then passed as a table parameter to the function module SWE_EVENT_CREATE. The name you give to the event container in your application is up to you.