Resurrecting BizTalk’s Wisdom: Rediscovering Forgotten BizTalk Whitepapers

Resurrecting BizTalk’s Wisdom: Rediscovering Forgotten BizTalk Whitepapers

Lately, I’ve been engaged in the process of cleaning and reorganizing my hard drives. The sheer volume of resources I’ve accumulated over the years is quite substantial. However, there are occasions when I find myself a bit frustrated in my quest to locate them. Additionally, I’ve been revisiting a few of my online profiles and initiating the process of consolidating my resources on GitHub.

As I embarked on this quest, I stumbled upon some of my vintage articles originally crafted for Microsoft TechNet Wiki. Astonishingly, I recognized that a handful of these articles had laid the foundation for my first book: BizTalk Mapping Patterns and Best Practices.

Considering the product’s inherent characteristics, they all remain exceptionally current and relevant, so I decided to add them to my GitHub repo.

BizTalk Server: Basic Principles of Maps

Maps or transformations are among the most common components in the integration processes. They act as essential translators in the decoupling between the different systems to connect. In this article, as we explore the BizTalk Mapper Designer, we will explain its main concepts, covering slight themes such as
product architecture, BizTalk Schemas, and some of the mo st widely used standards in the translation of
messages.

This whitepaper aims to serve as an introductory guide for individuals embarking on their initial journey with this technology.

For Portuguese speakers, the same whitepaper can be found here as well: BizTalk Server: Princípios básicos dos Mapas.

BizTalk Server: How Maps Work

Maps or transformations are a cornerstone of integration processes, functioning as essential translators that facilitate the seamless exchange of information among different systems. This whitepaper is aimed at demystifying how maps are processed internally by the engine of the product as we explore the map editor BizTalk Server.

For Portuguese speakers, the same whitepaper can also be found here: BizTalk Server: Como funcionam os mapas.

Microsoft BizTalk Server seen by the programmer’s eyes

Originally featured in the Portuguese magazine ‘Programar’, this whitepaper has since been translated into English. Its primary objective is to explore the advantages that the BizTalk Server platform offers to developers.

The same whitepaper for Portuguese speakers can also be found here: BizTalk Server aos olhos dos programadores.

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

Logic Apps Consumption: How to get the Logic App error detail message guide

Logic Apps Consumption: How to get the Logic App error detail message guide

I have often been writing about how to handle exceptions and get the correct and detailed error message describing in an easy and clean matter the failures in our processes:

And the reason why that happens is that we need to accept the fact that at a certain point in time, our process will fail. Or by the fact we did some updates that weren’t tested properly, an external system is down or in intervention, or by issues in Microsoft infrastructure, and so many other reasons. But when that happens, one thing is clear: we want to get the exact error message describing why it failed. But, of course, we can always go to the Logic Apps run history – except if it is a Stateless workflow on Standard – to check where and why it failed. And obviously, we will have all the information necessary to solve the problem. However, most of the time, if not always, we want to log the error in some place like Application Insights, SQL Database, Event Hubs, and so on in an automated way without human intervention. To accomplish that, we need to access this error message in runtime.

By default, Logic App allows handling errors using the Configure run after settings at a per action level. For more complex scenarios, it can be done by setting up Scope action and implementing try-catch/try-catch-finally statements. However, getting a detailed error message can be a bit challenging inside Logic App, and you will find different approaches to implement the same capabilities, each of them with advantages and disadvantages.

For those reasons, my teammate Luis Rigueira and I decided to create this 60 pages detailed whitepaper: Logic Apps Consumption – How to get the Logic App error detail message guide.

What’s in store for you?

In this whitepaper, we will be addressing some of the possible ways to address these needs but also addressing some of the following questions:

  • How can I implement error handling?
    • This is an important question and topic because, without proper error handling, we will not be able to send in an automated way access the error message instead, our workflow will finish in that action with a failure state.
  • What out-of-the-box features do I have to capture and access the error details?
  • How can I improve these default features in a no-code, low-code way and in a code-first approach?

Where can I download it

You can download the whitepaper here:

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

A Comprehensive Guide For Logic Apps Standard REST APIs

A Comprehensive Guide For Logic Apps Standard REST APIs

Azure REST APIs are service endpoints that support sets of HTTP operations (methods), which provide create, retrieve, update, or delete access to all Azure service’s resources. You may know, and many of you may be familiar with Logic Apps Consumption REST APIs that are very well documented by Microsoft here: Azure Logic Apps.

