Today while developing an existing Logic App Consumption in Visual Studio 2019, yes, we still don’t have support for Visual Studio 2022, I realized that for some unknown reason, one of the actions, in my case a For each action, didn’t have the normal arrow – that indicates the precedence of the previous step in the Logic App designer as you can see in the picture above – for some unknown reason it evaporated:
I tried to re-order (or move) the For each action in the designer to see if I could fix this issue, without success. A good option that you should always try is to close that file and open it again to force a refresh on the designer – that solves many issues – but it didn’t do the trick on this issue.
I couldn’t by Designer solve this issue because the property Configure run after settings were disabled:
I honestly don’t know what would happen if I tried to deploy this Logic App in this situation, but it shouldn’t be good. And this situation was causing me inconvenience when moving and reordering the actions. So I have no other option than try to fix it.
Cause
When inspecting the Code view, I realized that, again, for some unknown reason, the runAfter property was empty. The Logic App designer normally fills this value to run if the previous action Succeeded.
Solution
To fix this issue or behavior, we need to manually configure the runAfter property like:
Where the Name_Previous_Action is the name of the previous action on the workflow, the spaces in the action name are replaced by underscores.
After that, if you return to the designer, you will see everything back to normality:
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
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
One error never comes alone! Following the error reported in my last blog post while working last week with one of my clients, I was able to catch an error that I never saw during these long years working with BizTalk Server while trying to build a BizTalk Server Visual Studio solution in this specific case a custom pipeline component:
Couldn’t process file XMLAttributesStripper.resx due to its being in the Internet or Restricted zone or having the mark of the web on the file. Remove the mark of the web if you want to process these files.??????????????????
Indeed I download that resource from the Internet, from my GitHub page, like I do thousands of times for many clients and projects!
Cause
This issue happens due to the fact that you downloaded from the web these files/resources from a machine with security restrictions configured. So, when Visual Studio attempts to build the project, this error occurs because The .NET Framework resource compiler honors this marker and refuses to compile those resource files for security reasons.
The underlying cause is that the respective resource file has the so-called mark of the web applied to it. This is a marker that browsers place on downloaded files so that other applications can make informed decisions on whether to trust that file or not.
Solution
To fix this issue, the solution is quite simple. Nevertheless, there are many ways to solve or avoid this issue.
Solution 1: Fix the issue
To solve this issue, we need to remove the mark of the web, to do that, we need to:
Right-click on the file in windows explorer and select Properties.
On the General tab, at the bottom under Security, there is a check box to remove mark of the web.
Unselect the Unblock check box and click OK.
Note: This needs to be done with Visual Studio closed.
Solution 2: Fix the issue with PowerShell script
We can also do the same functionality as Solution 1 using the following PowerShell script:
On the folder for the project, run the following script
dir -Path . -Recurse | Unblock-File
or
Get-ChildItem -Path . -Recurse | Unblock-File
Solution 3: Fix the issue from Visual Studio
Didn’t try this approach, but apparently, we can also fix this issue directly from Visual Studio by:
Select the menu option Tools > Options
From the Options windows, select the option Trust Settings under Environment and add the project path as a trusted path.
Last week I was adding new processes to an existing and old project for a client, a project that I started a few years ago, and I was caught by surprise with the following error while trying to generate a new SAP schema from Visual Studio:
Error occurred while browsing the LOB system. Adapter Message: Could not load file or assembly ‘Microsoft.Adapters.SAP.SAPGInvoker.dll’ or one of its dependencies. The specified module could not be found.
At first sight, the cause for the error is simple, and I will explain above the main causes, but in my case, the problem was that I had all the pre-requirements for the WCF-SAP adapter to work, and again that was an existing project where I had already generated several SAP Schemas.
Cause
Normally the main reason for this error is that the pre-requirements to run the WCF-SAP adapter are not installed in the environment. Even if you see the WCF-SAP adapter present and configured in the BizTalk Server Administration console, it doesn’t mean that it is ready to work. This adapter requires you to install the following SAP resources to run the adapter in the BizTalk Server box:
NCo3018_Net40_x64.msi
NCo3018_Net40_x86.msi
You can download these resources from the SAP Service Marketplace.
It is required (mandatory) to install the x86 version of the SAP Connector for Microsoft .NET. However, if you want to run the adapter under a 64-bit Host Instance, you need to install both the x86 and x64 versions of the SAP Connector for Microsoft .NET (recommended).
But once again, I knew that I had all these resources installed, and I doubled check that they were installed.
In my case, for some unknown reason, some of these DLLs got corrupted, and for that reason, I was getting this error.
Solution
To fix this issue, the solution is quite simple:
Reinstall the x86 and x64 versions of the SAP Connector for Microsoft .NET.
NCo3018_Net40_x64.msi
NCo3018_Net40_x86.msi
When asked, repair the installation of the components.
After that, I was once again able to generate SAP Schemas from my BizTalk Server Visual Studio project.
Completing the enormous saga, aka nightmare, to install BAM in one of my latest BizTalk Server installations and once I thought I solve all the issues… BAM strikes again! Now complaining about the following error:
Exception Message=”Microsoft (R) Business Activity Monitoring Utility Version 3.13.717.0 Copyright (C) Microsoft Corporation. All rights reserved.
ERROR: Failed to set up BAM database(s). Database ‘BAMAnalysis’ has compatibility level larger than 1103 with StorageEngineUsed set to InMemory. Tabular databases with compatibility level at 1200 or above must use StorageEngineUsed set to TabularMetadata.
My team didn’t follow the SQL Server installation, we just send to another team the requirements necessary for BizTalk Server and the installation guide, so we were a little surprised by this error.
And despite I never had seen this error before, the reason was quite simple: This error is caused by the SQL Server Analysis Services (SSAS) instance being installed using the tabular mode, and BizTalk Server needs a multi-dimensional mode SSAS instance.
Solution
You have at least two solutions on the table to solve this issue.
Solution 1: Uninstall and re-install SQL Server Analysis Services (SSAS)
The trick here is to be able to know how to uninstall SSAS and to do that you need to:
Open Command Prompt as Administrator model on the SQL Server and execute the following command
Action performed. In here we are going to uninstall
Feature we are going to remove. AS indicates Analysis Services instance
The name of our AS instance
After that, you just need to add new features to the existing installation, in this case, a multi-dimensional mode SSAS instance.
Solution 2: Modify the msmdsrv.ini file
An alternative way is to modify the msmdsrv.ini file. Administrators can modify default server configuration properties of an SQL Server Analysis Services (SSAS) instance by using SQL Server Management Studio. However, properties pages in SQL Server Management Studio show a subset of the properties most likely to be modified. For SSAS, all properties are in the msmdsrv.ini file.
The default installation, msmdsrv.ini can be found in the C:Program FilesMicrosoft SQL ServerMSAS15.MSSQLSERVEROLAPConfig folder
Of course, this depend on the version you are using.
On the msmdsrv.ini file:
Configure the DeploymentMode property to be 0 (zero) and save the file
After that, restart the SSAS instance and these will change from a tabular instance to a multi-dimensional instance
Nevertheless, while trying to configure BAM features, I was getting the following error message:
Could not load file or assembly ‘Microsoft.SqlServer.SQLTask, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.
Once I solve that one, I endup getting another one:
Could not load file or assembly ‘Microsoft.SqlServer.Management.IntegrationServices, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.
And another one:
Could not load file or assembly ‘Microsoft.AnalysisServices, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.
And another one:
Could not load file or assembly ‘Microsoft.AnalysisServices.Core, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.
And another one:
Could not load file or assembly ‘Microsoft.AnalysisServices.AdomdClient, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.
This was a kind of a nightmare of errors after errors!
Cause
This is something that always annoyed me since Microsoft decided to separate the SSMS from the default installation. So, on one hand, it is great that clients can update to a recent version of the tool. Still, on the other hand, it complicates specific previous simple tasks like performing the configuration of BizTalk Server features in special BAM features.
By design, the latest SSMS only includes the latest version of SSIS assemblies.
I have been using this SSMS 18.4 version in almost all my BizTalk Server installations. But also, in most of my recent installations, my clients didn’t want me to install BAM because they were not using this feature. The reason I use SSMS 18.4 version is because it was the latest version available before BizTalk Server 2020 was released.
I have tried to uninstall this SSMS version and install a previous one – 17.9.1 – to solve this issue, but by doing that, I got a ton of other problems with the based features of BizTalk Server like SSO and Runtime. So I decide to keep using SSMS 18.4.
Trying to find the correct version of the SSMS may be an inglorious Task.
I saw comments and suggestions to solve this issue that I would do in a BizTalk Server environment like:
Installing SSIS on the BizTalk Server machine and re-run BizTalk configuration
Installing SSDT (SQL Server Data Tools) full ISO on the BizTalk Server machine and re-run BizTalk configuration
or by installing the Client Tools SDK from SQL Server installation media on BizTalk machine and re-run BizTalk configuration – this was, in fact, a possible alternative
But again, this issue is related without a doubt with problems related to assemblies reference mismatch.
Solution
You have several solutions on the table to solve this issue. I endup deciding that the simple and fast way was to do Assembly redirect at the machine level.
To solve this problem by using Assembly Binding Redirection in the machine configuration file (Machine.config) you should change both:
This time, while trying to configure a simple feature that usually doesn’t require too much effort, just selecting the checkbox, I got a different error message:
[2021-10-18 23:53:24:0397 Error EDIAS2Config] Failed to deploy BAM activity definitions. Please make sure that all BAM related Data Transformation Services (DTS) packages are removed along with the BAM databases. (Microsoft.BizTalk.Configuration.EDIAS2.Utility) Failed to execute process: C:Program Files (x86)Microsoft BizTalk ServerTrackingbm.exe. (Microsoft.BizTalk.Configuration.EDIAS2.Utility) Microsoft (R) Business Activity Monitoring Utility Version 3.13.717.0
Copyright (C) Microsoft Corporation. All rights reserved.
Using ‘BAMPrimaryImport’ BAM Primary Import database on server ‘SERVER-NAME’…
Deploying Activity… Done.
ERROR: The BAM deployment failed.
The alerts were not deployed.
Cannot start service BAMAlerts on computer ‘.’.
The service did not start due to a logon failure
(Microsoft.BizTalk.Configuration.EDIAS2.Utility)
Once again, for you to have a better perspective, we didn’t perform a full configuration in one shot because of issues happening during the configuration process. In this case, we took the approach of configuring feature by feature step-by-step. And this wasn’t the first time we were trying to configure this feature.
Cause
This isn’t the same issue that I reported in the previous post, but they are related since the origin of the problem was the same. There was a domain policy that disabled the user’s right to log on as a service, causing the services to stay stopped if, for some reason, you restart the services.
And that was one of the main reasons for this installation to become a nightmare. In this particular case, the BAMAlerts service was stopped, which was causing this error.
Also, because this wasn’t the first try to install this feature, you need to ensure that you have removed BAM artifacts that were probably created successfully. Avoid other types of errors once you give it another try to configure that feature.
Solution
You have several actions to perform to solve once and for all this issue:
Ensure you have removed all the EDI/AS2 BAM resources by accessing the tracking folder using the command line console in administration mode:
Usually, the path is: C:Program Files (x86)Microsoft BizTalk ServerTracking
After that, make sure that all BizTalk Server services, including Enterprise Single Sign-On and BAMAlerts is running
And then give another try configuring this feature.
Now, that will solve the issue momentarily. Nevertheless, to put in a correct configuration, you need to ask the security team to Restore user’s right to log on as a service for the BizTalk Services on the BizTalk Server machine.
In a normal situation, you could fix that by:
Sign in with administrator privileges to the computer from which you want to provide Log on as Service permission to accounts.
Go to Administrative Tools, click Local Security Policy.
Expand Local Policy, click User Rights Assignment. In the right pane, right-click Log on as a service and select Properties.
Click Add User or Group option to add the new user.
In the Select Users or Groups dialogue, find the user you wish to add and click OK.
Click OK in the Log on as a service Properties to save the changes.
If the right to log on as a service is revoked for the user account, restore it on a domain controller or a member server (standalone) depending on your situation.
This could be a valid error message if it weren’t for the simple little detail that we are dealing with a High-availability multi-server BizTalk Server installation. That means that the SQL Server was installed in another machine(s)… and yes, Microsoft SQL Server Integration Services was installed on the SQL Server as Analysis Service and all the pre-requirements of BizTalk Server 2020.
And again, yes. SQL Server Management Studio (SSMS) 18.4 was installed on the BizTalk Server box. So why the hell that when I was trying to configure BAM features, I was getting the following error message:
BizTalk Server 2020 BAM Configuration: Microsoft SQL Server Integration Services (SSIS) is not installed on the local machine. The version of SSIS must be the equivalent version as on the SQL server of the BAM Archive Database. (15)
Could not load file or assembly ‘Microsoft.SqlServer.ManagedDTS, Version=13.0.0.0′,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.
Cause
This is something that always annoyed me since Microsoft decided to separate the SSMS from the default installation. So, on one hand, it is great that clients can update to a recent version of the tool. Still, on the other hand, it complicates specific previous simple tasks like performing the configuration of BizTalk Server features in special BAM features.
By design, the latest SSMS only includes the latest version of SSIS assemblies.
I have been using this SSMS 18.4 version in almost all my BizTalk Server installations. But also, in most of my recent installations, my clients didn’t want me to install BAM because they were not using this feature. The reason I use SSMS 18.4 version is because it was the latest version available before BizTalk Server 2020 was released.
I have tried to uninstall this SSMS version and install a previous one – 17.9.1 – to solve this issue, but by doing that, I got a ton of other problems with the based features of BizTalk Server like SSO and Runtime. So I decide to keep using SSMS 18.4.
Trying to find the correct version of the SSMS may be an inglorious Task.
I saw comments and suggestions to solve this issue that I would do in a BizTalk Server environment like:
Installing SSIS on the BizTalk Server machine and re-run BizTalk configuration
Installing SSDT (SQL Server Data Tools) full ISO on the BizTalk Server machine and re-run BizTalk configuration
or by installing the Client Tools SDK from SQL Server installation media on BizTalk machine and re-run BizTalk configuration – this was, in fact, a possible alternative
But again, this issue is related without a doubt with problems related to assemblies reference mismatch.
Solution
You have several solutions on the table to solve this issue.
Solution 1: Install side-by-side SSMS 17.9.1
Note: do not uninstall SSMS version 18.4. Leave both side-by-side.
I know this is a little ridiculous, but it solves the problem.
Solution 2: Assembly redirect at the machine level (machine.config)
To solve this problem by using Assembly Binding Redirection in the machine configuration file (Machine.config) you should change both:
I have to say that I saw bizarre error messages during these long years as a consultant, but this one gained direct entry into my TOP 10 for a straightforward fact: there isn’t a SQL Adapter on BizTalk Server 2020. The adapter was deprecated since BizTalk Server 2006 R2, and they decided to remove it in this last version of the product. So, when I saw this error message appearing on the BizTalk Server Configuration Console:
Host (BizTalkServerApplication) is an invalid Receive Handler for SQL Adapter. Please go to BizTalk Administration Console to add BizTalkServerApplication as a new Receive Handler (Microsoft.BizTalk.Configuration.EDIAS2Config)
Humm… what? Humm…
I have done hundreds of installations during more than 15 years working in BizTalk Server, and many of these installations were BizTalk Server 2020, but I never faced this issue before.
On a small note, because of issues happening during the configuration process, I didn’t perform a full configuration in one shot. In this case, we took the approach of configuring feature by feature, step-by-step.
Cause
BizTalk Server 2020 Cumulative Update 2 and then try again to configure this feature. But I soon realized that this wasn’t the issue, neither the solution since the problem continues to happen. But, again, I have done several BizTalk Server 2020 installations since this last version was released and never got this error. And some of them were almost immediately when 2020 was announced and available.
I was almost ready to install the old and deprecated SQL Adapter in BizTalk Server 2020 to see if that solved the issue when I decided to have a look at the services and see if all the services were running. Shocking surprise Enterprise Single Sign-On Service wasn’t running… So again, this time I decided to start the SSO service and then try again to configure this feature… and everything worked. I was able to configure this feature in BizTalk Server 2020.
Yes, for sure you need the Enterprise Single Sign-On (ENTSSO) Service running to perform the BizTalk Server configuration. This is the first step of the BizTalk Server configuration, and without it, you cannot configure the rest of the features. However, clearly this problem, or in this case, the error message description presented to the user making the configuration, is what I call a problem between the chair and the keyboard. Someone forgot to fix these validations or update the validations made by the BizTalk Server Configuration Console.
Solution
The solution is simple:
Ensure that Enterprise Single Sign-On (ENTSSO) Service is running before you perform any configuration in BizTalk Server because all the features will rely on it.
I have been working on a new BizTalk Server project on a new client for a few weeks. Now that we are beginning the development phase, I was getting annoying with an Internet Explorer security blocking windows every time I try to open a schema document on Visual Studio with the BizTalk Server Schema Editor:
Internet Explorer
Content within this application coming from the website listed below is being blocked by Internet Explorer Enhanced Security Configuration:
about:security_devenv.exe
To be honest, I initially ignored this issue and immediately clicked on the Close button, and everything would work as usual. But starting to work every day on the project and facing this issue every time I tried to open a Schema was simple to annoying.
Cause
We don’t need the IE to develop BizTalk Schemas, but the XSD viewer, in fact, opens an IE embedded inside Visual Studio. And that is the reason for this issue.
I typically don’t get this “warning” message because I usually turn off Internet Explorer Enhanced Security Configuration on my BizTalk Servers.
Solution
The solution is simple:
You can turn off Internet Explorer Enhanced Security Configuration by:
Start by running the Server Manager, if it is not already open, from either:
On the Windows taskbar, click the Server Manager button
On the Start screen, click Server Manager
In the Server Manager Dashboard, from the scope pane (on the left side) click on Local Server
In the Server Properties for the Local Server, you’ll see the option for IE Enhanced Security Configuration. Click On to change the option
A dialog box appears, letting Internet Explorer Enhanced Security Configuration be enabled/disabled separately for normal users and administrators; turn off both. After disabling both options, click OK
Click the Refresh button at the top of the Server Manager and the IE Enhanced Security Configuration should now show as Off
Or, if don’t want to turn off Internet Explorer Enhanced Security Configuration , you can on the blocking pop-up window click on Add
On the Trusted sites window, make sure Require server verification (https:) for all sites in this zone is not marked and then click Add
After one of these two options/settings that annoying blocking behavior inside Visual Studio will be gone.
![Azure Logic App issues: The template language expression ‘triggerBody()?[‘…’]’ cannot be evaluated.](https://www.biztalkgurus.com/wp-content/uploads/2023/01/01-Azure-Logic-Apps-HTTP-Trigger-Evaluate-Properties-150x150.png)
