Posts Tagged ‘Runtime’

Every time I try to configure the BizTalk Accelerator for RosettaNet in BizTalk Server 2013 or BizTalk Server 2013 R2 of course using Windows Server 2012 or Windows Server 2012 R2 I encounter this error in the configuration logfile

[2015-05-14 16:37:40:0043 Error ConfigHelper] Failed to add member ‘user’ to NT Group IIS_WPG Error code: -2147022676
[2015-05-14 16:37:40:0043 Error ConfigHelper] The group name could not be found

BTARN-The-group-name-could-not-be-found

CAUSE

When, basically this is a bug that has not been fixed yet. BizTalk Accelerator for RosettaNet was introduced in BizTalk Server 2004 and since there only little or no changes were made.

BTARN requires the IIS_WPG group (group provided by IIS 6.0 that provides the minimum set of user rights and permissions required to run an application) but unfortunately for us this group doesn’t exist anymore…

SOLUTION

The solution is very simple… you just need to create it manually.

To accomplish that you need to:

  • Open Computer Management and in the console tree, expand “System Tools à Local Users and Groups” and then right-click Groups and select the option New Group .
  • In Group name
    • Type: IIS_WPG.
  • In Description
    • Type: RosettaNet IIS group
  • And then click Create, and then click Close

I really hope that Microsoft provide a hotfix for this or at least fix this problem in the next releases of the product

In the sequence of my last post, and following the result obtained while trying to solve the problems that had been originated by the SAP system migration to a newer version, I end up receiving another error. This time the connectivity problem with SAP was overcome, however without any reason I started to receive an error saying that the schema was not known

I got the following error:

“There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Receive Port: "IN_IDOC_PORT" URI: "sap://CLIENT=[SAPClientID];LANG=[LANG];@A/[SAPServer]/[SystemID]?ListenerGwServ=[GWServer]&ListenerGwHost=[GwHost]&ListenerProgramId=[ProgID]&RfcSdkTrace=True&AbapDebug=False" Reason: Finding the document specification by message type "http://Microsoft.LobServices.Sap/2007/03/Idoc/3/IDOC_NAME//740/Receive#Receive" failed. Verify the schema deployed properly.”

It was strange to receive this kind of error because the process was in testing stage, for about a month, and working properly.

CAUSE

After the SAP System migration to a newer version the process started also to use a newer version of the IDOC Schema. I really don’t know if the SAP team change anything in the SAP side or it had to do with the migration itself, however when I checked the source code I noticed that we were using the 711 version of the schema:

And now the SAP system process was using and sending the 740 version of the schema:

SOLUTION

The solution is very simple, you just need to generate and import the newest version of IDOC schema (740) to your BizTalk Solution, make all the necessary changes and redeploy all the required artifacts (schemas, orchestrations, maps, and so on)

Recently one of my clients migrated one of their SAP systems and after that intervention the BizTalk receive location that was listening in a specific Program ID started to failed with the following error message present in the event viewer: “RFC IDOC_INBOUND_ASYNCHRONOUS could not be resolved against SAP system because its metadata could not be obtained

Full error message:

The adapter "WCF-Custom" raised an error message. Details "Microsoft.ServiceModel.Channels.Common.MetadataException: RFC IDOC_INBOUND_ASYNCHRONOUS イ楸 could not be resolved against SAP system because its metadata could not be obtained. —> Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_EXCEPTION. ErrorGroup=RFC_ERROR_APPLICATION_EXCEPTION. SapErrorMessage=EXCEPTION FU_NOT_FOUND RAISED. AdapterErrorMessage=An error occurred while determining the function interface of the RFC IDOC_INBOUND_ASYNCHRONOUS イ楸.
at Microsoft.Adapters.SAP.RFCException.HelperThrow(Int32 retCode, String additionalErrorMessage)
at Microsoft.Adapters.SAP.RfcClientConnection.GetRfcFunctionInterface(String rfcName)
at Microsoft.Adapters.SAP.InternalRfcMetadata..ctor(String originalRfcName, SAPConnection sapConnection)
at Microsoft.Adapters.SAP.SAPMetadataContract.ResolveOperationMetadata(String operationId, TimeSpan timeout, TypeMetadataCollection& extraTypeMetadataResolved)
at Microsoft.ServiceModel.Channels.Common.Design.MetadataCache.GetOperationMetadata(String uniqueId, Guid clientId, TimeSpan timeout)
at Microsoft.Adapters.SAP.SapFunctionMetadata.ResolveOperationMetadataUsingSdk(String absoluteName, String displayName, String funcName, String operationNamespace, SAPConnection sapConnection, Boolean isTrfc, MetadataLookup metadataLookup, TimeoutHelper timeoutHelper)
— End of inner exception stack trace —
at Microsoft.ServiceModel.Channels.Common.Design.AdapterAsyncResult.End()
at Microsoft.ServiceModel.Channels.Common.Channels.AdapterReplyChannel.EndTryReceiveRequest(IAsyncResult result, RequestContext& requestContext)
at System.ServiceModel.Dispatcher.ReplyChannelBinder.EndTryReceive(IAsyncResult result, RequestContext& requestContext)
at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.EndTryReceive(IAsyncResult result, RequestContext& requestContext)".

