Office365 とクラウド型ワークフローとの連携方法について
SharePointOnline と Questetra との連携についての調査

 

システム連携ネタでよくブログを書いている日下です。
※ちなみにこれまでのネタはこちら

 

以前に「Office365 とクラウド型ワークフローとの連携状況」●注●として、その当時にわかっていた範囲でまとめたことがあります。ただ、その際は Office365 の API 呼出については深く調べるところまではできていませんでした。
※ちなみに、AzureAD との認証連携(シングルサインオン)については、別の記事●注●にある通り、以前から対応できています。
(●過去の記事は移行準備中です。少しお待ちください●)

 

今回は主に SharePoint Online との連携(Questetra から SharePoint Online へのファイル出力など)を意識して、実際に API で対応できるかどうかを調べた内容をまとめました。(認証部分は AzureAD との処理になりますので、SharePoint Online 以外の Office365 のサービスや Dynamics365 等の AzureAD で認証するサービスにも適用されるはずです)
※ちなみに Office365 API および AzureAD については、資料が多すぎて目的の資料になかなかたどりつけなかったのと、こういった横串でまとめた資料が見当たらなかったので、なかなか苦労しました・・・

 

目次
1: Office365 API 利用のための AzureAD 認証の種類
2: Questetra による各エンドポイントでの認証の可否
3: まとめ

 

1: Office365 API 利用のための AzureAD 認証の種類

Office365(SharePoint Online)の API を呼び出すための認証は、以下のいずれかを使うことになります。

 

AzureAD v2.0 endpoint(以降「AADv2」)

アプリケーション登録:Application Registration Portal(apps.dev.microsoft.com)から
認可エンドポイント URL:https://login.microsoftonline.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
トークンエンドポイント URL:https://login.microsoftonline.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token

 

AzureAD v1.0 endpoint(以降「AADv1」)

アプリケーション登録:AzureAD から
認可エンドポイント URL:https://login.microsoftonline.com/{tenant}.onmicrosoft.com/oauth2/authorize
トークンエンドポイント URL:https://login.microsoftonline.com/{tenant}.onmicrosoft.com/oauth2/token

 

AzureAD Access Control(以降「ACS」) ※SharePoint Online のみ

アプリケーション登録:https://{tenant}.sharepoint.com/_layouts/15/appregnew.aspx から
認可エンドポイント URL:https://{tenant}.sharepoint.com/_layouts/15/OAuthAuthorize.aspx
トークンエンドポイント URL:https://accounts.accesscontrol.windows.net/{tenant}.sharepoint.com/tokens/OAuth/2

 

それぞれの方式によってアプリの登録方法が異なり、使える API が異なります。またそれぞれ OAuth2 の4つの grant_type(Authorization Code / Client Credentials / Password / Implicit)に対応されているようです。

ちなみに、ACS はもともと AzureAD が登場する前から SharePoint のために準備されていたもののようです。古い方式ですので、なるべくなら使わない方がよさそうかと考えています。あと AADv2 が一番新しい方式になるのですが、現在対応を進めている途中のようで、現時点では AADv1 でないと実行できない API 処理が結構多くあるようです・・・

 

2: Questetra による各エンドポイントでの認証の可否

仕様上の制約などから Questetra から認証ができるものとできないものがあります。

grant_type が Authorization Code の場合、「OAuth2.0 設定」の設定だけで対応可能ですが、無期限のアクセストークンが発行できる場合に限定されます。ちなみに AzureAD は無期限のアクセストークンが発行できるので、問題ありません。

grant_type が Client Credentials / Password の場合、「スクリプトタスク」で対応可能です。ただ、Client Credentials の場合は UserContext にひもづかない認証となるため、使える API が限定されます。Password の場合ですが、今回のケースでは API アクセス側 = Questetra でパスワードを保持する形になりますので、問題ないと考えています(通常 grant_type の Password は API アクセス側にパスワードが渡ることがネックになりますが、その点は問題にならないという意味で)

可否を整理すると以下の通り。

  • AADv2、Authorization Code
    「OAuth2.0 設定」でアクセストークンが取得でき、API 呼出もできた。ただし、API の中には http ヘッダでの値の指定が必要なものがあり、Questetra の制約(現在は「X-」 始まりのもの、「BoxApi」、「Dropbox-API-Arg」のみ許可)にひっかかるものについては呼出できず。そういったケースは中間プログラムをはさむことで API 呼出できた
  • AADv1、Authorization Code
    AzureAD から戻ってくる expire_in の型が RFC に反しているため「OAuth2.0 設定」でアクセストークンが取得できず。中間プログラムをはさむことで API 呼出できた
  • AADv1、Client Credentialns/Password
    「スクリプトタスク」でアクセストークンを取得できたが、Questetra には http ヘッダに設定できる文字数の制限(現在は1000文字まで)があり、アクセストークンは1000文字を超えるケースばかりで、そのトークンを使って API 呼出できず。中間プログラムをはさむことで API 呼出できた
  • ACS、Authorization Code
    トークンエンドポイント URL で resource パラメータを指定することができないため「OAuth2.0 設定」でアクセストークンが取得できず。中間プログラムをはさむところまでは試さず
  • ACS、Client Credentialns/Password
    試せてないが、http ヘッダの文字数の制限にひっかかると想定される

 

3: まとめ

以上の結果から、目的が限定されていれば AADv2 により Questetra からの直接処理だけで実現できるケースはあるが、用途によっては中間プログラムによるカバーが必要となります。

中間プログラムとしては、DataSpider Cloud 等のEAIツール・データ連携ツール等でも対応可能ですし、マイクロソフトの Microsoft FlowLogic AppsAzure Functions 、また AWS LambdaAmazon API Gateway 等の利用も考えられます。
※今回は DataSpider Cloud の元となるオンプレ版の DataSpider Servista で試してみました。SharePoint Online への連携だけでなく Excel Online へのデータ挿入なども確認できました。

また、今後の Questetra の改良によって、中間プログラムなしで実現できる範囲が広がる可能性も考えられます。

 

もし、ご質問等がありましたら、お問い合わせフォームからご連絡ください。

 

※参考資料

 

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください