Zendeskのトリガで壁に当たった時のTips

Zendeskトリガは言うまでもなく使い勝手がよく、チケット作成とかを軽く通知したい程度だったら不自由なくできるのだが、がっつり他サービスでZendesk上のデータを扱い時に使おうとすると困った点があったのでまとめる。

前提：Zendeskで完結できないか考える

Zendeskにチケットがあるのだから当然Zendesk上で扱うのがベストである。身も蓋もないがトリガを作る必要がないのであればZendesk内で業務フローを完結させるのが実装コストも運用コストも良くなることが多い。

困りごとリスト

1. 条件分岐が難しい

「すべての条件を満たす」と「いずれかの条件を満たす」で条件を指定できるのである程度はカバーできるが、複雑な条件を指定したいときに躓くことがある。

2. 必要な情報がプレースホルダにない

主要な項目はプレースホルダとしてトリガ先に引き渡せるが、一部プレースホルダで追加できない項目もある。特にリスト要素、ネストされた要素などが弱い。

3. 実行結果、エラーをキャッチできない

Zendeskのトリガは条件とやることしか指定できないので、トリガによってあるREST APIをたたく、帰ってきた値をもとにその後の処理を決めるみたいなことはできない。また、エラーが発生した場合に後続の処理を中止する、エラーを通知するみたいなことができない。

4. 無限ループに陥る可能性がある

Zendesk管理画面のトリガの注意事項にも書かれているが、条件がチケット更新であり、なおかつやることとしてチケットを更新するような操作が入っているとトリガによる操作で再度トリガが起動し、その中の処理で再度トリガが起動し...と無限ループにハマる。

解決策

共通：トリガをやめてバッチ化する

上記のいずれかのような問題に陥っている場合、かなり複雑な操作をしようとしていることが推察される。処理にリアルタイム性を求めない場合、RundeckやEventBridgeなどの定期実行系でLambdaを起動し、Zendesk APIからCRUD操作することで解決ができる。二重操作を防ぐ場合はチケットのステータスで管理することが自然だが運用上の都合でチケットのステータスを変えたくない場合はカスタムフィールドでも対応できるだろう。副次効果としてLambda上にシステムを構築するのでソースコードとterraformをGit管理できるようになる。また、処理頻度が減ってクラウド上の処理コストが削減できることもある。

1の解決策：複数のトリガに分割する

やること側は全く同じで条件だけ変えた複数のトリガを作成することで対応できる。条件を分割する際に重複なく、抜け漏れがないように分割をしないと1つのチケットでトリガが複数回発火したり、発火しなくなったりするので注意が必要である。また、トリガのやることを変えることになった場合にすべてのトリガを修正する必要があり、オペミスを誘発する。

2の解決策：チケットIDだけを渡す

トリガ先がAPIである場合、チケットIDだけを渡して渡した先からZendesk APIを叩いて必要な情報を取得してくることができる。少しでもAPI経由で取ってくるべき情報があるなら、チケットID以外のすべての情報をAPI経由で取ってくるほうがZendeskから何が渡ってくるのかがシンプルになる(と個人的には思う)。

3の解決策：トリガ先で後続の処理する

トリガは1つのAPIしか叩かないようにしてトリガした先で処理した結果をもとにして後続の流れにつなげる。エラーもトリガ先で吐いてハンドリングするようにする。そもそもトリガの最初の処理のコールが失敗する場合なども考慮すると完璧とはいえないがおそらくレアケースだろう。

まとめ

大体の場合はバッチ化で解決できるし、シンプルで自由度の高い設計にして今後の問題をあらかじめ回避するという面でも優れている。ただ、小規模な仕組みを軽く直したい場合やイベントが起こったことを起点にしてリアルタイムに処理を行いたい場合などには別のワークアラウンドもある。