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:
Receive pipeline rejected incoming message due to the following RNIF exception:
UNP.SCON.VALERR: A failure occurred while validating the service content.
The document specification <MyNamespace.MyPIP> from assembly <MyAssemblyName, Version=188.8.131.52, 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.
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.
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