Here's an example of how to configure Liberator to handle subscription requests for a container.
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.
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.
- Container features and concepts
- How containers work
- Filtering and sorting containers using Transformer's Refiner Service blade
- How can I... Create containers in an Integration Adapter
- How can I... Obtain container data from several sources
- How can I... Obtain a container snapshot in a CSV or XLSX file
- Reference: DataSource peers configuration
- Reference: Data services configuration
- Reference: Object configuration