I have often wondered why the built-in functoids doesn't encompass an If-Then-Else functoid. The Value Mapping functoid only has an If-Then-part and not the Else-part.

This is the first of two blog posts. This post will explore how to solve the issue with the built-in functionality of BizTalk. The next post will be about creating a custom functoid to do the job instead and the issues that come with this task.

So, using the built-in functionality:

Imagine this input schema:

And imagine this output schema:

My goal, now is to create a map that will map the value of the "ifJan" element to the destination IF the "qualifier" element equals the word "Jan" and otherwise the value of the "ifNotJan" element should be mapped.

Basically, you need one value mapping functoid for each possible value to pass on, and a logical functoid for each value as well, to use in the value mapping functoid. The "String Concatenate" functoid is just my way of returning the string to use for the qualifier - in this case: "Jan".

You can also do it using one scripting functoid like this:

where the scripting functoid is an "Inline XSLT Call Template" scripting type, and the script looks likes this:

Both scripting solutions can be altered to accept the output of a logical functoid as the first input. Just change the string "Jan" to "true" in the scripts, and change the name of the parameter if you want.

Now then... I am not a big fan of either of these three options. Generally, I avoid scripting functoids when I can because it is difficult for a new developer to know what is happening when he opens the map because he will have to open up all scripting functoids and find out (and remember) what they do. Also, I am not really a big fan of the first solution either. First of all, there are too many functoids, and it can messy if this solution is needed several times in a map. Secondly, you get a warning every time you compile, because you have two inputs to one element.

In almost all multiple server installations of BizTalk I have encountered, there has been issues with MSDTC. MSDTC is Microsofts product for handling distributed transactions, meaning transactions that span multiple servers. BizTalk uses this in high scale, when running transactions against SQL Server, to maintain consistency in BizTalks databases.

All issues with MSDTC are solvable - sometimes it is just hard to figure out what is wrong.

First of all, always use the DTCTester tool at http://support.microsoft.com/kb/293799 to test your MSDTC installation. If this tool reports no errors and you are still having issues, then most likely, MSDTC isn't the cause of your issues.

If something is wrong with MSDTC, I have encountered four major issues:

MSDTC doesn't run on either of the server. Solve this by starting MSDTC. Steps to start MSDTC (Note, that the MMC snapin is buggy, and it might appear that the "Component Services" node has no children... but it does, trust me ):

Go to "Administrative Tools" => "Component Services"

Go to "Component Services" => "Computers" => "My Computer"

Right click "My Computer" and choose "Start MS DTC".

MSDTC isn't configured for network access on both servers. Solve this in "add/remove windows components" here:

The two servers have the same MS DTC ID. This ocurs if both servers are clones of the same server or if one of the ervers is a clone of the other server. Usually, when cloning servers, sysprep is used to clear out those errors, but in case it hasn't been used, here is how you fix it:

Run "msdtc -uninstall" from a command prompt

reboot

Run "msdtc -install" from a command prompt

reboot

You can't ping the servers by hostname, which is required. This basically means, that from both servers, you need to be able to ping the other server by hostname - pinging by IP address isn't enough. If you can't ping by hostname, you have two options:

Get the network administrator to update your DNS

Enter new information into the hosts file in c:\windows\system32\drivers\etc

People sometimes ask, what is the difference between catching System.Exception and the General Exception in a Catch Exception shape in the orchestration designer in BizTalk.

Off course, an obvious difference is, that with the General Exception, you don't get an object with properties to investigate. But then it seems that the General Exception is useless... surely there is a point to it?

Well, I was curious about this myself, so I investigated a bit, and found this post. So basically, I think the catch of the general exception in BizTalk 2006 is a left over from BizTalk 2004. In BizTalk 2004 it made sense, since you actually have exceptions thrown at you that didn't derive from System.Exception. That is no longer possible in .NET 2.0 - they just haven't removed it from the designer - probably just to be backwards compatible.

