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:

EDI application throwing routing failure for Batch Control Message

The EDI batching message that got stuck looked like this:

Failed Batch Control message

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:

BatchControlMessageRecvLoc having PassThruReceive Pipleline set

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:

Correct Setup for this 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!

EDI Batching Orchestration is 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:

BizTalk 2016 Developer Server instance hosted in Azure

I created the new Microsoft Server 2016 instance preinstalled with a default BizTalk 2016 installation.

The instance that is being provisioned is quite powerful:

BizTalk 2016 Developer Edition Server Instance

Then I ran the configuration of BizTalk Server 2016, all defaults for a single box:

All defaults in the BizTalk Configuration Wizard
Configuration running

After the configuration succeeds I directly went into the EDI application setup to see whether the effect shows up here as well:

BizTalk Management Console
Setup of EDI Batch Control Message Receive Location

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.

BizTalk 2016 EDI Subsystem throwing Routing failures

Johannes Rest

.NET Architekt und Entwickler


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

3 × drei =