I have a BizTalk Server 2010 Test Environment that was working properly for some time, all the adapters from BizTalk Server Adapter Pack 2010 were installed with the last cumulative updates, and were also working properly. In this environment, we use the SQL Server Adapter.
However, the last time the team tried to configure the receive location present in the application, they unexpectedly got the following error:
“Unable to create binding configuration element for editing. Check the values of the bindyingType and BindingConfiguration properties. (Microsoft.BizTalk.Adapter.Wcf.Converters.CreateBindingException) Unable to get binding type for binding extension “sqlBinding”. Verify the binding extension is registered in the machine.config.”
Also, every time they try to enable the Receive Location, they automatically become disabled again. When I checked the Event Viewer, I also found these two errors:
“The Messaging Engine failed to add a receive location “WcfReceiveLocation_SqlAdapterBinding_TypedPolling ” with URL “mssql://SERVER:PORT/INSTANCE/DB?InboundId=id” to the adapter “WCF-Custom”. Reason: “Microsoft.BizTalk.Adapter.Wcf.Converters.CreateBindingException: Unable to get binding type for binding extension “sqlBinding”. Verify the binding extension is registered in machine.config.”
“The receive location “WcfReceiveLocation_SqlAdapterBinding_TypedPolling ” with URL ” mssql://SERVER:PORT/INSTANCE/DB?InboundId=id ” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.”
Suspecting the problem but curious to understand the problem, I tried to create a new Receive Location, and I found out that the SQL binding was not present:
📝 One-Minute Brief
The issue occurs when WCF adapter bindings (such as sqlBinding) are missing from the 32-bit or 64-bit machine.config after installing or removing .NET Framework versions or BizTalk Adapter Pack components. The solution is to install both 32-bit and 64-bit adapters and manually register the missing WCF binding extensions and providers in the correct machine.config files.
Cause
The SQL Database adapter (also the Oracle Adapter or the Oracle E-Business Suite) is a WCF custom binding, which is registered under System.ServiceModel in the machine.config file.
Important note: A 64-bit platform has two machine.config files, one used by the 32-bit applications and the other used by the 64-bit applications. Actually, they have several machine.config for different .NET Frameworks, however, in this case, we are talking about the last .NET Framework v4.0.30319 normally present in BizTalk Server 2010 environment which you can find in the following folders:
- 32-bits: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config
- 64-bits: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config
When you install the 64-bit version of the BizTalk Adapter Pack, the setup wizard registers the bindings in the 64-bit version of the machine.config file. However, BizTalk Server Administration console runs as a 32-bit process, and hence when you configure a port for the adapter, it checks for the bindings in the 32-bit version of the machine.config file and fails, giving an error. This is also the reason why you should always install 32 and 64-bit versions of the adapters.
However, in my particular case, that wasn’t the problem because I had both versions of the adapter installed and they were working properly. So in my case, the problem started to happen because one of the members installed a new .NET Framework version (4.5.2) in the BizTalk Server machines and then uninstalled it. After this, all the adapters present in the BizTalk Adapter Pack stopped working.
Solutions
It depends on the configuration of your environment.
Solution 1
If 32-bit versions of the BizTalk Adapter Pack are not installed on your machine, you should:
- Install both the 32-bit and 64-bit versions of the BizTalk Adapter Pack on a 64-bit WCF LOB Adapter SDK installation.
- Note: You must only have a 64-bit WCF LOB Adapter SDK installation. Side-by-side installation of 32-bit and 64-bit WCF LOB Adapter SDK on a single computer is not supported.
Solution 2
Otherwise, you should check the machine.config if the custom binding extensions are configured properly in both 32-bit and 64-bit files.
To check or register the adapter bindings or the .NET Framework Data Providers:
- Navigate to the machine.config file on the computer.
- Open the file using a text editor or using the SvcConfigEditor.exe utility to edit the config file. It is easy to add the binding extensions in this utility; otherwise, with a common text editor like Notepad, it is very easy to make errors while editing the config file.
- Check if there are present the adapter bindings otherwise, you should register them:
- Search for the element <client> under <system.serviceModel>:
- If not present, add the following line under it:
<client>
<endpoint binding="sapBinding" contract="IMetadataExchange" name="sap" />
<endpoint binding="siebelBinding" contract="IMetadataExchange" name="siebel" />
<endpoint binding="oracleDBBinding" contract="IMetadataExchange" name="oracleDb" />
<endpoint binding="oracleEBSBinding" contract="IMetadataExchange" name="oracleEBS" />
<endpoint binding="sqlBinding" contract="IMetadataExchange" name="mssql" />
</client>
- Search for the element <bindingElementExtensions> under <system.serviceModel><extensions>:
- Look for the missing adapter binding, and if they are not present, add the following lines under the <bindingElementExtensions> node:
<add name="sqlAdapter" type="Microsoft.Adapters.Sql.SqlAdapterBindingElementExtensionElement, Microsoft.Adapters.Sql, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="sapAdapter" type="Microsoft.Adapters.SAP.SAPAdapterExtensionElement, Microsoft.Adapters.SAP, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleDBAdapter" type="Microsoft.Adapters.OracleDB.OracleDBAdapterExtensionElement, Microsoft.Adapters.OracleDB, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="oracleEBSAdapter" type="Microsoft.Adapters.OracleEBS.OracleEBSBindingElementExtensionElement, Microsoft.Adapters.OracleEBS, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="siebelAdapter" type="Microsoft.Adapters.Siebel.SiebelAdapterExtensionElement,Microsoft.Adapters.Siebel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
- To check and register the .NET Framework Data Providers:
- Search for the element <DbProviderFactories> under the <system.data> node.
- Look for the missing .NET Framework Data Providers. Add the following sections under the <DbProviderFactories> node, depending on the missing provider. You must register all the providers if the setup wizard fails to register any.
<add name="SAPClient Data Provider" invariant="Microsoft.Data.SAPClient" description=".NET Framework Data Provider for mySAP Business Suite" type="Microsoft.Data.SAPClient.SAPClientFactory,Microsoft.Data.SAPClient, Version=<version>, Culture=neutral, PublicKeyToken=<public key>" />
<add name="SiebelClient Data Provider" invariant="Microsoft.Data.SiebelClient" description=".NET Framework Data Provider for Siebel eBusiness Applications" type="Microsoft.Data.SiebelClient.SiebelProviderFactory,Microsoft.Data.SiebelClient, Version=<version>, Culture=neutral, PublicKeyToken=<public key>" />
- Save and close the machine.config file.
After I edit and fix the machine.config file, the WCF-SQL adapter started to work again.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
Hi Sandro,
Should the same configuration be applied to 2.0 machine config file?
I have made this configuration at both 32 and 64 bit for 4.0, yet received same error.
Monika