However, for those who didn’t know about this, I recommend you go there and have a look. You may find them very useful for achieving many things and automating certain tasks. One of these cases is the strategy I documented to get the error message from a particular failure inside Logic App Consumption, where I invoke the Get Workflow Run method to get the run history of a particular run in order
to extract the correct error message. You can read more about it here: How to get the Error Message with Logic App Try-Catch (Part II) – Using an Azure Function.

Another great thing about this Microsoft REST APIs documentation is the availability to try them directly from the documentation page. But unfortunately, these REST APIs can be applied only to Logic Apps Consumption. There isn’t any official REST APIs documentation available for Logic Apps Standard, and yes, they are different. A few months ago I decided to start documenting the new Logic Apps Standard REST APIs publishing three blog posts:

But that were only a few parts of the existing RESP APIs.

Now I have created a comprehensive whitepaper or guide about Logic Apps Standard REST APIs that you can download for free here: Logic Apps Standard Rest API’s a Comprehensive Guide.

What’s in store for you?

This whitepaper will give you a detailed understanding of the following:

  • A short introduction to Logic App Consumption REST APIs.
  • Comprehensive details about Logic Apps Standard REST APIs:
    • Workflow operations: For example, it provides operations for creating and managing workflows.
    • Workflow Runs operations: For example, it provides operations for listing and canceling workflow runs.
    • Workflow Run Actions operations: For example, it provides operations for lists of workflow run actions.
    • Workflow Versions operations: For example, it provides operations for lists of workflow versions.
    • Workflow Triggers operations: For example, it provides operations for listing and running workflow triggers.
    • Workflow Trigger Histories operations: For example, it provides operations for listening workflow trigger histories.
    • Logic App operations: For example, it provides that you can apply at the Logic App Standard App level.
    • App Service Plans: For example, it lists App Service Plan REST APIs operations that are interested in using bind with Logic App Standard.

Where can I download it?

You can download the whitepaper here:

I hope you enjoy reading this paper and any comments or suggestions are welcome.

Big thanks to my team member Luis Rigueira for contributing to this whitepaper as a Co-Author!

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

Using Liquid filters in APIManagement to transform messages whitepaper

Using Liquid filters in APIManagement to transform messages whitepaper

Those who know me and follow me are used to seeing me publishing several resources, including whitepapers. But this one is different! Typically, when it comes to whitepapers or books, I usually release them in BizTalk360 or Serveless360, a partnership that I have since many years, and you should expect to find it more in the future. However, this is the first whitepaper I have published under the DevScope umbrella, and I could be so proud of the result.

Note: not only I’m proud of the end result of this whitepaper, which I personally find this information very useful, but I’m also in love with my new corporate photo!

I typically write about “stuff” I work on daily bases, and for the past months, I have been working a lot with Liquid Template to perform transformations on API Management. Liquid is an open-source template language created by Shopify and written in Ruby. It is the backbone of Shopify themes and is used to load dynamic content on storefronts. However, Azure API Management uses a subset of Liquid templating language to transform the body of a request or response: DotLiquid

If it is true that we can find excellent Shopify documentation, the same may not be that simple for DotLiquid, and I struggle a little to get decent examples of how to use Liquid Filters in API Management, and that was the main reason why I decided to write this whitepaper.

What is DotLiquid?

DotLiquid is a deviation from Shopify’s original liquid template language. It is a .Net port of the popular Shopify’s Liquid templating language. It is a separate project that aims to retain the same template syntax as the original while using .NET coding conventions where possible. However, they are not entirely the same. In some cases, they have different behaviors.

Liquid uses a combination of objects, tags, and filters inside template files to display dynamic content.

Where:

  • Objects contain the content that Liquid displays on a page. Objects and variables are displayed when enclosed in double curly braces: {{ and }}.
Hi my name is {{ author.name }}
  • Tags create the logic and control flow for templates. The curly brace percentage delimiters {% and %} and the text that they surround do not produce any visible output when the template is rendered. This lets you assign variables and create conditions or loops without showing any of the Liquid logic on the page.
{% if author %}
 Hi my name is {{ author.name }}!
{% endif %}
  • Filters change the output of a Liquid object or variable. They are used within double curly braces {{ }} and variable assignment and are separated by a pipe character |.
{{ "Sandro" | Append: " Pereira" }}