Of course followed by the generic warning messages:

The adapter "WCF-Custom" raised an error message. Details "Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_INVALID_HANDLE. AdapterErrorMessage=An exception has occurred on the listener while executing RfcWaitForRequest..".

The adapter "WCF-Custom" raised an error message. Details "System.ServiceModel.CommunicationObjectFaultedException: The communication object, Microsoft.ServiceModel.Channels.Common.Channels.AdapterReplyChannel, cannot be used for communication because it is in the Faulted state.".

The adapter "WCF-SAP" raised an error message. Details "The WCF service host at address "sap://CLIENT=[SAPClientID];LANG=[LANG];@A/[SAPServer]/[SystemID]?ListenerGwServ=[GWServer]&ListenerGwHost=[GwHost]&ListenerProgramId=[ProgID]&RfcSdkTrace=True&AbapDebug=False" has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host."

However this time Wireshark didn’t provide me additional information to help me diagnose and solve the problem.

CAUSE

Well I’m not an “SAP expert” neither I have the intension to become, I only want to know and understand the basic, so I can properly diagnose and resolve the different problems that may arise.

In this case, and sorry if I’m not giving all the precise technical details, the root cause of this problem is related to the Encoding type of the RFC Connection – Non-Unicode or Unicode (you may see the differences between them here)

Additional you can found some useful information in this two forum threads:

SOLUTION

You should keep this SAP transaction names in mind: SALE, SM59, WE20, WE21 and WE02 As my dear friend Nino Crudele mention in one of his posts, “in SAP exist thousands of transactions, the most important for us are, SALE, SM59, WE20, WE21, WE02.”

In this particular problem you should use SM59 transaction to check if all the configuration are set correctly like the: message type, program id, the channel and so on… but in special the Unicode settings

For that you should the following macro steps

  • Launch SAPGUI and login in the SAP System.
  • Execute the SM59 (Display and maintain RFC destinations) transaction
  • Select TCP/IP Connections option and pick RFC destination that we are using
    • Go to special options and check the "Character Width in Target System" in the Unicode tab.

SAPGUI-SM59-RFC-destination-TCP-IP-Connections-Unicode

Make sure the Unicode option is selected, otherwise to contact your SAP team and they must ensure that the RFC Connection is properly configured to use Unicode.

In my case, by changing the RFC Connection from non-unicode to unicode solved the problem that we were facing.

In my opinion there are a lack of documentation, or good documentation and many of the existing one is obsolete, regarding some topics/feature of BizTalk Server – Microsoft BizTalk Accelerator for RosettaNet is one of them.

Today while I was trying to extend Microsoft BizTalk 2013 Accelerator for RosettaNet (BTARN) with a new receive Partner Interface Process (PIP) schema I was receiving the following error in the event log:

Source module:
RNDisAssembler

Correlation information:

Description:
Receive pipeline rejected incoming message due to the following RNIF exception:
UNP.SCON.VALERR: A failure occurred while validating the service content.

Details:
The document specification <MyNamespace.MyPIP> from assembly <MyAssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=…> failed to load. Verify the schema for this document specification is deployed and is in the Global Assembly Cache.

Note: this same error can occur in previous or new versions of BizTalk Server.

Based on the received error and according to a possible cause described by Microsoft at Troubleshooting: Microsoft BizTalk Accelerator for RosettaNet Issues and Resolutions either the document namespace or the root node property the deployed schema for the instance that you are trying to extend is incorrect.

In fact this could be the issue but I found really odd because in the error details my DLL, containing the schema that I was trying to extend, was being properly referenced, nevertheless I confirmed that it was properly deployed… But as I suspected this wasn’t my problem.

Note: this behavior does not happen with PIP that include out-of-the-box with BTARN (in the Microsoft.Solutions.BTARN.Schemas.RNPIPs dll) only with new ones and only in the incoming process.

Microsoft-Solutions-BTARN-Schemas-RNPIPs

