I’ve never been much of a patterns guy. I kind of always have the ability to apply common sense to a system and turn up something that is straight forward and makes sense. Periodically I get asked about what set of patterns I used to decide how a system should behave. To answer this question I tend to laugh maniacally, throw a flash-bang on the floor and run out of the room.  So I was glad to see that the pattern I’ve been using recently is called the VETO pattern.

Allow me to describe the requirements of the system that led me to the VETO pattern.

I have a source system message obtained from a staging table. This message is incomplete and needs to run additional queries against the target database in order to complete it. Once these additional queries are complete, the data needs to be inserted into the target database.

The original system performed all these tasks in a single java proxy, mangling the logic for enriching the source message with the SQL for inserting into the target database. I was tasked to migrate this to WebSphere Process Server with the knowledge that additional clients would need to use this service.

My solution was contained in four modules:

The first module received the message from the source system, validated it and determined what fields needed to be enriched. After enrichment, it transforms it into a target database message.  A second module provided the methods for enrichment from the Target Database. The third module processes a fully enriched source object for insertion into the target database. The fourth module just held the WebSphere Adapter for JDBC. I like keeping it in on it’s own incase independent adapter fixes are required.

Anyway, turns out that this is the VETO pattern. A pattern that I won’t be forgetting anytime soon.