Ansicht
Dokumentation

CRM_EVENT_MAINTAIN - Initial View Maintenance for Customizing Event Handler

CRM_EVENT_MAINTAIN - Initial View Maintenance for Customizing Event Handler

Vendor Master (General Section)   CPI1466 during Backup  
This documentation is copyright by SAP AG.
SAP E-Book

Purpose

This SAP-internal transaction enables you to register callbacks (function modules) for standard events in table CRMC_EVENT_CALL. When an event is triggered by an object, the event handler does the following:

  • Searches in system table CRMC_EVENT_CALL to find the callbacks that are registered for this event.
  • Executes the corresponding function modules 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.

Note: Customers can register their own events in Customizing table CRMV_EVENT_CUST, in Customizing for Customer Relationship Management under Transactions -> Basic Settings -> Edit Event Handler Table. If entries exist in both the system table and the Customizing table, the entries in both tables are analyzed and sorted according to the priority and name of the function module.

Determining Events for Callback Registration

To help you determine for which event and for which execution time to register, you can use the event trace. This provides detailed information about event processing for you own user or for other users. You use the event trace as follows:

  1. For your own user, set the value X for the user parameter CRM_EVENT_TRACE.
You do this under System -> User Profile -> Own Data on the Parameterstab page.
  1. Call transaction CRMD_EVENT_TRACE, enter a user and the maximum number of records, and execute.
The trace report shows events, objects, callbacks, and execution times. You can refresh the trace report during transaction processing.
By analyzing the events that have been set, and the execution times that have been reached, you can decide which combination of event, object, and execution time is best for you.

Registration of Callbacks for Events

This section contains an explanation of the fields of table CRMC_EVENT_CALL. The entities that can be entered in these fields are defined in this transaction (CRMV_EVENT) in the Definitions group box (see "Definition of Entities Relevant for Event Handler" below).

With the exception of the CHANGED_AT and CHANGED_BY fields, these are the same fields that are available to customers in the Customizing activity mentioned above.

Transaction Category (SUB_TYPE)

A business transaction category. This can be the general SAP CRM transaction category BUS20001 (to make the entry generally available) or a more specific transaction category (for example, BUS2000114, which only applies to leasing scenarios).

Note: An entry in table CRMC_EVENT_CALL that applies to a leading transaction category automatically applies to all secondary transaction categories.

Execution Time (EXE_TIME)

The point during the processing of a transaction when you want your callback to run. Various execution times are set during business transaction processing, as follows:

  • End of Header Processing, End of Item Processing, End of Document Processing, End of All Documents, and End of are set during editing of a transaction.
  • Before Saving and Save Document are only called when a transaction is saved.
  • Initialize Documentis called during the initialization of the business transaction.
  • End of Deletion, Save Header, and Save Item are currently not used.

When an event for which you have registered for is published, you may require an immediate reaction or you may want to wait until a later point in time. For example, if partner data is changed, pricing data needs to be checked immediately. Determination of organizational units, however, can wait until the end of header processing before reacting to the change.

If an execution time is set (in system table CRMC_EVENT_EXTI) that allows earlier execution times to be processed concurrently, the callbacks for earlier execution time are also processed.

Note: If you register a callback for the execution time Immediately (001) the callback is executed immediately after the event has been triggered. Only use the execution time Immediately if absolutely necessary as it reduces system performance due to the fact that several events can trigger the same callback. Do not use the execution timeImmediately (001) if you register for the event SAVE.

Callback Processing Priority (PRIO)

The priority of a callback. Acts as an additional sort criterion to determine when callbacks are carried out.

Object (OBJ_NAME)

The object (for example, partner, organizational data) that triggered the event. Objects are the building blocks of transaction categories and item object types.

Event (EVENT)

The event for which you want to register a callback. The following event categories exist:

Event Category When Triggered
Init When the transaction is initialized
Check Before an action is performed for a certain object (change, create, delete, save, create_with_ref)
Change After an action has been performed for a certain object
Delete When the transaction or objects are deleted
Save When the transaction is saved

Some events do not have a category. These events are triggered for very specific reasons.

Note: The events that are triggered depend on the objects involved, for example, events with the appendix WITH_REFERENCE are only triggered by headers and items when they are copied or a follow-up is created.

Attribute (ATTRI1)

The attribute is used as a filter to restrict the number of function modules called. If you always need to react to a particular event, then you should set ATTRI1 to SPACEor <*>. Depending on the object, you may not always need to react to an event being published. You can assign an attribute to the callback so that it only reacts when this attribute is set.

Example: This attribute is used by the status, partner, and appointment sets. The partner set uses this attribute to communicate for which particular partner an event has been published (0001 for contact person, and so on). The status set communicates the status change via this attribute. The appointment set communicates the date field being changed via this attribute. If you set SPACEor <*> for one of these sets, then your callback will react to every event published by this set.

Callback Function (FUNC_NAM)

The name of the callback (it should begin with CRM and end in EC). The object function is used to group certain callbacks in order to easily determine which callbacks are available for a certain transaction type. Before you can enter a callback in this view, it has to be assigned to an object function in the Definitions group box.

Perform Callback if Event for Header GUID is Published (ONLY_HDR)

This flag determines whether the callback should be carried out at header level.

Perform Callback if Event for Item GUID Is Published (ONLY_ITM)

This flag determines whether the callback should be carried out at item level.

Do Not Process Function if Event Error Occurs (ERROR_CHECK)

Set this flag if you do not want your callback to run if, for some reason, the object raises an error. For example, if the user enters the wrong product, then you may not want your callback to be processed.

The flag is passed to the event handler. Which errors set the flag (=TRUE) depends on the object in question.

Frequency of Callback Call (CB_FREQ)

Parameter setting for the callback.

Note:This setting is very important since it determines how often the callback will be put into the planning table for each execution time.

The setting does not impact the frequency if the callback is registered for execution time Immediately (001) since in this case callbacks are not planned for later execution.

The following values are supported:

  • Call to Header/Item, with Object, Event, Attr., Old/New Data (SPACE)
The callback is carried out for headers and items. The callback is provided with the object name, the event, and old and new data (the old and new versions of the work area structure). The structure that is passed is defined in table CRMC_EVENT_STRUC. If old and new data are required and you want the callback to run immediately once an event is published (execution time Immediately (001)), you must use this setting and not setting K (see below).
With this setting your callback will be planned in every time the event is triggered in order to provide the callback with each old and new data entry.
  • Call to Header/Item with Object, Event, Attr. W/Out Old/New (A)
The same procedure takes place as with setting SPACE, but without old and new data.
If a callback is registered with this setting, each time the respective event is triggered a check determines whether this callback has already been registered for the combination of GUID (of header or item), object, and attribute. If no entry with this combination is found, the entry is planned in again.
  • Call to Header/Item, W/Out Object, Event, Attr.,Old/New Data (B)
The callback can be carried out for header and items. Object, event, and old and new data are not provided.
If a callback is registered with this setting, each time the respective event is triggered a check determines whether this callback has already been registered for the relevant GUID (of header or item). The callback is only planned in again if the event is triggered by a different header or item.
  • Call Just Once Per Transaction (C)
    The same procedure takes place as with setting B, but the callback is carried out only once per transaction. Note: This is the only setting that you should use with the execution time Save (080).
If a callback is registered with this setting a check only takes place to determine whether this callback has been planned in once (for header or item). However if there a several registrations for the same callback for different execution times, the callback is planned in once per execution time.
  • Call to Hdr/Item with Object/Event/attr.+ Compressed Old/New (K)
