How containers work

Here’s a bit more background information about how containers work.

For an explanation of what containers are for, see here.

Several components interact to provide container facilities:

  • Client applications request container subscriptions using the StreamLink API.

  • Liberator manages containers on behalf of the client applications.

  • The container elements are defined by another DataSource application – typically an Integration Adapter or a Transformer. This can be a different DataSource application to the one that supplies the data referenced by the container elements.

  • Transformer manages filtering, sorting, and grouping, of container elements through its Refiner Service blade.

Here’s an example that shows the flow of data and processing within Caplin Platform components when a client subscribes to a container. This is the simplest possible example, involving a client application (with StreamLink), a Caplin Liberator, and an Integration Adapter that supplies both the container elements and the data that the elements refer to.

Container usage in Caplin Platform - simple case

Following the numbered steps in the diagram:

  1. The client application subscribes, through StreamLink, to the container /CTR/FI/ALL, and this request is sent to the Liberator.

  2. The Liberator doesn’t currently have a subscription to this container in its cache, so it looks in its configuration for a data service that can supply the container elements. In this simple example, the FI container elements for /CTR/FI/ALL and the data that the elements refer to (the FI instruments) are all obtained from a single Integration Adapter called FIDataSource.

  3. FIDataSource receives the request for /CTR/FI/ALL, and recognizes from the /CTR prefix to the subject name that this is a request for a container. Since this particular container is not in its cache (not previously requested since the Integration Adapter was started up), FIDataSource obtains the list of elements (subjects) that this particular container refers to, and populates the container with the subject names – /FI/A, /FI/B, /FI/C, and so on.

    The DataSource adapter returns the container elements to Liberator, where they are cached.

  4. Liberator examines the container contents and subscribes to the subject of each container element that isn’t already in its cache. (In this simple example, the container isn’t windowed, so all its elements must be subscribed to.) For each unsubscribed subject, it looks in its configuration for the data service that can supply the data. In this example, the data service is defined to use the same Integration Adapter as the one that supplies the container itself, namely, FIDataSource.

  5. FIDataSource receives the requests for the subjects /FI/A, /FI/B, /FI/C, and so on. It returns the data images for the corresponding instruments, either from its cache (cached when the instrument has previously been subscribed to since the DataSource adapter was started up), or, if it’s not already in the cache, by requesting the data from the relevant Bank system or external data feed. Liberator receives the data images for the subscribed container elements and caches them.

  6. Liberator sends the client the container image, and the data images of all the instruments referred to by the container elements.

  7. (This step isn’t shown in the diagram.) The Liberator sends the client all subsequent updates to the subscriptions. These can be:

    1. Changes to the container structure; for example, new elements appearing in the container.

    2. Updates to the subjects that the container elements refer to; for example, a change to the Yield field of instrument /FI/C.

To see the Liberator configuration for this example, look at How can I…​ Configure container usage in Liberator.

See also: