How to create a Logic App Consumption Visual Studio project

How to create a Logic App Consumption Visual Studio project

Unfortunately, until this date, there isn’t available an Azure Logic Apps Tools for Visual Studio Extension for Visual Studio 2022, which means that we still need to use Visual Studio 2019 to create Logic App Consumption projects with Visual Studio.

An opposite to other Azure Services like Azure Functions that have a dedicated Azure Function project Template:

There isn’t a Logic App Consumption Visual Studio project template. Instead, we need to use the Azure Resource Group project template, and inside we will select that it will be applying a Logic App template.

Creating a Visual Studio Logic App Consumption project

The Logic Apps designer integrates with the current Azure Resource Group project. That saying, you will not find any Logic App template in the list of templates. Instead, we need to create an Azure Resource Group project to get started, and to do that, we need:

  • Open Visual Studio, and on the Create a new project panel, select C# -> Azure -> Cloud, or search for Azure Resource Group:
    • From the list of project templates, select the Azure Resource Group template.
  • On the Configure your new project panel, give a proper Project name, Location, and Solution name. Leave the Framework as .NET Framework 4.7.2 and select Create.
  • Finally, on the Select Azure Template panel, from the Visual Studio Templates list, select the Logic App template and select OK.

This will create an empty Visual Studio Logic App solution. Now on the Visual Studio solution:

  • Right-click on the LogicApp.json file and select Open With Logic App Designer.
  • This will open a Logic App Properties window, where you need to:
    • Define the credentials to authenticate on the Azure subscription.
    • Define the Subscription and Resource Group where you want to create these resources.
    • Define if you want the Location to be in the same Region or in an Integration Service Environment (ISE) – be aware the ISE is being deprecated.
  • And then select OK.

This will embed the Logic App designer inside the Visual Studio.

Now you need to select a common trigger, a template, or use a blank Logic App to start creating your business process.

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

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

What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part III)

What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part III)

Finally, the last chapter of this blog post series where we address:

  • What we need to install to begin developing our stateful and stateless workflows using Azure Logic Apps (Preview) – PART I;
  • The first approach to what you need to create a new Logic App (Preview) resource and new stateful or stateless workflows through VS Code – PART II;

Today, I will start to explain a different and more powerful way for you to create your Logic Apps (Preview) projects and workflows. Notice that, for this approach, you need to have all the prerequisites installed; otherwise, it will not work correctly or at least certain features like Logic App Designer, debug, or inline code.

If you are like me, a developer used to work with Visual Studio as his primary tool, then you need a little learning curve to start developer using VS Code. It is a different way to developer your solutions.

Create a local project

Before you can create your logic app, the first thing you need to do is to create a local project. This will allow you to manage and deploy your logic app from Visual Studio Code.

To do that, you need to:

  • In your development environment, create an empty local folder:
    • in my case, C:VSCODEMy-First-Logic-App-Preview
    • This folder will be used for our Logic App (Preview) project that you’ll later associate in the Visual Studio Code.

Note: Using the VS Code, there are multiple ways for you to:

  • Create the local project: you can do it at the Subscription level or the Logic App (Preview) resource level (n the Logic App (Preview) extension); 
  • Create the Logic Apps (Preview) resource in Azure: Directly from the Subscription level on the Logic App (Preview) extension or during the local project deployment; 
  • And even the deployment: once again in the Logic App (Preview) resource level (n the Logic App (Preview) extension) or at the Çocal project level;

I will approach and explain the way I prefer better and which I think is the most ideal.

  • I am assuming that you have already created the Logic App (Preview) resource in Azure. If not, check to Create a new Logic App (Preview) resource in PART II.
  • In the Azure pane, from the Logic Apps (Preview) extension, expand your Subscription, select the Logic App (Preview) resource, and click on Create New Project.
  • This will open the Browse Explorer, select the folder we have created.
    • C:VSCODEMy-First-Logic-App-Preview
  • Centered at the top of the VS Code editor window, a wizard will appear asking to select a template for your project’s first workflow,  select either Stateful Workflow or Stateless Workflow. We will be using Stateful Workflow.
  • Provide a workflow name for the workflow you are creating or leave the default nameType Stateful-workflow-example and press Enter
  • Next, the wizard will ask you if we would like to open your project in a new window or the current one; select Open in current window.

