StatusSupport events
The StatusSupport event interface is defined in the StatusSupport.mon file, which is found in the monitors directory of the Apama installation (note, this is not the same directory as adapters\monitors).
All of the StatusSupport events contain the following fields:
serviceID — The service ID to subscribe to, a blank in this field targets all services
object — The object to request status of - this may include:
“Connection" - whether connected or not
"MarketState" - a market may be "Open", "Closed", or other states
subServiceID — The subService ID to subscribe to. Some services may expose several services. The interpretation of this string is adapter-specific.
connection — The connection to subscribe to. Some services may expose several services. The interpretation of this string is adapter-specific.
The StatusSupport interface defines the following events:
SubscribeStatus — This event is sent to the service monitor to subscribe to status.
event SubscribeStatus {
string serviceID;
string object;
string subServiceID;
string connection;
}
UnsubscribeStatus —
event UnsubscribeStatus {
string serviceID;
string object;
string subServiceID;
string connection;
}
Status —
event Status {
string serviceID;
string object;
string subServiceID;
string connection;
string description;
sequence<string> summaries;
boolean available;
wildcard dictionary <string, string> extraParams;
}
The additional fields for the Status event type are:
description — A free-form text string giving a description of the status.
summaries — The status of the object requested. This will be a well recognized sequence of words - for example, a financial market's "MarketState" may be "Open", "Closed", "PreOpen", etc. A Connection may be "Connected", "Disconnected", "Disconnected LoginFailed", "Disconnected TimedOut", etc. There should be at least one entry in the sequence.
available —
true if the object is "available" - the exact meaning is adapter specific; for example, connected, open for general orders, etc.
extraParams — Extra parameters that do not map into any of the above. Convention is that keys are in title case, for example, "Username", "CloseTime", etc.
A Status event does not denote a change of state, merely what the current state is — in particular, one will be sent out after every SubscribeStatus request.
Any adapter specific information that the application needs to supply or be supplied can be passed in the extraParams dictionary — these are free-form (though there are conventions on the keys, see below).
StatusError —
event StatusError {
string serviceID;
string object;
string subServiceID;
string connection;
string description;
boolean failed;
}
The additional field for this event type is:
failed — Whether the subscription has been terminated. Any subscribers will need to send a new SubscribeStatus request after this.
Note that the purpose of the StatusError event is to report a problem in the delivery of status information, not to report an error status. A StatusError should be sent when the service is unable to deliver status for some reason. For example, reports on the status of an adapter transport's connection to a downstream server cannot be sent if the correlator has lost its connection to the adapter — in this case the service would be justified in sending a StatusError event for the downstream connection status. However, in the same situation the service should continue to send normal Status events for the correlator-adapter connection status, as this status is known. The available flag in these Status events would of course be set to false to indicate that the connection is down.
If the failed flag in a StatusError event is true, this indicates that the failure in status reporting is permanent and any active status subscriptions will have been cancelled and receivers will need to re-subscribe if they wish to receive further status updates from the service. If the failed flag is false, the failure is temporary and receivers should assume that the flow of Status events will resume automatically at some point.