Remove XML Empty Nodes Pipeline Component

Remove XML Empty Nodes Pipeline Component

Another day, another BizTalk Server Pipeline Component! Today, I decided to release a brand new component called the Remove XML Empty Nodes Pipeline Component.

For those who aren’t familiar with it, the BizTalk Pipeline Components Extensions Utility Pack project is a set of custom pipeline components (libraries) with several custom pipeline components that can be used in receiving and sending pipelines. Those pipeline components provide extensions of BizTalk’s out-of-the-box pipeline capabilities.

Remove XML Empty Nodes Pipeline Component

As the name mentions, the Remove XML Empty Nodes Pipeline Component is a pipeline component that can be used to remove empty nodes present in an XML message. You can use this component in any stage of a receive or send pipeline.

This component has a single property that requires you to setup:

  • DisableRemoveBOM (boolean): This allows you to enable or disable the process of removing empty nodes from an XML message.

How to install it

As always, you just need to add these DLLs on the Pipeline Components folder that in BizTalk Server 2020 is by default:

  • C:Program Files (x86)Microsoft BizTalk ServerPipeline Components

In this particular component, we need to have this  DLL

  • BizTalk.PipelineComponents.RemoveXmlEmptyNodes.dll

How to use it

Like all previous, to use the pipeline component, I recommend you create generic or several generic pipelines that can be reused by all your applications and add this pipeline component in any required stage of a send or receive pipeline.

Download

THIS COMPONENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND.

You can download the Remove XML Empty Nodes Pipeline Component from GitHub here:

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can help us buy a Star Wars Lego for Sandro’s son! 

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

Friday Fact: XML to JSON Conversion in API Management and Logic Apps have different behaviors

Friday Fact: XML to JSON Conversion in API Management and Logic Apps have different behaviors

I don’t know the reason why two products from the same family – Azure Integration Services – have completely different behaviors while converting XML to JSON, but that is the current reality. It is a fact! API Management and Logic Apps have different behaviors while applying this conversion, and that is one of the main reasons that I decided to create an Azure Function to convert XML into JSON, to keep the consistency between these two products.

While using API Management, we can use the xml-to-json policy to convert a request or response body from XML to JSON. However, when dealing with XML namespaces and prefixes, which is quite normal when working with XML messages, the policy has, in my opinion, a strange conversion behavior:

  • It converts the prefixes that in XML are represented by prefix:MyField into prefix$MyField. In order words, it replaces the colon character (:) with the dollar character ($).

Let’s take this XML sample in order for you to see the upcome result of that xml-to-json policy:

Book-Signing Event Convert it to JSON

The result will be:

{
    "section": {
        "@xmlns": "http://www.test.com/events",
        "@xmlns$bk": "urn:loc.gov:books",
        "@xmlns$pi": "urn:personalInformation",
        "@xmlns$isbn": "urn:ISBN:0-999-99999-9",
        "title": "Book-Signing Event",
        "signing": {
            "bk$author": {
                "@pi$title": "Mr",
                "@pi$name": "My Name"
            },
            "book": {
                "@bk$title": "How cool is XML",
                "@isbn$number": "9999999999"
            },
            "comment": {
                "@xmlns": "",
                "#text": "Convert it to JSON"
            }
        }
    }
}

I think this behavior is strange and incorrect.

Now, if we take the same XML payload and try to convert it inside Logic Apps using the json() expression that returns the JSON type value or object for a string or XML. In this case, using, for example, the following expression:

  • json(xml(triggerBody()))

The result will be:

{
    "section": {
        "@xmlns": "http://www.test.com/events",
        "@xmlns:bk": "urn:loc.gov:books",
        "@xmlns:pi": "urn:personalInformation",
        "@xmlns:isbn": "urn:ISBN:0-999-99999-9",
        "title": "Book-Signing Event",
        "signing": {
            "bk:author": {
                "@pi:title": "Mr",
                "@pi:name": "My Name"
            },
            "book": {
                "@bk:title": "How cool is XML",
                "@isbn:number": "9999999999"
            },
            "comment": {
                "@xmlns": "",
                "#text": "Convert it to JSON"
            }
        }
    }
}

