SAP EM Blog Series #9 – Deciding on what parameters to use
In my last blog we spoke about the sizing considerations to take in to account for an SAP EM server. Now let’s go in to one of the most asked question in SAP Event Management – “Which type of the 4 available parameters should we use? Firstly, what are the 4 parameters that we are talking about?
1 – Info Parameter
Attribute of a trackable object stored against an EH in table /SAPTRX/EH_INFO – Stored as a name – value pair (PARAM_NAME stores the name of the parameter / attribute and PARAM_VALUE stores the actual value of the attribute. E.g. PARAM_NAME – CURRENCY and PARAM_VALUE = USD. PARAM_INDEX can be used to store different values to allow for the occurrence of multiple parameters with the same name. This parameter can be shown in the SAP EM Web UI on the Event Handler selection screen, list and Detail view.
2 – Control Parameter
Attribute of a trackable object stored against an EH in table /SAPTRX/EH_CNTRL – Similarly the values are stored as name – value pairs. Notice that the only difference between these 2 parameter tables is the length of the PARAM_VALUE field. The Info parameters can be 255 in length whereas the control parameter can only be 60 in length… This parameter can be shown in the SAP EM Web UI on the Event Handler selection screen, list and Detail view.
3 – System Parameter
Attribute of a trackable object stored against an EH in a Z table – The ONLY reason to store a parameter in a z-table (system parameter) is when it is frequently used as part of a query search to retrieve EHs. System parameters ultimately get stored in named, physical database fields that can have indexes created against them. Without an index being created for a field in the extension table renders it pretty much useless since without the applicable index the query would not be faster than if it were stored as a control or info parameter. See an example below. Notice the key is just the EH_GUID. This parameter can be shown in the SAP EM Web UI on the Event Handler selection screen, list and Detail view.
Note: A view called ZV_[system parameter name] is created as a join between /SAPTRX/EH_HDR and your system parameter table.
Z Table with defined field for each parameter
4 – Event Message Parameter
Attribute applicable to a particular instance of an event. It describes a certain characteristic specific to the event that is attached to the EVT_GUID (The unique ID for that event). It typically should not be stored against the EH because it only applies to that one event. This parameter can be shown in the SAP EM Web UI on the Event Message list and Detail view. Note: The key to the z table that stores the event message parameter is the Event GUID. Its intended use is drastically different from the extension table of the EH. The EH extension table is used to improve performance of queries whereas the event message extension table is used to store extra data describing the event that it is associated with.
Z table with defined fields for each message parameter
Now it comes down to decision time – Decision Tree
A decision must be made on which parameter type to use for each attribute of an Event Handler or Event Message. For performance reasons, it is best to split values between the info and control parameter tables. Below is an example of a decision tree used to decide on the parameter type:
I don’t think I need to go through all the words in the tree – Hopefully it’s self explanatory and is useful to you. Please leave a comment if you have other ideas or inputs for this decision tree that I use.
In my next blog I’ll take a look at the available web services in SAP Event Management. Come back and take a peak soon…
for the decision tree i would favor the following way:
Whenever you are sure that a parameter can only have 1 value you should use System Parameter independant if it is a field that you plan to use for queries. System Parameter are more flexible and can later also be used for archive info structures. You can also save some disk space as for a Control/Info Parameter always the Param name, Length etc. is stored.
It is also worth reading note 1260125 - Configuring search fields for the Web Interface.
Thanks for the input Steffen. Your point on the new archiving procedure is definitely a consideration knowing that parameters aren't allowed to go in to the info structure (A big issue for us as a side note). I may update the blog shortly with that as a consideration.
Nice blog Kevin!
Can you give more details about 'Will it be used for Control purposes?'
What exactly are Control Purposes in this context?
I've seen some projects where only System and Control Parameters were used (i.e. no Info parameters). If all the parameter lengths are less than < 60 can we then avoid Info parameters? Or is there a performance consideration that makes it necessary to have some defined as Info parameters?
the only difference is the length. This was needed because of the use of the Workflow Conditions as they have a restriction to 60 charcaters. But as they should not used anyway because of performance reasons there is no real difference between Info and Control Parameter. In the activitiy interface both are available.
If you need indexed Parameters and you want to query them together it can make sense to have one as Control and one as Info Param. See note 1260125 for further explanation.