Designing
ECI naming conventions
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 VMware Smart Assurance
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
VMware Smart Assurance
NOTIF Editor
tree viewApr -
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:VMware Smart Assurance
NOTIF
Editor tree view1996 -
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
VMware Smart Assurance
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.