Following my last blog post and while I was trying to fix some issues regarding a BizTalk Server 2020 installation and configuration provided by my intern as is learning process. We end up solving some critical problems that allow us to install the platform’s most important components. Nevertheless, several components like BAM Tools, BAM Portal and BizTalk EDI/AS2 Runtime failed to configure:
Once, we inspect the logfile provide the the BizTalk Server Configurarion Wizard we found the following error message:
[2020-11-10 22:17:18:0674 Error Configuration Framework]Feature: [BAM Tools] Failed to configure with error message [Feature is skipped due to failed validation. Please go to Custom Configuration to fix the validation error.
Validation Error: <Exception Message=”Error validating the SSIS Catalog database. Please ensure SQL Server Integration Services is installed on the local machine and SSIS Catalog is created on target SQL Server.” Source=”BAMTools” HelpID=”idsErrorValidateSSISCatalogDatabase”><Exception Message=”SSIS Catalog (SSISDB) does not exist on server BTS2020LABAVMRG. Please create SSIS Catalog.” Source=”Microsoft.BizTalk.Bam.CfgExtHelper.ToolsHelper” HelpID=”error_SSISCatalogNotExists”/></Exception>]
[2020-11-10 22:17:18:0674 Error Configuration Framework]Feature: [BAM Portal] Failed to configure with error message [The Configuration of Feature ‘BAM Portal’ failed because the dependent Feature ‘BAM Tools’ was not configured. ]
[2020-11-10 22:17:18:0674 Error Configuration Framework]Feature: [BizTalk EDI/AS2 Runtime] Failed to configure with error message [Feature is skipped due to dependent feature (BAM Tools) failed to configure correctly.]
Three distinct errors but the last two are a sequence of the first one, all of them are related to the same cause.
SSISDB was automatically created during the BizTalk Server configuration process on previous versions if we enable BAM Portal. However, BAM Portal was deprecated in this new BizTalk Server version, and the configuration process no longer created the SSIS Catalog. Instead, we need to create the catalog manually.
If you don’t create the SSIS Catalog manually, you will not be able to configure BAM Portal. Nevertheless, you can always perform this operation whenever you think is required, and after that, configure BAM Portal.
Make sure you also configure SQL Server Database Mail feature if you wish to configure BAM Alerts on your BizTalk Server 2020 environment
The solution is very simple, we need to manually create the catalog by using the following instructions:
Open SQL Server Management Studio and connect to the SQL Server Database Engine.
In Object Explorer, expand the server node, right-click the Integration Services Catalogs node, and then click Create Catalog.
On the Create Catalog window, do the following configuration and click OK.
Select Enable CLR Integration option.
Enter a password to protect the encryption key.
And run the BizTalk Server Configuration again. At the end you will be able to configure all BizTalk Server components.
As the learning process’s path, all my interns or new team members, regardless of what technologies they will be using more, one of the first things they will do is create a BizTalk Server development environment from scratch. Yes, all my team members will have skills in all Integration technologies, BizTalk Server, Logic Apps, Service Bus, APIM, and the list goes on and on.
I don´t mind or care if you get it right the first time or not. Sometimes it is with failures that we learn best and more. And I find it curious that with these exercises, they will find problems that I would never imagine happening, so sometimes it is a learning process and continuous improvement for both or the team.
This is one of these cases. My recent team member, while he was trying to configure BizTalk Server using the BizTalk Server Configuration wizard, was getting a failure in all the components immediately:
As he did not understand why this problem was happening, he asked me for help. Once we analyze the log file generated by the configuration wizard, we saw this error:
[2020-11-10 22:08:14:0631 Error Configuration Framework]Feature: [Enterprise SSO] Failed to configure with error message [<Exception Message=”Failed to create the SQL database ‘SSODB’ on SQL Server ‘BTS2020LABAVMRG’ (with SSO Administrator account ‘SSO Administrators’).” Source=”SSO” HelpID=””><Exception Message=”(0xC0002A21) An error occurred while attempting to access the SSO database.
” Source=”SSO” HelpID=””><Exception Message=”An error occurred while attempting to access the SSO database. See the event log (on computer ‘BTS2020LABAVMRG’) for more details.
” Source=”SSO” HelpID=””/></Exception></Exception>]
Basically, this error message does not show any clue or cause as to why this problem is happening. Nevertheless, it will point to you a source to see more details about this issue: the event viewer.
Once we chech the event viewer we got a very clear error message:
Cannot create file ‘C:Program FilesMicrosoft SQL ServerMSSQL15.MSSQLSERVERMSSQLDATASSODB.mdf’ because it already exists. Change the file path or the file name, and retry the operation.
The reason for this error to happen is clear. The BizTalk Server configuration wizard is trying to create the database files on the default SQL Server folders, but they already exist.
This error happened because my team member initially didn’t install all the required SQL Server components correctly. Once he was trying to add new features to an existing instance, he accidentally created another SQL Server instance.
After that, he uninstalled all the SQL Server instances and appropriately installed all the components, at least for now, let’s assume so. Nevertheless, while he was trying to do a Basic Configuration, he got that “strange” error.
Thru the SQL Server Management Console, we couldn’t see these databases, not only SSO as the error description, but also with all other BizTalk Server databases. But once we saw that folder, we realize that the uninstalls did not delete BD files created before from the hard drive.
The solution is very simple, delete all the Unnecessary files from that folder, like:
And run the BizTalk Servr Configuration again. At the end you will be able to configure BizTalk Server.
Hey… but there still errors over there. Indeed, there are, but I will leave that to another post that will be published very soon. However, this blog post’s original error was solved, and we were able to configure the required and critical BizTalk Server components: SSO, Group, and BizTalk Runtime.
Finally, the last chapter of this blog post series where we address:
What we need to install to begin developing our stateful and stateless workflows using Azure Logic Apps (Preview) – PART I;
The first approach to what you need to create a new Logic App (Preview) resource and new stateful or stateless workflows through VS Code – PART II;
Today, I will start to explain a different and more powerful way for you to create your Logic Apps (Preview) projects and workflows. Notice that, for this approach, you need to have all the prerequisites installed; otherwise, it will not work correctly or at least certain features like Logic App Designer, debug, or inline code.
If you are like me, a developer used to work with Visual Studio as his primary tool, then you need a little learning curve to start developer using VS Code. It is a different way to developer your solutions.
Create a local project
Before you can create your logic app, the first thing you need to do is to create a local project. This will allow you to manage and deploy your logic app from Visual Studio Code.
To do that, you need to:
In your development environment, create an empty local folder:
in my case, C:VSCODEMy-First-Logic-App-Preview
This folder will be used for our Logic App (Preview) project that you’ll later associate in the Visual Studio Code.
Note: Using the VS Code, there are multiple ways for you to:
Create the local project: you can do it at the Subscription level or the Logic App (Preview) resource level (n the Logic App (Preview) extension);
Create the Logic Apps (Preview) resource in Azure: Directly from the Subscription level on the Logic App (Preview) extension or during the local project deployment;
And even the deployment: once again in the Logic App (Preview) resource level (n the Logic App (Preview) extension) or at the Çocal project level;
I will approach and explain the way I prefer better and which I think is the most ideal.
I am assuming that you have already created the Logic App (Preview) resource in Azure. If not, check to Create a new Logic App (Preview) resource in PART II.
In the Azure pane, from the Logic Apps (Preview) extension, expand your Subscription, select the Logic App (Preview) resource, and click on Create New Project.
This will open the Browse Explorer, select the folder we have created.
Centered at the top of the VS Code editor window, a wizard will appear asking to select a template for your project’s first workflow, select either Stateful Workflow or Stateless Workflow. We will be using Stateful Workflow.
Provide a workflow name for the workflow you are creating or leave the default nameType Stateful-workflow-example and press Enter
Next, the wizard will ask you if we would like to open your project in a new window or the current one; select Open in current window.
Visual Studio Code reloads and will switch to the Explorer pane, showing you the workflow definition and your new Logic App (Preview) local project, which will include several automatically generated project files. For example:
The project will have a folder with the name that you specify for your workflow – Stateful-workflow-example. Inside this folder, the workflow.json file contains your logic app workflow’s underlying JSON definition.
Also host.json and local.settings.json files;
and so on.
Developing your Logic Apps in VS Code
Now that we have everything we need already created, we can start developing our logic apps locally on VS Code.
To do that, you need to:
Expand the project folder, in my case MY-FIRST-LOGIC-APP-PREVIEW, and then expand your workflow folder, Stateful-workflow-example. Righ-click workflow.json file and select Open in Designer.
From the Enable connectors in Azure list, select Use connectors from Azure, which applies to all managed connectors that are available and deployed in Azure, not just connectors for Azure services.
From the Select subscription list, select your subscription. This will be were the connectores will be created.
And finally, from the Select a resource group for new resources list, select the resource that you created for this project.
After that, the Logic App Designer appears, the Choose an operation prompt appears on the designer and is selected by default, which shows the Add a trigger pane.
Note: If you have .NET Core SDK 5.x, this version might prevent you from opening the logic app’s underlying workflow definition in the designer. Rather than uninstall this version, in your project’s root location, create a global.json file that references the .NET Core runtime 3.x version that you have that’s later than 3.1.201, for example:
Make sure that you explicitly add that global.json file to your project at the root location from inside Visual Studio Code. Otherwise, the designer won’t open.
To check the versions that are installed on your computer, run the following command:
And the rest is basically the same that we are already used to doing it in our “original” Logic Apps, or using the Azure Portal or inside Visual Studio. We need to add a trigger and actions.
On the designer, select the Choose an operation an in the Add a trigger pane, under the Choose an operation search box, make sure that Built-in is selected so that you can select a trigger that runs natively.
In the Choose an operation search box, enter when a http request, and select the built-in Request trigger that’s named When a HTTP request is received.
When the trigger appears on the designer, the trigger’s details pane opens to show the trigger’s properties, settings, and other actions.
This means that you can now define the JSON Schema, method, and all the other properties of this trigger.
Let’s leave the default for now.
Because this is a simple sample, let’s add an HTTP Response to our logic. On the designer, under the trigger that you added, select New step.
On the Add an action pane, under the Choose an operation search box, enter Response, and select the built-in Request action that’s named Response.
To have a more friendly response, set the body property of the Response action to be:
"Message": "Welcome to your first Stateful Workflow"
Finally, on the designer, select Save.
Now what we need before deploying this is to run and test this workflow locally.
Testing locally our Logic Apps
To do that, we need to:
On the Visual Studio Code toolbar, open the Run menu, and select Start Debugging (F5).
A Terminal window will open so that we can review the debugging session.
Because this workflow is trigger by an HTTP request, we need to find the callback URL for the endpoint on the Request trigger. Usually, we go to the When a HTTP request is received trigger, after we save our Logic App, and on the HTTP POST URL, we would find the callback URL. However, we will not find it locally. Instead, we will find a message saying, “Url not available during authoring in local project. Check the Overview page.”
As the message describes, for us to now the callback URL for the endpoint on the Request trigger we need to:
Reopen the Explorer pane so that you can view your project.
And from the workflow.json file’s inside the workflow folder – Stateful-workflow-example – right-click and select Overview.
There you will find the Workflow Properties like the Callback URL but also the local Run History of that workflow
Copy that URL to Postman or any other tool, and test sending a request to see if you get the desired outcome.
On the Overview page, you will get another entry on the Run History.
How can I add more workflows to my project?
Can I add more workflows to my local project? If so, how can I do it?
Yes, you can. And to do that, you need to:
Switch back to Azure pane and under Logic App (Preview), select your Logic App resource, and select Create Workflow.
A wizard will appear asking to select a template for your workflow, select either Stateful Workflow or Stateless Workflow. We will be using Stateful Workflow.
Provide a workflow name for the workflow you are creating or leave the default name, Type Another-Stateful-workflow-example, and press Enter.
Now, if we switch back again to the Explorer pane, we will notice that we have another workflow added to our local project.
Publish (deploy) to Azure Logic App (Preview) resource
Everything we created above is not created/publish on Azure, they were developed and created locally. Nevertheless, from Visual Studio Code, you can deploy your project and with it all your workflows directly to Azure. If the Logic App (Preview) resource type is not yet created, you can create in Azure during the deployment.
To do that, you need to:
On the Visual Studio Code toolbar, select the Azure icon.
On the Azure: Logic Apps (Preview) pane toolbar, select your Logic App (Preview) resource type, in our case, My-First-Logic-App-Preview, and then select Deploy to Logic App.
The deploy wizard will appear asking to Select subscription from the list.
And then to Select Logic App (Preview) in Azure. We will be selecting the one that we craete previously
If a message appear asking you if you want to continue with the deployment and overwrite any previou depoyment, select Deploy.
This will trigger the deployment process to Azure. Once the deployment is finished, you will be able to see your stateful workflows live in Azure and enabled by default.
Today we will see one of the ways to create a new Logic App (Preview) resource and new stateful or stateless workflows through VS Code. This doesn’t mean that it’s the best way, but later we will address this topic.
Create a new Logic App (Preview) resource
To do that, you need:
Open your VS Code, select the Azure icon.
In the Azure pane, under Azure: Logic Apps (Preview), select Sign in to Azure.
When the Visual Studio Code authentication page appears, sign in with your Azure account.
After you sign in, the Azure pane shows the subscriptions in your Azure account.
Any Logic Apps resources you may have already deployed/released it will not be showing here. You can see any original Logic Apps resources you created using the original extension in the released extension’s Logic Apps section.
In the Logic App (Preview) section, you will only see the new Logic Apps (Preview) resource type within functions runtime.
Note: You cannot create a Logic Apps (Preview) resource type directly from the Azure Portal. The only option at the moment is using Visual Studio Code (and probably scripting).
This is probably the best way, but if you don’t fill comfortable to work in VS Code, the first thing you can do is:
From the Logic Apps (Preview) extension, right-click on your Subscription and select one of the two options:
Create Logic App in Azure…
Create Logic App in Azure… (Advance) – we will be using this one.
Centered at the top of the VS Code editor window, a wizard will appear asking to specify a globally unique name for the logic app, which is the name to use for the Logic App (Preview) resource.
Type My-First-Logic-App-Preview and press Enter.
The second step will ask you to select a hosting plan for your new logic app, either App Service Plan or Premium.
Select App Service Plan.
The next step asks you if you want to create a new App Service plan or select an existing plan.
Select Create new App Service Plan.
Enter the name of the new App Service Plan you are creating or leave the default name
Type My-First-Logic-App-Preview-AS-Plan and press Enter.
And then select a pricing tier for the new App Service plan.
Select the S1 Standard plan (you can choose F1 Free plan).
The next step asks you if you want to create a new resource group for new resources or select an existing resource group.
In this case, select Create new resource group
Enter the name of the new resource group you are creating or leave the default name
Type My-First-Logic-App-Preview-RG and press Enter.
The next step asks you if you want to create a new storage account or select an existing storage account.
In this case, select Create new storage account
Enter the name of the new storage account you are creating or leave the default name
Type myfirstlogicapppreviewsa and press Enter.
The next step asks you if you want to create a new Application Insights resource or select an existing Application Insights resource.
In this case, select Create new Application Insights resource
Enter the name of the new Application Insights resource you are creating or leave the default name
Type My-First-Logic-App-Preview-AppIns and press Enter.
And finally, select a location for the new resources
In our case, West Europe
After that, you will see on the bottom right of VS Code Editor windows a status progress of the resources being created in Azure:
After it is finished, you will be able to see that resources in VS Code:
And the same thru the Azure Portal:
Create a new stateful or stateless workflows
Now that we have our Logic App (Preview) resource created, we can start creating our:
Stateful workflows: Stateful logic apps provide high resiliency if or when outages happen. After services and systems are restored, you can reconstruct the interrupted logic app runs from the saved state and rerun the logic apps to completion. Stateful workflows can continue running for up to a year.
Create stateful logic apps when you need to keep, review, or reference data from previous events. These logic apps keep the input and output for each action and their workflow states in external storage, which makes reviewing the run details and history possible after each run finishes.
or Stateless workflows: Create stateless logic apps when you don’t need to save, review, or reference data from previous events in external storage for later review. These logic apps keep the input and output for each action and their workflow states only in memory, rather than transfer this information to external storage. As a result, stateless logic apps have shorter runs that are usually no longer than 5 minutes, faster performance with quicker response times, higher throughput, and reduced running costs because the run details and history aren’t kept in external storage. However, if or when outages happen, interrupted runs aren’t automatically restored, so the caller needs to manually resubmit interrupted runs. These logic apps can only run synchronously and for easier debugging, you can enable run history, which has some impact on performance.
To do that we can:
Select the Logic App (Preview) resource we created previously, My-First-Logic-App-Preview, and then click on the Create Workflow… button.
Centered at the top of the VS Code editor window, a wizard will once again appear asking to select a template for your workflow, select either Stateful Workflow or Stateless Workflow.
We will be using Stateful Workflow
Provide a workflow name for the workflow you are creating or leave the default name
Type My-First-Stateful-Workflow and press Enter
This will create locally a workflow.json file that contains your logic app workflow’s underlying JSON definition.
Note: the Stateful Workflow is not yet created in Azure.
Since full Logic Apps designer is supported in VS Code in this kind of resource, you may be thinking that now you can switch to Logic Apps designer… Unfortunately, using this creation strategy, you can’t! It will be exactly like the original Logic App extension. Only the code view is supported, and the Designer is read-only.
Does that mean that Logic Apps designer is not supported in VS Code? No, it is, but you need to use a different approach that we will address later in Part III.
You can modify the workflow logic as you want, for example, the bellow code:
Now, to actually create this resource in Azure (in the Logic App (Preview) resource group) you need to:
Select the Logic App (Preview) resource we created previously, My-First-Logic-App-Preview, and then click on the Deploy to Logic App… button.
If it asks if you are sure and if you want to overlap existing resources, select Yes.
The deployment will make take some minutes to finish. After that, you will be able to see it on the Workflow list inside the Logic App (Preview) resource in VS Code:
Once again, the Designer is read-only.
But you can also find the stateful workflow in the Azure Portal, and from there, you will be able to use the new Logic App Designer.
Of course, all the changes you make in the Portal can be synchronized back to VS Code by selecting the Refresh button
In the next blog post, we will explain a different and more powerful way for you to create your Logic Apps (Preview) projects and workflows. Stay tuned!
Recently a friend of mine, Howard S. Edidin, a truly T-Rex, passed away. He was a former BizTalk Server MVP and he dedicated most of his professional life to BizTalk Server and HL7, work that you can find perpetuated in this book: HL7 for BizTalk. I personally couldn’t find a better way to honor him than this way: How to install BizTalk Accelerator for HL7 in a standalone machine.
Install BizTalk Accelerator for HL7
Starting with BizTalk Server 2013 R2 and newer versions, the BTAHL7 installation includes a 32-bit installation package (BizTalk AcceleratorsA4HL7 on the BizTalk Server ISO) and a 64-bit installation package (BizTalk AcceleratorsA4HL7(64) on the BizTalk Server ISO).
On a 32-bit computer, install only the 32-bit package. On a 64-bit computer, install the 32-bit or 64-bit package. The 64-bit package enables the adapter and pipelines to run in both 32-bit and 64-bit mode.
Note: The user installing and configuring BTAHL7 must be a member of the BizTalk Administrators group, and a member of the Administrators group on the SQL Server where the BTAHL7 data is stored.
Note: BizTalk Server should have the basic components installed and configured, including a 32-bit BizTalkServerApplication host with standard out of the box adapters, Enterprise Single Sign-on (SSO), the Group, and Runtime.
To install BizTalk Accelerator for HL7 we need to:
Run the BizTalk Accelerator for HL7 (A4HL7) setup.exe as Administrator.
On the Welcome to the Wizard for Microsoft BizTalk Accelerator for HL7 page, select Next.
On the License Agreement page, accept the terms, and then select Next.
On the Customer Information page, enter your user name and organization, and then select Next.
On the Setup Type page, select the Typical setup, and then select Next.
On the Logging Service Account page, leave the default group names and select Next.
The Logging Service Account page automatically gives the following groups the logging permissions:
BizTalk Server Administrators
BizTalk Application Users
BizTalk Server B2B Operators
BizTalk Server Operators
On the Summary of features being installed page, review the summary, and select Next.
On the Destination Folder page, select Next to use the default folder. Or, select Change to choose a different installation folder.
On the Logging Database Information page, leave the default configuration, and then select Next.
Database Server Name: The default value is the server name (name of the computer that the BizTalkMgmtDb database resides – you cannot change this value.).
HL7 Database name: Enter the name of the database that contains the data for your BTAHL7 solution, or accept the default setting, which is BTAHL7
You must use the ANSI-ASCII character set per database requirements; BTAHL7 does not support other character sets.
On the Ready to Install the Program page, select Install.
On the InstallShield Wizard Completed page, select Finish to complete.
And finally, you need to install through the Microsoft Installer (MSI) the Azure Functions Core Tools, either version 3.0.2931 or 2.7.2936. These tools include a version of the same runtime that powers the Azure Functions runtime that runs in Visual Studio Code.
In the next blog post, we will explain how you can create your first Logic Apps (Preview) project. Stay tuned!
Azure Logic Apps Tools is available for Visual Studio 2019, 2017, and 2015 Community edition or greater and will allow you to design and deploy your logic apps from within Visual Studio. The Logic App designer integrates with the current Azure Resource Group project so you can seamlessly work with resource deployments that include Logic Apps.
Although this tool is officially supporting three versions of Visual Studio, I will advise you to install it only on Visual Studio 2019 and not in older versions. At some point, they will be officially removed or discontinued.
Visual Studio 2019, 2017, or 2015 – Community edition or greater;
Visual Studio Tools for Azure: Azure SDK, tools, and projects for developing cloud apps and creating resources using .NET Core and .NET. Important also to create hybrid solutions without having the need for another development environment.
In the Visual Studio installer, install Visual Studio (or modify an existing installation). Make sure the Azure development and ASP.NET and web development workloads are selected.
Install Azure Logic Apps Tools for Visual Studio 2019
AftAfter you install the prerequisites, this is a straightforward process. To accomplish that, we need to:
Open your Visual Studio, on the entry screen select the option Continue without code->
Then on the menu, navigate to Extensions > Manage Extensions
Select Online and search for Logic Apps
The add-in will be listed in the search results section. Click Download to download and install the add-in. You need to close your Visual Studio in order to begin installing this extension.
On the VSIX Installer screen
Make sure that the correct version of Visual Studio is selected.
Click Install or Modify. This will download and install the add-in to your version of Visual Studio.
At the end select Close.
Creating a Visual Studio Logic App project
The Logic Apps designer integrates with the current Azure Resource Group project. That saying, you will not find any Logic App template from the list of templates. Instead, we need to create an Azure Resource Group project to get started and to do that, we need:
Open Visual Studio and on the Create a new project panel, select C# -> Azure -> Cloud, or select for Azure Resource Group;
Select Azure Resource Group from the template list;
On the Configure your new project panel, give a proper Project name, Location, Solution name, and leave the Framework as .Net Framework 4.7.2 and select Create.
Finally, on the Select Azure Template panel, from the Visual Studio Templates list, select the Logic App template and select OK.
This will create an empty Visual Studio Logic App solution. Now on the Visual Studio solution:
Right-click on the LogicApp.json file and select Open With Logic App Designer
This will open a Logic App Properties window, where you need to:
Define the credentials to authenticate on the Azure subscription;
Define the Subscription and Resource Group where you want to create these resources;
Define if you want the Location to be in the same Region or in an Integration Service Environment (ISE);
And then select OK.
This will embed the Logic App designer inside the Visual Studio.
Now you need to select a common trigger, a template, or use a blank Logic App to start creating your business process.
SharePoint Saturday Lisbon has been rebranded, and it is now Collabdays Lisbon. Don’t worry, it is still organized by the same people and maintains the same spirit as in previous years.
Collabdays Lisbon is a community-driven event dedicated to all that is great about SharePoint and now also: Office 365 and Azure. At the moment, due to the COVID-19 pandemic, this will be a one-day free virtual event and I will be there presenting a session about Power Automation: Best practices, tips, and tricks
Power Automation: Best practices, tips, and tricks
As I mentioned before, my session will be all about best practices and small tips and tricks that we can apply to our Power Automate flows. For those reasons, I would like you to invite you to join me at the Collabdays Lisbon virtual event next Saturday, October 10, 2020.
Abstract: Power Automation: Best practices, tips and tricks
In this session, we will do a reflection to your existing Power Automation flow’s and when thru a list of must-have best practices, tips, and tricks that will allow you to build more reliable and effective flows. At the same time, these will allow you to be more productive and document your flow’s from the beginning.
Join us and reserve your presence at the Collabdays Lisbon virtual event, it is free!
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:
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.
In the console tree, expand BizTalk Server Administration, and then expand BizTalk Group.
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)
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.
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.