Office365 GraphAPI で認証アプローチ毎のアクセス範囲にハマった話 ユーザーの予定(Event)を横断的に取得したい!
先週くらいに、Office365 のCalendar情報を横断的に取得したいという要望があって調べていたんですが、ちょっと変に先入観があって躓いていました。
うーん、Graph API のUser Events APIの アクセス許可がうまくいかないなー。https://t.co/GEcVM5nDSK、https://t.co/GEcVM5nDSK.Shared つけているのに。
— Kazuya Sugimoto (@sugimomoto) April 3, 2019
ログインしているユーザーとは別のユーザーのイベントにアクセスしようとしても、「Access is denied.」になるなーhttps://t.co/MQ94GPGEQp
https://twitter.com/sugimomoto/status/1113275622841737218?s=20
いろいろと試行錯誤を経て解決したんですが、改めて全体像を調べてスッキリ理解できたので、GraphAPIにおける認証アプローチとアクセス範囲に関する考え方をまとめておきたいと思います。
ちなみにわかり易さから予定表(イベント)の取得に焦点を当てていますが、考え方はファイルやメールなどにも共通するお話です。
なお、Exchange Online(EWS)ベースのアプローチであれば、以前取り組んでいたのをBlogにしています。
- やりたかったこと
- 今回のお話の焦点:Azure AD アプリにおけるGraphAPIのアクセス許可
- それぞれの「アクセス許可」方法の確認
- 実際に予定を取得してみる
- CData Office365 Driverの対応状況
- おわりに
- 追記 20210201
やりたかったこと
Office365の予定表では、以下のような感じにいろんな人の予定が見えるようになっていると思いますが、これをGraphAPI経由で横断的に取得したい、というのが今回の目的です。
こんな感じの予定データを
横断的に取得して、分析活用したい、というイメージですね。
データ連携的観点でも、例えば外部のCRMアプリケーションなどで作られた営業案件の再訪問スケジュールを連携して、結果を確認したい、みたいなことがあると思います。
それを実現するための、GraphAPIアクセス範囲・アクセス許可の考え方です。
今回のお話の焦点:Azure AD アプリにおけるGraphAPIのアクセス許可
今回とりあげるのは、Azure ADのアプリケーション登録で行う以下のアクセス許可の話です。
以下のリファレンスがベースになりますが、私の解釈も踏まえてざっくりお話していきます。
ベースとなるアクセス許可は2種類
まず、大前提として抑えておきたいことは、ベースとなる「アクセス許可」は2種類存在するということです。
それが、「委任されたアクセス許可」と「アプリケーションのアクセス許可」です。
なんのことを言っているんだ、となるかもしれませんが、これはOAuthのAuthorizationURLが2種類
「委任されたアクセス許可」の場合以下のようなURLで
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&response_mode=query&scope=offline_access%20user.read%20mail.read&state=12345
このようなアクセス許可を求められますね。
https://docs.microsoft.com/ja-jp/graph/auth-v2-user#2-get-authorization
「アプリケーションのアクセス許可」の場合は、URL構成が変わって、
https://login.microsoftonline.com/{tenant}/adminconsent?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&state=12345&redirect_uri=https://localhost/myapp/permissions
ちょっとだけ、メッセージも変わったことがわかると思います。
https://docs.microsoft.com/ja-jp/graph/auth-v2-service#3-get-administrator-consent
メッセージが示すとおりでもありますが、それぞれで役割が違います。
- 委任されたアクセス許可
明示的なサインインユーザーが存在する場合に利用するアプローチです。 これは言ってしまえば、ユーザー自身がOffice365を利用する時と同様のアクセス範囲を想定した 自分の予定、自分のメール、自分のファイルをベースに、アクセス許可を行ったユーザーに共有されたgファイル、予定などにもアクセスすることを想定しています。
- アプリケーションのアクセス許可
明示的なサインインユーザーが存在しないアプリで利用するアプローチです。たとえば、バックグラウンド でデータ連携をしたり、強力な権限で組織全体のリソースにアクセスしたい場合に使用します。そして注意したいのが、アプリケーションのアクセス許可は「管理者のみが同意」してはじめて利用できるようになるという点です。
GraphAPIリソースへのアクセス許可は「リソース:操作:制約」の3つで捉える
その上で、GraphAPIのアクセス許可は以下の図に示すように、「リソース:操作:制約」の3つで捉えるのが個人的にいいと思っています。
- リソースは「Event、File」など、どんなデータにアクセスするのか
- 操作は「Read、Write」など、データに対してどんな処理を行うのか
- 制約は「All、Shared、None」など、どの範囲までアクセスするのか
今回の図は趣旨を理解しやすくするために単純化していますが、「操作」と「制約」はこれ以外にもいくつかあります。
必要な操作とリソースの特定方法
おそらく、操作とリソースは比較的わかりやすいでしょう。
予定を取りたいなら、CalenderのRead
予定の書き込みも行いたいなら、CalenderのReadWrite
各必要なリソース名、操作はそれぞれのリソースページから確認することができます。
例えば予定(Event)の主得であれば、以下の通り。
アクセス範囲の肝となる「制約」の考え方
そして、今回のポイントになるのは、この「制約」の部分になります。
基本的な制約の種類は以下の3種類。一番上が強い権限です。
- All
- Shared
- None(制約の指定無し)
Noneだけちょっと分かりづらいですが、一番弱い(アクセス範囲が狭い)権限です。ドキュメントでは「制約の指定無し」と書かれていて、混乱を招きやすいですね・・・。一番弱い制約って言うと語弊がありますし。
これ以外に、AppFolderや各リソース固有のものが存在しますが、基本的には上記の3種類がベースになっていると思っていいと思います。
それぞれの制約の範囲イメージ
これらの制約をEventのリソースをベースに表したのが、以下のそれぞれの図になります。
Noneの場合は、アプリケーションにログインしたユーザー自身のリソースにしかアクセスできません。これは、予定が共有されていたとしても変わりません。
そして、もう少しアクセス範囲を広げたい場合は、Sharedが必要になります。この場合は自分の予定に加えて、共有されている予定にもアクセスできます。
そして、最後に共有されていない予定にもアクセスしたい場合は、「All」が必要になります。これが今回私が必要としていたアクセス範囲です。
一番注意したいのが、委任されたアクセス許可では、この制約範囲を利用できない、ということです。
制約で「All」を使いたい場合は 2種類のアクセス許可に気をつける
ここが今回私が躓いたポイントでした。
アプリケーションの権限で「Calender.ReadAndWrite.All」を付与していたにも関わらず、アクセス許可は「アプリケーションのアクセス許可」で実施していなかったので、他のユーザーのリソースにアクセスしようとしても「Access is denied.」になってしまいました。
それぞれの「アクセス許可」方法の確認
ここまで来れば、あとはそれぞれの「アクセス許可」を使ってAccessTokenを取得するだけです。
アプリケーションの登録方法はどちらも同じですが、アクセス許可の方法は
「委任されたアクセス許可」の場合、「AuthorizationCode」
「アプリケーションのアクセス許可」の場合、「ClientCredential」
で実施します。
ちなみに、Graphエクスプローラーは現在「AuthorizationCode」にしか対応していないみたいなのでご注意ください。
「委任されたアクセス許可」を使ってユーザーの代わりにアクセスを取得する
ほとんどリファレンスに書かれている通りなので、要点だけ記載します。
1. AuthorizationURLを生成して、ユーザーへログイン要求を実施
この時ポイントになるのが、Scopeパラメータ。アプリ側で権限を許可していても、ここでスコープの要求をしない限り、操作を実施することはできないので要注意。
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&response_mode=query&scope=offline_access%20user.read%20mail.read&state=12345
2. アクセス許可後のリダイレクトURLに含まれる「Code」を使って、AccessTokenを取得
Callbackとして、以下のようなデータが返却されるので、Stateをチェックし、Codeを取得したら
https://localhost/myapp/? code=M0ab92efe-b6fd-df08-87dc-2c6500a7f84d &state=12345
そのCodeを利用して、TokenエンドポイントにAccessTokenを要求します。この時GrantTypeはAuthoricationCodeを指定します。
POST https://login.microsoftonline.com/common/oauth2/v2.0/token HTTP/1.1 Content-Type: application/x-www-form-urlencoded client_id=6731de76-14a6-49ae-97bc-6eba6914391e &scope=user.read%20mail.read &code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr... &redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F &grant_type=authorization_code &client_secret=JqQX2PNo9bpM0uEihUPzyrh
これで晴れてAccessTokenが取得できます。
{ "token_type": "Bearer", "scope": "user.read%20Fmail.read", "expires_in": 3600, "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...", "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4..." }
「アプリケーションのアクセス許可」の仕方、ユーザーなしでアクセスを取得する
アプリケーションのアクセス許可も基本プロセスは似ていますが、要所要所でちょっと違います。
1. Adminconsentエンドポイントを使って、管理者の同意を実施
前述したとおり、一番最初に必要なことは、対象のアプリケーション(ClientID)に対して、管理者が同意するというプロセスです。「委任されたアクセス許可」とはURLやパラメータが違うことに注意してください。
GET https://login.microsoftonline.com/{tenant}/adminconsent ?client_id=6731de76-14a6-49ae-97bc-6eba6914391e &state=12345 &redirect_uri=https://localhost/myapp/permissions
また、レスポンスも変わり、「委任されたアクセス許可」であったようなCodeは含まれません。つまり、「アプリケーションのアクセス許可」の場合、同意と後続のプロセスは独立した形になります。
GET https://localhost/myapp/permissions ?tenant=a8990e1f-ff32-408a-9f8e-78d3b9139b95&state=12345 &admin_consent=True
2. 同意された後、AccessTokenを取得する
同意が完了したら、あとはAccessTokenを取得するだけです。前述したとおり、Codeを渡す必要は無いので、同意さえ取っていれば、どのタイミングで実施しても問題ありません。
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token HTTP/1.1 Host: login.microsoftonline.com Content-Type: application/x-www-form-urlencoded client_id=535fb089-9ff3-47b6-9bfb-4f1264799865 &scope=https%3A%2F%2Fgraph.microsoft.com%2F.default &client_secret=qWgdYAmab0YSkuL1qKv5bPX &grant_type=client_credentials
あとは、同じようにAccessTokenがレスポンスで変えるだけですが、Scopeが含まれないので要注意。
{ "token_type": "Bearer", "expires_in": 3599, "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBP..." }
※ちなみに、管理者の同意はAzure ADのアプリケーション管理画面で「アクセス許可の付与」をクリックすれば、特にURLの生成などは必要なく実施することができます。(逆に手軽に実施できてしまうので要注意)
余談:そもそも「管理者」ってどんな「管理者」?
GraphAPIとAzure ADのアプリリファレンスを見ていると、たくさんの「管理者」というキーワードに遭遇します。
そして、今ひとつどの管理者設定を入れておけば、この管理者という要件を満たすのかが、いまいちわかりづらいですね。
管理者の同意に必要な権限は何か?
結論から言うと、Azure AD ロールの「アプリケーション管理者(全体管理者でももちろんOK)」が必要です。
アプリケーション管理者:このロールのユーザーは、エンタープライズ アプリケーション、アプリケーション登録、アプリケーション プロキシの設定の全側面を作成して管理できます。 さらに、このロールは、委任されたアクセス許可とアプリケーション アクセス許可 (Microsoft Graph と Azure AD Graph を除く) に同意する権限を付与します。 このロールに割り当てられたユーザーは、新しいアプリケーション登録またはエンタープライズ アプリケーションを作成する際に、所有者として追加されません。
以下の画面で付与することができます。
なので、例えば、予定表を取得したいからといって、Exchangeの管理者権限が必要か? といえばそんなことは無いようです。アプリケーション管理者が同意してしまえば、そのClientIDはその権限にしたがって効力を発揮します。
ちなみに、私がはじめ勘違いしていたのですが、Office365 管理画面で表示できる、この画面の役割とさっきのAzure ADロール管理画面の役割は一緒です。同期されてます。
ただし、アプリケーション管理者のロールはAzure ADロール管理画面でしか付与することができませんので要注意。
実際に予定を取得してみる
というわけで、実際に予定を取得してみます。せっかくなので「アプリケーションのアクセス許可」で試してみましょう。シェアをしていないユーザーの想定です。
1. Azure AD アプリケーション登録
まず、リファレンスにある通り、「Calendars.Read.All」の権限を持ったAzure ADアプリを作成。
CientIDとCientSecretを取得します。(アプリの作り方は以前Blogで書いているので割愛。)
2. 管理者の同意を取得
さくっと、Azure ADの画面から実施してしまいます。
3. アクセストークンの取得
そして、アクセストークンを取得します。
POST /a67527d4-180e-4472-bcdd-bca82c56c70a/oauth2/token?api-version=1.0 HTTP/1.1 Host: login.microsoftonline.com Content-Type: application/x-www-form-urlencoded client_id=XXXXXXXXXXXXXXXXXXXXXXXXXX &scope=https%3A%2F%2Fgraph.microsoft.com%2F.default &client_secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXX= &grant_type=client_credentials
4. 指定ユーザーのイベントを取得
通常、自分自身のイベントを取得する場合は以下のようなURLですが
GET /me/events
他のユーザーのイベントを取得する場合はUsersの後にXXX@XXX.onmicrosoft.comといった形でユーザーを指定することで、予定を取得できます。
GET /users/{id | userPrincipalName}/events
実際にはこんな感じのリクエストですね。
GET /v1.0/users/user01@sugimomoto21.onmicrosoft.com/events HTTP/1.1 Host: graph.microsoft.com Authorization: Bearer eyJ0XXXXXXXXX
CData Office365 Driverの対応状況
ちなみに、CData Office365 Driverを使って、予定やファイルの取得が可能なのですが、今の所「委任されたアクセス許可」のみに対応中でした。
でも、やっぱり管理権限でバッチ処理を動かしたり、予定を横断的に取得したいというシナリオはよく聞くので、現在USチームと実装に向けてディスカッション中です。
もし、そういった使い方
https://www.cdata.com/jp/drivers/office365/
ちなみに、Excel-Addinで予定を取得する場合は、Office365 Excel Add-inをインストールして
Excelのリボンから「From Office365」をクリック
接続画面はDefaultのままでいいので、「Test Connection」をクリック
同意画面が表示されるので、内容を確認して、承諾するだけ。
接続が完了します。
あとは、Eventsテーブルを選択して、OKをクリックすれば
自分自身の予定データがずらっと取得できます。
おわりに
結構権限周りを調べるのはめんどいことがわかった記事でした。
結構悩む人は多いのではなかろうか。。。
追記 20210201
「アプリケーションのアクセス許可」と書くべきところを、「委任されたアプリケーションアクセス許可」と書いていたので修正しました。
Dynamics 365 Business Central GraphAPI(Beta)を触ってみる:トライアル取得からGraphエクスプローラーでアクセスするまで
Dynamics シリーズとしては初となる、GraphAPI エンドポイントが Dynamics Business Centralで提供されはじめましたー。
まだ、Betaの状況ですが、基本的な機能は試せる感じです。
今回はトライアルアカウントの取得方法とGraphエクスプローラーでテストするまでを書き留めておきたいと思います。
Dynamics 365 Business Centralって?
https://dynamics.microsoft.com/ja-jp/business-central/overview/
公式サイトから引用すると
財務、営業、サービス、運用を結び付けることができるオールインワンの ERP ビジネス管理ソリューション
もともとはDynamics NAVとして提供されていた製品が Dynamics 365に統合され、正式にクラウド版として提供を開始され、製品名をリブランディングした、といった形でしょうか。
日本では、PBCが日本語へのローカライゼーションを行って、提供していますね。
https://www.pbc.co.jp/product/microsoft-dynamics-nav/dynamics-365-business-central/
Business Central Graph APIドキュメント
以下のURLで API ドキュメントが提供されています。
もともとはDynamics 365 BC のユーザー画面やWeb Serviceの画面から認証用のKeyを発行したり、有効化を行ったりしていましたが、今回からGraphAPIに統合されたので、認証もAzure ADベースで行います。
Azure ADでのアクセス方法は以前私のBlodでも書いていましたが、今回はGraphエクスプローラーで簡易的に試すので割愛します。
GraphAPIなのでもちろんODataベースでの提供です。
Dynamics 365 BC自身も以前からODataでAPIを提供していたので、あまり操作感は変わらないでしょう。
ページングやフィルター、バッチ要求なども恐らくGraphAPIの機能範囲でサポートされると思いますが、細かなサポート範囲は特に記載がありませんでした。
トライアルを申し込む前に
トライアルにはUSのOffice365アカウント(XXX@XXX.onmicrosoft.com)が必要です。現在日本地域で取得したOffice365アカウントでは作成することができません。
Dynamics 365 のページからはアカウントを作ることができなくなっているみたいなので、適当にOffice365 USサイトからE3のトライアルを申し込むのがいいと思います。
https://products.office.com/en-us/business/office-365-enterprise-e3-business-software
Business Central の Free Trial を申し込む
US版Office365アカウントを取得してしまえば、環境の取得は結構簡単です。
以下のURLにアクセスして、「START FREE」をクリック
https://dynamics.microsoft.com/en-us/business-central/overview/
取得したUS版Office365アカウントを入力して、SignUP
あとは2クリックくらいするだけで、特に難しい設定はなく作業が完了します。らくちん。
Graphエクスプローラーで戯れる
それでは、APIを試してみたいと思います。
以下のURLにアクセスして、取得したアカウントでサインインします。
https://developer.microsoft.com/ja-jp/graph/graph-explorer
ログイン後、必要な委譲権限を追加します。権限はシンプルで、一つだけ。
Financials.ReadWrite.All
以下のようにドキュメントに記載されています。
これを付けて再度認証すればOKです。
APIの実行
Dynamics 365 BCは会社情報(Companies)を中心としてデータが集積されています。
なので、とりあえずCompaniesを取得してみます。
GET https://graph.microsoft.com/beta/financials/companies
{ "@odata.context": "https://graph.microsoft.com/beta/$metadata#financials/companies", "value": [ { "id": "c79fb153-0632-4e09-bad7-ccb78bd13dac", "systemVersion": "29776", "name": "CRONUS USA, Inc.", "displayName": "CRONUS USA, Inc.", "businessProfileId": "" }, { "id": "a5d0bc68-7ab8-4ab5-99ab-a30aa5d250f3", "systemVersion": "29776", "name": "My Company", "displayName": "", "businessProfileId": "" } ] }
次に対象のCompaniesが特定できたので、その会社に紐付いた顧客を取得してみます。
companiesに対象の会社GUIDを渡して、accountsエンドポイントを叩きます。
companies('c79fb153-0632-4e09-bad7-ccb78bd13dac')/accounts
GET https://graph.microsoft.com/beta/financials/companies('c79fb153-0632-4e09-bad7-ccb78bd13dac')/accounts
こんな感じで取得できました。
{ "@odata.context": "https://graph.microsoft.com/beta/$metadata#financials/companies('c79fb153-0632-4e09-bad7-ccb78bd13dac')/accounts", "value": [ { "@odata.etag": "W/\"JzQ0O3RRQ2NNZUZNMUtWa2VmQytLRHZQbmFtZW9od2JjTThFR3ZjbWpNWGtmQ3c9MTswMDsn\"", "id": "fed40b9a-754d-420a-82b0-03530193b3dc", "number": "40100", "displayName": "Income, Services", "category": "Income", "subCategory": "Income, Services", "blocked": false, "lastModifiedDateTime": "2019-03-24T13:21:11.5Z" }, { "@odata.etag": "W/\"JzQ0O3pCWG9YN2MxVnNGY0xSdWRYWWh6VVFiSTBkWUNmWVB4NHlvS2tBaXVQa2s9MTswMDsn\"", "id": "aa758160-4702-4a48-bb56-03dc92845959", "number": "10600", "displayName": "Prepaid Insurance", "category": "Assets", "subCategory": "Prepaid Expenses", "blocked": false, "lastModifiedDateTime": "2019-03-24T13:21:10.63Z" } ] }
せっかくなので、顧客情報の作成も試してみようと思いましたが、
https://docs.microsoft.com/ja-jp/graph/api/dynamics-create-customer?view=graph-rest-beta
POST https://graph.microsoft.com/beta/financials/companies('c79fb153-0632-4e09-bad7-ccb78bd13dac')/accounts
{ "number": "10000", "displayName": "Coho Winery", "type": "Company", "address": { "street": "192 Market Square", "city": "Atlanta", "state": "GA", "countryLetterCode": "US", "postalCode": "31772" }, "phoneNumber": "", "email": "jim.glynn@cronuscorp.net", "website": "", "taxLiable": true, "taxAreaId": "taxAreaId-value", "taxAreaDisplayName": "tax area", "taxRegistrationNumber": "28012001T", "currencyId": "currencyId-value", "currencyCode": "USD", "paymentTermsId": "paymentTermsId-value", "shipmentMethodId": "shipmentMethodId-value", "paymentMethodId": "paymentMethodId-value", "blocked": false, "overdueAmount": 0, "totalSalesExcludingTax": 0, }
「Entity does not support insert.」と怒られてしまいました。このあたりはまだBetaだからなんでしょうか?
{ "error": { "code": "BadRequest_MethodNotAllowed", "message": "Entity does not support insert.", "innerError": { "request-id": "ca27a7a2-caca-485e-86b4-4e5138f760a6", "date": "2019-04-14T06:50:37" } } }
とりあえず、試せるだけ試せることがわかったので、今回はこれで満足です。
Publicリリースはいつになるのか、気になるところですねー。
Dynamics 365 for Customer Engagement (Dynamics CRM) のデータを ローカルの SQL Server に1時間に1回バックアップする:CData Sync
クラウドサービスを使っていて、一番面倒なことの筆頭として、「バックアップどうするの?」があげられるんじゃないかなと思います。
もちろん、何を観点として「バックアップ」と言うのか? については多くの議論が必要になるでしょう。
Dynamics 365 自体もクラウドとしてディザスタリカバリやデータセンターのバックアップについては十分ちゃんとした対応を取っています。
でも、自分たちの手元に自分たちがコントロールできる状態にデータを持っておきたい、という考えはベンダーに依存するよりも健全であるし、多様なクラウドサービスの選択肢がある今の時代においては適切な判断ではないかと思っています。
それは採算やコスト度外視なアプローチではなく、現実的なラインで自分たちが適切にコントロールしメリットを感じられるスケールで行うことが大事かなと。
今回はそんなバックアップ手段の一つの選択肢として、Dynamics 365 for Customer Engagement のデータをローカルのSQL Serverにバックアップする方法を書き留めておきたいと思います。
続きを読む2月20日にWindows女子部で「Dynamics 365 Customer Engagement 理解のススメ -サブスクリプションビジネスモデルから読み解くカスタマーサポート機能活用のポイント-」の発表をしてきました
久しぶりに Dynamics 365 一色なセッションを2月20日にWindows女子部で発表してきました。
(Burikaigi 2019ではちょっといろいろ手を出していたのと共同セッションだったので、また今回は毛色が違いますね。)
第して、「Dynamics 365 Customer Engagement 理解のススメ -サブスクリプションビジネスモデルから読み解くカスタマーサポート機能活用のポイント-」
以下でセッションスライドを公開しています。
なんでこんな発表をしようと思ったのか?
今回 Windows 女子部という、あまり普段 Dynamics に馴染みが無い層の方々向け、ということを考えていた部分もありますが、
おそらく大きく影響したのは私自身が「SIerでは無くなったこと」が大きなきっかけとしてあるなと思います。
視点が実際にCRMを使って、業務を効率化したり、可視化する側のエンドユーザーサイドに立ったことで、今までの自分自身の知っているコンテンツを棚卸しし、かつ私自身のエンドユーザー経験も踏まえて、Dynamics ってこういうことじゃないの? というお話をまとめてみたいなーという野望がありました。
かつ、昨今 Power Platform (Power Apps / Power BI / Flow)が広まって、徐々に認知されるようになってきた Dynamics 365 シリーズですが、まだ実際に触った方は少ないのではないかなと思うので、そもそも Dynamics 365 を理解するためには、何から始めるべきなのか? という下地の部分を訴えてみたかったところもあります。
機能とかデータモデルとか触ってみるとかのその前に、「考え方」「捉え方」から伝えてみたい。それが以下の1スライドのメッセージでも掲げられているところかなと思っています。
Dynamics 365 CEを理解するためには Dynamics 365 CE を知る・触るよりも前に 何かの課題を解決しようとした ビジネスモデル・手法を理解する必要がある
それをより明確に伝えるため、昨今のビジネスモデルの流れ、サブスクリプションビジネスモデルを取り上げることで、よりよく Dynamics 365を理解するための礎になればという感じでした。
個人的にテクニカルな内容は5%くらいで、かなり新しい試みのセッションになりました。
すごく独断と偏見と経験にまみれた内容ではあります。(Microsoftはこんなことを言ってはいないw)
でも、ビジネスモデルに多様な「解」があるように、おそらくこれも一つの「解」なのだと思って見てもらえると嬉しいです。
今後 Dynamics 365 の導入を予定されている会社の参加者からも「すごく参考になった、ここのなぜ? どうやって?使うのかという意識の部分は、私の会社でも根付かせていかなければいけない」といったコメントをいただけて、個人的な棚卸しも含めてとても有意義なセッションだったなと思います。
せっかくなので、このあたりの「考え方」の部分は、今後もどこかで発表しつつ棚卸ししていきたいなと思った次第です。
Microsoft MVP更新の季節。CData Excel Add-Inを使って、Twitter での活動情報をさくっと可視化してみる
Microsoft MVP 更新の季節がやってまいりました。
昨年から Microsoft MVP の更新スケジュールが代わって、年度末である3月に統一されましたね。
Microsoft MVPの申請・更新には日々どのような形でコミュニティに貢献したかどうかを数値化、文書化して貢献度を可視化する必要があります。
昨今ですと、Twittter や FacebookなどSNSでの活動状況も入力するシチュエーションがあるかと思います。
ただ、ちまちまと記録をさかのぼって、集計するのもなかなか骨が折れる作業ですね・・・。
そこで、そんな面倒な作業を CData Excel-Addinを使って、Excel上でさくっと集計・可視化する方法を紹介します。
Microsoft MVP 向け CData ツール・ドライバーの無償提供
ちなみに、通常 CData Driver は有償のツールなのですが、Microsoft MVP向けには個人利用の範囲で無償のライセンスを提供しています!
以下のURLから申請することが可能ですので、是非申し込んでみてください。
https://www.cdata.com/jp/community/mvp/
私のTwitterやFacebookに直接ご質問頂いても大丈夫です。
ちなみに、今回はTwitterですが、FacebookやInstagram、Youtube、Wordpress などのExcel Add-inもあるので、そちらも集計することが可能です。
必要なもの
・Twitter アカウント
・Twitter ClientID・ClientSecret・AccessToken・AccessTokenSecert
実施手順
それでは具体的な実施手順を説明していきます。
Twitter アプリ登録・認証用情報の取得
まず CData Excel Add-inを通じて Twitter APIにアクセスするために、Twitter APIアクセスに必要な各種情報を入手します。
詳しい入手方法は以前私がBlogにしたためているので、参考にしてみてください。若干UIが変わっていますが、大筋は同じです。
CData Twitter Excel-Addinのダウンロード・インストール
次に、CData Twitter Excel-Addinを入手します。
以下からトライアル、もしくはMVP用のライセンスがあればそれを使って、ダウンロードし、セットアップしておいてください。
https://www.cdata.com/jp/drivers/twitter/excel/
セットアップは特に難しい設定はありません。
そのまま次へ次へと進めていくだけでインストールが完了します。
CData Twitter Excel-Addin の 接続設定
インストールが完了するとこのようにExcelにCData タブが追加され、アドインを利用できるようになります。
それでは、実際に接続をしてみましょう。「取得元Twitter」をクリックして、接続画面を表示します。
表示された接続プロパティ画面に、事前に取得しておいた「ClientID・ClientSecret・AccessToken・AccessTokenSecert」を入力します。
OKをクリックして、接続テストを行い、以下のように「サーバーに接続できました」というメッセージが表示されれば、OKです。
CData Excel Add-inでは、SQLベースでTwitterのデータが取得できるようになっています。
SQLを知らなくとも、Twitter データがテーブルやビュー・カラムの構造になっているので、かなり直感的にTwitterのデータが取得できると思います。
今回は自分自身のツイートデータを取得したいので「Tweets」テーブルを選択します。
そして、下のSQL入力フォームに、各種条件のSQLを記述します。
例えば今回私はDynamics のデータを取得したいので、「[From_User_Screen_Name] = 'sugimomoto'」で私のツイートの絞り込み、「Text Like '%Dynamics%'」で Dynamics に部分一致の指定を行います。
SELECT * FROM [CData].[Twitter].[Tweets] WHERE [From_User_Screen_Name] = 'sugimomoto' and Text Like '%Dynamics%'
入力完了後、OKをクリックすれば
このように過去に私がDynamics についてつぶやいたツイートの一覧が取得できます!
あとはピボットテーブルで、IDの合計でツイート数、Favorite_CountとりRetweet_Countを取得すればOKですね。
(私の今年度の Dynamics ツイート少ないな・・・orz)
注意事項
Twitterの無償APIは最新のものから最大3200件までしか、ユーザータイムラインのツイートを取得できません。
上記出力結果は3200件のデータを裏で取得して、そのなかの Dynamics が含まれているキーワードだけ算出しています。
1年間に3200ツイート、1ヶ月260ツイートくらいまでが取得の目処になるので、Twitter中毒の方は要注意。4半期に1回とかやっておくといいかもしれないですね。
有償のAPIを使えば、もっと柔軟に取得できますが、なかなかお高いです・・・。(最低1万円はくだらない。)
終わりに
いかがでしたでしょうか!
今回はTwitter データだけでしたが、前述の通り他にもFacebookやInstagram、YoutubeなどのDriverもあるので、是非各種Driverでも試してもらえればと思います。
何かわからないこと、こんなことできないの? みたいなご質問があれば、TwitterかFacebookでお気軽にどうぞー。
2月20日(水)に虎ノ門で「Windows女子部/初心者向け:Dynamics365 カスタマーサポート業務での活用ポイント解説」を開催します!
Burikaigi 2019に続いて、Dynamics 365 関係で登壇することになりました。
今回はMS MVP の方々がリレー形式で登壇を担当する企画を開催している「Windows女子部」で発表します。
そして、珍しくというか、久しぶりにというか、初心者向けと銘打って、カスタマーサポート機能を中心に「Dynamics 365 Customer Engagement」を解説する予定です。
具体的にどんなお話をするの?
でも、そもそも今回お話する「Customer Engagement」、名前からして、今までDynamics 365 に関わってこなかった方々にはよくわかんないですよね。
顧客管理とかSFAとかMAとか、キーワードや世の中の風潮?みたいなもので大事っぽいっていうのはなんとなく理解している。
でも、じゃあ Dynamics 365 を使ったからって何が変わるの? っていうのがイメージできない。そんな方が多いのではないかなーと漠然と思ってます。
今回実は初心者向けとは銘を打ちつつも、個人的に結構新しい試みをしていて、昨今のビジネスモデルを土台にしながら、Dynamics 365 をどのように解釈すればいいのか? その上で、なんでこんな機能があるのか? どんな風に使えるのか? というのをお話する予定です。
是非、今まで Dynamics 365 を触ったことが無い人も、触っている人も、開発している人も、参加してもらいたいなーと思います。
3月1日(金)に仙台で「【JAZUG TOHOKU】ZOZO前澤社長お年玉リツイート企画のビッグデータに立ち向かう方法」を開催します!
1月28日(月)に日本マイクロソフト品川本社セミナールームで開催した「ZOZO 前澤社長のお年玉リツイート企画は、どのくらい世の中に影響を与えたのか?」の仙台スピンオフを開催することになりました!
イベントページはこちらからどうぞ。
【JAZUG TOHOKU】ZOZO前澤社長お年玉リツイート企画のビッグデータに立ち向かう方法 - connpass
東京開催時のTwitterまとめもあるので、どんな感じなのかなーと気になっている方は見てみてください。
会場は以前も Azure 勉強会でお世話になりましたSRIAさんのオフィスです! 仙台駅から徒歩圏内。
セッション終了後には LT & ビアバッシュ会になっていますので、是非お気軽にご参加ください!