Fortunately for us we have an extended BizTalk Server: List of Errors and Warnings, Causes, and Solutions at TechNet Wiki, I usually update with some frequency and that I used as a reference, which gave me some clues to the final solution. Nick Heppleston mention in his blog that:

“RN Disassembler does in-fact attempt to validate the message contained within the Service Content against a deployed schema just like the standard XmlDisassembler. The message that our trading partner was sending did not validate and hence the RosettaNet Accelerator threw this error message; once we had corrected the schema and redeployed, the error went away.

This is certainly one to be aware of if you are developing custom PIP’s to use with the RosettaNet Accelerator: ensure that the message in the Service Content validates against your custom PIP schema”

Again this isn’t my problem, because the Schema was properly deployed in the system, I only mention this because is important for understanding how the BTARN engine/processes works.

CAUSE

By default BTARN App Pool Settings are configured to use .NET framework 2.0, doesn’t enable 32-bit applications and the application pool is in Classic mode

BTARN-App-Pool-default-Settings

Important for you to know is that the accelerator requires both an in-process and out of process host, both of which must be marked as "Authentication Trusted" and "32-bit only".

To run the BTARN End to End scenario you need two important things:

  • Enable the BTARN Application Pools for 32 bit.
  • Add a HTTP Handler for *.dll refering the IsapiModule Filters.

But what I found today is that when you want to extend BTARN with new incoming PIP’s, the artifacts generated are going to be .NET 4.0/4.5 unless Visual Studio is configured to do otherwise, which we really cannot control using BizTalk projects:

re-targeting-Visual-Studio-BizTalk-Projects-error

This means along with setting the application pools for the 32-bit the .NET setting must be set to match.

SOLUTION

To solve this issue you must:

  • Type “Internet Information Services (IIS) Manager” or “IIS” in the Windows Start screen and click in “Internet Information Services (IIS) Manager” option on Apps menu.
  • Expand the server and click on “Application Pools” to display available application pools in center panel.
  • Right-click on “BTARNAppPool” and select “Advanced Settings”.
  • On the “Advanced Settings” window:
    • Change the value of “.NET Framework version” from “v2.0” to “v4.0”.
  • Change the value of “Enable 32-bit Applications” from “False” to “True”.
  • And then click “OK”.

BTARN-App-Pool-correct-Settings

Advice: you should do the same for the “BTARNHttpReceivePool” application pool

After I fix these configurations I was able to successfully receive the PIP message from my external Partner.

Credits to LemMotlo – BTARN App Pool Settings for BizTalk 2010

A few days ago I wrote a post about these same warning messages from WCF-SAP Adapter: The adapter "WCF-SAP" raised an error message. Details "System.ServiceModel.CommunicationObjectFaultedException: The communication object, Microsoft.Adapters.Internal.LayeredChannelBindingElement.LayeredInboundChannel cannot be used for communication because it is in the Faulted state.

The adapter "WCF-SAP" raised an error message. Details "Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_INVALID_HANDLE. AdapterErrorMessage=An exception has occurred on the listener while executing RfcWaitForRequest..

The adapter "WCF-SAP" raised an error message. Details "The WCF service host at address "sap://CLIENT=[SAPClientID];LANG=[LANG];@A/[SAPServer]/[SystemID]?ListenerGwServ=[GWServer]&ListenerGwHost=[GwHost]&ListenerProgramId=[ProgID]&RfcSdkTrace=True&AbapDebug=False" has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host."

The adapter "WCF-SAP" raised an error message. Details "System.ServiceModel.CommunicationObjectFaultedException: The communication object, Microsoft.Adapters.Internal.LayeredChannelBindingElement.LayeredInboundChannel`1[System.ServiceModel.Channels.IReplyChannel], cannot be used for communication because it is in the Faulted state.

I told at the time that this are generic error messages and does not provide what is really the problem.

These warnings occurs, normally, when BizTalk is trying to connect to a SAP system to receive the IDOC and, again, most of the times these are related with connectivity issue or permissions between BizTalk and SAP.

CAUSE

Normally, the reason for these warnings could be any of the following options:

  • There may be a problem with the SAP system.
  • Maybe BizTalk Server don’t have the proper authorization to connect with that particular SAP program id
    • Check my previous post here
  • Also some times is a configuration problem in the Receive Location in your BizTalk Server

There are some options for you to try to find more details about this warnings:

  • You can use external tools, like Wireshark, to dig deep into network traffic and inspect individual packets for clues
  • You may enable the RfcSdkTrace in the WCF-SAP port configuration to be able to see all the traces.
  • Or another useful option is to setup WCF tracing to see the underlying error.

