Routing a request to multiple adapters

The data services configured in the Caplin Platform define how Liberator and Transformer are to route requests to the correct DataSource peer applications. These may simply route requests with a particular subject prefix to a particular Integration Adapter, as is the case with the default configuration created by the CIS. You can modify this to include multiple adapters, failover and load balancing configuration.

Download the presentations for this course.

Configuring Shared Data for FX Subject Requests

The Pricing Integration Adapter blade which you have deployed is composed of configuration for routing requests commencing with /FX/ and the adapter’s implementation. The configuration instructs Liberator to route the requests to Transformer (in Blade\Liberator\etc\rttpd.conf) and Transformer to the adapter (Blade\Transformer\etc\transformer.conf). The implementation reads incoming requests and connects to the mock server to return the price data for the requested currency pairs. We shall add a new collaborating adapter which provides additional data for the FX requests.

Follow the steps below:

Create a new project in the same way the PricingAdapter was created. Name the project "FXData".
This adapter will provide some additional data to the BidPrice, AskPrice etc. which are provided by the PricingAdapter. These fields need to be configured in FXData’s fields.conf:
```
add-field InstrumentName        -45028 0 0
add-field Data                  -45036 0 0
add-field Data_Timestamp        -45037 0 0
```

Implement the onRequest method so that it sends an initial message and subsequently sends update messages containing random data every 30 seconds, e.g.:

RecordType1Message updateMessage =
  publisher.getMessageFactory().createRecordType1Message(requestEvent.getSubject());
updateMessage.setField("InstrumentName", requestEvent.getSubject());
updateMessage.setField("Data", "Random data " + (int)(Math.random() * 50 + 1));
Date date = new Date();
String timestamp = String.valueOf(date.getTime());
updateMessage.setField("Data_Timestamp", timestamp);
publisher.publishToSubscribedPeers(updateMessage);

The default configuration created by the CIS involves a new data service called FXDataPricingSvc which routes /FX/ requests to FXData. Trying to run the platform with this service will cause it to clash with PricingAdapterPricingSvc which also claims to provide the /FX/ data. In order to set-up shared data for /FX/ you must define only one data service. Delete the data service configured in the FXData blade (Blade\Liberator\etc\rttpd.conf and Blade\Transformer\etc\transformer.conf).

Change the Transformer configuration in the PricingAdapter to route FX requests both to the PricingAdapter and FXData as follows:
```
add-data-service
        service-name        PricingAdapterAdvPricingSvc${THIS_LEG}
        include-pattern     "^/FX/"
        add-source-group
                required
                add-priority
                        label    PricingAdapterAdv${THIS_LEG}
                end-priority
        end-source-group
        add-source-group
                required
                add-priority
                        label    FXData${THIS_LEG}
                end-priority
        end-source-group
end-data-service
```
Export both FXData and the PricingAdapter (as configuration-only blades) and deploy them using the Deployment Framework.
Start up the platform (using the Deployment Framework) and adapters (using Eclipse) as well as the mock server. Use the Liberator Diagnostics Page to make a request. You should now see the additional fields appearing in the returned data:

Adapter Status

Try terminating the mock pricing & trading server. Notice that data updates (Liberator Explorer) simply stop and the Pricing Adapter is still connected to Transformer (see the CMC).

Change the implementation of the PricingAdapter so that it only starts up once the connection to the mock server has been established, and so that it is stopped when this connection is lost.

Use the DataSource methods start(), setStatusUp() and setStatusDown() to manage the DataSource connection to Transformer.

Notice now that when the mock server is terminated, The PricingAdapter disconnects from its DataSource peer Transformer (see CMC), and all current data subscriptions become stale (see Liberator Explorer Log):

<timestamp> - FINE : In - SubjectStatusEvent [subject=/FX/USDJPY, status=STATUS_STALE]