Arbeiten mit Konvoiszenarien
Ein Konvoi ist immer dann vorhanden, wenn mehrere einzelne Nachrichten verknüpft sein müssen, um das erforderliche Ergebnis zu erzielen. Es gibt zwei Standard Arten von Konvois: sequenziell und parallel.
Unter bestimmten Bedingungen kann eine Orchestrierungsinstanz eine Gruppe korrelierter Nachrichten gleichzeitig empfangen. In einem solchen Fall kann eine Racebedingung auftreten, in der eine der Nachrichten der Gruppe in der Orchestrierungsinstanz einen Korrelationssatz initiieren muss, damit die anderen Nachrichten mit dieser Orchestrierungsinstanz korreliert werden können.
Um sicherzustellen, dass alle korrelierten Nachrichten von derselben Orchestrierungsinstanz empfangen werden, ermittelt BizTalk Server die Wahrscheinlichkeit einer solchen Racebedingung und behandelt diese Nachrichten als Konvoi. Beim Eintragen erstellt die Laufzeit ein allgemeines Abonnement und erkennt dieses als Teil eines Konvois. Beim Ausfüllen des Abonnements wird mithilfe der Messaging-Engine anhand der Werte der vordefinierten Korrelationseigenschaften ein temporäres Abonnement erstellt. Dieses temporäre Abonnement wird als Konvoisatz bezeichnet. Bei einem Konvoisatz handelt es sich um eine Gruppe von Korrelationssätzen, die in einem Konvoi verwendet werden. Alle folgenden Nachrichten, die mit dem allgemeinen Abonnement übereinstimmen, werden anhand des Konvoisatzes ausgewertet. Die übereinstimmenden Nachrichten werden an einen vorhandenen Port weitergeleitet.
Verwenden von Konvois in Geschäftsprozessen
Beachten Sie beim Verwenden einer Konvoiverarbeitung von Geschäftsprozessen Folgendes.
Ein Korrelationssatz ist eine Liste von Eigenschaften mit bestimmten Werten, die Sie verwenden, um Nachrichten an einen bestimmten Geschäftsprozess weiterzuleiten. Der korrelationssatz, der für eine Receive-Form verwendet wird, darf nicht mehr als drei Eigenschaften enthalten, die für die Korrelation verwendet werden. Dies liegt daran, dass diese Werte auf Datenbankebene ermittelt und gespeichert werden, sodass maximal drei Parameter unterstützt werden.
Parallele und sequenzielle Konvois können nebeneinander im selben Geschäftsprozess enthalten sein, sie können jedoch über keine gemeinsamen Korrelationssätze verfügen. Dies liegt daran, dass jeder Korrelationssatz zu lediglich einem Konvoi gehören kann.
BizTalk Server unterstützt die Konvoiverarbeitung nicht, wenn Sie das Shape "Orchestrierung starten" verwenden, um einen bereits initialisierten Korrelationssatz an eine neue Orchestrierung zu übergeben. Dies liegt daran, dass Konvoisätze auf Datenbankebene und somit unabhängig von bereits ausgeführten Orchestrierungsinstanzen verarbeitet werden.
Sie können keine einzelne Receive-Form verwenden, um zwei oder mehr Korrelationssätze zu initialisieren, die in separaten Konvois verwendet werden. Wenn beispielsweise Empfänger e1 die Korrelationssätze k1 und k2 für den ersten Konvoi initialisiert, folgt Empfänger e2 für den zweiten Konvoi auf k1 und für den dritten e3 auf k2. Die für den zweiten Konvoi vorgesehenen Konvoisätze sind k1 und e2, und die für den dritten Konvoi vorgesehenen Konvoisätze sind k2 und e3, die alle von e1 initialisiert werden. In diesem Fall werden diese durch die Orchestrierungs-Engine nicht als Konvois behandelt. Bei dem Beispiel handelt es sich um ein gültiges Konvoiszenario, wenn sowohl e2 als auch e3 auf k1 und k2 (k1, e2, e3 und k2, e2, e3) folgen, wenn beide nur auf k1 (k1, e2, e3) folgen, oder wenn beide nur auf k2 folgen (k2, e2, e3).
Zombies
Die Verwendung von Konvois kann zu "verlorenen" Nachrichten – so genannten Zombies – führen. Wenn ein nicht aktivierendes Empfangsabonnement einer ausgeführten Orchestrierung mit einer Nachricht in der MessageBox-Datenbank übereinstimmt, wird die Nachricht von der MessageBox an die Orchestrierung übertragen. Da die MessageBox die Geschäftslogik innerhalb der Orchestrierung nicht kennt, werden einfach alle mit dem Abonnement übereinstimmenden Nachrichten an die Orchestrierung übertragen. Wenn solche Nachrichten übertragen werden, nachdem der Ausführungsfluss der Orchestrierung die Empfangsabonnements durchlaufen hat, die die Nachrichten verarbeiten können, werden diese Nachrichten zu Zombies.
Zombies entstehen beispielsweise, wenn in einer Schleife mit 17 Durchläufen 18 Nachrichten übertragen werden, die dem Empfangsabonnement der Schleife entsprechen. (Der MessageBox ist nicht bekannt, dass über die Orchestrierungslogik nur 17 Nachrichten verarbeitet werden.) Die achtzehnte übertragene Nachricht wird von der Orchestrierung nicht verarbeitet, da der Ausführungsfluss die Schleife bereits verlassen hat. Die Orchestrierung wird mit verworfenen Nachrichten (Zombies) abgeschlossen, die nicht wieder aufgenommen werden können, da die Orchestrierungsinstanz bereits abgeschlossen wurde.
Zombies können mithilfe eines Windows-Verwaltungsinstrumentationsskripts (WMI) verwaltet werden, indem die Instanzen mit dem Status Suspended-NonResumable abgefragt werden. Zudem wird mithilfe der Messaging-Engine die Fehlermeldung „Mit gesperrten Nachrichten abgeschlossen“ ins Ereignisprotokoll geschrieben.
Auch wenn Sie über einen sequenziellen Konvoi mit einem Transaktionsbereich mit langer Laufzeit und einer Timeouteinstellung verfügen, können am Ende einige Orchestrierungsinstanzen mit dem Suspended-NonResumable vorliegen. Möglicherweise stellen Sie zudem fest, dass die Summe der Ausgabemeldungen und der Suspended-NonResumable-Instanzen kleiner ist, als die Anzahl der Eingabemeldungen. Dieses Verhalten ist beabsichtigt. Beim Auftreten einer Timeoutausnahme wechselt der Code in den Ausnahmehandler. In BizTalk Server wird der Ausnahmehandler aufgerufen, damit die Ausnahme einschließlich der Zombies verarbeitet werden kann. Im Ausnahmehandler kann ein Sendeport verwendet werden, um die Zombies zur weiteren Prüfung und Verarbeitung an ein bestimmtes Ziel zu senden.
Auch in anderen Szenarien können Zombies entstehen. So kann beispielsweise eine Orchestrierungsinstanz eine Antwortnachricht von einem Geschäftsprozess erwarten und aus einem bestimmten Grund zwei übereinstimmende Abonnementantwortnachrichten erhalten. In einem solchen Fall wird aus der zweiten Antwortnachricht ein Zombie. Ein weiteres Beispiel ist, wenn Sie über ein Listen-Shape mit einem Receive-Shape an einem Branch und einem Delay-Shape an der anderen Verzweigung verfügen. Wenn eine Nachricht zum gleichen Zeitpunkt wie der Timeout eintrifft, wird sie zum Zombie.
Weitere Informationen zum Verwalten von Zombies finden Sie unter Entfernen von angehaltenen Dienstinstanzen in der Api-Namespacereferenz für Benutzeroberflächen und Entwickler.