Recently I developed a custom file adapter called FILE-Z adapter that I blogged on the BizTalk360 blog. This is an adapter created from the original idea of my dear friend Nino Crudele. It is a custom File adapter capable of reading empty files.
You can see his original blog post here: BizTalk and zero byte file. And you can download the FILE-Z adapter here: FILE-Z adapter GitHub page.
But while I was searching about this adapter, I found an interesting blog post from Yan (Pamela) Yang where she described a different scenario. Some systems can create empty files without locking them. Then, they grab the files again and write some data to them. However, this behavior may cause problems with the default BizTalk Server FILE adapter. For example, the adapter may grab the file AFTER the system creates the empty file, but BEFORE the system attempts to write to it, causing integration issues. Or, in other cases, we may not want to pick up that empty files.
You may also know that the native FILE adapter released with BizTalk grabs and deletes all zero-byte (empty) files without triggering any associated processes. Instead, it logs a warning or error saying that:
The FILE receive adapter deleted the empty file “dir:<folder><file-name>” without performing any processing.
This behavior, according to Microsoft, is by design. Though you can argue that it is not consistent how different adapters treat empty files, e.g., FTP adapter can transfer empty files with no problem.
The File-RADITZ adapter is, kind of, the arch-enemy of the File-Z Adapter. This adapter doesn’t pick up or process empty (zero-byte) files. Instead, it leaves the empty files in the original folder.
I decided to create or recreate this adapter based on Yan Yang scenario just for fun and for mentoring how you can create your custom File adapter by making use of:
DotNet File Adapter sample source code that was available on previous versions of the BizTalk Server SDK
This adapter can be used as a Receive Adapter or as a Send Adapter.
Why the name File-RADITZ?
Well, I named the other adapter FILE-Z because it meant to mean File-Zero, but in reality, because I was a massive fan of Dragon Ball Z :). As I mentioned before, this adapter is, kind of, the arch-enemy of the File-Z Adapter. So, making the idea for a better name, I named it based on a memorable Dragon Ball villain: Raditz, that was one of the first enemy encounters in Dragon Ball Z.
How to install it?
If you want to install the BizTalk Server FILE-RADITZ Adapter, you need to:
Place the folder BizTalkFileRADITZAdapter on any location on your BizTalk Server box. I will recommend to put it in:
C:Program Files (x86)
Note: if you put in any other path you need to modify the StaticAdapterManagement.reg file
Access the folder and double-click on the StaticAdapterManagement.reg file
This will register the adapter to run under 32-bit host instances. To make it available also for 64-bits, you need to:
Click Start
Type %windir%SysWoW64cmd.exe in the search box and press enter
Run the same adapter registry (.reg) file from this command prompt
Now you just need to add this adapter to the BizTalk Server Administration Console:
Open BizTalk Administration Console by pressing the Windows key to switch to the Start menu, type BizTalk Server Administration or BizTalk, click the BizTalk Server Administration option from the Search window.
In the console left tree, expand BizTalk Server Administration à BizTalk Group à Platform Settings and then Adapters.
In the Adapter Properties
In the Name box, type a descriptive name for this adapter.
FILE-RADITZ
In the Adapter combo box, select the adapter from the drop-down that you want to add.
FILE-RADITZ
In the Description box, type a description for the adapter (this is optional).
BizTalk Server File Adapter that is able to process all files except empty (zero byte) files.
Click OK to complete the process of adding the adapter.
Where can you use it?
This version available on GitHub is currently compiled on .NET 4.7.2 and optimized for BizTalk Server 2020. Nevertheless, you can take this code and compile it in other versions of .NET and BizTalk Server. It will be 100% compatible.
Download
THIS ADAPTER IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download the BizTalk Server FILE-RADITZ Adapter from GitHub here:
Unfortunately, some good BizTalk Server resources have disappeared over these years, and they are no longer available. A lot of these resources are custom adapters. One of these adapters was the BizTalk WCF Loopback Adapter initially developed by synthesis consulting (I think), providing back then the source code.
What is the WCF-Loopback Adapter?
The Loopback adapter is simply a two-way send adapter that, in its essence, returns a copy of the outbound message. This capability can be used in several situations or scenarios:
One of them is to replace the need to call pipelines inside an orchestration. Calling pipelines inside orchestrations is a good option, but it complicates the logic of the orchestrations with loops and expressions. You’ll also end up repeating the “code” for each message type/orchestration.
And when it comes back in without the overhead of some repository.
I was recently doing a proof-of-concept at a client, and I needed to invoke a receive pipeline inside the orchestration. That approach worked fine, but it feels like a static black hole that you don’t know is there, and if there is a need to apply any changes, you need to redeploy the orchestration. You cannot simply modify a setting on the pipeline. So, I decide to use the Loopback adapter to recreate the same experience implementing a different approach. Unfortunately, this adapter was no longer available for download, and all the references were wiped out from the face of the Earth. Luckily, I had some old print screens on my vast list of internal resources, and I decided to create a new version of this WCF adapter (king of re-creating) and make this WCF adapter available again.
It was also a good training experience to create a WCF Adapter.
How to install it?
This is a WCF adapter, so installing this adapter is the same as installing any other BizTalk Server WCF extension. And you have two options:
Using the machine.config files – This is the most complicated option, but it is the one I prefer to use;;
Or using the availability of registring WCF extensions on the receive and send handlers will not explain this approach.
You can choose to register this WCF adapter to run under 32-bit host instances, 64-bit host instances, or of course, both.
Open the machine.config present on the folder: C:WindowsMicrosoft.NETFrameworkv4.0.30319Config
I will also recomend, not mandatory, to change also the machine.config present on the folder: C:WindowsMicrosoft.NETFrameworkv2.0.50727CONFIG
To run under 64-bit host instances
Open the machine.config present on the folder: C:WindowsMicrosoft.NETFramework64v4.0.30319Config
I will also recomend, not mandatory, to change also the machine.config present on the folder: C:WindowsMicrosoft.NETFramework64v2.0.50727CONFIG
Restart the services.
Where can you use it?
This version available on GitHub is currently compiled on .NET 4.7.2 and optimized for BizTalk Server 2020. Nevertheless, you can take this code and compile it in other versions of .NET and BizTalk Server. It will be 100% compatible.
Download
THIS ADAPTER IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download the BizTalk Server WCF-Loopback Adapter from GitHub here:
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:
We published a REST web service in BizTalk Server a long time ago that exposes a BizTalk Server Orchestration. Basically, we receive a JSON payload, convert it to XML on the receive pipeline, and apply some logic. If everything goes well, we had this message in a queue to be processed and delivered to an internal system. And this has been working fine until recently the business reported that a few cases were getting stuck on the source system with the following error message:
413 Request Entity Too Large
The above picture was a test we did using Postman with a sample message that was failing on the source system to validate if the problem was related to BizTalk Server. And in this case, it was.
You should always try and validate if the error is a BizTalk Server issue or not, and only then try to solve the problem. Because most of the time, the business tries to blame the middleware system and a lot of times are other components that are failing.
Cause
Based on the HTTP status 413 and error description is easy to understand that the server is refusing to process a request because the request payload is larger than the server is willing or able to process.
The most complex part is understanding where and what properties to change to solve these issues. Some solutions that you will find on the internet will tell you that the quickest and easy solution is to increase the upload size limit on IIS: uploadReadAheadSize property.
Others will tell you to put a maxRequestLength in the system.web to allow, for example, 2MB message size. Or add a binding section on the config and set maxReceivedMessageSize and readerQuotas.
And all of these options, at some point, make sense. The service is running in IIS as a web application and indeed has a web.config, So, that should be, in theory, the first place to look and tunning. But none of these solutions will solve the problem.
Note: This doesn’t mean that for specific scenarios, these will be helpful.
Solution
To solve once and for all this issue you need to:
On the BizTalk Server Administration Console, access to the WCF-WebHTTP Received Location bindeed to this service that is having issues.
On the Receive Location properties window, select Configure..
On the WCF-WebHTTP Transport Properties, select the Binding tab
And incrise the Maximum received message size (bytes) property
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.
A few months ago, I was playing around with BizTalk Server hybrid Integration, in this case, trying to send messages from Logic App to BizTalk Server by using the Send message action of the Logic app BizTalk Server connector. While I conducted the first set of tests, I realized my Logic App was failing to send the message to BizTalk Server. On the BizTalk Server machine, I found that BizTalk Server was throwing the following error while receiving the message:
The Messaging Engine encountered an error when creating the receive adapter “LogicApp”. The Assembly is: “Microsoft.BizTalk.Adapter.LogicApp.Runtime.LogicAppReceiver, Microsoft.BizTalk.Adapter.LogicApp.Runtime”. The error occurred because the component does not implement the mandatory interface “IBTTransportControl”.
The Messaging Engine failed to add a receive location “POC_LOGICAPP_TO_BIZTALK_LA” with URL “/LogicAppTestService/Service1.svc” to the adapter “LogicApp”. Reason: “80070057”.
The receive location “POC_LOGICAPP_TO_BIZTALK_LA” with URL “/LogicAppTestService/Service1.svc” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.
The Messaging Engine failed to add a receive location “POC_LOGICAPP_TO_BIZTALK_LA” with URL “/LogicAppTestService/Service1.svc” to the adapter “LogicApp”. Reason: “80070057”.
The receive location “POC_LOGICAPP_TO_BIZTALK_LA” with URL “/LogicAppTestService/Service1.svc” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.
Exception: System.ServiceModel.ServiceActivationException: The service ‘/LogicAppTestService/Service1.svc’ cannot be activated due to an exception during compilation. The exception message is: Receive location for address “/LogicAppTestService/Service1.svc” not found. (The BizTalk receive location may be disabled.). —> Microsoft.BizTalk.Adapter.Wcf.AdapterException: Receive location for address “/LogicAppTestService/Service1.svc” not found. (The BizTalk receive location may be disabled.)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.ReceiveLocationManager`2.GetEndpointContext(Uri uri)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WebServiceHostFactory`3.CreateServiceHost(String constructorString, Uri[] baseAddresses)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.CreateService(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(ServiceActivationInfo serviceActivationInfo, EventTraceActivity eventTraceActivity)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)
— End of inner exception stack trace —
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)
at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath, EventTraceActivity eventTraceActivity)
Process Name: w3wp
Process ID: 8068
I faced similar issues in the past with other adapters (HTTP, WCF, SOAP, …). However, I knew that I had published the service on IIS with the correct App Pool, privileges and the BizTalk Server receive port associated with this server was running (Enabled).
Nevertheless, my first action was to validate the I could access that URL on the browser, and to my surprise, it was failing!
Luckily I found a very good post written by my friend Ahmed Taha explaining the reason why that was happening and the solution
Cause
The reason for this issue is a bug on the default BizTalk Server 2020 configuration tool that assigns the Logic App Receive Adapter to an In-Process host. The correct setting is to be bound to the Isolated host.
Solution
The resolution is simple but a little annoying.
First, you need to remove the adapter from all assigned send ports and receive locations from all your BizTalk Server applications.
YYou can optimize this process using PowerShell, or if you were lucky like me that only have one receive port and one send port, you could easily do that manually..
The next step is to remove/un-register the Logic App adapter from BizTalk Server. You can do that by running the following VB script:
RemoveLogicAppAdapter.vbs: script to un-register the Logic App adapter from the BizTalk Server
These steps resolved the Logic App Adapter Handler Receive configuration issue in BizTalk Server 2020 and correctly bound it to the Isolated host. So if you try now to configure your receive port, it should work fine.
Final note: BizTalk Server Cumulative Update 2 already provide a hotfix to this issue:
After applying this fix, new receive handlers will be added as Isolated receive handler. However, any existing in-process LogicApp receive handlers need to be deleted manually. So basically, you need to reconfigure all your Receive Locations to use the Isolated host and then delete the receive handlers bounded to the In-Process host.