Visual Studio Code reloads and will switch to the Explorer pane, showing you the workflow definition and your new Logic App (Preview) local project, which will include several automatically generated project files. For example:

  • The project will have a folder with the name that you specify for your workflow – Stateful-workflow-example. Inside this folder, the workflow.json file contains your logic app workflow’s underlying JSON definition.
  • Also host.json and local.settings.json files;
  • and so on.

Developing your Logic Apps in VS Code

Now that we have everything we need already created, we can start developing our logic apps locally on VS Code.

To do that, you need to:

  • Expand the project folder, in my case MY-FIRST-LOGIC-APP-PREVIEW, and then expand your workflow folder, Stateful-workflow-example. Righ-click workflow.json file and select Open in Designer.
  • From the Enable connectors in Azure list, select Use connectors from Azure, which applies to all managed connectors that are available and deployed in Azure, not just connectors for Azure services.
  • From the Select subscription list, select your subscription. This will be were the connectores will be created.
  • And finally, from the Select a resource group for new resources list, select the resource that you created for this project.
  • After that, the Logic App Designer appears, the Choose an operation prompt appears on the designer and is selected by default, which shows the Add a trigger pane.

Note: If you have .NET Core SDK 5.x, this version might prevent you from opening the logic app’s underlying workflow definition in the designer. Rather than uninstall this version, in your project’s root location, create a global.json file that references the .NET Core runtime 3.x version that you have that’s later than 3.1.201, for example:

{
   "sdk": {
      "version": "3.1.101",
      "rollForward": "disable"
   }
}
  • Make sure that you explicitly add that global.json file to your project at the root location from inside Visual Studio Code. Otherwise, the designer won’t open.
  • To check the versions that are installed on your computer, run the following command:
..Users{yourUserName}dotnet --list-sdks

And the rest is basically the same that we are already used to doing it in our “original” Logic Apps, or using the Azure Portal or inside Visual Studio. We need to add a trigger and actions.

  • On the designer, select the Choose an operation an in the Add a trigger pane, under the Choose an operation search box, make sure that Built-in is selected so that you can select a trigger that runs natively.
  • In the Choose an operation search box, enter when a http request, and select the built-in Request trigger that’s named When a HTTP request is received.
  • When the trigger appears on the designer, the trigger’s details pane opens to show the trigger’s properties, settings, and other actions.
    • This means that you can now define the JSON Schema, method, and all the other properties of this trigger.
    • Let’s leave the default for now.
  • Because this is a simple sample, let’s add an HTTP Response to our logic. On the designer, under the trigger that you added, select New step.
  • On the Add an action pane, under the Choose an operation search box, enter Response, and select the built-in Request action that’s named Response.
  • To have a more friendly response, set the body property of the Response action to be:
{
     "Message": "Welcome to your first Stateful Workflow"
}
  • Finally, on the designer, select Save.

Now what we need before deploying this is to run and test this workflow locally.

Testing locally our Logic Apps

To do that, we need to:

  • On the Visual Studio Code toolbar, open the Run menu, and select Start Debugging (F5).
    • A Terminal window will open so that we can review the debugging session.
  • Because this workflow is trigger by an HTTP request, we need to find the callback URL for the endpoint on the Request trigger. Usually, we go to the When a HTTP request is received trigger, after we save our Logic App, and on the HTTP POST URL, we would find the callback URL. However, we will not find it locally. Instead, we will find a message saying, “Url not available during authoring in local project. Check the Overview page.”
  • As the message describes, for us to now the callback URL for the endpoint on the Request trigger we need to:
    • Reopen the Explorer pane so that you can view your project.
    • And from the workflow.json file’s inside the workflow folder – Stateful-workflow-example – right-click and select Overview.
  • There you will find the Workflow Properties like the Callback URL but also the local Run History of that workflow
  • Copy that URL to Postman or any other tool, and test sending a request to see if you get the desired outcome.

On the Overview page, you will get another entry on the Run History.

How can I add more workflows to my project?

Can I add more workflows to my local project? If so, how can I do it?

Yes, you can. And to do that, you need to:

  • Switch back to Azure pane and under Logic App (Preview), select your Logic App resource, and select Create Workflow.
  • A wizard will appear asking to select a template for your workflow,  select either Stateful Workflow or Stateless Workflow. We will be using Stateful Workflow.
  • Provide a workflow name for the workflow you are creating or leave the default name, Type Another-Stateful-workflow-example, and press Enter.
  • Now, if we switch back again to the Explorer pane, we will notice that we have another workflow added to our local project.

