Previous – Datatype Channel | Index | Next – Dead Letter Channel

This week, we’ll study a pattern known as Invalid Message Channel.

When do I use this pattern?

An “Invalid Message” Channel is used to store Invalid Messages for developers to analyse. A message is put into an invalid message channel if it can be sent to the receiver successfully and cannot be processed by the receiver because of its contents. Note that if the message generates an application error, then such a message should not be put into an invalid message channel.

For example, a message missing a header such as Authorization or Cookie header where basic authentication is used is a candidate for invalid message channel. Whereas, a message that has an invalid value for a field should not be put into an invalid message channel.

In other words, the invalid message channel contains messages that are deemed invalid because of a coding/configuration issue in the sender or the messaging system. As the messages in the invalid message channel have coding/configuration issues, they cannot be retried.

Invalid Message Channel in CPI

In CPI, we’ll put the messages missing the authentication header in the invalid message channel.

Integration Flow

Get Products

This simple example flow starts immediately using a Timer Start Event, gets the products from ES5 system using a Request-Reply and OData Receiver Adapter.

If any exceptions occur, an Exception Subprocess is used that simply puts the incoming message in the ‘InvalidMessages’ queue using JMS Receiver Adapter.

Configuration of OData Receiver Adapter:

*Note that Authentication Property is left to None on purpose to cause the error for demonstration purpose.

Output – Authorization Issue

When the integration flow is deployed, it runs immediately, fails to fetch the production because of missing authorization. The message is put into ‘InvalidMessages’ queue.

Invalid Messages

Output – Issue Resolution

The issue can be resolved by adding Basic Authentication to the configuration of the OData Receiver Adapter.

Once the issue is resolved, the flow runs successfully without any issues.

Issue Resolved

When is this pattern useful, really?

From the example, it may seem that this pattern is only useful in a development environment in a classic tiered deployment system. The ideal scenario will be that this pattern is only used in the development environment. However, this pattern is more useful where multiple senders are sending messages to a single channel.

If a new sender is added to the list of senders, it is easier for the developer to monitor the invalid message channel to quickly investigate common issues such as missing the authorizations. More helpful error identifiers can be coded using an XML Validator or EDI Validator or using custom validations such as checking for body length or existence of required headers.

EIPinCPI Rating – 10/10

Similar to all previous Message Channel patterns, this pattern is supported in CPI through JMS Queues, and therefore deserves 10 out of 10 EIPinCPI Rating.

Note that the 10 rating is for the availability of creating an Invalid Message Channel itself and not for identifying the issues in the message. Although, the validation of message is supported through XML Validator or EDI Validator.

Conclusion

“Invalid Message” Channel contains messages that are delivered to the receiver successfully but cannot be processed because of the contents of the message.

References/Further Readings

• Invalid Message Channel Pattern in Enterprise Integration Patterns
• CPI Components
  • Timer Start Event
  • Request-Reply
  • OData Receiver Adapter
  • Exception Subprocess
  • JMS Receiver Adapter
  • XML Validator
  • EDI Validator

Hope this helps,
Bala

Previous – Datatype Channel | Index | Next – Dead Letter Channel