Custom Data - Your Way
INTRODUCTION
In our previous article of Write Once – Run Anywhere, we spoke about the multitude of (micro) services available in the Bloomberg Enterprise real-time ecosystem. This includes products such as B-PIPE that make more than a dozen services available. These services have a nomenclature to identify a unique service, which consists of the ‘firm’ name followed by the short name (intent) for the service. One example available in the Desktop API, Server API, B-PIPE, etc is
//blp/marketdata
that supports a subscription paradigm to stream market data, allowing you for example to subscribe to VOD LN Equity (Vodafone on LSE) pricing. The “blp” refers to the firm Bloomberg and the “marketdata” a short name/hint about the service.
Bloomberg has a number of products, each offering one or more of these services, typically layering API access to functionality surfaced up through the Bloomberg Terminal. This broad range of functionality addresses use-cases across buy-side, sell-side, cross-asset, and anything from pre-trade to post-trade. It’s a comprehensive set of capability that suits many use cases.
But, what if, the functionality or content you want to make available can’t be configured with the existing set of services, what are the options ? Perhaps you want to offer some capability or content across your whole organisation, or make reference to an internal custom data source, or write an adapter to a third party data source. Underpinning this is the ability to support two paradigms;
PUBLISH/SUBSCRIBE
The ability to publish custom data to one or more end points that are subscribing (listening). There are two types of publisher that can be built; broadcast publishers that just stream/publish everything, irrespective of whether anyone or anything is interested, and is by far the easiest pattern to design and build. The other option is an interactive publisher, whereby your service waits for a subscription request, determines what action to take (eg, initiate downstream connection/request, open database) and then starts to stream any updates. When designing your broadcast/interactive publisher there is also a choice of whether you manage the (Last Value) Cache.
In summary, a Publisher makes streaming custom data available to consuming Subscribers.
RESPONSE/REQUEST
This is the ability to create a service that responds to single atomic requests, eg get me this piece of custom data, send this order, update the database, query this dataset. Once the action is taken, the response is sent back, there is no further activity until the next request. Each Request service is configured with one or more “requests”. A good “blp” example of this is “refdata” whereby you can request history, or a piece of static reference information.
In summary, processing a Request results in executing custom action and/or returning custom data, both as a Response.
IMPLEMENTATION
Bloomberg currently only makes the capability to construct your own Publisher and Response service when your Delivery Point is on-premise. Any on-premise deployments includes at least one pair of resilient servers known as Appliances which fundamentally manage the cache (for Publishers) including cache replication to other appliances. In order to support the distribution of custom data in a Bloomberg Enterprise ecosystem, you need to opt in to the Data Distribution and Management (DDM) (pronounced “pub sub”) capability. This allows you to register your ‘firm’ and one or more custom services, eg
//SherpaBankInc/InternalPricing
The next consideration is how does one create a publisher. There’s a choice; Excel or a custom application using the BLP API SDK.
Excel includes a formula for Publishing called =BPUB(), such that you can BPUB() both a custom ticker (eg, “VODSHERPA LN Equity”) and some fields (BID, ASK, etc) to your custom data service (//SherpaBankInc/InternalPricing), it would like something like this:
BPUB(“//SherpaBankInc/InternalPricing/ticker/VODSHERPA LN Equity”, “BID”, 21.5, “ASK”, 21.6)
(shortened for brevity)
The BID and ASK are available in the default data model, but you can choose an entirely custom data model to suit your custom data model with both flat and deep data models supported, however, only flat data models can be cached in Appliances.
Other than Excel, your only other choice is to write some code using any of the languages supported by the BLP API SDK. However, once you have a publisher (Excel or Custom Application), then you have the possibility across your organisation to leverage several means of consuming the custom data (subscription), including;
Using the =BDP() Excel formula to consume your custom data
Leveraging the Bloomberg Terminal Launchpad
Custom in-house application
Third Party Application
BENEFITS
One possible option of solving the business problem of distributing custom data is to use something like MQ, Kafka, Redis, etc.. so what’s the value in using this Bloomberg Enterprise capability (via the DDM)?
Reduction in APIs across the real-time application estate. Architecturally, you could reduce the number of API SDKs used, focusing on the BLP API to power all your real-time applications
Reduce risk/cost of compliance by leveraging existing toolchain for entitlement and reporting.
Time to Market advantages
Support both structured (tickers/records) and unstructured data (pages/text)
Offer in-house/custom data to your Bloomberg Terminal users (via Launchpad)
Manage distribution of key data points across user base (eg, published interest rates, FX Rates, spreads)
Tag custom data with custom identifiers (EIDs). Publishing custom data provides the ability to use custom EIDs meaning that you can continue to use Bloombergs’ EMRS Entitlement System.
Managed Service - This is essentially a Platform as a Service (PaaS) offering, meaning you get caching, replication, scale and failover all built in, thus reducing costs on supporting the infrastructure.
WRAP-UP
There’s lots of nuances and detail when embracing the distribution of custom data, and if you think you have a business problem to solve and this may be the answer, reach out to the Solution Engineers group within Bloomberg, or, if you want to have a discussion with our experts, don’t hesitate in getting in touch.
FINALLY
In case you’re looking for some inspirational custom data ideas, then here’s a few;
Create a custom application that subscribes to the standard //blp/mktdata service, that derives pricing (through blending?) but then publishes that to a custom data service //SherpaBankInc/DerivedPricing such that Bloomberg Terminal users can view on their Launchpad, that non-Bloomberg users could process in their Excel sheets, whilst being consumed downstream in third party applications.
Create a custom application that subscribes to the standard //blp/mktdata service, creates derived pricing, then publishes that data to a custom data service //SherpaBankInc/WebSitePricing where a subscriber application is waiting for updates to post to a website (or database, or cloud, …)
Create a response to a request that interrogates the securities white list to understand whether the supplied ticker should be traded or not. The response includes TRUE or FALSE and a REASON should it be FALSE.
Manufactured in-house custom data (possibly derived data) in one region/city, for onward consumption in another region/city
Send a request, supplying local restaurant name, and return the menu in the response (page)
