Alerthubのメール受信機能／Pigeon架電要求機能について

フォローする
HM

お世話になっております。

現在弊社では、架電の自動化だけでなく、
アラート発生から自動架電までの経緯の自動化を模索しております。

そのため、AlertHubのメール受信時の待ち行列の仕様と
おなじくPieonの架電時の待ち行列の仕様についてお尋ねします。

〔1．AlertHub〕
AlertHub が複数のメールを一度に受けとった時、
（受信スロットは全アラート共通。そのスロットの単一メアドしか使わないシングル処理構想）
メール処理の待ち行列のMAX値と、なんらかの処理の特徴などあればご教示ください。
また受信スロットには primary/secondary のメアドがセットされますが、これはメール処理の待ち行列仕様に関係がありますでしょうか？

〔２．Pigeon〕
Pigeon については今までの経緯から以下のように理解しております。
A. 契約上架電回線は１
B. 架電リクエスト後の確認タイミングは  10秒ごと
C. 複数の架電要求が同時に行われた場合、コールフローAの架電が終了するまで、コール　フローBの架電リクエストは、最大10分間のガイダンスタイムアウトが適用されるまでは、保持される。
D. Cは例えば、架電リクエストがA~Jまで10個同時発生した際、それぞれのリクエスト要求発生時間から換算して10分後にリクエスト終了＝架電失敗となり、連絡失敗通知を設定していれば通知対象となりオペレータに架電失敗を通知する
E. 架電リクエスト上限は架電中の1件を含め30件。その際の仕様は以下↓
　①HTTPステータスはリクエスト成功時と同様に「201」
　②status の値が rejected となる
　③架電リクエスト上限に達したことでリクエストが拒否された旨のメッセージが含まれる
　②③の情報は、HTTPステータスが「201」なので、Pigeon から通知は出さない。
　代わりに、AlertHubのアクション実行異常として「異常連絡」（以下スクショ）が設定されていれば、こちらからオペレータが分かるように通知される


上記、何か認識違いや不足などありませんでしょうか？

以上、ご回答のほどよろしくお願いいたします。






 

 

0

コメント

24件のコメント

