Technical lessons in BizTalk Migration

1. Although SeeBeyond Collaborations can be translated to BizTalk Orchestrations, it makes better sense to separate an implementation into Orchestrations for business processes, Maps for data transformation, Business Rule policies for business logic, and Pipelines for low level message pre-processing. In a SeeBeyond implementation, the Collaboration is the main executive module where most logic resides - and all these sub-tasks are mixed together creating a delirious “code cocktail” we have witnessed first-hand. In BizTalk such collaboration can be cleanly split into functional modules which are easier to maintain.

2. Data conversion. Type system mismatch between Java and .Net, date and time formatting can be sources of subtle errors. For example, in Java the default DateTime string formatting is different from neutral culture formatted DataTime string in the .NET Common Type System. SeeBeyond code compare dates as strings which is culture specific in .Net, so it’s better to switch to a DateTime object.

3. Message size. In SeeBeyond messages are binary structures and strings. But all flat file and native messages entering BizTalk are converted into XML – blowing up their size 3 to 5, even 10 times! When these are mapped they are held in memory as is the transformed message – which is equally large perhaps. This can easily lead to performance problems due to memory pressure. One should pay close attention to the message size. Since messages in BizTalk are immutable developers may create duplicates in the orchestrations which will add to the memory overhead. Instead the BizTalk developer should chunk up the message into smaller (physical) sizes – as BizTalk is highly parallel and is best optimized for processing a high throughput of light-weight or medium-weight messages with remarkable speed – but the reverse (heavy messages and low throughput) is not true.

4. SeeBeyond’s data structures map pretty well to .Net typed DataSet. This fact can be used when converting component logic from Java to .Net. Entire structures can be mapped to a typed dataset which makes case for straightforward code conversion. There is a difference thoough – nullable types. .NET DataSet supports DbNull and this should be taken in account.

5. Centralized logging and tracing is critical in this type of mission. Microsoft Enterprise Logging Block or Log4Net library can help to tackle this task.

6. Sometimes it makes far more sense to engineer the logic in .NET components than BizTalk. Just because it’s a migration exercise does not mean BizTalk is a natural choice. A .NET library with a BizTalk wrapper can do the trick in many cases – do try to think out of the box when evaluating design.

7. Proper encoding should be used for data both in xml as well as in flat file formats. If this is not taken care of, it may result in output data mismatch and can lead to multiple test cycles and rework.

8. Automated test scripts also play a major role in making things easier since you must be prepared for many cycles of verification and overload testing.