ECC queue

The External Communication Channel (ECC) Queue displays input and output messages from and to MID Servers.

The ECC Queue is the normal connection point between an instance and other systems that integrate with it, most commonly a MID Server. Messages are classified as Input (from a MID Server to the instance) or Output (from the instance to a MID server).

View the ECC queue by navigating to one of the following:
  • Discovery > Output and Artifacts > ECC Queue.
  • Discovery > Discovery Schedules > {schedule name} > {Discovery status record} > .
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.
Figure 1. An example ECC queue record
An example ECC Queue

ECC Queue form fields

Field Input Value
Agent

The name of the external system that this messages is either from or to. If the message is from or to a MID Server, the agent name is in the form mid.server.xxx, where xxx is the name of a particular MID Server.

Topic

The contents of this field is arbitrary; it's intended as a way to inform the recipient of the message about what kind of message it is. In Discovery, it is name of the probe the MID server is to run (or ran, if this message is a response from a MID server).

Name

The contents of this field is arbitrary; it's intended as a way to inform the recipient of the message of more detail than the Topic field provides. In Discovery, it is either a descriptive name for human use, or the actual command the probe is to run (or ran). For example, if Topic is SSHCommand, then the Name field contains the actual shell command to run.

Source

The contents of this field is arbitrary; it's intended as a way to inform the recipient of the detailed recipient or target of this message. In Discovery, the Source field usually contains the IP address that the probe is to run against (or ran against). A few probes run against multiple IP addresses; in those cases, this field contains a human-readable description.

Response to

This optional field contains a reference (sys_id) to the ECC Queue message that this message is in response to. Discovery makes extensive use of this field to track the hierarchy of messages that result from a given scheduled Discovery.

Queue

This field determines whether this message is an input message or an output message, by being set to input or output, respectively.

State

This field is initially set to ready when any message is inserted into the ECC Queue. For output messages, the recipient of the message is responsible for updating this field to processing (when it starts processing the message) and processed (when it has completed processing the message). For input messages, the ServiceNow ITSA Suite instance is responsible for updating this field to processing or processed as it begins and completes processing of the message. Generally speaking, this processing occurs in business rules (on the ECC Queue) that watch for incoming messages being inserted. Note that in all cases, the processing state is optional – it is perfectly acceptable for message states to be updated directly from ready to processed.

Created

The time when this message was created.

Processed

The time when this message was processed

Sequence

The unique sequence number for this message. This value is automatically generated when an ECC Queue record is inserted. Its use is deprecated.

Error string

An error message if an error occurred during processing (this field is hidden on the standard form unless there was an error).

Payload

The body of the message. The contents of this field is arbitrary; generally it is different for each system that messages are being exchanged with. Discovery uses XML documents for the payload. The returned XML document has a root tag of <results> containing one or more <result> tags and a single <parameters> tag. The parameters are simply an echo of those sent to the MID server in the probe; they vary from probe to probe, but in general they tell the probe the details of what it is to do and how it should behave. The result tags are the most interesting ones: they contain the actual data generated by the probe.