Logic App Consumption Deployment: The trigger ‘…’ of current version of workflow ‘…’ has concurrency runtime configuration specified. Trigger concurrency runtime configuration cannot be removed once specified.

Logic App Consumption Deployment: The trigger ‘…’ of current version of workflow ‘…’ has concurrency runtime configuration specified. Trigger concurrency runtime configuration cannot be removed once specified.

And yet another Logic App Consumption Deployment issue, and more to come! Like the previous posts, while trying to deploy an existing Logic App Consumption thru Visual Studio 2019 in our development environment, I got the following error message:

Resource Microsoft.Logic/workflows ‘LA-NAME’ failed with message ‘{
“error”: {
    “code”: “CannotDisableTriggerConcurrency”,
    “message”: “The trigger ‘When_one_or_more_messages_arrive_in_a_topic_(peek-lock)’ of current version of workflow ‘LA-NAME’ has concurrency runtime configuration specified. Trigger concurrency runtime configuration cannot be removed once specified.”
  }
}’

This error happened because I tried to modify the Logic App Consumption Trigger from When one or more messages arrive in a topic (peek lock) to When one or more messages arrive in a topic (auto-complete).

Cause

The cause of the problem is simple to understand based on the error message. The trigger of the currently deployed version of the Logic App has Concurrency Control settings enabled. We can validate that by:

  • Right-click on the 3 dots on the Trigger and select the Settings option.
  • On the Settings windows of the trigger, we can validate that the Concurrency Control option is enabled and defined to have a Degree of Parallelism of 5.

Saying that, and despite the cause of the problem being easy to understand, the reason why this happens is not that clear. Still, it seems for some internal reason in the Logic App Runtime, after you set up the trigger to have Concurrency Control enabled, you cannot revert that configuration. You cannot do it while trying to deploy a new version of the Logic App thru Visual Studio, nor go directly to the Azure Portal and perform the same actions.

From Azure Portal or Visual Studio (it doesn’t matter the tool you use), if you try to:

  • Update the existing trigger to disable the Concurrency Control option and try to save it. It doesn’t work.
  • Delete the current trigger and add a new one. It doesn’t work, either.

Again, this seems to be a limitation that exists at the moment in the Logic App Consumption Runtime – not sure at this point if you will have the same limitation/issue in Logic App Standard.

Solution

Fixing this issue is not that simple. We can’t fix it, but we can apply two workarounds:

  • Workaround 1: if you don’t need to keep the run history of the existing Logic App.
  • Workaround 2: if you need to keep the run history of the existing Logic App.

Workaround 1

  • Delete from the Azure Portal the existing Logic App by selecting the Logic App and then, on the top menu, click the Delete option.
  • And then redeploy the Logic App.

This will solve the deployment problem, but again you will lose the run history.

Workaround 2

If you need to keep the run history, then unfortunately, the only option you have is to provide a different name to your Logic App, something like:

  • LA-NAME-V2

Make sure you change that, at least in the LogicApp.parameters.json file, but I suggest you change that also in the LogicApp.json file.

Just make sure you disable the “old” one – LA-NAME – and create a TAG specifying that it is deprecated.

After you validate everything is working fine and you don’t need the run history of the old one anymore, delete this Logic App to avoid confusion and to be simple to manage the overall solution.

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 Consumption Deployment: Deployment template validation failed: ‘The template parameters ‘…’ in the parameters file are not valid

Logic App Consumption Deployment: Deployment template validation failed: ‘The template parameters ‘…’ in the parameters file are not valid

Like the previous post, while trying to deploy an existing Logic App Consumption thru Visual Studio 2019 in our development environment, I got the following error message:

Template deployment returned the following errors:

Error: Code=InvalidTemplate;

Message=Deployment template validation failed: ‘The template parameters ‘name-of-the-parameter’ in the parameters file are not valid; they are not present in the original template and can therefore not be provided at deployment time. The only supported parameters for this template are ‘list-of-parameters-present-in-the-LogicApp’. Please see https://aka.ms/arm-pass-parameter-values for usage details.’.

The deployment validation failed.

Cause

The cause of the problem is once again quite simple, and the error description is really good, not only describing the problem but providing the solution also.