I am currently supporting an existing BizTalk 2004 environment, and came across the need to debug an orchestration in the production environment. Yes, I know - "Not in the production environment", you scream... but yes, indeed - in the production environment.

Anyway, I set some breakpoints, waited for the orchestration to hit the breakpoint and tried to attach to the orchestration. I got this error:

Debugging user validation against group '<servername>\BizTalk Server Administrators' failed with error: Debuging Client is not a BizTalk
Server Administrator.

This seemed odd, so I investigated a bit further. It turns out, that the setup is a multiple server setup, ie. one server for SQL Server and one for BizTalk 2004. Also, it tunrs out, that the gyuy who installed the servers didn't use domain groups. The services were running under domain accounts, but the BizTalk groups were created on both machines. Not a supported setup, but I am hoping they will upgrade to BizTalk 2006 R2 before long, and therefore, we are not going to touch that.

Anyway, it turns out, that the user I was logged in as was a member of the "BizTalk Server Administrators" group - but only on the BizTalk Server. Once I added him to the same group on the SQL Server server, all was fine.

I googled the error, and didn't stumble upon an answer, so I just thought I'd blog about it in case anyone has the need for the answer some day

The other day, I suddenly found myself in a situation, where I needed to use the "Find message" functionality and HAT to find a message, and I needed to filter on a promoted property.

My problems started appearing, when there were no promoted properties to select in the Message properties filter view. I had chosen my schema, but still, the dropdowns for promoted properties were empty.

So I checked that tracking of both message bodies and promoted properties were enabled in the receive port. Yes, they were... so I started wondering what might be the cause of this. And then I though: Oh yeah, you need to enable tracking of these individually in HAT. But in HAT I couldn't find anywhere to enable this. That stunned me for a couple of minutes. Turns out, that was in BizTalk 2004

Whoops

And the I remembered that I needed to do two things in order to get the tracking of promoted properties to work:

The first is to enable the tracking in the receive port:

And the second thing is to enable tracking of each specific promoted property - and now I remembered it isn't in HAT anymore, it is in BizTalk Server Administration for each schema. So open BizTalk Server Administration. Go to the application that has the schema, for which you need to track promoted properties. Go to the schemas collection of this application, double click on the appropriate schema, go to the tracking pane, and here you must select the properties to track.

I googled this a lot, but had great difficulty finding any information... that's the reason for this post.

I had post some time ago, which explained how to promote fields from a schema generated by the SQL Adapter. This post contains some information that could be useful for people searching the net for information about changing the records in the generated schema into elements. A search for those words wouldn't have my post in the top 1000 hits, though

So I thought just to have this simple post with a title that will hopefully match what people search for, and let them find the information.

A guy on the microsoft.public.biztalk.orchestration newsgroup has asked about looping around elements inside an orchestration, and I thought I'd just write some lines about the issue here, for everybody to see in the future.

It takes the employee from the big incoming message that corresponds to the counter and assigns it to the message that is to be constructed.

In the next expression shape, I just write the content of the distinguished field "title" of the employee to the eventlog.

And in the final expression shape, I increment the counter variables:

counter = counter + 1;counterStr = System.Convert.ToString(counter);

So by doing this, I am looping over the employees inside the employees-message, and I have access to all the values inside the single employee. I didn't have to have schema number 2, describing a single employee, I could have just used xpath all the way down, or maybe declare an XmlNode variable to hold the employee-element instead. But I like this solution better.

Another option I have now is that I can add a decision shape, and based on the title value, I can call different orchestrations, that will handle a specific employee-type. Or perhaps I could just send the employee message to a direct-bound send port and have other orchestrations subscribe to the employee message type. This would require the title to be a promoted property instead of a distinguished field, though, in order to route on it.

Suggestion 2

I propose using an XML Envelope to split the incoming file into several employee-messages and let the orchestration handle them individually.

To do this, I have created two schemas:

