[ServiceNow]Flowにおいて開発者側ではキャッチできない例外が発生することがあるので、特に外部連携を組み込む際は注意

ServiceNowのFlow designerを用いてワークフローを開発する際は、開発者側ではキャッチできず、Flow全体が強制停止してしまう例外が発生することがあるので、運用での対応を予め検討する必要があることが分かったので、詳細をシェアします。なお、この記事はQuebecバージョンの情報をもとに書いています。また、Workflow editorはもう古い機能なので、この記事では扱いません。

どのような例外がキャッチできないか

Flow designerでは、下記のような例外・エラーについては開発者側でキャッチし、処理することが可能です。
・Script内で例外が発生した場合（存在しない変数を参照しようとした場合など）
　→ Script内にtry, catchを書くことで処理が可能
・カスタムAction内に組み込んだREST stepにおいて、400,500番台のエラーが返ってきた場合
　→ 続くstepにおいて、ステータスコードに応じた処理を行うScriptを書くことで処理が可能

一方で、下記のような場合は、開発者側で例外・エラーをキャッチ、処理することが不可能です。
・既存Action内でエラーが発生した場合（適切な入力を渡さなかった場合など）
・カスタムAction内に組み込んだREST stepにおいて、レスポンス自体が返ってこないような通信系の例外が発生した場合（通信先ホストが落ちていた場合など）
これらの例外・エラーは外部連携をFlowに組み込む場合には必ず発生する可能性があり、かつ対向システム都合で発生してしまうことがあるため、防ぎようがありません。

検出、リカバリ方法

そのため、これらの例外・エラーに対しては予めどのように気付き、対処するかという運用を決めておく必要があります。

例外・エラーの検出方法
これらの例外・エラーはSystem logとしては出力されますが、Sourceフィールドでフィルタしようにも例外・エラーの発生個所によってSourceが"Flow Designer"だったり"com.glide.ui.ServletErrorListener"だったりして安定しません。しかし、Flow engine context[sys_flow_context]テーブルにおいて、Stateフィールドが"Error"になった場合にNotificationを飛ばすようにしておくと、安定して検出できます。そして、この方法だと設計、テスト漏れによりカバーしきれなかった原因の例外・エラーもまとめて検出することができます。

例外・エラーのリカバリ方法
とはいえ、一度止まってしまったフローコンテキストは再開することもできないので、処理を手動で再実行したり、Catalog Itemがトリガの場合は申請者に再度申請をあげてもらうといった対応が必要になります。

おわりに

最近外部連携を実装することがあり、異常系のテストも最低限ステータスコードが正しく返ってくるものしかやる予定がなかったのですが、たまたまテスト中に対向システムがメンテに入り、通信系例外が発生してくれたおかげでこのことに気づくことができました。皆さんもFlow designerで外部連携を組み込む際には、このような例外・エラーにどのように気付き、対応するのかを予め決めておくことをお勧めします。

以上です。