But what I realized today is that sometimes this warnings may occur and none of the assumptions described above fit into the actual problem.

While I was migrating and configuring one BizTalk solution, I forgot to start the incoming IDOC subscriber (in this case an orchestration) which caused my messages to stay Suspended in a Non-resumable way, raising a “no subscribers were found” error

The Messaging engine failed to process a message submitted by adapter:WCF-SAP Source URL: sap://CLIENT=[SAPClientID];LANG=[LANG];@A/[SAPServer]/[SystemID]?ListenerGwServ=[GWServer]&ListenerGwHost=[GwHost]&ListenerProgramId=[ProgID]&RfcSdkTrace=True&AbapDebug=False. Details: The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure.

And as you can see in the print screen bellow this error will generate also the appearance of the WCF-SAP warnings in the event viewer… although there is no problem in connectivity between BizTalk and SAP, and all the messages (IDOC) are being received and reached BizTalk

BizTalk-Server-2013-R2-WCF-SAP-Warnings-Event-Viewer-why

SOLUTION

In this particular case the solution is really simple, just create, or set correctly, one subscribe (Orchestration or send port with a filter) for the incoming IDOCs.

In the last few weeks I have been playing around with WCF-SAP adapter, I have many thing to write about it in terms of installation, configuration, communication and so on but I will start with this topic/problem.

While trying to create a WCF-SAP Receive port to be able to listener incoming IDOC from SAP system and despite the receive location be and stay enable in the BizTalk Administration Console I soon realized that the documents were not being picked up by BizTalk.

When I consulted the Event Viewer to check if there were additional information about the causes that were happening I found this three warning messages:

“The adapter "WCF-SAP" raised an error message. Details "System.ServiceModel.CommunicationObjectFaultedException: The communication object, Microsoft.Adapters.Internal.LayeredChannelBindingElement.LayeredInboundChannel`1[System.ServiceModel.Channels.IReplyChannel], cannot be used for communication because it is in the Faulted state.
at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Close()
at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.Close()".

“The adapter "WCF-SAP" raised an error message. Details "The WCF service host at address "sap://CLIENT=[SAPClientID];LANG=[LANG];@A/[SAPServer]/[SystemID]?ListenerGwServ=[GWServer]&ListenerGwHost=[GwHost]&ListenerProgramId=[ProgID]&RfcSdkTrace=True&AbapDebug=False" has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host."

