Failed to Update Binding Information

Sometimes you may come across the error "Failed to update binding information" when trying to import bindings for a BizTalk application.

Your bindings may indeed be correct, and you likely also have the proper Host created (you checked THREE times already!).  However, you may not have added the host within the BizTalk Adapters.

This is especially common when building a new BizTalk server or have a BizTalk application which will be using a new Host.

enableBizTalkCompatibilityMode in SAP adapter bindings

I've installed the BizTalk SAP adapter (more specifically, the WCF LOB Adapter SDK) to my development box and have successfully connected to our test SAP environment.

Within Visual Studio, I created a new BizTalk solution, used the Consume Adapter Service, and selected the sapBinding option. I went through the process of configuring the connection string, credentials, contract type, and, in this case, which IDoc was needed to create the schemas and binding information.

It all works wonderfully well. Two things, however, make me scratch my head a little bit.

First, the binding xml file (you could import this at the application level within the Administration Console) which is created by the wizard assumes you will be using the WCF-Custom transport type instead of WCF-SAP. This isn't really that big of a deal, more of a curiosity, since the configurations are essentially the same, just displayed a bit differently.

Second, the binding file has the binding configuration/property enableBizTalkCompatibilityMode set to false. When I mouse-over this property when selecting the WCF-SAP transport, I get this:

Set to True when used within BizTalk. Set to False otherwise.

So why doesn't the wizard set this to True in the first place?

To be honest, I'm not sure what this property does, as the documentation for it is a bit light.

I'll keep you posted as I come across new findings.

BizTalk Install: "RPC server is unavailable"

I'm in the process of upgrading BizTalk 2009 to 2010. The new BizTalk environment is a two-server active/active environment - the operating system for both aren't using a clustered configuration. The SQL back end is a separate tier (SQL Server 2008R2).

The first BizTalk tier went flawless with the install and configuration. The second tier installation was successful as well.

However, when I tried to configure the second tier, I got the error "(RPC: 0x800706BA: The RPC server is unavailable.) (SSO)" when trying to Join to the existing Enterprise SSO.



There is a bit of documentation out there, and most of it led to information on MSDTC issues. One of the configurations within the BizTalk install is to ensure that the DTC rules are enabled within the firewall configuration. Those were enabled, yet I still recieved errors.

A Microsoft tool called DTCPing, helped me out considerably. I copied the executable to my app tiers and also to our SQL Server tier. You have to run them all simultaneously on each tier. I was able to ping from my BizTalk Sever tier to SQL, but I couldn't successfully ping in the opposite direction.

Hmmm, firewall?

Initial test: Turn the firewalls on the BizTalk app tiers off. Restart the DTCPing process. SUCCESS with ping!

So now we know it's a firewall issue. A new rule added to the firewall was the fix.

As a side note, Chris Forster does a decent job describing some background to MSDTC and SQL.

BizTalk 2010 and BAHS

If you have installed BizTalk Adapters for Host Systems (BAHS) in the past and are now looking to do the same for BizTalk 2010 (i.e. migrate from previous BizTalk version), Microsoft has rolled the adapters into BizTalk Host Integration Server 2010.

Licensing for HIS 2010 is included as part of BizTalk 2010 (6th bullet point down), so there are no worries about that.

If you just want the BizTalk adapters, configuration of HIS 2010 is not neccessary. Thanks to Stephen Jackson and Ben Cline for quick response and clarifications.

BizTalk 2010 Adapter Pack 2.0 install issues

I'm installing a new instance of BizTalk 2010 server, and wanted to add the WCF-SQL adapter. This requires the BizTalk LOB Adapter SDK 2010 as a prerequisite. The OS is Windows Server 2008R2, 64-bit.

After I downloaded and installed the SDK (x64), I installed the x64 version of the Microsoft BizTalk Adapter Pack (v2.0). I figured at this point I could now go into the BizTalk Administration console and add the WCF-SQL adapter by selecting Platform Settings/Adapters/(right-click) new/Adapter.

The Adapter dropdown list was empty.

It doesn't seem clear, but it seems apparent that you also need to install the x86 version of the Adapter Pack as well. I did not need to install the x86 version of the LOB SDK. Can anyone verify/clarify this?

BizTalk's Table Looping Functiod in detail

There are several posts based on the Table Looping Functiod:

• Evan Koch


• Dan Schulz - dead link, view via Wayback Machine


• flatlander, explaining a repeating structure


• and BizTalk and .NET Stew, who explains the gated concept

These are all great examples, but I'd like to get into detail of what may happens when using flatlander's example without using the BizTalk .NET Stew example.

I'm going to copy flatlander's example. My source file looks like this:

Take note that I have 3 Chef nodes, but only 1 MaitreD node.

Testing the map produces the below output:


Notice that I have 3(?!) MaitreD instances of Mr. Cook. That isn't right. My initial suspicions are that you will iterate both the same time as the node which has the highest number of iterations. So if node Chef has 3 iterations (child nodes), you will have the same iterations in your output with your MaitreD nodes.

Not quite what I want.

So, going on, I'm following what BizTalk and .NET Stew explains, by using the gated functionality of the functoid. The question becomes now: How do I gate the input if I only have fewer iterations of one node vs. the other?

Being that the two root nodes in the source are iterative, I can determine which iteration I am on from the source. Taking that one step further, I can also determine if a particular iteration of a node is not null. The assumption is that the node you are comparing cannot be null.

So in this exercise, let's take the Chef/Name and MaitreD/Name as the 'gate' nodes to compare, since I have determined they cannot be null or empty. If a node at a particular index doesn't exist (i.e. Chef/Name[20]), then it will be blank/null. I pipe the 'value' of that index to a NotEqual functoid. I compare it to an empty string, and from there I should have a boolean value which determines if that index of the node exists - my gate.



Let's take a look into the functoid's configurations.
Index:


And NotEqual. The string value is empty (no spaces).


I use these two outputs as column1 of the Table Looping functiod. Also note that I have the Gated checkbox checked, as in BizTalk and .NET Stew explains:


Testing the map, and you have a cleaner representation of the output:


This may not be the most elegant solution, but in this scenario we are using only functiods in the map and staying away from XSLT, scripting, or an external assembly - as many have suggested to do instead.

I personally lean towards the approach that if it's not too difficult, stay within a single pattern or two for supportablity within your development environment.

Scheduled task may execute indefinitely when using certificates on Windows

I'm an administrator of an FTP server (on Windows Server 2008R2) which has a well-known FTP client on it. We use SSH and SSL, depending on our partners. Most of the time we use scheduled tasks to trigger FTP scripts. I've been noticing within the Windows Task Scheduler that tasks aren't completing, and are always in a 'running' state.

Typically I use my account to log in and make changes. However, I use a different local adminstrator account to execute the scheduled tasks. I have found out that this is bad practice.

In my case, when using SSL, SSH, (and I *think* PGP), the keys are saved somewhere within the C:\Users\{username}\AppData folder. I believe this is a common practice throughout the industry - not sure if this is a Microsoft policy.

So when you log in using a different username to set up the environment and use a different username to execute the task, your results aren't as anticipated. This is likely due to the fact that the keys you saved/accepted are NOT in the proper user folder.

I logged into the server using the same credentials as the scheduled task, accepted the certs, and all has been working well since.