Bloomberg API（BLPAPI）開発
Desktop API・Server API・B-PIPE の違いを踏まえた接続設計から、本番運用までを請け負います。
概要
Bloomberg の API は BLPAPI（Bloomberg Open API）という共通のプログラミングインタフェースの上に、Desktop API・Server API・B-PIPE・Platform という製品が乗る構成です。公式のコア開発者ガイドは「すべての API 製品は同じプログラミングインタフェースを共有し、ほぼ同一に動作する」と説明しています。
違いが出るのはアプリケーション側の責務です。Desktop API を除くエンタープライズ製品では、データを配信・受信する前に認証・認可・パーミッショニングをアプリケーション側で行う必要があります。ここを設計に織り込まずに Desktop API 前提で作ると、本番のエンタープライズ環境へ移すときに作り直しになります。
技術仕様
公式ドキュメントで確認した内容です。出典はページ末尾に記載しています。仕様は更新されることがあるため、実装前に一次資料をご確認ください。
- 製品
- Desktop API / Server API / B-PIPE / Platform（共通の BLPAPI 上に構築）
- 対応言語
- Java, C/C++, .NET, Perl, Python。Excel 向けに COM Data Control
- 実装形態
- Java・C・.NET はネイティブ実装（.NET は C# ネイティブ）。C++・Python・Perl・COM は C API 上に構築
- 通信パラダイム
- Request/Response と Subscription の 2 種類。サービスごとにどちらを使うかが決まる
- 主なサービス
- //blp/refdata（価格・ヒストリカル・日中バー/ティック）、//blp/mktdata（ストリーミング配信）、//blp/mktvwap、//blp/mktbar、//blp/mktlist、//blp/apiflds、//blp/instruments、//blp/tasvc、//blp/apiauth
- 製品限定のサービス
- //blp/mktdepthdata は B-PIPE のみ。//blp/mktbar は B-PIPE では利用不可
- Session の主な操作
- start / stop / openService / getService / sendRequest / subscribe / resubscribe / unsubscribe
受託の範囲
- 接続方式の選定（Desktop API / Server API / B-PIPE）と、移行を見込んだ抽象化レイヤの設計
- リファレンスデータ取得のバッチ実装（IntradayTickRequest / IntradayBarRequest を含む）
- ストリーミング配信の購読管理と再購読・切断復帰の設計
- エンタープライズ製品での認証・認可・パーミッショニング実装
- 取得データの正規化と、社内のデータ基盤への取り込みパイプライン
実装で詰まりやすい点
Desktop API で作って B-PIPE へ移せない
プログラミングインタフェースは同じでも、エンタープライズ製品では認証・認可・パーミッショニングがアプリケーション側の責務になります。最初から権限判定を差し替え可能な場所に置いておかないと、移行時に取得部分を書き直すことになります。
サービスによって呼び出し方が違う
購読型のサービス（//blp/mktdata、//blp/mktvwap など）では getService を使いません。Request/Response 型と同じ手順で書くと動かない箇所があり、ここは公式ガイドでも注意書きが付いています。
リアルタイムをリファレンスデータで代用しない
リファレンスデータのリクエストにも現在値は含まれますが、公式ガイドはリアルタイムを多用するアプリケーションにはストリーミングのサービスを使うよう明記しています。ポーリングで代用すると負荷と遅延の両方で不利になります。
参照元
Bloomberg API についてよくあるご質問
Bloomberg Terminal の契約は必要ですか。
接続方式によります。Desktop API は端末上で動作するため Terminal が前提です。サーバー側で無人稼働させる場合や、複数の利用者へ配信する場合は Server API や B-PIPE の検討が必要になります。どの方式が要件に合うかの切り分けからご相談いただけます。
既存の取得処理を作り直さずに移行できますか。
BLPAPI のインタフェースは製品間で共通なので、取得ロジック自体は流用できることが多いです。作り直しが発生しやすいのは認証・認可の部分です。まず現行実装のどこが製品依存になっているかの棚卸しから入るのが確実です。