In this whitepaper, I’m going to focus on the DotLiquid Filters you can use on API Management to transform the body of a request or response.

What is a liquid filter?

As mentioned above, Filters change the output of a Liquid object or variable. They are used within double curly braces {{ }} and variable assignment and are separated by a pipe character |. They are like functions in C# code or Functoids in BizTalk Server maps.

If we apply, for example, the Append filter like:                                                              

{% assign myvariable = "Sandro" %}
{{ myvariable | Append: " Pereira" }}   

The end result will be: Sandro Pereira

We can also apply multiple filters on one output which are applied from left to right. Like a PowerShell pipeline. A PowerShell pipeline is a series of commands connected by pipeline operators (|). Each pipeline operator sends the results of the preceding command to the next command. Filters use the same concept. For example:

"Name": "{{ "Sandro Pereira" | Split: " " | Last }}"

The end result here will be: “Name”: “Pereira”

Download

You can see the official release announcement here: Download Sandro Pereira’s whitepaper on Liquid Filters.

You can download, for free, the Using Liquid filters in APIManagement to transform messages whitepaper here:

Hope you find this useful! So, if you liked the content or found it useful 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

Logic App Standard CI/CD from zero to hero whitepaper

Logic App Standard CI/CD from zero to hero whitepaper

Continuous integration/continuous delivery (CI/CD) pipelines are a practice focused on improving software delivery using a DevOps approach.?

A CI/CD pipeline may sound like overhead, but it isn’t. It’s essentially a runnable specification of the steps that any developer needs to perform to deliver a new software product version. In the absence of an automated pipeline, Engineers would still need to perform these steps manually and, therefore, be far less productive.

This is a must to have when deploying resources to Azure! Especially for non-development environments.

In this whitepaper, I will address and explain in a detailed way a complete guide for automating the implementation of Logic Apps Standard using Azure DevOps Pipelines.

I will explain in detail all the basic things you have to know, from the creation of a Logic App Standard on Visual Studio Code to everything you need to create and configure inside DevOps to archive the implementation of the CI/CD process.

What’s in store for you?

This whitepaper will give you a detailed understanding of the following:

  • An introduction to:
    • What are Continuous Integration (CI) and Continuous Deployment (CD)?
    • What are CI/CD Pipelines?
    • What is Azure DevOps?
  • Create an organization or project collection in Azure DevOps
  • Create a project in Azure DevOps
  • Building your Logic App Standard from scratch
    • Publish your code from Visual Studio Code
  • A step-by-step approach to building Azure Pipelines
  • A step-by-step approach to building Azure Release Pipelines

Where can I download it

You can download the whitepaper here:

I hope you enjoy reading this paper and any comments or suggestions are welcome.

Azure Function App CI/CD from Zero to Hero whitepaper

Azure Function App CI/CD from Zero to Hero whitepaper

Continuous Integration and Continuous Deployment (CI/CD) is a practice that has become an essential aspect of Azure development. Although it is possible to execute each of the CI/CD pipeline steps manually, the actual value can be achieved only through automation.

And to improve software delivery using CI/CD pipelines, either a DevOps or a Site Reliability Engineering (SRE) approach is highly recommended.

In this whitepaper, I will address and explain how you can implement CI/CD oriented to Azure Function Apps using Azure DevOps Pipelines.

I will explain in detail all the basic things you have to know, from the creation of an Azure Function on Visual Studio 2022 to everything you need to create and configure inside DevOps to archive the implementation of the CI/CD process using Azure Functions.

What’s in store for you?

This whitepaper will give you a detailed understanding of the following:

  • An introduction to:
    • What are Continuous Integration (CI) and Continuous Deployment (CD)?
    • What are CI/CD Pipelines?
    • What is Azure DevOps?
  • Create an organization or project collection in Azure DevOps
  • Create a project in Azure DevOps
  • Building your Azure Function from scratch
    • Publish your code from Visual Studio
  • A step-by-step approach to building Azure Pipelines
  • A step-by-step approach to building Azure Release Pipelines

Where can I download it

You can download the whitepaper here:

I hope you enjoy reading this paper and any comments or suggestions are welcome.

BizTalk Server 2020: Step-by-Step WCF-ORACLE Adapter installation guide

