Category name:BizTalk

BAM: don’t use spaces in view names!

if you’re familiair with BAM in BizTalk 2004, it is easy to notice the changes between 2004 and 2006 while setting up a BAM environment in BizTalk 2006.


Changes can be found for example when defining the activities and views. Besides textual changes (on for example buttons) I found out that it is no longer prohibited to use spaces in the names of activities and views. I thought that was a nice improvement to increase readibility.


I still feel that way, but it turned out not to be so handy when you want to remove the views with the BM tool. When you try to remove a view with a space in the name, it gently informs you that such a view doesn’t exist! In the BM tool in 2004 it was also possible to remove deployments based on a number, but in 2006 that is no longer the case. Strangely you can view the changes but not remove them anymore.


I tried to remove the views using the stored procedures in the BAMPrimaryImport but I couldn’t find an SP to remove the view. I did find one to remove an activity, but there seem to be none for views.


Finally I decided to remove tables, views and so from the database. Obviously that isn’t a nice way to solve it.


Does anyone know how to remove a view with a space in its name?

BAM portal (no) views

In the past I worked on BAM with BizTalk 2004. Now I’m on a project with BizTalk 2006 and again I’m the one to do the BAM part.


I played a bit with BAM and 2006 but nothing serious. I under the impression the way BAM in BizTalk 2006 works, or at least the way to create activities and views wasn’t changed drastically.


So I went for a basic BAM implementation to get to know the implementation chain. A simple activity in an simple view and the view should show up in the BAM portal. And you can guess it…..it didn’t work. There was no view in the view-list and nothing in the eventlog to help me with this. In these scenario’s Google is my best friend, so I searched on Biztalk 2006 BAM and “no view to display”. I ended up with only result: http://blogs.msdn.com/tihot/archive/2006/06/13/630313.aspx


This also didn’t fix the issue.


At the end I suddenly remembered that in 2004 was also necessary to define accounts on the views so users had rights to view them. That actually solved the issue.

File delivery assurance in orchestrations

It has been a while since my last post, but I ran into something that I think is worth sharing with you.

At the moment I’m working on a BizTalk project which has the requirement that it should be able to handle large messages. That is up to a Gb or more.

For the business process I needed an orchestration. In the orchestration I move the message from the receive location to a share on another server using a send port. After that I call a web service which is responsible for transferring the message to a remote server using a XCOM server (this is a CA product).

For small messages everything worked fine, but the moment I tried a large message (say over 100 Mb) I found out that the file was not completely written to the fileshare before the web service was called. Obviously that call resulted in an error. The send port worked according to a kind of fire-and-forget mechanism so the orchestration moved on while the message transfer was still busy.

So I had to think of something to make sure the message was completely on the share before moving on down the orchestration. The first thing I thought of was using an ACK. I never looked at this before, but it sounded like something I could use. While using Google to find some samples about using the ACK I ran into the solution (thanks to Matt Milner) that is as simple as obvious: put the send shape in a transaction and the orchestration will wait until it is finished.

The actual steps are:

  • put the send shape in a scope
  • set the transactional properties to long running
  • set the Delivery Notification of the port to Transmitted
  • if necessary you can catch the DeliveryNotificationException

It is a very simple solution and it works great!

Scripting functoids and their method names

Recently I was working on a mapping for which I needed two scripting functoids.


I used the inline C# and defined a certain method name. I used the same method name for the other scripting functoid because it quite described what was done in the method, but the implementation was slightly different.


When I tested the map it seemed that only one of the functoids was executed. However it looked like it generated output for both functoids. It appeared the implementation of the first functoid was applied to both.


After some debugging I found out the cause of this was multiple functoids having the same method name. After changing that, everything worked as expected again.


I learned my leasson and now I always change the method name to something unique for that mapping. But I was a bit surprised that the compiler didn’t warn about this.