This guideline is focused on clients considering or having already decided to move their entire BizTalk Server on-premises integration solution to Azure or parts of the solution into Azure, therefore, making some hybrid solutions. Of course, in this process, many questions about best practices to use, what services to use, and others will be raised.
This guide provides an overview of the reasons and benefits, product comparisons, capabilities, and other information to help you start migrating from on-premises BizTalk Server solutions to cloud-based Azure Integration Services. Following this guide, you’ll find more guides that cover how to choose the services that best fit your scenario, along with migration strategies, planning considerations, and best practices to help you deliver successful results:
This is a simple feature matchup diagram that you will find in the guide:
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
Today while my team and I were trying to do a small Logic App proof-of-concept using a Request – When a HTTP request is received trigger – something quite simple and basic – with a simple JSON payload like:
We were always getting the following error when we were trying to trigger the Logic App using Postman:
InvalidTemplate. Unable to process template language expressions for action ‘For_each’ at line ‘0’ and column ‘0’: ‘The template language expression ‘triggerBody()?[‘Data’]’ cannot be evaluated because property ‘Data’ cannot be selected. Property selection is not supported on values of type ‘String’. Please see https://aka.ms/logicexpressions for usage details.’.
To be honest, I was getting annoyed because this a simple stuff that I have done thousands of times!
Cause
Unfortunately, I cannot use the common excuse: “sorry, it is Friday!” because today is Tuesday :). But I can always say that most of the time the error resides between the chair and the keyboard! ?
You may pay more attention to the Logic App designer when you define a JSON Schema in your When a HTTP request is received trigger. It will warn you not to forget to include a Content-Type header set to application/json in your request!
If you do not provide the Content-Type header, it will assume that is plain text, and it will not parse the JSON and render all the properties, so it will not going to be tokenized, and there you will get this or similar errors.
Solution
The solution is quite simple, on the Postman request add a Content-Type header and set it to application/json.
If you try again… problem is solved!
Hope you find this useful!
My youngest son (almost 5 years old) is a big Star Wars fan, and when I’m trying to write something, and he arrives home and want to play with me, I always say to him: Let the father finish work to earn some money so we can buy more toys… now I promise him that all contributions from my blog are going to be used for buying Star Wars Legos!
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
I’m back to another blog post about BizTalk Server! I know that my latest post has been about Azure Logic Apps, and you may count on seeing many more in the future. And the reason is that I work both on-premise with BizTalk Server and in the cloud with Azure Integration Services… but relax, I will continue to post many things about BizTalk Server. BizTalk Server is not dead. It is well alive, contrary to what many think!
For those who aren’t familiar with it, the BizTalk Pipeline Components Extensions Utility Pack project is a set of custom pipeline components (libraries) with several custom pipeline components that can be used in receive and sent pipelines. Those pipeline components provide extensions of BizTalk’s out-of-the-box pipeline capabilities.
CSV Structure Validation Pipeline Component
The CSV Structure Validation Pipeline Component is a pipeline component that can be used to validate the structure of a basic CSV or flat file component before being converted to an XML message. Of course, this same strategy can be used in more complex scenarios.
This is the list of properties that you can set up on the CSV Structure Validation pipeline component:
Property Name
Description
Sample Values
DelimiterChar
Define what is the delimiter char inside a line.
;
NumberFieldsPerLine
Number of fields expected per line
3
Note that this component takes as granted that the line delimiter is the CRLF (Carriage ReturnLine Feed).
If we take this example:
one;two;t
1;2;2
Then we need to configure the port in the following way:
If we receive an invalid file, then the component will raise an error suspending the message in the BizTalk Server Administration Console. For example, with the following error message:
Invalid format data in the document. Line number 3 has 2 fields, and it should be expected 3 fields
If you are wondering why create a Pipeline component to validate the structure of the CSV or flat-file document? Can we use instead the Flat-File Schema to do this structure validation?
And the answer is Yes and No! In many cases and with many requirements, we don’t need to create a custom pipeline component. Using a Flat-File schema can be used to address the goals but in other scenarios doing a CSV Validation with the Flat-File schema is not enough. However, I will leave that “discussion” to my next BizTalk Server Best practices, tips and tricks.
How to install it
As always, you just need to add these DLLs on the Pipeline Components folder that in BizTalk Server 2020 is by default:
Like all previous, to use the pipeline component, I recommend you to create generic or several generic pipelines that can be reused by all your applications and add the Message Archive Pipeline Component in the stage you desire. The component can be used in a stage of the receive and send pipelines.
Download
THIS COMPONENT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download CSV Structure Validation Pipeline Component from GitHub 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
I had the pleasure of being invited a few weeks ago by my friend – and now Microsoft Principal Product Manager – Azure Logic Apps – Kent Weare to record a special episode on Logic Apps Development Tips and Tricks on his YouTube channel.
First of all, if you are unaware of his YouTube channel and you like or are interested in Azure Integration Services, I suggest you follow his channel, which is full of fantastic content. You can check and follow his channel here: https://www.youtube.com/@KentWeare
In this episode, we are going to discuss some of the most basic and important Logic Apps development best practices, tips, and tricks:
Naming Conventions, which will include Logic App, Action, and Connectors naming conventions
Error Handling and how to retrieve the error message inside Logic Apps
For Each Parallelism
Fixing API Connections and why you should care about this.
and comparing Logic Apps (Standard) and Azure Logic Apps (Consumption)
You can see the full episode here: https://www.youtube.com/watch?v=cLzplA1xVaM&t=479s
Let me know what you think about these Best practices, tips, and tricks or what you would like to be addressed in my series of blogs about this topic.
You can check all my tips and tricks here:
And of course, stay tuned for more Logic App Best practices, Tips, and Tricks.
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
Workflow Triggers: Provides operations for listing and running workflow triggers.
Workflow Versions: Lists workflow versions.
Workflows: Provides operations for creating and managing workflows.
Today we are going to address the Workflow Trigger Histories REST APIs for Logic App Standard.
Workflow Trigger Histories
These are the available operations:
Get: Gets a workflow trigger history.
List: Gets a list of workflow trigger histories.
Resubmit: Resubmits a workflow run based on the trigger history.
This list may change since this is not the official list, and many things under the hood are different from Consumption to Standard.
Get
Request URL:
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/icrosoft.Web/sites/{logicAppStdName}/hostruntime/runtime/webhooks/workflow/api/management/workflows/{workflowName}/triggers/{triggerName}/histories/{historyName}?api-version=2018-11-01
URI Parameters:
Name
In
Required
Type
Description
subscriptionId
path
True
string
The subscription id.
resourceGroupName
path
True
string
The resource group name.
logicAppStdName
path
True
string
The Logic App Standard name.
workflowName
path
True
string
The workflow name.
triggerName
path
True
string
The workflow trigger name.
historyName
path
True
string
The workflow trigger history name. Corresponds to the run name for triggers that resulted in a run.
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppStdName}/hostruntime/runtime/webhooks/workflow/api/management/workflows/{workflowName}/triggers/{triggerName}/histories?api-version=2018-11-01
URI Parameters:
Name
In
Required
Type
Description
subscriptionId
path
True
string
The subscription id.
resourceGroupName
path
True
string
The resource group name.
logicAppStdName
path
True
string
The Logic App Standard name.
workflowName
path
True
string
The workflow name.
triggerName
path
True
string
The workflow trigger name.
api-version
query
True
string
The API version.
$filter
query
False
string
The filter to apply on the operation. Options for filters include: Status, StartTime, and ClientTrackingId.
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/icrosoft.Web/sites/{logicAppStdName}/hostruntime/runtime/webhooks/workflow/api/management/workflows/{workflowName}/triggers/{triggerName}/histories/{historyName}/resubmit?api-version=2018-11-01
URI Parameters:
Name
In
Required
Type
Description
subscriptionId
path
True
string
The subscription id.
resourceGroupName
path
True
string
The resource group name.
logicAppStdName
path
True
string
The Logic App Standard name.
workflowName
path
True
string
The workflow name.
triggerName
path
True
string
The workflow trigger name.
historyName
path
True
string
The workflow trigger history name. Corresponds to the run name for triggers that resulted in a run.
We may also get some errors if you try to resume an invalid instance.
Stay tuned for the next Operation Group: Workflow Triggers.
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
Workflow Triggers: Provides operations for listing and running workflow triggers.
Workflow Versions: Lists workflow versions.
Workflows: Provides operations for creating and managing workflows.
Today we are going to address the Workflow Runs REST APIs for Logic App Standard.
Workflow Runs
These are the available operations:
Cancel: Cancels a workflow run.
Delete: Deletes a workflow run.
Get: Gets a workflow run.
List: Gets a list of workflow runs.
This list may change since this is not the official list, and many things under the hood are different from Consumption to Standard.
Cancel
Request URL:
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppStdName}/hostruntime/runtime/webhooks/workflow/api/management/workflows/{workflowName}/runs/{runId}/cancel?api-version=2018-11-01
We may also get some errors if you try to cancel an already completed instance.
{
"error": {
"code": "WorkflowRunCanNotBeCancelled",
"message": "The workflow 'DemoHTTP' run '08585286433641737811956886654CU00' with state 'Succeeded' could not be canceled, because it is not active."
}
}
Note: I wasn’t able to successfully test this API. But I assume it will exist.
Get
Request URL:
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppStdName}/hostruntime/runtime/webhooks/workflow/api/management/workflows/{workflowName}/runs/{runId}?api-version=2018-11-01
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{logicAppStdName}/hostruntime/runtime/webhooks/workflow/api/management/workflows/{workflowName}/runs?api-version=2018-11-01
URI Parameters:
Name
In
Required
Type
Description
subscriptionId
path
True
string
The subscription id.
resourceGroupName
path
True
string
The resource group name.
logicAppStdName
path
True
string
The Logic App Standard name.
workflowName
path
True
string
The workflow name.
api-version
query
True
string
The API version.
$filter
query
False
string
The filter to apply on the operation. Options for filters include: Status, StartTime, and ClientTrackingId.
Stay tuned for the next Operation Group: Workflow Trigger Histories.
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