By default the SOAP, HTTP, and HTTP-based WCF adapters (and .NET in general) open only two concurrent HTTP connections from each BizTalk server to any specific destination server.

For example, if you have a SOAP send port sending messages to http://www.contoso.com/SomeWebService.asmx, then by default each BizTalk server will open only two concurrent HTTP connections to http://www.contoso.com, no matter how many messages need to be sent.

This setting conforms to the IETF RFC for the HTTP 1.1 specification, and although it is suitable for user scenarios it is not optimized for high throughput.

Incresing the Number of Concurrent Connnections

To increase the number of concurrent connections, you can modify the entry in the BizTalk Server configuration file, BTSNTSvc.exe.config (or BTSNTSvc64.exe.config for 64-bit hosts), on each BizTalk server. You can increase this for the specific servers being called.

The following is an example of the configuration for the maximum connections property:

<configuration>
   <system.net>
      <connectionManagement>
         <add address=" http://www.contoso.com" maxconnection="20" />
         <add address = "http://www.northwind.com" maxconnection = "2" />
         <add address="*" maxconnection="10" />
      </connectionManagement>
   </system.net>
</configuration>

In this sample we are saying that:

• The endpoint contoso is configured with 20 concurrent connections
• The endpoint northwing is configured with 2 concurrent connections
• And the remaining are configured with 10 concurrent connections (change the default value)

Note:

Do not increase the value for the maxconnection parameter to such a large value that the Web server being called is overwhelmed with HTTP connections. Perform stress testing by sending requests to each destination Web server to determine a value for maxconnection that will provide good without overwhelming the target Web servers.

The default value for the “maxconnnection” property is 2, the maximum value that can be set for the “maxconnection” property for all URIs is 20.

Other considerations:

The “maxconnnection” property has no effect on the connection limit for making calls to local web services. Therefore, local web services always tend to give preference to the requests that come from the local computer over requests that come from other machines. This degrades the throughput of the web service for remote clients.

If the local web services are not making calls to any external systems and their web method processing time is considerably low, package them into a .NET library and call them from within your orchestrations. If those web services are calling external systems or take a considerable amount of processing time, move them off the BizTalk Server Group servers.

Related links

• Setting SOAP, HTTP, and HTTP-based WCF Adapters Concurrent Connections
• Book Pro BizTalk 2009
• Tuning IIS and ASP.NET Settings

(this post is mainly for personal tracking, sorry for the duplicate content)

Tags: BizTalk | SOAP | HTTP | WCF | Adapters | Configurations

This weekend after installing .NET Framework 4.0 in a BizTalk Server 2006 R2 environment, the BizTalk Adapter 2.0 for mySAP Business Suite started to throw the following error when he tried to receive data from the SAP system.

“Event Source: BizTalk Adapter v2.0 for mySAP Business Suite
Description: Error in Check Transaction: Failed to load the runtime.
(Exception from HRESULT: 0×80131700)”

CAUSE

This issue occurs after installing .NET Framework 4.0. The registration of the assembly used by mySAP Business Suite does not specify the correct version of the .NET Framework. When .NET Framework 4.0 is installed, the assembly will try to use the newer framework and then raise this error.

SOLUTION

You need to manually reregister the sapreceiver.dll (this DLL is usually in this folder: “C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\”). To accomplish that you need to:

• Execute cmd (Start → cmd)
• Type “cd C:\Windows\Microsoft.NET\Framework\v1.1.4322”
• And execute the following command to fixed the problem:
  • regasm.exe “C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\sapreceiver.dll”

Note: When you install .NET Framework 4.0 in older versions of BizTalk Server like BizTalk Server 2006 or 2006 R2, normally, you will also have problems with the Enterprise Single Sign-On Service for the exact same reasons and the solution is also to manually reregister the DLL but this time the SSOSQL.dll. To find more about this error check: Fixing BizTalk ENTSSO – Could not create SSOSQL. To fix the problem, reinstall SSO or try ‘regasm SSOSQL.dll’ from a Visual Studio command prompt.

References:

• Common Call Generators

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.

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

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:

• Table Operation on Oracle 11g XE with OracleDbBinding
• Installing the WCF Oracle DB adapter for BizTalk 2010

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.

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.

In this last week I’ve been migrating legacy custom adapters from previous BizTalk Versions (2004 and 2006) for recent version of BizTalk Server (2010 and 2013). In this particular case is an Isolated Adapter that in fact is a socket listener that will be listening on one or more TCP ports for a custom and private message format to address and solve an integration problem with legacy platforms of one of my clients. Working and creating custom adapter it’s always a funny task, it makes me remember and come back to my roots of .NET developer and how much I love this job.

Note: It’s also important to remember that recent version of BizTalk Server normally runs under 64-bit and because BizTalk Administration Console runs under 32-bits it’s imperative to register the adapter in both 32-bit and 64-bit versions of the BizTalk Adapter, at least if you want the adapter to run under 64-bit, nevertheless you always need to register under 32-bit.

If you are developing a custom adapter, you can register it with BizTalk Server by modifying and running one of the registry files included with the sample file adapter in the software development kit (SDK). Or, you can use the Adapter Registry Wizard to create a registry file. You can learn more about this topic here: Registering an Adapter.

Although it is a migration of an existing adapter which have worked correctly over several years I decide to optimize the adapter to run on new versions of NET Framework (4.0) and also to support 64-bit. The question and the main reason for this post is: How to properly register this custom BizTalk adapter?

How to properly register a custom BizTalk adapter

Again and this is very important:

• On a 32-bit machine, the registry (.reg) file generated by the Adapter Registration wizard must be run from the command prompt.
• On a 64-bit machine, the registry (.reg) file generated by the Adapter Registration wizard must be run both from the 32-bit and 64-bit command prompt.

So if you are in a 32-bit machine you only need to run the adapter registry (.reg) from the command prompt or even double-click in adapter registry (.reg) file.

However if you are in a64-bit machine you need extra steps:

• If run the adapter registry (.reg) from the command prompt or even double-click in adapter registry (.reg) file – this will register the adapter under 64-bit.

If you try to check and add this new adapter in the BizTalk Administration Console (Adding the Adapter to BizTalk Server) you will notice that the adapter will not be present and referenced in the Adapter drop box.

• So now you need to force to do the same in 32-bit, to accomplish that you need to open a 32-bit command prompt:
• Click Start.
• Type %windir%\SysWoW64\cmd.exe in Start Search box and press Enter
• Run the same adapter registry (.reg) from this command prompt

Again, if you try to check and add this new adapter in the BizTalk Administration Console you will notice that the adapter now will be present in the drop box.

This weekend after installing .NET Framework 4.0 in a BizTalk Server 2006 R2 environment, the BizTalk Adapter 2.0 for mySAP Business Suite started to throw the following error when he tried to receive data from the SAP system.

“Event Source: BizTalk Adapter v2.0 for mySAP Business Suite
Description: Error in Check Transaction: Failed to load the runtime.
(Exception from HRESULT: 0x80131700)”

CAUSE