Publish (deploy) to Azure Logic App (Preview) resource

Everything we created above is not created/publish on Azure, they were developed and created locally. Nevertheless, from Visual Studio Code, you can deploy your project and with it all your workflows directly to Azure. If the Logic App (Preview) resource type is not yet created, you can create in Azure during the deployment.

To do that, you need to:

  • On the Visual Studio Code toolbar, select the Azure icon.
  • On the Azure: Logic Apps (Preview) pane toolbar, select your Logic App (Preview) resource type, in our case, My-First-Logic-App-Preview, and then select Deploy to Logic App.
  • The deploy wizard will appear asking to Select subscription from the list.
  • And then to Select Logic App (Preview) in Azure. We will be selecting the one that we craete previously
  • If a message appear asking you if you want to continue with the deployment and overwrite any previou depoyment, select Deploy.

This will trigger the deployment process to Azure. Once the deployment is finished, you will be able to see your stateful workflows live in Azure and enabled by default.

The post What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part III) appeared first on SANDRO PEREIRA BIZTALK BLOG.

What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part II)

What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part II)

In the first part of this blog post series – What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part I) – I explained what we need to install to begin developing our stateful and stateless workflows using Azure Logic Apps (Preview). Today, I will start to explain what we actually need to do to create our first Azure Logic Apps (Preview) workflow.

Today we will see one of the ways to create a new Logic App (Preview) resource and new stateful or stateless workflows through VS Code. This doesn’t mean that it’s the best way, but later we will address this topic.

Create a new Logic App (Preview) resource

To do that, you need:

  • Open your VS Code, select the Azure icon.
  • In the Azure pane, under Azure: Logic Apps (Preview), select Sign in to Azure.
  • When the Visual Studio Code authentication page appears, sign in with your Azure account.
  • After you sign in, the Azure pane shows the subscriptions in your Azure account.
    • Any Logic Apps resources you may have already deployed/released it will not be showing here. You can see any original Logic Apps resources you created using the original extension in the released extension’s Logic Apps section.
    • In the Logic App (Preview) section, you will only see the new Logic Apps (Preview) resource type within functions runtime.

Note: You cannot create a Logic Apps (Preview) resource type directly from the Azure Portal. The only option at the moment is using Visual Studio Code (and probably scripting).

This is probably the best way, but if you don’t fill comfortable to work in VS Code, the first thing you can do is:

  • From the Logic Apps (Preview) extension, right-click on your Subscription and select one of the two options:
    • Create Logic App in Azure…
    • Create Logic App in Azure… (Advance) – we will be using this one.
  • Centered at the top of the VS Code editor window, a wizard will appear asking to specify a globally unique name for the logic app, which is the name to use for the Logic App (Preview) resource.
    • Type My-First-Logic-App-Preview and press Enter.
  • The second step will ask you to select a hosting plan for your new logic app, either App Service Plan or Premium.
    • Select App Service Plan.
  • The next step asks you if you want to create a new App Service plan or select an existing plan.
    • Select Create new App Service Plan.
  • Enter the name of the new App Service Plan you are creating or leave the default name
    • Type My-First-Logic-App-Preview-AS-Plan and press Enter.
  • And then select a pricing tier for the new App Service plan.
    • Select the S1 Standard plan (you can choose F1 Free plan).
  • The next step asks you if you want to create a new resource group for new resources or select an existing resource group.
    • In this case, select Create new resource group
  • Enter the name of the new resource group you are creating or leave the default name
    • Type My-First-Logic-App-Preview-RG and press Enter.
  • The next step asks you if you want to create a new storage account or select an existing storage account.
    • In this case, select Create new storage account
  • Enter the name of the new storage account you are creating or leave the default name
    • Type myfirstlogicapppreviewsa and press Enter.
  • The next step asks you if you want to create a new Application Insights resource or select an existing Application Insights resource.
    • In this case, select Create new Application Insights resource
  • Enter the name of the new Application Insights resource you are creating or leave the default name
    • Type My-First-Logic-App-Preview-AppIns and press Enter.
  • And finally, select a location for the new resources
    • In our case, West Europe

After that, you will see on the bottom right of VS Code Editor windows a status progress of the resources being created in Azure:

