It sounded better in my head. Honest.
May 14th, 2008 Scott
I previously talked about using XPath expressions in an orchestration in BizTalk Mapping Tips 01. I have recently discovered that you do not always want to wrap your XPath expression within a string() function. You only want to use the string function when you want to retrieve the text value of an XML node. You want to omit the string function if you are trying to set the value of an XML node.
So, to get a value you want your XPath expression to look something like this:
myVar = xpath(myMessage, "string(/*[local-name()='MyRootNode'])”);
To set a value, your XPath expression should look something like this:
myVar = xpath(myMessage, "/*[local-name()='MyRootNode']”);
Posted in BizTalk, Technology | No Comments »
May 12th, 2008 Scott
Here is a handy little mapping trick I happened to stumble over. In BizTalk 2006 and later, if you are using a map from within an orchestration you can use multiple input schemata and map them to a single output schema. For example, you can combine a source XML file with the results from a web service call and map them into a single destination schema.
To accomplish this, you will need to define a message for each schema inside of the orchestration. From there, double click on a transform shape in the orchestration designer. On the transform configuration screen, choose to configure the source messages and add a row to the list for each input message you want to add to the map. In my example you can see I have added a row for MySource and OtherData schemata.

Then define the destination message and check the “Open map in editor” box before clicking OK. The map editor will open, and you should see all of your input schemata defined on the left side of the map editor.

From there you can drag links to nodes and use functoids as you would for any other map. Note you can also use this setup to configure multiple destination schemata.
Posted in BizTalk, Technology | No Comments »
May 9th, 2008 Scott
I have been doing a fair amount of EDI mapping on my latest gig, and I wanted to share a neat trick I figured out for mapping 856 Advanced Shipping Notice transactions. What makes an 856 special is that all of the action takes place in one looping segment that contains a number of child segments. The fun part is that you need to use a different subset of those child segments in each loop iteration. For example, the first iteration you need to map data to the PRF, DTM and N1 segments. The second and third iterations map data to the LIN, SN1 and PID segments. The final iteration maps data to the TD1, TD5 and SAC segments. Anybody who has used the BizTalk mapper realizes that to map something like this you can not just drag a link from the source schema to the destination schema in the designer.
My solution to this problem came to me when I figured out that you can declare variables inside of one scripting functoid, and manipulate them from within another scripting functoid. I use two scripting functoids along with a looping functoid to control the number of loops that are created in the destination instance. The first scripting functoid contains the following C# code:
int _counter = 1;
public string Increment()
{
_counter += 1;
return "";
}
This code declares the loop counter, and increments it for each loop iteration. The second scripting functoid contains this code:
public int GetCounter()
{
return _counter;
}
This code returns the current value of the loop counter to the other mapping elements. Now you might be wondering why I did not combine the code into a single functoid. That is what I initially tried to do, but I discovered that for every output link, the scripting functoid evaluates its code. This causes all kinds of strange things to happen inside of the map. By separating the code into two functoids, I can control when the counter gets incremented.
To finish up our 856 map, we combine the loop counter with a set of logical functoids that will determine which nodes get mapped during each loop iteration. The logical functoids can be used to test for a specific loop iteration, or used to test for a certain range within the loop iterations. By dragging output links from the logical functoids to the segments that need to be mapped for the respective iteration, the segments will be created when the functoid evaluates to true and will be suppressed when the functoid evaluates to false. From there you can map the rest of the data using whatever combination of links and functoids works best. In the end you end up with a map that looks something like the image below. (Click on the image for a bigger version.)

Do you have questions? A better way of solving this problem? Please share it by leavinga comment.
Posted in BizTalk, EDI, Technology | No Comments »
May 7th, 2008 Scott
Just wanted to share a little bit of BizTalk trivia. BizTalk 2006 added the ability to create separate applications. For somebody with a programming background, like myself, a Biztalk application is conceptually very different from, say, a .NET application. A .NET application runs inside of its own process and has its own memory space. A BizTalk application is more of an organizational tool. It provides a convenient way of grouping together BizTalk artifacts, and makes it easier to stop and start a group of ports. However, all BizTalk applications are run within the same process.
That little bit of background information makes explaining this next part easier. Since everything runs in the same process, you have to be a little bit careful when you share artifacts between applications. For example, if you have two orchestrations that both use the same schema, you need to be sure that only one version of that schema is deployed. (Based on the XML namespace and the root node name combo that BizTalk uses to uniquely identify a schema.) If you deploy the same schema more than once, BizTalk will have trouble matching an instance to the correct schema and you will get all kinds of weird errors in the Event Log.
To avoid this problem, make sure you organize your shared artifacts into separate assemblies, and have the projects that use them all reference those assemblies. This is also nice, because if one of your shared schemas needs to be modified it only needs to be modified in one assembly, and then all the projects that reference it will get those changes. You might also consider deploying shared artifacts into a separate application to make it easier to keep track of them. (The default “BizTalk Application 1″ that gets created during installation is a good candidate for this.) Hopefully this little tip will help others who are new to BizTalk avoid some of the pain that comes with the large learning curve.
Posted in BizTalk, Technology | No Comments »
May 5th, 2008 Scott
Wow. Microsoft has announced another “R” version of BizTalk 2006. Check out that link for a rough list of the improvements coming with the R3 release. While on one hand I love getting new developer tools, on the other hand this will be the third BizTalk release in almost as many years. On top of that, you have BizTalk “Oslo” waiting in the wings. BizTalk is the most expensive of the retail products that Microsoft sells. The Enterprise version costs $35,000 per processor, so for a typical dual-processor server it costs $70,000 to deploy BizTalk. If your project requires more than one BizTalk server, the costs can get real expensive in a hurry. Each “R” release is treated as a new product, and is sold at full price. In my opinion, the functionality introduced in R2, and what is tentatively announced for R3 should have been released in a service pack. In essence, these rapid-fire BizTalk releases seem to be a ploy to force customers to purchase Software Assurance coverage for their BizTalk licenses. For early adopters of other Microsoft products, SA is a complete waste of money because the coverage usually expires before a new version is released. With the current BizTalk release cycle, you get completely hosed if you do not purchase SA, because there is a chance that two or more releases will happen during the SA coverage time period. I guess it is a good racket to be in if you can get away with it.
Posted in BizTalk, Technology | No Comments »
April 16th, 2008 Scott
I am setting up a little experiment. The primary operating system on my laptop is Fedora 8, but I spend a fair amount of time developing in a Windows environment. Currently, I run all of my Windows systems inside of VMware virtual machines. I want to create a common location for all of my code and other files that I can access from both my Linux and Windows systems. I tried creating a shared folder on the Linux system, but Visual Studio refuses to build and run programs that are stored in a shared folder. (At least, it refuses to work without mucking around with the security policy)
My new plan is to use a SCM to manage my files, and to keep all of my systems synchronized. The main repository will run under Linux, and the Windows systems will synchronize their files with the Linux host. To this end, I need to choose a SCM system. Out of all the options out there, the two that I know the best are Subversion and Git. Lately I have been doing more work with Git and I would prefer to work with its distributed model instead of the centralized model of Subversion. The problem is that Git is not well supported on Windows. Plus Subversion has really nice Windows integration through the TortoiseSVN shell extension.
So it all boils down to a choice between the superior (in my opinion) model of Git, or the polished Windows experience of Subversion. Decisions, decisions…
Posted in Linux, Technology, Windows | 2 Comments »
April 14th, 2008 Scott
Recently, I have been working on a project using BizTalk to translate sales orders from a web store and import them into Dynamics AX. The DAX schema has a number of optional nodes, but if some of these nodes are present in an instance of the XML file, the system will fail to import the sales order. The easiest way I have found to suppress these nodes is to drag a boolean functoid onto the map, set its inputs to always be false, and drag a link to nodes that you want to remove from the output schema. For example, I use an Equals functoid and I set the two inputs to 1 and 2. Since 1 will never equal 2, this will evaluate to false. From there drag a link to each node you want to suppress, compile and deploy your map.
Posted in BizTalk, Technology | No Comments »
April 11th, 2008 Scott
Every time I have ever tried using an XPath expression inside an orchestration, I only managed to generate XLANG errors in the event log. Well, today I found this blog post that clued me in to the magic that makes XPath work in BizTalk. When using the xpath() function within an orchestration, make sure you wrap the XPath expression itself within a string() function call. A properly formatted XPath expression would look like this:
myVar = xpath(myMessage, "string(/*[local-name()='MyRootNode'])”);
This works beautifully in BizTalk 2006 R2.
Posted in BizTalk, Technology | 1 Comment »
March 7th, 2008 Scott
I finally get it. I have used TDD on a few of my past projects, but I have always struggled with determining which tests I should write. In my head I could see the code for the feature I was working on, but I could not see the code for the tests for that feature. That brings me to some code I was working on last night. In my quest to become an open source developer, I was spending some quality time playing around with the RSpec testing framework for Ruby. I was working through a tutorial from IBM developerWorks.While technically RSpec is a BDD framework, it still follows the TDD idea of writing tests before writing code and letting the tests guide the design. Unlike most testing frameworks, RSpec lets you write tests in a form that resembles how you would write the requirements in English. That is what finally made the pieces fall into place for me. I now understand that the tests are supposed to define the details of the requirements in code. As you write more tests and then write the code the makes those tests pass, you uncover more things that you need to write tests for. It makes for a really nice feedback loop.
Using my newly-discovered knowledge, I built a small class up using RSpec and following the loop. I have included that code here with the hope it may help somebody else out there better understand how all this works.
First, I have the RSpec test suite:
require 'warehouse'
describe Warehouse do
before :each do
@warehouse = Warehouse.new
end
it "should be empty before items are stored in it" do
@warehouse.should be_empty()
end
it "initial item count should be zero" do
@warehouse.item_count("item number").should == 0
end
it "should receive items for inventory" do
@warehouse.receive_item("item number", 10)
@warehouse.item_count("item number").should == 10
end
it "should add items to count if they already exist" do
@warehouse.receive_item("item number", 10)
@warehouse.receive_item("item number", 40)
@warehouse.item_count("item number").should == 50
end
end
And here is the code for the class under test:
class Warehouse
attr_accessor :items
def initialize
@items = Hash.new
end
def empty?()
@items.length
end
def item_count(item_number)
@items[item_number] == nil ? 0 : @items[item_number]
end
def receive_item(item_number, count)
if (@items[item_number])
@items[item_number] += count
else
@items[item_number] = count
end
end
end
So now I am basking in my moment of enlightenment. I only wish I would have figured all of this out sooner
Posted in Development, Ruby, Technology | No Comments »
March 5th, 2008 Scott
I have run into an unusual problem with a solution that integrates BizTalk 2006 R2 with Sharepoint 2007 and Infopath 2007. The basic idea is that XML messages that are processed using BizTalk are sent to a Sharepoint document forms library. From there the messages are edited using Infopath, and then BizTalk picks them up again for final processing. One of the neat things you can do with Infopath and Sharepoint is to promote certain elements in an XML message that will then show up as columns in the Sharepoint document library. These promoted elements can then be used to create custom views and can be sorted on among other things. The problem comes in because BizTalk uses an XML namespace prefix of “ns:0″, and Infopath by default uses a prefix of “ns:1″. Normally this is not a problem, but when you have a document library that has been created from an Infopath template, it requires that any XML messages sent to it have the same namespace prefix in order for the promoted elements to show up in the Sharepoint document library views.
I managed to get my solution working by creating using a custom XSLT transform in my BizTalk map, but I would really like to find a proper fix to this issue. If anybody knows how to make this work without using a strange workaround, please leave a solution in the comments.
Posted in BizTalk, Sharepoint, Technology | No Comments »