In my case, the error says that “arm_ServiceBus_Subscription_A” doesn’t exist – is not valid – in the template parameter file that I’m using to deploy the Logic App Consumption thru Visual Studio. And it also says that the only supported parameters for this template are:

  • arm_ServiceBus_Subscription_ABC
  • arm_ServiceBus_Connection_Name
  • arm_ServiceBus_Connection_DisplayName
  • arm_ServiceBus_Topic
  • arm_LA_InitialState

Solution

Fixing this issue is simple, and you have three options that you need to choose according to your scenario:

  • Remove/delete this template parameter from the parameters file.
  • Rename this parameter to a valid one.
  • Or add this ARM parameter in the LogicApp.json file
    • Perhaps this last option is the most unlikely to happen since this would mean that you would have to change the code to include this parameter in some content or configuration of the actions or settings of the Logic App – what is the point of having an ARM parameter defined if you don’t really need it.
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 Consumption Deployment: The inputs of template action ‘…’ cannot reference action ‘…’

Logic App Consumption Deployment: The inputs of template action ‘…’ cannot reference action ‘…’

Today while trying to deploy an existing Logic App Consumption thru Visual Studio 2019 in our development environment, I got the following error message:

"error": {
     "code": "InvalidTemplate",
     "message": "The template validation failed: 'The inputs of template action 'name_of_the_action_with_error' at line '1 and column '5938' cannot reference action 'name_of_the_action_that_is_being_referenced'. Action 'name_of_the_action_that_is_being_referenced' must either be in 'runAfter' path or within a scope action on the 'runAfter' path of action 'name_of_the_action_with_error', or be a Trigger.'."
}

The template validation failed: ‘The inputs of template action ‘name_of_the_action_with_error’ at line ‘1 and column ‘5938’ cannot reference action ‘name_of_the_action_that_is_being_referenced’. Action ‘name_of_the_action_that_is_being_referenced’ must either be in ‘runAfter’ path or within a scope action on the ‘runAfter’ path of action ‘name_of_the_action_with_error’, or be a Trigger.

Cause

The cause of the problem is quite simple, once you check the underline code in your Logic App workflow. In my case, because I copied and pasted the properties from another action below into this one, I unintentionally was referring inside the add expression, an action that at that point didn’t exist in that workflow step – the action was only created four steps below as you see in the picture:

And indeed, the error message is correct. You can only reference actions that exist before the current action – within a scope action on the ‘runAfter’ path – or from the trigger.

Solution

Fixing this issue is simple. In my case, this Parse JSON – Message Properties action is trying to parse the existing Properties of the trigger – so I had two options:

  • Move the Parse JSON – Message Properties action just below the trigger or above the Send Message action.
  • Or modify the add expression to not reference the Parse JSON – Message Properties action.
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.

BizTalk Server SSO Application Configuration CLI Tool for BizTalk Server 2020

BizTalk Server leverages the Enterprise Single Sign-On (SSO) capabilities for securely storing critical information such as secure configuration properties (for example, the proxy user ID, and proxy password) for the BizTalk adapters. Therefore, the BizTalk Server requires SSO to work properly.

But it also can keep your own application configuration data in the SSO database, let say the usual configurations that we normally keep in a configuration file (“app.config”)). Unfortunately, there is no command-line tool to allow you to script the deployment SSO Application Configurations or perform CI/CD thru DevOps.

BizTalk Server SSO Application Configuration CLI

BizTalk Server SSO Application Configuration CLI is a command-line tool that provides the ability to import SSO configuration applications – key-value pairs in the SSO database – that can be deployed to different environments. This way enables you to script these tasks.

This tool is designed to address this gap allowing you to:

  • You can securely import Application configurations by using this CLI application;

And it mandatory accepts 5 arguments:

  • Path: full path to the .sso file
  • Password: password to unencrypted the .sso file
  • Contact Info: Internal field that is normally in the format of an email that is used internally in SSO tables for Application Configurations
  • Application User Account: SSO Affiliate Administrators Group or the Group that will access (read) key.values, for example: BizTalk Application Users.
  • Application Admin Account: SSO Administrator Group – Administrators of the Enterprise Single Sign-On (SSO) service.

Download

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

You can download BizTalk Server SSO Application Configuration Tool from GitHub here:

The post BizTalk Server SSO Application Configuration CLI Tool for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Deployment Framework (BTDF) Visual Studio plugin for BizTalk Server 2020

BizTalk Deployment Framework (BTDF) Visual Studio plugin for BizTalk Server 2020

