# DataSource configuration DataSource applications are highly configurable. Once you’ve built a [DataSource application](index.md) (such as an [Integration Adapter](../platform-architecture/putting-data-into-the-platform.md)) using the [Caplin Integration Suite](../cis/index.md), the [C DataSource API](https://docs.caplin.com/developer/api/datasource_c/latest/) or the [DataSource.NET API](https://docs.caplin.com/developer/api/datasource_dotnet/latest/), 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](#using-blades-to-simplify-configuration) below. [Liberator](../liberator/index.md) and [Transformer](../transformer/index.md), 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: ![DataSource_Configuration_Example_1](../../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 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 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](datasource-active-subscription-model.md) from the peer, and it also accepts data (contributions) from the peer. * `heartbeat-time` and `heartbeat-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](datasource-active-subscription-model.md), 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 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](datasource-data-services.md). 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](datasource-active-subscription-model.md), 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](../deployment-framework/index.md), the availability of [Caplin Platform blades](../platform-architecture/platform-blades.md) 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](../liberator/liberator-configuration-and-blades.md). --- **See also:** * [DataSource For C Configuration Syntax Reference](datasource-configuration-syntax.md) * [DataSource configuration reference](datasource-datasource-configuration-reference-introduction.md) * [Data services](datasource-data-services.md) * [The Caplin Platform Deployment Framework](../deployment-framework/index.md) * [Caplin Platform blades](../platform-architecture/platform-blades.md)