Nullifying BizTalk Messages
BizTalk Null Adapters, sometimes called Void Adapters, have existed for quite some time, they are used to get rid of (nullify) unwanted BizTalk messages.
These adapters are just like any other BizTalk Adapter except they don’t transmit the incoming messages to a target system, instead they make the messages disappear! but, why would anyone need that?
In this post I talk about some of the typical use cases for nullifying messages in BizTalk Server in light of the solution design and implementation aspects.
Unwanted messages: a Design flaw or an Inevitable by-product?
By design, a published message in BizTalk must have at least one subscriber, otherwise that message will be suspended in the message box and the dreaded BizTalk error will appear: “The published message could not be routed because no subscribers were found”.
The purpose of a Null Adapter is to get rid of the unwanted published messages in the message box.
However, having unwanted published messages to the message box seems questionable; as it entails a waste of Compute, Network, Memory, and I/O resources during the whole journey of those unwelcomed messages only to throw them away.
This could indicate that the solution design lacks proper control of the messaging flows to the extent that a dedicated subscription to these messages is required in order to flush them out of the message box to prevent them from getting suspended and cluttering the message box.
It makes more sense to prevent these unwanted messages from being published in the first place, that way we don’t need to have additional message box hops (Pub/Sub) which not only entails I/O performance overhead, but also unnecessarily increases the solution complexity.
Controlling the Message Flow
When chosen wisely in the right context and with full understanding of its typical performance tradeoffs, Orchestrations lead to confidence with its visual canvas that clearly defines the messaging flows in a more deterministic manner.
In an orchestration workflow, you are in charge of designing the message flow, which includes ingesting, processing, deciding when to publish, and importantly, when not to publish messages to the message box. Consequently, this level of control could prevent unwanted messages from being published in the first place.
Selective Omission of Messages
In request-response messaging scenarios where a subset of published messages would not be needed based on specific message context or content criteria, message omission could be done in the pipeline.
This could be accomplished using a custom pipeline component that searches for these messages and destroys them. Alternatively, the BRE pipeline Framework has a wide range of powerful, ready-made BRE artifacts that execute within a pipeline component, one of which is the Conditional Nullify for messages based on your arbitrary BRE conditions.
Nullifying messages in pipelines is very useful in low-latency messaging scenarios which can’t tolerate additional overheads from the extra message box hops or from the usage of orchestrations.
For example, nullifying response messages coming back from a downstream system via a Send port based on specific message context properties. In this case, there are still transport and compute overheads on the adapter-level, however, this option is more efficient as it avoids unnecessary message box hops compared to a send port subscription with a Null Adapter.
The Overlooked One-way Pattern
As the solution evolves and its complexity increases, some of published messages that were once subscribed upon could become no longer needed.
In a poorly operated environment and with insufficiently skilled BizTalk Administrators or Developers, BizTalk Server is treated as black box, consequently, the subscribed service instances (Send Ports or Orchestrations) would just be un-enlisted and replaced with send port with Null adapter in an effort to keep things running with minimal change to the running solution.
In one-way messaging scenarios, the most efficient option for getting rid of unwanted messages would be to avoid them altogether by using one-way Send Ports for the supported adapters. Although this is straightforward to BizTalk veterans, it is often disregarded by the less experienced, especially when the project timeline pressure is added to the mix.
Final quick points to recap and to take into consideration
- Try to avoid publishing unwanted messages in the message box as much as possible
- If absolutely necessary, try to use pipeline components instead of adapters to nullify messages
- Re-think the solution design if you have unwanted messages being published
- Message tracking is generally important and if you are nullifying messages it becomes vital
- Novice BizTalk Developers and the Null Adapter are a recipe for disaster
- Nullifying messages increases the solution’s complexity as it degrades its predictability
- Nullifying messages decreases the solution’s maintainability as it introduces runtime challenges and edge cases
- Even though Null adapters don’t emit messages, they still consume compute resources