最終回です。ここまでの 5 回で、GitHub の課題を読み、作り、更新し、値を取り出せるようになりました。残るは、うまくいかないときの話です。
外部のサービスとやりとりする工程は、こちらの設定が正しくても失敗します。相手が一時的に止まっていることもあれば、トークンの期限が切れていることもあります。失敗そのものは防げません。用意できるのは、失敗したときに誰かが気づいて対処できる仕組みです。
前回：第 5 回 レスポンス活用編 — 返ってきた JSON から値を取り出す
エラー内容の保存
第 1 回で、文字 (複数行)のデータ項目を 2 つ用意しました。「レスポンス」（q_response）と「エラー内容」（q_error）です。後者を設定していない工程があれば、今のうちに指定しておいてください。
このデータ項目は、正常に処理できたときは空のままです。何か起きたときだけ、理由が書き込まれます。つまり、この項目が空かどうかを見れば、その工程が成功したかどうかが分かります。
GitHub が返してくるもの
エラー内容には、GitHub が返した状態コードと説明が入ります。よく出会うものを挙げます。
401 は、こちらが誰なのかを GitHub が確認できなかった状態です。トークンの文字列が誤っているか、有効期限が切れています。［HTTP 認証設定］を見直してください。トークンには期限があるので、しばらく動いていたアプリが突然この状態になることがあります。
403 は、こちらが誰かは分かったが、その操作を許していない状態です。REST API を短時間に呼び出しすぎた場合もここに含まれます。GitHub には一定時間あたりの呼び出し回数の上限があり、超えると受け付けてもらえません。現在の残り回数は次の宛先で確認できます。
https://api.github.com/rate_limit
404 は、宛先が見つからない状態です。ただし GitHub では、権限が足りないときも 404 を返すことがあります。存在しないふりをすることで、非公開のリポジトリの有無を外から探れないようにしているためです。URL に間違いがないのに 404 が返るなら、トークンの権限を疑ってください。
422 は、宛先も権限も正しいが、送った内容が受け付けられない状態です。第 3 回で扱った JSON の組み立てに問題があるときに出ます。多くは escapeJson の付け忘れです。
送る前の確認
工程を作っている最中は、ケースを一から流し直すより、その工程だけを試せたほうが早く進みます。
工程のプロパティのメモ欄の下に［この工程のみデバッグ］ボタンがあります。これをクリックすると、開始イベントとヒューマンタスク、対象の工程、終了イベントだけからなる仮のワークフローが用意されます。フォームに値を入れて工程を通し、レスポンスとエラー内容を確かめる。この繰り返しで設定を詰められます。
なお、この工程から送られるリクエストには、Questetra-Debug というヘッダが必ず付きます。値は、デバッグケースや［この工程のみデバッグ］からの実行なら true、通常のケースなら false です。相手が自社で用意したシステムであれば、この値を見て本番のデータを書き換えないようにする、といった作りにできます。GitHub のような外部のサービスはこのヘッダを見ませんから、デバッグ実行でも課題は本当に作られます。練習用のリポジトリで試してください。
止まったままにしない仕組み
設定が正しくても、運用の中では失敗します。そのときにケースがどう進むかを決めておきます。
［メッセージ送信中間イベント (HTTP)］の後ろに［分岐 XOR ゲートウェイ］を置き、遷移条件で「エラー内容」のデータ項目を選び、「値が入力されていない」を条件にします。入力されていなければ、そのまま先へ進めます。入力されていれば、人の工程に戻します。
置く位置は、その［メッセージ送信中間イベント (HTTP)］のすぐ後ろです。第 5 回で［スクリプトタスク］を足した工程では、スクリプトタスクよりも手前になります。並びは［メッセージ送信中間イベント (HTTP)］→［分岐 XOR ゲートウェイ］→［スクリプトタスク］です。この順にしておけば、通信が失敗して JSON でないものが返ったときに、スクリプトタスクまで進みません。第 5 回の末尾で触れた「そのまま解釈しようとするとスクリプトタスクがエラーで止まる」を防ぐのが、この配置です。
また、この分岐は［メッセージ送信中間イベント (HTTP)］ごとに、それぞれの直後に置いてください。「エラー内容」は全ての工程で共有しているので、まとめて後ろで判定しようとすると、後続の工程が成功した時点で空に上書きされ、どの工程が失敗したのかを追えなくなります。
戻す先の工程では、エラー内容のデータ項目を表示専用で置いておきます。処理担当者は、何が起きたのかをその場で読めます。原因を直してもう一度送る経路と、GitHub への登録をやめて手作業に切り替える経路を用意しておけば、ケースがどこにも進めなくなることはありません。
自動工程が失敗したときにどの工程へ戻るのかを決めておくと、外部連携を含むワークフローを運用に乗せられます。
連載のまとめ
6 回を通じて、ひとつのワークフローアプリを組み上げました。社内から上がった改善要望を受け付け、GitHub の課題として起票し、進捗をコメントで伝え、完了したら閉じるアプリです。開発チームは Questetra BPM Suite の工程を処理していくだけで、GitHub 側への書き込みは、置いた［メッセージ送信中間イベント (HTTP)］が代わりに行います。同じ内容を二度入力する手間がなくなります。
題材は GitHub でしたが、ここで扱った考え方はほかのサービスにも当てはまります。宛先を URL で指定し、送る形式を選び、認証を添え、返ってきたものを受け取り、失敗に備える、という 5 つです。