日付 投票
  • Kompiraサポートチーム

    ご質問ありがとうございます。

    〔1．AlertHub〕
    AlertHub が複数のメールを一度に受けとった時、
    （受信スロットは全アラート共通。そのスロットの単一メアドしか使わないシングル処理構想）
    メール処理の待ち行列のMAX値と、なんらかの処理の特徴などあればご教示ください。

    受信したメールや Webhook は全件処理いたします。

    また、受信したメッセージの処理はその後のルール実行、イベント発行と非同期に行います。
    そのため、基本的にはアラートの受信順で処理されますが、受信間隔が短い場合は前後する可能性がございます。

    また受信スロットには primary/secondary のメアドがセットされますが、これはメール処理の待ち行列仕様に関係がありますでしょうか？

    受信スロットの primary/secondary は処理系に影響はございません。
    ただし secondary は、 primary アドレスが漏洩したなどで再発行するときに一時的に利用するために用意しておりますので、平常時は primary のみをご利用いただくのが良いかと思います。

    〔２．Pigeon〕
    Pigeon については今までの経緯から以下のように理解しております。
    A. 契約上架電回線は１
    B. 架電リクエスト後の確認タイミングは  10秒ごと
    C. 複数の架電要求が同時に行われた場合、コールフローAの架電が終了するまで、コール　フローBの架電リクエストは、最大10分間のガイダンスタイムアウトが適用されるまでは、保持される。
    D. Cは例えば、架電リクエストがA~Jまで10個同時発生した際、それぞれのリクエスト要求発生時間から換算して10分後にリクエスト終了＝架電失敗となり、連絡失敗通知を設定していれば通知対象となりオペレータに架電失敗を通知する
    E. 架電リクエスト上限は架電中の1件を含め30件。その際の仕様は以下↓
    　①HTTPステータスはリクエスト成功時と同様に「201」
    　②status の値が rejected となる
    　③架電リクエスト上限に達したことでリクエストが拒否された旨のメッセージが含まれる
    　②③の情報は、HTTPステータスが「201」なので、Pigeon から通知は出さない。
    　代わりに、AlertHubのアクション実行異常として「異常連絡」（以下スクショ）が設定されていれば、こちらからオペレータが分かるように通知される

    A~E について、ご記入の通りとなります。

    0
    コメントアクション Permalink
  • HM

    お世話になっております。
    前述〔２．Pigeon〕-E 〔架電リクエスト〕について追加で質問させてください。

    Pigeonの架電リクエストは、どこからの何をもってリクエスト完了と判断され、次のリクエストを受け付けるのでしょうか？
    以前、御社の架電サービスの時に Pigeon が架電要求を実行した後の流れを記載した資料を添付いたします。
    架電サービスからの何らかの応答を待って、架電リクエスト完了としているのなら、それが資料のどの部分かご教示ください。
    またもし架電サービスからの応答は待たず、Pigeonから/api/apps/pigeon/chain/invoke を投げてそれで終了なら、どうやって上限30を見極めているのか教えてください。



    0
    コメントアクション Permalink
  • HM

    お世話になっております。
    前述〔２．Pigeon〕-E 〔架電リクエスト〕について追加質問の関連になります。
    AlertHubのアクション異常連絡（以下スクショ）についてご教示ください。

    この機能はPigeon架電リクエスト上限30 を超えた場合にも異常を通知してくれるものと思います。
    アクションは webhook/ Pigeon /mail と3アクションで選択できたかと思いますが、
    AlertHubのアクション実行異常には、webhook/ Pigeon /mail のそれぞれで検知条件など違いがあるのでしょうか？
    具体的に聞くと、mail は架電（IVR）は使わないので固有の異常検知条件があり、
    webhook/ Pigeon は /api/apps/pigeon/chain/invoke の異常検知条件を共有しているということになるのでしょうか？

    0
    コメントアクション Permalink
  • HM

    お世話になっております。
    幾つもの質問になり申し訳ありません。
    自動化に伴い、Pigeonの再架電の可能性についてお尋ねします。

    Pigeon架電リクエスト上限30を超えて、架電リクエストが破棄されてしまった場合などに、
    再度Alerthub にアラートを送って架電をやりなおす以外に、
    Alerthub の機能の中に、Pigeonに引き渡したデータをどこかに格納できて、そこから再架電できるような仕組み・工夫はありますか？
    pigeon のコマンドジェネレータ以外でお願いいたします。

    0
    コメントアクション Permalink
  • HM

    お世話になっております。
    5日前（8/26）に、上記3件の質問を出させていただいております。
    それほど急いでいる訳ではありません。
    ただいつもよりお時間がかかっているようなので、受付されているかどうかだけ教えていただけるでしょうか？

    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    お待たせして大変申し訳ございません。
    回答について今しばらくお待ちいただければと思います。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    お世話になっております。
    それぞれの質問について回答いたします。

    Pigeon のリクエスト完了判定について

    Pigeon から架電システムに対してリクエストしたあと、結果を10秒間隔で取得（ポーリング）します。
    資料上ですと、架電システムが DB へ実行履歴更新をした後、 Pigeon がポーリングすることでリクエスト完了となります。

    またもし架電サービスからの応答は待たず、Pigeonから/api/apps/pigeon/chain/invoke を投げてそれで終了なら、どうやって上限30を見極めているのか教えてください。

    同時架電の上限判定は、 Pigeon がリクエストを受けた時点で架電中ステータスの個数から判定しております。

    AlertHub アクションの異常連絡について

    アクションの異常連絡は、アクションのステータスが 失敗 となったときに行います。
    それぞれアクションが失敗となるケースは以下のようになります。

    Pigeon

    同時実行数を超過、または存在しないリソース (コールフローやガイダンス) を指定した場合はタスク自体が reject となり、アクションも失敗となります。

    Webhook

    レスポンスのステータスコードが 200 番台以外のときに失敗となります。
    ただし、永続的な失敗 (具体的には 400, 401, 403, 404, 407 のステータスコード) 以外の場合は3回までリトライ処理が行われます。

    また、 Webhook アクションから Pigeon を実行する場合、先で説明したタスクが reject となるケースであっても、 Webhook アクション自体は成功扱いとなるためご注意ください。

    Mail

    SendGrid または、 AlertHub 画面の 設定 > Email アクション送信元 で設定したサーバが落ちていない限り、正常に終了します。

    AlertHub から再架電する方法について

    Pigeon アクションの実行内容は、 AlertHub のアクション実行結果または Pigeon の連絡履歴に格納されますが、再架電する機構はございません。

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • HM

    お世話になっております。
    ご回答いただきありがとうございました。

    いただいた回答に対してもう少し質問させていただきたいので、よろしくお願いいたします。

    • Pigeon のリクエスト完了判定について

      〔貴社回答_1〕

      Pigeon から架電システムに対してリクエストしたあと、結果を10秒間隔で取得（ポーリング）します。
      資料上ですと、架電システムが DB へ実行履歴更新をした後、 Pigeon がポーリングすることでリクエスト完了となります

      〔0905_質問1〕
      上記の回答について以下の認識であっていますか？
      ①Pigeon のリクエストを架電システムが受けてDBへ実行履歴更新
      ②Pigeon のポーリングに対し架電システムがリクエスト受け付けたことを返答したら、ポーリング終了。回線塞がりなどでwaiting になった場合は10秒t間隔でポーリング継続。
      ポーリング継続限界が10分間。
      ③ポーリング継続限界の10分間を超えた時、Pigeonが架電リクエスト失敗を判断し、
      いつもの以下のメールをユーザーに送信
      ④この時のエラーメッセージは　"polling timeout" のみ？


      *****------------------------------------------------*****
      [ajs-kompira] 連絡に失敗しました 
      Kompira cloud <noreply@kompira.jp>

      以下の連絡に失敗しました。

      https://XXXXXXXXXXXXXXXXXX.jp/apps/pigeon/results/yyyyyyyyyyyyyyyyyyyyyyyyyy

      失敗理由: error message
      *****------------------------------------------------*****

       

       

      〔貴社回答_2〕

      同時架電の上限判定は、 Pigeon がリクエストを受けた時点で架電中ステータスの個数から判定しております。


      〔0905_質問2〕
      架電リクエスト上限30 の判定は架電システムでなく Pigeonが判定しているとのことですが、以下の認識で合っていますか？
      架電ステータス(status) が
      ・preparing が29
      ・calling または aborting が１　　の状態の時に要求された31番目になるリクエストに対して上限エラーが発生する




      AlertHub アクションの異常連絡について

      アクションの異常連絡は、アクションのステータスが 失敗 となったときに行います。
      それぞれアクションが失敗となるケースは以下のようになります。

      Pigeon
      〔貴社回答_3〕

      ◆同時実行数を超過、または存在しないリソース (コールフローやガイダンス) を指定した場合はタスク自体が reject となり、アクションも失敗となります。

      〔0905_質問3〕
      Pigeon の同時架電数はスタンダード契約で "1" ですが、それを超過した時にリクエスト待ち行列に入ると認識しています。
      Pigeon アクションが失敗となる同時実行数とは何をさしていますか？
      同時架電数ではないですよね。


      〔貴社回答_4〕
      ◆また、 Webhook アクションから Pigeon を実行する場合、先で説明したタスクが reject となるケースであっても、 Webhook アクション自体は成功扱いとなるためご注意ください。

      〔0905_質問4〕
      「先で説明したタスクが reject となるケース」について、どの事を仰ってるのかわかりませんでした。以下↓の部分でしょうか？
      「同時実行数を超過、または存在しないリソース (コールフローやガイダンス) を指定した場合はタスク自体が reject となり、アクションも失敗となります。」


      ・webhook からpigeonを実行するケースとは（/api/apps/pigeon/chain/invok）のことでしょうか？
      　・invoke の要求がreject された場合、とくにパラメータの記載ミスなど、webhookアクションエラーになったと記憶してました。

      　・また、webhook は成功となり、 Pigeonアクションが異常になった場合、Pigeon からの失敗通知はいつものスタイル（質問1に記載のメールパターン）で通知されると認識しています。合ってますでしょうか？


      以上、4点、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    こちら確認いたしますので、回答まで今しばらくお待ちいただければと思います。

    0
    コメントアクション Permalink
  • HM

    お世話になっております。
    9/5に追加で出させていただいた質問の回答予定を教えていただけますか？

    予定だけで構いません。
    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    お待たせして大変申し訳ありません。
    それぞれ回答いたします。

    〔0905_質問1〕
    上記の回答について以下の認識であっていますか？
    ①Pigeon のリクエストを架電システムが受けてDBへ実行履歴更新
    ②Pigeon のポーリングに対し架電システムがリクエスト受け付けたことを返答したら、ポーリング終了。回線塞がりなどでwaiting になった場合は10秒間隔でポーリング継続。
    ポーリング継続限界が10分間。
    ③ポーリング継続限界の10分間を超えた時、Pigeonが架電リクエスト失敗を判断し、
    いつもの以下のメールをユーザーに送信
    ④この時のエラーメッセージは　"polling timeout" のみ？

    はい、そのご認識であっています。

    〔0905_質問2〕
    架電リクエスト上限30 の判定は架電システムでなく Pigeonが判定しているとのことですが、以下の認識で合っていますか？
    架電ステータス(status) が

    - preparing が29
    - calling または aborting が１　の状態の時に要求された31番目になるリクエストに対して上限エラーが発生する

    そのご認識で概ねあっています。
    より厳密には、架電のステータスではなく、連絡履歴のステータスで「preparing」「waiting」「processing」「aborting」の総数が30個ある状態で、要求された31番目になるリクエストで上限エラーが発生いたします。
    先日の回答で「架電中ステータス」と書いてましたが、 Web 画面に合わせて書くと「連絡履歴ステータス」が正確になります。紛らわしい書き方をしてしまい申し訳ございません。

    連絡履歴の各ステータスの説明はこちらの回答をご参照ください。

    〔0905_質問3〕

    Pigeon アクションが失敗となる同時実行数とは何をさしていますか？
    同時架電数ではないですよね。

    失礼いたしました。
    ここでの同時実行数は Kompira Pigeon 仕様情報における 架電リクエスト上限 に関する値となります。

    〔0905_質問4〕

    「先で説明したタスクが reject となるケース」について、どの事を仰ってるのかわかりませんでした。以下↓の部分でしょうか？
    「同時実行数を超過、または存在しないリソース (コールフローやガイダンス) を指定した場合はタスク自体が reject となり、アクションも失敗となります。」

    分かりづらく書いてしまい申し訳ありません。
    そのご認識であっています。

    - webhook からpigeon を実行するケースとは（/api/apps/pigeon/chain/invok）のことでしょうか？
      - invoke の要求がreject された場合、とくにパラメータの記載ミスなど、webhookアクションエラーになったと記憶してました。
      - また、webhook は成功となり、 Pigeonアクションが異常になった場合、Pigeon からの失敗通知はいつものスタイル（質問1に記載のメールパターン）で通知されると認識しています。合ってますでしょうか？

    API はそれであっています。

    先日の回答で紹介した Pigeon タスクが reject となるケースは、API リクエスト時点で失敗となる場合です。
    それ以外の架電処理中の失敗 (パラメータの記載ミス) ではアクションとしては成功扱いとなりますが、 Pigeon として失敗となるため通知されます。

    それぞれのパターンでの AlertHub アクションおよび Pigeon のステータスや通知の有無についてまとめた表が以下となります。

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • HM

    お疲れ様です。

    度々申し訳ありませんが、以下４点の質問をお願いいたします。


    【0930_①】
    私どもの、Pigeon>設定>連絡失敗通知　は、以下のプログラム（API）の結果に準じて通知していますか？
    POST /api  /apps  /pigeon  /chain  /invoke　連絡処理の実行


    【0930_②】

    webhookアクションで、存在しないリソース (コールフローやガイダンス) を指定した場合、
    異常を通知するのは　AlertHub>設定>通知先の異常連絡　の設定でしょうか？


    【0930_③】
    またwebhookアクションで、存在しないリソース (コールフローやガイダンス) を指定して
    アクションテストを実施した際、invoke API はコード400で異常終了しました。
    （異常情報：誤ったコールフローid が webhook で展開されるようにした） 

    以下の回答のケースと一致しないのは何が違うのでしょうか？
    >> 架電処理中の失敗 (パラメータの記載ミス) ではアクションとしては成功扱いとなりますが～


    【0930_④】
    架電リクエスト上限を超えた時、rejected のstatus を通知するのは、以下のプログラム（API）でしょうか？
    POST /api  /apps  /pigeon  /chain  /invoke　連絡処理の実行


    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    【0930_①】

    私どもの、Pigeon>設定>連絡失敗通知　は、以下のプログラム（API）の結果に準じて通知していますか？

    POST /api  /apps  /pigeon  /chain  /invoke　連絡処理の実行

    はい、その通りです。

     

    【0930_②】

    webhookアクションで、存在しないリソース (コールフローやガイダンス) を指定した場合、

    異常を通知するのは　AlertHub>設定>通知先の異常連絡　の設定でしょうか？

    「存在しないリソース」について齟齬があると思われるので、以下に整理して回答いたします。

    1. 削除済みのリソースを指定した場合、前回の回答の表における「リクエスト時に失敗する場合」となり、Webhook アクションでは AlertHub から異常通知されない (Pigeon アクションからは異常通知される)
    2. リソースの ID が UUID のフォーマットではない場合、REST API のレスポンスとして 400 となるため、AlertHub から異常通知される

     

    【0930_③】

    またwebhookアクションで、存在しないリソース (コールフローやガイダンス) を指定して

    アクションテストを実施した際、invoke API はコード400で異常終了しました。

    （異常情報：誤ったコールフローid が webhook で展開されるようにした）

    「アクションテスト」とは AlertHub の Webhook アクションからの実行かと思われますが、400 になったのはおそらく、【0930_②】 の回答の 2 に書いた、 UUID として不正な ID を指定したのが原因かと思われます。

    以下の回答のケースと一致しないのは何が違うのでしょうか？

    >> 架電処理中の失敗 (パラメータの記載ミス) ではアクションとしては成功扱いとなりますが～

    「パラメータ」についても齟齬があると思われるので、整理も含めて回答させていただきます。

    前回の回答で書いた「パラメータの記載ミス」はガイダンスのパラメータを想定して回答しております。
    (架電処理の実行 API のリクエストボディにおける params.parameters です)

     

    例えば、ガイダンスのテンプレートで {{ server_name }} を使用するのに、リクエスト時それがない場合、
    Pigeon の連絡履歴は生成されますが、エラー理由「ivr error: 必須なパラメータを指定しておりません。」で失敗となります。

    「架電処理中の失敗」と書いたのは、連絡履歴は生成されるが、ステータスが失敗となるケースを指していました。

     

    また、質問者様の想定する「パラメータ」は、架電処理の実行 API のリクエストボディにおける params 全体を指していると思われます。

    この場合、例えばコールフローが指定されていなかったり ID が UUID の形式ではないなど、リクエストの形式として不正なものは、架電処理の実行 API のリクエスト時にステータスコード 400 を即時に返します。

     

    【0930_④】
    架電リクエスト上限を超えた時、rejected のstatus を通知するのは、以下のプログラム（API）でしょうか？
    POST /api  /apps  /pigeon  /chain  /invoke　連絡処理の実行

    上記の API のレスポンスで "status": "rejected" として返却されます。

    AlertHub や Pigeon として通知されるかは前回の回答の表における「リクエスト時に失敗する場合」をご参照ください。

     

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • HM

    お世話になっております。
    ご回答ありがとうございました。

    回答内容をじっくり読ませていただいたのですが、
    以下の蛍光ペンを引いた箇所
    (AlerHub＆Pigeon アクションのどちらからも通知がされない）
    が、どうしても気になりました。


    こちらでもパターンを細かくしてみましたので、
    この認識であっているかご回答いただけますか？
    削除済リソースについては、テストはしていませんが、
    PigeonアクションはGUI設定なので、最新のリソースしか表示されないだろうと考えております。

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    添付いただいた画像の「削除済みリソース指定」の Webhook アクションから呼び出した場合 (D5, D6 セルですかね?) について、AlertHub のアクションステータスは「成功 (status code: 201」で通知は「されない」になります。

    また、同行の Pigeon の連絡履歴も生成されず通知されないはそのままになります。

    これはユースケースとしては、アクションの作成後にコールフローないしガイダンスの削除することを想定しているため、Pigeon アクションからも再現しうるケースとなります。

     

    先日の回答で注意事項として触れた「Webhook アクションから Pigeon を実行する場合〜」がまさにこのケースとなります。

    ので、基本的に AlertHub から Pigeon を実行するのは Pigeon アクションで行うことを推奨しています。

    (Pigeon アクションならこの場合の失敗でも通知されますので)

     

    また、この回答の表では、Pigeon アクションで同等の設定ができるもののみをまとめていたため、「リソースID がUUID-fmtと不一致」は「リクエスト時に失敗する場合」とは別の想定でした。(紛らわしくて申し訳ありません)

    Pigeon アクションで再現できないケース (不正な形式で架電リクエストする場合) も含めた表を改めて添付いたします。

     

     

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • HM

    お世話になっております。
    ご回答ありがとうございました。

    削除済リソースのパターンなど、承知いたしました。

    ただ、弊社では現在、発生したアラートを自動的にkompira に送り込もうとしているので、
    上記表の9行目が大変気になります。
    "リクエスト時（同時実行上限エラーなど）
    webhookアクションからの呼び出しは、AlertHub/ Pigeon ともに通知されない"

    現在の架電業務は、webhook アクションの架電が殆どであり、またその定義体（スコープ～アクション）が共通のものなので、アクションの異常検知は
    AlertHub ＞設定 >通知先 >異常連絡（弊社設定環境）　からの通知が頼みです。

    同時実行上限エラー（Pigeon架電リクエスト上限30超え）の場合、
    上記の設定からのアクション異常（以下スクショ）通知はされないということでしょうか？
    弊社ではされるものとして認識しておりましたが。

    もし通知されないのであれば、何か対処法をご教示いただけませんか。
    よろしくお願いいたします。



    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    ご迷惑をおかけして申し訳ありません。

     

    Webhook アクションの場合、同時実行上限エラーでは AlertHub, Pigeon いずれからも通知されません。

    こちらについて、Pigeon アクションに切り替える以外ですと、昨日リリースしたランブック機能にて通知が可能です。

    ランブックでは、アクションの実行結果を使って、後続アクションの実行を判断することができます。

    例えば、以下のような Pigeon での同時実行上限エラーが返ってきたとき (このときの HTTP ステータスコード は 201 です) に、status が "rejected" と一致する場合はメール通知するといった処理が可能となります。

    {
      "params": {
        "callflowId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
        "guidanceId": "YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY",
        "parameters": {}
      },
      "status": "rejected",
      "errorDescriptor": {
        "title": "Invalid request parameter(s)",
        "detail": "number of active tasks exceed the limit"
      }
    }

    ランブックの詳細は以下のマニュアルからご参照いただけます。

    https://fixpoint.github.io/runbook-manual/

     

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    尚、ランブック機能については現在ベータ版として提供させていただいております。

    現状は制限なくご利用いただけますが、今後変更がある場合は営業担当などからご連絡させていただきます。

    0
    コメントアクション Permalink
  • HM

    お世話になっております。

    ランブックでの改善見込み情報をありがとうございました。マニュアルを拝読いたしました。

    ただ、導入後分かった不具合のために有償機能の導入提案をするのは、少々ハードルが高いです。
    一年前の、Pigeonアクションから webhook アクションへ切り替えるご相談をした際の件もありますし。
    また、現在は時期としても難しい一面があります。

    以前のご回答に以下の記述が有りました。こちらの実行結果 のステータスが rejected になっているのを確かめる術はございませんか？
    どこかのDB に格納されているのではないかと思うのですが。

    また、完了コード201 は、https://ajs-kompira.cloud.kompira.jp/ 上でのみ返却されると思いますが、それで合っていますか？
    その構成の上で、ランブックの機能が追加されたのだとは思いますが、ランブック購入以外の方法はないでしょうか？

     
    ＞＞

    架電リクエスト上限を超えた時、rejected のstatus を通知するのは、以下のプログラム（API）でしょうか？
    POST /api  /apps  /pigeon  /chain  /invoke　連絡処理の実行

    上記の API のレスポンスで "status": "rejected" として返却されます


    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • HM

    お世話になっております。

    10/7の質問の回答をお待ちしている状況ではありますが、追加の質問をさせていただきます。

    〔10/12質問①〕
    以下のアクション異常時の通知ですが、いつからリンク先(黄色の蛍光線部分）が
    /api/apps/alerthub/action-records/{actionRecordId}アクション実行履歴の取得に変わったでしょうか？
    以前は、
    /api/apps/alerthub/scopes/scopeId/overview だったかと思います。

    できればご教示願います。




    〔10/12質問②〕
    作成していただいた表の最終掲載の9行目、12行目についてです。
    両者とも完了コード201なのは、/api/apps/pigeon/chain/invoke（連絡処理の実行）自体は正常に終了してしまうからだと思います。
    12行目は展開されたガイダンスId などが実際には存在せず、架電起動失敗。
    9行目は待ち行列が超過しており、架電スケジューリング失敗　なのだと思います。

    どちらも invoke から要求が正常に出され、それを感知・判断した存在がいるはずですが、
    9行目のケースは、その存在から "rejected" （拒否された）ということですよね。
    この事象が拾えないというのは、"rejected" が正常ステータスとして扱われているからだと思いますが、スケジュールが拒否される以外、どんな時が "rejected” になりますか？ 

    また、invoke のステータスは "rejected" だと返した存在は、以下の以前のご回答通り、invoke 自身であり、
    Pigeonやその他の制御プログラムで、この待ち行列超過という事象に関与している存在はいないということでよろしいですか？

    【0930_④】
    架電リクエスト上限を超えた時、rejected のstatus を通知するのは、以下のプログラム（API）でしょうか？
    POST /api  /apps  /pigeon  /chain  /invoke　連絡処理の実行

    上記の API のレスポンスで "status": "rejected" として返却されます。



    0
    コメントアクション Permalink
  • HM

    お世話になっております。

    〔10/7〕〔10/12〕分の返答待ちの状態でありますが、もう一つ質問いたします。

    〔10/14質問〕
    架電待ち行列超過の異常通知について（同時実行上限エラー）

    webhookアクションから架電リクエストを呼び出した場合、
    ・AlertHubアクションは通知しない
    ・Pigeonアクションは通知しない（rejected なので連絡履歴が生成されない）

    とのことですが、架電待ち行列超過（同時実行上限エラー）の場合、
    ・Pigeonの連絡履歴画面に何もでない
    ・アクション異常通知もこない

    ・他にも全くなんらかのお知らせも何にもない

    という認識であっていますか？

    現在、この件を報告などしておりますので、本日の質問に関しては早めにご返答いただけないでしょうか？

    2か月前、念のために、待ち行列の仕様に関して認識合わせをしております。この問い合わせの一番最初の質問です。
    その際、「A~E について、ご記入の通りとなります。」と確認もとれておりましたので、弊社では
    架電待ち行列超過（同時実行上限エラー）の場合でも問題なく運用できると考えておりました。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    多くの質問をいただきましたので、コメントを分けて回答させていただきます。

    https://kompira.zendesk.com/hc/ja/community/posts/9727551237273/comments/11231166991769 について、

    以前のご回答に以下の記述が有りました。こちらの実行結果 のステータスが rejected になっているのを確かめる術はございませんか？

    どこかのDB に格納されているのではないかと思うのですが。

    その構成の上で、ランブックの機能が追加されたのだとは思いますが、ランブック購入以外の方法はないでしょうか？

    現状、Pigeon アクションでの連携とするかランブックによる制御のみとなります。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム
    • 編集済み

    https://kompira.zendesk.com/hc/ja/community/posts/9727551237273/comments/11422199747609 について、

    〔10/12質問①〕

    以下のアクション異常時の通知ですが、いつからリンク先(黄色の蛍光線部分）がアクション実行履歴の取得に変わったでしょうか？

    こちらは 2021-11-11 のアップデートからとなります。

     

    〔10/12質問②〕

    作成していただいた表の最終掲載の9行目、12行目についてです。

    両者とも完了コード201なのは、/api/apps/pigeon/chain/invoke（連絡処理の実行）自体は正常に終了してしまうからだと思います。

    12行目は展開されたガイダンスId などが実際には存在せず、架電起動失敗。

    9行目は待ち行列が超過しており、架電スケジューリング失敗　なのだと思います。

     

    どちらも invoke から要求が正常に出され、それを感知・判断した存在がいるはずですが、

    9行目のケースは、その存在から "rejected" （拒否された）ということですよね。

    この事象が拾えないというのは、"rejected" が正常ステータスとして扱われているからだと思いますが、スケジュールが拒否される以外、どんな時が "rejected” になりますか？

    細かいですが、12行目はガイダンスは存在するが、{{ ... }} の形式で記載されたパラメータが実行時に渡っていない場合となります。

    また、9行目に書いた、HTTP ステータスは 201 になるが "rejected" になるケースは以下となります。

    • 同時実行上限エラー
    • callflowId が正しいフォーマットだが存在しない
    • 空のコールフローを指定する (空のコールフローは作成後に連絡先自体を削除することで発生します)
    • guidanceId が正しいフォーマットだが存在しない
    0
    コメントアクション Permalink
  • Kompiraサポートチーム
    • 編集済み

    https://kompira.zendesk.com/hc/ja/community/posts/9727551237273/comments/11483026086809 について

    〔10/14質問〕
    架電待ち行列超過の異常通知について（同時実行上限エラー）

    webhookアクションから架電リクエストを呼び出した場合、

    ・AlertHubアクションは通知しない

    ・Pigeonアクションは通知しない（rejected なので連絡履歴が生成されない）

    とのことですが、架電待ち行列超過（同時実行上限エラー）の場合、

    ・Pigeonの連絡履歴画面に何もでない

    ・アクション異常通知もこない

    ・他にも全くなんらかのお知らせも何にもない

    という認識であっていますか？

    はい、現状 Webhook アクションでは、"rejected" による失敗では通知や画面表示はされません。

     

    2か月前、念のために、待ち行列の仕様に関して認識合わせをしております。この問い合わせの一番最初の質問です。

    その際、「A~E について、ご記入の通りとなります。」と確認もとれておりましたので、弊社では

    架電待ち行列超過（同時実行上限エラー）の場合でも問題なく運用できると考えておりました。

    最初の質問への回答時は Pigeon アクション連携を勝手に想定していたため、そのような回答となりました。

    こちらの不手際で混乱させてしまい大変申し訳ございません。

    0
    コメントアクション Permalink

サインインしてコメントを残してください。

お探しのものを見つけられませんでしたか？

新規投稿