In this case, the json() expression does not replace the colon character (:) with the dollar character ($) in the prefixes. It’s maintaining, which I think is the correct behavior.

To lazy to read? We’ve got you covered! Check out our video version of this content!

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can help us buy a Star Wars Lego for Sandro’s son! 

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

Azure Function to Apply XML Validation (Advanced)

Azure Function to Apply XML Validation (Advanced)

After the release of our previous XML Validation Functions: 

It is now time to release our last Azure Function under the same context: an Azure Function to Apply XML Validation (Advanced).

As I explained in my previous posts, all the out-of-the-box Azure Integration Services capabilities to validate XMLs have a huge limitation: they don’t allow us to have a chain of XML Schemas! As I also mentioned, this is a common feature present in many Enterprise XML Schemas definitions. EDI or RosettaNet Schemas may have 2 or more schemas that define the overall structures of the messages. Blocking this way many enterprise scenarios that we need to address in our Azure integration solutions.

Our previous Azure Function allows us to solve many of those scenarios, and it can be used inside Logic Apps Consumption or Standard or even inside API Management. However, it also has a limitation: it only allows first-level chain support for XML Schemas (meaning that it will only take into consideration all the import schemas of the main XML Schema).

However, for example, in RosettaNet Schemas, it is very common that our main schema imports a “child” XML Schema and that child schema imports or includes other XML Schemas itself.

Apply XML Validation (Advanced)

What does this Azure Function do?

This Azure Function allows you to perform XML validations against an XML Schema, including support for all chains of XML Schemas. That means that it will take into consideration all depth of importation for a specific type of message. It will recursively include or import all XML Schemas, supporting this way all types of XML message validation.

To trigger this function, you need to:

  • In the Body, the XML payload that you want to be validated.
  • You should specify the following mandatory headers:
    • Content-Type as text/xml (or application/xml).
    • SchemaFileName with the name of the XML Schema (XSD) file present in the storage account.

The response will be a:

  • 200 OK – Validation successful. If it’s a valid message.
  • Or 400 Bad Request with a list of errors if there is something invalid.

Notice that by default, if you send a message to be validated against a schema that doesn’t have the same target namespace and root node, the response will be an OK. This function also validates that type of message, so if you send a message that doesn’t correspond to that schema, you will get a 400 Bad Request.

Where can I download it?

You can download the complete Azure Functions source code here:

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego! 

Thanks to my team member Luís Rigueira for helping me realize and implement this idea.

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

Azure Function to Apply XML Validation (Intermedium)

Azure Function to Apply XML Validation (Intermedium)

After the release of our Azure Function to Apply XML Validation (Basic), it is now time for another Azure Function under the same context: an Azure Function to Apply XML Validation (Intermedium).

You may be wondering why a new Azure Function is required to archive the same? And why not only one with all capabilities?

Both are good questions that I will be happy to respond to. First of all, in my last blog post, I mentioned that, in the next few days, we will be releasing two additional versions of this function with more functionalities/capabilities. And to answer the second question, the main reason why I decided to do 3 different versions is performance. The basic function has fewer capabilities, but it will have better performance. Of course, the advanced function will have all the capabilities, but it will have a small overhead in the overall performance.

The previous Azure Function is great for basic validations, similar to what we can archive using the default out-of-the-box capabilities inside:

  • Logic Apps Standard;
  • Logic Apps Consumption using the Integration Account;
  • Or in API Management

Of course, the basic XML Validation Function it is a good approach to replace the dependency of the Integration Account in Logic App Consumption.

But all of them have a huge limitation! None of those services allow a chain of XML Schemas!

What do you mean by a chain of XML Schemas?

