de:code 2015 レポート day2 - PBS-001
クロスワープの大鷲です。
前回に引き続き、de:code 2015 day2 のレポートをお届けします。
参加セッション
再掲となりますが、参加したセッションは以下の通りです。
本記事では、「ここまでできる! Office 365 API を活用したアプリ開発 ～Office 365 内のデータ活用～」のレポートをお届けします。
資料はこちらで公開されています。
その他のセッション動画及びスライド資料も Channel9 で公開されています。
オープニング キーノートは Microsoft Virtual Academy のサイトで公開されています。
day 1
| CODE | ROOM | TITLE |
|---|---|---|
| SNR-004 | Room G | デジタルテクノロジーが推進する、アプリケーション革新 |
| SPL-001 | Room C | マイクロソフトが考える 5 年後を見据えた技術提言 |
| CHK-002 | Chalk Talk | クラウドアプリケーションのアーキテクチャ設計を深める |
| CHK-003 | Chalk Talk | プログラミング パラダイムの知識を深める |
| CDP-008 | Room C | MS版Docker 誕生! Windows Server Containers とは? |
day 2
| CODE | ROOM | TITLE |
|---|---|---|
| ARC-001 | Room A | クラウド時代のデータアーキテクチャ |
| SNR-009 | Room B | フルスタックエンジニアとか無理! 比べてわかったAzure PaaSの勘所 |
| DEV-019 | Room F | 徹底解説! プログラマーがおさえておくべき Azure Active Directory のすべて |
| PBS-001 | Room E | ここまでできる! Office 365 API を活用したアプリ開発 ～Office 365 内のデータ活用～ |
| DEV-006 | Room A | ASP.NET 5 Web 開発 ～ランタイム編～ |
| DEV-007 | Room A | ASP.NET 5 Web 開発 ～フレームワーク編～ |
| DEV-008 | Room A | 進化は止まらない! ADO.NET Entity Framework の今 |
PBS-001 ここまでできる! Office 365 API を活用したアプリ開発 ～Office 365 内のデータ活用～
スピーカーは日本マイクロソフトの大田 昌幸さん。
前のセッションに引き続き、社内でも Office 365 を利用していることもあって、興味があったため参加しました。
ビジネスチャンス
最初に、Office 365 がどの程度利用されているかという説明がありました。
- Microsoft CEO が「Office 365 は最も戦略的に大切にして行きたいエリア」と発言
- 12 億人以上のユーザー
- 1 億以上のモバイル アプリ ユーザー（iOS や Android にも対応）
- 毎日 2 ～ 3 時間利用されている（アクティブなユーザーがちゃんといる）
- 毎月 8.5 億時間ものミーティングが（Lync / Skype for Business で）行われている
- 4 兆通ものメール
- 470PB 以上のデータ
Office 365 API の全体像
API を使う上では、先のセッションで説明された Azure Active Directory を使って認証する必要があります。
その上で、Office 365 API を使うと、以下のようなデータにアクセスすることができます。
- Azure AD のユーザーやグループ
- Exchange Online や Outlook.com のメール、カレンダー、連絡先
- SharePoint Online のサイトやライブラリをはじめとする様々なデータ
- OneDrive、OneDrive for Business のファイル
Outlook.com は以前は Hotmail と呼ばれていたサービスですし、OneDrive（for Business じゃない方）も元は Windows Live のサービスです。
つまりはもともと Office 365 の外にあるサービスなのですが、同じ API で利用できるようです。
Lync（Skype for Business）や Yammer については言及されていませんでした。
パートナー各社のソリューション事例
最初に、ランチセッションでも紹介された「セキュアファイル便」の事例が紹介されました。
内容については割愛しますが、「セキュアファイル便は SharePoint Online 上で動くアプリだが、その内部で Exchange Online の API を使ってメールを送信している」と紹介されていました。
はて、以前のセッションでは、確か SendGrid を使っていたと言っていたような…。
続いては、やはり JBS のセッションでも紹介がありました工事進捗管理システム。
こちらは、SharePoint を、写真をアップロードするためのストレージやとして利用したり、地図を表示する機能を使っているそうです。
続いて、セラフの「パノラマ新聞」。
送受信したメールを新聞風に表示するアプリのようです。
個人向けアプリなので、Outlook.com の API を使っていると言われていましたが、ニュースリリースを見ると Exchange Online の API を利用しているようですね…
次は Any3 Office Graph。Any3 というシステムの機能の一部のようです。
Office 365 の Graph API を利用し、自分と関係の深いユーザーや、そのユーザーとの間でやり取りしたファイル等を取得することができるとのことです。
最後がジョルダンの乗換案内。
Apps for Office という機能を使って Excel の中に Web アプリを連携させることで、Excel と Web アプリの間でデータを転記したりしなくても、ワンクリックで自動化でき、経費精算が簡単にできるそうです。
問い合わせを通して知る Office 365 API の使い方
スピーカーの大田さんは、エバンジェリストになる前はサポート エンジニアとして顧客からのサポート リクエストに答える立場だったということで、顧客からの質問があったという想定で Office 365 API の使い方を解説されました。
Office 365 API は認証に Azure AD を使います。
先ほどのセッションでは忙しく駆け抜けてしまった部分に関して、こちらのセッションの方が若干丁寧に解説されている印象も受けました。
Office 365 API でのデータのクエリには OData を利用するようです。
Office 365 API SDK ライブラリを利用することで、LINQ を使って OData クエリを組み立てることもできるようになっています。
また、今年 3 月に発表された Azure Logic Apps を使えば、あらかじめ用意されている API を、デザイナーを使って組み合わせるだけで、ノンコーディングで Office 365 API を使ったアプリを作れるというデモもされました。
続いて、SharePoint API を使うというシチュエーションを例に、Discovery Service の使い方を解説されました。
Exchange の場合は API Endpoint の URL は固定でよいのですが、SharePoint の場合、テナントごとに契約しているドメインやサイトの構造によって、API Endpoint の URL が変わってしまいます。
そのため、まず Discovery API に問い合わせて API の URL を取得する必要があります。
Discovery Service も Office 365 が提供する API の一つです。
そして、アクセストークンはサービスごとに取得する必要があります。
そのため、SharePoint API を使用する際は、
- まず Discovery Service 用のアクセストークンを取得する
- Discovery Service にアクセスして SharePoint の API URL を取得
- 続いて SharePoint API にアクセスするためのアクセストークンを取得
- SharePoint API を呼び出す
という手順を踏む必要があるとのことでした。
続いては、以下のような問題の解決策がないかという問い合わせがあったという想定でした。
- Discovery Service を使うのが面倒
- 複数のサービスを利用するには、沢山のアクセストークンの管理が大変
- アクセストークンの期限が切れると、再取得のためのリクエストが何度も必要で、パフォーマンスに影響する
これは、Office 365 を構成するサービス群である Exchange や SharePoint が、もともと個別に API が作られてきたという経緯によるものです。
しかし、ユーザーはどのサービスでも Azure AD で一元管理できているわけですから、ユーザーを中心として関連リソースを芋づる式に取得できてもよいのではないか。
というわけで作られた新しい API が、Office 365 Unified API です。
Unified API はエンドポイントが 1 つしかなく、それだけで Exchange も SharePoint も使えるので、Discovery Service が不要で、アクセストークンの管理も 1 つだけで済みます。
さらに、1 回のクエリで複数のサービスを横断的に検索することができるというメリットもあります。
ただし、では Unified API さえあれば従来の API は不要なのかというとそうではなく、サービスを深く使うためには従来の API でしか利用できない機能もあるそうです。
なお、Unified API も OData 形式になっているようです。
サンプルコード
GitHub で公開されています。
Active Directory Authentication Library
https://github.com/azuread
Office 365 API
https://github.com/officedev
