此功能允許使用者批量導入現有檢查至最近建立的通訊頻道。預期這是一個一次性操作，因為新發現或更新的檢查將透過已啟動的自動通知自動轉發至通訊頻道。
為什麼重新執行歷史檢查通知？
使用此功能將補充現有的自動通知行為，允許用戶將其歷史檢查（在創建通信渠道之前發現的檢查）重新運行到其目標通信渠道。這對於希望在其工單渠道中跟蹤歷史檢查的用戶非常有用，同時利用通信渠道提供的自動解決功能來解決工單。
API 端點:
支援的通訊管道
- Jira
- ServiceNow
- Zendesk
- AWS SNS
- Webhook
重要：
- 對於票務渠道（Jira、ServiceNow 和 Zendesk），如果檢查已經與票務渠道關聯，重新執行歷史檢查將不會創建重複的票。
- 對於非票務渠道（AWS、SNS 和 Webhook），這將在每次呼叫端點時重新發送檢查。
- 該功能目前僅支援帳戶層級的通訊管道。
- 只有對指定帳戶（已配置通訊設定）具有寫入權限的使用者才能使用此端點。
- 在成功請求後，檢查通知可能需要幾分鐘才會出現在您的通訊頻道中。
- 根據通信渠道的配置觸發器，發送到您目標通信渠道的歷史檢查將被已過濾。
使用者情境
-
強烈建議在您的通訊渠道上配置一些觸發器，詳細資訊請造訪此處。
-
API 端點接受兩個篩選器
newerThanDays或olderThanDays，我們建議選擇一個更接近您通訊管道建立或更新時間的時間範圍。要了解您可能需要的檢查，您可以在 Cloud Risk Management UI 的 「Browse All Checks」 部分配置篩選器。 -
例如，如果我的自動通知通訊管道是從今天起30天前建立的，則
olderThanDays30的篩選器將提供該通訊管道建立之前的歷史檢查。
範例
假設您已經加入了一個AWS帳戶，並且合規掃瞄已完成首次掃瞄，而您尚未設置Jira工單系統。
造訪「Browse All Checks」，您可以看到您的S3儲存桶資源已創建2個失敗。作為使用者，您希望看到這些失敗檢查通知被傳送到您的Jira票務系統。
若要獲取所有歷史檢查通知，您將建立新的 Jira 工單溝通管道並啟用自動通知，並應用以下觸發條件：
- 服務：S3
- 風險等級：極高、非常高和高
- 標籤：「staging」和「demo」
使用 Postman 與 API 端點：
查看失敗的檢查已成功匯入至 Jira。
在解決這些故障後，Jira 通訊上的自動通知將解決所創建的兩個票據。