After it is finished, you will be able to see that resources in VS Code:

And the same thru the Azure Portal:

Create a new stateful or stateless workflows

Now that we have our Logic App (Preview) resource created, we can start creating our:

  • Stateful workflows: Stateful logic apps provide high resiliency if or when outages happen. After services and systems are restored, you can reconstruct the interrupted logic app runs from the saved state and rerun the logic apps to completion. Stateful workflows can continue running for up to a year.
    • Create stateful logic apps when you need to keep, review, or reference data from previous events. These logic apps keep the input and output for each action and their workflow states in external storage, which makes reviewing the run details and history possible after each run finishes.
  • or Stateless workflows: Create stateless logic apps when you don’t need to save, review, or reference data from previous events in external storage for later review. These logic apps keep the input and output for each action and their workflow states only in memory, rather than transfer this information to external storage. As a result, stateless logic apps have shorter runs that are usually no longer than 5 minutes, faster performance with quicker response times, higher throughput, and reduced running costs because the run details and history aren’t kept in external storage. However, if or when outages happen, interrupted runs aren’t automatically restored, so the caller needs to manually resubmit interrupted runs. These logic apps can only run synchronously and for easier debugging, you can enable run history, which has some impact on performance.

To do that we can:

  • Select the Logic App (Preview) resource we created previously, My-First-Logic-App-Preview, and then click on the Create Workflow… button.
  • Centered at the top of the VS Code editor window, a wizard will once again appear asking to select a template for your workflow,  select either Stateful Workflow or Stateless Workflow.
    • We will be using Stateful Workflow
  • Provide a workflow name for the workflow you are creating or leave the default name
    • Type My-First-Stateful-Workflow and press Enter
  • This will create locally a workflow.json file that contains your logic app workflow’s underlying JSON definition.
    • Note: the Stateful Workflow is not yet created in Azure.

Since full Logic Apps designer is supported in VS Code in this kind of resource, you may be thinking that now you can switch to Logic Apps designer… Unfortunately, using this creation strategy, you can’t! It will be exactly like the original Logic App extension. Only the code view is supported, and the Designer is read-only.

Does that mean that Logic Apps designer is not supported in VS Code? No, it is, but you need to use a different approach that we will address later in Part III.

You can modify the workflow logic as you want, for example, the bellow code:

Now, to actually create this resource in Azure (in the Logic App (Preview) resource group) you need to:

  • Select the Logic App (Preview) resource we created previously, My-First-Logic-App-Preview, and then click on the Deploy to Logic App… button.
  • If it asks if you are sure and if you want to overlap existing resources, select Yes.

The deployment will make take some minutes to finish. After that, you will be able to see it on the Workflow list inside the Logic App (Preview) resource in VS Code:

Once again, the Designer is read-only.

But you can also find the stateful workflow in the Azure Portal, and from there, you will be able to use the new Logic App Designer.

Of course, all the changes you make in the Portal can be synchronized back to VS Code by selecting the Refresh button

In the next blog post, we will explain a different and more powerful way for you to create your Logic Apps (Preview) projects and workflows. Stay tuned!

The post What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part II) appeared first on SANDRO PEREIRA BIZTALK BLOG.

What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part I)

What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part I)

Microsoft Logic Apps Team recently announced a public preview of the new Logic Apps runtime. This new release adds several new features to Azure Logic Apps, including:

  • Development improvements
    • Full Logic Apps designer support in VS Code;
    • Local project support;
    • New Logic Apps Designer;
  • Hosting Flexibility – ability to run Logic apps workflows where you need to, including on-premises and edge environments
    • Run local (i.e. on my dev box);
    • Deploy to Azure or run containerized in Docker or Kubernetes environments;
  • Performance improvements
    • Stateless mode for low latency – better performance for request/response scenarios;

To create Logic Apps stateful or stateless workflows, you need to use Visual Studio Code and the Azure Logic Apps (Preview) extension – at the moment, there is no other way.

Prerequisites

To be able to use all capabilities of the Azure Logic Apps (Preview) extension for Visual Studio Code, you need:

  • To have Visual Studio Code 1.31.0 (January 2019) or later and you need the following VS Code extensions:
  • An Azure subscription or sign up for a free Azure account.
  • Microsoft Azure Storage Emulator 5.10 tool – This tool is necessary to have the full Logic Apps designer support in VS Code.
  • And finally, you need to install through the Microsoft Installer (MSI) the Azure Functions Core Tools, either version 3.0.2931 or 2.7.2936. These tools include a version of the same runtime that powers the Azure Functions runtime that runs in Visual Studio Code.

