BizTalk Server 2020 – 20 days, 20 posts: XML Namespace Stripper Pipeline Component for BizTalk Server 2020

BizTalk Server 2020 – 20 days, 20 posts: XML Namespace Stripper Pipeline Component for BizTalk Server 2020

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:

<?xml version="1.0" encoding="utf-8"?>
<ns0:Pip7B1WorkInProcessNotification xmlns:ns0="http://schemas.microsoft.com/biztalk/btarn/2004/7B1_MS_V01_00_WorkInProcessNotification.dtd" xmlns:ns1="http://Microsoft.Solutions.BTARN.Schemas.RNPIPs.BaseDataTypes" xmlns:ns2="http://www.w3.org/XML/1998/namespace">
  <ns0:fromRole>
    <ns0:PartnerRoleDescription>
      <ns0:ContactInformation>
        <ns0:contactName>
          <ns0:FreeFormText>Demo</ns0:FreeFormText>
        </ns0:contactName>
        <ns0:EmailAddress>demo@demo.com</ns0:EmailAddress>
        <ns0:telephoneNumber>
          <ns0:CommunicationsNumber>000-111-2222 EXT 1111</ns0:CommunicationsNumber>
        </ns0:telephoneNumber>
      </ns0:ContactInformation>
      <ns0:GlobalPartnerRoleClassificationCode>Solution Provider</ns0:GlobalPartnerRoleClassificationCode>
      <ns0:PartnerDescription>
        <ns0:BusinessDescription>
          <ns0:GlobalBusinessIdentifier>000000001</ns0:GlobalBusinessIdentifier>
        </ns0:BusinessDescription>
        <ns0:GlobalPartnerClassificationCode>Contract Manufacturer</ns0:GlobalPartnerClassificationCode>
      </ns0:PartnerDescription>
    </ns0:PartnerRoleDescription>
  </ns0:fromRole>
  ...
  <ns1:OrderReference>
	  <ns0:DocumentReference>
		<ns0:GlobalDocumentReferenceTypeCode>Purchase Order</ns0:GlobalDocumentReferenceTypeCode>
		<ns0:LineNumber>00001</ns0:LineNumber>
		<ns0:ProprietaryDocumentIdentifier>QctPoNumber_0</ns0:ProprietaryDocumentIdentifier>
	  </ns0:DocumentReference>
	  <ns0:DocumentReference>
		<ns0:GlobalDocumentReferenceTypeCode>Customer Batch Number</ns0:GlobalDocumentReferenceTypeCode>
		<ns0:ProprietaryDocumentIdentifier>Name_0</ns0:ProprietaryDocumentIdentifier>
		<ns0:RevisionNumber>Value_0</ns0:RevisionNumber>
	  </ns0:DocumentReference>
	</ns1:OrderReference>
	...
 </ns0:Pip7B1WorkInProcessNotification>

Into this:

<?xml version="1.0" encoding="utf-8"?>
<Pip7B1WorkInProcessNotification>
  <fromRole>
    <PartnerRoleDescription>
      <ContactInformation>
        <contactName>
          <FreeFormText>Demo</FreeFormText>
        </contactName>
        <EmailAddress>demo@demo.com</EmailAddress>
        <telephoneNumber>
          <CommunicationsNumber>000-111-2222 EXT 1111</CommunicationsNumber>
        </telephoneNumber>
      </ContactInformation>
      <GlobalPartnerRoleClassificationCode>Solution Provider</GlobalPartnerRoleClassificationCode>
      <PartnerDescription>
        <BusinessDescription>
          <GlobalBusinessIdentifier>000000001</GlobalBusinessIdentifier>
        </BusinessDescription>
        <GlobalPartnerClassificationCode>Contract Manufacturer</GlobalPartnerClassificationCode>
      </PartnerDescription>
    </PartnerRoleDescription>
  </fromRole>
  ...
  <OrderReference>
	  <DocumentReference>
		<GlobalDocumentReferenceTypeCode>Purchase Order</GlobalDocumentReferenceTypeCode>
		<LineNumber>00001</LineNumber>
		<ProprietaryDocumentIdentifier>0000000001</ProprietaryDocumentIdentifier>
	  </DocumentReference>
	  <DocumentReference>
		<GlobalDocumentReferenceTypeCode>Customer Batch Number</GlobalDocumentReferenceTypeCode>
		<ProprietaryDocumentIdentifier>demo</ProprietaryDocumentIdentifier>
		<RevisionNumber>D</RevisionNumber>
	  </DocumentReference>
	</OrderReference>
	...
