Plötzlich stockendes XML Debatching mit ungeahnter Ursache

04.05.2017

Die Eingangsdaten kommen in Form eines großen Requests an, sollen aber in Form vieler Einzelnachrichten weiterverarbeitet werden? Eine ganz typische Lösung ist es, ein Envelope Schema für den großen Request und ein Schema für die Einzelnachricht zu definieren. Mit Hilfe des XML Disassemblers in der Receive Pipeline kann dann die große Nachricht aufgespaltet werden.

Diese Lösung war bei unserem Kunden genau so seit Jahren im Einsatz. Die Quelle war eine Datenbankabfrage, das Ziel eine Orchestration zur weiteren Verarbeitung. Doch plötzlich kam an dem Zielsystem nichts mehr an: Sobald die große Nachricht im BizTalk ankam, wurde tatsächlich überhaupt nichts mehr verarbeitet - auch keine andere Nachricht. Zu allem Übel konnte man auch keine Abfragen mehr in der BizTalk Administration Console nach Service Instanzen ausführen. 

Solche Probleme werden in der Regel durch Datenbank-Sperren verursacht - sogenannte Locks. Mit Hilfe des SQL Profilers konnten wir erkennen, dass viele Abfragen in der BizTalkMsgBoxDb auf genau eine weitere Abfrage warteten, es gab jedoch kein Dead-Lock. Normalerweise hilft in so einem Fall einfach abwarten, bis die Abfrage fertig ist. Aber das war sie längst und sie hatte eine "Orphaned MSDTC Transaction" erzeugt, zu erkennen in der Abfrage "sp_who" an einem SPID Wert -2.

Eine verteilte Transaktion also, deren Zustand unklar ist. So eine Transaktion lässt sich per KILL Befehl im SQL Server beenden. Daraufhin reagiert die BizTalk Adminstration Console wieder und suspendete Receive Port Instanzen begrüßten uns mit einem Transaktionsfehler. Ein Resume der Instanz führte dann zu keinem Fehler mehr - wir dachten: Hurra, das Problem ist gelöst! Doch weit gefehlt. Sobald eine neue große Nachricht für diese Verarbeitung ankam, fing das Spiel von vorne an. Dabei war es egal, ob Ambient Transactions des Quell-Adapters aktiviert waren. Selbst mit dem FILE Adapter gab es das Problem. Aber warum plötzlich jetzt, was hatte sich verändert?

 

Typisch für ein Produktionssystem sind schleichend steigende Nachrichtenanzahlen oder -größen. In diesem Fall war wohl mit der Zeit die Größe der Einzelbelege gestiegen und somit auch die Gesamtgröße der Nachricht. So wie wir die Nachricht verkleinerten, war das Problem behoben. Aufgrund der Logik des Verarbeitungsprozesses war das jedoch ebenfalls nur ein Workaround und keine Dauerlösung.

 

Die Kombination von Nachrichtengröße und Datenbankproblemen der BizTalkMsgBoxDb brachte dann aber den nötigen Hinweis. Denn – es gibt eine Einstellung in BizTalk, die beeinflusst, in welchen "Häppchen" BizTalk Nachrichteninhalte in die Messagebox überträgt - die Large Message Threshold (LMT). Dieser Wert bestimmt, ab welcher Größe eine Nachricht in mehr als einem Fragment an die MessageBox übergeben wird. Mit dem MessageBoxViewer (MBV; er wird mittlerweile mit BizTalk mitinstalliert und findet sich unterhalb des Installationsverzeichnisses im Ordner SDK\Utilities\Support Tools\MsgBoxViewer) oder dessen Nachfolger BizTalk Health Monitor (BHM; Zum Download unter https://www.microsoft.com/en-us/download/details.aspx?id=43716) lässt sich ein guter Wert für die LMT bestimmen. Details dazu findet man unter Large Message Threshold im MBV.

 

Der Wert lässt sich dann komfortabel über das Settings Dashboard erhöhen:

 

 

 

 

 

Nach einem Neustart aller Hostinstanzen konnten die großen Nachrichten endlich wieder verarbeitet werden. Hurra - das Problem ist gelöst!

 

 

Tipp: Tatsächlich ist eine regelmäßige Prüfung der BizTalk Umgebung mit dem MBV oder BHM in jedem Fall ratsam. Eine gründliche Prüfung der Warnungen und Empfehlungen kann solche Probleme unter Umständen schon vor deren Entstehung beseitigen. In unserem Fall musste die LMT von dem Standardwert 100 KB auf über 1.400 KB angehoben werden, wodurch zwar der Speicherverbrauch des BizTalks leicht angestiegen ist, aber auch die Verarbeitungszeiten reduziert werden konnten.

zurück

© 2017 QUIBIQ GmbH · AGB und Nutzungsbedingungen