This issue occurs after installing .NET Framework 4.0. The registration of the assembly used by mySAP Business Suite does not specify the correct version of the .NET Framework. When .NET Framework 4.0 is installed, the assembly will try to use the newer framework and then raise this error.

SOLUTION

You need to manually reregister the sapreceiver.dll (this DLL is usually in this folder: “C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\”). To accomplish that you need to:

• Execute cmd (Start → cmd)
• Type “cd C:\Windows\Microsoft.NET\Framework\v1.1.4322”
• And execute the following command to fixed the problem:
  • regasm.exe “C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\sapreceiver.dll”

Note: When you install .NET Framework 4.0 in older versions of BizTalk Server like BizTalk Server 2006 or 2006 R2, normally, you will also have problems with the Enterprise Single Sign-On Service for the exact same reasons and the solution is also to manually reregister the DLL but this time the SSOSQL.dll. To find more about this error check: Fixing BizTalk ENTSSO – Could not create SSOSQL. To fix the problem, reinstall SSO or try ‘regasm SSOSQL.dll’ from a Visual Studio command prompt.

References:

• Common Call Generators

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

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

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

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
• Sometimes, setting the Receive Timeout to its maximum value: 24.20:31:23.6470000 (24 days), may solve some cases (BizTalk Adapter Pack – SAP Binding ReceiveTimeout by Kent Weare)

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

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.

Last week while trying to generate from Visual Studio 2013 a schema of a custom SAP IDOC by:

• Right-click your BizTalk Server project, and then choose “Add | Add Generated Items | Consume Adapter Service”.
• In the “Consume Adapter Service” Add-in screen, select the sap adapter binding.
• You should set the connection URI to SAP server and after that click “Connect”
• From the “Select contract type” drop-down list, select “Service (Inbound operations)” option
• In the “Select a category” box, expand the IDOC node and select the IDOC that you want to retrieve, to see the IDOC message types in the “Available categories and operations” box.
• From the “Available categories and operations”, add the “Receive” operation to the "Added categories and operations" by selecting the operation and click the “Add” button
• And finally click “Ok” to generate the IDOC SAP schema

I got the following error:

“Error while retrieving or generating the WSDL. Adapter message: Details: ErrorCode=RFC_EXCEPTION. ErrorGroup=RFC_ERROR_APPLICATION_EXCEPTION. SapErrorMessage=SEGMENT_UNKNOWN. AdapterErrorMessage=Error returned by RfcCallReceiveEx while calling RFC: IDOCTYPE_READ_COMPLETE..

Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_EXCEPTION. ErrorGroup=RFC_ERROR_APPLICATION_EXCEPTION. SapErrorMessage=SEGMENT_UNKNOWN. AdapterErrorMessage=Error returned by RfcCallReceiveEx while calling RFC: IDOCTYPE_READ_COMPLETE..”

Server stack trace:

