Lets just recap on the solution we have now:
This completes the first part of the solution: receiving the message using webservice, transform it to a mail body and store it as a text file.
Adding the Event Driven Consumer
We want to add the consumer to our integration that listen for new files, we do this by creating a private method where the consumer code lives. We must register our consumer in Camel before its started so we need to add, and there fore we call the method addMailSenderConsumer in the constructor below:
The consumer needs to be consuming from an endpoint so we grab the endpoint from Camel we want to consume. It's
The URL configuration in Camel endpoints is just like regular URL we know from the Internet. You use ? and & to set the options.
When we have the endpoint we can create the consumer (just as in part 1 where we created a producer}. Creating the consumer requires a Processor where we implement the java code what should happen when a message arrives. To get the mail body as a String object we can use the getBody method where we can provide the type we want in return.
Camel Type Converter
Why don't we just cast it as we always do in Java? Well the biggest advantage when you provide the type as a parameter you tell Camel what type you want and Camel can automatically convert it for you, using its flexible Type Converter mechanism. This is a great advantage, and you should try to use this instead of regular type casting.
Sending the email is still left to be implemented, we will do this later. And finally we must remember to start the consumer otherwise its not active and won't listen for new files.
Before we test it we need to be aware that our unit test is only catering for the first part of the solution, receiving the message with webservice, transforming it using Velocity and then storing it as a file - it doesn't test the Event Driven Consumer we just added. As we are eager to see it in action, we just do a common trick adding some sleep in our unit test, that gives our Event Driven Consumer time to react and print to System.out. We will later refine the test:
We run the test with
Sending the email
Sending the email requires access to a SMTP mail server, but the implementation code is very simple:
And just invoke the method from our consumer:
Unit testing mail
For unit testing the consumer part we will use a mock mail framework, so we add this to our pom.xml:
Then we prepare our integration to run with or without the consumer enabled. We do this to separate the route into the two parts:
So we change the constructor code a bit:
Then remember to change the ReportIncidentEndpointTest to pass in false in the
Adding new unit test
We are now ready to add a new unit test that tests the consumer part so we create a new test class that has the following code structure:
As we want to test the consumer that it can listen for files, read the file content and send it as an email to our mailbox we will test it by asserting that we receive 1 mail in our mailbox and that the mail is the one we expect. To do so we need to grab the mailbox with the mockmail API. This is done as simple as:
How do we trigger the consumer? Well by creating a file in the folder it listen for. So we could use plain java.io.File API to create the file, but wait isn't there an smarter solution? ... yes Camel of course. Camel can do amazing stuff in one liner codes with its ProducerTemplate, so we need to get a hold of this baby. We expose this template in our ReportIncidentEndpointImpl but adding this getter:
Then we can use the template to create the file in one code line:
Then we just need to wait a little for the consumer to kick in and do its work and then we should assert that we got the new mail. Easy as just:
The final class for the unit test is:
End of part 3
Okay we have reached the end of part 3. For now we have only scratched the surface of what Camel is and what it can do. We have introduced Camel into our integration piece by piece and slowly added more and more along the way. And the most important is: you as the developer never lost control. We hit a sweet spot in the webservice implementation where we could write our java code. Adding Camel to the mix is just to use it as a regular java code, nothing magic. We were in control of the flow, we decided when it was time to translate the input to a mail body, we decided when the content should be written to a file. This is very important to not lose control, that the bigger and heavier frameworks tend to do. No names mentioned, but boy do developers from time to time dislike these elephants. And Camel is no elephant.
I suggest you download the samples from part 1 to 3 and try them out. It is great basic knowledge to have in mind when we look at some of the features where Camel really excel - the routing domain language.
From part 1 to 3 we touched concepts such as::