Install additional VS Code extensions

To start with, first, you must install the additional VS Code extension from the marketplace. To accomplish that, we need to:

To make sure that all the extensions are correctly installed, reload or restart the VS Code.

Install the Azure Storage Emulator 5.10 tool

To install the Azure Storage Emulator 5.10 tool, follow these steps:

  • Download the tool here: Azure Storage Emulator 5.10 and execute the microsoftazurestorageemulator.msi file.
  • On the Welcome to the Microsoft Azure Storage Emulator – v5.10 Setup Wizard screen, select Next.
  • On the Change, repair, or remove installation screen, select Repair.
  • On the Ready to repair Microsoft Azure Storage Emulator – v5.10 screen, select Repair.
  • On the Completed the Microsoft Azure Storage Emulator – v5.10 Setup Wizard screen, select Finish.

Install the Azure Functions Core Tools

To install the Azure Functions Core Tools, follow these steps:

  • On the End-User License Agreement screen, accept the terms and select Next.
  • On the Destination Folder screen, leave the default, and select Next.
  • On the Ready to install Microsoft Azure Functions Core Tools – 3.0.2931 (x64) screen, select Install.
  • On the Completed the Microsoft Azure Functions Core Tools – 3.0.2931 (x64) Setup Wizard screen, select Finish.

Install Azure Logic Apps extension for Visual Studio Code

To accomplish that, we need to:

  • After installing this extension, you will find the two Azure Logic Apps (Preview) section of the Explore section of the VS Code, but the first thing you need to do is to Sign in to Azure…

Once again, to make sure that this extension is correctly installed, reload or restart the VS Code.

Set up VS Code Azure Logic Apps (preview) extension

For everything to work correctly, you need to make sure that the following two properties are correctly configured:

  • Azure Logic Apps V2: Panel Mode
  • Azure Logic Apps V2: Project Runtime

To do that, you need:

  • Open your VS Code, and on the File menu, go to Preferences, and then Settings.
  • On the User tab, go to > Extensions > Azure Logic Apps (Preview).
  • Check if the Enable panel mode option is selected on Azure Logic Apps V2: Panel Mode property. Otherwise, please enable it.
  • Under Azure Logic Apps V2: Project Runtime, set the version to ~3 or ~2, based on the Azure Functions Core Tools version that you installed earlier.
    • In our case: 3
    • If you want to use the Inline Code action for running JavaScript code, make sure that you use Project Runtime version 3 because the action doesn’t support version 2. Also, this action currently isn’t supported on Linux operating systems.

In the next blog post, we will explain how you can create your first Logic Apps (Preview) project. Stay tuned!

The post What do I need to do to start developing stateful or stateless workflows – Azure Logic Apps (Preview)? (Part I) appeared first on SANDRO PEREIRA BIZTALK BLOG.

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.

BizTalk Server 2020 – 20 days, 20 posts: Carry SOAPHeader To WCF-BasicHttp Pipeline Component for BizTalk Server 2020

BizTalk Server 2020 – 20 days, 20 posts: Carry SOAPHeader To WCF-BasicHttp Pipeline Component for BizTalk Server 2020

BizTalk Server 2020 – 20 days, 20 posts – day 16. We are almost finishing migrating all the BizTalk Pipeline Components Extensions UtilityPack project, today is the component: Carry SOAPHeader To WCF-BasicHttp Pipeline Component.

Carry SOAPHeader To WCF-BasicHttp Pipeline Component

The Carry SOAPHeader To WCF-BasicHttp Pipeline Component is a pipeline component for BizTalk Server which can be used in a send pipeline and is intended to carry forward the received custom SOAP Header to the outgoing message, in other words:

  • This component will read the Custom SOAPHeader from the Message Context Properties
    • The custom header name will be defined on the component configuration and we can read it from the target http://schemas.microsoft.com/BizTalk/2003/SOAPHeader
  • and will configure this custom header in the OutboundCustomHeaders property used by the WCF-BasicHTTP Adapter.