at Microsoft.Adapters.SAP.RFCException.HelperThrow(Int32 retCode, String additionalErrorMessage)
at Microsoft.Adapters.SAP.RfcOutboundInvoker.Invoke()
at Microsoft.Adapters.SAP.InternalIdocMetadata..ctor(String idocType, String cimType, String release, String version, MetadataLookup metadataLookup, SAPConnection sapConnection, TimeoutHelper timeoutHelper)
at Microsoft.Adapters.SAP.SAPMetadataContract.ResolveTypeMetadata(String typeId, TimeSpan timeout, TypeMetadataCollection& extraTypeMetadataResolved)
at Microsoft.ServiceModel.Channels.Common.Design.MetadataCache.GetTypeMetadata(String uniqueId, Guid clientId, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.MetadataLookup.GetTypeDefinition(String typeId, TimeSpan timeout)
at Microsoft.Adapters.SAP.SapIdocMetadata..ctor(String absName, String idocType, String cimType, String release, String version, SAPConnection sapConnection, Boolean generateFlatFileCompatibleIdocSchema, Boolean segmentTypeInFlatFileAnnotation, MetadataLookup metadataLookup, TimeoutHelper timeoutHelper)
at Microsoft.Adapters.SAP.SAPMetadataContract.ResolveTypeMetadata(String typeId, TimeSpan timeout, TypeMetadataCollection& extraTypeMetadataResolved)
at Microsoft.ServiceModel.Channels.Common.Design.MetadataCache.GetTypeMetadata(String uniqueId, Guid clientId, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.MetadataLookup.GetTypeDefinition(String typeId, TimeSpan timeout)
at Microsoft.Adapters.SAP.IdocOperationMetadata.ExportXmlSchema(XmlSchemaExportContext schemaExportContext, MetadataLookup metadataLookup, TimeSpan timespan, OperationParameterDirection direction)
at Microsoft.Adapters.SAP.IdocOperationMetadata.ExportInputXmlSchema(XmlSchemaExportContext schemaExportContext, MetadataLookup metadataLookup, TimeSpan timespan)
at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilderHelper.AddOperationSchema(OperationMetadata operationMetadata, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilder.SearchBrowseNodes(MetadataRetrievalNode[] nodes, WsdlBuilderHelper helper, TimeoutHelper timeoutHelper)
at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilder.GenerateOperationSchemas(WsdlBuilderHelper helper, MetadataRetrievalNode[] nodes, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilder.GetWsdl(MetadataRetrievalNode[] nodes, Uri uri, TimeSpan timeout)
at Microsoft.Adapters.SAP.SapCustomWsdlRetrieval.GetWsdl(MetadataRetrievalNode[] nodes, Uri uri, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Design.MetadataExchanger.ProcessMetadataGet(Message message, Uri target, TimeSpan timeout, MetadataLookup metadataLookup)
at Microsoft.ServiceModel.Channels.Common.Design.MetadataExchanger.ProcessMetadataMessage(Message message, Uri target, TimeSpan timeout, MetadataLookup metadataLookup, Message& replyMessage)
at Microsoft.ServiceModel.Channels.Common.Channels.AdapterRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.ServiceModel.Channels.IMetadataRetrievalContract.GetMetadata(MetadataRetrievalNode[] nodes)
at Microsoft.ServiceModel.Channels.Tools.MetadataSearchBrowse.MetadataPanel.GetWsdl(MetadataRetrievalNode[] nodes)
at Microsoft.ServiceModel.Channels.Tools.MetadataSearchBrowse.MetadataUserControl.GetWsdl()

CAUSE

The SAP adapter uses the IDOCTYPE_READ_COMPLETE RFC to retrieve the metadata for the Receive operation for an IDOC. Invoking this RFC requires specific user permissions in the SAP system. To generate metadata, if you have connected to the SAP system using a credential that does not have permission to invoke the IDOCTYPE_READ_COMPLETE RFC, the SAP adapter gives an error.

So in order to demystify problems you should:

• Make sure that your connection URI are well set
• And you should try to import a schema from a standard IDOC, like INVOIC01, STATUS or ORDER01

If you are unable to import the schemas then you have a different problem from what I’m addressing here and you probably need to contact your SAP team to try to diagnose the problem, it probably may be lack of permissions. But normally in this cases you will receive a:

• SapErrorMessage= OBJECT_UNKNOWN.

In my case I was able to import all the standard IDOC from SAP, however as I stated before I was trying to import the schema from a custom SAP IDOC created by my customer and I got instead a:

• SapErrorMessage=SEGMENT_UNKNOWN

Which means, that while importing the IDOCTYPE_READ_COMPLETE RFC was not properly identifying some segments of the IDOC.

After validating with my SAP team we realize that some segments were not in the state “released” in SAP, this may not be the correct SAP interface logic but just to give you an idea here are some SAP print screens:

Note: that all custom segments used in the IDOC must be released in SAP before you can import and use them in BizTalk Server.

SOLUTION

Well the only solution is to contact you SAP team and they must be sure that all segments of the IDOC that you are trying to import are released correctly.

Unfortunately we don’t have the segment information in question, but more likely it is some custom segment that they created.

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.

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

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:

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

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

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:

• IDOC_INBOUND_ASYNCHRONOUS could not be resolved against SAP system because its metadata could not be obtained
• IDOC_INBOUND_ASYNCHRONOUS could not be resolved against SAP system because its metadata could not be obtained

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.

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 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&quot; 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:

• http://Microsoft.LobServices.Sap/2007/03/Idoc/3/IDOC_NAME//711/Receive#Receive

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

• http://Microsoft.LobServices.Sap/2007/03/Idoc/3/IDOC_NAME//740/Receive#Receive

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)

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

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

This series of post will explain in detail – a step-by-step guide – how to install and configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) on a standalone environment running Windows Server 2012 R2 and BizTalk Server 2013 R2.

RosettaNet is a business protocol that enables enterprises to conduct business over the Internet. The RosettaNet Consortium (http://www.rosettanet.org) is an independent, nonprofit consortium of major information technology, electronic component, and semiconductor manufacturing companies working to create and implement industry-wide, open process standards. These processes are designed to standardize the electronic business interfaces used between participating supply chain partners. The RosettaNet Implementation Framework (RNIF) specification is a guideline for applications that implement RosettaNet Partner Interface Processes (PIPs). These PIPs are standardized electronic business processes used between trading partners. You can find all the Framework specification and the list of PIPs available, as well the PIPs contract (DTD and documentation) in the RosettaNet Consortium website: http://www.rosettanet.org.

BTARN will extend the existing BizTalk Server capabilities allowing you to run RosettaNet Partner Interface Processes (PIPs) and by doing that, this will allow you to exchange RosettaNet documents with your business partners, by simple providing a set of orchestrations, schemas, tools and related helper assemblies. BTARN supports the RosettaNet Implementation Framework (RNIF) versions 1.1 and 2.0.01. However installing the accelerator can be difficult if you do not plan correctly for it.

This guide will provide you comprehensive guidelines that will help you plan the installation and configuration of BTARN.

Assumptions and out of scope

It will be assumed that all the BTARN software requirements already have been installed. This guide will use BizTalk Server 2013 R2 running over Windows Server 2012 R2 with all the latest critical Windows updates from Microsoft and latest Cumulative Updates for BizTalk Server installed.

Important considerations before you install the RosettaNet Accelerator

There are some important considerations or suggestions, since some of these operations are not mandatory, that we can and should set before starting the installation and configuration Microsoft BizTalk 2013 R2 Accelerator for RosettaNet (BTARN).

Software Requirements

The following table lists the software that BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) requires to run correctly. BTARN has the same software and hardware requirements as BizTalk Server 2013 R2.

Things to be taken care

When you are planning to install Microsoft BizTalk 2013 R2 Accelerator for RosettaNet (BTARN), you need to be very careful with certain, documented and non-documented, notes or necessary configuration in your existing BizTalk environment. These are the notes in the official documentation:

• Both BTARN and BizTalk Server 2013 R2 require Microsoft .NET Framework 4.5 as software pre-requisite.
  • If you have multiple versions of .NET Framework installed on your computer, make sure that the BtarnAPP Web application is referencing .NET Framework 2.0. You can configure this by using the Internet Information Services (IIS) Manager.
  • Personal note: Despite the official documentation saying that the BtarnAPP Web application need to refer .NET Framework 2.0, what I noticed is that it will work properly in .NET 4.0.
• The BizTalk Host Instance Account and the BizTalk Isolated Host Instance Account should be the same. Otherwise, BTARN will not function correctly.
• BTARN allows you to add only individual service accounts, and not groups, to the BizTalk Server Administrators group or the BizTalk Application Users group.
• You need to create a WebService extension for BTSHTTPReceive.dll, configuring the IIS isolation mode.
  • For more information, see the “404 Not found error when sending a HTTP request” entry in the “Troubleshooting: Issues and Resolutions” topic at http://go.microsoft.com/fwlink/?LinkId=188560. Also, see the “How to Configure IIS for an HTTP Receive Location” topic in BizTalk Server Help.
• Add your server (http://<server name>) to the Local Internet zone in the Internet Explorer security options.
• If a remote SQL instance using non default port is used for configuring BTARN, then the SQL Server Client Tools must be installed locally.
  • For details, see BizTalk Server Installation Guide for multicomputer environment at http://go.microsoft.com/fwlink/?LinkId=186857.
• A separate group must be used for role – BizTalk Administrator, BizTalk Host Users, and BizTalk Isolated Host Users during the configuration of BizTalk Server.
• BTARN does not support the use of alias created for SQL instance to configure the BTARN database.

Unfortunately for us, there are still plenty of notes or the necessity to perform additional settings in our environment so that the minimal conditions are guaranteed for BTARN be able to run properly:

• Installation
  • RosettaNet 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) unfortunately for us this group doesn’t exist anymore, so you need to create it manually. Otherwise, BTARN installation will fail.
• Host Instances
  • The accelerator requires both in-process and isolated host to be marked as “Authentication Trusted” and “32-bit only“. Otherwise, BTARN installation will fail.
    • Very important: The accelerator requires both in-process and isolated host to be marked as “Authentication Trusted” (this setting is off by default when you create a new host) and “32-bit only“.
      • And the reason why in-process need to be also trusted is that the BizTalk Host Instance Account and the BizTalk Isolated Host Instance Account should be the same and you cannot use the same account for trusted and untrusted hosts. Otherwise it was only necessary to mark the isolated host as trusted.
  • The BizTalk Host Instance Account and the BizTalk Isolated Host Instance Account should be the same. Otherwise, BTARN will not work correctly.
    • If the service account set for the BTARN application pools is different from the Isolated Host account, BTARN will not be able to process incoming messages correctly. When the receive “.aspx” page calls the pipeline, the pipeline will not have access to the appropriate certificates. Therefore, it will not be able to decrypt the incoming message or validate the signature. It will also not be able to access the MessageBox database.
  • Do never use Full Qualify domain name in the Logon credentials. Otherwise, BTARN will not work correctly.
  • Make sure the BTARN in-process host is the default send handler of HTTP Adapter and the general Default Host in the group
    • Important: Make sure the BTARN in-process host is the default send handler of the HTTP Adapter. When you create a Partner it will create two send ports and it will use the default send handler for the HTTP Adapter: If the BTARN in-process host is not the default handler, the engine will use the default one instead and then you need to stop the BTARN process, unbinding the send ports, reconfigure the send handler and only then start everything again, so this will induce a small shutting down in our environment.
    • When installing the accelerator, it will install all the assemblies into the default BizTalk Application, and will attempt to configure all orchestrations and ports to run in the first host it finds that is marked as “Authentication Trusted”.  To ensure everything is installed to the host instances you need to:
      • Temporarily make the trusted host instance as the default instance (not recommended).
      • Or if you want the assemblies to be in a different application than the default, create a new application in the BizTalk Administration Console and set it as the default during the installation.
• BAM
  • Microsoft provide a Tracking file with the activity definitions. However: you need to create your custom BAM views
    • BTARN supports enhanced tracking using BizTalk Activity Monitoring (BAM).
      • Right-click the BizTalk Accelerator for RosettaNet node and then click Properties.
      • In the Global Properties dialog box, select Enable BAM Tracking to enable tracking, or clear this option to disable it.
    • Microsoft provide a Tracking file with the activity definitions however:
      • The tracking points are not customizable;
      • Do not change activity definitions.
      • You only can Manage BAM views and deployment.
• Databases Maintenance
  • BTARN database are not backuped by default
    • Fortunately for us, Microsoft provides two SQL Scripts that you need to run against this databases in other to extend the standard backup mechanisms but you also need to modify the adm_OtherBackupDatabases table to include a row for each of your custom databases.
      • C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\Schema
        • Backup_Setup_All_Procs.sql
        • Backup_Setup_All_Tables.sql
      • Also you need to modify the adm_OtherBackupDatabases table to include a row for each of your custom databases
  • There are no maintenance processes to clean up BTARN databases so you need to create these maintenance processes according to the legal requirements of your company/organization, be aware that:
    • BTARN databases can grow quickly because they contain the PIP XML that you are processing
    • They can affect the performance of your environment
    • They are important

Related links:

• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Preparing your BizTalk Server 2013 R2 environment for BTARN (Part 2)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Install and configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) (Part 3)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Additional Configurations of BizTalk 2013 R2 Accelerator for RosettaNet (Part 4)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Troubleshooting Your Installation (Part 5)

This may be the most important section in order for you to accomplish a successfully BTARN installation and configuration and at the same time preventing further additional problems. Again, the installation and configuration process is very simple, however be able to correctly configure the accelerator in order to work properly can be difficult if you do not plan correctly for it.

This part will focus on how to prepare your existing BizTalk Server 2013 R2 environment for BTARN.

Create a new account to be associated with the BTARN hosts

As mention before the accelerator requires both BTARN in-process and BTARN isolated host to be marked as "Authentication Trusted" and "32-bit only“ and the account associated with these Host instances should be the same, otherwise, BTARN will not work correctly.

"Authentication Trusted" is off by default when you create a new host, or if you don’t specify in the BizTalk Server configuration process that you want this setting enable. And BizTalk will not allow you to use the same user account for both trusted and untrusted hosts. 

Also because, for security aspects, we don’t want to have all our host instances marked as "Authentication Trusted" it is necessary for us to create:

• A new user account that will be associated to the trusted hosts.
• And a new user account (support account) that will help us in the switching host process from untrusted to trusted.

Note: Sometimes it is often easier/more desirable to create a new User Group with the same privileges of the “BizTalk Application Users” group (let’s say: BTARN BizTalk Application Users) and a new user account that will be associated with this group to run all the BTARN processes.

To accomplished that we need to:

• Press the “Windows key” to switch to the Start screen, type “Computer Management” and click in “Computer Management” option from the Search menu
• On the left three of the “Computer Management” screen,, expand “System Tools à Local Users and Groups” and select “Users”
• Right click under “Users” folder, and then select “New User…”

• In the “New User” dialog box, do the following:
• User name: Type the user name. For this guide let’s assume “btsadmin”
• Full name: Optionally, type a full user name for this account.
• Description: Optionally, type a description for this account.
• Password: Type a password for the user.
• Confirm password: Confirm the password for the user.
• And leave only the “Password never expires” check box enabled

Note: Make sure that the user that you are creating (btsadmin) it has:

• The same privileges of the existent BizTalk Admin Account (in my case or in developer environments)
• It has the same privileges of the existent Account associated in the “BizTalk Application Users” group

Repeat the same steps to create another account for support, let´s call it “supportacc”:

• This account will be deleted after the installation/configuration
• Normal user account, it doesn’t requires any particular privileges

(Re)Configure BizTalk Host and Host Instances to support BTARN

BizTalk Server provides great flexibility for addressing high availability, because you can strategically dedicate logical hosts to run specific areas of functionality such as receiving messages, sending messages or processing orchestrations.

By default the BizTalk configuration will create two BizTalk Host and Host Instances:

• BizTalkServerApplication: This is the default Host and Host Instance created during configuration that will do all the work on the BizTalk Server, i.e. is the default send and receive handler for all installed adapters (other than HTTP, WCF (BasicHttp, CustomIsolated, WebHttp and WSHttp) and SOAP Receive Handlers), and is also used for processing orchestration and tracking.

• BizTalkServerIsolatedHost: The logical container for HTTP, WCF (BasicHttp, CustomIsolated, WebHttp and WSHttp) and SOAP Receive Handlers.

Although a single BizTalk Host can contain items that receive, send, and process messages, it is considered a best practice to create different hosts for each function to create security boundaries and for easier management and scalability. In particular, we recommend that you use different hosts for processing and for receive/send operations, and that you separate trusted and non-trusted items.

While there are benefits to creating additional host instances, there are also potential drawbacks if too many host instances are created.

• Each host instance is a Windows service (BTSNTSvc.exe), which generates additional load against the MessageBox database and consumes computer resources (such as CPU, memory, threads).

Regarding to BTARN installation and configuration process, it becomes more difficult to configure when we have multiple host and host instances created, compared with the default configuration (with only two BizTalk Host and Host Instances) and the reasons are:

• The accelerator requires both in-process and isolated hosts that will run BTARN artifacts to be marked as "Authentication Trusted" (this setting is off by default when you create a new host), "32-bit only” and should run under the same service account.

To ensure everything is installed and configured properly we have different options:

• Temporarily mark all the hosts as "Authentication Trusted" and the "32-bit only” host as the default host
• Of course, this is not the recommended solution, but is the easier one.
• Or we need to properly configure the hosts and host instances to handle correctly BTARN.

Because I have all my environments, even my developer environments, with host separation according to some of the best practices described here: BizTalk Server Best Practices: Create and Configure BizTalk Server Host and Host Instances. I need to properly configure the hosts and host instances to handle correctly BTARN, to accomplish that we need to:

• Press the “Windows key” to switch to the Start screen, type “BizTalk Server” and click in “BizTalk Server Administration” option from the Search menu
• In the console tree, expand “BizTalk Server Administration”, expand the “BizTalk group”, click “Platform Settings”, and then click “Host Instances”.
• Now we need to change all the host instances, with the exception of “BizTalkServerApplication” and “BizTalkServerIsolatedHost” (these two will be running the BTARN artifacts), to run under this last user that we just created in the last section: “btsadmin”
• Right-click in the host instance name, for example “BizTalkServerReceiveHost”, and select “Stop”

• In the details pane, right-click the host instance you want to modify, and then click “Properties”, for example: “BizTalkServerReceiveHost”
• In the “Host Instance Properties” dialog box, click “Configure” to modify the service account information.

• Change the logon credentials to run under the “btsadmin” account

• Do the rest for all the host instances that you have with the exception of “BizTalkServerApplication” and “BizTalkServerIsolatedHost” host instances.

The next step is to configure the both BTARN in-process and isolated hosts to be marked as "Authentication Trusted" and "32-bit only” but because we still have two non-trusted host instances running with the same account that we need to mark as trusted and we cannot have the same account being used as "Authentication Trusted" and non "Authentication Trusted", we first need to provisionally change one of the host instance, to use the “supportacc” account, we can use for example the “BizTalkServerIsolatedHost” host instance

• Right-click in the “BizTalkServerIsolatedHost” name, and then click “Properties”
• In the “Host Instance Properties” dialog box, click “Configure” to modify the service account information.
• Change the logon credentials to run under the “supportacc” account

Now we need to change the “BizTalkServerApplication” Host configuration and mark it as:

• "32-bit only” à by default is already marked as 32-bit only
• And "Authentication Trusted"

To accomplish that we need to:

• In the BizTalk Server Administration console tree, under “Platform Settings”, click “Hosts”.

• In the “Hosts” pane, right-click the host that is not trusted, in this case “BizTalkServerApplication”, and then click Properties.
• In the “Host Properties” dialog box, on the “General” tab:
• Verify if the “32-bit only” check box is selected, if not select the “32-bit only” check box
• Verify if the “Authentication Trusted” check box is selected, if not select the “Authentication Trusted” check box

• And then click OK.
• Now do the exact same to the “BizTalkServerIsolatedHost” host

Because the BTARN BizTalk Host Instance Account and the BizTalk Isolated Host Instance Account should be the same we need to change the “BizTalkServerIsolatedHost” host instance logon account, which we momentarily configured to run under the “supportacc” account to be the same of the “BizTalkServerApplication” host instance: “Administrator”.

• In the BizTalk Server Administration console tree, under “Platform Settings”, click “Host Instances”.
• Right-click in the “BizTalkServerIsolatedHost”, and then click “Properties”
• In the “Host Instance Properties” dialog box, click “Configure” to modify the service account information.
• Change the logon credentials to run under the “Administrator” account

Finally you should restart all the BizTalk Host instances services.

Note: Because we don’t really want to run all our isolated processes under a trusted host instance, I recommend you to create a new Isolated Host and Host Instance that you should configured as non-“Authentication Trusted” and set to run under the “btsadmin” account (in this scenario). For that operation please check the following MSDN articles:

• How to Create a New Host
• How to Add a Host Instance

Configure the Default Host and Default Handlers

The last concern that you need to have regarding with BizTalk Host and Host instances are the:

• General Default Host in the group
• And the Default send handler of HTTP Adapter and SQL Adapter

Again, as explained previously, when we are installing the RosettaNet Accelerator, the installer will install all the BTARN assemblies into the default BizTalk Application: “BizTalk Application 1”, and will attempt to configure all the orchestrations and ports (receive and send) to run not with the first host that it finds that is marked as "Authentication Trusted" but instead with the default host and handlers that are configured in the environment.

To ensure that everything will be configured properly, or at least minimize some problems, with the BTARN configuration process you need to:

• Make sure the BTARN in-process host (BizTalkServerApplication) is the general Default Host in the group

• Make sure the BTARN in-process host (BizTalkServerApplication) is the default send handler of the SQL Adapter (yes the old obsolete one – not the WCF-SQL) and it is also associated with the receive handler.

• Make sure the BTARN in-process host (BizTalkServerApplication) is the default send handler of the HTTP Adapter.

• And of course the BTARN isolated host (BizTalkServerIsolatedHost) is configured to be the receive handler of the HTTP Adapter.

Create the IIS_WPG group

When configuring BTARN on Windows 8.1, Windows Server 2012, and Windows Server 2012 R2, you must create the IIS_WPG group manually. We need this because RosettaNet accelerator 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 in the SO listed above, so you need to create it manually. Otherwise, BTARN installation will fail.

To accomplished that you need to:

• Press the “Windows key” to switch to the Start screen, type “Computer Management” and click in “Computer Management” option from the Search menu
• In the console tree, expand “System Tools”, expand the “Local Users and Groups”, and then click “Groups”.

• Right click under “Groups” folder, and then select “New Group…”
• In the New Group dialog box, set the following parameters:
• In Group name, type “IIS_WPG”.
• In Description, type “RosettaNet IIS group”

• Click “Create”, and then click “Close”.

Create a WebService extension for BTSHTTPReceive.dll

BTARN uses the HTTP adapter to send (left picture) or receive (right picture) PIPs to and from different partners:

If the PIP process is asynchronous, each message transmission over the Internet occurs on a different HTTP connection. If the PIP is synchronous, each message transmission occurs on the same connection, which the HTTP adapter holds until the process is complete.

For that reason we need to create a WebService extension for the BTSHTTPReceive.dll and configure the IIS isolation mode. To accomplish that we need to:

• Press the “Windows key” to switch to the Start screen, type “IIS” and click in “Internet Information Services (IIS) Manager” option from the Search menu
• In Internet “Information Services (IIS) Manager” screen, select the root Web server entry. In the “Features View”, double-click “Handler Mappings”

• And then in the Actions pane, click “Add Script Map…”

• In the “Add Script Map” dialog box, in the “Request path” field, type “BtsHttpReceive.dll”.
• In the “Executable” field, click the ellipsis (…) button and browse to “C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2 \HttpReceive”.
• And select “BtsHttpReceive.dll” and then click “OK”.
• In the “Name” field, type “BizTalk HTTP Receive”

• Then click “Request Restrictions”.
• In the “Request Restrictions” dialog box, click the “Verbs” tab and then select “One of the following verbs”.
• Enter “POST” as the verb.

• On the “Access” tab, select “Script”, and then click “OK”.

• When prompted to allow the ISAPI extension, click “Yes”.
• Do the exact same process this time using the “C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\HttpReceive64\BTSHTTPReceive.dll”

Related links:

• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Important considerations before you install BTARN (Part 1)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Install and configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) (Part 3)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Additional Configurations of BizTalk 2013 R2 Accelerator for RosettaNet (Part 4)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Troubleshooting Your Installation (Part 5)

This part will focus on installing and configuring Microsoft BizTalk 2013 R2 Accelerator for RosettaNet.

Make sure that you have installed all the prerequisites and prepared you environment for the RosettaNet accelerator.

Install Microsoft BizTalk 2013 R2 Accelerator for RosettaNet

BizTalk Accelerator for RosettaNet is available in the BizTalk Server installation disk (ISO) under: “BizTalk Accelerators” folder.

• Access to “BizTalk Accelerators” folder in the BizTalk Server ISO, and then run the Setup.exe file.

• On the Start page, click “Microsoft BizTalk 2013 R2 Accelerator for RosettaNet”

• On the “Installation Wizard” screen for Microsoft BizTalk Accelerator for RosettaNet, click “Install”.

• On the “Customer Information” page, type your user name, organization, and the product key, and then click “Next”.

• On the License Agreement page, read the End User License Agreement, and then click Accept.

Note: If you do not accept the license agreement, you cannot continue with the installation.

• On the “Installation Options” page, select “Complete” for a full installation and ensure the installation path is correct, and then click “Next”.
• Or if you wish so, you can also customize the features that you want to install or perform apartial installation by selecting the “Custom” option
• Note: If you select Custom, select the components to install from the Custom Installation page. If you select to install SDK or Documentation components only, you must have .NET Framework 4.5 installed before running the setup program.

• On the “Summary” page, review the components you are installing, and then click “Install”.
• The Installation Progress screen displays the progress of the installation procedure.

• On the “Installation Completed” page, ensure the Run Configuration Wizard box is selected, and then click “Finish”.

• The BTARN Configuration Wizard opens. Next, you configure BTARN.

Important:

• If you perform a custom installation to install only the BTARN HTTP Front End feature, BTARN configuration may fail after setup is complete, displaying the error message "Failed to create object for feature: WebApp". If this occurs, you need to copy two files (Microsoft.VC80.ATL.manifest and atl80.dll) from a computer with BizTalk Server 2013 R2 installed on it, to the computer where you installed the BTARN HTTP Front End feature.
• If Visual Studio 2012 is installed on the same computer as BizTalk Server, the source folder for the two files is <drive>:\Program Files\Microsoft Visual Studio 11.0\VC\redist\x86\Microsoft.VC100.ATL. If Visual Studio 2012 is not installed on the BizTalk server, the source folder for the two files on the BizTalk server is a folder under <drive>:\WINDOWS\WinSxS. The version of the files should be 8.0.50727.42. The destination folder on the computer where you have installed the HTTP Front End feature is the BTARN installation directory (by default, <drive>:\Program Files (x86)\Microsoft BizTalk 2013 R2 Accelerator for RosettaNet).
• After you have copied these files to the computer with the HTTP Front End feature installed, rerun Configuration.exe.

Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet

Note: Before configuring BTARN, Make sure that you have installed all the prerequisites and prepared you environment for the RosettaNet accelerator. In specially:

• Make sure you map .NET Framework 4.0 under Handler Mappings in IIS.
• Also, when configuring BTARN on Windows 8.1, Windows Server 2012, and Windows Server 2012 R2, you must create the IIS_WPG group manually.

To configure BTARN using Basic Configuration:

• Press the “Windows key” to switch to the Start screen, type “RosettaNet”, right-click “BizTalk 2013 R2 Accelerator for RosettaNet Configuration” option from the Search menu, and then click Run as Administrator.
• On the “Microsoft BizTalk 2013 R2 Accelerator for RosettaNet” Wizard page:
• Select the “Basic configuration” option to configure the server with default settings
• Or “Custom configuration” to configure the server using advanced configuration options.
• In the “Database server name” text box under “Database” properties, verify that the server name displayed is correct.
• In the “Service credential” properties, type the “User name” and “Password” for the account that the configure BTARN will run under.

• Click “Configure”.
• If your account has administrative privileges, click “Yes” to proceed with the configuration.

• On the “Summary” page, review the components you are installing, and then click “Next”.

• On the “Configuration Completed” page, click “Finish”.

Note:

• If you selected Custom configuration in step 1, perform the following steps:
• To configure the runtime, in the Microsoft BTRAN Configuration dialog box, click “Runtime” in the left pane:
• In the right “Runtime” pane, click “Enable the Runtime feature on this computer”.
• To join an existing database group, clear “Do you want to create a new database group”.
• Select the appropriate Web server name, port number, data stores, Application Pool service account, and BizTalk HTTP Receive virtual folder.
• To configure the WebApps feature, in the Microsoft BTRAN Configuration dialog box, click “WebApps” in the left pane:
• In the right “WebApps” pane, click “Enable the Runtime feature on this computer”.
• Enter the appropriate BizTalk Server name and port number, or select the defaults.
• Select the appropriate Web application virtual folder.
• Click Apply Configuration.

Note: BTARN configuration will fail if you use a special character in the name of any of the BTARN databases.

Related links:

• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Important considerations before you install BTARN (Part 1)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Preparing your BizTalk Server 2013 R2 environment for BTARN (Part 2)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Additional Configurations of BizTalk 2013 R2 Accelerator for RosettaNet (Part 4)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Troubleshooting Your Installation (Part 5)

This section provides detailed information about additional configurations of BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) that you need to do before you start using it:

