The StatusSupport.mon ships with Apama. The com.apama.statusreport interface, defined in StatusSupport.mon, is a companion protocol to com.apama.oms and com.apama.marketdata for detecting and handling connection status issues. Please note that the com.apama.statusreport interface is not specific to capital markets applications. This section presents a de-facto standard pattern for using the interface that is expected to be used by all Apama capital markets adapters. Adapters in other application areas may choose to use different status reporting patterns.

One of the main things that this interface is used for is to give users and algorithms access to the IAF connectivity information produced by the com.apama.adapters protocol.

Please note that the CMF contains a number of utilities for dealing with this protocol. The ConnectionMonitor.mon service can convert com.apama.adapters events into com.apama.statusreport events. Normally this configuration event would be sent by an adapter’s logon manager service. The StatusPublisher object can be used to implement other status publishers. It implements reference counting and ensures correctly formatted status messages.

The actors in com.apama.statusreport include:

The events in com.apama.statusreport include:

The temporal rules for the status report interface are basically the same as for market data. We have a subscription based service, where consumers must subscribe and unsubscribe. If the reference count of a subscription is greater than 0 the publisher should distribute status events. Unlike the market data interface there are error events that can be associated with a subscription. These should only occur after a subscription event has been sent, and when the reference count is above 0.

Authority rules and cardinality rules are symmetric to the market data protocol.

The status event itself contains a Boolean value that specifies whether an object is available for a given connection, service, and sub service. The summaries field contains a selection of adapter specific tags adding additional status information and there is also an extraParams field for anything else.

The exact usage of the fields serviceId, object, subServiceId, and connection are adapter specific, see the documentation for each to see what values are supported. However, a de-facto standard has developed around the pattern used in the adapters supported by the FX Aggregator solution accelerator and this should be followed, as far as possible, for all new adapters. This pattern expresses a minimum set of requirements; individual adapters can and should expose more detailed status information as long as this is documented clearly.

A status subscription for (SERVICE_NAME, Adapter, "", Market) should therefore succeed for any adapter following this pattern.

The adapter object represents the overall status of the adapter including the service monitors, the connection from the correlator to the IAF, the codec/transport, the connection to the remote service, any required login to the service and readiness of the service to handle subscriptions/orders/etc. The available flag of status events for the adapter service should only be true if the adapter is in a state where any subscription requests or order management events sent in by a client will be accepted by the adapter and passed through to the underlying remote service.

Several standard values have also been defined for the summaries sequence in the status event. These should be used where possible rather than defining new values for the summaries:

Adapters are free to define additional objects, subServiceIds, and summaries keys to express more fine-grained status if desired (for example, a market data adapter can use the Status interface to indicate subscription errors for specific instruments without using the unreliable Tick or DepthSubscriptionError events).