Introduction

In one of my previous posts I briefly described the concept of test message. Today I wanted to explain it in more details. The need of having production system operational is self-explanatory. It is the highest priority in all businesses - be able to operate. Without any doubts regarding software quality. Users need to trust the system.

Usually systems communication can look like following.

There is number of systems exchanging information.

If I pay for a book I trust the banking application, to be charged once. That’s one piece. Another one is messaging. All systems exchange messages. Communication between components, processes, computers etc. requires some kind of messaging schema. In large systems this is called integration. Having those two pieces the concept of test message can easy arise. In order to keep the system operational we need to ensure that messages are flowing in the way they intended to.

Potential problem

”If it works, don’t touch it” isn’t said without reasons. As long as we actively develop particular integration we know how it works. WE have one interface with other party and everybody is happy.

Potential problems can arise when one of the systems or another component, like authentication mechanism, is updated. It is hard to figure out what part of the system can be affected. The only reasonable solution is to create exact same test environment. Sometimes this can be hard or even impossible.

Another possibility is to update system, wait till first message arrives and examine that everything worked correctly. It is a possibility, but some integrations may exchange messages very seldom.

I don’t think there is a silver bullet to this problem

Test Message

At this point I want to intoduce Test Message. Test message itself will not ensure logical integrity. Integrity should he achieved by other ways. Test message can ensure that integration is operational. General idea of this concept is described here

Generally said the idea is that test message is generated by one of the system and received by other system. In case if we are in charge of the systems it is easy to filter out test messages. In case where we integrate with system out of our administration I suggest to intercept message at out endpoint to the external system.

The simplest solution can be adding extra flag to message schema indicating that this particular message is for testing. To make domain purists happy there is another simple solution. Set the value of one of the properties to a test value, eg.”TEST_VENDOR” or “TEST_QUOTE_NUMBER”. Then filter messages with that value at the endpoint.

Having some messages generated and flowing in the system it would be nice to have monitoring in place. Monitoring will be our sensor to check system health. I’ll touch that in another post.