Null port
Null ports subscribe to the bus and discard the message. The optional variable, map, and pipeline stages still run before the discard — so audit entries, tracking metadata, and variable captures survive.
A null port is a flavour of send port whose dispatch step is replaced by discarding the message. The flow runs the standard outbound stages — variable assignments, outbound map, outbound pipeline, more variable assignments — and then deletes the message. Null ports are one-way only; there is no return path.
The use case is straightforward but specific: prevent messages from sitting on the bus indefinitely when no real subscriber wants them. By giving an unwanted message a subscriber that simply consumes and discards it, you keep the bus tidy. The optional outbound stages are still useful — they let you capture values for activity tracking or audit before the message disappears.
Outbound map & pipeline, with surrounding variable assignments — optional; same as a send port's outbound flow
No adapter, no return path, no Message Type — the message is discarded after the outbound stages
The null port has a single map hookpoint on the outbound side. It takes the same three configurations as every other port-side map: None (no transform), Typed (a table of maps keyed on source Message Type), and Universal (a single map applied regardless of source). See Maps — Selecting a map for the concept. Typed table rows are unique by source Message Type — the UI enforces that.
Because the message is discarded after the outbound stages, no Publish Message Type Fallback applies — nothing ever publishes. The map runs for its side effects: variable captures, tracking entries, audit metadata. Typed is genuinely useful when a single null port consumes messages of different Message Types and you want a different transform for each before the variables are captured; otherwise Universal or None usually does the job.
The port’s subscription expression matches a message on the bus and pulls it into the null port. The configured stages then run in order before the message is dropped.
An optional set of variable assignments runs as soon as the subscription expression matches and the message enters the port. This is the place to capture context from the message that needs to survive the discard — correlation IDs, partner identifiers, audit fields, or anything that should appear on the Tracking screen.
The map step has three modes — None, Typed (a table of maps keyed on source Message Type), or Universal (one map regardless of source). Because the message is discarded after the outbound stages, no Publish Message Type Fallback applies on this side. The map runs purely for its side effects — reshaping the in-flight message so the following stages can capture different values from it. See the Map configuration section above.
The outbound pipeline can apply intermediate processing — useful when the goal is to extract or compute values that the on-exit variable assignments will need, or to invoke a custom component for audit or external notification before the discard.
A second optional variable-assignment stage runs after the pipeline, immediately before the message is dropped. The values captured here, together with the on-entry capture, are everything that will survive the null port — the message body itself is about to be gone.
The null port has no adapter and no return path. The in-flight message is deleted. What survives is everything the previous stages emitted out-of-band — captured variables, tracking entries, audit records, and any side effects invoked by pipeline components.
Two options are independent of port type and direction — they apply equally to receive, send, loopback, and null ports.
Exceptions. When enabled, the port has a configured exception Message Type. An error during processing swaps the in-flight message's Message Type to that exception Message Type and re-publishes it. The payload itself is untouched.
Subscribe to the exception Message Type from another port to handle failures centrally — typically a send port that emails an alert, writes to a log, or files a ticket. Error traffic flows on its own Message Type rather than mixed with the original. On the Tracking screen, runs handled by a configured exception path appear as Exceptions; runs that failed without one appear as Errors.
Tracking. Per-port setting with three levels controlling what — if anything — is persisted to the Tracking store on each run.
Set the same level across every port of a flow for a coherent end-to-end view on the Tracking screen. The system also maintains its own minimal internal tracking for running and suspended transactions (used for the runtime dashboard) — that's separate from this configurable Tracking and is always on. Every tracked step writes to the tracking database — mind the cost tradeoff with retention and reindexing jobs.
Send, loopback, and null ports each carry a subscription expression — a Boolean filter evaluated against every message published to the bus. Two-way receive ports carry the Response Subscription Expression for the same evaluation, used to identify which message on the bus is the response to send back to the caller through the same port.
Pub/sub. When a message hits the bus, every subscription is evaluated independently. Each matching port gets its own copy and runs the message through its own flow. The same message can be picked up by any number of ports.
Message Type is the string identifier every bus message carries (similar in concept to BizTalk’s). A subscription expression most often checks the Message Type, but it can reference any of the following:
| Token / source | Resolves to |
|---|---|
{{Message.MessageType}} | The current message’s Message Type identifier |
{{Promoted.MessageType.Name}} | A promoted property defined on the Message Type (see Message types) |
{{Variable.Name}} | The current value of an application Variable |
{{Config.PortName}} | The Name of the port the current message originated from |
{{Message.Body}}.XPath() | A value read from the message body — XPath (XML) or JPath (JSON) |
| Custom functions | Runtime-evaluated logic |
That's the null port
Anything not subscribed by another port can land here, leaving variables and tracking intact. Closes the loop on the four port types — back to the Ports overview.