Apama 10.3 | Apama Capital Markets Foundation Documentation | Capital Markets Foundation | Utilities | Adapter status bridge service
 
Adapter status bridge service
The adapter status bridging service is part of the Status Utils bundle. It provides bridging of com.apama.statusreport.* events between two correlators, so that an application in the client correlator can monitor the status of an adapter connected to the server correlator. A bridge instance is configured by sending configuration events to the client and server correlators. On the client side, send a com.apama.statusreport.ConfigureClientSideBridge event, and on the server side, send a com.apama.statusreport.ConfigureServerSideBridge event. See the ApamaDoc for these events for details about their fields. In most cases, the fields of the client and server configuration events for a given bridge instance are identical. However, the instanceName field must be unique across all status bridges used by the application.
In addition to configuring the bridge itself, an application should also configure monitoring of the fake adapter connection between the two correlators. Use an instance of the com.apama.connection.IAFStatusFaker and an instance of the com.apama.adapters.IAFStatusToStatusConvertor service on each side of the connection. If this is not done, the status bridge will not forward any events in either direction because the inter-correlator connection will appear to be down. The generic adapter bridging service described above handles this automatically; it is recommended that applications use this service wherever possible. This should always be the case, as it is no more than the adapter service monitors would need to do if all of the instances were running in the same correlator. Otherwise, see the implementation of the com.apama.adapter.bridge.ConfigBridge service in the Adapter Bridging Utils bundle to see how bridge connection monitoring is implemented.
Once the bridge is configured, com.apama.statusreport.SubscribeStatus or UnsubscribeStatus events routed by the client-side application for the bridged service will be forwarded to the server correlator, where they should be handled by the adapter service as normal. Any Status or StatusError events generated by the adapter service will in turn be forwarded back to the client correlator where they can be handled by application listeners in the usual way.
The adapter bridge deals with multiple clients bridging to the same server-side adapter service in the following ways:
*Each client correlator should configure a separate bridge connection with a unique instanceName field and channel.
*Multiple bridge clients within the same correlator should set up status subscriptions in the usual way; these subscriptions will be reference counted by the client-side bridge.
Note: The generic bridging service may not be suitable if the application does not want status, market data and order management services to be bridged, although there is generally no harm in setting up bridging for services that are not going to be used. The generic service will also not work for more complex configurations, such as different service names on the client and server sides of the bridge.

Copyright © 2013-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.