「Kompira Pigeon を利用した通知電話の利用」記事について
お世話になっております。
表題の記事についてお尋ねします。
質問【20210729_2】
弊社では、架電の resultID が「aborted」「failed」だった場合に、Kompira Cloud を監視しているオペレータに架電障害があることを気づかせるため、そのアラートを自動で行いたいと考えております（MailでもOK)。
以前から表記の記事の利用をご紹介いただいていたのですが、
こちらの内容は、なんらかのインシデントが発生した時に、
Kompira Enterpriseの HTTPリクエストを送信するための組み込み関数 urlopen()
にて、
コールフローID,ガイダンスID,パラメータ,サーバー名,incident を手入力して架電している内容と認識しております。
今回の弊社の場合は、オペレータに気づかせるための mailなどのアクションの実行を自動化したいのですが、AlertHubでは難しいと以前ご回答いただいたと思います。
やはり Enterprise での定期的な 架電result ID へのポーリング検知による実行になる場合、「aborted」「failed」になった架電処理の情報はどの程度採取可能でしょうか？
（時刻・対象スコープ・アクション・コールフロー・ガイダンス内容など）
また、少しそれますが、ガイダンスに指定する{{}}の変数名は、各種トリガーやガイダンスで共通の変数名を用いる設計をしております。この変数の値の一時的な保存については、UNIQUEななんらかのIDに結びついていて、メッセージ保有期間30日の間、UNIQUEに保持されているということでよろしいでしょうか？
以上、ご教示のほど、よろしくお願い申し上げます。
-
ご質問ありがとうございます。
Enterprise での定期的な 架電result ID へのポーリング検知による実行になる場合、「aborted」「failed」になった架電処理の情報はどの程度採取可能でしょうか？
Pigeonの架電をEnterpriseから実行するか、AlertHub経由で実行するかで若干異なりますので、それぞれのケースについて回答します。
【EnterpriseからPigeonの架電実行する場合】
- ・/api/apps/pigeon/chain/invokeで電話かける（コラムにも記載）
- ・invokeの結果、result_idを取得
- ・result_idを指定して定期的に結果をポーリング（/api/apps/pigeon/results/{resultId}）
- ・↑の結果を見て、架電が終わったか（成功／失敗したか）定期的に確認
- ・api/apps/pigeon/results/{resultId}で返ってくる以下の情報取得が可能です。
各架電の時刻、コールフロー、ガイダンス内容、ボタン応答等
【AlertHubのアクションでPigeon実行する場合】
- ・/api/apps/alerthub/action-records/{actionRecordId}
- ・ステータスとして[ rejected, requested, started, aborted, failed, succeeded ]が取得可能です。
- ・上記のステータスを確認して、さらに通知で追加情報が必要であれば同じ箇所にあるresultIdをもとに架電結果情報を取得することが可能です。
また、少しそれますが、ガイダンスに指定する{{}}の変数名は、各種トリガーやガイダンスで共通の変数名を用いる設計をしております。この変数の値の一時的な保存については、UNIQUEななんらかのIDに結びついていて、メッセージ保有期間30日の間、UNIQUEに保持されているということでよろしいでしょうか？
こちらは、Pigeonの連絡履歴とAlertHubのメッセージは独立して保管しており、AlertHubメッセージはご理解の通り30日経過すると画面から参照できなくなりますが、Pigeonの連絡履歴は半年間参照可能です。
この際ガイダンスに渡されたパラメータ情報はPigeonの連絡履歴の一部として扱われますので、30日をすぎたとしても連絡履歴から変数の内容を確認することができます。
以上、よろしくお願いします。
サインインしてコメントを残してください。
コメント
1件のコメント