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