DataSource configuration
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.
Liberator and Transformer, being C-based DataSource applications, are also configured in the same way. They have their own, application specific, configuration settings too.
What do I need to configure in my DataSource application?
The configuration for a DataSource application includes:
-
Its name.
-
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:
![Platform deplyment diagram for Liberator and Transformer talking to an FX Trading Adapter](../../../images/DataSource_Configuration_Example_1.png)
The configuration for the FX Trading Adapter would look like this. The Adapter’s called FXTradingAdapter
and it has a unique label (datasrc-local-label
) of FXTradingAdapter01
# # 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-name
is the name by which the Adapter knows the peer. -
remote-label
is the unique label that identifies the peer. -
addr
is the host name or IP address of the peer. -
port
is the TCP port number to which the Adapter sends connection requests to the peer. -
local-type active|contrib
means that the FX Trading Adapter accepts active subscription requests from the peer, and it also accepts data (contributions) from the peer. -
heartbeat-time
andheartbeat-slack-time
define 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 (datasrc-local-label)
of LiberatorA
.
# # 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 (datasrc-local-label
) of TransformerA
.
# # 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.
The 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 addr
and 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 use the Caplin Platform Deployment Framework, the availability of Caplin Platform blades makes it much easier to configure your Integration Adapters, Liberator and Transformer.
-
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.
See also:
-
DataSource For C Configuration Syntax Reference (Explains the syntax of the datasource configuration.)