Test message EIP

[jiminaus]

I'm building a system that doesn't require high throughput, but it does need to be highly reliable.   I'm attracted to the Test Message pattern documented in Enterprise Integration Patterns.  I really like the idea of composites being able to test themselves and having the reassurance that the components are actually behaving correctly.

I've tried building the pattern within a single composite.  I built bean components for the Test Data Generator, Processor (the actual component that does the work and that is being tested), and Test Data Verifier.   I build a camel routing component for the Test Message Separator.

I had hoped that the Test Data Generator could send the expected outcome to the Test Data Verifier together with a test correlation ID and also insert that test correlation ID into the test message, and then the Test Message Separator could detected the presence of the test correlation ID in a message leaving the Processor and divert the message to the Test Data Verifier instead of the usual composite reference.

What I'm struggling with is having the test correlation ID propagate across the Processor.  Message tracing is showing me that test correlation ID is in the message at Exchange scope between the Test Data Generator and the Processor, but then it dissapears.

I had the idea of changing the Processor to also look for correlation ID and copy it into the message going out from it, but that like seems like an anti-pattern.

Is what I'm shooting for possible in SwitchYard 1.1?  Can anyone give me any advice or references on how to do this pattern?

[kcbabo]

If you attach what you have going now, we can help provide advice on where to go.

[jiminaus]

I've attached the architectural spike I'm working on.  I've also attached an image of the pattern I'm trying to implement.

In TestDataGeneratorBean, I have this code where I'm trying to send the test data to the TestDataVerifierService before sending the test message to the ProcessorService.

String correlationId = "123";
String testMessage = "From test data generator";
String expectedOutcome = "In Processor.process1: text=From test data generator.";

testDataVerifierService.newTestMessageSent(
 new TestMessageSentEvent(correlationId, testMessage, expectedOutcome)
);

ReferenceInvocation i = processorService.newInvocation();
i.getContext()
 .setProperty("com.example.switchyard.test_msg_proto.correlationId", "123", Scope.EXCHANGE);
try {
 i.invoke(testMessage);
} catch (Exception e) {
 e.printStackTrace();
}

In TestMessageSeperatorRoute, I've tried to set up this.

from("switchyard://TestMessageSeperator")
 .choice()
   .when(header("com.example.switchyard.test_msg_proto.correlationId").isNotNull())
     .to("switchyard://TestDataVerifierService?operationName=verify")
    .otherwise()
     .to("switchyard://PostProcessorService");

But the test messages always land up at the PostPrcoessorService and never at the TestDataVerifierService.

[kcbabo]

The issue here is that the property is not set on the invocation of TestMessageSeparator.  Let me explain why.  Right now, you are doing this:

TestDataGeneratorSerivce --(1)--> ProcessorService --(2)--> TestMessageSeperator

There are two message exchanges there, each represented by --(n)-->.  In the current app, you are setting the exchange-scoped property in (1), which means it's visible to TestDataGeneratorService and ProcessorService.  You are not setting it in (2) however, which means that it's not visible to TestMessageSeparator.

[kcbabo]

One other thing to keep in mind is that each component in the Test Message pattern doesn't necessarily have to be a service.  For example, the message separator can be included inside the application's processing logic to screen out test messages.  Whether or not this is appropriate for your case is obviously a decision for you to make, but figured I would bring it up.  For laughs, I threw together a new version of the project which uses this approach.  Here's what the app looks like:

I have attached the source project if you want to poke around.  I added test clients for the SOAP and HTTP bindings so you can push a message through the normal and test paths.

hth,

keith