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:



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:

Table 1. Node Identifiers
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 nodeId and processId. That is, a process cannot span servers. A process that begins on one particular node cannot suddenly start reporting a different nodeId.
  • A process can contain zero or more steps.
  • A file transfer can occur on its own or within the context of a process.