About Features
This section is home to feature articles by regular and guest authors. Topics and opinions vary - some articles include discussions!
| Extensibility Features in BizTalk Server |
| Features - Feature Articles |
| Written by Erik Westermann |
| Friday, 20 February 2009 15:39 |
|
BizTalk's programming model is largely based on orchestrations that, when used in combination with maps for example, usually provide enough functionality for a range of problems. There can be cases when it is either difficult* or not possible* to represent a solution using BizTalk's stock toolset. BizTalk developers can extend it's functionality using C#, Visual Basic .NET, or any .NET-supported language. You package your code in an assembly (DLL), or Class Library project in Visual Studio .NET and reference it from your BizTalk project in Visual Studio like  you reference any other assembly (Select Project -> Add Reference from the Visual Studio menu). You can access your assembly's functionality using an Expression shape from the Orchestration designer toolbox.On hearing the great news that you can write your own code, most developers fire-up Visual Studio and happily start writing a bunch of code (after all, BizTalk uses a declarative approach. If you like code it is hard to resist an opportunity to be in control again by writing your own code). Before you do that, make sure that you really cannot express your proposed solution in BizTalk - and understand that you assume some risk when you write your own code. When I was learning C++ I got stuck on several problems along the way. I often found myself late at night sitting in front of my noisy 486-based system - its 200Mb hard drive spinning the bits of my solution at the same dizzying rate that I was going through ideas to try to solve my problems. On further reflection about the problem at hand I found that I was standing in my own way - I was not able to find solutions to the problems because my approach was wrong. I ignored the symptom (not being able to solve the problem) and instead focused on finding a solution. I easily came up with an effective solution the moment I changed the way I thought about the problem. My point is that I see a lot of developers immediately creating new assemblies, writing a bunch of code, and then calling that code through BizTalk. The presence of the code is often a symptom of not understanding the problem, not understanding BizTalk, or both. You need to keep this in mind if you to write some code as part of your BizTalk solutions:
The first point, about using serializable types, is easy to address: avoid using non-serializable objects! The great thing is that this is pretty easy to use serializable types since most types you use day-to-day are in fact serializable. You might be tempted to use some unconventenial approaches if you accidentally use a serilaizable type, or cannot avoid using one* . For example, if you look around the internet you might find some interesting ways to work around having to use serilaizable types by tricking the type system into serializing a non-serializable type - use those techniques with extreme caution. You have to mark your types (classes) serializable for BizTalk to accept them - just add the [Serializable] attribute to your class' declaration. The compiler will gently remind you with a cryptic error message if you lie forget and use non-serializable types anyway. The second point - you need to sign your assembly and deploy in the GAC - this is also really easy to address. Signing in this sense is actually to Strong Naming your assembly. You can use the Strong Name Utility (sn.exe) or use Visual Studio to sign your assembly. Deploying the signed assembly is also easy: just drag the assembly to the c:\windows\assembly folder (it goes there as a copy), or command line enthusiasts can use can use gacutil (gactul.exe). I have oversimplified the management aspect of strong naming and deploying assemblies into the GAC. One key management aspect is versioning - you can have multiple versions of the same assembly deployed in the GAC. While multi-version support solves a lot of problems, you need to become more deliberate in how you manage versions and deployment since you can end up with some hard to track down behaviours and bugs. You also have to think about configuration since using config files with assemblies deployed in the GAC is not easy. Although you can do just about anything you like in your custom assembly, you should carefully consider the performance impact of your code. For example, loading a huge XML document into an XmlDocument object will use a lot of memory, which can slow overall performance due to paging. You may also have to start thinking about threading - BizTalk is fast because it is multi-threaded. If your code manipulates any shared information (in memory, in a database, file, etc), you will run into threading problems. When you are writing your own code, try to keep it as lean as you can: use StringBuilder and streaming types, try to use math instead of procedural code whenever possible, and use compact representations of data even if that makes your code a little more complicated. Unit test your code to ensure that it works and become familiar with advanced debugging techniques since F5 debugging is not possible. Measure your system's performance and ensure that your code is as fast as possible; however, avoid optimizing without knowing whether it is necessary BizTalk is a robust system that's ready to handle a broad range of problems. In this article you learned about extending BizTalk Server's functionality using code you write. You learned about some considerations when writing your own code and learned about how to reduce the impact of the code you write. * - When something seems impossible, it is usually a symptom of incorrectly approaching the solution or having an incomplete understanding of the problem you're trying to solve (or both, at worst). You can more effectively address the solution when you understand BizTalk's capabilities - I have not yet come across a problem I could not solve using BizTalk. Gaining a complete understanding of the problem you're trying to solve is an exercise I'll leave to you. |
Newsflash
"The number of computer science majors enrolled at U.S. universities increased for the first time in six years..." |