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
Until now, I usually have used the Logic App adapter to send messages to Azure Logic Apps and extend the BizTalk Server capabilities with the Azure Services. Yesterday, once I was trying the inverse capabilities, i.e., receiving a message from Logic App into BizTalk Server using the Logic App Adapter and, of course, the BizTalk Server Connector available on Logic App. I was surprised with the following error while I was trying to access the exposed service to receive messages from Logic App:
Receive location for address “/LogicAppTestServoce/Service1.svc” not found. (The BizTalk receive location may be disabled.)
This is a common error. It means that the Receive Location doesn’t exist or it is disabled. So I went to the BizTalk Server Administration Console and Enabled the Receive Location, but it automatically disabled again.
Once I check the Event Viewer for errors I found the 3 following errors:
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. “.
Cause
There is a critical bug in the default installation of the Logic App adapter that will affect the process of receiving messages from Logic Apps using the BizTalk Server Connector.
The Logic App Receive handler, or what we usually call the Logic App Receive adapter, is, by default, configured to use the default In-Process Host, normally the BizTalkServerApplication, in this case, as you saw in the picture bellow BizTalkServerReceiveHost.
Like what happens with the HTTP adapter, the Logic App Adapter is one of the adapters that support two-way communications. Still, unlike other adapters, this adapter has two characteristics that define it:
The Logic App Receive Adapter that is responsible for delivering messages to BizTalk is, in fact, a WCF Service that runs inside Internet Information Services (IIS).
And for that reason, it must be configured in IIS – it is not there out-of-the-box.
This means that when we create and configure a receive location that uses the Logic App adapter inside the BizTalk Server Administration Console, this receive location uses an application within IIS.
So, if you leave this Logic App Adapter default configuration, you will end up having the above errors when trying to activate a Receive Location. This happens assigned because the Receive handler is associated with the In-process Host and it should be bound to the Isolated Host.
Solution
To fix this bug we need to:
Remove the adapter from all assigned send ports and receive locations in my applications
Therefore, it is essential to do this immediately after the installation and configuration of your BizTalk Server environment. Otherwise, it will affect your existing application that uses the Logic App adapter to send messages to Logic Apps.
When you deploy a new BizTalk Server solution to a different environment, and if for some reason, you don’t use or cannot use CI/CD (Continuous integration and continuous delivery):
Your environment is too small to justify using CI/CD;
The client doesn’t provide access to Visual Studio Team Services (VSTS);
Don’t like to use BTDF (Deployment Framework for BizTalk);
Not using custom tools like BizTalk Bindings Exporter tool;
Then one of the most common tasks you need to do is to change all the URI from all the ports, Receive Ports and Send Ports, from the binding files.
Of course, you can do it in many different ways, for example:
Before import to the new environment, open notepad or any other editor, and manually replace all the Inbound Transport URL and Outbound Transport URL;
Import AS IS and on the Administration Console, manually change these parameters;
Or script this process;
This is not always a quick and easy job. Luckily for us, these tasks can be automated, leading them to become simpler, faster, and avoid fewer errors.
This script that I will be showing you can be very useful, for example, in scenarios that during the lifecycle of existing applications, one system got updated or migrated to a different version or server (or both), and we need to update the URI or part of it on a range of the Receive Locations according to the new configuration/specification.
PowerShell script overview
With this PowerShell sample, we will be able to set or update the URI (address) or part of the URI on a list of BizTalk Server Receive Locations deployed in your BizTalk Server environment.
foreach($receivePort in $catalog.ReceivePorts)
{
# For each receive location in your environment
foreach($recLocation in $receivePort.ReceiveLocations)
{
# In this case ...
if($rcvLocations.Contains($recLocation.Name))
{
[string] $address = $recLocation.Address
$address = $address.Replace("DEV-SERVER-NAME","PRO_SERVER-NAME")
# Sample of additional custom changes
if($address.Contains("PREFIX"))
{
$address = $address.Replace("DATABASE","DATABASE-WITH-PREFIX-A")
}
else
{
$address = $address.Replace("DATABASE","DATABASE-WITH-PREFIX-B")
}
$recLocation.Address = $address
}
}
}
This script was tested in BizTalk Server 2016.
Download
THIS POWERSHELL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
With security be every day more important, this also brings additional problems (good problems) to BizTalk Server Administrators during the deployment of new BizTalk Server Applications or even during the lifecycle of existing applications:
What a few years ago was anonymous, because they were internal services, they are now authenticated.
Nowadays, many organizations implement a combination of Minimum Password Age policy also enforcing a Password History policy that requires to reset the password, even for services accounts, from time to time and avoid reusing the same password.
These tasks lead to BizTalk Server Administrators to manually set the user credentials in a range of ports (send and receive). This is not always a quick and easy job.
Luckily for us, these tasks can be automated, leading them to become simpler, faster, and avoid fewer errors.
PowerShell script overview
With this PowerShell sample, we will be able to set or update the Authentication Credential on a list of BizTalk Server Receive Locations deployed in your BizTalk Server environment.
foreach($receivePort in $catalog.ReceivePorts)
{
# For each receive location in your environment
foreach($recLocation in $receivePort.ReceiveLocations)
{
# In this case ...
if($rcvLocations.Contains($recLocation.Name))
{
$bindingConfiguration = $recLocation.TransportTypeData
if($bindingConfiguration.CustomProps.Password.vt -eq "1")
{
$bindingConfiguration.CustomProps.Password.InnerText = "my_password"
$bindingConfiguration.CustomProps.Password.vt = "8"
}
else
{
$passwordElement = $bindingConfiguration.CreateElement("Password")
$passwordElement.SetAttribute("vt", "8")
$passwordElement.InnerText = "my_password"
$bindingConfiguration.CustomProps.InsertAfter($passwordElement, $bindingConfiguration.CustomProps.SuspendMessageOnFailure)
}
if($bindingConfiguration.CustomProps.UserName.vt -eq "8")
{
$bindingConfiguration.CustomProps.UserName.InnerText = "my_username"
}
$transportConfigData = $bindingConfiguration.InnerXml
$recLocation.TransportTypeData = $transportConfigData
}
}
}
This script was tested in BizTalk Server 2016.
Download
THIS POWERSHELL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
