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.
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.
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.
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
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.
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
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.
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
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 Shopifyand 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 Shopifydocumentation, 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.
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:
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
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
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
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:
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
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
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