Null port
Null ports subscribe to the bus and discard the message. A null port is a one-way send port without an adapter: 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.
Outbound map & pipeline, with surrounding variable assignments, optional; same as a send port's outbound flow
No adapter, no return path, nothing published, the message is discarded after the outbound stages, so the null port has no port-level Message Type setting of its own
In the port editor a null port is a trimmed send port: Port Type Null, one of the four values that dropdown carries, the Adapter picker empty, Way pinned to One and no Response group in the sidebar; the Solicit group keeps the same five tabs, Subscription, Open Variables, Map, Pipeline, Close Variables. It borrows the send-port editor, so its Solicit group is the send-port kind, sublabelled Bus → Adapter, an outbound position leaving the bus, except that the discard stands where the adapter would.
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.
A null port is an outbound-only position: it takes a message off the bus and nothing ever goes back on, so no port-level Message Type setting applies here. The message arrives carrying the type it was published under, that type drives the Typed-table lookup, and any component in the pipeline still sets a Message Type on everything it emits, as it does at every other position. See Components classify the Message Type. 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). The source Message Type is the one the bus message was published under. Because the message is discarded after the outbound stages, no port-level Message Type setting 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.
A null port carries a subscription expression but no Exception Message Type field: a run whose map or pipeline stage fails is recorded as an Error, with no exception path to re-publish on. Write a subscription expression, the Boolean filter evaluated against every message on the bus, to select which messages this port consumes. What a null port’s runs persist is decided by the Tracking level set on the Application, which covers every port it owns; there is no tracking field on the port. Tracking and Subscriptions behave as on every port and are documented once, with diagrams and the full token list, under Options available on every port and Subscriptions and Message Types on the Ports overview.
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.