“The adapter "WCF-SAP" raised an error message. Details "Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_FAILURE. AdapterErrorMessage=An exception has occurred on the listener while executing RfcWaitForRequest..
at Microsoft.ServiceModel.Channels.Common.Design.AdapterAsyncResult.End()
at Microsoft.ServiceModel.Channels.Common.Channels.AdapterReplyChannel.EndTryReceiveRequest(IAsyncResult result, RequestContext& requestContext)
at Microsoft.Adapters.Internal.LayeredChannelBindingElement.LayeredInboundChannel`1.
System.ServiceModel.Channels.IReplyChannel.EndTryReceiveRequest(IAsyncResult result, RequestContext& context)
at System.ServiceModel.Dispatcher.ReplyChannelBinder.EndTryReceive(IAsyncResult result, RequestContext& requestContext)”

BizTalk-WCF-SAP-Adapter-Event-Viewer-warnings

CAUSE

Well. unfortunately this errors are generic error messages and does not provide what is really the problem.

So my advice is to first check all the port configurations for any possible configuration mistakes. After that you should use external network tools that let you dig deep into network traffic and inspect individual packets, for example Wireshark.

On this particular case I found that the BizTalk Server didn’t have the proper authorization to connect with that particular SAP program id:

ERR*.1.registration of tp [PROGRAM ID] from host [BIZTALK SERVER] not allowed.720.SAP-Gateway.721.2.gwxxrd.c.3644..Thu Feb  5 18:46:11 2015….33844.SAP-Gateway on host [SAP SERVER] / [GWServer]…..*ERR*.

BizTalk-WCF-SAP-Adapter-wireshark-monitoring

SOLUTION

Unfortunately, I’m not a SAP expert and I don’t know exactly what to do in SAP, what I can tell you is that there is nothing wrong in your configuration, this is not a BizTalk problem Smile. What I could see in one of the SAP tools was that BizTalk was trying to connect but it was straight away disconnected.

So to solve this problem you must contact your SAP team to proper configure the access. Once is done everything will work fine, at least in this case it solved my problems.

Recently I work in a project when I need to communicate with Oracle database in which I encountered some platform configuration problems. In general, communicate with Oracle is very simple and somewhat similar to SQL Server.

In development phase I didn’t have any problem, but notice that before you start developing you need to make sure that you have BizTalk Adapter Pack installed and Oracle client (or at least Oracle Data Access Components (ODAC) – 32 and 64 bits) installed to use BizTalk Adapter for Oracle in your BizTalk environment.

The BizTalk Adapter Pack consists of the following adapters:

  • Microsoft BizTalk Adapter for Oracle Database (Oracle Database adapter).
  • Microsoft BizTalk Adapter for Oracle E-Business Suite (Oracle E-Business adapter).
  • Microsoft BizTalk Adapter for mySAP Business Suite (SAP adapter). This also includes the .NET Framework Data Provider for mySAP Business Suite (Data Provider for SAP).
  • Microsoft BizTalk Adapter for Siebel eBusiness Applications (Siebel adapter). This also includes the .NET Framework Data Provider for Siebel eBusiness Applications (Data Provider for Siebel).
  • Microsoft BizTalk Adapter for SQL Server (SQL adapter).

And you can found more information how to install it here: BizTalk 2013 Installation and Configuration – Installing BizTalk Adapter Pack (Part 12)

The Microsoft BizTalk Adapter for Oracle Database is a Windows Communication Foundation (WCF) custom binding. This binding contains a single custom transport binding element that enables communication with an Oracle database.

The following figure shows part of “BizTalk Oracle Adapter Architecture”:

BizTalk-Oracle-Adapter-Architecture

According to BizTalk official documentation, the support version of Oracle are:

  • Oracle database version 11.1,
  • Oracle database version 10.2,
  • Oracle database version 10.1,
  • Oracle database version 9.2

And supported client versions:

  • Oracle Data Access Components for Oracle Client 11.1.0.6 with Patch Set 11.1.0.7,
  • Oracle Data Access Components for Oracle Client 11.1.0.7

You can read more on how to install Oracle client here:

As I said earlier, I didn’t had any problem in development phase however in runtime I catch the following error:

The adapter failed to transmit message going to send port “SEND_Oracle” with URL “oracledb://connection”. It will be retransmitted after the retry interval specified for this Send Port. Details:”System.IO.FileNotFoundException: Could not load file or assembly ‘Oracle.DataAccess, Version=2.112.1.2, Culture=neutral, PublicKeyToken=89b483f429c47342’ or one of its dependencies. The system cannot find the file specified.

File name: ‘Oracle.DataAccess, Version=2.112.1.2, Culture=neutral, PublicKeyToken=89b483f429c47342’ —> System.IO.FileNotFoundException: Could not load file or assembly ‘Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342’ or one of its dependencies. The system cannot find the file specified.
File name: ‘Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342’
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.

So I tried to check in the GAC if the correct assemblies were there and I realized that the client add installed a different version of the Oracle Client: Oracle 11g R2.

BizTalk-Oracle-Client-GAC-dll

CAUSE

When installing the Oracle WCF Adapter for BizTalk there is a design time requirement to use Oracle.DataAccess Version 2.111.7.0.

Official the Oracle 11g R2 is not supported and again according to official documentation I should use one of the supported clients. However my client only had access to this version and did not want to use another. Although not officially supported you can connect to Oracle 11g R2 database and use Oracle 11g R2 client with minor configuration adjustments.

SOLUTION

One possible solution to fix this problem is configuring Assembly Binding Redirection in the machine configuration file (Machine.config):

  • 32-bit: c:\Windows\Microsoft.NET\Framework\[version]\config\machine.config
  • 64-bit: c:\Windows\Microsoft.NET\Framework64\[version]\config\machine.config

Note: You should apply this in both 32 and 64-bit machine configuration files.

By using the <assemblyBinding> Element for <runtime> that will contain all the information about assembly version redirection and the locations of assemblies.

In this case you should apply the following configurations:

<runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
        <assemblyIdentity name="Oracle.DataAccess"
          publicKeyToken="89b483f429c47342" />
 
        <bindingRedirect oldVersion="2.111.7.0" newVersion="2.112.1.2" />
      </dependentAssembly>
       </assemblyBinding>
</runtime>

Just to be sure, I add this configuration in both 32 and 64-bit in .NET Framework 2.0 and 4.0 machine configuration files.

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.”

WCF-Custom-Transport-Properties-Error

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. “.”

 

WCF-Custom-Ports-disabled

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:

WCF-Custom-Transport-Properties-list-bindings-without-sql

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>”:

machine-config-system-serviceModel-client

      • 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>”

machine-config-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.

WCF-Custom-Transport-Properties-list-bindings

WCF-Custom-Ports-enabled