The OutboundCustomHeaders property is used if you want to specify the custom SOAP headers for outgoing messages. When this property is used, the property must have the <headers> element as the root element. All of the custom SOAP headers must be placed inside the <headers> element

  • If the custom SOAP header value is an empty string, you must assign <headers></headers> or <headers/> to this property.

This component is useful if you are implementing CBR operations on legacy service (SOAP – .asmx) using the new WCF-Adapters in BizTalk Server. Notice that the SOAP adapters, still present in BizTalk Server 2020, are obsolete and discontinued.

Carry SOAPHeader To WCF-BasicHttp Pipeline Component

This component requires one configuration that is the SOAPHeaderName where you should specify the SOAP Header name present in the inbound message to be passed to the OutboundCustomHeaders in the outgoing message.

To use this pipeline component in your projects you just copy the CarrySOAPHeader.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: Carry SOAPHeader To WCF-BasicHttp 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: Carry SOAPHeader To WCF-BasicHttp Pipeline Component for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2020 – 20 days, 20 posts: CBR IDoc Operation Promotion Encode Pipeline Component for BizTalk Server 2020

BizTalk Server 2020 – 20 days, 20 posts: CBR IDoc Operation Promotion Encode Pipeline Component for BizTalk Server 2020

BizTalk Server 2020 – 20 days, 20 posts – day 15. Continuing the BizTalk Pipeline Components Extensions UtilityPack project topic, today I released the: CBR IDoc Operation Promotion Encode Pipeline Component.

CBR Operation Promotion Encode Pipeline Component

The CBR IDoc Operation Promotion Encode Pipeline Component is a pipeline component for BizTalk Server which can be used in send pipelines, Encode stage, to promote IDOC Operation property. This component is useful to implement a pure Content-Based Routing solution to integrate with SAP Server.

This component requires one configuration that is the MessageType string to be ignored. Then it will take the last string (word) from the MessageType Message Context Property and promote it to the Operation Message Context Property.

CBR IDoc Operation Promotion Encode Pipeline Component for BizTalk Server 2020

To use this pipeline component in your projects you just copy the CBRIdocOperationPromotionDecode.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: CBR IDoc Operation Promotion Encode 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: CBR IDoc Operation Promotion Encode Pipeline Component for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2020 – 20 days, 20 posts: CBR Operation Promotion Encode Pipeline Component for BizTalk Server 2020

BizTalk Server 2020 – 20 days, 20 posts: CBR Operation Promotion Encode Pipeline Component for BizTalk Server 2020

BizTalk Server 2020 – 20 days, 20 posts – day 14. Continuing the BizTalk Pipeline Components Extensions UtilityPack project topic, today I released the: CBR Operation Promotion Encode Pipeline Component.

CBR Operation Promotion Encode Pipeline Component

The CBR Operation Promotion Encode Pipeline Component is a pipeline component for BizTalk Server which can be used in send pipelines, Encode stage, to promote Operation property. This component is useful to implement a pure Content-Based Routing solution to integrate with SQL Server.

The component will promote Operation property by taking the value (word) which lies ahead of the cardinal (#) from the MessageType message context property and promote it to the Operation Message Context Property.

CBR Operation Promotion Encode Pipeline Component

This component doesn’t require any configuration.

To use this pipeline component in your projects you just copy the CBROperationPromotionDecode.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: XCBR Operation Promotion Encode 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: CBR Operation Promotion Encode Pipeline Component for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.

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

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

BizTalk Server 2020 – 20 days, 20 posts – day 13. Once again, here is another pipeline component migrate to BizTalk Server 2020 that makes part of my BizTalk Pipeline Components Extensions UtilityPack project: XML Namespace Remover Pipeline Component. This component was initially developed by Johan Hedberg

XML Namespace Remover Pipeline Component

The XML Namespace Remover Pipeline Component is a pipeline component for BizTalk Server which can be used in any stage of both receive and send pipelines to remove XML namespaces from XML documents.

This component has the availability to transform the root of the message from this:

&amp;lt;ns0:Blah xmlns:ns0="http://RemoveXmlNamespace.BTS.BlahMessage"&amp;gt;

Into this:

&amp;lt;Blah&amp;gt;

If you have the option, you shouldn’t remove the namespace from the messages. However, we don’t leave in a perfect world and we need to deal with legacy systems and sometimes they required, for unknown reasons for me, that we deliver messages without namespace.

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