Patrick Wellink, a long-time BizTalk Server consultant from the Netherlands, asked me to broadcast this news. I’m happy to do it because I know that many of you use and like BizTalk Deployment Framework (BTDF) to perform deployment across your environments.

Patrick suppresses a need by developing a Visual Studio 2019 plugin (VSIX) for BizTalk Server 2020. Of course, there was already a new version of The BTDF Framework. But one of the convenient things was the visual studio plugin… that was missing.

Unfortunately, and I understand this feeling entirely because I also have several community projects, we always have to for the owner and developer to upgrade his project, and we usually struggle to find the time. So I take this opportunity to encourage all community members to start contributing to these initiatives as Patrick did. Start performing changes and submit your contributions to the repo. I speak for myself, and from what I know from the community, we accept the changes and are happy that you contribute.

And it wasn’t that difficult, rephrasing Patrick:

With some guidance of this post and some fiddeling I got the VSIX to work for VS2019. After some more fiddeling I got the project wizard to run as well.

I did so with minimal effort.

Where I can download it

You can download the Visual Studio 2019 plugin (VSIX) for BizTalk Server 2020 here:

The post BizTalk Deployment Framework (BTDF) Visual Studio plugin for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.

Deploying local queues (MSMQ) with PowerShell

When migrating your BizTalk Server environment or deploy to a new or different environment, there are many different resources or configurations that you need to take into considerations like:

  • local queue creations
  • cloud queue creations
  • folder creations
  • and so on.

In this blog post, I will address how we can easily “export” a list of existing local private Message Queues (MSMQ) and recreate them, and set proper permissions in a different environment/server.

PowerShell script to extract a list of all private Message Queues (MSMQ) names

With this PowerShell sample, we will be able to extract a list of all private Message Queues (MSMQ) names to a CSV file to be used on a different script to deployed these resources on a different BizTalk Server environment.

set or update the URI (address) or part of the URI on a list of BizTalk Server Receive Locations deployed in your BizTalk Server environment.

Get-MsmqQueue -QueueType Private | 
Select-Object QueueName, Transactional, UseJournalQueue | 
Export-Csv -Path c:tempqueues.csv -Encoding ascii -NoTypeInformation

THIS POWERSHELL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

You can download this script here: Extract a list of all Private Message Queuing (MSMQ) names to a CSV file with PowerShell

PowerShell script to create private Message Queues (MSMQ)

With this PowerShell sample, we will be able to create local Private Message Queues (MSMQ) and set proper permissions on a different BizTalk Server environment.

New-MsmqQueue -Name $queueName -Label $queueName -QueueType $queueType -Transactional | 
                Set-MsmqQueueAcl -UserName "Everyone" -Allow FullControl

THIS POWERSHELL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

You can download this script here: Create local Private Message Queuing (MSMQ) and set proper permissions with PowerShell

The post Deploying local queues (MSMQ) with PowerShell appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Solution Deploy Error: Error saving map. Stored procedure returned non-zero result.

BizTalk Solution Deploy Error: Error saving map. Stored procedure returned non-zero result.

In my infamous crusade to document any BizTalk Server error that I have already come across, here is another error, warnings, cause, and solutions blog post, this time joining another of my favorite topic: Maps.

While trying to deploy a BizTalk Server solution – MSI – into production. While trying to import the BizTalk Application from the .msi file into the BizTalk group by using the BizTalk Server Administration Console by:

  1. Opening the BizTalk Server Administration Console for the instance of BizTalk Server into which you want to import the application. Click Start, click All Programs, click Microsoft BizTalk Server 20xx, and then click BizTalk Server Administration.
  2. In the console tree, expand BizTalk Server Administration, and then expand BizTalk Group.
  3. Right-click Applications, point to Import and then click MSI file.

I came across this error during the progress phase:

Failed to add resource(s). (mscorlib)
– Change requests failed for some resources. (Microsoft.BizTalk.ApplicationDeployment.Engine)
– BizTalkAssemblyResourceManager failed to complete end type change request. (Microsoft.BizTalk.ResourceManagers)
Failed to deploy map “FULLY-QUALIFIED-MAP-NAME”. Error saving map. Stored procedure returned non-zero result. Check if source and target schemas are present. (mscorlib)
Error saving map. Stored procedure returned non-zero result. Check if source and target schemas are present. (Microsoft.BizTalk.Deployment)

