Power BI との連携開発の前に知っておくべきこと

ここでは、現在多くの方にお使いいただいている Power BI と連携したアプリ開発をお考えの ISV 企業の皆さんのために、理解すべき情報をまとめます。

まず、Power BI のコンセプトは「BI の民主化」、つまり本来開発して使うものではない という点は理解しておきましょう。
Microsoft では、過去、OLAP などの専門領域を扱う開発企業や Professional Engineer などに委託して実現されていた高度なデータ設計や BI の実現を、現場のエンドユーザーの元に開放する「みんなの BI」 (=誰もが "作れる" BI) 的な取り組みを (SQL Server チームなどを中心に) 長年実施してきました。
Power BI はこうした過程の中で登場しました。

自社で出荷している製品の県別の売り上げを政府が出している県別の人口統計や年齢別の統計などを元に分析・統合して Insight を得る場合を想像してみましょう。Power BI なら、1 ステップもコードを書く必要はありません。
例えば、企業内で公開されているデータベース上の売り上げ情報と Web 上で公開されている県別の人口統計をマッシュアップ (Join) し、不要なデータの削除、計算列の提供などの簡単なデータ整形をおこない、このデータを元に多角的なレポート (複数) を作成してこれを全社従業員に共有し、さらに県ごとにある支社に共有して各支社ではそれを元に独自のカスタマイズ (レポート追加等) をおこなって支社内で共有させる、といったケースを考えます。これらはすべて、Power BI の UI を使った簡単な設定で実現でき、そこに開発コードは必要ありません。

こうした Power BI のコンセプトを踏まえた上で、なお、製品アプリやサービスにおいては「Power BI と同等の機能をわざわざ作りたくない」、「顧客ごとに個別・特有の細かなレポート要求をわざわざすべて実装せず、いっそのこと Power BI と連携してそっちでやってほしい」といった開発ニーズ (連携ニーズ) が多数存在しています。
大切なポイントは、連携開発の目的を明確にすることです。なぜなら、Power BI では、こうした連携のための手段を 目的に応じて複数提供 しているためです。本来の開発目的を整理し、適材適所に (あるいは、その複数の組み合わせで) 開発方法を選択するのが最大のポイントです。

まず、大きく開発のタイプ (種類) ごとに分類してみます。下記をご参照ください。

統合開発 (Integrate)	ISV のアプリやサービスと Power BI を、まさに「連携・連動」する開発方法です。
組み込み開発 (Embed)	ISV のアプリやサービスの中に Power BI の機能の一部を埋め込む開発方法です。もっともわかりやすいのは、Power BI で作ったレポート (ハイライト、フィルタリングなどの機能含む) そのものを企業アプリの UI に入れてしまうケースです。
拡張開発 (Extend)	ISV アプリ (サービス) 専用の機能、もしくは ISV アプリ (サービス) でよく使う機能を Power BI 側に追加する方法です。

では、ここに、実際の開発手法 (技術手法) をマップしてみます。

さいごに、上記で紹介した開発手法について、細かなポイントや注意すべき点を補足説明します。

まず REST API ですが、現時点では、REST API の呼び出しの前に、必ず OAuth によるログイン (Power BI のログイン画面を表示してトークンを取得する) が必要です。ISV アプリが Office 365 (すなわち Azure AD) とシングル・サインオン (SSO) して構築されているケースではシームレスに利用できますが (SSO によりそのままログインユーザーのトークンで Power BI と連携できます)、そうではないほとんどの ISV サービスではこのログインのタイミングを検討する必要があります。

なお、Power BI ではデータの変動にあわせてリアルタイムに (刻一刻と) レポートを変更させることができますが、このリアルタイム更新には Data の Push が必要であり、こうしたレポートを提供する場合は概ね REST API が必要と考えてください。(厳密には REST API を使わずに既成のサービスや機能から Push 連携も可能ですが、これらも内部では REST API が使用されています。)

上述で Power BI の埋め込み開発として Power BI Embedded を記載していますが、実は Power BI には 3 種類のレポート (またはタイル) の埋め込み方法が提供されています。最大の違いは認証・認可の考え方です。
1 つ目の方法は匿名アクセス可能な iframe 埋め込み用の uri を取得する方法で、これは開発不要であり、Power BI の画面上から埋め込み用の uri を作成できます。(最近話題になったポケモン Go のレポートなどはこの方法で提供されています。誰でも認証せずに見ることができます。)
2 つ目の方法は Power BI による認証 (Azure AD 認証) を使った埋め込み uri で、この uri は上記の REST を使って取得できます。この方法で取得した uri を使って iframe 上でレポートを表示するには、事前に OAuth によって Power BI のログイン画面を提供し、そこで得たトークンを iframe に渡す必要があります。
そして 3 つ目の方法が Power BI Embedded であり、この方法を使うと、ISV 企業独自の認証 (独自の OAuth, Basic 認証など何でも構いません) と自由に組み合わせ、セキュアにレポートをホストできるというメリットがあります。接続先のデータソース (インスタンス) も利用者や利用企業ごとに変更できるなど、現実の ISV アプリとの連携を想定したさまざまな方法を提供しています。

ISV アプリに埋め込まれたこうした Power BI のレポートは、Power BI の JavaScript API を使ってページ変更、フィルタリング等々の機能連携もできるので、利用者に「まるで ISV アプリの一部」であるかのような動作を提供できます。

ただし、こうした埋め込みの最大のデメリットは、利用者自身がその画面上で自分のレポートを追加 (新規作成) できないという点であり、もし「セルフサービス BI」という観点を重視して連携開発するなら Template Content Pack など他の方法による連携を検討すべきです。
また、Power BI Embedded は対応しているデータソースも制限されているので (パスワード認証方式を有するデータベースのみで、現状、Azure SQL Database など一部のデータベースのみです)、この点も注意が必要です。

さいごに、組み合わせよって対応していない技術もあるので注意してください。(例えば、Power BI Embedded の中の DataSet に対する REST API からのデータの Push、REST API で Import された DataSet に対する REST API によるデータの Push、などは不可能です。) このため、必ず実際の開発に入る前に、簡単なケースでの動作確認やフィージビリティの確認をおこなってください。

参考情報

Power BI REST API を使ったデータ連携
https://blogs.msdn.microsoft.com/tsmatsuz/2016/01/06/power-bi-custom-development-using-rest-api/

Build Your Custom Visuals in Power BI (Step-by-Step)
https://blogs.msdn.microsoft.com/tsmatsuz/2016/09/27/power-bi-custom-visuals-programming/

How to use Power BI Embedded via REST
https://blogs.msdn.microsoft.com/tsmatsuz/2016/07/20/power-bi-embedded-rest/