Posts

Of late I have been spending most of my free time (which isnt a great deal) with pipeline components. BizTalk pipelining is very intriguing and potentially a powerful tool in any BizTalk developers toolkit. Pipeline component development like most BizTalk related development, seems to involve allot of boilerplate code. Others have tried to counter this with VS.NET wizards (eg. pipeline component wizard, adapter wizard, etc). For some reason I just dont like these…they are a little heavy for my needs. ...

BizTalk’s tracking capabilities are a wonderful diagnostic feature when in thick of core BizTalk development work, or when a curly situation raises its head in a production environment. Typically when involved with BizTalk development it is not uncommon to find yourself integrating with COTS (Commercial Off The Shelf) products. Participating systems can (and do) deviate from the agreed contracts, sometimes in ways never foreseen. Doing integration between business units and their systems is a political hotspot when things go wrong; being able to identify the cause of an integration problem quickly is crucial. BizTalk tracking can be easily switched on and off at runtime, at both the port and orchestration level. The actual information (message bodies and/or context properties) and the granularity (pre and/or post processing) of tracking can be easily controlled using the administration console. ...

This semester I have enrolled in a security unit at my local University. Before we get into the mechanics of modern security techniques (mathematical theory, ciphers, protocols, hashing, Kerberos), the first lecture kicked off with a gentle overview of PKI and the basics of using the GNU Privacy Guard, aka GnuPG or GPG for short. In short it is a complete and free implementation of the OpenPGP standard. Generate a key pair: ...

The other day I built a schema that was the cause of much confusion and time wasting. Basically the tiny schema was being used by a centralised error handling process, that was designed to subscribe to and publish errors. The schema had a number of child elements, two of which were named “message” and “source”. Each field in the schema was distinguished (not promoted) to allow participating orchestrations to examine and/or manipulate the error message instances. ...

Today I was preparing to do some maintenance work, and while studying the relevant maps and schemas discovered a very unusual looking map—unusual to me anyway. I have included the XML source definition of the map below for reference. The source definition of the map was an aggregation of two schemas. That is, the source definition had two root elements InputMessagePart_0 and InputMessagePart_1 which contained XSD imports of two schemas. The thing that took me by surprise was that the source definition of this particular map was not actually explicitly defined through a “wrapping” schema definition. Instead the actual details of the aggregation was defined and stored in the map definition itself, under the target namespace of: http://schemas.microsoft.com/BizTalk/2003/aggschema ...

Publishing BizTalk orchestrations (or schemas) as Web Services is a wonderful thing. A neat little code generator known as the BizTalk Web Service Publishing Wizard accompanies the standard suite of BizTalk development tools, and basically plumbs up a classic (asmx) web service that inherits parts of the BizTalk object model. The web service must be hosted-and-execute on a BizTalk Server that holds the “exposed” orchestration. It then becomes a simple affair of defining a SOAP Receive Location that binds to the generated web service. ...

In the process of maintaining some existing maps, I interestingly came across the following error message, whenever I attempted to build the associated schemas project. Node node name - Specify a valid .NET type name for this root node. The current .NET type name of this root node is a duplicate. When I opened the offending schema (which contained a number of imports) using the BizTalk mapper in VS.NET, the schema did indeed appear to contain repeating (or duplicate) nodes. After digging a little deeper by manually studying the schemas using a simple text editor notepad2, in-fact discovered that the schema definitions were sound. The mapper was misbehaving. After a quick google, soon located the official knowledge base article KB922431, including a hotfix and analysis of the problem. To get the hotfix a request must be submitted to Microsoft Online Customer Services. ...

Log Parser: An elegant utility that does all the real grunt work. It is well worth spending some time with this guy as it will come in handy for other unexpected situations, like analysing your web server logs, or parsing through custom CSV files etc. Microsoft Office 2003 Web Components: Some COM components that provide for graph generation of the statistical data. Performance Analysis of Logs: A script that automates the “leg work” involved in real-world performance analysis, such as managing the set of counters to be used for particular situations (eg. BizTalk 2006 analysis), invocation of log parser to do the actual analysis of each counter, detection of threshold breaches when things seem to be fishy. PAL is implemented as a VBScript, and comes with a little .NET WinForm GUI which can be (optionally) used to setup the arguments to be fed into the VBScript. The result, a comprehensive HTML report complete with alerts (threshold breaches), graphs and explanations. ...

When ingesting (importing) BizTalk application bindings between different environments/machines it is important that its dependencies (hosts, host instances and adapters) are setup before running the import. Otherwise you run the risk of getting the following somewhat misleading error message: Failed to update binding information. The following items could not be matched up to hosts due to name and/or trust level mismatches: Item: ‘FILE’ Host: ‘MyBizTalkHost’ Trust level: ‘Untrusted’ You must do one of the following: ...

Last week I had to rebuild a BizTalk 2006 development box, running Windows Server 2003 R2. Im not sure where or how the base image came about, but through installing BizTalk I hit a number of interesting snags, all relating to not having a functional Distributed Transaction Coordinator or MSDTC; commonly employed for managing transactions across distributed resources. OK, so the basic “installation” procedure ran fine. That is the necessary files to facilitate a functional BizTalk Server were copied and registered without error. Running the BizTalk Configuration tool to actually get the various pieces working together were where things were halted to a stop. ...