Although the naming of ECI objects is determined by the designer of the adapter, it is worth noting here as the entire structure of the ECI tree is based on how this is accomplished. As an example, assume that events are built based upon the date. Some events may use the time format mmm/dd/yyyy, others may use yyyy/mmm/dd. If the former is used, (mmm/dd/yyyy), the month shows up as the primary ID (eventBaseID), and the NOTIF Editor branch shows based on month:
Raw event wrapper of IDs
DATE.Apr_01_1996
DATE.Apr_01_1997
Specific defined ECIs
ECI-DATE.Apr_01_1996
ECI-DATE.Apr_01_1997
NOTIF Editor tree view
Apr -
01 -
1996
1997
1998
02 -
…
A single ECI may be defined to process any month of any year on a specific day by creating ECI-DATE.*_01_*
However, a common ECI cannot be created to process any day of any year given this wrapper format. If the wrapper format was yyyy/mmm/dd, then the tree would appear as:
NOTIF Editor tree view
1996 -
Apr -
01
02
...
1997 -
Apr -
01
02
...
1998 -
Apr -
...
In this case, an ECI could be ECI-DATE.*_*_01 to process any event on the 1st:
ECI-DATE.*_Apr_* to handle any event in April.
ECI-DATE.1996_*_* to handle any event in 1996.
ECI-DATE.*_*_* to handle any event.
There are two issues from the previous example, first is the view from the NOTIF Editor where it is undesirable to have hundreds of ECI objects showing under one branch. Second is the selection of what fields are used for the eventBaseID, eventSubID1, eventSubID2 fields greatly impact how ECI objects are designed.