• Start BTARN orchestrations, send ports, and receive locations, manually. These do not start automatically when you install and configure BTARN.
• Note: You need to start the “PrivateInitiator_To_LOB” and “PrivateResponder_To_LOB” send ports before you can start the “PrivateInitiatorProcess” and “PrivateResponderProcess” orchestrations.
• On computers where you have configured an Internet Information Services (IIS) virtual server with Secure Sockets Layer (SSL), you must configure the virtual server to accept the client certificate. For more information, see the "Step 4: Enabling Secure Sockets Layer in IIS" topic in the MSDN Double Action Tutorial.

Start BTARN orchestrations, send ports, and receive locations

• Start “BizTalk Server Administration” console as an administrator.
• In the “BizTalk Server Administration Console”, in the left pane, expand “BizTalk Group”, expand “Applications”, and then expand “BizTalk Application 1”.
• Click “Send Ports”.
• In the right pane, for each BTARN send port that is not started, right-click and then click “Start”:
• “PrivateInitiator_To_LOB” Static One-Way send port
• “PrivateResponder_To_LOB” Static One-Way send port
• Click “Receive Locations”.
• In the right pane, for each BTARN receive location that is not started, right-click and then click “Enable”.
• “Async_Http_Receive” HTTP location
• “Sync_Http_Receive” HTTP location
• “LOB_To_PrivateInitiator” SQL location
• “LOB_To_PrivateResponder” SQL location
• Click “Orchestrations”.
• In the right pane, for each BTARN orchestration that is not started, right-click and then click “Start”
• Microsoft.Solutions.BTARN.CommonTypes.OdxTypes
• Microsoft.Solutions.BTARN.CommonTypes.SendExceptionToLOB
• Microsoft.Solutions.BTARN.CommonTypes.SendExceptionToPrivateProcess
• Microsoft.Solutions.BTARN.PublicResponder.PublicResponderProcess
• Microsoft.Solutions.BTARN.PublicResponder.PublicResponderV11
• Microsoft.Solutions.BTARN.PublicInitiator.PublicInitiatorProcess
• Microsoft.Solutions.BTARN.PublicInitiator.PublicInitiatorV11
• Microsoft.Solutions.BTARN.PrivateResponder.PrivateResponderProcess
• Microsoft.Solutions.BTARN.PrivateInitiator.PrivateInitiatorProcess

