AlertHubからPigeonのキューに格納する際のふるまいについて
完了
お世話になっております。
標記の件について確認よろしくお願いします。
[前提（確認出来ていること）]
・Kompira Cloudへ架電用メール56通を一気に送信
・AlertHub→Pigeon間はWEBHOOK連携
・AlertHubのアクションレコード詳細のBODY部分を確認すると
a)送信された30通までは以下の結果となっている
status → requested（受付済の想定）
※Pigeon側のresultIdも確認出来る
b)送信された31通以降は以下の結果となっている
status → rejected（実行対象として受け付けられなかった？）
※JSON形式で以下の内容も確認出来る
"errorDescriptor": {
"title": "Invalid request parameter(s)",
"detail": "number of active tasks exceed the limit"
}
→上限オーバー？
【確認事項】
①Pigeonに格納できる架電要求数は30件が（キューの）MAXという認識です。
齟齬はないでしょうか？
②30件を超えるか否かはAlertHubでチェックして、上限を超える場合はエラーにしている
という認識です。
齟齬はないでしょうか？
③上限を超える場合にAlertHub内ではエラーにして、通知等は行なわないのは仕様でしょうか？
→Pigeonで架電エラー（応答なし等）時に架電失敗メールが送信されるように
30件（キュー格納数MAX）オーバーの際にも架電失敗メールを送付するように
することは可能なのでしょうか？
以上、よろしくお願い致します。
-
お問い合わせありがとうございます。
ご質問の件について以下回答させていただきます。① Pigeonに格納できる架電要求数は30件が（キューの）MAXという認識です。
齟齬はないでしょうか？ご認識の通りです。
Pigeon で同時に受け付けられる架電リクエスト（実行中および待機中の合計）の上限は 30件 です。
これを超える31件目のリクエストを行うとエラーとなり、受け付けられません。②30件を超えるか否かはAlertHubでチェックして、上限を超える場合はエラーにしているという認識です。
齟齬はないでしょうか？上限チェックはPigeonで行われます。AlertHub はアクションとして Pigeon へのリクエストを行いますが、Pigeon 側で上限（30件）に達していたため、記載していただいた内容（rejected）が返却され、その結果が AlertHub のアクションレコードに記録されています。
③上限を超える場合にAlertHub内ではエラーにして、通知等は行なわないのは仕様でしょうか？
→Pigeonで架電エラー（応答なし等）時に架電失敗メールが送信されるように
30件（キュー格納数MAX）オーバーの際にも架電失敗メールを送付するように
することは可能なのでしょうか？ご要望の「架電失敗メール（失敗通知）」については、AlertHub側のランブックで実現可能です。
PigeonをAPIでコールした時に上限オーバーだった時に返却されるステータスコードは201（成功）ですが、
レスポンス中にある「status」が「rejected」となるのはこのケースだけとなりますので、レスポンスのstatusの内容で判別いただけます。手順としては以下の通りです。
- ランブックでPigeon API をコールするWebhookアクションを呼ぶ。
- レスポンスを「フィールドをJSONとしてパースする」でパースしてstatusの内容をフィールドに格納する。
- 「フィールドを文字列比較する」で status == rejected であるか判定し、そうであれば上限オーバー時の処理（メール通知等）を実行する。
以上、よろしくお願いします。
-
お世話になっております。
ご認識の通りです。
ランブックの使用方法についてはこちらにマニュアルがございますので、
よろしければ参考にしてください。以上、よろしくお願いします。
-
お世話になっております。
回答ありがとうございます。
参考までに追加で確認よろしくお願いします。・rejectedになった場合ですが、架電要求自体受け付けられないので
Pigeon（results等）のデータは残らない想定で問題ないでしょうか？
→Pigeonの判定でrejectedになっているのであれば、Pigeon上に何か
残るのか？と思いの問いになります。・前述の通り、現在当方環境ではランブックは使用していないのですが
ランブック導入した際は
・設定自体は容易に出来るのでしょうか？
※出来れば現在の設定を生かして差分設定で実施したいです。
・ランブックを導入することに対する弊害はないでしょうか？
・導入に伴う費用増はない想定ですが、齟齬はないでしょうか？以上、よろしくお願い致します。
-
お世話になっております。
■設定の容易さについて
受信スロットからアクションを直接呼んでいるかと思いますが、代わりにランブックを呼ぶようにするとよいかと思います。
また、すでに作成済の通知アクション（メール、Pigeon、Webhook）を、そのままランブック内のアクションステップとして組み込むことができますので、
現在活用中の設定を活かしながら段階的に導入することが可能です。
ランブックマニュアルの設定例の中に、Webhookアクションを実行して、その結果をその後の処理に活用する場合の方法も紹介しておりますので、こちらも参考にしていただければと思います。■導入による弊害について
導入に際して留意いただく事項としましては、以下の２点があるかと思います。
・ランブックからPigeonの架電を実行する場合、ステップ設定で「アクションの実行完了を待つ」にチェックを入れても、電話連絡が終了するまで待機することはできません。
・ルールに比べて、より詳細で複雑なフローを組める反面、管理すべき設定箇所が増える点には注意が必要です。■費用について
ご認識の通り、費用面での追加負担もございません。以上、よろしくお願いします。
-
お世話になっております。
回答ありがとうございます。
・rejectedになった場合ですが、架電要求自体受け付けられないので
Pigeon（results等）のデータは残らない想定で問題ないでしょうか？
→Pigeonの判定でrejectedになっているのであれば、Pigeon上に何か
残るのか？と思いの問いになります。
…この点については如何でしょうか？
また、弊害についてですが、１点目は製品不具合という認識です。
※ステップ設定で「アクションの実行完了を待つ」を使わなければよい
齟齬がありましたら連絡よろしくお願いします。
ランブックについては導入を検討したいと思います。
まとめると以下のようになる認識です。
・ランブック不使用 → AlertHubからPigeonへのリクエストの際にキューあふれを検知する術がない
・ランブック使用 → AlertHubからPigeonへのリクエストの際にランブックに検知処理を組み込めば
キューあふれを検知出来るが、弊害もある
以上、よろしくお願い致します。 -
お世話になっております。
・rejectedになった場合ですが、架電要求自体受け付けられないので
Pigeon（results等）のデータは残らない想定で問題ないでしょうか？データとして残りません
また、弊害についてですが、１点目は製品不具合という認識です。
※ステップ設定で「アクションの実行完了を待つ」を使わなければよい
齟齬がありましたら連絡よろしくお願いします。Pigeon の架電リクエスト API は、「架電要求を受け付けたこと」をもってレスポンスを返す仕様となっており、実際の電話連絡が完了するまで待機してレスポンスを返すものではございません。 そのため、ランブックのアクションステップにて「アクションの実行完了を待つ（Webhookアクションの場合はAPIのレスポンスが返ってくるのを待つ、の意）」にチェックを入れていただいた場合でも、電話連絡の終了まで待機できない挙動は、仕様どおりの動作となります。恐れ入りますが、現時点ではランブックには Pigeon の連絡完了を待ってから後続ステップを実行するための設定や機能、または回避策となる事例はございません。ご期待に沿えず誠に申し訳ありませんが、何卒ご理解いただけますと幸いです。
サインインしてコメントを残してください。
コメント
8件のコメント