Error saving map. Stored procedure returned non-zero result

Cause

In previous versions of BizTalk Server, mainly 2010 and 2009, a bug was reported related to this issue. That problem occurred because BizTalk was trying to deploy the mapper assembly before the schema assembly. The solution for that case was installing the cumulative update 4 (or above) for BizTalk Server 2010 or the cumulative update 7 for BizTalk Server 2010.

Nevertheless, I was using BizTalk Server 2016, so that wasn’t the case. Luckily for us, the error provides a piece of clear evidence where the error is happening: FULLY-QUALIFIED-MAP-NAME.

To understand this issue, I went to my dev environment and opened that solution to analyze that specific map, mainly to know which schemas were being used. I then realize that one of the schemas was from an external assembly, a common schema that could be used by several applications.

The cause of this error was precisely that. I used a reference schema (external DLL) inside my map outside the project I was trying to deploy. But that assembly – DLL containing the map’s schema – was not yet deployed in the environment.

Solution

Make sure to deploy all the reference assemblies, special the ones outside your visual studio solution, are deployed before you deploy your solution. And in this case, make sure that all schemas are deployed before installing the maps.

But once again, the critical point here is to make sure to deploy all schemas outside your solution that are being used. Because, even if we use specific projects for maps and schemas inside our solution, BizTalk Server is smart enough to see the dependencies and deploy it accordingly.

After installing the external assembly that contains the schema used by that map, I was able to deploy the BizTalk project into production successfully.

The post BizTalk Solution Deploy Error: Error saving map. Stored procedure returned non-zero result. appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Visual Studio Deploy Issue: The “MapperCompiler” task failed unexpectedly. Access to the path ‘…’ is denied

BizTalk Visual Studio Deploy Issue: The “MapperCompiler” task failed unexpectedly. Access to the path ‘…’ is denied

Back to one of my favorite topics: Errors and Warnings, Causes, and Solutions since I have several issues to report in my internal OneNote. But in fact, this one happened today while I was implementing a new RosettaNet PIP on a client… nevertheless, this is not specific to RosettaNet.

I
was making a small improvement to an existing process/project to allow specific
orchestrations to be activated based on some properties promoted from the
message by applying a filter on the activate Receive Message shape. Everything
was going peacefully well until I tried to redeploy the Visual Studio solution.
Once I try to redeploy the BizTalk Server Visual Studio solution from Visual
Studio, I got the following error:

Error The “MapperCompiler” task failed unexpectedly.

System.UnauthorizedAccessException: Access to the path ‘C:……MapsmapNotifyOfShipmentReceipt_To_PIP4B2.btm.cs’ is denied.

   at Microsoft.VisualStudio.BizTalkProject.Compiler.MapCompiler.Compile(BizTalkBuildSnapshot buildSnapshot, IEnumerable`1 mapFilesToCompile, IEnumerable`1 schemaFiles, List`1& generatedCodeFiles, List`1& xsltFiles)

   at Microsoft.VisualStudio.BizTalkProject.BuildTasks.MapperCompiler.Execute()

   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()

   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() EAI.RosettaNet.4B2.

BizTalk Server: The MapperCompiler task failed unexpectedly

The funny part was that this was a small change that I did in an existing solution that already was running fine in the environment… and the change was a small improvement in the orchestration, not on the map!

Cause

Well,
I don’t know why the compiler decided to pick the mapper to complain. But This
issue is not related to any kind of maps you may have in your solution.

And
yes, the user that I was using to open, and build the solution had full rights
to access the file in question, all full rights to deploy stuff to the BizTalk
Server environment.

There are several possible causes for you to get such Access Denied errors when deploying BizTalk solutions directly from Visual Studio. Most common is that you don’t have the right BizTalk privileges to deploy artifacts, or in other words, you are not a local Administrator.

But most of the time is simpler than that and indeed is related to additional securities setting present in recent Windows Server versions. For you to be able to successfully deploy a BizTalk Server solution directly from Visual Studio, you must run Visual Studio as an Administrator, or with elevated permissions, because BizTalk assemblies need to be deployed into the GAC. What normally happens, is that if you have User Account Control (UAC) activated, or sometimes even deactivated, there are some additional securities setting present in recent Windows Server versions that, by default, doesn’t run Visual Studio with elevated permissions.