However, sometimes, from some strange unknown reasons, even if the installation/configuration end up successfully, some of the artifacts may not be properly created/deployed in your BizTalk environment, for example ports and/or bindings. This situation already happen to me twice in several installations.

In this particular problem, the reason was that, because the configuration process has their half dozens of failures/limitations/bugs, some of the binding files used by BTARN (generated by configuration/installation process) was configure to use the default host – that in my case it was incorrectly defined as “BizTalkServerApplication64Host”, a non-BTARN host – in the receive and send ports. The problem was that this particular host is used only to process orchestrations and it is not associated with any BizTalk adapter.

The solution in this situations is to understand the problem and manually fix. Fortunately for us Microsoft made available all the BTARN resources: DLL, source code, binding files and so on in the BTARN installation folder, which by default is:

• “C:\Program Files (x86)\Microsoft BizTalk 2013 R2 Accelerator for RosettaNet”

It is recommend to validate if all the resources are correctly deploy and configured in your BizTalk Server. I already face an issue where I found out after finish the installation/configuration process that none of the DLL’s where deployed correctly in the environment:

• In the “BizTalk Server Administration Console”, in the left pane, expand “BizTalk Group”, expand “Applications”, and then expand “BizTalk Application 1”.
• Click “Resources” and you should find there 11 BTARN DLL’s (otherwise you need to manually deploy the missing ones)
• Microsoft.Solutions.BTARN.CommonTypes.dll
• Microsoft.Solutions.BTARN.GlobalSchemas.dll
• Microsoft.Solutions.BTARN.PipelineReceive.dll
• Microsoft.Solutions.BTARN.PipelineSend.dll
• Microsoft.Solutions.BTARN.PrivateInitiator.dll
• Microsoft.Solutions.BTARN.PrivateResponder.dll
• Microsoft.Solutions.BTARN.PublicInitiator.dll
• Microsoft.Solutions.BTARN.PublicResponder.dll
• Microsoft.Solutions.BTARN.Schemas.RNIFv11.dll
• Microsoft.Solutions.BTARN.Schemas.RNIFv201.dll
• Microsoft.Solutions.BTARN.Schemas.RNPIPs.dll