for the envelope and for the employee. Note: I have changed the names of the root nodes in both schemas. Naturally, in real life you wouldn't do this. The only reason I did this is to be able to have both my examples deployed at the same time. If I hadn't done it, I would have had multiple schemas deployed with the same combination of target namespace and root node, which we all know is BAD. On the schema for the envelope, I have clicked on the "<Schema>"-node and in the properties windows, I have set "Envelope" to "Yes". Then, I clicked on the "EmployeesEnvelope"-node and in the properties window, I set the "Body XPath" property to point at the "EmployeesEnvelope"-element.

Then, I created an orchestration, that takes an employee as the input - not the employees-type, but the single employee. It looks like this:

So here I have a much smaller, simpler, and faster orchestration than the one from suggestion 1.

After the solution is deployed, I create a receive location, and remember to use the default XMLReceive pipeline. The disassembler stage will look at the incoming message, determine the message type, see it is an envelope, split the message into smaller messages, and publish them individually with their own message type.

If I need different orchestrations depending on the value of the title attribute, I can promote it to a promoted property instead of a distinguished field, and add it to a filter on the receive shape in each orchestration.

Every now and then, I come across the need of adding a node to the output of a BizTalk map.

Now, if I just want to add some node which isn't dependent on the input, I can just use a custom scripting functoid which is an XSLT template that just craeted the node for me, like this:

Use the "Inline XSLT Call Template" instead, if you need parameters to your XSLT.

BUT, sometimes I need to add a node to a list of existing nodes. One example of this I came across was the need to have a log inside the XML structure that was updated every time BizTalk touched the document. So there would be a structure inside the XML like this:

<TheLog><LogEntry>This is the first log entry and it was added by Jan</LogEntry><LogEntry>This is the second entry and it was added by BizTalk</LogEntry></TheLog>

So BizTalk needed to add a line to TheLog when BizTalk mapped the document.

Another example is a guy on the microsoft.public.biztalk.general newsgroup that needs to add an OrderItem to an existing list of OrderItems.

To do this, I have only found one solution, which is a custom xslt script that does the whole thing.

My example input schema:

My example output schema:

In both schemas, the "Order"-element can occur multiple times.

The map looks like this:

Basically, just one scripting functoid. Note that no links go from the source document. The scripting functoid is a "Inline XSLT" type, and the source is this:

A colleague of mine, Morten la Cour Thomsen, who is "MCTS: BizTalk Server 2004" AND "MCTS: BizTalk Server 2006" discovered something strange the other day. In fact, it is so strange, that I thought I'd share it here on my blog.

Morten was on a project, where he had taken over another persons BizTalk solution. Unfortunately for Morten, the other guy had decided to put all artefacts into one single assembly. That's right - all schemas, all maps, pipelines, orchestrations.. the works! Just one big assembly.

This turned out to be quite a problem for the company that had this solution, since versioning any single artefact meant versioning the whole thing. That is also why they until now didn't version anything. Should something need to be changed in the big assembly, four steps were performed:

Stop all receive locations

Make the change in the artefact that needed changing

Wait until all long running transactions have stopped

Deploy the new assembly on top of the old one, leaving all versionnumbers the same

Mortens job was to create a better architecture, since it really wasn't ok with the customer to have to stop receiving new messages until all orchestrations had stopped.

One of the steps Morten came across was that he actually at some point needed to call an orchestration that was inside this big assembly. The orchestration that Morten needed to call was being called from other orchestrations inside the assembly, so it was ready to be called (no activate receive shape, etc.). The only problem for Morten was, that the orchestration, off course, was internal to the assembly. Morten could reference the assembly, but he couldn't call the orchestration from within an "Call Orchestration"-shape.

But that's when Morten tried something that I would never have thought of trying: He had the source code for the big assembly. And he had the keyfile that had been used to sign it. So he changed the orchestration to be public, recompiled the big assembly, referenced the newly compiled assembly, added the former internal orchestration to his "Call Orchestration"-shape and compiled his own assembly.

He now deployed his own assembly, but left the old big assembly in place.

Now he had the old big assembly, which still had the internal orchestration inside it. And he had another deployed assembly, which was compiled against the source code with a public orchestration. The big assembly was never redeployed!

