The Biztalk Deployment Framework is an extended support system for deploying Biztalk solutions. Why do you need this? Out of the Box Biztalk can be packaged up into an msi which is imported and installed through the administration console. That msi will contain your orchestrations, maps, pipelines and ports. what it won't install is your configuration, your business rules policy, your host instances, your webservice. External assemblies? Good luck. BAM artifacts? You're on your own.
The Biztalk Deployment Framework is Biztalk Deployment as it should be. Setting it up is not a one click operation. There's xmls to configure but it makes deployment one click and it has good documentation.
The BRE(Business Rules Engine) is one of the most fascinating components of Biztalk. An entire system to itself it allows complex logic to be executed via IF THEN conditions. It can loop, recurse or "forward chain". All your conditions are placed in a policy, which is how Biztalk categorises its sets of conditions. However one thing to note about BRE policies is they are immutable. Once published on the server they cannot be altered, only a new version created and then published in its place.
Of course that's not entirely true. You can unpublish policies from Biztalk, though it's recommended you shouldn't outside of a development environment. Nevertheless if you want to go ahead and clean up the old versions, here's how.
Connect to your Biztalk DB through SQL Management Studio. Your policies can be found with:
Once you identify the policy version you want to unpublish use:
SET nStatus = 0
WHERE strName = 'MyPolicy' AND nVersion = 'myVersion'
with your name and version.
If you have the composer open while you do this, be sure to refresh in order to see your changes.
You can do this with vocabularies too! They're in [BiztalkRuleEngineDB].[dbo].[re_vocabulary].
Now here's where it gets a bit tricky. There's a few components which go with Biztalk, some of them are systems in themselves.
The Business Rules Engine
Biztalk's own logic engine, the BRE contains rules policies which are called to act upon xmls and can perform a wide variety of operations. The BRE works differently to anything else I've seen from Microsoft. Each rule consists of conditions and if those conditions are found true actions are taken on facts. The BRE requires a logical programming mindset, which can be difficult to adopt unless you have a Prolog developer on your team.
The Biztalk Xref Database
The Xref database is a limited value translation database included as part of Biztalk. The primary advantage it has is its data is cached, giving it a big speed boost over standard database lookups. It is incorporated in the form of functoids allowing the translations to be made on Biztalk maps.
The ESB Toolkit is part of the error handling framework for Biztalk. It allows for the capturing of failed messages, reporting on their errors and even their resubmission to the Biztalk message queue. Personally I've found a lot of bugs in the out of the box software. The ESB requires the commitment to develop it as another system.
The Business Activity Monitor
A reporting solution for Biztalk. BAM consists of two main components. Activities which are essentially databases containing all the data you track on messages, and tracking profiles, which determine the relationship between orchestrations, messages and activities.
The Administration Console
Often forgotten, the Admin console for Biztalk is its own MMC snap-in which allows for visual monitoring and interaction with Biztalk applications and the message queue. The Console has its bugbears, its slow due to having to query the database constantly but its usually the first place to look for problems. One important thing to remember is anything that can be done through the Admin console can be done via command-line as well. The Console should be for extraordinary cases, not the first option for deployments and startups.
This is but the briefest of introductions and I'm going to write some more on them soon.
I’ve seen this error pop up a lot when using the DB2 Adapter for Biztalk 2010:
The parameter value for parameter 23 could not be converted to a native data type.
After days of testing and retesting different kinds of data and fiddling with maps there’s one thing I recommend you do to fix it.
Constrain your schema. The xsd you generate off of your DB2 table will likely contain a series of strings and decimals. Rather than just accepting this I’d recommend adding simpleType restrictions to bound the max length of the xml fields to the max length of the DB2 fields. Doing this keeps the DB2 Adapter from getting confused and generating invalid insertions/updates.
Biztalk is something I've used quite a bit in both its 2006 and 2010 variants. It has its benefits and its drawbacks. So I thought I'd break down my understanding of its components as a reference.
A schema in Biztalk is an xml schema, that is an xsd. Schemas are fairly straightforward. Their job is to act as the template for xmls you receive and process in Biztalk.
There are receive and send ports in Biztalk. Their job is simply to transmit and receive xmls. Where ports get interesting are their types and the components you can connect to a port.
A port type determines its interaction with an outside system. You can have a file port, which consumes xml files or outputs them. You can have a web port, connected to a web service that processes requests. Then there's SQL ports which allow you to turn xml into an SQL query and run it on a server. You can have e-mail ports, FTP ports, even MSMQ ports.
The other neat feature of ports are components hanging off them. Ports can have maps, which we'll get to soon, connected to them directly which allow you to immediately transform xmls coming in or going out. Why is this great? Well if all you need is to turn one xml into another you can build a map, connect it to a port and call it a day. Ports also use pipelines which can do all sorts of crazy things. In fact let's jump to them next.
Pipelines are an area I haven't worked much. I know what they do, they transmute the incoming data and dissassemble it for reading by the other components. I also know you can build custom pipelines that will do other things on the incoming message or make calls to external libraries and log or change data. You could essentially build your entire application into a pipeline, though that might make it unreadable.
Maps are the meat of xml transformations. To set up a map you give it a source and destination xsd. Once deployed you feed it xmls of the source type and it outputs xmls of the destination type. So what? XSLTs do that and a map is, if you look in the code behind, just an XSLT. However what a map does is provide a visual layer that makes it easier to see what's going where. Maps also have functoids which are visual shorthand for script functions allowing you to do things like concatenate two fields into one, add today's date to a field or even do a database lookup for a value.
Orchestrations are the highest level of a Biztalk Application. An orchestration contains the logic that dictates what to do and where to send messages. Orchestrations generally receive messages from ports, transform them with maps and then send them out on ports. That's simple orchestration. Complex orchestrations can call other orchestrations, decide where to route messages or what transformations to apply, they can even perform send/receive requests where they contact external services to do something with the content of a message. Orchestrations are about bringing all the other components together and doing something interesting with them.
Next time I'll do some introductory blurbs on the components that can hang off a Biztalk Server like the Business Activity Monitor.