EI Challenge #2

EI Challenge #2

The second biggest challenge that we encounter on all EAI projects is testing. Testing something that is essentially a magic black box with messages coming in at one end and out the other is already something of a challenge. When you add to that the fact that you are likely interfacing with multiple other systems, on multiple platforms, and using multiple protocols, you now have a huge challenge on your hands. How can you test that something that came out of SAP, came through BizTalk, got transformed, validated and encrypted, had business rules applied to it, and then was routed to be consumed by an external system actually created the expected results? How do you find out if something wasn’t quite right along the way? Where did it happen? How do you correlate the incorrect results in the target system with the actual transaction that came out of SAP and every other step in between?

Simply put, this requires a lot of planning. Right from the requirements gathering phase, you must identify what will need to be tested and how you will validate the end results. You must also plan your architecture and design to support testing. This usually involves using some kind of transaction ID that you can use to correlate messages from source to destination. This may sound trivial, but a lot of systems do not support such an externally generated ID, and you may not have the option of changing those systems. You may have to resort to the creative use of an unused data field, or some auditing mechanism that stores both your transaction ID and the system’s corresponding ID.

For projects of any significant size you should also plan on developing some tools to help you with the task of correlating messages and validating what happens to them (their state) at each step of the process. You should be capable of injecting and inspecting messages at all stages of the process. You should also design the system so that tracing can be turned on or off at multiple levels of detail to support various levels of testing and troubleshooting. BizTalk already offers some tools like HAT to help you with this task, but HAT doesn’t bring in data from the external processes nor does it provide a mechanism to correlate with that external data.

In summary, testing a complex BPI solution is a challenge, but one that is not insurmountable if you plan for it ahead of time. Just like a solution architect should always wear his/her “security hat”, s/he should also wear a “testing hat” throughout the life of the project, from envisioning to deployment. Failure to properly plan, architect, and design the solution with testing in mind will result in serious difficulties and delays in the latter part of the project, and even throughout the system’s useful life.

No Comments