Header Ads

Everything about CRMV events

4:52 AM , , ,

CRM_EVENT_MAINTAIN

____________________________________________________

Short Text

Initial View Maintenance for Customizing Event Handler

Purpose

The following document contains an explanation of the entries and flags to be found in the Event Handler Customizing table CRMC_EVENT_CALL and general information on how the Event Handler works.
This transaction is split into 4 sections- 1. maintenance of CRMC_EVENT_CALL (Assignments), 2. How Callbacks are Selected, 3. Definitions and 4. Checks. These sections are described in detail below.
In Release 4.0, the following change has been made:
A new entity has been added to the Event Handler. This is the object function. Object functions belong to objects or sets. For example, the partner set has the object functions Partner and Buying Center Handling. Function modules are assigned to an object function which in turn is assigned an object/set. The object/set is assigned to a transaction category (BUS Object) which is assigned to a transaction type or item type.  If an object is not assigned to a transaction type, then any callbacks assigned to the object function can be ignored by the event handler. Thus, for each transaction type or item type, the Event Handler can determine which function modules are required.  Via an additional function module (CRM_EVENT_FILTER_PROC_TYPE for transaction  types and CRM_EVENT_FILTER_ITEM_TYPE for item  types), specific object functions (i.e. groups of callbacks) can be excluded from selection.
Which event do I need to register for?
To find out which event is best for you, try the following:
Set the user parameter CRM_EVENT_TRACE to X. You can find this in the menu under System -> User Profile -> Own Data, tab Parameters.
Run your transaction as normal. In a separate session, call transaction CRMD_EVENT_TRACE. The no. of records shown is set to 250 as default. You may need more. While working in your transaction, you can refresh the trace report. This will be automatically updated. As a result, you will be able to see which events have been set, which execution times have been reached, and you can hopefully decide which combination of event, object and execution time is best for you.
1. Maintenance of CRMC_EVENT_CALL
CRMC_EVENT_CALL is used to register function modules for events.
When an event is published, the event handler finds all function modules (callbacks) registered for this event and runs them at the appropriate time.
Fields in CRMC_EVENT_CALL:
Transaction category (SUB_TYPE)
Business transaction category (Sales, service, contact, opportunity etc.). This can be the general CRM transaction category BUS20001 (this makes the entry available to everyone) or it can be more specific (for example, BUS2000114 only applies to leasing scenarios).
Please note: every process type contains a main transaction category (generally sales BUS2000115) followed by secondary transaction categories. For example, the process type SRVO (Service order) contains the categories Sales (BUS2000115), Service (BUS2000116) and Contact (BUS2000126). If the entry you require exists for your main category, you do not need to recreate an entry for the secondary 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 the processing of a transaction, for example, end of item processing, end of header processing, before save. When the event you are registered for is published, you may need to react immediately, or you may want to wait until a later time-point. For example, if partner data is changed, then the pricing data needs to be checked immediately (execution time 001). Orgman however can wait until the end of header processing(execution time 030) to react to this change.
Note: You should not use exe_time immediately (001) if you register for the event SAVE.
Execution times are maintained under Definitions- Execution times.
Priority (PRIO)
Priority of callback. Acts as an additional sort criterion as to when callbacks are carried out.
Object name (OBJ_NAME)
The object you are interested in (e.g. Partner, Orgman).
Note: Objects are maintained under Definitions- Objects.
Event (EVENT)
The event you are interested in (e.g. after_create, save, end of header processing).
Note: Events are maintained under Definitions- Events.
Attribute (ATTRI1)
The attribute is used as a filter to cut down on the number of function modules called. Depending on the object or set, you may not always need to react to an event being published. If you always need to react to a particular event, then you should set ATTRI1 to SPACE or <*>. You can assign an attribute to the callback so that it only reacts when this attribute is set. This attribute is used for example 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 etc.). 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 SPACE or <*> for one of these sets, then your callback will react to every event published by this set.
Function (FUNC_NAM)
The name of your callback (it should begin with CRM and end in EC). Before you can enter a callback in this view, it has to be assigned to an object function.
Note: Callbacks can be assigned to object functions under Definitions- Object function/Callbacks.
Object functions can be defined under Definitions- Object functions.
Perform function for document header (ONLY_HDR)
The callback should be carried out at header level.
Perform function for document item (ONLY_ITM)
The callback should be carried out at item level.
Do not process function if error occurs (ERROR_CHECK)
If, for some reason, the callback raised an error, this flag causes the message to be passed on to the calling program.
For example, if the user enters the wrong product, then you may not want your callback to be processed.
Call callback (CB_FREQ)
Frequency and characterization of the callback. This attribute is very, very, important! It determines how often the function module should be called. The following values are allowed:
    • Call to Header/Item, with Object, Event, Attr., Old/New Data (SPACE)
      The callback can be carried out for headers and items. The callback is provided with the object name, the event, old and new data. Old data is the old version of the work area structure. New data is the new version of the work area structure. The structure to be passed is defined in table CRMC_EVENT_STRUC. If  old and new data are required and the callback should run immediately (Exe_time = 001) once an event is published, you must use this setting and not 'K'.  (K is explained below).
    • Call to Header/Item with Object, Event, Attr. W/Out Old/New (A)
      Like SPACE, but without old and new data.
    • Call to Header/Item, W/Out Object, Event, Attr.,Old/New Data (B)
      The callback can be carried out for header and items. Old and new data are not provided.
    • Call Just Once Per Transaction (C)
      The callback is carried out only once per transaction. Old and new data are not provided. Note: This is the only setting that should be used with EXE_TIME 080 (Save).
    • 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. This means that if an event is published more than once, you get 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 react later. However, for specific partner data, i.e. if you are registered for a change to a specific partner function (field attri1 = 0001 or similar) and not general partner changes (field attri1 = <*> ) you need to use SPACE, as partner data cannot be cumulated.
