みなさん、こんにちは。カスタマー・サポート課のマツシタです。
re:Inventの話題で盛り上がっている我々の業界ではあります。弊社は今年も無事APNプレミアコンサルティングパートナーに選ばれました。
これからも一層、AWSに精進してまいりたい次第ですが、ワタシは、本日もQuestetra BPM Suite（以下、Questetra）からWeb APIを繋いでいきたいと思います。
過去のWeb APIで繋がるシリーズ
Web APIで繋がる Questetra / Slack / Trello 連携
Web APIで繋がる Questetra / Backlog 連携
Web APIで繋がる Questetra / Box 連携
QuestetraとBacklogの連携を紹介させていただきました際にサラッと流してしまったのですが、Questetraワークフローから別のQuestetraワークフローをコールすることも改めて紹介しておこうと思います。
別のワークフローをコールするには2つのパターンがあります。
新しいワークフローを起動させる
新しいワークフローを起動させたい場合には次のように「メッセージ送信中間イベント（http）」を設定します。
通信設定
| URL | https://＊＊＊＊＊.questetra.net/System/Event/MessageStart/start |
|---|---|
| メソッド | POST |
送信パラメータ
| key | APIキー |
|---|---|
| processModelInfoId | プロセスモデル番号 |
| nodeNumber | ノード番号 |
| data[x].input | 引数（必要に応じて;x=0,1,2,3...） |
レスポンス
| (任意の変数名) | 起動したプロセスID |
|---|
新しいワークフローを起動した場合、正常に起動できると返り値として起動したプロセスIDが得られます。
他のサービスとの連携だと、その返り値はJSON形式だったり、XMLだったりします。
Questetraワークフローから返り値はプロセスIDがそのまま返されます。
例えばプロセスID「11111」というプロセスを起動した場合には、返り値は「11111」となります。
数値IDのみを返されるので、それをスクリプトでパースしてIDだけを抽出するような手間がいらない点が便利です。
既に起動されている待ち状態のワークフローを再開させる
既に起動されている待ち状態のワークフローを再開させる場合には、次のように「メッセージ送信中間イベント（http）」を設定します。
通信設定
| URL | https://*****.questetra.net/System/Event/IntermediateMessage/receive |
|---|---|
| メソッド | POST |
送信パラメータ
| key | APIキー |
|---|---|
| processId | プロセスID |
| nodeNumber | ノード番号 |
| data[x].input | 引数（必要に応じて;x=0,1,2,3...） |
新しいワークフローと異なり、既に起動されているのでプロセスモデル番号ではなく、プロセスIDを指定します。
では、続いて受信側の設定を紹介します。 受信側も送信側同様に新しくワークフロー開始する場合と、待ち状態のワークフローを再開させる場合の2つのパターンが存在します。 ただ、プロセス図のアイコンが異なるだけで、設定項目が同じなので、まとめて紹介します。
受信側の設定
新しくワークフローを開始する場合には「メッセージ開始イベント（http）」を使います。
待ち状態のワークフローの再開ポイントには「メッセージ受信中間イベント（http）」を使います。
設定項目としては、受け取ったhttpリクエストが既存の各プロセスデータ項目を更新して良いかの編集可否の設定のみです。
具体例
編集可否の二択ですが、注意すべき点があります。具体例で紹介します。
次のような3つのプロセスデータ項目があったとします。
| プロセスデータ項目名 | 変数型 | 番号 | 必須 | 編集可否 |
|---|---|---|---|---|
| X | 文字列 | 0 | Yes | 編集可 |
| Y | 文字列 | 1 | Yes | 表示なし |
| Z | 文字列 | 2 | Yes | 編集可 |
送信側でPOSTするパラメータを次のように設定を行った場合にどうなるでしょうか？
→Xには「aaa」が代入されます。Y、Zには何も代入されません。
data[0].input="aaa"は番号0のプロセスデータ項目に"aaa"を代入するという意味です。
data[1].input="bbb"は番号1のプロセスデータ項目に"bbb"を代入しようと試みます。
しかし、プロセスデータ項目「Y」の編集可否が「表示なし」というのは「編集不可」という意味と同義なので、
値を渡しても、その値が代入されることはありません。
番号2のプロセスデータ項目には値をPOSTしていないので、プロセスデータ項目「Z」には何も代入されません。
さて、その後、このワークフローは起動、もしくは再開されるでしょうか？
→ワークフローは起動せずにエラーが返されます。
なぜなら、「編集可」且つ「必須」なパラメーターには必ず値をPOSTしないとワークフローは起動、もしくは再開されません。
例えば、番号2のプロセスデータ項目「Z」が「必須ではない」、もしくは「表示なし」の場合にはワークフローは起動、もしくは再開します。
そして、起動された場合には、新たに起動されたプロセスIDが返されます。
いかがでしたか。Questetraワークフローから別のQuestetraワークフローの起動、もしくは再開ができるようになりましたね。
最後に一番大切な注意事項
ただし、注意しないといけないことがあります。
httpリクエストでワークフローを起動した場合に、起動元のワークフローと起動されたワークフローをつなぐ情報はQuestetra上にありません。
後で、不具合や不正処理などをトリガーにデバッグしようとした場合に確定的な紐付ける情報がないので大変困ります。
では、その問題をどのように解決するか。それには受け渡す変数に送信側のプロセスIDも含めるのが良いでしょう。
送信側のプロセスIDが受信側で必要な情報ではなかった場合にも、必ず送信情報に含めておくことでデバッグできるようになります。
QuestetraワークフローではプロセスIDがユニークなIDになります。デバッグするためには必ずお互いのプロセスIDを保持させるように
設計することを推奨します。
サンプルイメージ
最後に、全体像のサンプルイメージを紹介します。
上のスイムレーンの左から開始します。入口は通常の手動起動とhttp起動を用意しました。
http起動の場合はスクリプトで渡された値の入力確認を行い問題がなければ手動入力のタスクはスキップします。
入力に不備があった場合や、手動起動の場合は入力タスクへ進みます。
そして、必要な情報を入力された場合に「メッセージ開始イベント（http）」から下のワークフローにPOSTされます。・・・（１）
下のワークフローでも値の処理をスクリプトで実行し、「メッセージ開始イベント（http）」を使って、
Backlogやbox、AWS、Salesforceなどのサービスと連携し処理を実行します。・・・（２）
そして、再度、「メッセージ開始イベント（http）」を使って処理の結果を上のワークフローに返します。・・・（３）
下のワークフローでも手動起動ができるようにしています。
手動処理を通常は行わないワークフローでも手動で起動できるようにしておくことで試験やデバッグが容易になります。
上のワークフローに戻り「メッセージ受信中間イベント（http）」で処理結果を受け取り、タスクでその結果を確認し、このワークフローを終了させます。
http起動時に不備がなければ、この最後のタスクまでは全自動で処理されることがわかっていただけるでしょう。 定型化されたタスクは自動化させていくと一切の人手を介さずに処理できるのです。なんと素晴らしい！！
松下 稔 (Minoru Matsushita) 記事一覧はコチラ
クラウドインテグレーション部SRE3課
かれこれ入社8年目を迎えました。
数字集計をExcelからAthenaに置き換えられないか模索中。