Note: You will find these DLL’s in the BTARN installation folder under the “Bin” folder: “C:\Program Files (x86)\Microsoft BizTalk 2013 R2 Accelerator for RosettaNet\Bin”

• The second step is to fix and import the binding files.
• Note: You will find these Binding Files in the BTARN installation folder under the “Bin” folder.
• Note: Before you import it you need to manually fix manually, that way the Preparing your BizTalk Server 2013 R2 environment for BTARN section is very important to avoid these type of problems after the installation and configuration process.

• In this case to solve the problem that you need to:
• Right-click in the “BizTalk Application 1”, and select the option “Import à Bindings…” and import the following binding files that you will find in the BTARN Bin folder:
• CommonTypesBinding
• PrivateInitiatorBinding
• PrivateResponderBinding
• PublicInitiatorBinding
• PublicResponderBinding
• The next step is to make sure that all the artifacts (orchestrations, send ports and receive locations) are associated with the BTARN hosts:
• BizTalkServerApplication
• BizTalkServerIsolatedHost
• Click “Send Ports” and check if the following BTARN send ports are running under the “BizTalkServerApplication” send handler, otherwise you should modify it.
• “PrivateInitiator_To_LOB”
• “PrivateResponder_To_LOB”

• Click “Receive Locations”.
• Check if the following BTARN receive location are running under the “BizTalkServerIsolatedHost” receive handler, otherwise you should modify it.
• “Async_Http_Receive”
• “Sync_Http_Receive”
• And check if the following BTARN receive location are running under the “BizTalkServerApplication” receive handler, otherwise you should modify it.
• “LOB_To_PrivateInitiator”
• “LOB_To_PrivateResponder”