The callback can be carried out for headers and items. The callback is provided with the object name, the event, and cumulated old and new data. Therefore, if an event is published more than once, you receive the old data from the initial call, and the new data from the final call. All changes in between are irrelevant. Normally, you need to set SPACE if you want to react immediately and K if you want to react later. However, for specific partner data, (for example, if you are registered for a change to a specific partner function (field attri1 = 0001 or similar) and not for general partner changes (field attri1 = <*> ) you need to use SPACE, since partner data cannot be cumulated.
If a callback is registered with this setting, each time the respective event is triggered a check determines whether this callback has already been registered for the combination of GUID (of header or item), object, and attribute. If no entry with this combination is found, the entry is planned in again. However, the old and new data is stored every time so that the compressed old and new data values can be provided later.

Changed On (CHANGED_AT)

Date of change to data record

Changed By (CHANGED_BY)

User who made the change

ONLY_ONE_CALL

This flag is no longer relevant.

Definition of Entities Relevant for the Event Handler

In the Definitions group box you can define the following:

  • Events: The events that can be published in the event handler
  • Objects: The objects that are used to design a transaction category or item object type
  • Object/Event Structure: A structure must exist for an object to be able to pass information when publishing an event (for example, new quantities in an order or changed partner data). You need to enter the structure so that the event handler can format the data.
  • Object Functions:Object functions are functions carried out by an object or set. They are used to group sets of callbacks so that they can be planned or excluded when an event is published.
  • Object/Object Function: Assignment of object functions objects.
  • Object Function/Callback: Assignment of callbacks to object functions.
  • Times: The execution times that can be set during the various processing stages of a transaction.

Determination of Callbacks During Processing

Each time an event is triggered, all possible callbacks have to be determined for each transaction type and item object type. The event handler selects callbacks on header and item level depending on which level the event has been triggered. The selection on header level is performed by function module CRM_EVENT_FILTER_PROC_TYPE_OW. The selection on item level is also performed by this function module if the item object type is not yet known. If the item object type is known, the selection on item level is performed by module CRM_EVENT_FILTER_ITEM_TYPE_OW.

After all possible callbacks have been determined, the callbacks for the triggered event are evaluated.

In detail, the event handler procedes as follows to determine callbacks (note that steps 3 and 4 are interchangeable):

  1. Determines the transaction category and secondary transaction category for the transaction type (tables CRMC_PROC_TYPE and CRMC_PR_ASSIGN).
  2. Sets callbacks for these transaction categories (tables CRMC_EVENT_CALL and CRMC_EVEN_CUST).
  3. For header level or item level withoutitem object type known:
    1. Selects objects for the transaction type (table CRMC_OBJECT_ASSI).
    2. Selects all item types for the transaction type (table CRMC_IT_ASSIGN).
    3. Selects all objects for all item object types (table CRMC_OBJ_ASSI_I).
  4. For item level withitem object type known, selects object for item object type (table CRMC_OBJ_ASSI_I).
  5. Adds generic objects, such as ACTION or ORDER.
  6. Determines object functions for objects (table CRMC_OBJECT_FUNC).
  7. Removes object functions according to Customizing settings.
For example, if a user status profile is specified in Customizing, the object function CRM_USER_STATUS is added.
  1. Selects callbacks from preselection for remaining object functions (table CRMC_FUNC_ASSIGN).

Checks

You can display the callbacks that are scheduled for a certain transaction type or item category (by clicking Determine Callbacks for Trans.Type/Item Category). If a callback is not displayed in the result list, it cannot be executed. If you want to display callbacks for an item category, you need to also enter a transaction type as some Customizing at header level has an effect on the item level.

This check is particularly useful to see if any unnecessary callbacks have been assigned to the transaction type or item category. If this is the case, then you should adjust the callback registration accordingly.

Integration

Prerequisites

Features

Selection

Standard Variants

Output

Activities

Example






Vendor Master (General Section)   BAL Application Log Documentation  
This documentation is copyright by SAP AG.

Length: 19167 Date: 20240531 Time: 114449     sap01-206 ( 286 ms )