XML Schema provides mechanisms to include or import other XML Schema documents, enabling the reuse and extension of schema definitions across multiple files. This capability is essential for managing complex schemas in a modular and maintainable manner.

  1. Include: The include element is used when you want to incorporate definitions from another schema that is in the same target namespace. By using include, you can split your schema definitions into separate, smaller files for better manageability and readability while treating them as part of a single schema during validation. The included schema essentially becomes a subset of the including schema, allowing for the extension or redefinition of elements and types within the same namespace.
  2. Import: The import element is used to incorporate definitions from another schema that is in a different target namespace or from no namespace into the current schema. This allows you to reference and use types and elements defined in an external schema within your current schema document. Importing is crucial when you need to integrate or reference types defined in a completely separate schema, possibly managed by a different organization or standard body.

Both include and import mechanisms facilitate the construction of complex XML schemas from modular components, promoting reuse and simplifying the management of schema definitions. They enable schema designers to build upon existing standards and to organize their schema definitions logically and efficiently.

This a common feature present in many Enterprise XML Schemas definitions. EDI or RosettaNet Schemas may have 2 or more schemas that define the overall structures of the messages.

Apply XML Validation (Intermedium)

What does this Azure Function do?

This Azure Function allows you to perform XML validations against an XML Schema, including first-level chain support for XML Schemas. That means that it will take into consideration all the import schemas of the main XML Schema

To trigger this function, you need to:

  • In the Body, the XML payload that you want to be validated.
  • You should specify the following mandatory headers:
    • Content-Type as text/xml (or application/xml).
    • SchemaFileName with the name of the XML Schema (XSD) file present in the storage account.

The response will be a:

  • 200 OK – Validation successful. If it’s a valid message.
  • Or 400 Bad Request with a list of errors if there is something invalid.

Notice that by default, if you send a message to be validated against a schema that doesn’t have the same target namespace and root node, the response will be an OK. This function also validates that type of message, so if you send a message that doesn’t correspond to that schema, you will get a 400 Bad Request.

Where can I download it?

You can download the complete Azure Functions source code here:

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego! 

Thanks to my team member Luís Rigueira for helping me realize and implement this idea.

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

Azure Function to Apply XML Validation (Basic)

Azure Function to Apply XML Validation (Basic)

After the release of our two previous Azure Functions that will help us minimize or completely remove the need for an Integration Account:

Today is the correct time to release another Azure Function that will replace another Integration Account functionality: an Azure Function to Apply XML Validation.

Of course, you can apply out-of-the-box this functionality in:

  • Logic App Standard (without the need for an Integration Account)

    
        
    
    

However, Logic App Consumption requires an Integration Account to provide those same capabilities out of the box.

Once again, our main objective in creating this specific version of this function was to use it inside Logic Apps Consumption to avoid needing an Integration Account. But that we will address later on in another blog post.

If you are wondering what I mean by this specific version of this function, well, in the next few days, we will be releasing two additional versions of this function with more functionalities. But, once again, that we will address later on in another blog post.

Apply XML Validation (Basic)

XML (Extensible Markup Language) validation is the process of checking an XML document against a set of rules to ensure its structure and content adhere to a specific format or standard. This process is crucial for ensuring that the XML document is both well-formed and valid.

  1. Well-formed XML: This means that the XML document follows the basic syntax rules laid out by the XML specification. These rules include proper nesting of elements, correct use of opening and closing tags, attribute value quoting, and more. A well-formed XML document is one that can be correctly parsed and understood by an XML parser.
  2. Valid XML: Beyond being well-formed, a valid XML document also adheres to a specific schema or Document Type Definition (DTD) that defines the structure, content, and relationships within the document. Validation against a schema or DTD ensures that the XML document contains the expected elements, attributes, and data types, and that these components are organized in a defined way.

There are several schema languages used for XML validation, with the most common being:

  • DTD (Document Type Definition): An older schema language that defines the structure and allowed content within an XML document. – Not supported in the Azure Function.
  • XML Schema (also known as XSD): A more powerful and expressive schema language that allows for more detailed specifications of the content and structure, including data types and namespace support.