BizTalk Server 2020: Step-by-Step WCF-ORACLE Adapter installation guide

Oracle Database (commonly referred to as Oracle DBMS or simply as Oracle) is a multi-model database management system produced and marketed by Oracle Corporation. It is a database commonly used for running online transaction processing (OLTP), data warehousing (DW), and mixed (OLTP & DW) database workloads.

One of the most common scenarios we face in several organizations is to be able to integrate other systems and applications with Oracle, and for that, BizTalk Server uses the Microsoft BizTalk Adapter for Oracle Database or simply the WCF-ORACLE adapter.

The Microsoft BizTalk Adapter for Oracle Database exposes the Oracle database as a WCF service. Adapter clients can perform operations on the Oracle database by exchanging SOAP messages with the adapter. The adapter consumes the WCF message and makes appropriate ODP.NET calls to perform the requested operation. The adapter returns the response from the Oracle database back to the client in the form of SOAP messages.

The Oracle Database adapter surfaces metadata of Oracle database artifacts (tables, functions, procedures, etc.) that describes the structure of a SOAP message in the form of Web Service Description Language (WSDL).

  • It uses the Add Adapter Service Reference Visual Studio Plug-in, the Consume Adapter Service BizTalk Project Add-in, and the Add Adapter Metadata Wizard to enable adapter clients to retrieve metadata for operations and generate programming artifacts that can be used in your programming solution.
  • And it communicates with the Oracle database through the Oracle Data Provider for .NET (ODP.NET) and the Oracle client, which are part of the Oracle Data Access Components (ODAC) for Windows.

The following figure shows the end-to-end architecture for solutions that are developed by using the Oracle Database adapter:

This paper explains in detail – a step-by-step guideline – how to install and configure the WCF-OracleDB Adapter on a BizTalk Server 2020 standalone environment running Windows Server 2019.

What’s in the Whitepaper for you?

This whitepaper will give you a detailed understanding of the following:

  • Installation requirements
    • Supported systems
  • Install Oracle Data Access Components (ODAC)
    • Installation checks
    • Testing Oracle connectivities

Where can you download it

You can download the whitepaper here:

BizTalk Server 2020: End-to-end Scenario – Receiving messages through the HTTP adapter whitepaper

BizTalk Server 2020: End-to-end Scenario – Receiving messages through the HTTP adapter whitepaper

The role of an adapter is to enable communications between BizTalk Server and external systems and trading partners. Users configure adapters by creating send ports and receive locations that define the properties for given instances of the adapter. Most adapters support both send and receive operations, whereas other adapters support communication in only one direction.

The HTTP Adapter is one of the adapters that support two-way communications, but unlike other adapters, this adapter has two characteristics that define it:

  • The HTTP “Receive” Adapter that is responsible for delivering messages to BizTalk is, in fact, a DLL that runs inside Internet Information Services (IIS)
  • And for that reason, it must be configured in IIS – it is not there out-of-the-box.

In this whitepaper, we will describe the step-by-step process of installing and configuring the HTTP Adapter in order to receive messages.

Some of you may think that the HTTP adapter is deprecated, but that is not true. The only adapters that were deprecated were the old SAP adapter (removed) and the SOAP and SQL adapter (that still are present in the Administration Console). The HTTP adapter is a classic but is not deprecated and is still very used today.

The idea for this whitepaper was partly out of a real need and at a customer’s request. Because it is a strange adapter with a peculiar configuration unlike any other adapter in BizTalk Server, when I was giving a training course, the attendees struggled to understand and put it working correctly. By coincidence, a week later, I needed to put this adapter working at another client.  As a result of that request and that client’s need, I end up creating this step-by-step guide on how to install and configure the HTTP adapter to receive messages through HTTP requests. I think this is a good whitepaper about a classic adapter in BizTalk Server.

There is a similar whitepaper that I wrote in the past: BizTalk Server 2016: Receiving messages through the HTTP Adapter installation whitepaper focus on BizTalk Server 2016 as the name describes. This new one is just a small update on the BizTalk Server versioning and is to be updated with the latest version of the BizTalk Server.

What’s in the Whitepaper for you?

This whitepaper will give you a detailed understanding of the following:

  • Prerequisites
  • Configure the HTTP Receive Adapter in IIS
  • Configure the HTTP Adapter Receive and Send Handlers
    • Receiving messages using the HTTP Adapter
    • Testing our solution

