I was thinking a little ‘tongue in cheek’ when I came up with the title for this one. To add to the growing number of “Seven Habits” resources, I’ll add one on BizTalk. I wouldn’t say I was a “Highly Effective” BizTalk developer, but I have picked up a few habits that seem to improve the way I work with the product.
1 One-Click Deployment
This topic has been covered in quite a few articles and blogs. Personally, I use the NAnt deployment script, developed by Scott Colestock. I sometimes create a “Quick NAnt Deploy” script, and add a task to the menu and use it when I am modifying a small part of the project. Even with a deployment and build script, it can sometimes take five minutes to run through everything, with a simpler script it can take a minute to deploy part of a project.
When working with modifications to an orchestration, it’s possible to re-GAC the orchestration dll, and then restart the BizTalk host that hosts the orchestration. The following batch script is an example:
REM GAC BizTalk dll
C :\WINDOWS\Microsoft.NET\Framework\v1 .1.4322\gacutil /
if bin\Development\TransformHub.dll
REM Restart BizTalk Server
net stop "BizTalk Service BizTalk Group : BizTalkServerApplication"
net start "BizTalk Service BizTalk Group : BizTalkServerApplication"
PAUSE2 One-Click Testing
I’ve seen a few posts and questions about automated testing for BizTalk applications, but have not seen any real implementations. I’ve started to look at this, and have been building automated tests for my current project.
A simple one-click test can be created by writing a batch file that will drop a number of test documents in the target folder for a file adapter. It’s easy to run this test after a build, or modification, and check that no orchestrations get suspended, and that the output messages are as they should be.
When working with other adapters, such as SOAP, SQL Server, or MQ Series, creating a test may require developing a test framework. I followed the testing guidelines on the Enterprise Integration Patterns site, and created the test framework as a C# project. This was able to create documents from XML templates, validate the output documents, and also interact with a database.
Stress testing is also important, especially when using the SQL adapter for database updates, as there can be problems with transaction deadlocks. For batch file driven testing, you can create a folder, and place 1,000 or so documents there, the batch copy them into a target folder. With a C# test framework you can use a for-next loop to create a large number of messages.
Before stress testing a BizTalk project, make sure you have set up all the BizTalk database cleanup and backup tasks in SQL Sever. (But you did that straight after the install, right ;-).) If this is not done, your message box, or tracking database will start taking over all your hard drive space.
3 Prototype Outside the Project
I’ve always recommended prototyping outside the project as a good way to solve problems. With BizTalk projects, I find it even more beneficial.
When working on a medium or large project, trying to implement a new idea or unfamiliar technique can often take far longer then expected, and results can be messy. Worse, it can disrupt other developers on the team, break the build, or leave the project in an unexecutable state.
Creating a small prototype project that focuses on a specific idea or technique has several advantages:
- The code/build/deploy/test/undeploy/fix cycle is much shorter
- The prototype can be focused on one specific problem
- The prototype is disposable, if it gets messy, throw it away and start again
- You can experiment with the techniques, trying things you would not try in a production project.
- When you have solved the problem, you can implement it quickly and cleanly in a larger project.
- You build a resource of prototype projects to share with your team.
I have probably created over a hundred small projects when I needed to get my head around new ideas. It’s good to be able to dig them up, and play around with them when I need to.
4 Follow the Patterns
The Enterprise Integration Patterns book and website provide a great resource for integration architects and developers. The patterns and ideas are not specific to BizTalk, but then integration projects are rarely specific to BizTalk. Quite a few of the patterns are provided out-of-the box with BizTalk, but a lot of the message processing patterns require implementation in an orchestration.
It’s a good learning experience to implement a simple aggregator, or resequencer as an orchestration. It’s also valuable to use “Enterprise Integration Pattern Language” within a project, often your dealing with a lot of other systems, outside the Microsoft world, and it helps if everyone knows what a splitter, or a wire-tap is.
5 Learn to Debug
I’ve spent quite a lot of time debugging orchestrations, and discovered a few techniques I use, as well as the standard tools.
Event Viewer
The event viewer is usually the first place to look when something goes bad in an orchestration. It’s quicker and easier than starting HAT, but does not provide too much information.
BizTalk posts errors, warnings, and information to the Application section of the Windows event log. The text of these events give you a good indication of the error that occurred, such as an XLANG/s error, or undefined reference error. Often this can be enough to figure out what you have done wrong. What it won’t tell you is where the error occurred in the orchestration.
HAT
HAT provides a view of the messages, and orchestration instances (Service instances) that are present in the message box, and tracking databases. As it’s specific to the BizTalk databases, and not the server where the orchestration was run on, it’s great for use in multi server environments.
HAT also provides the option to save tracked messages, and to view orchestrations in an orchestration debugger.
System.Diagnostics.Debug.WriteLine
Use the System.Diagnostics.Debug.WriteLine method in your orchestration code, then attach Visual Studio to the BizTalk service (Tools -> Debug Process -> BTSNTSve.exe, and check “Common language runtime”). You can then view the debug trace in the output window.
This is great for checking on the flow of an orchestration, and getting a dump of all the orchestration variables, and messages. You can dump a message by assigning it to an XmlDocument object, then dumping the OuterXml of the document.
testXmlDocument = InputMsg;
System.Diagnostics.Debug.WriteLine (testXmlDocument.OuterXml)Performance Monitor
PerfMon is good when you are running stress tests, or optimizing orchestrations. It can also give you a good insight into what is going on in the orchestration engine. Looking at the number persistence points for a complex orchestration can be a good way to target performance bottlenecks. I usually create a PerfMon tamplate with several of these counters, so I can quickly monitor the application.
The full list is here: ms-help://BTS_2004/SDK/htm/ebiz_prog_orch_nfup.htm
XLANG/s Orchestrations
Orchestrations completed, Orchestrations created, Orchestrations resident in memory, Orchestrations suspended
These are great when you are sending a batch or messages to an orchestration, and want to see the progress of the orchestration instances. HAT can give you this information, but with PerfMon, it’s displayed real time, and as a graph, (HAT can sometimes get slow when your box is under heavy load). You can also take a coffee break or lunch, and see how things went when you get back.
Persistence points, Persistence points/sec
The number of persistence points an orchestration makes as it executes is important, especially if you have large messages or orchestration variables. I usually check this, make changes to the orchestration, then test again. The number of points per second can give some indication as to the amount of data that is being persisted, as the message size gets larger, this will decrease.
BizTalk:Messaging
Documents received, Docuemnts processed, Docuemnts suspended
These counters can be used in much the same way as the orchestration counters, but provide statistics on messages.
6 View the Source
I posted about viewing the XLANG/s of an orchestration a while back, and I have used this technique quite a lot. I usually rename the file to C# (I like the color coding for comments), and chop out the attributes and XML stuff.
With a complex orchestration, the code is hidden in the shapes, and it’s hard to spot exactly what goes on inside. The code view is great when you want to optimize things, check for unused messages, or spot bugs that are caused by code in different shapes.
Another good use is when building a new orchestration based on a pattern from an existing one.
7 Join the Community
Last but not least, get connected with other developers.
Blogs
If your reading this, you probably know about the BizTalk blogs that have been popping up over the past year or so. I found them a great help when I was getting into BizTalk, and I keep a list in my favorites that I go through every day or so. Running your own blog gives you the chance to share your ideas with others, and get feedback on any possible improvements to certain practices.
News Groups
The Microsoft communities are also good, you can learn a lot reading the discussions and posts, and get good answers to questions. You also learn a lot by answering posts, and thinking about how to solve problems.
User Groups
Local BizTalk or .net user groups are a great way to meet other developers, it’s valuable to spend time chatting to people, and there’s often good tech oriented (as appose to marketing oriented) presentations.
The Enterprise Integration Patterns Site can be found here.
