Overview
Regardless of how events are posted, each event must identify the node (or server) the event
occurred within. This is done by providing a unique nodeId which must follow this
pattern:
[node type code]/[node ID]
The first element of the nodeId identifies what type of node is
publishing the event. All subsequent elements of the nodeId are used to identify
the node. Multiple elements can be used to convey a logical or geographical hierarchy. Examples:
cron/crsvr1412.acme.com
cron/us-nc/crsvr1412.acme.com
In these two examples, the node type code is "cron" which tells us that these events
are coming from a "cron" type of server (though cron is really just a process that runs on a
server). The first example keeps it simple while the second example organizes servers by location.
What you use for your node type code is up to you but it must be used consistently and must be the
first element of your slash-delimited nodeId. However, do not use any of the
following node type codes, which are reserved for future use:
| Node Type Code | Description |
|---|---|
| adcom | B2B Advanced Communications |
| cceng | IBM Control Center engine |
| ccwc | IBM Control Center Monitor Web Console |
| cd | Connect:Direct |
| ce | Connect:Enterprise |
| cx | Connect:Express |
| b2bi | B2B Integrator |
| fgate | Sterling File Gateway |
| ftp | FTP Server |
| gm | Global High Availability Mailbox |
| mqmft | MQ Managed File Transfer |
| proxy | Sterling Secure Proxy |
| spe | Standards Processing Engine |
Event Type
IBM Control Center recognizes the following types of events:
| Event Type | Description |
| File transfer | A file received, sent, or transferred. |
| Heartbeat | An event, sent at regular intervals, to let IBM Control Center Monitor know the server is still "alive". |
| Process | A process executed. |
| Server command | A command was received or issued by the server. |
| Server status | The status of the server has changed. |
Processes and File Transfers
Processes and file transfers both represent potentially long-running transactions that start at time A and end at time B. While IBM Control Center allows you to collect many events and post them all at once, you may end up posting process started and file transfer started events in one batch, while posting process ended and file transfer ended events in another. To correlate these events, it is important to follow a few simple rules:- Every process must have a unique identifier.
- All events for a given process must report the same
nodeIdandprocessId. That is, a process cannot span servers. A process that begins on one particular node cannot suddenly start reporting a differentnodeId. - A process can contain zero or more steps.
- A file transfer can occur on its own or within the context of a process.