XML validation is performed using XML parsers or validation tools, which can programmatically check a document against its DTD or XSD to ensure compliance. This is a critical step in many data exchange, configuration management, and content authoring workflows, ensuring that the data is correctly structured and interpretable by receiving systems or applications.

What does this Azure Function do?

This Azure Function allows you to perform basic XML validations against an XML Schema.

To trigger this function, you need to:

  • In the Body, the XML payload that you want to be validated.
  • You should specify the following mandatory headers:
    • Content-Type as text/xml (or application/xml).
    • SchemaFileName with the name of the XML Schema (XSD) file present in the storage account.

The response will be a:

  • 200 OK – Validation successful. If it’s a valid message.
  • Or 400 Bad Request with a list of errors if there is something invalid.

Notice that by default, if you send a message to be validated against a schema that doesn’t have the same target namespace and root node, the response will be an OK. This function also validates that type of message, so if you send a message that doesn’t correspond to that schema, you will get a 400 Bad Request.

Where can I download it?

You can download the complete Azure Functions source code here:

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego! 

Thanks to my team member Luís Rigueira for helping me realize and implement this idea.

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

Azure Function to Apply XSLT Transformations

Azure Function to Apply XSLT Transformations

Another Azure Function? Can we accomplish the same with default capabilities inside Logic Apps or Azure API Management? These may be, once again, the questions that you are asking yourself at the moment. Because if we are using Azure Integration Services, we can easily use: 

  • If we are using Logic App Consumption we can use the Transform XML action in conjugation with an Integration Account.
  • If we are using Logic App Standard it already provides out-of-the-box support for applying XML transformations (using Transform XML action) without the Integration Account need.
  • Or, if you are using API Management, we can make use of the xsl-transform policy to apply an XSL transformation to XML in the request or response body.

Our main objective in creating this function was to use it inside Logic Apps Consumption to avoid needing an Integration Account. But that we will address later on in another blog post.

What does this Azure Function do?

The ApplyXSLTTransformation allows you to dynamically convert an XML payload into another XML, JSON, or any other format using XLST. To use this function, you must set up an Azure Storage Account and a container to store the XSLT files.

To trigger this function, you need to:

  • In the Body, send an XML payload
  • You should specify the following mandatory headers:
    • Content-Type as text/xml, or application/xml.
    • XsltFileName with the name of the xslt file present in the storage account.
  • Optionally, you can set the following header:
    • Output-Content-Type: this will specify the outcome (response) content-type. The default value is text/xml.

Once again, our main objective in creating this function was to use it inside Logic Apps Consumption to avoid needing an Integration Account. But that we will address later on in another blog post. However, it can be used in other scenarios.

Where can I download it?

You can download the complete Azure Functions source code here:

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego! 

Thanks to my team member Luís Rigueira for helping me realize and implement this idea.

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

Azure Functions to Convert XML into JSON

Azure Functions to Convert XML into JSON

Why do we need this Azure Function? This may be the question that you are asking yourself at the moment. Because if we are using Azure Integration Services, we can easily use: 

  • The json() expression that returns the JSON type value or object for a string or XML inside Logic Apps
  • Or the xml-to-json policy that converts a request or response body from XML to JSON inside API Management.

Well, our main objective in creating this function was to be used in Azure API Management to overcome some non-conforming behaviors while converting XML to JSON of the xml-to-json policy, mainly if that XML contains prefixes.

As you may know, prefixes are used inside XML to prevent name conflicts. And when we use them, a namespace for the prefix must be defined. They will work as an abbreviation of the full XML namespace. The namespace declaration has the following syntax:

  • xmlns:prefix=”URI“.

allowing MyField to be written in this namespace as prefix:MyField rather than, say, {URI}MyField

And in Enterprise Integration solutions, it is quite normal to see XML documents and Schemas using several prefixes.

Later in another blog post, we will explain the issue behind the decision to create this Azure Function in detail.

And what does this Azure Function do?

The ConvertXMLtoJSON Azure Function, as the name mentions, converts an XML payload to JSON. This function can be used to modernize APIs based on XML-only backend web services.

