DataSource applications are highly configurable.
Once you’ve built a DataSource application (such as an Integration Adapter) using the Caplin Integration Suite, the C DataSource API or the DataSource.NET API, you can configure it. You do this through settings supplied in one or more configuration files, or through settings that are stored in a database and supplied to the DataSource application by a configuration script. When you define the configuration in files, you’d normally make these files part of a Platform Blade that packages up the DataSource application (typically it would be an Adapter blade) - see Using blades to simplify configuration below.
What do I need to configure in my DataSource application?
The configuration for a DataSource application includes:
A label that is unique within the network of connected DataSource applications.
Connection details for each of the DataSource application’s peers.
Here’s an example of the DataSource configuration for an Integration Adapter that handles FX trades. The Adapter is called
FXTradingAdapter and has a unique label
FXTradingAdapter01. It talks to both a Liberator and a Transformer, and when it starts up it initiates the connection to each of them.
The Platform deployment would look like this:
The configuration for the FX Trading Adapter would look like this. The Adapter’s called
FXTradingAdapter and it has a unique label (
# # DataSource configuration for FX Trading Adapter # datasrc-name FXTradingAdapter # Unique label identifying this Adapter: datasrc-local-label FXTradingAdapter01 # # Configuration defining this Integration Adapter's connection to LiberatorA. # add-peer remote-name LiberatorA remote-label LiberatorA addr <liberator host name or ip address> port 15000 local-type active|contrib heartbeat-time 15 heartbeat-slack-time 5 end-peer # # Configuration defining this Integration Adapter's connection to TransformerA. # add-peer remote-name TransformerA remote-label TransformerA addr <transformer host name or ip address> port 15001 local-type active|contrib heartbeat-time 15 heartbeat-slack-time 5 end-peer
This is what the
add-peer … end-peer configuration that specifies each of the Trading Adapter’s peers means:
remote-nameis the name by which the Adapter knows the peer.
remote-labelis the unique label that identifies the peer.
addris the host name or IP address of the peer.
portis the TCP port number to which the Adapter sends connection requests to the peer.
local-type active|contribmeans that the FX Trading Adapter accepts active subscription requests from the peer, and it also accepts data (contributions) from the peer.
heartbeat-slack-timedefine the rate at which heartbeat messages are exchanged between the Adapter and its peers to ensure that the connection between them is kept open when no data is being exchanged.
And here’s the DataSource configuration for the Liberator that talks to both the Transformer and the FX Trading Adapter. The Liberator’s called
LiberatorA and it has a unique label
# # DataSource configuration for LiberatorA. # datasrc-name LiberatorA # Unique label identifying this Liberator: datasrc-local-label LiberatorA datasrc-port 15000 # # Configuration defining this Liberator's connection to TransformerA. # add-peer remote-name TransformerA remote-label TransformerA remote-type active|contrib heartbeat-time 15 heartbeat-slack-time 5 end-peer # # Configuration defining this Liberator's connection to the FX Trading.Adapter # add-peer remote-name FXTradingAdapter remote-label FXTradingAdapter01 remote-type active|contrib heartbeat-time 15 heartbeat-slack-time 5 end-peer
Note that in the configuration for each peer connection the
remote-label must match the
datasrc-local-label in that peer’s configuration. The
remote-type setting for each peer (in this case for Transformer and the Trading Adapter) tells the Liberator that the peers support active subscriptions, so the Liberator can send them subscription requests, and that they also accept data (contributions) from the Liberator.
Finally, here’s the DataSource configuration for the Transformer that talks to both the Liberator and the FX Trading Adapter. The Transformer’s called
TransformerA and it has a unique label (
# # DataSource configuration for TransformerA. # datasrc-name TransformerA # Unique label identifying this Transformer: datasrc-local-label TransformerA datasrc-port 15001 # # Configuration defining this Tranformers's connection to LiberatorA. # add-peer addr <liberator host name or ip address> port 15000 remote-name LiberatorA remote-label LiberatorA local-type active|contrib heartbeat-time 15 heartbeat-slack-time 5 end-peer add-peer remote-name FXTradingAdapter remote-label FXTradingAdapter01 remote-type active|contrib heartbeat-time 15 heartbeat-slack-time 5 end-peer
This configuration is very similar to the Liberator’s. The main difference (apart from names) is that the Transformer initiates the connection to the Liberator (
port 15000 in the
add-peer … end-peer setup for the Liberator), but not to the Trading Adapter. In reality you would probably want to access the FXTradingAdapter from Liberator and Transformer through a configured data service.
local-type active|contrib option in the
add-peer configuration for the Liberator means that the Transformer will accept subscription requests and contributions from the Liberator peer. Conversely the
remote-type active|contrib option in the
add-peer for the Trading Adapter tells the Transformer that the Trading Adapter supports active subscriptions, so subscription requests can be sent to it, and the Adapter will accept contributions from the Transformer.
You might have noticed that whereas the
add-peer items in the Integration Adapter and the Transformer configuration specify connection addresses (
addr) and port numbers (
port), the Liberator configuration doesn’t have this information in its
add-peer items. These items aren’t needed in the Liberator’s peer configuration because the Integration Adapter and the Transformer connect in to the Liberator, rather than the Liberator initiating the connections. Similarly, the Transformer configuration for the Integration Adapter peer connection doesn’t need
port options because the Adapter connects in to the Transformer.
How do I create custom configuration items?
If you’re writing a C or C++ based DataSource application, such as an Integration Adapter, you can create new configuration items that are specific to your application. Just call the appropriate configuration functions in the C DataSource API. For more about this, see the "Configuration API" page in the C DataSource API Documentation.
Using blades to simplify configuration
When you develop an Integration Adapter using the Caplin Integration Suite , the Adapter is generated as an Adapter blade, that includes all the configuration necessary for it to connect to a Liberator and/or Transformer.
Liberator and Transformer are also supplied with Config blades that implement specific features without you needing to write your own configuration; for example, see the list of Liberators blades that are supplied with the Deployment Framework.