この機能により、ユーザは既存のチェックを新しく作成されたコミュニケーションチャネルに一括で取り込むことができます。これは一度限りの操作であり、新たに発見されたチェックや更新されたチェックは、有効化されたAutomatic
notificationsを通じて自動的にコミュニケーションチャネルに転送されます。
なぜ履歴チェックNotificationsを再実行するのですか?
この機能を使用すると、Automatic notificationsの既存の動作を補完し、ユーザが過去のチェック (通信チャネルの作成前に発見されたチェック) をターゲットの通信チャネルに再実行できるようになります。これは、ユーザがチケットチャネルで過去のチェックを追跡しながら、通信チャネルによって提供される自動解決機能を利用してチケットを解決したい場合に役立ちます。
APIエンドポイント:
サポートされている通信チャネル
- Jira
- ServiceNow
- Zendesk
- AWS SNS
- ウェブフック
[Important:]
- チケット発行チャネル (Jira、ServiceNow、Zendesk) では、チェックがすでにチケット発行チャネルに関連付けられている場合、履歴チェックを再実行しても重複したチケットは作成されません。
- チケット発行以外のチャネル (AWS、SNS、Webhook) については、エンドポイントが呼び出されるたびにチェックを再送信します。
- 組織レベルの通信チャネルを使用する場合、履歴チェックを再実行するために1つのアカウントIDを入力する必要があります。
- 指定されたアカウント (通信設定が構成されているアカウント) への書き込みアクセス権を持つユーザのみがこのエンドポイントを使用できます。
- リクエストが成功した後、チェックNotificationsがCommunication Channelに表示されるまでに数分かかる場合があります。
- 設定されたトリガーに基づいて、ターゲットの通信チャネルに送信された過去のチェックはフィルタリングされます。
ユーザシナリオ
-
強くお勧めします。通信チャネルにいくつかのトリガーを設定してください。詳細については、こちらをご覧ください。
-
APIエンドポイントは、
newerThanDaysまたはolderThanDaysの2つのフィルターを受け入れます。通信チャネルの作成または更新時間に近い時間枠をお勧めします。どのチェックを行いたいかのアイデアを得るには、Conformity UIの[Browse All Checks]セクションでフィルターを構成できます。 -
例: 自動通知通信チャネルが今日から30日前に作成された場合、
olderThanDays30のフィルターは、その通信チャネルの作成前の履歴チェックを提供します。
例
AWSアカウントをオンボードし、Conformity Botが最初のスキャンを完了し、Jiraチケッティングシステムが設定されていないと仮定します。
[Browse All Checks]にアクセスすると、S3バケットリソースが2つのFailureを作成したことがわかります。ユーザとして、これらのFailureチェックNotificationsがJiraチケッティングシステムに配信されることを望んでいます。
すべての履歴チェック通知を取得するには、新しいJiraチケットコミュニケーションチャネルを作成し、Automatic notificationsを有効にして、次のトリガーを適用します:
- サービス: S3
- リスクレベル: Extreme, Very high, 高
- タグ: "staging"および"demo"
PostmanでAPIエンドポイントを使用する:
失敗したチェックがJiraに正常にインポートされたことを確認しています。
これらの失敗に対処した後、Jiraの通信に関するAutomatic notificationsは作成された2つのチケットを解決します。
