Discovery Pattern Design

Patterns are the modern engine of horizontal Discovery. Where the legacy approach used a long chain of probes and sensors, a pattern is a declarative, ordered set of operations that the MID Server executes to find data, parse it, and populate Configuration Items (CIs). You author and edit patterns in the Pattern Designer, a low-code editor. Understanding what a pattern is made of and how it runs is the single most testable skill on the exam.

Anatomy of a pattern

A discovery pattern is built from sections, and each section is an ordered list of steps:

• Identification section: runs first. Its job is to collect just enough data to identify the primary CI (for example, the host) and create or match it in the CMDB through the Identification and Reconciliation Engine (IRE). The identification section determines whether you have found a real, uniquely identifiable device before you invest effort exploring it.
• Connection section(s): exist only in application patterns (Service Mapping). They run after an identification section has matched the CI and find the CI's outgoing connections (for example, from a load balancer to the application servers behind it, or from a running process to the database it connects to). Horizontal (infrastructure) patterns have no connection section, and a connection section never opens or authenticates the SSH, WMI or SNMP session.
• Extension sections: add logic (often through a shared library) without editing the shipped identification section.
• Steps and operations: every step holds exactly one operation, and steps run in order.

Operations and parsing strategies

Each pattern is a sequence of operations. Common operation types you must recognize:

• Set Parameter Value: assign or compute a variable used later in the pattern.
• Parse Variable / Parse File: extract structured data from raw command output or a file.
• Process and connection collection: Parse Command Output on commands such as ps or netstat pulls running processes and their network connections (the backbone of application discovery).
• WMI Query, SNMP Query, HTTP Get Call, Parse Command Output: protocol-specific data collection steps.
• Create Relation/Reference: build a relationship (such as Runs on::Runs) or reference between CIs. CI attributes themselves are filled through CI attribute variables.
• Create Connection: describe an outgoing connection; available only in connection sections of application patterns.
• Merge Table / Filter Table / Transform Table / Union Table: manipulate the in-pattern tabular variables (Merge Table joins two tables, Filter Table keeps the rows that meet a condition).
• Match: checks a condition and stops running the pattern if the condition is not met. It does not join tables or filter rows.

There is no generic "Web Service" operation (HTTP data collection uses HTTP Get Call) and no loop or For Each construct: table operations already work across all rows.

When you extract data from raw text, you choose a parsing strategy. The main strategies tested are:

• Delimited text: split each line on a delimiter (space, comma, tab) into columns.
• Configuration file strategies (for example INI or properties files): pull name = value style output.
• Regular expression (regex): capture groups from semi-structured text. The most flexible and the most common source of pattern bugs.
• XML / JSON / table: parse structured payloads directly into pattern variables.

Most operations write their results into a temporary variable (scalar or tabular). The documented variable kinds are global variables, CI attribute variables and temporary variables; there are no CI, Global or Connection "scopes". Later operations read from those variables. Tracing the flow of a variable from the operation that fills it to the operation that consumes it is the core troubleshooting skill.

Authoring and debugging in Pattern Designer

• Use Debug mode to run a pattern against a chosen target, testing each step with its Test button and inspecting the value of every variable after each operation. This is how you isolate which operation produced a wrong or empty value.
• Pattern steps run top to bottom; reordering operations changes behavior. An identification step that depends on a variable must come after the operation that sets it.
• Extensions let you enhance a pattern (add new exploration logic) without altering its identification section, so you do not change how the primary CI is matched.
• Patterns are versioned and can be associated with CI types; the right pattern runs based on what classification determined the device to be.

Pattern vs. probe-based discovery

• Probes/sensors (legacy/classic) are still used in the early phases (port scanning, classification), but identification and exploration of most CI classes is pattern-driven today.
• A pattern executes entirely on the MID Server and returns results in a single payload, which is generally more efficient than many round-trips of probes and sensors.

What to drill for Domain 1: the section types (identification, extension, and connection sections in application patterns only) and one operation per step; the order of operations and variable flow; Match vs. Merge Table vs. Filter Table; parsing strategies and when to use each; how to use Debug to find the failing step; extensions vs. editing identification; and how a connection section in an application pattern finds outgoing connections after identification.