架電リクエスト上限を超えた状態の把握について
完了
お世話になっております。
弊社にて、Kompira自動架電運用の更なる自動化を進めております。
以前にも確認しておりますが、架電リクエスト上限（30）を超えてしまったリクエストの状態について、今一度ご教示ください。
前提条件：弊社はwebhookアクションを利用しています。
：ランブックの使用は現在ありません。
１．results APIで採取できる情報について
①架電リクエスト31件目以降の未完了時のステータスは何になりますか？
未完了時の isActive は "true" の認識です。
②架電リクエスト31件目以降の完了時のステータスは何になりますか？
完了時の isAvtive は"failed",status は"success" の認識です。
③pigeonリクエストがされる前に、reject されているとすると、results にはデータがない
２．invoke APIの情報について
①架電リクエスト31件目の未完了時のステータスは何になりますか？
②架電リクエスト31件目の完了時のステータスは何になりますか？
完了時の status は「成功 (status code: 201,rejected」
このinvoke 結果は 弊社（ユーザー）では results のように情報を扱うことはできない認識です。この結果を判定するのはpigeonで、架電リクエスト上限を超えたケースでは、Pigeon は"rejected"を受けても、その後エラーを生成しないと聞いています。
３．質問２の②に絡んだ質問です。架電リクエスト超過件数に対し、Pigeon はエラー生成をしないということは聞いています。
①Pigeon の連絡履歴画面には、データ表示されない認識で合っていますか？
②Pigeon が動作しないのであれば、calls APIを採取した時、その情報は何が記録されますか？
③results API と calls API のresultsId でマッチングした時、両者ともに架電リクエスト超過件数分は「存在なし」になりますか？
３．以前確認した情報の再確認です。webhookアクション からPigeon架電を行っている場合、
①架電リクエスト数を把握するのは、results APIの
・「preparing」「waiting」「processing」「aborting」の総数
・isActive が true の数
であり、results API を実行したタイミングで両者は「同数」であり、どちらを使用しても良いことで合っていますか？
４．現在、ランブックは無償提供かどうか決まりましたでしょうか？以前はまだ未定というお返事でした。
以上、よろしくお願いいたします。
①
-
お世話になっております。
以下の通り回答いたします。1.results APIで採取できる情報について
ご認識の通り、架電リクエストの上限は30件です。
31件以上のリクエストについては、webhook を送信しても reject されるため Pigeon 側でリクエストを受け付けない状態となります。
リクエストを受け付けなければ電話連絡自体が開始されませんので、results にもデータは残りません。
同様に、電話連絡が開始されないため、完了・未完了といった状態や各架電のステータス等も存在しません。2.invoke APIの情報について
こちらも1と同様に、電話連絡が開始されないため、完了・未完了といった状態や各架電のステータス等も存在しません。
Pigeon ではそもそもリクエストを受け付けていない状態ですので、エラーを生成することもありません。
ご質問内の「成功 (status code: 201,rejected」については、あくまでも webhook を送信したことに対してのステータスとなります。
「webhook の送信には成功したものの、受け取り手（Pigeon）から reject された」という意味を表しています。3(上)
①電話連絡自体が開始されていない状態ですので、履歴にも残らず表示はされません。
②電話連絡が開始されていないため、架電結果も残りません。
③電話連絡が開始されていないため、resultID 自体が存在しません。3(下)
架電リクエスト数の総数はご認識の通りに把握が可能です。
"status" が "preparing","waiting","processing","aborting" の総数と "isActive" が "true" のリクエストの数は同数になります。4
こちらについては引き続き確認しておりますので、恐れ入りますが今しばらくお待ちいただくようお願いいたします。 -
ご回答いただきありがとうございました。
弊社でKompira自動架電運用の更なる自動化を進める上で、
invoke,results のステータス認識が混同してしまっている状態になっておりました。
そのため、①②③とそれぞれが矛盾する質問を出させていただきました。
ご回答にお困りになられたかと思います。
申し訳ありませんでした。整理した回答をしていただき、感謝いたします。
１．結論を整理させていただきます。
”31件以上のinvokeによる架電リクエストについて：
■webhook を送信しても reject されるため Pigeon 側でリクエストを受け付けない
→電話連絡自体が開始されない→したがって、Results/Calls APIで採取する情報には、31件以上の架電情報は存在しない
→resultsIdも同様
→架電リクエスト31件目の invoke 完了時のステータス「成功 (status code: 201,rejected」は、invoke のCode説明（以下）の通りであり、送信の成功コードであって、架電スケジュールは保証されていない
２．弊社の自動化における、架電リスエスト上限を超えた場合の把握仕様※弊社では、現在kompira に処理させるアラートについて、一旦人が確認してからKompira に送り込んでいます。今後はその「人の確認」作業を排除し、自動でより多くのアラートを Kompira に送り込んでいこうとしており、そのため架電状態を監視する仕組みを作り込んでおります（専用監視画面にて実施）。
以下は、その監視仕様において、架電リクエスト上限に対する対策として考えているものになります。
■invoke API による架電スケジュールが拒否され、架電されない事実を利用する
→AleatHubで受け取るメールbody 文の中にアラートメール毎のユニークキーを仕込んでおき、パラメータ加工フローで採取することによって、元々のアラート情報とresults API採取情報とをそのユニークキーでマッチングする。
それによりresults のAPIの採取情報から status を把握し、自動化の監視に用いる。
→results APIの採取情報に存在しないユニークキーの場合は、ステータスフィールドは空白となり、何らかの異常としてオペレータが把握できるようにする。
上記のように考えております。
もし何かありましたら、参考にさせていただきますので、ご意見などいただけると助かります。
以上、よろしくお願いいたします。
サインインしてコメントを残してください。
コメント
6件のコメント