---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# ECC queue for Discovery

# The ECC queue for Discovery {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of The ECC queue for Discovery

The External Communication Channel (ECC) Queue is a critical integration point within ServiceNow that connects your instance to external systems, primarily through a MID Server.
It holds records representing messages exchanged during all stages of the Discovery process---either as output from the instance to target systems or input from those systems back to the instance.
These records provide a detailed flow of probe and sensor activities along with the XML payloads involved in discovery tasks.
Show full answer Show less  

## Key Features

* **Content of ECC Queue:** Tracks messages and data exchanged during Discovery, enabling insight into the probe and sensor operations and their results.
* **Automatic Record Deletion:** ECC queue records older than 7 days are deleted by default to manage storage size, but this schedule can be customized. Retaining records for at least a month is recommended for troubleshooting purposes.
* **Access Points:** The ECC queue can be accessed via the Discovery module or directly through the ECC module in ServiceNow, facilitating monitoring and investigation.
* **Record States:** Records cycle through states such as ready, processing, processed, and error, reflecting their progress and allowing for error identification and troubleshooting.
* **Debugging Support:** Debugging ECC queue processing is possible by using the script debugger on the same session and reviewing business rules and scripts that handle the payload.
* **Configurable Properties:** Properties like "Save ECC queue attachments" can be enabled to retain attachments for debugging, overriding the default behavior of deleting attachments after successful sensor processing.

## Key Outcomes

* Provides a transparent and detailed communication log for Discovery activities, essential for troubleshooting and validating discovery accuracy.
* Enables efficient management of ECC queue data volume through automated cleanup schedules, while allowing customization to meet operational needs.
* Supports proactive monitoring of Discovery progress and immediate identification of issues via ECC queue record states and error tracking.
* Facilitates advanced debugging and analysis of discovery processes by preserving detailed data and allowing inspection of processing logic.  
The External Communication Channel (ECC) Queue is a connection point between your ServiceNow instance and other systems that integrate with it, most commonly a MID Server.{#r_DiscoveryStatusECCQueue__ph_ecc-queue-intro}

## Contents of the ECC Queue {#r_DiscoveryStatusECCQueue__section_cjh_4cr_ccb}

The ECC queue contains records that are created during all
stages of discovery. Each record is a message from the instance to system your are
targeting for discovery, classified as output, or a message from
that system to the instance, classified as input. {#r_DiscoveryStatusECCQueue__p_ecc-queue-content}

ECC queue records provide you with a connected flow of probe and sensor activity along
with the XML payload sent to or from an instance and the assets you are targeting.

## Automatic deletion of ECC queue records {#r_DiscoveryStatusECCQueue__section_z4h_4cr_ccb}

As your IT Asset Discovery runs, the size of the ECC queue can grow
to several gigabytes. Most of the "completed tasks" records are unnecessary, but some
might be important for troubleshooting any problems.

For example, if Discovery is not properly capturing the disk drives
on a particular Windows server, you can look in the ECC Queue at the data returned by
the Windows - System Information probe. For this reason, you should retain ECC Queue
data from Discovery for at least a month.  
By default, records in the ECC Queue older than 7 days are deleted automatically. You can set the deletion schedule by updating the ECC queue (as we will explain in the next section) and the table rotation schedule. The table rotation names are:

* ecc_queue_event
* ecc_queue
{#r_DiscoveryStatusECCQueue__ul_jx3_5cr_ccb}

## Accessing the ECC queue {#r_DiscoveryStatusECCQueue__section_djh_4cr_ccb}

You can access the ECC queue from either of these locations:

* DiscoveryOutput and ArtifactsECC Queue
* ECCQueue
{#r_DiscoveryStatusECCQueue__ul_nj3_gfp_qbb}

The following image is an example of a record in the ECC queue. This record shows that a
WMI classifier probe was instructed to run and has been processed. Note the XML payload
it returned as the discovery task collected data. See [The MID Server ECC queue](https://www.servicenow.com/docs/access?context=ecc-queue-mid-server&version=yokohama&pubname=yokohama-servicenow-platform&ft:locale=en-US) for a
description of each field.  
Figure 1. An example ECC queue record

## ECC queue states

Input and output messages keep processing until the discovery is finished or terminated.
You can monitor the ECC queue to see records populate during discovery and see the
states of each record change.

ECC queue input records are processed by business rules (BR), but not all business rules
direct these ECC queue inputs to process. As a result, some ECC queue inputs remain in a
ready state.  
The process is as follows:

1. When new probe instructions are available for the MID Server, the system creates an output record with the state of ready.
2. The MID Server then starts processing the probe instructions and the state changes to processing before it finally changes to processed.
3. When a result returns to the MID Server and is ready to be sent to the instance, the system creates an input record with the state of ready.
4. While the system processes the payload, the state changes to processing before it finally changes to processed.

   If any errors are encountered, the state
   changes to error. You can review errors as a starting
   point for troubleshooting a failed discovery.
{#r_DiscoveryStatusECCQueue__ol_gww_ls4_lz}

## Debug processing of ECC queue records {#r_DiscoveryStatusECCQueue__section_exh_c3r_pvb}

To use a script debugger, process the payload on the same session as the debugger.
Review the business rule which processes the particular ECC queue record and the actual
code which processes the payload.

## Properties and parameters that affect the ECC queue

These properties are available to control aspects of the ECC queue:{#r_DiscoveryStatusECCQueue__table_khy_354_lz__entry__2}

| Property | Description |
|-|-|
| Save ECC queue attachments | The normal behavior for discovery sensors is to delete attachments to ECC queue entries upon successful sensor processing. Enabling this property overrides this behavior, and forces attachments to be preserved. This is typically done for debugging purposes. To enable this property, navigate to Discovery DefinitionProperties. |
[ ]

{#r_DiscoveryStatusECCQueue__table_khy_354_lz}
**Related topics**   

* [Manage ECC Queue content for a MID Server](https://www.servicenow.com/docs/access?context=ecc-queue-mid-server&version=yokohama&pubname=yokohama-servicenow-platform&section=manage-ecc-queue-content&ft:locale=en-US)

*[\>]: and then