# Dynamic Data Services

Dynamic Services enables adapters to configure Liberator and Transformer with data routing rules at the time of peer connection.

**Available from:** Platform 8

## Overview

[Data services](datasource-data-services.md) specify the data routing rules in Caplin Platform, mapping subject requests to the DataSource instances that serve them.

Statically defined data-services are defined with [`add-data-service`](../datasource/datasource-data-services-configuration.md#add-data-service) in the configuration of consuming DataSources, such as Liberator. Adding static routing rules for a new adapter requires downtime to define a new data-service in the consuming peers' configuration.

**Static peer configuration and static data-service configuration**

```plantuml
[Liberator1\n<color:gray>192.168.1.100</color>] as Liberator1
[PricingAdapter1\n<color:gray>192.168.1.50</color>] as PricingAdapter1

PricingAdapter1 -right-> Liberator1

note bottom of Liberator1
datasrc-local-label Liberator1

<color:blue>~# Incoming peer connection</color>
add-peer
  remote-label PricingAdapter1
end-peer

add-data-service
    service-name PricingService
    include-pattern ^/FX
    add-source-group
        add-priority
            remote-label PricingAdapter1
        end-priority
    end-source-group
end-data-service
end note

note bottom of PricingAdapter1
datasrc-local-label PricingAdapter1

<color:blue>~# Outgoing peer connection</color>
add-peer
  addr 192.168.1.100
  port 14001
end-peer
end note
```

In contrast, dynamically defined data-services are configured using [`add-provided-data-service`](../datasource/datasource-data-services-configuration.md#add-provided-data-service) in the configuration of the providing DataSources and are applied to consuming DataSources in the peer connection handshake. Consuming peers do not need to be restarted after receipt of a provided data-service.

**Dynamic peer configuration and dynamic service configuration**

```plantuml
[Liberator1\n<color:gray>192.168.1.100</color>] as Liberator1
[PricingAdapter1\n<color:gray>192.168.1.50</color>] as PricingAdapter1

PricingAdapter1 -right-> Liberator1

note bottom of Liberator1
datasrc-local-label Liberator1

**add-apikey "f9912b266<color:blue>...</color>ea25e047" <color:gray><U+2926></color>**
    **"ds-connect,ds-dynamic-peer, <color:gray><U+2926></color>**
    **ds-dynamic-service,ds-dynamic-fields"**
end note

note bottom of PricingAdapter1
datasrc-local-label PricingAdapter1

<color:blue>~# Outgoing peer connection</color>
add-peer
  addr 192.168.1.100
  port 14001
  **apikey "9702ff...029b491"**
end-peer

**add-provided-data-service**
    **service-name PricingService**
    **apply-if-label ^Liberator[0-9]+**
    **include-pattern ^/FX**
    **remote-label-regex ^PricingAdapter[0-9]+**
**end-provided-data-service**

end note
```

In the configuration above, Liberator contains no static `add-peer` or `add-data-service` configuration for the connecting adapter. It does, however, now define an API key that all connecting peers must bear. API keys are not a requirement for dynamic configuration, but we recommend them for production deployments.

In Platform 8, [API keys](../datasource/datasource-apikeys.md) are a new way to manage trust in deployments where new adapters can connect to live deployments and provide configuration for Liberator and Transformer. Deployment administrators can configure API keys with specific levels of authorisation depending on requirements. The API keys in Liberator and Transformer configuration files are SHA256 hashed, protecting them if server security is compromised.

Within a system, there can be a mixture of dynamic and statically configured data services. However, a dynamic service cannot update a statically configured service. 

If multiple adapter instances provide the same dynamic service configuration, the configuration of the last instance to connect applies. This means that an adapter connecting later will override configuration set by earlier connecting instances.

The adapter that sends the service definition doesn’t have to be the adapter that supplies the data.

Dynamic Services do not support [source affinity](datasource-load-balance-adapters-using-source-affinity.md). If you require source affinity, either use a statically defined data service or use [Discovery](../discovery/index.md), which supports source affinity in dynamic, scalable deployments.

Dynamic data services enforce load-balancing and automatically re-balance requests across providing instances. To disable automatic re-balancing, set the global option [`service-rebalance-time`](../datasource/datasource-data-services-configuration.md#service-rebalance-time) to `-1` in the Liberator or Transformer.

---

**See also:**

* [`add-data-service`](../datasource/datasource-data-services-configuration.md#add-data-service)
* [`add-provided-data-service`](../datasource/datasource-data-services-configuration.md#add-provided-data-service)
* [Dynamic Peers](../datasource/datasource-dynamic-peers.md)
* [Dynamic Fields](../datasource/datasource-field-definitions.md#dynamic-fields)
* [API Keys](../datasource/datasource-apikeys.md)