Changed on (CHANGED_AT)
Date of change to record
Changed by (CHANGED_BY)
User who made the change
ONLY_ONE_CALL= this flag has no relevance as of release 3.0.
2. How the event handler selects callbacks
The event handler selects callbacks for each transaction and item type. For the transaction type, the selection is as follows:
In table CRMC_PR_ASSIGN, business objects are found for a transaction type. Note: There is also a business object BUS20001. Entries in CRMC_EVENT_CALL for this business object  are valid for all transaction types.
In tables CRMC_OBJECT_ASSI and CRMC_OBJ_ASSI_I,  the allowed set objects are determined for the business objects.
In table CRMC_OBJECT_FUNC, object functions are determined for the set objects.
In table CRMC_FUNC_ASSIGN,  the allowed callbacks are determined from the object functions.
In addition, there is a function module, CRM_EVENT_FILTER_PROC_TYPE_OW which exists to filter out additional object functions based on object-specific and transaction-type-specific Customizing.
For the item type, the selection is as follows:
In table CRMC_IT_ASSIGN, business objects are found for an item type. Note: There is also a business object BUS20001. Entries in CRMC_EVENT_CALL for this business object  are valid for all  item types.
In table  CRMC_OBJ_ASSI_I,  the allowed set objects are determined for the business objects.
In table CRMC_OBJECT_FUNC, object functions are determined for the set objects.
In table CRMC_FUNC_ASSIGN,  the allowed callbacks are determined from the object functions.
In addition, there is a function module, CRM_EVENT_FILTER_ITEM_TYPE_OW which exists to filter out additional object functions based on object-specific and item-type-specific Customizing.
3. Definitions
The definition section contains the following:
    • Events: The events that can be published in the event handler
    • Objects: The objects that are used to design a transaction type or item type
    • Structure for Event/Object: If an object wishes to pass information when publishing an event (for example, new quantities in an order or changed partner data), then a structure is required to do so. The structure is entered in this table 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 functions: Object functions are assigned to objects.
    • Object functions/Callback: Callbacks are assigned to object functions.
    • Objects: The objects and sets available to design a 1Order transaction.
    • Times: These are the execution times that can be set during the various processing stages of a transaction. For example, initialization, delete, save, end of header processing.
4. Checks
If  you enter a transaction type and click the execute button, you will get a list showing all callbacks that are relevant to the transaction type. If  you enter a transaction type +  item type and click the execute button, you will get a list showing all callbacks that are relevant to the item type.  You need to enter both 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. If this is the case, then you should adjust the customizing tables accordingly or enhance the filter function modules mentioned above.

Post a Comment

Powered by Blogger.