</Pip7B1WorkInProcessNotification>

This component doesn’t require any configuration.

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:

  • ..Program Files (x86)Microsoft BizTalk ServerPipeline Components;

on every server.

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.

The project is available on the BizTalk Server Open Source Community repository on GitHub (https://github.com/BizTalkCommunity), and everyone can contribute with new pipeline components that can be extended or improve the existing BizTalk Server capabilities.

BizTalk Pipeline Components Extensions Utility Pack: JSON Encoder Pipeline Component for BizTalk Server 2020

At the moment this project is available for:

  • BizTalk Server 2020;
  • BizTalk Server 2016;
  • BizTalk Server 2010;
  • BizTalk Server 2006-2009

Where to download it?

You can download BizTalk Pipeline Components Extensions Utility Pack from GitHub here:

BizTalk Pipeline Components Extensions Utility Pack

The post BizTalk Server 2020 – 20 days, 20 posts: XML Namespace Stripper Pipeline Component for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.

Receiving a RNIF exception: PIP name specified does not match the PIP specification (error number 2005).

Receiving a RNIF exception: PIP name specified does not match the PIP specification (error number 2005).

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:

Source module:
PublicResponderProcess

Correlation information:
PIP Code : 3C4
PIP Version : V01.00
PIP InstanceID : 922731_20180912T050751
SourcePartnerName :
DestinationPartnerName:

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.

BizTalk RosettaNet (BTARN): 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.
<Preamble xmlns="http://schemas.microsoft.com/biztalk/btarn/2004/Preamble_MS_V02_00.dtd">
    <standardName>
        <GlobalAdministeringAuthorityCode>
            RosettaNet
        </GlobalAdministeringAuthorityCode>
    </standardName>
    <standardVersion>
        <VersionIdentifier>
            V02.00
        </VersionIdentifier>
    </standardVersion>
</Preamble>
  • The Delivery Header
    • The delivery header is new in RNIF 2.0 and facilitates the routing of messages through hubs. It contains the following attributes:
      • Elements for the sending and receiving of trading partner identities
      • Message date and time stamp
      • Globally unique tracking ID
<DeliveryHeader xmlns="http://schemas.microsoft.com/biztalk/btarn/2004/DeliveryHeader_MS_V02_00.dtd">
    <isSecureTransportRequired>
        <AffirmationIndicator>
            Yes
        </AffirmationIndicator>
    </isSecureTransportRequired>
    <messageDateTime>
        <DateTimeStamp>
            20180912T050743.000Z
        </DateTimeStamp>
    </messageDateTime>
    <messageReceiverIdentification>
        <PartnerIdentification>
            <GlobalBusinessIdentifier>
                xxxx
            </GlobalBusinessIdentifier>
        </PartnerIdentification>
    </messageReceiverIdentification>
    <messageSenderIdentification>
        <PartnerIdentification>
            <GlobalBusinessIdentifier>
                yyyyy
            </GlobalBusinessIdentifier>
        </PartnerIdentification>
    </messageSenderIdentification>
    <messageTrackingID>
        <InstanceIdentifier>
            922730_20180912T050744**00**
        </InstanceIdentifier>
    </messageTrackingID>
</DeliveryHeader>
    • 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.
<ServiceHeader xmlns="http://schemas.microsoft.com/biztalk/btarn/2004/ServiceHeader_MS_V02_00.dtd">
    <ProcessControl>
        <ActivityControl>
            <BusinessActivityIdentifier>
                Notify Of Invoice Reject
            </BusinessActivityIdentifier>
            <MessageControl>
                <fromRole>
                    <GlobalPartnerRoleClassificationCode>
                        Invoice Reject Provider
                    </GlobalPartnerRoleClassificationCode>
                </fromRole>
                <fromService>
                    <GlobalBusinessServiceCode>
                        Invoice Reject Provider Service
                    </GlobalBusinessServiceCode>
                </fromService>
                <Manifest>
                    <numberOfAttachments>
                        <CountableAmount>
                            0
                        </CountableAmount>
                    </numberOfAttachments>
                    <ServiceContentControl>
                        <ActionIdentity>
                            <GlobalBusinessActionCode>
                                Invoice Reject Notification Action
                            </GlobalBusinessActionCode>
                        </ActionIdentity>
                    </ServiceContentControl>
                </Manifest>
                <toRole>
                    <GlobalPartnerRoleClassificationCode>
                        Invoice Reject Receiver
                    </GlobalPartnerRoleClassificationCode>
                </toRole>
                <toService>
                    <GlobalBusinessServiceCode>
                        Invoice Reject Receiver Service
                    </GlobalBusinessServiceCode>
                </toService>
            </MessageControl>
        </ActivityControl>
        <GlobalUsageCode>
            Test
        </GlobalUsageCode>
        <pipCode>
            <GlobalProcessIndicatorCode>
                3C4
            </GlobalProcessIndicatorCode>
        </pipCode>
        <pipInstanceId>
            <InstanceIdentifier>
                922730_20180912T050744
            </InstanceIdentifier>
        </pipInstanceId>
        <pipVersion>
            <VersionIdentifier>
                V01.00
            </VersionIdentifier>
        </pipVersion>
        <KnownInitiatingPartner>
            <PartnerIdentification>
                <GlobalBusinessIdentifier>
                    XXXXXX
                </GlobalBusinessIdentifier>
            </PartnerIdentification>
        </KnownInitiatingPartner>
    </ProcessControl>
</ServiceHeader>
  • And the Service Content
    • Service Content is specified in individual PIPs. Each PIP has one or more business actions that are described by means of individual DTDs or schema.
    • The payload part of a RosettaNet Business Message—that is, the actual business content—is a message in XML format.

BizTalk RosettaNet (BTARN): PIP name specified does not match the PIP specification - Message Parts

For this problem, the things you need to know about the PublicResponderProcess orchestration is that:

  • It will call a method “GetRuntimeConfig” on the “GetRNConfig” shape that will get the process/agreement configuration;
rnConfig = Microsoft.Solutions.BTARN.ConfigurationManager.RuntimeConfigGenerator.GetRuntimeConfig
  (destinationPartyID, sourcePartyID, pipCode, pipVersion,
    false, true
 );
  • 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:
...
if (propertyValue != base.GetPIPConfigValue("PIP_Name"))
{
   str = str + StringResources.GetString(StringResourceIDNames.rtcV11InvalidPipName);
}
...
      • “GetPIPConfigValue(“PIP_Name”)” comes from the RosettaNet process

03-BizTalk-RosettaNet-BTARN-PIP-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.

BizTalk Schema Problems: The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace

BizTalk Schema Problems: The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace

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

C:TFS…RosettaNet.Common.Schemas.3B2DomainLogisticsCodeListRN_FreightPaymentTerms_01_03.xsd.cs 9 13 RosettaNet.Common.Schemas.3B2 …

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.

namespace name 'SerializableAttributeAttribute' does not exist in the namespace

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:

namespace name 'SerializableAttributeAttribute': RosettaNet PIP3B2 Sctructure

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

namespace name 'SerializableAttributeAttribute': Change schema namespace

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.

Microsoft BizTalk 2016 Accelerator for RosettaNet (BTARN) Configuration Wizard: A BizTalk Isolated Host instance configured with the user account was either not running or does not exist on this computer

Microsoft BizTalk 2016 Accelerator for RosettaNet (BTARN) Configuration Wizard: A BizTalk Isolated Host instance configured with the user account was either not running or does not exist on this computer

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.

user account was either not running or does not exist: Microsoft BizTalk 2016 Accelerator for RosettaNet Configuration Wizard fail open

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.

user account was either not running or does not exist: BTARN BizTalk Server host instances

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

user account was either not running or does not exist: BTARN host instances reconfigured

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.