Recently I came across a very strange behaviour when I was reviewing a fresh installed BizTalk 2016 environment using the EDI application that comes with BizTalk 2016.
On that environment theres a customer applications that wants to write out EDI files. The testing of the application was stalled due to the fact that the EDI application produces suspended messaging instances:
The EDI batching message that got stuck looked like this:
When checking this issue I analyzed various sources for this effect, but non proved to be correct. Also the favourite search engine produced little results.
When approaching the issue systematically, I checked the routing settings of the EDI application itself. Then something strange caught my eye:
This is astonishing, as the PassThruReceive pipeline setting will not enable BizTalk to determine the incoming message type. And that would explain why there are no subscribers available in the system.
Checking an existing installation with a running version of the EDI applications shows the following for that receive location:
That looks far more reasonable! So I went for this and started the party batch again, and to not much suprise the EDI application came back to life!
But how did it come to such a strange configuration? At first I was thinking of a manual configuration error, that rendered the EDI application virtually unusable. Luckily enough I had a fresh installed BizTalk Development Server at my disposal and used it to verify the setting there as well.
And it turned out that this machine had the same issue! So no manual intervention happend here, but some bogus setup coming directly from the BizTalk 2016 installation itself.
So logically the last part of this article would be to verify that setup with a standard installation provided by Microsoft itself:
I created the new Microsoft Server 2016 instance preinstalled with a default BizTalk 2016 installation.
The instance that is being provisioned is quite powerful:
Then I ran the configuration of BizTalk Server 2016, all defaults for a single box:
After the configuration succeeds I directly went into the EDI application setup to see whether the effect shows up here as well:
So this effect does not come up with a new installation on Azure. Which makes me wonder why the error occured on our images in the first place. This is really good news.
However, I hope you found this article worth reading and perhaps it helped reading it.