Where can you download it

You can download the whitepaper here:

Installing BizTalk Server 2020 in a Basic Multi-Computer Environment Guide

Installing BizTalk Server 2020 in a Basic Multi-Computer Environment Guide

There are many things to consider when planning this type of installation. This whitepaper will explain in detail – a step-by-step guideline – how to install and configure Microsoft BizTalk Server 2020 on a basic multi-computer environment using Windows Server 2019, i.e., installation of BizTalk Server with a remote SQL Server (1 SQL Server and 1 BizTalk Server). There will be 3 virtual servers:

  • 1 Domain controller
  • 1 Virtual Machine to host SQL Server
    • Windows Server 2019
    • SQL Server 2019SQL Server 2019 Enterprise Edition
  • 1 Virtual Machine to host BizTalk Server.
    • Windows Server 2019
    • BizTalk Server 2020 Enterprise or Development Edition

In this scenario, I will perform a basic full installation of Microsoft BizTalk Server 2020, except for the SharePoint Adapter and additional components like Accelerators, ESB Toolkit or UDDI, emulating a production environment. The following components will be installed:

  • Enterprise Single Sign-On (SSO)
  • BizTalk Group
  • BizTalk Runtime
  • Business Rule Engine
  • BAM Tools and Alerts
  • BAM Portal (Although Microsoft has deprecated the BAM portal, it is still possible to install it.)
  • BizTalk EDI/AS2 Runtime
  • Microsoft BizTalk Adapters

This information will help you plan the installation and configuration of BizTalk Server 2020, applications, and components on which it depends focused on creating a UAT or Production environment (you can also follow this tutorial to help you create developer environments. However, if this is the case, you need to add some steps and additional components or software, in especially Visual Studio 2019).

Of course, it is assumed that all machines are already installed with the operating system and the latest critical Windows updates from Microsoft. Another presumption is that the domain controller is already installed and configured.

What’s in the Whitepaper for you?

This whitepaper will give you a detailed understanding of the following:

  • The need for a Domain Controller – Windows Groups and Service Accounts
  • Preparing Computers for Installation – Important considerations before setting up the
  • servers
  • Preparing and Install SQL Server 2019 machine
  • Prepare and install prerequisites on BizTalk Server 2020 machine
  • Testing environment connectivity
  • Install and configure BizTalk Server 2020 machine
  • Optimize the BizTalk Server 2020 environment

Where can you download it

You can download the whitepaper here:

BizTalk Server 2020: Step-by-Step WCF-SAP Adapter installation guide

BizTalk Server 2020: Step-by-Step WCF-SAP Adapter installation guide

There was a lot of inconsistent and incorrect information about the BizTalk WCF-SAP Adapter installation process and how it works, especially in old versions of the adapter where there was a need to use the classic RFC library to connect to SAP.

Fortunately for us, this process is now simpler and more direct, and this is due specifically to two points:

  • The Classic RFC Library has been discontinued and is no longer supported (support ended on March 21, 2016). All customers should, if not already using, the “new” SAP .NET Connector (NCo) 

Notice that the BizTalk Adapter Pack WCF-SAP adapter has been re-engineered to use SAP .NET Connector instead of the classic SAP RFC SDK. The SAP .NET Connector is available through the ConnectorType property within the WCF-SAP binding. This feature is available from BizTalk Server 2013 and above.

  • On BizTalk Server 2020, the Microsoft BizTalk Adapter Pack x86 and x64 are now installed with the default installation process. That means that the WCF-SAP adapter is already registered on the server and present on the BizTalk Server Administration Console.

However, that does not mean that everything is ready for you to be able to use this adapter. Unfortunately, you still need to install the SAP Connector for Microsoft .NET available for you to download through the SAP Service Marketplace.

Notice that, like any other adapter, the 64-bit version of the SAP Connector for Microsoft .NET is optional, but if you have a 64-bit BizTalk environment and you want to run it under a 64-bit Host Instance, then you need to also install both versions of the SAP Connector for Microsoft .NET.

BizTalk Server 2020: Step-by-Step WCF-SAP Adapter installation guide

By reading this whitepaper, decision-makers should have more information on the following areas:

  • Pre-requirements resources that are necessary and how to install them
  • Register the adapter in BizTalk Server Administration Console

Where can I download it?

You can download the whitepaper here: