こんにちは、SEタケです。
kintoneでできることを増やすには、プラグインとスクリプト以外に、Webhookを利用する方法もあります。
kintoneのWebhookで、PowerAutomateやAzureなど外部のサービスを呼び出せば、できることは格段に増えるのですが・・
ここで気を付けなければならないことが、いくつかあります。
Webhookを初めて利用する場合、意外とできないことがあって困ったり、気付かずに無駄な出費をすることになったり、ということがあるかもしれません。
場合によっては、実装のミスで多大な迷惑をかけてしまったり、何かのペナルティを受けてしまったりする可能性もあります。
私もWebhookからAzureを利用したのですが、意外なことができなくて困ったり、うっかりして数千円を無駄に支払うことになりましたので、その経験を共有したいと思います。
これからWebhookを利用しようとしている方や、利用を検討されている方は、ぜひ読んでください。
無限ループに注意！
これ、一番気を付けなければならない点です！絶対気を付けてください！
無限ループになっていると、気付かないうちにWebhookが何万回も実行されてしまいます。
例えば、自動でSNS投稿する機能を追加しようとして、同じ内容で何万件もSNS投稿されてしまう、ということが起きたら、どうですか。
考えただけでヒエッ！てなりませんか。
そんなに大きな影響のない処理だったとしても、kintoneからは注意を受けるし、場合によっては実行する外部サービスの利用料金もかさんでしまいます。
外部サービスにAzureのLogicAppsを利用している場合、実行時間に応じて支払う従量プランにすることも多いと思いますが、利用料がかさんでしまいますね。
これが、どういうときに起こるかというと・・
例えば、kintoneのレコード更新時に、実行したい処理があるとします。
そして、その処理の中で、kintoneのレコードを更新する必要があったとします。
先ほどの例では、レコード更新時にSNSに投稿して、投稿した日時を同じレコード内のフィールドに更新する、などの場合が考えられます。
普通にあり得るケースだと思いませんか。
ですが、何も考えずに実装すると、以下のようになります。
- kintoneのレコード更新
- Webhookでサービスが実行される
- サービス内でkintoneのレコード更新→２に戻る
たったこれだけのことで、大変な結果になる無限ループの出来上がりです。
こわいですね・・
無限ループの回避策としては、以下の対策が考えられます。
- そもそも、Webhook実行のきっかけとなるレコードと同じレコードは、更新しない仕組みにする
- Webhookで実行される処理の中で、何度も実行されないような条件を追加する（レコードの更新者が人の場合だけ実行する、処理の中で更新するフィールドが空のときだけ実行する、など）
また、実装中にうっかり無限ループになる状態でテストしてしまう、ということもあるかもしれません。
以下のことを心がけることで、事故は防げるのではと思います。
- 大事になりそうな処理は最後に追加する（先ほどのSNS投稿の例では、処理の中で投稿を実際に行う部分は最後に追加する、など）
- 異変を感じた時にすぐに止める方法を準備しておく
無限ループにならないかどうかは、常に気を付けておきましょう。
Webhookの実行が完了したかどうかはわからない
Webhookは、外部サービスに処理の実行を依頼するのですが、実行が終了するまで待ちません。
例えば、レコード更新時にWebhookを実行した場合、Webhookで実行依頼をした後、すぐに更新完了画面が表示されます。
Webhookで実行した処理が途中で失敗していても、何も通知されません。
Webhookの処理が正常に実行されたかどうかを知りたい場合は、そのための仕組みを作りこむ必要があります。
また、処理が終わったのか、いつ終わるのか、これもわからないんです。
プラグインでもありますよね、
例えば、レコード更新時にメール送信など何かの処理を行った結果、処理日時がレコードのフィールドに反映されるような仕組みになっているものがありますが、
レコード更新直後は処理日時が入っていなくて、しばらくしてから画面を更新すると入っている、そういうのを見たことがありませんか。
これは、レコード更新完了画面が表示された時点では、Webhookで依頼した処理が完了していないからです。
郵便局で書類を送ったあと、送りました！って電話する感じですかね。。
宛先不明で返ってきたら届かないし、いつ届くかも郵便次第です。
必ず実行されないと困る処理なのかどうか、実行する処理の性質にもよりますが、
Webhookを使うときは、実行に失敗したときに気付ける仕組みも、必要かもしれません。
Webhookでは更新前のレコード情報は取れない
レコード更新時のWebhookで、Webhook先の外部サービスに渡される情報には、レコード更新後の情報しか渡されません。
レコード更新前にどんな値が入っていたのかは、渡されないです。
どういうこと？と思いましたか。
これの何が問題かというと。。
例えば、レコード更新時に、あるフィールドが更新前から変更になったときだけ、処理をしたい。
そういうとき、Webhook先で、そのフィールドが更新前から変更になったかどうか分からないので、判定できないんです。
これを行うには、そのための小細工を組み込むしかありません。
１つは、下記のような方法があります。
- 更新前の値を入れるフィールドを用意する。このフィールドはスクリプトなどで表示されないようにしておく。
- スクリプトで、更新画面表示や一覧の行更新開始時に、１のフィールドに値をコピーする。
- Webhook先で、1のフィールドとコピー元のフィールドの値を比較する。
このあたりの方法は、下記の記事にも詳しく書いていますので、参考にしてください。
kintoneのWebhookの限界を超える、更新/削除前のレコード情報が取れない問題を解決 – 小さくはじめるＩＴ活用 (ict4small.com)
Webhookでは削除前のレコード情報は取れない
レコード削除時のWebhookで、Webhook先の外部サービスに渡される情報には、このレコードを削除したよ、という情報しか渡されません。
レコード更新前にどんな値が入っていたのかは、渡されないです。
これが問題になるケースとしては、
例えば、レコード削除時に、そのレコードが参照していたルックアップ先のレコードに対して、集計などの更新処理を行いたい、というような場合です。
そういうとき、Webhook先で、レコードが参照していたルックアップ先がわからないので、集計ができないんです。
これを行うには、そのための小細工を組み込むしかありません。
１つは、下記のような方法があります。
- 削除前の値を入れるフィールドを用意する。このフィールドはスクリプトなどで表示されないようにしておく。
- スクリプトで、削除直前に、１のフィールドに値をコピーしてAPIでレコードを更新
- レコード更新のWebhookが実行されるので、そこで1のフィールドを元に集計する
先ほどのレコード更新の時よりも少しややこしいですね。。
このあたりの方法は、下記の記事にも詳しく書いていますので、参考にしてください。
kintoneのWebhookの限界を超える、更新/削除前のレコード情報が取れない問題を解決 – 小さくはじめるＩＴ活用 (ict4small.com)
Webhookの実行回数制限と件数制限
kintoneのWebhookは、1ドメイン（＝1契約）毎に、１分間の実行回数が60回までとなっています。
ユーザー数やアプリの数に関係なく、実行回数が決まっているんです。
1秒間に1回と考えると、この制限に引っかかることはあまりなさそうに感じるかもしれませんが・・
例えば、いくつかのアプリに、更新時のWebhookが１つずつ設定されていたとします。
60人のスタッフが利用していたとして、それぞれのスタッフがたまたま同じ１分間に１回ずつ更新処理を行うと、60回になってしまいますね。
それぞれのスタッフがどのアプリを利用しているかは関係ありません。
そう考えると、結構ありえると思いませんか。
この上限に引っかかる場合は、一部をスクリプトで代用する、などの方法をとる必要があるかもしれません。
また、Webhookが設定できるのは、1アプリ毎に10件までになります。
まとめ
kintoneのWebhookは大変便利で、使いこなせればkintoneの活用の幅が大きく向上します。
特徴を把握して、便利に使っていきたいですね。
以上、最後までお読みいただき、ありがとうございました。
コメント