Architektur zum Veröffentlichen und Abonnieren
In einem Veröffentlichen/Abonnieren-Entwurf gibt es drei Komponenten:
Herausgeber
Abonnenten
Ereignisse
Zu den Herausgebern gehören Empfangsports, die an Empfangsspeicherorten ankommende Nachrichten veröffentlichen, Orchestrierungen, die Nachrichten beim Versenden oder beim asynchronen Starten einer anderen Orchestrierung veröffentlichen, und Sendeports vom Typ "Antwort anfragen", die Nachrichten veröffentlichen, wenn sie eine Antwort von der Zielanwendung oder vom Transport erhalten.
In BizTalk Server gibt es zwei Standard Arten von Abonnements: Aktivierung und instance. Ein Aktivierungsabonnement gibt an, dass eine Nachricht, die das Abonnement erfüllt, beim Empfang eine neue instance des Abonnenten aktivieren oder erstellen soll. Situationen, in denen Aktivierungsabonnements erstellt werden, umfassen Sendeports mit Filtern oder an Orchestrierungen gebundene Sendeports sowie Orchestrierungsformen vom Typ "Empfangen", deren Eigenschaft "Aktivieren" auf "Wahr" festgelegt ist. Ein instance-Abonnement gibt an, dass Nachrichten, die das Abonnement erfüllen, an eine bereits ausgeführte instance des Abonnenten weitergeleitet werden sollen. Beispiele für Situationen, in denen Instanzenabonnements erstellt werden, sind Orchestrierungen mit korrelierten Empfangsports sowie Empfangsports vom Typ "Anforderungsantwort", die auf eine Antwort von BizTalk Server warten.
Der Unterschied zwischen diesen beiden Abonnementtypen auf der Informationsebene besteht darin, dass ein Instanzenabonnement eine eindeutige Instanz-ID enthält, die in der Abonnementtabelle der MessageBox-Masterdatenbank gespeichert wird. Wenn eine Orchestrierungsinstanz oder ein Empfangsport die Verarbeitung abschließt, werden Instanzenabonnements aus der MessageBox entfernt, während Aktivierungsabonnements stets aktiv bleiben, solange die Orchestrierung oder der Sendeport eingetragen ist.
Erstellen von Abonnements
Abonnements werden in BizTalk Server von Dienstklassen erstellt, die in der Tabelle "adm_ServiceClass" in der BizTalk Server-Verwaltungsdatenbank aufgelistet sind. Zu diesen Diensten gehören der Zwischenspeicherungsdienst, In-Process- und isoliertes Messaging (gehostet vom Endpunkt-Manager) und Orchestrierungen/XLANG (gehostet vom XLANG-Subdienst). Jede dieser Dienstklassen kann Abonnements erstellen und veröffentlichte Nachrichten empfangen.
Ein Abonnement ist eine Sammlung von Vergleichsanweisungen bzw. Prädikaten, die Nachrichtenkontexteigenschaften und die spezifischen Werte des Abonnements beinhalten. "Nachrichtentyp" zum Beispiel ist eine Kontexteigenschaft für Nachrichten, und viele Abonnements geben den Nachrichtentyp in ihrem Abonnement an. Allgemeine Informationen zum Abonnement werden vom Nachrichtenagenten in die Abonnementtabelle eingefügt, während die spezifischen Prädikate in eine der folgenden Prädikattabellen eingefügt werden, je nach angegebenem Operationstyp für das Abonnement:
BitwiseANDPredicates
EqualsPredicates
EqualsPredicates2ndPass
ExistsPredicates
FirstPassPredicates
GreaterThanOrEqualsPredicates
GreaterThanPredicates
LessThenOrEqualsPredicates
LessThenPredicates
NotEqualsPredicates
All dies wird durch Aufrufen des Bts_CreateSubscription_<Anwendungsnamens> und Bts_InsertPredicate_< Anwendungsnamen> gespeicherten Prozeduren in der MessageBox-Datenbank erreicht, wobei <anwendungsname> der Name des BizTalk-Hosts ist, der das Abonnement erstellt.
Wenn ein Sendeport eingetragen ist, erstellt der Port mindestens ein Abonnement für jede Nachricht, deren Kontext die Transport-ID dieses Sendeports enthält. Auf diese Weise kann der Sendeport stets Nachrichten empfangen, die ausdrücklich für ihn bestimmt sind. Wenn ein Orchestrierungsport an einen bestimmten Sendeport gebunden ist, werden die Bindungsinformationen in der BizTalk-Verwaltungsdatenbank gespeichert. Wenn Nachrichten von der Orchestrierung durch den an den physikalischen Sendeport gebundenen Port gesendet werden, ist die Transport-ID im Kontext enthalten, sodass die Nachricht zum entsprechenden Sendeport weitergeleitet wird. Beachten Sie jedoch, dass dieser Sendeport nicht der einzige Sendeport ist, der Nachrichten von der Orchestrierung empfangen kann. Wenn eine Orchestrierung eine Nachricht sendet, wird diese Nachricht in der MessageBox-Datenbank mit allen relevanten höher gestuften Eigenschaften veröffentlicht. Der gebundene Sendeport empfängt immer eine Kopie der Nachricht, da sich die Transport-ID im Kontext befindet, es kann jedoch auch jeder andere Sendeport oder jede andere Orchestrierung ein Abonnement besitzen, das mit den Nachrichteneigenschaften übereinstimmt. Es ist sehr wichtig zu verstehen, dass jedes Mal, wenn eine Nachricht direkt in der MessageBox veröffentlicht wird, alle Abonnenten mit übereinstimmenden Abonnements eine Kopie der Nachricht erhalten.
Veröffentlichung und Routing
Nachdem ein Abonnement erstellt und aktiviert wurde, muss eine Nachricht veröffentlicht werden, bevor sie verarbeitet wird. Nachrichten werden veröffentlicht, wenn sie von einem der oben erwähnten Dienste in BizTalk Server empfangen werden. Bei dieser Erläuterung zum Routing befassen wir uns mit den Nachrichten, die über einen Adapter in BizTalk Server eingehen.
Wenn Nachrichten von einer Empfangspipeline verarbeitet werden, werden die Eigenschaften in den Nachrichtenkontext höher gestuft. Nach der Verarbeitung durch den Empfangsadapter und die Empfangspipeline kann eine Nachricht in der MessageBox veröffentlicht werden. Anschließend fügt der Nachrichtenagent die Eigenschaftswerte der höher gestuften Eigenschaften sowie die Prädikatwerte aus dem Nachrichtenkontext in die SQL Server-MessageBox-Masterdatenbank ein. Anhand dieser Werte in der Datenbank kann der Nachrichtenagent Routingentscheidungen treffen.
Im nächsten Schritt fragt der Nachrichtenagent die MessageBox-Masterdatenbank nach Abonnements für den aktuellen, zu veröffentlichenden Nachrichtenstapel ab. Berücksichtigen Sie hierbei, dass die Nachrichten noch nicht in die Datenbank geschrieben wurden, sondern nur die Eigenschaften aus dem Kontext. Die gespeicherte Prozedur "bts_FindSubscriptions" in der MessageBox fragt die oben beschriebenen Abonnement- und Prädikattabellen ab und verknüpft sie mit den gespeicherten Nachrichteneigenschaften für den aktuellen Nachrichtenstapel.
Mit diesen Informationen fügt der Nachrichtenagent die Nachricht ein Mal in jede MessageBox-Datenbank ein, die über ein Abonnement verfügt, indem er die gespeicherte Prozedur "bts_InsertMessage" aufruft. Die bts_InsertMessage gespeicherten Prozedur wird zuerst mit einer Abonnement-ID aufgerufen. In diesem ersten Durchlauf ruft die gespeicherte Prozedur die int_EvaluateSubscriptions gespeicherten Prozedur auf, die für die Suche nach abonnementspezifischen Detailinformationen verantwortlich ist, und überprüft, ob die Nachricht die Sicherheitsanforderungen für die Anwendung erfüllt, indem überprüft wird, ob Nachrichten-Prädikate anwendungseigenschaften für den Host entsprechen, und fügt je nach Zustand einen Verweis auf die Nachricht in der anwendungsspezifischen Warteschlange oder anwendungsspezifischen angehaltenen Warteschlange ein. Die Nachrichten-ID, Abonnement-ID, Dienst-ID und andere Abonnementinformationen werden in der anwendungsspezifischen Warteschlangentabelle für jedes Abonnement eingefügt, das für diese Anwendung gefunden wurde. Nachdem die Nachrichten eingefügt wurden, werden die stapelbezogenen Werte aus den Nachrichteneigenschaften und Nachrichtenprädikattabellen entfernt.
Die gespeicherte Prozedur "bts_InsertMessage" wird nacheinander für jeden Teil in der Nachricht aufgerufen. Beim ersten Aufruf wird der Nachrichtenkontext übergeben und dann zusammen mit Metadaten zur Nachricht in die SPOOL-Tabelle eingefügt, z. B. die Anzahl der Teile, der Name des Textteils und die ID. Darüber hinaus wird der Nachrichtentextteil mithilfe der gespeicherten Prozedur int_InsertPart in die TABELLE PARTS eingefügt. Die gespeicherte Prozedur "bts_InsertMessage" wird anschließend für jeden der verbleibenden Nachrichtenteile aufgerufen, die dann einfach an die gespeicherte Prozedur "int_InsertPart" übergeben werden, um persistent in der PARTS-Tabelle gespeichert zu werden.
Beim Routing von Nachrichten werden Verweise für jeden Dienst hinzugefügt, der die jeweilige Instanz der Nachricht und ihre Teile empfängt, indem in den folgenden Tabellen Datensätze eingefügt werden:
MessageRefCountLog1
MessageRefCountLog2
PartRefCountLog1
PartRefCountLog2
Diese Verweise verhindern, dass die Nachrichten und Nachrichtenteile von Bereinigungsaufträgen gelöscht werden, die regelmäßig ausgeführt werden, um Nachrichtendaten zu nicht mehr im System befindlichen Nachrichten aus der MessageBox zu entfernen. Es werden zwei Tabellen verwendet, um Konflikte und Sperrungen zu reduzieren.
Nachdem die Nachricht nun in die richtige Warteschlange weitergeleitet und in den SPOOL- und PARTS-Tabellen gespeichert wurde und in den anwendungsspezifischen Warteschlangen auf sie verwiesen wird, muss sie von einer Anwendungsinstanz aus der Warteschlange entnommen werden. Jede Hostinstanz besitzt eine Reihe an Verarbeitungsthreads, die die Datenbank regelmäßig in einem bestimmten Intervall abrufen. Dieses Intervall wird in der BizTalk-Verwaltungsdatenbank in der Tabelle "adm_ServiceClass" konfiguriert. In der gleichen Tabelle befindet sich eine Spalte, in der die Anzahl der zu verwendenden Verarbeitungsthreads angegeben wird. Jeder Thread ruft die MessageBox-Datenbank auf und ruft die gespeicherte Prozedur bts_DequeueMessages_<Anwendungsname> auf, die für die Hostanwendung geeignet ist, in der sie ausgeführt wird. Diese gespeicherte Prozedur verwendet Sperrsemantik, um sicherzustellen, dass nur ein instance- und ein Thread, der sich löst, zu einem bestimmten Zeitpunkt mit einer Nachricht in der Warteschlange arbeiten kann. Die Hostinstanz, die die Sperre erhält, erhält die Nachricht, und muss diese an den zuständigen Subdienst übergeben.
Wenn der Endpunkt-Manager die Nachricht empfängt, wird der Sendeport gestartet (oder der Antwortbereich eines Empfangsports vom Typ "Anforderungsantwort"). Empfängt der XLANG/s-Subdienst die Nachricht, wird eine Orchestrierung entweder erstellt oder gesucht, um das Abonnement zu bedienen, je nachdem, ob das Abonnement eine Instanz-ID enthält. Der Dienst gibt dann den Verweis auf die Nachricht und ihren Teil frei, sodass, falls keine anderen Dienste darauf verweisen, die Nachrichtendaten gelöscht werden können.