Recently I was debugging an orchestration and found unexpected output from the map. The obvious decision was to use Visual Studio’s “Test Map” option. I opened the Map and realized that “Input” schema is a multi-part schema.
Combining two xml messages into one file will produce the multiple roots exception. So, I looked at the map’s source to figure out the structure. In order to view the map source, I simply ran “Validate map” and opened the generated xslt stylesheet.
The interesting part I found on the top of the schema was:
<?xml version=”1.0″ encoding=”UTF-16″?>
exclude-result-prefixes=”msxsl var s1 s0 userCSharp”
The aggregation schema
Here is the root
<xsl:apply-templates select=”/s1:Root” />
The catch statement
The Input message has to have the following structure in order to comply with the generated schema:
Here is the resulting message I came up with for testing.
You can find a dedicated page for BizTalk books on B&N!
Here is an example of a custom functoid method that converts an EBCDIC signed value to ASCII format:
Add a new C# class library project to your BizTalk solution and call it MyCompany.BizTalk.Functoids. Create a C# class in the project and use the same project name for the namespace.
/// Summary description for Utils.
public class Utils
Add the method to perform the conversion:
/// Convert EBCDIC signed values to ASCII format
/// <param name=”amount”>Amount to be converted</param>
/// <param name=”sign”>Signed Value</param>
public double ConvertFromEBCDIC(double amount, string sign)
amount = (amount / 10);
This post continues the series on creating custom pipeline components. The previous posts in the series can be found here: post 1, post 2.
In order to complete the exercise of creating the archive component, we need to add the code to actually perform the archival of the message. For this example, the requirements of the archive component is to persist an exact copy of the message coming into BizTalk (whether flat file, xml, binary or even an encrypted) in it’s original form to the local filesystem.
To start off, we need to create a method to write an inputstream to the filesystem outputstream. The following CopyStream method does this…
protected void CopyStream(Stream input, Stream output)
int BUFFER_SIZE = 4096;
byte buffer = new byte[BUFFER_SIZE];
bytesRead = input.Read(buffer, 0, BUFFER_SIZE);
I came across an article on CodeProject about creating a custom pipeline component for dissassembling incoming messages in zip formats. Even though it is implemented in 2004 version, it is still valid for 2006. It articulates well on how the custom pipeline is constructed in C# and how it can be deployed to a BizTalk solution.
One of the vexing problems when designing XML schemas for a BizTalk solution is to decide whether to promote a distinguished field or a property field. You can do both types of promotion using the Promote Property dialog box in BizTalk Schema Editor, but which one do you need?
Well, generally speaking, distinguished fields can only be used in the orchestration engine, whereas promoted property fields can be accessed through all phases of the BizTalk message processing, including orchestration, routing, pipelines, and of course custom code.
Behind the scene, the real difference lies within the implementation of these two types of promotions. For promoted property fields, BizTalk simply takes note of the XPath expression used to point to the property fields, whereas for distinguished field, the values of the fields are actually copied to the message context within the orchestration. The performance…
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…