• Click “Orchestrations” and check if the following BTARN orchestrations are running under the “BizTalkServerApplication” host, otherwise you should modify it
• Microsoft.Solutions.BTARN.CommonTypes.OdxTypes
• Microsoft.Solutions.BTARN.CommonTypes.SendExceptionToLOB
• Microsoft.Solutions.BTARN.CommonTypes.SendExceptionToPrivateProcess
• Microsoft.Solutions.BTARN.PublicResponder.PublicResponderProcess
• Microsoft.Solutions.BTARN.PublicResponder.PublicResponderV11
• Microsoft.Solutions.BTARN.PublicInitiator.PublicInitiatorProcess
• Microsoft.Solutions.BTARN.PublicInitiator.PublicInitiatorV11
• Microsoft.Solutions.BTARN.PrivateResponder.PrivateResponderProcess
• Microsoft.Solutions.BTARN.PrivateInitiator.PrivateInitiatorProcess

You should do all of this configuration, to prevent future problems, otherwise, sooner or later you will have problems with BTARN.

Note: The Official documentation specifies that should restart the BizTalk Server machine to apply any modifications made in configuration and permissions. Fortunately, you don’t need that.

Configuring IIS Application Pool Identities

IIS supports running 32- and 64-bit web sites in separate application pools. Regarding to BTARN is very important to:

• Set the BTARN application pool to 32-bit mode.
• The Identity used in the BTARN Application pools should be the same that we use in the BTARN BizTalk Host Instance Account and the BizTalk Isolated Host Instance Account. Otherwise, BTARN in some situations may not work correctly.
• If the service account set for the BTARN application pools is different from the Isolated Host account, BTARN will not be able to process incoming messages correctly. When the receive “.aspx page” calls the pipeline, the pipeline will not have access to the appropriate certificates. Therefore, it will not be able to decrypt the incoming message or validate the signature. It will also not be able to access the MessageBox database.

To change the Identity property of BATRN application pools you need to:

• Open the IIS Management Console
• On the left three in the “Internet information Services (IIS) Manager” console, click in “Application Pools” node underneath the machine node.
• Right-click the “BTARNAppPool” application pool and select “Advanced Settings…”
• Select the “Identity” list item and click the ellipsis, the following dialog appears:

• Select the “Custom account” option and set the same service account used for the Isolated Host and Host instances
• Do the exact same steps for the “BTARNHttpReceivePool” application pool.

Related links:

• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Important considerations before you install BTARN (Part 1)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Preparing your BizTalk Server 2013 R2 environment for BTARN (Part 2)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Install and configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) (Part 3)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Troubleshooting Your Installation (Part 5)

This section provides information about troubleshooting your BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) installation.

Do not install SQL Server on the domain controller computer

If you install SQL Server on the same computer as your domain controller computer, it returns the following error message when it is trying to create the SQL send ports:

Error: Failed updating binding information.
BindingException: Could not validate TransportTypeData or Address properties for Primary Transport of Send Port ‘SendPort1′. Exception from HRESULT: 0x80131500.
Error: Failed updating binding information.
BindingException: Could not validate TransportTypeData or Address properties for Primary Transport of Send Port ‘SendPort1′. Exception from HRESULT: 0x80131500

Important: Do not install SQL Server on the domain controller computer.

Service account for the application pools must be the same as the service account for the Isolated Host and Host instances

