Cisco Cisco Configuration Engine 3.5 Entwickleranleitung
2-6
Cisco Configuration Engine Software Development Kit API Reference and Programmer Guide 3.5
OL-17661-02
Chapter 2 Event Service and IMGW
Event Bus Interface
Figure 2-3
IMGW separates Event Gateway functions into three separate modules
Event Bus Interface
The Event Bus interface handles all interactions with external workflow engines. You can subscribe to
or publish events on this Event Bus. The current Event Gateway uses the Tibco Event Bus protocol. This
logic is separated to enable using a different Event Bus, such as CORBA, or even use an entirely different
event management scheme.
or publish events on this Event Bus. The current Event Gateway uses the Tibco Event Bus protocol. This
logic is separated to enable using a different Event Bus, such as CORBA, or even use an entirely different
event management scheme.
Device Interface
The device interface has been enhanced and modularized to allow support for many different types of
devices. Currently, the Event Gateway only supports devices running the Cisco IOS version of the Event
Agent. Because there are many different versions of Cisco IOS in use, it is desirable to support older
versions of IOS. In addition, there are many non-Cisco IOS devices (such as CatOS-based switches) that
are a major part of Cisco’s product line. Such devices can be supported by a Telnet Gateway module.
The advantage of this type of architecture is that at some point in the future, if desired, it is extensible
to new types of interaction with other devices. For example, there are many non-Cisco devices on the
market that do not have a telnet daemon in them, but rather, are controlled entirely by HTTP. With this
type of architecture, an “HTTP Gateway” module could be written to communicate with such devices.
devices. Currently, the Event Gateway only supports devices running the Cisco IOS version of the Event
Agent. Because there are many different versions of Cisco IOS in use, it is desirable to support older
versions of IOS. In addition, there are many non-Cisco IOS devices (such as CatOS-based switches) that
are a major part of Cisco’s product line. Such devices can be supported by a Telnet Gateway module.
The advantage of this type of architecture is that at some point in the future, if desired, it is extensible
to new types of interaction with other devices. For example, there are many non-Cisco devices on the
market that do not have a telnet daemon in them, but rather, are controlled entirely by HTTP. With this
type of architecture, an “HTTP Gateway” module could be written to communicate with such devices.
Event Bus Interface
To send a configuration to a device, a node on the Event Bus should publish on a subject of the format
cisco.mgmt.cns.config.load.dev_id and possibly cisco.mgmt.cns.config.sync-status.dev_id, and
subscribe to the cisco.mgmt.cns.config.complete.dev_id, cisco.mgmt.cns.config.failure.dev_id, and
cisco.mgmt.cns.config.warning.dev_id subjects. The functions and formats of these messages are
described earlier in this document. The .dev_id suffix is translated by the Namespace Mapper into two
pieces of information: an internal subject without the suffix (for example, cisco.mgmt.cns.config.load)
and a device ID (inferred from the suffix). This simplifies matters for application processing modules,
such as the Configuration Agent, because they do not need to know anything about decoding the
destination of an event from the subject. It also allows router groups to be defined, where the suffix does
not refer to an individual router, but rather, to a group of routers.
cisco.mgmt.cns.config.load.dev_id and possibly cisco.mgmt.cns.config.sync-status.dev_id, and
subscribe to the cisco.mgmt.cns.config.complete.dev_id, cisco.mgmt.cns.config.failure.dev_id, and
cisco.mgmt.cns.config.warning.dev_id subjects. The functions and formats of these messages are
described earlier in this document. The .dev_id suffix is translated by the Namespace Mapper into two
pieces of information: an internal subject without the suffix (for example, cisco.mgmt.cns.config.load)
and a device ID (inferred from the suffix). This simplifies matters for application processing modules,
such as the Configuration Agent, because they do not need to know anything about decoding the
destination of an event from the subject. It also allows router groups to be defined, where the suffix does
not refer to an individual router, but rather, to a group of routers.
Note that it is not possible to do a two-stage commit when using telnet. The purpose of this event is to
inform devices to apply a previously downloaded configuration, so as to minimize the time during which
there is an inconsistent state of network element configuration. However, because the devices do not
have intelligence in them to hold an un-applied configuration, it is not possible to implement this event
using this gateway. Therefore, this event is ignored if it is sent by applications.
inform devices to apply a previously downloaded configuration, so as to minimize the time during which
there is an inconsistent state of network element configuration. However, because the devices do not
have intelligence in them to hold an un-applied configuration, it is not possible to implement this event
using this gateway. Therefore, this event is ignored if it is sent by applications.
75505
Event bus
Business logic
Tibco
Namespace Manger
Agent Proxies
Statistics Monitor
Other applications
Agent Proxies
Statistics Monitor
Other applications
IOS Event Agent
IOS legacy
Cisco non-IOS
non-Cisco
IOS legacy
Cisco non-IOS
non-Cisco
Devices