This
was indeed one of these cases, Visual Studio was not open with elevated
permissions.

Solution

The quick solution is for you to run
Visual Studio as an Administrator by simply run below step:

  • Right-click
    under Visual Studio and choose Run as administrator option.
Visual Studio: Run as Administrator

The problem with this approach is that
you need to remember yourself to do it every time you want to run Visual Studio.
Otherwise, the next time you try to deploy the solution, it will fail again
with the same error.

You may find more how to configure Visual Studio to run with elevated permissions as administrator by default here: https://blogs.biztalk360.com/biztalk-server-tips-and-tricks-configure-visual-studio-to-run-with-elevated-permissions-as-administrator/

If you try now to deploy your solution, you will see that this problem goes aways and you will be able to deploy it successfully (assuming that the solution does not actually have errors).

The post BizTalk Visual Studio Deploy Issue: The “MapperCompiler” task failed unexpectedly. Access to the path ‘…’ is denied appeared first on SANDRO PEREIRA BIZTALK BLOG.

Demystify Invalid type name error on BizTalk Schemas (Part II)

Demystify Invalid type name error on BizTalk Schemas (Part II)

In the last post, we try to demystify the reason and cause of the error: Invalid type name. The root node type has to be a valid C# identifier when you are working with a schema with a single root node.

In this second part of the post, we will address what happens If we are working with a schema with multiple root nodes, and two or more root nodes contains hyphens (-) or any other punctuation characters?

Let’s take the following example, where we have:

  • The root node “My-NAME-SANDRO” with the “RootNode TypeName” property set as “My-NAME-SANDRO”
  • And the root node “Let-SEE-What-happens” with the “RootNode TypeName” property set as “Let-SEE-What-happens”

BizTalk Schema: Invalid type name error

If we try to build our BizTalk Server solution within Visual Studio it will fail with the following errors:

Severity Code Description Project File Line Suppression State
Error Node “My-NAME-SANDRO” – Specify a valid .NET type name for this root node. The current .NET type name of this root node is invalid (it is a reserved BizTalk Keyword or is an invalid C# identifier). c:users…documentsvisual studio 2015ProjectsBizTalk Server Project1BizTalk Server Project1Schema2.xsd 1
Error Node “Let-SEE-What-happens” – Specify a valid .NET type name for this root node. The current .NET type name of this root node is invalid (it is a reserved BizTalk Keyword or is an invalid C# identifier). c:users…documentsvisual studio 2015ProjectsBizTalk Server Project1BizTalk Server Project1Schema2.xsd 1

BizTalk Schema: Invalid type name errors

Cause

Official Microsoft documentation state that The Type Name property of this schema file is not valid. Because the value of the Type Name property is used as the name of an automatically generated C# class name, it must be a valid C# identifier and cannot be a reserved BizTalk keyword.

And in this case – when working with multiple root nodes in a single schema – it is not allowed the use of hyphens or other punctuations like “.”, “!” and so on, with the exception for the underscore (_).

We saw in the previous post that we could work around this “limitation” in schemas with a single root node by open the Schema with XML (Text) Editor and fix the “rootTypeName” for the value you want. In this case, it will not work.

Solution

As hyphens, or any other punctuation characters, are not allowed, the only solution you have is to change it from the “RootNode TypeName” property. For example:

  • For the node “My-NANE-SANDRO” the “RootNode TypeName” value can be “MyNAMESANDRO” or “My_NAME_SANDRO” instead of “My-NAME-SANDRO”
  • And for the node “Let-SEE-What-happens” the “RootNode TypeName” value can be “LetSEEWhathappens” or “Let_SEE_What_happens” instead of “My-NAME-SANDRO

By removing all hyphens, or any other punctuation characters, from this property in all schemas you will guarantee that you will not face this issue again at least in this project.

Conclusion

As a best practice you should use hyphens, or any other punctuation characters in the “RootNode TypeName”, nevertheless:

  • The use of hyphens or any other punctuation characters is allowed in schemas with a single root node;
  • The use of hyphens or any other punctuation characters is not allowed in schemas with multiple single root node;

And by the way, can my root node name still contain hyphens or any other punctuation characters?

Yes, it can. In all scenarios as long the root “RootNode TypeName” property doesn’t contain any of them as you will see in the picture below:

BizTalk Schema: Invalid type name error resolved

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