Node types
Reference for the five node shapes in Fabrik's query builder — Start, Class, Filter, Post-Processor, and Output — and what each one actually does.
Every query in Fabrik is a graph made of five node types. Each one has a single job, a specific place it can live in the graph, and a panel of settings that appear when you click on it. This page is the reference — the deep dives live on their own pages, linked where relevant.
At a glance
| Node | Purpose | Where it lives | Covered in |
|---|---|---|---|
| Start | Binds the query to an APIC connection | Always first, exactly one | Connect an APIC |
| Class | Asks APIC for objects of a specific ACI class | After Start, or chained from another Class | Building a query |
| Filter | Applies standalone APIC filter rules | After a Class | Filters |
| Post-Processor | Transforms the result after APIC returns it | Downstream of a Class (or another processor) | Post-processors |
| Output | Terminates the graph and defines how results appear | Exactly one, at the end of a chain | This page + Results |
A minimal runnable query is three nodes: Start → Class → Output. Everything else is elaboration.
Start
The Start node is the only node that's always present. A fresh canvas gives you one; you can't add another, and you can't delete the last one.
What it carries. A reference to one of your saved APIC connections. Without it, nothing downstream has anywhere to run.
Visual state.
- A coloured status dot in the top-right corner mirrors the last test result on the bound connection — green for success, red for failure, grey when the connection has never been tested.
- With a connection selected, the node shows its name and a tooltip (URL, username, SSL state, last test).
- With nothing selected, an amber banner inside the node reads "No APIC connection selected".
Auto-selection. If there's only one APIC connection you can see, Fabrik picks it for you automatically. With more than one, click Select APIC on the node to open the picker; to change later, the same button reads Change.
Where it can connect to. Only to a Class node — there's nothing else that makes sense immediately after Start.
Class
The Class node is the workhorse: it represents an ACI class (fvTenant, fvBD, vzBrCP, and so on) that Fabrik will query via APIC's REST API.
What it carries. The class name, optional MIM metadata (properties, relationships, containment info), local filters attached to this class, and per-class query scope settings.
Visual state. The node shows the class name and a package badge (fv, vz, bgp, …). If local filters are set, a badge reports the count.
Preview button. A small play-circle icon on hover runs a preview query scoped to this node and everything upstream of it. The raw result is cached in memory (not committed to any saved query) so you can iterate on downstream post-processors without re-hitting APIC every time.
Where it can connect to.
- Another Class node — the edge is then read as containment (
fvTenant → fvBDmeans "bridge domains inside this tenant"). The Connection rules page explains which parent/child combinations the MIM actually allows. - A Filter node, a Post-Processor, or the Output.
Filter
Filter is a standalone node for cross-cutting restrictions that don't belong on a specific class — scoping, DN pattern matching, subscription flags.
What it carries. A filter type and the filter expression itself. Three types are supported:
| Type | What it does |
|---|---|
| Property | Filter results by object property values (name, status, and so on). |
| Query-target-filter | Apply wildcard or regex patterns against Distinguished Names. |
| Subscription | Subscribe to changes or audit logs on the matched set. |
Visual state. A filter-type badge on the node, and a count badge when multiple filter rules are combined.
Where it can connect to. Downstream into another Class node, a Post-Processor, or the Output.
The full filter operator reference lives on the Filters page.
Post-Processor
Post-Processors run after APIC returns data. They transform rows, extract fields, sort, group, flatten, or run regex replacements on the result set — whatever you need to shape the data before it hits the Output.
What it carries. A processorType (see the table below), a processor-specific configuration, and an isPaused flag.
Ten processor types, at a glance:
| Category | Types |
|---|---|
| Row filtering | filter_rows, pattern-filter |
| Field operations | field-extract, dn-extract, flatten, map-transform |
| Text | regex-transform, text-operations |
| Aggregation | array-sort, aggregate |
Execution order is visual, not topological. When multiple Post-Processors are chained, the backend runs them top-to-bottom by their Y position on the canvas — not by edge order. Lay them out the way you want them to execute.
Pause. Hover a processor and the action bar appears above it with a Pause button. A paused processor is greyed out and skipped during execution without being deleted — useful when you want to see what the pipeline looks like without a specific transformation.
Where it can connect to. Another Post-Processor, another Class (to start a pipeline stage), or the Output.
The full processor catalogue with each type's configuration is on the Post-processors page.
Output
The Output node is the terminator. Every runnable query has exactly one, at the end of a chain — the Run button stays disabled until it's there.
What it carries.
- Pagination — on/off plus page size (10, 25, 50, 100, 500, or 1000 rows per page).
- Time Machine tracking — on/off. When on, each execution produces a snapshot you can compare later.
- Validation-query flag — marks this query as a source for AWX validation rules.
- A pipeline-out handle on the right side, for chaining into a new Class to build multi-stage pipelines.
Pagination and Time Machine are mutually exclusive. Time Machine needs the complete result set to detect drift, so turning it on disables pagination. The Output node's configuration panel surfaces this as an explicit warning rather than silently overriding.
Time Machine requires a saved query. The toggle is disabled until you save — snapshots are indexed against a saved query ID, so unsaved queries have nowhere to attach them.
Where it can connect to. Nothing further, unless you're building a pipeline — the pipeline-out handle on the right lets you chain an Output into a new Class node, starting a second stage that reads this stage's results as its input.
Shared mechanics
A few things are the same everywhere.
Click to configure. Clicking any node opens the right panel with that node's configuration. Click empty canvas (or press ⌘B / Ctrl+B) to dismiss.
Hover to act. Hovering a node reveals an action bar above it with:
- Delete — on every node type.
- Pause / Resume — only on Post-Processor nodes. Pausing class or filter nodes would break the query's structural meaning, so those opt out.
Colour ring on select. The selected node gets a coloured ring and a heavier shadow so you can always see what you're editing.
Every node type has a coloured status dot. The meaning depends on the node — connection health for Start, preview activity for Class, presence of filters for Filter, pause state for Post-Processor, always-on for Output.
Things the canvas won't let you do
A few hard rules are enforced at the canvas level so you can't build something the backend would reject:
- There's always exactly one Start node. You can't add a second, and the one you have can't be deleted.
- A chain can only have one Output node. Pipelines produce a new chain after the Output, not a branch off of it.
- Run stays disabled until the graph has at least one class downstream of Start and an Output at the end.
- Edges between Class nodes must respect the ACI containment hierarchy encoded in the MIM. Invalid parent→child combinations are rejected as you try to draw them. See Connection rules.
Reference done. The next page, Building a query, walks through the actual flow of picking node types, finding ACI classes, and wiring them together.