RE 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:
o 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).
o Call to Header/Item with Object, Event, Attr. W/Out Old/New (A)
Like SPACE, but without old and new data.
o 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.
o 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).
o 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:
o Events: The events that can be published in the event handler
o Objects: The objects that are used to design a transaction type or item type
o 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.
o 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.
o Object/ Object functions: Object functions are assigned to objects.
o Object functions/Callback: Callbacks are assigned to object functions.
o Objects: The objects and sets available to design a 1Order transaction.
o 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.