Write Once - Run Anywhere
In a previous article we discussed the beauty that is wrapped up in the Bloomberg API (BLP API). As a recap, this API allows you to connect to micro-services within the Bloomberg ecosystem. The micro-services deliver content and capability in a ‘real-time’ manner. What do we mean by real-time? Well, some might immediately jump to streaming data, but no, what the BLP API is delivering is real-time access to content and capability, ie the I need it now access. One good example to demonstrate the principle is tick history. If you were performs trades on behalf of a client and needed to perform Transaction Cost Analysis (TCA), Best Execution and as a consequence needed to understand the trades/quotes that occurred from the time you placed the order to the time of fulfilment, then you’re probably going to need that pretty damn quick, and not only are you going to need that over a very precise/small timeframe, but also frequently. This is an example of realtime access to content. Submitting a request in a file, waiting 15 minutes or more, receiving a file, is probably not going to work out, not to mention that this slower method of access is probably not going to make the data available until T+1, possibly without the precision, etc, etc. Enter the BLP API. With over a 100 micro-services, covering everything from cross asset risk, order entry/routing, volatility services, price contribution, full depth order books, static/reference data and yes, streaming data, plus way more.
So, we know the BLP API is micro-service driven and it’s realtime access. It supports four fundamental methods; publish, subscribe, request and response. This means that you can publish a price, subscribe to a ticker, request tick history, or respond to a request for some internal firm data. Not only is there over a 100 micro-services, but it’s also extensible, so you can write your own. That is, write a custom service that responds to a publish, subscribe, request or response. The services have a naming nomeclature that looks like;
//<FIRM>/<SERVICE-NAME>
whereby all Bloomberg services have a FIRM of “BLP”, but firm-specific services have your firms name, for example
//ALPHA-BETA-BANK/<SERVICE-NAME>
So, we’ve got the BLP API and we’ve got services. We need to build applications, so how do we connect the components together to get a working application.
Essentially, you write your application in a language of your choice (eg, Python, .NET, Java, C, C++, etc), then you bind/link to the BLP API library. The SDK with documentation, samples, libraries etc is available here or if you are lucky enough to have a Bloomberg Terminal, then just type WAPI<GO>, or, if you’re a Bloomberg customer, at their customer service portal here. One other resource is the fact that Bloomberg run a number of “Developer Day” events around the world, with a most recent one being the “Demystifying APIs for Bloomberg” London event back in May 2023. Look out for others.
The pattern for writing code is;
Create a session by nominating one or more delivery points
Open a service (or use the defaults)
Do stuff
Close the service
Close the session
So, what are delivery points? They are network end points, IP addresses, DNS addresses, where Bloomberg is listening for BLP API calls. What do they look like in different environments;
Bloomberg Terminal is localhost (127.0.0.1)
SAPI is wherever the server(s) were installed (eg, 172.16.1.1)
B-PIPE on-premise (edge of your network, eg, 10.0.0.1/2)
B-PIPE over Private Cloud (Zero FootPrint) cloudpoint1.bloomberg.com
B-PIPE in public cloud (Amazon Web Services, Microsoft Azure, Google Cloud Platform)
So the above is the various ways a BLP API delivery point can be made available. The Bloomberg Terminal and SAPI are for applications that display data only, whilst the B-PIPE delivery points are enterprise delivery points, open to everyone and everything in the firm (under control of course). This means it’s possible to create code that creates a session, whereby the delivery endpoint IP Addresses/DNS’s are configurable (through settings) and you needn’t worry whether your code is running on premise or in the cloud, it’s all the same.
So, full circle to the title of this blog.. you have the ability to write once in terms of your application and run anywhere. If you currently made an investment in writing code for on-premise, and you now have a cloud mandate that says move it, then start up an EC2 instance or whatever is appropriate and run it there, change your session options such that the IP Address/DNS is correct, and, connect to a cloud delivery point (assuming you’ve bought one). There’s no mandatory refactoring, you haven’t got to think about switching from an Application Binary Interface (ABI) that is BLP API to a REST/SOAP API or any other API/Protocol. It is, the same API, the same data model, the same behaviour, same design pattern.
No Compromise
Not only that, but when you’ve gone cloud (applicable to SAPI or B-PIPE), the permissioning, entitlement, reporting system is the very same instance you used for on-premise. The entitlement system knows about delivery points, so you have strict control over usage an applications.
What’s the benefit you say? The DevOps cycle is so much easier. If you’re writing a Bloomberg real-time server application, you could; start programming against a Bloomberg Terminal, it’s not ideal and has many constraints. Bloomberg also make available a dev(eloper) instance (of the delivery point) for their Enterprise products. If you’re coding against B-PIPE and you’re using your UAT instance (or even worse your PROD instance) then ask your Bloomberg representative for your dev(eveloper) instance details. With this delivery point there’s no chance of impacting production, whilst still getting access to the real behaviour and features.
There’s no barrier to entry in terms of moving to cloud, no refactoring. Develop and debug on-premise, then promote to your cloud instance. Bloomberg makes the return on investment compelling.
If you need to speak to anyone to learn more about what’s possible, how it all fits together, what you need to get your existing or future application on cloud, then don’t hesitate in reaching out to Sherpa Consultancy. Happy coding !
