Configure container usage in Liberator

Here’s an example of how to configure Liberator to handle subscription requests for a container.

Simple configuration

This configuration follows the architectural example shown in How containers work. Requests for the container /CTR/FI/ALL are routed to an Integration Adapter called FIDataSource that supplies both the container and the data that populates it.

add-peer
   remote-name  FIDataSource
   remote-label FIDataSource
   remote-type  active
end-peer

add-data-service
   service-name         ContainersFI
   include-pattern      ^/CTR/FI/
   add-source-group
      required          TRUE
      add-priority
         remote-label   FIDataSource
      end-priority
   end-source-group
end-data-service

add-data-service
   service-name         InstrumentsFI
   include-pattern      ^/FI/
   add-source-group
      required          TRUE
      add-priority
         remote-label   FIDataSource
      end-priority
   end-source-group
end-data-service

The first add-data-service item (service ContainersFI) deals with subscriptions to the container. The container subject /CTR/FI/ALL matches the include-pattern ^/CTR/FI/, so the required data service is ContainersFI. The data service definition has a single add-priority item with the remote-label FIDataSource, which directs the Liberator to the Integration Adapter called FIDataSource. FIDataDource is defined in the add-peer item with the matching remote-label called FIDataSource. So the Liberator sends a subscription request for the container /CTR/FI/ALL to the FIDataSource Integration Adapter.

The second add-data-service item (service InstrumentsFI) deals with subscriptions for the data in the container. For example, a request for the container element with subject /FI/A, matches the include-pattern ^/FI/, so the data service that can supply the data for the subject /FI/A is InstrumentsFI. The data service definition has a single add-priority item with the remote-label FIDataSource, so this directs the Liberator to the FIDataSource Integration Adapter as the source of the container’s data.

For simplicity, this example configuration doesn’t include failover within the data services, which you would most likely need in a production deployment. For example, see How can I…​ Set up server failover capability in the Deployment Framework pages.
For an example of a more complex container-related configuration, see How Can I…​ Obtain container data from several sources

Mapping containers

You can map the name of a container within Liberator in the same way as other subject names (see Object mapping). For example, a client request for the container /CTR/FI/ALL could be mapped to a request for /CTR/FI/ALL/<tier>, where <tier> is the price tier for the requesting user. When the mapped request is passed to the DataSource application that supplies the container, the DataSource application can respond by populating the container with just the instruments that can be traded within the indicated price tier.

In this example, the mapping would typically be done by a Liberator Auth module that determines users' price tiers. You can also set up simple mappings in Liberator using the object-map configuration item.

See also: