Zombies in BizTalk

Question

Ich habe eine BizTalk 2006 R2-Anwendung, die perfekt funktioniert. Es empfängt die Nachrichten, verarbeitet sie und sendet korrekte Antworten.

Aber obwohl das alles korrekt ist (die Nachrichten werden gepflückt erfolgreich durch die Orchestrierungen und die Antwort wird ohne Fehler gesendet), BizTalk noch erzeugt eine „Nachricht nicht verbraucht“ Fehler auf die Antwortnachricht im Zusammenhang ...

Ich habe jedes Bit der Anwendung debuggt und es gibt keinen Fehler, keine doppelte Nachricht, keine Nachricht zurückgelassen, nichts ... Ich habe den Fehler gegooglet und die große Mehrheit der wenigen Links, die ich zu dem Thema finde, sind verwandt mit Zombie bereinigen Skripte. Das lässt mich fragen, ob dies ein allgemeines Problem in BizTalk ist ...

Hat jemand eine Idee auf, was diesen Fehler verursachen kann?

Answer 1

Das klingt wie ein Zombie. Verwendet Ihre Orchestrierung Korrelation und eine Wartezeit? Wenn ja, bist du in Zombie Land. Das Problem besteht darin, dass Sie warten müssen und einen Lesevorgang warten müssen, um zu sehen, welcher Auslöser zuerst ausgelöst wird. Wenn die Wartezeit erst auslöst und dann eine neue Nachricht auf die Korrelation kommt ... Zombie.

Lassen Sie uns mehr über Ihre Orchestrierung wissen, und wir können weiter eine Lösung diskutieren.

Answer 2

Ja ... Dies ist ein häufiges Problem, das meistens durch eine leichte Änderung in der Art und Weise überwunden werden kann, wie Ihre Lösung zusammengestellt wird.

Zombies treten normalerweise auf, wenn Korrelationen und Timeouts verwendet werden, aber nicht das einzige Mal. Die Orchestrierung ist dehydriert und wartet entweder auf eine Antwort auf die Korrelationsmenge oder das Zeitlimit. Wenn die Zeitüberschreitung auftritt, fährt die Orchestrierung mit der Verarbeitung fort, üblicherweise nach dem Empfangsort, der auf die korrelierte Antwort wartet. Jetzt erhält das Meldungsfeld die Antwort, aber es wartet nichts mehr auf diese Antwort. Daher dein Fehler.

Ich habe auch dieses Verhalten beim Anrufen eines Web-Service und Warten auf eine Antwort gesehen; aber das hatte damit zu tun, wie ich Fehler behandelte. Eine kleine Änderung an meinem Prozess löste dieses Problem.

Möglichkeiten, das Auftreten dieses Problems zu minimieren, ist es, den Arbeitsaufwand der Orchestrierung nach dem Timeout zu verkürzen. Mache das Fenster für Zombies so klein wie möglich.

Manchmal ist es nicht möglich, dieses nicht-deterministische Beendigungsproblem zu vermeiden, also habe ich selbst einen "ZombieHandler" -Prozess aufgebaut, der diese Nachrichten empfängt und nach sich selbst aufräumt.

Wenn Sie weitere Informationen über Ihren Prozess veröffentlichen könnten, könnten wir versuchen, einige mehr zu unterstützen.

Answer 3

Der Fehler ist in der BizTalk-Gruppe und nicht im Ereignisprotokoll und ist "Die Instanz abgeschlossen, ohne alle ihre Nachrichten zu konsumieren. Die Instanz und ihre nicht konsumierten Nachrichten wurden ausgesetzt.". Im Grunde genommen habe ich eine Haupt-Orchestrierung, die eine Nachricht über einen Zwei-Wege-Port empfängt, sie an das Nachrichtenfeld sendet, während eine Korrelation initialisiert wird. Die nächste Form in dieser Orchestrierung wartet auf eine Nachricht (ohne eine Zeitüberschreitungslogik) und folgt der Korrelation, die in der vorherigen Sendeform erstellt wurde. Wenn eine Antwort empfangen wird, wird sie an den ursprünglichen Anforderer weitergeleitet.

Es ist eine sehr einfache Orchestrierung (Screenshot: http://img139.imageshack.us/img139/2307/orchestration.jpg) mit fast keiner Logik. Der Punkt ist, dass ich immer richtige Antworten bekomme, so dass ich nicht herausfinden kann, was den Fehler "Nachricht nicht verbraucht" auslöst. Übrigens ist die Nachricht, die als nicht verbraucht markiert ist, die Antwortnachricht.

Weitere Ideen?

Ps. Ryancrawcour, kannst du deinen ZombieHandler genauer ausführen? An welche Eigenschaften binden Sie solche Orchestrierungen?

Answer 4

Warum verwenden Sie einen Korrelationssatz? Sie haben einen initialisierenden Empfang für den Korrelationssatz, wo wird der folgende empfangen?

Können Sie einen Schritt zurückgehen und erklären, was die Voraussetzung für die Korrelation ist? Welche Nachrichten möchten Sie hier zusammenfügen? Ich schätze, wenn Sie Korrelation von dieser Orchestrierung entfernen, wird es perfekt funktionieren.

Hier ist ein link Korrelation Tutorial, wenn Sie einen Blick darauf werfen möchten.

Answer 5

@ChrisLoris:

Screenshot der Orchestrierung: http://img139.imageshack.us/img139/2307/orchestration.jpg

In der Abbildung oben, dass ich eine Orchestrierung haben zu einem Sende verknüpft sehen/Port empfangen. Grundsätzlich erhalte ich eine Nachricht zur Verarbeitung, aktualisiere einige Attribute darauf und sende sie an das Meldungsfeld, während ich eine Korrelation basierend auf einer bestimmten Eigenschaft initialisiere (lasst es MsgIdentifier nennen). Andere Orchestrierungen werden diese Nachricht aufnehmen und die eigentliche Verarbeitung vornehmen. Wenn eine Antwort in das Meldungsfeld mit demselben MsgIdentifier (benutzerdefinierte Eigenschaft) abgelegt wird, nimmt diese Orchestrierung es auf und sendet es an den ursprünglichen Requester zurück.

Die Korrelation wird in der Sendeform initialisiert, die die Anforderung an das Meldungsfeld sendet, und die folgende Empfangsform wartet auf eine Antwort, die derselben Korrelation folgt, d. H. In der MsgIdentifier-Eigenschaft denselben Wert hat.

Stellen Sie sich diese Orchestrierung als Vermittler vor, als Vermittler zwischen dem externen System und den internen Funktionen der BizTalk-Anwendung.

Noch einmal, alles funktioniert einwandfrei und die richtigen Nachrichten werden ohne Probleme aufgenommen und das ist das genaue seltsame Verhalten, das ich versuche zu analysieren. Es sollte die Antwort nicht als Nachricht markieren, die nicht konsumiert wird, weil sie erkannt, verbraucht und zurückgegeben wird.

Answer 6

Besteht die Möglichkeit, dass die ursprüngliche Nachricht von mehreren Orchestrierungen verarbeitet wird? In diesem Fall können zwei Nachrichten in das Meldungsfeld für eine Antwort auf die Orchestrierung, die wir besprechen, eingefügt werden. In diesem Fall würde die erste Nachricht von dem Korrektursatz aufgenommen werden. Da es beim folgenden Empfang kein Schleifenkonstrukt gibt, hätte die zweite Nachricht keinen Platz - Zombie.