Debugging

The Pipeline Debugger provides an interactive testing environment for validating pipeline processing logic before deployment. It enables you to execute pipelines with test data and observe how each processor transforms the data through the processing chain.

Accessing the Debugger

The debugger is a tab of the Pipeline Editor's dock. Navigate to Content Management > Pipelines, select a pipeline, click Pipeline Editor in the pipeline detail header, then select the Debugger tab in the dock along the bottom. The dock also carries a Prediction tab, which runs a sample through the pipeline to estimate how much each processor reduces or enriches the data; the two tabs share the sample picker described below.

Dataset Providers

Test data is selected in a two-step drawer: Select sample (choose a provider) and Select log lines (pick a specific log entry), after which Choose log line starts the session. The debugger supports four providers:

Provider	Description
Library samples	Select a sample from the Library, or one that came with the pipeline's Content Hub pack (Kind: Pack)
Upload log file	Upload a log file containing test data
Enter logs manually	Enter log data directly in the input editor
Live logs	Capture live logs from a Director or Device in real time

Library samples

One table lists two sources together: the samples that came with the pipeline's Content Hub pack, and the Library's own samples that are offered to the debugger. The Kind column tells them apart — Pack for the pipeline's own samples, Template or Records for the Library's — and the Records column shows how many lines each one holds. Pack samples are listed first, and Search samples narrows both sources by name. Pick a sample, then choose one of its lines in the next step.

note

The Library samples tile is available without Library read permission too; it then lists the pack's samples only.

Upload log file

Upload log files for one-time testing. After upload, select a specific log line from the file content to use as test input.

Enter logs manually

Enter log data directly in the input editor, then select a specific log line to use as test input. This method is useful for:

• Testing specific edge cases
• Debugging individual log entries
• Quick validation of processor behavior

Live logs

Capture live data from a selected Director or Device, then pick a captured log line as test input. The capture controls match the Live Data panel. While a capture is running, the list stays where you left it rather than scrolling to the newest event, so you can pick a line while events keep arriving.

Changing the Sample

Once a sample is selected, the debugger header shows its name beside the Sample label, with a Change button. Change opens the Manage selected sample modal, where you pick another line of the same sample and confirm with Select log line. Change sample inside that modal reopens the drawer to pick a different sample.

The Prediction tab uses the same drawer and modal, except that you tick several lines and confirm with Select log lines.

Entry Point

The Entry point control in the debugger header names the pipeline a run starts from — the main pipeline or one of its child pipelines. Until something has been run, the entry point follows the pipeline tab that is active in the editor, so switching to a child pipeline's tab debugs that child; the selected sample is kept. After a run, or after you pick an entry point by hand, it stays where it is, and Run brings the entry point's tab forward. Changing the entry point while a sample is selected asks for confirmation, because the change restarts the debugger; your edits to the pipeline are kept.

Environment Variables

The debugger allows configuration of environment variables that affect pipeline execution context:

Open the modal with the Manage environment variables toolbar button.

Control	Input Type	Description
Choose custom device type	Dropdown	Simulates the source device type (Windows, Linux, Syslog, HTTP, TCP, UDP, Kafka, Azure Event Hubs, Azure Blob Storage) — sets the devicetype variable
Definition ID	Dropdown	Sets the definitionid log definition identifier from available Windows and Linux log types
Request	Text	Configures request-level context variables
Enable System Fields	Toggle	When enabled, system-generated metadata fields are included in the debugging process
Route configuration	YAML editor	A route configuration document — the same YAML an Advanced Route's Route Configuration step takes — with a conf block. The debugger applies that block over the pipeline's own settings for every run in the session, the way a Director does for a route

info

Configure these variables to match production conditions when testing pipelines that contain conditional logic based on device type or other context values. Leave Enable System Fields off to show only user data fields, reducing clutter when tracing data transformations.

Unlike the other controls, which reach the pipeline as text, the route configuration can express a boolean, a number, or a list — useful for debugging a pack in a mode other than its default:

conf:
  use_smart_routing: false

The route configuration is part of the editing session; it is not saved with the pipeline. A document that is not valid YAML, or has no conf block, fails the run with an error that says so.

Pipeline Visualization

The debugger displays the pipeline structure as an interactive node graph:

• Pipeline nodes: Represent the main pipeline and any referenced child pipelines
• Processor nodes: Show individual processors in the execution chain
• Connection lines: Indicate data flow between processors

Navigating Child Pipelines

When a pipeline references child pipelines, click on a pipeline node to navigate into its structure. A breadcrumb trail at the top of the view tracks your navigation path and allows you to return to parent pipelines. Two toolbar buttons perform the same navigation: Step into (enabled when a pipeline node is selected) and Step out (enabled when inside a child pipeline).

Execution and Results

Running the Pipeline

Click Run to execute the pipeline with the current input data. The debugger processes the data through all configured processors and displays results for each step. The Quit debugger toolbar button closes the debugger and returns to the pipeline detail view.

Node Status Indicators

After execution, each node displays a status indicator:

Status	Description
Completed	Processor executed successfully
Failed	Processor encountered an error
Skipped	Processor was skipped due to conditional logic
Continue	Processing continued to the next processor
Dropped	Event was dropped by the processor
Return	Processing returned early from the pipeline

Viewing Results

The debugger displays input and output in a side-by-side layout, enabling direct comparison of data before and after processing. This parallel view simplifies identification of changes at each pipeline stage. Click a processor node to view its specific output.

Click Switch to diff view to compare input and output in a unified diff that highlights changes; click Switch to split view to return to the two-panel layout. Click Show processor config to display the selected processor's YAML configuration in a read-only viewer, and Hide config to collapse it.

Rerouted Runs

When a run sends a record through a smart-routing pack's reroute processor, Simple view reflects it:

• The status in the debugger toolbar reads Rerouted instead of Dropped or Completed, and the size figure beside it is hidden.
• The Output header shows a switch: Default, followed by one entry per rerouted record, named after the reroute's table or stream (for the ASIM packs, the table name — ASimNetworkSessionLogs, ASimWebSessionLogs) — or its target when it names none. Selecting an entry shows that record in Output; the size figure next to the switch belongs to whichever output is selected. The same switch appears in the diff view's header.
• Several copies of the same record sent to different targets under one table name are listed once.
• A dropped record shows {} in Output.

Failed Runs

In Simple view, a failed run shows a notice above Output naming the processor that failed, its position in the pipeline, the pipeline it belongs to and the line it is on. Go to processor opens that pipeline's tab in the editor and jumps to the line.

Workflow

1. Select or enter test data using one of the dataset providers
2. Configure environment variables if needed for conditional processing
3. Click Run to execute the pipeline
4. Review node status indicators to identify processing results
5. Click individual nodes to inspect their output
6. Use Switch to diff view to compare transformations
7. Iterate on pipeline configuration based on test results

---