But it worked! Mortens orchestration is now calling the internal orchestration of the other assembly, simply because it was compiled against a public orchestration and the signature of the deployed big assembly matches the signature of his newly compiled big assembly.

A guy (I think it is a guy, anyways ) on the microsoft.public.biztalk.orchestration newsgroup has a problem with this issue. And since I had the issue myself a long time ago, and always wanted to write a quick blog entry about it, this seemed like a perfect time for it

A quick note: This issue appears on both BizTalk 2004 and BizTalk 2006.

So basically, the problem is: When compiling a BizTalk project, you get the "'projectname.orchestrationname': cannot resolve imported 'service'" error. This occurs when you are compiling a project that has an orchestration inside it, that calls another orchestration in another project that again calls an orchestration in a third project. Confused? I bet! I will give you details, screenshots and explanations in just a few lines.

The quick answer is: The project you are trying to compile must reference the third project.

BUT, to the long answer:

I have created a solution with three projects:

ProjectA with ABCSchema.xsd and OrchestrationA.odx

Orchestration A does this

Receive a message of type ABCSchema.xsd

Initialize a string variable to receive the value from a distinguished field in ABCSchema

Write the value to the eventlog

Call OrchestrationB

ProjectB with OrchestrationB.odx

Orchestration B does this:

Receive the string parameter from OrchestrationA

Write the value to the eventlog

Call OrchestrationC

ProjectC with OrchestrationC.odx

Orchestration C does this:

Receive the string parameter from OrchestrationB

Write the value to the eventlog

Screenshots:

The (very small) schema:

OrchestrationA:

OrchestrationB:

OrchestrationC:

No hokus pokus at all!

In order to call OrchestrationC from OrchestrationB, I added a reference to ProjectC from ProjectB. Both ProjectB and ProjectC compile just fine.

In order to call OrchestrationB from OrchestrationA, I add a reference to ProjectB from ProjectA, but ProjectA wont compile. I get this error:

The famous "cannot resolve imported 'service'" error.

BUT, referencing ProjectC from ProjectA solves this issue, and I can compile just fine.

Actually, the error description indicates it. When compiling ProjectA, it can't import the "ProjectC.OrchestrationC" service. But often, you are maybe compiling the entire solution, and you just see that the file in quesion is projectb.dll. But the error just states that ProjectA cannot import ProjectC.OrchestrationC, which it needs to according to projectb.dll.

Should anyone think that it is really silly that ProjectA needs to reference a dll that another dll references and that this breaks all nice architectures, I would agree. If someone gives me a set of 20 dll's that make up a nice solution he/she has made, and I need to call an orchestration in one of them, then I also need to reference all the dll's that this one dll references, assuming there are internal "Call Orchestration"s between these dll's. I will need to know how these dll's reference eachother in order to reference one of them. Really silly, indeed.

I ran into this one a while ago. I couldn't find any information about the error on the internet, so I tried the microsoft public newsgroups. Again, no help (although those newsgroups are a GREAT place for getting help...). Anyway, I found out, what the error was, and it can probably be found in google groups by now, but I thought I'd just share it here as well.

Basically, the problem was that BizTalk 2004 SP1 apparently has a bug. If you have a "Call Orchestration"-shape (or a "Start Orchestration"-shape) in your orchestration, and this shape is placed in some particular unreachable code, you get this error.

I had a decision shape in my orchestration, but I hadn't gotten around to deciding what the rule in the decision shape was going to be. So I entered "1 == 1" in order for the assembly to compile and then I could deploy it and test it for that branch of my decision shape. Then, I wanted to test the other branch, still not knowing what the final rule would be. So I modified the orchestration to have the rule to be "1 != 1" - but then I couldn't compile - weird, eh?

Below is my orchestration.

So, as you can see - no funny stuff. Another weird thing is, that I can compile just fine with my "Call Orchestration"-shape after a Terminate-shape. But that is unreachable code as well.