ワークフローサンプル: 第506話：社外パートナとも安全なファイル共有！

「あのプレゼン資料、PDFではなく、PPTファイルで下さい！」

社内のファイル共有。。。イマドキであれば「クラウド型ストレージ」を活用しているだろう。（昔は「ファイルサーバ」ってのがありましたが。。。）

ただ「関連会社や代理店とのファイル共有」や「共同プロジェクトにおけるファイル共有」といった場合、相手が『社内』ではないので、色々とメンドウだ。もし「メール添付で共有する」となれば、催促するまで届かなかったり、関係ないファイルも一緒に届いてイラっとしたり、逆に自分自身も「欲しいと言われるまでは共有しなくてもイイか…」と躊躇してしまったりしてしまう。（そもそもメールプロトコルには、セキュリティ面での不安もある）

そんな時には「ユーザ数10億人」の Google アカウントを活用するのが良い。

「Google Drive」にプロジェクト用のフォルダを作って、そのフォルダの共有設定でチーム全員の「Google アカウント」を追加しておけばよいのだ。（「Google アカウントを持ってない人」が居ませんように・・・・）

以下はチーム内のワークフローで承認されたファイルが、自動的に「Google Drive」にアップロードされる仕組みだ。

もし『G Suite』（Google Apps）のユーザが居て「社外共有」が認められているのであれば、Questetra 標準の［サービスタスク（Googleドライブ）］（M229）を配置すれば済むのだが、、、このケースでは「Google Drive」が、一般の gmail.com / googlemail.com アカウントで運用されることが想定されている。

[ファイル承認フロー]

この仕組みには Questetra 標準にはない自動工程が利用されている。（アドオン XML で追加されている）

そして、このワークフローを稼働させるには、幾つか事前の設定が必要となる。つまり、この「ファイルアップロード」という自動処理が「認可」されていなければならない。具体的には、オーナー自身が『Google API Manager』にて、必要な情報をプロジェクト登録して『Consumer Key』と『Consumer Secret』を取得し、その情報を Questetra 側の［OAuth2.0設定］に登録しなければならない。

＜Google側の設定サンプル＞

Authorized redirect URIs (承認済みのリダイレクト URI): https://s.questetra.net/oauth2callback

＜Questetra側の設定サンプル＞

Name: Q2Drive
Authorization Endpoint URL: https://accounts.google.com/o/oauth2/auth?access_type=offline&approval_prompt=force
Token Endpoint URL: https://accounts.google.com/o/oauth2/token
Scope: https://www.googleapis.com/auth/drive
Consumer Key: (Google Developers Console で取得)
Consumer Secret: (Google Developers Console で取得)

ちなみに、この例では「自動工程追加ファイル（アドオン XML）ダウンロード」に掲載されている自動工程をそのまま活用しているので、15分程度で末尾添付の Questetra ワークフローを設計できた。。。

しかし、もし、、、『自分で「オリジナルの自動工程」を実装したい！』となれば、それは簡単な話ではない。つまり、

認証や認可に関する知識
リソースサーバ側の API 仕様
クライアントとなる Questetra でのプログラミング知識

といった知識が必要となり、特に今回の『Google Drive APIs v3』の様な難易度・自由度の高い API を使用する自動通信工程には、それなりに実装の手間が必要となってくる。

ちなみに Google Drive は、当初「フォルダの概念」が無かったこともあり、今日に至っても

複数のフォルダに所属できる
ユニークなファイル名である必要がない

といった特性を持っているため、どうしても他のストレージ系 API より複雑な実装になってしまう。（Drive におけるフォルダは「"mimeType": "application/vnd.google-apps.folder"」というファイルでしかない）

ここで活用されている「upload-googledrive-20161019-addonxml」においても、

『Upload URI』に対して［Simple upload］(5 MB 制限)で POST してから、
『Metadata URI』に対してファイル名と親フォルダの PATCH を行う

という回りくどい実装方式となっているが、ストレートな実装方式（［Multipart upload］による POST）の場合、API 側は multipart/related （RFC2387）でのファイル送信を求めるのに対して、クライアント側に用意されているメソッドでは実現できないという状況にあるのだ。

もし「こんな自動工程が欲しいんだけど」と思ったら、一覧への掲載をリクエストしてみるのも良い。

▼通信部分のコード

var uri = "https://www.googleapis.com/upload/drive/v3/files?uploadType=media";
var response = httpClient.begin()
  .bearer( token )
  .body( files.get(i) )
  .post( uri );
accessLog += "---POST request--- " + response.getStatusCode() + "\n";
accessLog += response.getResponseAsString() + "\n";

var jsonObj = JSON.parse( response.getResponseAsString() );
var uri2 = "https://www.googleapis.com/drive/v3/files/";
uri2 += jsonObj.id;
var myObj2 = {};
myObj2.name = files.get(i).getName() + "";
var response2 = httpClient.begin()
  .bearer( token )
  .queryParam( "addParents", folderId )
  .queryParam( "removeParents", "root" )
  .body( JSON.stringify( myObj2 ), "application/json" )
  .patch( uri2 );
accessLog += "---PATCH request--- " + response2.getStatusCode() + "\n";
accessLog += response2.getResponseAsString() + "\n";

[ファイル承認フロー：「2.承認」画面]