はじめに
これまであまりまじめに対応していなかったエラーハンドリングを、少し対応してみました。
エラーハンドリングとは書きましたがそれは一例で、Slackにも限らず、Sub Workflowの使い方のお話です。
説明
前提
JavaScriptで、テストとして、下記のようにオブジェクトでエラーを作ります。３件のレコードで、２件目がエラーだったという例。
return {
records: [
{isOk: true, value: 1, string: "aa",},
{
isOk: false,
error: {
type: "JavaScriptError",
message: "Error occured when Process B.",
stack: "x() > y() > z()",
node: "JavaScriptProcessXYZ",
occuredAt: new Date().toLocaleString(
"ja-JP", {timeZone: "Asia/Tokyo"}
),
}
},
{isOk: true, value: 3, string: "cc",},
]
};
これを Split Out ノードでバラして、１件ずつ処理するところまでが、テストでいうドライバーです。
１件ずつ、 If ノードで`判定して、Errorのときの話です。
Sub Workflowで行うエラー処理の概要
これは、Execute Sub-workflow ノードです。
Slackへ通知するだけなら、Sub Workflowは使わなくてよさそうですが、エラーが発生する箇所が複数あるとか、また今のWorkflowでない 別のWorkflowでも同じエラー処理をしたいことがあるので、Sub Workflowとして定義しておくとそういう時便利です。
これを使うときのポイントは２つ。
- Sub Workflowのポイント①：渡し方
- Sub Workflowのポイント②：受け方、使い方
1. Sub Workflowのポイント①：渡し方
エラーオブジェクトをそのまま渡してます。これは、errorという名前のオブジェクトは渡していなくて、errorの子たちのtype、message、、、を展開しているイメージ。
渡すときに使う変数は、jsonで固定です。変更不可。これがわかりづらいですが、受け方を見るとわかります。
2. Sub Workflowのポイント②：受け方、使い方
呼ばれるSub Workflowの処理はこう。さらに付け加えることも当然できます。
Sub Workflowのトリガーの部分は、設定が一応あります。プログラム的には、関数の引数の定義のようなものです。でも、Accept all dataも選べたりして、めちゃくちゃ自由。Define using JSON exampleを選んで、わざわざ書いてますが、これは参考にされているのだろうか。たぶんされていない。🤣
そして肝心のSlackでの使用方法。いちおう上から下までキャプチャしましたが、今いいたいのはMessage Textのところ。こういうふうに使いますよという話なので。
Message Textを広げるとこれ。
type: {{ $json.json.type }}
$json はおなじみの、前処理の結果のハコという意味。
つぎの json は、渡すときの固定の変数名。イケてない！変更できるならerrorとかにしたいところ。
最後の typeは、変数が展開されています。
これで取得できます。
おわりに
無事これで、エラー処理をいろんなところで使えます。Slackでは、エラー専用の通知チャンネルを用意してあるので、そこに出るはず。
あとSub Workflowを使わなきゃと思ってたけど、めんどくさくて放置してた。コピーすればいいかと思って。でもわかれば使えるし、何度も同じ処理があるときには便利なので、今後は使っていきます。
ではよきワークフローライフを！
追記
いつのまにか、下記のように変数が展開されていました。タイミングが全然わからないので再現性もわからず。。
こうなると、受け側も変数名がjsonでないので書き換えないといけない。
これでOK。
