VETRO Pattern

Intent

The VETRO pattern combines multiple sequential actions taken on a message into a consistent structure with well-defined responsibilities. It has many variations. One such variation is the VETO pattern, which excludes the route step

Context and problem

Camel is a lightweight integration framework. In the same way that it can scale down and be used for ad hoc protocol bridging only, it can also scale up and be part of a fully-fledged ESB with hundreds of routes. When the number of Camel routes is that large, it becomes a different challenge for all parties involved, which is as follows:

• The architects have to design new services with manageable complexities.

• The development team must develop, test, and debug multiple new routes in a short time.

• The DevOps team must understand and provide 24/7 support for all these processing flows in production.

In such an environment, having a common structure for the Camel routes becomes essential. It must follow a strict naming convention with project-wide guidelines and principles to help us interpret the message flows.

Note: The common naming convention means that we will be able to reason about the purpose of a route by its ID, the implementation of a Processor by its name, etc.

Having project-wide guidelines and principles will ensure that the team is not wasting time choosing from various DSLs, components, error handling policies, logging strategies, etc.

Forces and solutions

If we analyze the Camel routes in a large project, we will notice that the majority have a similar structure and perform similar operations. Perhaps they differ in the following:

• The transport protocol
• The message format
• The persistent store
• The target system

The overall routing flow is quite common. Usually, the message is received from the source system and goes through the following steps:

• Step 1: It is validated.
• Step 2: It is enriched with some contextual information.
• Step 3: It is transformed into the desired format.
• Step 4: It is acted upon immediately or routed to another system.

Following are some of the exceptions while applying this pattern:

• Some flows may have more elaborate validation if the message comes from an untrusted system, and some may not require validation.

• Some messages may require enrichment from external data sources, and some may not require any additional information at all.

• Some flows may have the data in the right format, and some may require transformation.

• Some messages may require routing to other systems, ...