この機能を使用すると、ユーザは、最近作成された通信チャネルに既存の小切手を一括で取り込むことができます。新たに検出されたチェックまたはアップデートされたチェックは、有効な自動通知を介して通信チャネルに自動的に転送されるため、1回限りの処理であることが想定されます。
履歴チェック通知を再実行する理由
この機能を使用すると、自動通知の既存の動作が補完され、ユーザは履歴チェック (通信チャネルの作成前に検出されたチェック) を対象の通信チャネルで再実行できます。これは、通信チャネルが提供する自動解決機能を利用してチケットを解決する一方で、チケットチャネルの履歴チェックを追跡する必要があるユーザに役立ちます。
APIエンドポイント:
サポートされる通信チャネル
- Jira
- ServiceNow
- Zendesk
- AWSSNS
- Webhook
[重要:]
- チケットチャネル (Jira、ServiceNow、およびZendesk) で、チェックがすでにチケットチャネルに関連付けられている場合、履歴チェックを再実行してもチケットが重複することはありません。
- チケット以外のチャネル (AWS、SNS、およびWebhook) の場合、エンドポイントが呼び出されるたびにチェックが再送信されます。
- 現在、この機能はアカウントレベルの通信チャネルのみをサポートしています。
- 指定されたアカウント (通信設定が構成されている) への書き込みアクセス権を持つユーザのみが、このエンドポイントを使用できます。
- リクエストが成功してから通信チャネルにチェック通知が表示されるまでに数分かかることがあります。
- 対象の通信チャネルに送信された履歴チェックは、通信チャネルに設定されたトリガーに基づいて除外されます。
ユーザシナリオ
-
詳細については、通信チャネルでいくつかのトリガを設定することを強くお勧めします。ここ。
-
APIエンドポイントは2つのフィルタを受け取ります
newerThanDaysまたはolderThanDaysでは、通信チャネルの作成時間または更新時間に近い時間枠をお勧めします。どのようなチェックが必要になるかを把握するには、 クラウドポスチャ UIの [Browse All Checks] セクションでフィルタを設定します。 -
例: 自動通知チャネルが今日から30日前に作成された場合。のフィルタ
olderThanDays30は、その通信チャネルの作成前に履歴チェックを提供します。
例
AWSアカウントをオンボーディングしており、 クラウドポスチャ検索 が最初の検索を完了しており、Jira Ticketingシステムを設定していないとします。
[Browse All Checks]にアクセスすると、S3バケットリソースで2件のエラーが発生したことがわかります。ユーザは、これらのエラーチェック通知がJiraチケットシステムに配信されることを確認します。
すべての履歴チェック通知を受け取るには、新しいJiraチケット発行通信チャネルを作成し、自動通知を有効にして、次のトリガーを適用します。
- サービス: S3
- リスクレベル: [極]、[非常に高]、および[高]
- タグ: 「ステージング」と「デモ」
PostmanでAPIエンドポイントを使用する:
失敗したチェックが Jira に正常にインポートされたことを表示します。
これらのエラーに対処すると、Jira通信の自動通知によって、作成された2件のチケットが解決されます。