Once again, our main objective in creating this function was to be used in Azure API Management to overcome some non-conforming behaviors of the xml-to-json policy. However, it can be used in other scenarios.

Where can I download it?

You can download the complete Azure Functions source code here:

Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego! 

Thanks to my team member Luís Rigueira for helping me realize and implement this idea.

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

Azure Logic Apps team is interested in your feedback – XML Support in Logic Apps Survey

Azure Logic Apps team is interested in your feedback – XML Support in Logic Apps Survey

And once again, the Logic App team wants to listen to our feedback! And this time, on the topic we all developers or consultants were anxiously waiting for, specially BizYalk Server developers: XML Support in Logic Apps!

XML Support in Logic Apps Survey

With this new survey, the Logic App team seeks feedback on how you guys want to have or imagine having XML Support inside Logic Apps. They want to learn about your needs and feedback on the current Logic Apps workflows support for XML and to provide us information about potential scenarios that you want to see covered around XML and SOAP:

  • What industry do you work in?
  • Information about the current XML capabilities of Logic Apps Workflows
    • Have you used Transform XML, XPath,  XML Validation, Transform XML to JSON, or Transform XML to TEXT actions? Do they fulfill your needs?
    • What is your biggest challenge in dealing with XML Documents in Azure Logic Apps workflows?
    • How are you currently dealing with XMLs documents with schemas definitions (XSDs) in Azure Logic Apps workflows? 
    • Are you currently converting SOAP to REST services or calling SOAP services from Logic Apps? If so, what procedure do you follow?
    • Are you familiar with the HTTP connector? Does it address your needs? 
    • Are you familiar with the Custom Connector experience that supports SOAP? Does it address your needs?
    • How are you retrieving individual data elements from an XML document and then using that value in an action?
    • Are you migrating schemas from BizTalk or other products to Azure Logic Apps?
    • (For Consumption Only) How would you rate the XML capabilities of the Enterprise Integration Pack?
    • Please Rank the areas you feel Azure Logic Apps should include XML native support.

THIS IS YOUR OPPORTUNITY! Don’t complain that the developing experience is not that good or you missing XML capabilities inside Logic App in the future if you don’t fill out this form. The survey does not take long to respond to, and this is your opportunity to try to change and influence the next set of features.

I did my part!

Please fill out the following survey to help Azure Logic Apps: 

On a final note, congratulations to the Logic App team for being so engaged with the community over the last few months! Keep this engagement active, and please continue to do a great job!

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

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.

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

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

BizTalk Server 2020 – 20 days, 20 posts – day 18. Another blog post about the topic and project BizTalk Pipeline Components Extensions UtilityPack, but this time it is a brand new component: XML Namespace Management Pipeline Component.

XML Namespace Management Pipeline Component

This custom XML Namespace Management Pipeline Component it is basically the opposite of the XML Namespace Remover Pipeline Component. It is a pipeline component for BizTalk Server which can be used in any stage of both receive and send pipelines that allow you to add or change the namespace to inbound and outbound BizTalk Messages.

XML Namespace Management Pipeline Component

Once again, this component allow you to add a namespace to inbound and outbound BizTalk Messages, transforming the root of the message from this:

<sample>
  <to>Sandro</to>
  <from>Pereira</from>
</sample>

Into this:

<sample xmlns="http://blog.sandro-pereira.com/">
  <to>Sandro</to>
  <from>Pereira</from>
</sample>

Or change the existing namespace of inbound and outbound BizTalk Messages, transforming the root of the message from this:

<sample xmlns="http:/demo/">
  <to>Sandro</to>
  <from>Pereira</from>
</sample>

Into this:

<sample xmlns="http://blog.sandro-pereira.com/">
  <to>Sandro</to>
  <from>Pereira</from>
</sample>

This component requires one configuration that is the TargetNamespace in which you specify the namespace you want to set on the message.

To use this pipeline component in your projects you just copy the BizTalk.PipelineComponents.NamespaceMgmt.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 Management Pipeline Component for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.