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 also working properly, in this environment we use the SQL Server Adapter.
However the last time the team try to configure the receive location present in the application they unexpected 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 this 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 try to create a new Receive Location and I found out that the SQL binding was not present:
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 installed 32 and 64 bits version of the adapters.
However in my particular case that wasn’t the problem because I had both version 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. After this all the adapters present in the BizTalk Adapter Pack stopped to work.
SOLUTION
It depends on the configuration of your environment.
Solution 1:
If 32-bit versions of the BizTalk Adapter Pack are note installed in 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 in the machine.config if the custom binding extension are configured properly in both 32 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 util to edit the config file. It is easy to add the binding extensions in this utility otherwise with a common text editor like notepad 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 fixed the machine.config file the WCF-SQL adapter started to work again.
