I was recently helping one of our clients parse a record-based flat file where the records are mostly positional identified by a tag. The issue was that the flat file was a credit card transaction log where each record, identified by a tag, is a sibling to the other records with no specific order in which the records appear. Such a scenario cannot be handled by an “out of the box” usage of the FF wizard. This series of postings will focus on explaining how BizTalk Flat File schemas are structured, analyze the output of the FF wizard and how to customize it.
BizTalk handles Flat Files through the use of flat file extensions defined within schema annotations (more about annotations…, more about flat file extensions…). A receive pipeline component known as a Flat File Disassembler (or assembler for the send counterpart) can act on these extensions to parse an…
Recently, a company in the process of implementing BT 2006 within their enterprise asked me for a recommendation regarding best practices for a pre-existing usage scenario they were seeking to accommodate using BizTalk. This company receives, on a reoccurring basis, a variety of disparate inbound flat file business documents which, at present, are processed into their suite of business applications using SQL Server DTS. While the interchange with this company in question has CERTAINLY inspired folks at BlogBizTalk and Tallan to start developing a whitepaper comparing and defining best-practice usage and design considerations for implementing SSIS (or equivalent ETL tool) and BizTalk both in scenarios of consonance or autonomy, a few much more immediate considerations arose for my address.
One such very much more low level consideration was that for the handling of the disparity of received file formats. My understanding…
In the previous post we started creating the c# class that implements the interfaces needed to develop a custom BizTalk pipeline component. In this post, we continue with this sample…
The next interface we will implement is the IPersistPropertyBag interface. Before we do that, we need to add two generic utility methods to read to & write from property bags. A property bag is an object which can persistently save its properties. MSDN provides more info on the Microsoft.BizTalk.Adapter.Framework.PropertyBag class.
#region utility functions
/// Reads property value from property bag
/// <param name=”pb”>Property bag</param>
/// <param name=”propName”>Name of property</param>
/// <returns>Value of the property</returns>
private object ReadPropertyBag(
Microsoft.BizTalk.Component.Interop.IPropertyBag pb, string propName)
object val = null;
pb.Read(propName, out val, 0);
This is the first post in a series on how to develop custom pipelines and incorporate advanced functionality. The final example will allow the reader to incorporate PGP decryption on the receive sid and encryption on the send ports.
A custom pipeline component is just a plain .NET class that implements several BizTalk interfaces. I recommend creating a seperate c# project to contain just your custom pipeline classes.
In this post, I will go through creating a sample pipeline component that archives the incoming message to the file system at the Decode stage
To get started, create a standard C# Class Library project.
Add references to the following:
Microsoft.BizTalk.Messaging (C:\Program Files\Microsoft BizTalk Server 2006\Microsoft.Biztalk.Messaging.dll)
Microsoft.BizTalk.Pipeline (C:\Program Files\Microsoft BizTalk Server 2006\Microsoft.BizTalk.Pipeline.dll)
Add your namespace and the following namespace directives…
In the BizTalk Pipeline component, often times you need to construct new messages out of the received messages in the Disassemble stage before passing them on to the orchestration. This can be done in a few different ways.
The easiest way is to build a concatenated XML string using StringBuilder or something similar, and load it into a new XmlDocument object. However, this is very inflexible. If the structure of the message is changed, the Pipeline component would have to be recompiled and redeployed. Another approach will be to load the XML strings from a configuration file at runtime, or keep it as a separate resource file to be loaded at the runtime. This approach avoids the recompilation process when the XML structure is changed, but you still have to worry about keeping the external XML file in sync with the…
Recently, I had the opportunity to help one of our company’s developers through some training exercises for BizTalk 2006 development. In that process I encountered what I considered to be a fantastic solution sample that I wanted to share with the BizTalk community should anyone be in a similar Trainer / Trainee situation or simply looking for a good example to demo to a technical audience regarding the power of BizTalk messaging and orchestrations. However, should the case be the former, you would be hard pressed to find a solution example that better illustrates to a developer who has a good handle on messaging but needs to be introduced to some of the more complex, advanced topics in Orchestration development.
In the circumstance I encountered, the developer was reviewing the use of envelope schemas for the purpose of dissecting composite messages…
One of the questions I was recently asked in the seminar we gave in NY a few weeks ago is whether it is possible to merge links and functoids from multiple pages into one page in the BizTalk mapper (without having to delete and redefine). I never came across such a request but my first reaction was to edit the xml source of the .btm file and it was really easy to get around. The schema is pretty simple defining source and destination schemas, pages, links and functoids. Moving the links and functoids around is just a matter of copying them under the target page.
In summary, all you have to do is Right-Click the map in your solution explorer and select “open with…”, select the standard VS XML editor and you’re all set.
My source xml looks like:
<Page Name=“Page 1“>
BizTalk Orchestration Designer is the core tool for laying out components representing business processes, and connecting them with logic operations when designing BizTalk applications in Visual Studio. Behind the scene, the XLANG compiler actually generates C# source code before compiling it into .NET assemblies. If you ever want to look under the hood and view the C# source, here is a little trick.
Use your favoriate registry editor (I simply use RegEdit.exe), go to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0. This is where some key properties of Visual Studio 2005 IDE are stored. Add a DWORD value named “GenerateCSFiles”, and set the value to 1.
Next time you launch Visual Studio to open a BizTalk project with orchestration files (.odx file) in it, click on the “Show All Files” icon in the Solution Explorer after the project is built. You will see along side with your abc.odx…
We always enjoy giving presentations and seminars on BizTalk 2006 and show IT and business stakeholders what BizTalk can do for their business. Last week was no exception with our Tallan Fall Seminars series.
In both events we had a focused group of companies/individuals who were mostly looking into adopting better ways to manage their integration processes. The goal of the seminars was to introduce BizTalk and give simple demos on how to perform message integration as well as business process modeling using orchestrations in BizTalk. If you were one of the attendees and want to learn more on how we can help you, contact us for more information.
The presentation from the NYC event can be found here.
I had a tremendously frustrating experience recently configuring BizTalk Server 2006, but I walked away from the situation a little wiser. We wanted BizTalk Server on an Application Server communicating with a seperate Database Server running SQL Server 2005. I have performed multi-server environments before, but the vast majority had been installation and configuration on a single server (BizTalk and SQL Server on the same machine).
Having created the Domain Groups and Domain Accounts which were required, we set about to perform the Custom Configuration. The BizTalk Server 2006 Configuration Helper is a huge improvement when it comes to configuring BizTalk: a much cleaner interface and the ability to configure each service seperately. However, when we attempted to configure the BizTalk Group or Run Time configuration, we consistently saw the Red Warning Icon when we entered our Domain Group Names.
Initially, we were convinced…