Background documentationEvent Handler and Callback Registration

 

Business transaction processing is controlled by the event handler, which enables communication between interrelated subobjects (see Business Transaction Subobjects). Subobjects are decoupled and, therefore, do not communicate directly with each other. Instead they use a publish/subscribe communication pattern. Each subobject publishes certain events, and callbacks (function modules) can be registered to react to these events.

When an event is triggered by a subobject, the event handler finds the callbacks that are registered for this event, and executes the corresponding function modules (callbacks) for event handling at the defined time and with the defined priority. The event handler is called when business transactions are edited or saved, but not when they are displayed.

Features

  • Predefined events and callbacks

    SAP predefines the events that are published by subobjects, and the callbacks for these events. This is done in transaction CRMV_EVENT. The system table is CRMC_EVENT_CALL.

    For detailed information about the various parameters involved in callback registration, for example, the execution time, see the documentation linked to this transaction.

  • Customer-defined events and callbacks

    Customers can register additional callbacks in Customizing for Customer Relationship Management, under Start of the navigation path Transactions Next navigation step Basic Settings Next navigation step Edit Event Handler Table End of the navigation path. The Customizing table is CRMV_EVENT_CUST.

    For more information, see the documentation for the above Customizing activity.

During processing, the event handler searches for entries in tables CRMC_EVENT_CALL and CRMV_EVENT_CUST. If entries exist in the tables, the entries in both tables are analyzed and sorted according to the priority and name of the function module.

Activities

During the processing of API calls (such as CRM_ORDER_MAINTAIN), the subobjects are accessed (read), and requests (such as create or change) are processed. During the processing of a request, each subobject decides whether events should be triggered, and which events, for example, AFTER_CHANGE.

To trigger an event, the subobject notifies the event handler via function module CRM_EVENT_PUBLISH_OW. The event handler then determines all callbacks that are registered for this event. Depending on the execution time, the callbacks are executed immediately or planned in for a later execution time. The execution times are set by the API at certain times during processing, via the function module CRM_EVENT_SET_EXETIME_OW.

Within callbacks, other subobjects can be accessed and new requests (such as create or change) can be triggered. These requests, in turn, can trigger additional events. For these events, callbacks are also determined and need to be executed depending on the execution time.

The determination and execution of callbacks by the event handler described above is depicted in the following figure, using certain subobjects and callbacks as an example:

Example Example

A callback for the generation of service item extensions is registered for the administration item creation event. This callback creates a service item extension entry. This triggers the event AFTER_CREATE for the service item extension. For this event, the callback to update the unit in the schedule lines is registered. This updates the schedule lines, which also triggers an event for which other callbacks might be registered.

End of the example.

Caution Caution

In order to avoid side effects and ensure good system performance, consider carefully the impact of any callbacks that you want to register.

  • Keep in mind that any subobject processed by a callback might trigger a chain of additional events. Therefore, carefully check the effects of new entries, for example, by using the event trace transaction described (see the documentation for the transaction CRMV_EVENT).

  • Consider whether it is absolutely necessary to set the execution time Immediately. The other execution times are better for performance since several events might trigger the same callback. If you need to react immediately to changes consider using the following callbacks (both must used):

    • A callback that is registered for several events, which collects all changes and prepares the execution

    • A callback that is registered to execute the desired processing, which is registered less frequently

    This is already set up for pricing, for example. Collection is done using function module CRM_PRIDOC_COM_DET_PRCTYPE_EC and execution is done using function module CRM_PRIDOC_UPDATE_EC.

  • Consider carefully which value you set for the parameter Call Callback and restrict the number of times the callback is planned in for a certain execution time to a minimum. For more information on the parameters, see the documentation for the transaction CRMV_EVENT.

  • Register your callback for individual transaction categories instead of for the generic transaction category BUS20001 so that your callbacks do not run unnecessarily for other transactions.

  • If the subobject you are interested in transfers certain attributes and you are only interested in a certain value, register your callback only for these specific attribute changes, especially when working with partner, status, and appointments.

End of the caution.