- Itinerary to be started
- Transformation Type (thus, the name of the map)
- Endpoint (Set End Point Outbound Transport Location, e.g. Transport Type, Location, Action etc.)
This wonderful stuff can be done by doing BRI Lookups in the pipeline (executed in the ESB Pipelines using the ESB Dispatcher pipeline component) or even from within an itinerary (this applies for Transformation Type and Endpoint information off course)
One of the difficulties of this is that testing this is fairly cumbersome since tooling wasn’t readily available to do some automated testing….now there is!
Tool for testing BRI calls
My colleague IT Hero - Tomasso Groenendijk has created a very useful tool to do manual testing on BRI lookups. This enables you to quickly test rules and determine if the ESB information is correctly set. This is possible using a practical interface and comes even with documentation containing screenshots (yes that’s right….a tool, with code….and DOCUMENTATION!)
Automated unit testing BRI calls
As I was working on a quite large Rule set, I used the tool and thought it would be useful to create my unit tests with the tool by creating some helper classes…this made it extremely easy to do automated testing.
As the code is fairly simple I will point out the functionality of the tool and show screenshots of the unit testing features you could use it for:
private static void ValidateItineraryName(string pathToInputFile, string customer, string expectedItineraryName)
FileParameterReplacerStep fprs = new FileParameterReplacerStep();
fprs.FileName = pathToInputFile;
ESBRuleTester esbTest = new ESBRuleTester();
RuleContainer rc = new RuleContainer();
rc.FactType = RuleContainer.FactsEnum.Itinerary;
rc.PolicyName = "Policy.ESBResubmit.ItinerarySelect";
ItineraryContainer ic = esbTest.RetrieveItineraryContainer(pathToInputFile, rc);
Assert.AreEqual(ic.Name, expectedItineraryName, true, "The Itineraryname is not as expected");
Well, I’m sorry for not posting the code, although I hope this gives some ideas how to use the Tool and how to implement unit testing. In my case it was fairly easy to test about 25 itineraries automatically and isolated which had to be done otherwise by creating a lot of BizUnit steps that supplied messages on ports that were configured using test-bindings to simulate calls, and derive by verifying the output files that the correct itinerary was started.
Method: GetPathToDataFile(“”) this is implemented in a base TestClass and retrieves the path of the Unit test datafiles by determine the Assembly directory of the ‘TestResultsfolder’. I do this to make it easy to work with files
Class: ESBRuletester contains the functionality provided by the Tool, this created to enable testing from code instead of using a GUI
Class: RuleContainer, this is a simple class that contains usefull parameters
Class: ItineraryContainer (this is a simple data class that contains the results of the ItineraryFact, same structure is developed for testing EndPoint / Transform, this makes it easier to implement BizUnit validation steps.
Well, hopefully this helps in developing automated testing when developing functionality for the business rules engine and the ESB Toolkit.