If the service account set for the BTARN application pools is different from the Isolated Host account, BTARN will not be able to process incoming messages correctly. When the receive .aspx page calls the pipeline, the pipeline will not have access to the appropriate certificates. Therefore, it will not be able to decrypt the incoming message or validate the signature. It will also not be able to access the MessageBox database.

Related links:

• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Important considerations before you install BTARN (Part 1)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Preparing your BizTalk Server 2013 R2 environment for BTARN (Part 2)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Install and configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) (Part 3)
• How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Additional Configurations of BizTalk 2013 R2 Accelerator for RosettaNet (Part 4)

Last week while trying to generate from Visual Studio 2013 a schema of a custom SAP IDOC by:

• Right-click your BizTalk Server project, and then choose “Add | Add Generated Items | Consume Adapter Service”.
• In the “Consume Adapter Service” Add-in screen, select the sap adapter binding.
• You should set the connection URI to SAP server and after that click “Connect”
• From the “Select contract type” drop-down list, select “Service (Inbound operations)” option
• In the “Select a category” box, expand the IDOC node and select the IDOC that you want to retrieve, to see the IDOC message types in the “Available categories and operations” box.
• From the “Available categories and operations”, add the “Receive” operation to the “Added categories and operations” by selecting the operation and click the “Add” button
• And finally click “Ok” to generate the IDOC SAP schema

I got the following error:

“Error while retrieving or generating the WSDL. Adapter message: Details: ErrorCode=RFC_EXCEPTION. ErrorGroup=RFC_ERROR_APPLICATION_EXCEPTION. SapErrorMessage=SEGMENT_UNKNOWN. AdapterErrorMessage=Error returned by RfcCallReceiveEx while calling RFC: IDOCTYPE_READ_COMPLETE..

Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_EXCEPTION. ErrorGroup=RFC_ERROR_APPLICATION_EXCEPTION. SapErrorMessage=SEGMENT_UNKNOWN. AdapterErrorMessage=Error returned by RfcCallReceiveEx while calling RFC: IDOCTYPE_READ_COMPLETE..”

Server stack trace:

at Microsoft.Adapters.SAP.RFCException.HelperThrow(Int32 retCode, String additionalErrorMessage)
at Microsoft.Adapters.SAP.RfcOutboundInvoker.Invoke()
at Microsoft.Adapters.SAP.InternalIdocMetadata..ctor(String idocType, String cimType, String release, String version, MetadataLookup metadataLookup, SAPConnection sapConnection, TimeoutHelper timeoutHelper)
at Microsoft.Adapters.SAP.SAPMetadataContract.ResolveTypeMetadata(String typeId, TimeSpan timeout, TypeMetadataCollection& extraTypeMetadataResolved)
at Microsoft.ServiceModel.Channels.Common.Design.MetadataCache.GetTypeMetadata(String uniqueId, Guid clientId, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.MetadataLookup.GetTypeDefinition(String typeId, TimeSpan timeout)
at Microsoft.Adapters.SAP.SapIdocMetadata..ctor(String absName, String idocType, String cimType, String release, String version, SAPConnection sapConnection, Boolean generateFlatFileCompatibleIdocSchema, Boolean segmentTypeInFlatFileAnnotation, MetadataLookup metadataLookup, TimeoutHelper timeoutHelper)
at Microsoft.Adapters.SAP.SAPMetadataContract.ResolveTypeMetadata(String typeId, TimeSpan timeout, TypeMetadataCollection& extraTypeMetadataResolved)
at Microsoft.ServiceModel.Channels.Common.Design.MetadataCache.GetTypeMetadata(String uniqueId, Guid clientId, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.MetadataLookup.GetTypeDefinition(String typeId, TimeSpan timeout)
at Microsoft.Adapters.SAP.IdocOperationMetadata.ExportXmlSchema(XmlSchemaExportContext schemaExportContext, MetadataLookup metadataLookup, TimeSpan timespan, OperationParameterDirection direction)
at Microsoft.Adapters.SAP.IdocOperationMetadata.ExportInputXmlSchema(XmlSchemaExportContext schemaExportContext, MetadataLookup metadataLookup, TimeSpan timespan)
at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilderHelper.AddOperationSchema(OperationMetadata operationMetadata, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilder.SearchBrowseNodes(MetadataRetrievalNode[] nodes, WsdlBuilderHelper helper, TimeoutHelper timeoutHelper)
at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilder.GenerateOperationSchemas(WsdlBuilderHelper helper, MetadataRetrievalNode[] nodes, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Design.WsdlBuilder.GetWsdl(MetadataRetrievalNode[] nodes, Uri uri, TimeSpan timeout)
at Microsoft.Adapters.SAP.SapCustomWsdlRetrieval.GetWsdl(MetadataRetrievalNode[] nodes, Uri uri, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Design.MetadataExchanger.ProcessMetadataGet(Message message, Uri target, TimeSpan timeout, MetadataLookup metadataLookup)
at Microsoft.ServiceModel.Channels.Common.Design.MetadataExchanger.ProcessMetadataMessage(Message message, Uri target, TimeSpan timeout, MetadataLookup metadataLookup, Message& replyMessage)
at Microsoft.ServiceModel.Channels.Common.Channels.AdapterRequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.ServiceModel.Channels.IMetadataRetrievalContract.GetMetadata(MetadataRetrievalNode[] nodes)
at Microsoft.ServiceModel.Channels.Tools.MetadataSearchBrowse.MetadataPanel.GetWsdl(MetadataRetrievalNode[] nodes)
at Microsoft.ServiceModel.Channels.Tools.MetadataSearchBrowse.MetadataUserControl.GetWsdl()

Cause

The SAP adapter uses the IDOCTYPE_READ_COMPLETE RFC to retrieve the metadata for the Receive operation for an IDOC. Invoking this RFC requires specific user permissions in the SAP system. To generate metadata, if you have connected to the SAP system using a credential that does not have permission to invoke the IDOCTYPE_READ_COMPLETE RFC, the SAP adapter gives an error.

So in order to demystify problems you should:

• Make sure that your connection URI are well set
• And you should try to import a schema from a standard IDOC, like INVOIC01, STATUS or ORDER01

If you are unable to import the schemas then you have a different problem from what I’m addressing here and you probably need to contact your SAP team to try to diagnose the problem, it probably may be lack of permissions. But normally in this cases you will receive a:

• SapErrorMessage= OBJECT_UNKNOWN.

In my case I was able to import all the standard IDOC from SAP, however as I stated before I was trying to import the schema from a custom SAP IDOC created by my customer and I got instead a:

• SapErrorMessage=SEGMENT_UNKNOWN

Which means, that while importing the IDOCTYPE_READ_COMPLETE RFC was not properly identifying some segments of the IDOC.

After validating with my SAP team we realize that some segments were not in the state “released” in SAP, this may not be the correct SAP interface logic but just to give you an idea here are some SAP print screens:

Note: that all custom segments used in the IDOC must be released in SAP before you can import and use them in BizTalk Server.

Solution

Well the only solution is to contact you SAP team and they must be sure that all segments of the IDOC that you are trying to import are released correctly.

Unfortunately we don’t have the segment information in question, but more likely it is some custom segment that they created.