誰得記事ですが、自分がこまごまと困ったので書いた。
最初に結論を言うと公式ドキュメントが最強なので最初によくよく読もう。公式は正義。
Webhook - n8n Documentation
n8nとは
n8nは、IFTTT、Zapier と並べて名前があがることが多いワークフロー自動化ツールだ。
オープンソースなので自力でサーバを立てて動かすことができる。
公式ドキュメントが充実しているし、Dockerがあるので、動かすのにそんなに苦労はないだろう。
Docker Compose - n8n Documentation
有料で利用できる n8n.cloud もある。
n8n.cloud | Powerful workflow automation tool
※今回のn8n利用バージョンは 0.175.0
目標
お問い合わせのチケット管理システムZendeskの専用ノードがn8nには存在するが、最近バグを踏んだのか動かなくなった。
Zendesk Trigger node error DeprecatedTargetType - Questions - n8n
Problem activating workflow The following error occurred on workflow activation: Zendesk error response [403]: DeprecatedTargetType
↑こんなエラーが出た。はてさて困った。 公式コミュニティでも一時的な解決策としてWebhookの利用が提案されていたので、作り直すことにした。
n8n・Webhook URLs を確認
ワークフローの発火点としてWebhookを使う。 Webhookのノードを選択して編集画面を見ると、Webhook URLsが表示される。 この「Test URL」をコピーしておく。最初の動作確認時は「Test URL」を使っていく必要がある。
- Authentication: Header Auth
- HTTP Method: POST
- Path: (自動で入っているものそのまま、編集しても良いと思う)
- Respond: Immediately
- Response Code: 200
上部の Credential for Header Auth
の欄から Header Auth の設定を新規作成できる。ここでZendesk側との設定と合わせていく必要がある。
Zendesk・Bearer token設定
管理センター > アプリおよびインテグレーション > Webhook より、Webhookの作成ができる。
「ベアラートークン」(Bearer認証のトークン)は token68 形式にする必要があり、token68 は base64 をカバーしているとのことで、base64で生成しても良いと判断した。Rubyでこんな感じに作った。
# ※サンプルダミーです require 'securerandom' SecureRandom.base64(30) # nは適当 => "TSrSP3yNzSVT71ZmX4ba8n6VRA9s0onoKxS2kB5i" # この TSrSP... を、Zendeskの「トークン」の欄に入力する
参考 - Authorization Bearer ヘッダを用いた認証 API の実装 - げっとシステムログ - Bearer認証について - Qiita
n8n・Header Authを設定
Bearerトークンを決めたので、n8nのHeaderAuthの設定を進める。
編集画面で次のようにして保存する。 TSrS...
のところは先ほどのサンプルダミー。
- Name: Authorization
- Value: Bearer TSrSP3yNzSVT71ZmX4ba8n6VRA9s0onoKxS2kB5i
動作確認する
まず、n8n側のWebhookについて、「Execute Workflow」を押し、イベントを待ち受ける。
その間に、Zendesk側の「Webhookをテスト」 > 「送信テスト」を押す。
すると、n8n側で情報を受け取ったことが確認できる。
ポイントとしては、n8n側のURLとして「Test URL」「Production URL」の2つがあるが、次のことに気をつけたい。
- Test URL → 上記のように手動で Execute Workflow を押した時のみ動作する。
- Production URL → 対象ワークフローをActiveに切り替えたときに動作する。
最初、あまりよく分からずやっていたら、実際の動作確認のときにURLを取り違えていて詰まってしまった時があった。
APIを使いたい
Zendeskは1問い合わせに対して、コメントを積み重ねていく形でやりとりが記録されていく。 Webhookで得られるJSONの中には、一番古いコメントのデータしか載せられていないので、APIでコメントデータを取りに行くことにした。
前のノードからの情報を活用する
まず、上記手順で 「Supportチケットのサンプル」の送信テストをしている状態 で、HTTP Requestノードを選択し、設定する。
- Authentication: OAuth2
- Request Method: GET
- URL: ※編集する
- Response Format: JSON
URLの部分は、歯車マーク > Add Expression を押す。
URLの形は
https://〇〇〇.zendesk.com/api/v2/tickets/{ticket_id}/comments.json
としたい。〇〇〇の部分は組織のサブドメインがはいる。
(参考: https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_comments/#list-comments)
ここで、 {ticket_id} というのはZendeskからWebhookで届いた情報の内容を使いたい。左カラムから、送信テストとして届いたデータの内容を取ってきて埋め込むことができる。
Result側にはちゃんとticket_idが数値として入っている様子がわかる。
OAuth2の設定
n8n側で Credential for OAuth2 API
の枠があるので、そこで Create New する。
表示されたフォームを、下記ドキュメントに従い、次のように埋める。 アプリケーションでのOAuth認証の使用 – Zendeskヘルプ
- Authorization URL: https://〇〇〇.zendesk.com/oauth/authorizations/new
- Access Token URL: https://〇〇〇.zendesk.com/oauth/tokens
- Client ID: (任意の英文字列)
- Client Secret: (今から埋める)
- Scope: read
- Auth URI Query Parameters: (未入力のまま)
- Authentication: Header
OAuth Redirect URLを控えておく。クリックするとクリップボードにコピーしてくれる。
次に、Zendesk側での設定を進める。
管理センター > アプリおよびインテグレーション > Zendesk API > OAuthクライアント > OAuthクライアントを追加
重要な部分は次の2ヶ所。
- 一意のID: (n8n側のClient IDと同じ表記を記入する)
- リダイレクトURL: (n8nからコピーしてきた OAuth Redirect URL を貼る)
保存するとシークレットキーが表示されるので、それをn8n側の「Client Secret」に貼り、Connect my account を押す。 ポップアップで許可ウインドウが出るので「許可」すると、Account connected となる。
準備ができた状態で、「Excecute Workflow」で待ち受けている状態でテストで送信してみると、正常にデータが取れるはず。
あとは利用したいデータを、公式API Referenceを参考しつつ取ってくればOK。 API Reference Home | Zendesk Developer Docs
(Zendesk)トリガと紐づける
諸々のWebhookやらOAuth2の設定が終わっても、本格的に使うには「実際に問い合わせが届いた時のデータの処理」の確認が最初は必要だと思う。Test URLを使わせたまま、Zendeskの管理センター > オブジェクトとルール > トリガ で、アクションとしてWebhookを選択し、作ったWebhookに当てて任意の形式のJSONを送るように指定した状態で、n8n側「Execute Workflow」で実行結果を待ち受けつつ、色々やってみる必要はあると思う。ここからはやりたいことによって様々な活用方があると思うので、割愛。
実際に運用する設定に切り替え
全てがおわったら、次の2点を忘れずにやっておく。
- Zendesk側のWebhookの設定 > エンドポイントURL の欄は、n8nの「Test URL」から「Production URL」に差し替える。
- n8n側で、作成したWorkflowを「Active」にしておく。
そうしないと、待てど暮せど動かなかったりするので注意。