Skip to Content

I would like to share some thoughts about my experience using Detroubulator, which was released at TechEd in Amsterdam earlier this year. See the link for more information.

I have been using Detroubulator for the last three months on a project.

My first thought about Detroublator, was that it would take a long time to test mappings and would not provide sufficient value for time spent on the test. I believe that I’m fairly good at building messages mappings and verifying contexts. At AppliCon we use a few well-tested standard functions to handle selection based on qualifiers, and I was fairly confident about using them.

The working process I have used with the tool is the following:

  1. 1. Create the mapping based on the specification
  2. 2. Document the mapping and correct potential errors.
  3. 3. Go through the mapping and create test cases that can potentially break the mapping contexts.

It is primarily errors related to context changes, that I am looking for. Therefore most of my tests include three lines. Line 1+3 contains the item while line 2 doesn’t. If the context is incorrect, then line 2 will be completed instead of line 3. When I find an error, I correct it. Correcting an error essentially means making the corresponding test no longer fail. I also try to find places, where I have used UDFs which perform string manipulation or calculation.

The conclusions from using the tool in real-life projects are the following.


  • I have found quite a lot of errors with the tool, because using the tool forces you to go though the mapping systematically. This definitely helps the detection rate.

  • I have also tested some XSLT mappings. Here the test also found some problems in the mapping, but it was more the test performed which gave those results. Detroubulator was not as effective to find errors in XSLT mappings, because the flexible use of XPath and for-each, mean there are fewer context problems.

  • The real value of Detroubulator comes when a developer at a later point has to change something, which would not break the rest of the mapping. It could be changing some of the shared functions or something with contexts on lines. Having a test suite has saved my butt quite a few times, and therefore is definitely worth the time.

  • When the mapping has to be changed, the test cases have to be updated to reflect the new mapping. If the mapping has a lot of changes many of the tests can be discarded. It is therefore crucial that the specifications is right the first time. One alternative is to wait with creating the test cases until the mappings has been verified. That means, however, that the business users have to test a mapping with potential problems. I believe that this must be judged on a case by case basis.
  • I need a larger screen on my laptop to contain both the test document, input documents and dumps together with mappings ๐Ÿ™‚

I recently had to make a change in a mapping at a customer site, where the mapping was created prior to Detroubulator’s development. That meant that I had to rely on the test functionality of the Integration Builder. I therefore did not have any confidence, that the change did not spoil anything. It is interesting that after using Detroubulator for just three months, I see it as a must-have in that situation.

I hope that other users will start using Detroubulator and also contribute to the development of the tool, to make it even better.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply