BizTalk Server 2020 – 20 days, 20 posts – day 19. To finalize this topic about the BizTalk Pipeline Components Extensions UtilityPack project, here another brand new component: XML Namespace Stripper Pipeline Component. I actually create this component for a need in a recent RosettaNet project.
XML Namespace Management Pipeline Component
This custom XML Namespace Stripper Pipeline Component is a pipeline component for BizTalk Server which can be used in a Send Pipeline (Encode stage) to remove all namespaces and prefix from an XML message.
Once again, the goal of this component is to clean up all namespaces and prefix present in XML outbound messages, transforming the the message from this:
To use this pipeline component in your projects you just copy the NamespaceStripper.dll file into the Pipeline Components folder that exists in the BizTalk Server installation directory:
You do not need to add this custom pipeline component to be used by the BizTalk Runtime to the Global Assembly Cache (GAC).
What is BizTalk Pipeline Components Extensions Utility Pack?
BizTalk Pipeline Components Extensions Utility Pack is a set of custom pipeline components (libraries) with several custom pipeline components that can be used in received and sent pipelines, which will provide an extension of BizTalk out-of-the-box pipeline capabilities.
PIP name specified does not match the PIP specification, this is the last RosettaNet error that tries to make my life a little bit difficult.
Fortunately, to date, Microsoft documentation has significantly improved, moving to DOCS was a good approach and community members now have the availability to help to improve the product documentation. Nevertheless, there are still some topics that the existing the documentation is obsolete, scarce or simply non-existent. One of these topics is Microsoft BizTalk Accelerator for RosettaNet.
I was receiving this error on the PublicResponderProcess orchestration, for those who are not familiar with Microsoft BizTalk Accelerator for RosettaNet (BTARN), this is a default artifact developer by Microsoft that compose a BizTalk Solution that handles PIP messages:
When a responder receives a request message, BTARN routes the request message from the public-process orchestration, to the private-process orchestration, to the line-of-business (LOB) program. The responder requires the response service content from the LOB program to generate a RosettaNet response message back to the initiator. Many of the elements in the response message are populated using the values from the request message. As a result, you can incorporate a map in the responder private-process orchestration to help the LOB program generate the response service-content message in the required format.
The difficult part is to “debug”/track these errors to understand what and why this is happening. The full error message in the event log was:
Description: Public Responder could not send an Async exception signal due to internal errors bellow: RNIF Exception detail:- Error code:UNP.SHDR.VALERR Error Number:2005 Description: PIP name specified does not match the PIP specification.
Note: this same error can occur in previous or new versions of BizTalk Server.
Cause
Again, it was difficult to understand all the internal behaviors developed by Microsoft for BTARN but basically, when you receive a PIP message you will end up receiving 4 parts:
The Preamble:
All RosettaNet messages must have a Preamble. It is specified with a DTD that is common across all messages.
The Preamble section of the MIME message contains elements that are global to the RosettaNet service and others that are common to the Service Header and Service Content; for example, the message standard and version used in the message.
The Service Header is specified with a DTD that is common across all messages. A separate DTD and/or XML schema for each message validates the body of the messages.
The Service Header helps identify the following items:
The PIP
The activity and the action to which the message belongs
The PIP instance
Information about the sender of the message
Information about the recipient of the message
The date and time at which the message was sent
Whether the message is a Test message or a Production message
Whether the sender is to be treated as an “unknown partner”
The Service Header format is fixed and independent of the specifics of the message contained in the payload. However, the Service Content could change based on the variance in the business content.
And it will call a method “IsActionMessageValid” on the “ValidateMessage” shape that will validate if the message received a match to any process/agreement active in the system
rnConfig.IsActionMessageValid( inRNIFMessage, out exceptionInfo );
This last method calls an additional method call “ValidateActionServiceHeader”, here a piece of the code:
“GetPIPConfigValue(“PIP_Name”)” comes from the RosettaNet process
The other comes from the Service Header message part in the BusinessActivityIdentifier element
Both need to be equal – case sensitive!
My problem was that:
the RosettaNet process name was: Notify of Invoice Reject
and the Service Header was: Notify Of Invoice Reject
Solution
To solve this issue you must.
Ensure that the process name is equal to the BusinessActivityIdentifier element in the Service Header message part
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
An error never comes alone … When an error appears, it always appears two or three, and I still have thousands to published, but this one but this one made me crazy for a few minutes: The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace!
Yes, you read it right, while I was trying to compile a RosettaNet schemas projects, in this particular case a PIP3B2 Advance Shipment Notification I got thousands of errors, 3054 to be exact saying:
Error 1 The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace
RosettaNet.Common.Schemas._3B2.System’ (are you missing an assembly reference?)
Error 3054 The type or namespace name ‘NonSerializedAttribute’ does not exist in the namespace ‘RosettaNet.Common.Schemas._3B2.System’ (are you missing an assembly reference?) C:TFS… RosettaNet.Common.Schemas.3B2DomainProcurementINT_Procurement_02_07_01_09.xsd.cs 5072 21 RosettaNet.Common.Schemas.3B2
… and several other schemas as you may see in the picture below.
But do not be fooled into thinking this is a problem related exclusively to RosettaNet, it is not, and it can happen with any “normal” or any kind of schemas.
Cause
There are certain keywords, type names, and identifier names that you should use because they are internally used by BizTalk and it way enter in conflict and sometimes originate problems and errors, keywords like activate, atomic, body, task, compensate, method and several ones, you can see the full list here XLANG-s Reserved Words. But there are other keywords that depending on the artifact, may give you problems like:
BTS (associated with Microsoft.BizTalk.GlobalPropertySchemas assembly)
“-“ in RootNode Typename inside schemas
…
And “System”!
If you use the keyword “System” inside a schema namespace like:
“RosettaNet.Common.Schemas._3B2.System”
“MyNamspace.System.Schemas”
You will not be able to compile your schema project.
The problem, if you download from the GS1 RosettaNet Standards certain PIP’s they will have the following structure:
And as you see, there is a folder “System” that inside have several schemas and normally the schema namespace is composed by the project name or (assembly name) and the path to the schema, for example in this case:
RosettaNet.Common.Schemas._3B2.System.CodeList
Or RosettaNet.Common.Schemas._3B2.System
And this is causing all of these problems because in this case, “System” is a reserved keyword that shouldn’t be used.
Solution
The difficult part of this error was finding the cause of the problem. Once you know what is causing the problem the solution is quite simple. You just need to:
Change the “Namespace” property on all the schemas the word “System” to another name, for example, “_System” (to maintain the consistency but it can be other word/value)
In my case, I hade the change the “Namespace” property of the schemas in the “System” folder
You can now rebuild your schema solution and this error should go away.
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
While trying to document, or better update my RosettaNet installation and configuration guide, I got a very strange (but by now I should know that nothing is strange with BizTalk and RosettaNet) while executing Microsoft BizTalk 2016 Accelerator for RosettaNet Configuration Wizard:
A BizTalk Isolated Host instance configured with the user account ‘DOMAINadministrator’ was either not running or does not exist on this computer. Use the BizTalk Administration Console to create a new Isolated host or to reconfigure an existing host to run as ‘DOMAINadministrator.
This error occurred just after I try to open the BTARN configuration wizard! (first thing that appears)
I well aware that when you are planning to install and configure Microsoft BizTalk 2016 Accelerator for RosettaNet (BTARN), you need to be very careful with a certain configuration like this one:
The BizTalk Host Instance Account and the BizTalk Isolated Host Instance Account should be the same account. Otherwise, BTARN does not function correctly.
Or that:
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).
BTARN 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)
Notice that this last one is just for everything to work well but it doesn’t impact the configuration itself.
And in fact, all my host instances have the same account and all of them was running.
Cause
BTARN installation process it’s quite old fashioned and weird is some points, the true it that Microsoft just invest a little to modernize it, and change some behaviors and requirements which are no longer justified, a good example is the IIS_WPG group requirement, this group doesn’t exist anymore, so you need to create it manually. Otherwise, BTARN installation fails.
In this case, the problem, as you can see in the figure above, is that I have two types of logon formats:
The 2 default host instances, created by the BizTalk installation wizard, are defined as “username” – without the domain or in this case the machine name (this is a standalone environment)
And others are set up in the format “DOMAINUsername”.
Well, regarding BTARN, if you want to avoid problems during the installation/configuration process or future problems in the runtime you should:
Never use Full Qualify domain name in the Logon credentials. Otherwise, BTARN does not work correctly.
To avoid BTARN problems use the down-level logon name format (DOMAINUsername).
Solution
To solve this issue the solution was quite simples, I just need to configure the logon to all my host instance in the down-level logon name format (DOMAINUsername).
After that, I was able to execute the BTARN configuration wizard without any further issues and especially no more user account was either not running or does not exist on this computer.
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira