I have been testing Data Mapper for almost maybe 4 months since the first private previews. Still, I have usually tried the Data Mapper capabilities and not the interaction between Logic Apps Standard workflow and the Data Mapper. Now that I’m preparing and finalizing my session for the Azure Logic Apps Community Day 2023, I’m finding these little headaches in trying to put these pieces working together. You also need to be aware that this behavior and experience may change in the future since DaTa Mapper is still in preview.
So, while I was trying to call a transformation created by the new Data Mapper, in this case, a JSON to JSON transformation, running locally in my machine, I was always getting this really annoying and non-sense error since it doesn’t provide any real and valuable help or insight on the issue we are facing:
undefined. undefined
Sometimes I think the Microsoft developer team likes that I write all these Errors and Warnings, Causes and Solutions blog posts, or they are just teasing us.
I was surprised to see this error since I just finished developing my map, and I had successfully tested it on the Data Mapper editor.
And that you can see in action in this video of Kent Weare:
Solution
For the map to run successfully in runtime, within your local.settings.json file in your logic apps standard project, ensure you have the following property configuration:
FUNCTIONS_WORKER_RUNTIME property set to dotnet-isolated.
And add the AzureWebJobsFeatureFlags property with the value: EnableMultiLanguageWorker
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
One of the first steps, while you are trying to configure BizTalk Server, is to provide the “Database server name” on the BizTalk Server <version> Configuration page. So far nothing new. However, in one of my recent BizTalk Server installations where we were using a SQL Server that was configured with a non-default port (1433), we encountered this bizarre problem:
BTS2016LAB01, 3431 is invalid because it contains one or more of the following characters: `~!@#$^*()+=[]{}|;’”<>?.
Cause
Well, the reason is obvious for all but in this case, a little stupid considering the current days. Of course, we all can understand that the special characters are not allowed and we cannot use it.
But was not our case, we are not using any special characters in the Database server name and if you check carefully, we catch the error while configuring the Group, which means that we already were able to create the SSO database in the SQL Server – so the database name was valid/correct.
And if there were really special characters in the Database server name, then the configuration wizard should be smart to validate on the BizTalk Server <version> Configuration page and do not to continue with the configuration.
I personally consider this as a bug in the BizTalk Server Configuration Wizard tool because in our case the real problem and the cause of this error was that we had provided the database name with a space between the server and the port: “BTS2016LAB01, 3431”
Solution
The solution to this problem is simple, first of all, and obviously, you cannot use any of the following special characters: `~!@#$^*()+=[]{}|;’”<>?. under the Database Server Name.
In our case, the solution was simple also, we just need to remove the empty space on the Database Server Name: “BTS2016LAB01,3431”
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
It is not the first time, neither will be the last that I encountered similar problems like this one or the same problem with earlier versions, we call it DLL hell (or nightmare) but I think that all BizTalk Administrator are familiar with it and vaccinated for the problem. Some months ago, while trying to communicate with an Oracle database within Visual Studio in a brand-new BizTalk Server 2016 Developer environment to generate the proper Schemas, we faced with the following Oracle.DataAccess problem:
Error saving properties. (System.ArgumentException) Invalid binding. (System.IO.FileNotFoundException) Could not load file or assembly ‘Oracle.DataAccess, Version=4.121.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342’ or one of its dependencies. The system cannot find the file specified.
Cause
When installing the Oracle WCF Adapter for BizTalk Server 2016 there is a design-time requirement to use Oracle.DataAccess Version 4.121.1.0.
BizTalk Server 2016 requires that specific Oracle.DataAccess version, however, us we were able to very on the GAC, the DLL that existed in our environment had a different version.
Trying to find the correct ODP.NET 11.2.0.1.2 version under Oracle website can be a challenge
Note: depending on the BizTalk Server version that you are using, this the required Oracle.DataAccess version may change.
Solution
Trying to find the correct ODP.NET 11.2.0.1.2 version under Oracle website can be a challenge, so one of the easier and fast ways to solve this problem is using Assembly Binding Redirection in the machine configuration file (Machine.config):
Note: You should apply this in both 32 and 64-bit machine configuration files.
By using the <assemblyBinding> Element for <runtime> that will contain all the information about assembly version redirection and the locations of assemblies.
In this case, you should apply the following configurations:
By doing this when BizTalk Server will look to the Oracle.DataAccess version which not exists in your environment, it will be redirected to the existing DLL version.
Just to be on the safe side, you should add this configuration in both 32 and 64-bit in .NET Framework 2.0 and 4.0 machine configuration files.
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