Meldungen
Eine EMS-Nachricht (Enterprise Message Service) enthält wie eine JMS-Nachricht drei separate Teile: Header, Eigenschaften und Text. Der Header ist der einzige erforderliche Teil einer EMS-Nachricht. Dieses Thema beschreibt, wie Nachrichten im Microsoft BizTalk-Adapter für TIBCO Enterprise Message Service behandelt werden.
Hinweis
Zum Festlegen oder Abrufen eines Headerfelds (z. B. Festlegen der Nachrichtenpriorität oder Korrelations-ID) oder einer Nachrichteneigenschaft aus der Orchestrierung müssen Sie mithilfe von Projektmappen-Explorer einen Verweis auf die Microsoft.BizTalk.Adapters.TIBCOEMSProperties.dll in Ihrem Projekt hinzufügen.
Nachrichtenheader
Der Nachrichtenheader enthält eine Reihe vordefinierter Felder, die Werte enthalten. Im BizTalk-Adapter für TIBCO Enterprise Message Service ist hinterlegt, was im Header festgelegt werden kann und was nicht. Wenn Sie versuchen, einen schreibgeschützten Wert festzulegen, leitet der Adapter den Wert im Abschnitt Eigenschaften{} um oder legt diesen fest.
Headerbeispiel
Beachten Sie im folgenden Beispiel, dass Properties= { Destination={String:Queue[Q2]} }. Properties ist eine Eigenschaft, die eine Zeichenfolge enthält, und der Inhalt der Zeichenfolge ist Q2. Dies steht in keinem Zusammenhang mit dem Abschnitt Destination. Dieser enthält Zeichenfolgen aus von Ihnen festgelegten Werten, die an keine andere Stelle gehören, sodass sie vom Adapter in diesem Abschnitt abgelegt wurden.
Die ReplyTo -Eigenschaft kann in der Orchestrierung festgelegt werden, um einem letztlichen Consumer mitzuteilen, wohin eine Antwort gesendet werden soll. EMS legt die Destination -Eigenschaft fest, wenn die Nachricht von TIBCOEMS empfangen wird. Diese zweite Eigenschaft ist in der Orchestrierung, die die Nachricht von TIBCOEMS empfängt, schreibgeschützt und kann in der Orchestrierung nicht bearbeitet werden.
Eine Orchestrierung kann beispielsweise keine Nachrichten verschicken und das Ziel dynamisch innerhalb einer Orchestrierung festlegen. Der Wert von Destination wird vom Port festgelegt, an den die Nachricht übermittelt wird.
Wenn Sie Nachrichten an verschiedene Warteschlangen verschicken möchten, müssen Sie für jede Warteschlange Sendeports erstellen. Anschließend kann die Orchestrierung entscheiden, welchem Port die Nachricht zugewiesen werden soll.
Im folgenden Meldungsbeispiel ist Destination= {Queue[Q1]} schreibgeschützt. Dieser Wert wird von TIBCOEMS festgelegt, wenn der Server die Nachricht empfängt. Der Wert für Destination, „Q1“, stammt aus den Transporteigenschaften.
Beispiel
TextMessage={
Header={ MessageID={ID:EMS-SERVER.824437A58B11C75F4:1}
Destination={Queue[Q1]}
' This is READONLY. It gets set by the server when the
' message is received by the server (EMS). It is set in the
' Transport Properties when you specify that you want to
' listen for messages on Q1.
ReplyTo={}
DeliveryMode={Persistent}
Redelivered={False}
CorrelationID={}
MsgType={}
Timestamp={12/1/2005 11:59:01 PM}
Expiration={0}
Priority={1} }
Properties={ Destination={String:Queue[Q2]} }
' This is a property that contains a string, and the
' contents of the string is Q2. This has nothing to do with
' the Destination section above – it is just another
' property that is set.
' This is in the schema. The adapter knows what it can and
' cannot set in an EMS header. The values that the adapter
' cannot set are put in the Properties section.
text={<?xml version="1.0" encoding="utf-16"?>
<ns0:Employees xmlns:ns0="http://BizTalk_Server_Project1.Employee">
<Emp Id="Id_0">
Name>Name_0</Name>
</Emp>
</ns0:Employees>
}
Der Header enthält eine Reihe vordefinierter Felder, die Werte enthalten, die vom Adapter in den BizTalk Server-Nachrichtenkontext zur Verwendung in der Orchestrierung höher gestuft werden. Die höher gestuften Eigenschaften sind der Definition nach mit den Headerstandardeigenschaften identisch, wie sie durch die JMS-Spezifikation und die TIBCO Enterprise Message Service-Erweiterungen definiert sind. Alle Eigenschaften mit Ausnahme von zwei sind für die Orchestrierung verfügbar, wie sie von EMS empfangen werden: Destination und ReplyTo beschreiben ein Ziel, das nicht ordnungsgemäß für die Verwendung in einer Orchestrierung als einzelne Eigenschaft zugeordnet werden kann.
Der BizTalk-Adapter für TIBCO EMS ordnet die TIBCOEMS-Eigenschaft einem Zeichenfolgentyp zu und verwendet die Zeichenfolgendarstellung Destination. Dies sieht wie folgt aus: StaticQueue[queuename] oder StatisTopic[topicname]. Die Orchestrierung kann den Wert für ReplyTofestlegen, und der Adapter ersetzt ihn durch ein gültiges Zielobjekt im Header.
Der Adapter stellt ein Schema und eine Referenzassembly bereit, die alle TIBCO EMS-Headereigenschaften beschreiben, die von Orchestrierungen verwendet werden können. Diese Eigenschaften können entweder zum Filtern eingehender Nachrichten verwendet werden, oder um sie den ausgehenden Nachrichten hinzuzufügen. Die Regeln, die den Orchestrierungsfilter bestimmen, unterscheiden sich von denen für den Nachrichtenselektor für den EMS-Server. Orchestrierungen können z. B. nach der TibcoEMS.ReplyTo - oder - TibcoEMS.Destination Eigenschaft filtern, aber die JMS-Spezifikation unterstützt keine Nachrichtenauswahl für dieselbe Eigenschaft.
Wenn diese Eigenschaften von der Orchestrierung definiert wurden, werden sie in die Headereigenschaften der JMS-Nachricht aufgenommen. Alternativ werden diese Headereigenschaften in den BizTalk Server-Nachrichtenkontext kopiert, wenn die EMS-Nachricht empfangen wird.
Wenn eine Eigenschaft mit der Portkonfiguration übereinstimmt, setzt der Wert der Eigenschaft der Nachricht die Portkonfiguration außer Kraft. Wenn die Priorität beispielsweise im Port auf „4“ festgelegt ist, Sie aber die Priorität der Nachricht in der Logik der Orchestrierung auf „9“ festlegen, wird die Nachricht vom TIBCO EMS mit der Priorität 9 empfangen.
Eigenschaftsbeschreibungen
In der folgenden Tabelle wird beschrieben, wie jede Eigenschaft vom BizTalk-Adapter für TIBCO Enterprise Message Service verwendet wird.
| Name | Typ | BESCHREIBUNG |
|---|---|---|
| TibcoEMS.MessageID | Zeichenfolge | Sendende Aufrufe weisen jeder Nachricht eine eindeutige ID zu und zeichnen diese im Header auf. Alle Nachrichten-ID-Werte beginnen mit der aus drei Zeichen bestehenden Präfix-ID (die für diesen Zweck reserviert ist). Schreibgeschützt. Das Ändern des Werts hat keine Auswirkungen auf die Nachricht. |
| TibcoEMS.Timestamp | long | Sendende Aufrufe zeichnen einen UTC-Zeitstempel im Header auf. Dieser gibt die ungefähre Zeit an, zu der die Nachricht vom Server akzeptiert wurde. Der Wert ist in Millisekunden seit dem 1. Januar 1970 angegeben. Schreibgeschützt. Das Ändern des Werts hat keine Auswirkungen auf die Nachricht. |
| TibcoEMS.Redelivered | boolean | Der Server legt den Header so fest, dass angezeigt wird, ob eine Nachricht möglicherweise ein Duplikat einer zuvor zugestellten Nachricht darstellt: – false: Der Server hat noch nicht versucht, diese Nachricht an den Consumer zu übermitteln. – true– Es ist wahrscheinlich, aber nicht garantiert, dass der Server zuvor versucht hat, diese Nachricht an den Consumer zu übermitteln, aber der Consumer hat keine rechtzeitige Bestätigung zurückgegeben. Schreibgeschützt. Das Ändern des Werts hat keine Auswirkungen auf die Nachricht. |
| TibcoEMS.Destination | Zeichenfolge | Sendende Aufrufe zeichnen das Ziel (Warteschlange oder Thema) der Nachricht in diesem Header auf. Das Format wird von einem Ziel zu einer Zeichenfolge angepasst. Das Format wurde zuvor beschrieben. Schreibgeschützt. Das Ändern des Werts hat keine Auswirkungen auf die Nachricht. |
| TibcoEMS.DeliveryMode | Zeichenfolge | Verfügt über zwei mögliche Werte: PERSISTENT und NON-PERSISTENT. Der Standardwert ist der Modus PERSISTENT. Der Adapter wartet auf eine Bestätigung vom EMS-Server, bevor die an den BizTalk Server gesendete Nachricht bestätigt wird. Diese Headereigenschaft und das Portkonfigurationselement steuern den Zeitraum, den der EMS verwendet, um diese Bestätigung an den Adapter zu senden und die Zuverlässigkeit der Nachrichtenübermittlung zu kontrollieren. Bei Verwendung des Zustellmodus PERSISTENT wartet der EMS-Server, bis die Nachricht erfolgreich auf dem EMS-Server beständig gespeichert wurde. Durch diese Aktion ist garantiert, dass die Nachricht in der Warteschlange eingegangen ist. Berücksichtigen Sie bei Verwendung des Zustellmodus PERSISTENT Folgendes: Je größer die Nachrichten sind, desto länger dauert es, bis BizTalk Server die Nachricht als gesendet einstuft. Bei Verwendung des Zustellmodus NON-PERSISTENT gibt der EMS-Server die Bestätigung zurück, bevor die Nachricht beständig gespeichert wurde. Wenn ein Fehler beim EMS-Server auftritt, kann die Nachricht verloren gehen, auch wenn sie von BizTalk Server als erfolgreich gesendet eingestuft wird. |
| TibcoEMS.Expiration | long | Zeitraum, über den die Nachricht gültig ist, bevor sie abläuft. Bei Festlegung auf „0“ läuft die Nachricht nie ab. Die Gültigkeitsdauer (Time-to-Live, TTL) wird in Millisekunden angegeben. |
| TibcoEMS.Priority | INT | Verwendet eine numerische Rangfolge zwischen 0 und 9, um die Nachrichtenpriorität als normal oder beschleunigt zu definieren. Höhere Zahlen entsprechen höheren Prioritäten. |
| TibcoEMS.CorrolationID | Zeichenfolge | Kann zum Verknüpfen von Nachrichten verwendet werden, z. B. zum Verknüpfen einer Antwortnachricht mit einer Anforderungsnachricht. In der Regel ist dies derselbe Wert wie . EMS.JMSMessageID Dies wird in der Regel zusammen mit der EMS.JMSReplyTo -Eigenschaft verwendet. |
| TibcoEMS.ReplyTo | Zeichenfolge | Ein Ziel, an das eine Antwortnachricht gesendet werden soll. Das Format ist identisch mit der Konfiguration des EMS.JMSDestination Ports und des Ports. |
| TibcoEMS.Type | Zeichenfolge | Beschreibt den Nachrichtentyp (Text, Byte, String (Zeichenfolge)…). Einige JMS-Anbieter verwenden ein Nachrichtenrepository zum Speichern von Nachrichtentypdefinitionen. Clientprogramme können einen Wert in diesem Feld speichern, um auf ein Ziel in dem Repository zu verweisen. EMS unterstützt diesen Header, verwendet ihn aber nicht. Die JMS-Spezifikation definiert weder ein Standardrepository für Nachrichtendefinitionen noch eine Benennungsrichtlinie für Nachrichtentypdefinitionen. Einige Anbieter erfordern Nachrichtentypdefinitionen für jede Anwendungsnachricht. Um die Kompatibilität mit solchen Anbietern zu garantieren, können Clientprogramme diesen Header festlegen, auch wenn sie ihn nicht verwenden. Um die Portierbarkeit zu garantieren, können Clients diesen Header mit symbolischen Werten festlegen (statt mit Literalwerten) und so konfigurieren, dass sie mit dem Repository des Anbieters übereinstimmen. |
Eigenschaften
Der Integrator kann einen Satz von Eigenschaften definieren, die in den BizTalk Server-Nachrichtenkontext höher gestuft werden sollen, wonach die Eigenschaften im Properties-Teil der JMS-Nachricht hinzugefügt werden. Der Integrator kümmert sich beim Definieren des Typs der Eigenschaft darum, während das Schema erstellt wird. Wird dieser Eigenschaftenwert in einem Nachrichtenselektor verwendet, sind in Abhängigkeit vom Typ der Eigenschaft bestimmte Vorgänge gültig. Wenn beispielsweise die Nachrichtenauswahl myMessageProperty > 5 verwendet wird, muss die Eigenschaft als ganzzahliger Wert definiert werden, und der Adapter fügt den Wert in der Nachricht als ganzzahligen Wert ein. Die Namen der Eigenschaften, die höher gestuft werden sollen, müssen mit EMSX beginnen. Ferner dürfen sie nicht dieselben Namen wie die vordefinierten Eigenschaften besitzen.
Der BizTalk-Adapter für TIBCO Enterprise Message Service stellt ein Schema und eine Assembly bereit, die die EMS- und JMS-spezifischen Eigenschaften deklarieren, die in diesem Abschnitt vorkommen können. Diese können so erweitert werden, dass Auslassungen erfasst werden. Alle EMSX-Eigenschaften, auf die im Nachrichtenkontext verwiesen wird, werden im Nachrichteneigenschaftenabschnitt der EMS-Nachricht abgelegt. Weitere Informationen finden Sie im TIBCO EMS-Benutzerhandbuch.
Text
EMS unterstützt alle Nachrichten, die in der JMS-Spezifikation aufgelistet sind: Text, Byte, Stream, Zuordnung und Objekt. Der BizTalk-Adapter für TIBCO EMS unterstützt nur den Textnachrichtentyp.
JMS erfordert nicht, dass Nachrichten vom Typ Text XML-formatierte Textkörper enthalten. Der Adapter verarbeitet den Nachrichtentext nicht. sie wird BizTalk Server als empfangen bereitgestellt. Daher analysieren Nachrichten, die vom Adapter an BizTalk gesendet werden, möglicherweise nicht immer als XML-Daten.
Persistente Nachrichten
Nachrichten können auf dem EMS-Server beständig gespeichert werden, um die genau einmalige Zustellung an einen Abonnenten zu garantieren. Dies kann sich jedoch beträchtlich auf die Leistung des Adapters auswirken. Wenn Sie Nachrichten senden, wird die jeweilige Nachricht vom EMS im lokalen Speicher gespeichert, bevor ihr Empfang dem Adapter bestätigt wird. Sie können diese Eigenschaft in der Orchestrierung pro Nachricht oder für alle von dem Port verarbeiteten Nachrichten festlegen.
Unter dem Aspekt des Empfangens betrachtet kann der Adapter Nachrichten verlieren, wenn er das Thema nicht abonniert hat. Nachrichten die in Themen bereitgestellt werden, für die keine Abonnenten vorhanden sind, werden vom EMS nicht beständig gespeichert. Der Adapter benötigt einen Mechanismus zum Empfangen von Nachrichtenbereitstellungen, auch wenn er aktuell kein Abonnement unterhält. Ähnlich wie die Verwendung persistenter Nachrichten hat dies jedoch ebenfalls signifikante Auswirkungen auf die Leistung des EMS und ist nicht immer erforderlich.
Hinweis
Aus Sicht des EMS ist ein Mechanismus zum Empfangen vorhanden, doch er ist weder implementiert, noch ist dies wünschenswert. Dies ist nur für Themen ein Problem; Warteschlangen sind hiervon nicht betroffen. Ein Thema wird normalerweise für zeitabhängige Daten verwendet – beispielsweise Aktiennotierungen. Geht ein Aktienkurs verloren, wissen Sie, dass er später erneut bereitgestellt wird.
Aus diesen Gründen gestattet Ihnen die Portkonfiguration das Aktivieren bzw. Deaktivieren der Nachrichtenpersistenz auf dem EMS-Server.
Nachrichtenbestätigung
Der BizTalk-Adapter für TIBCO Enterprise Message Service bestätigt immer den Empfang einer Nachricht, wenn diese ordnungsgemäß an BizTalk Server verschickt wurde. Dies bedeutet, dass nicht bestätigte Nachrichten von EMS erneut an den Adapter gesendet werden. Der Adapter kann die Anzahl der erneuten Sendeversuche für eine Nachricht durch EMS nicht kontrollieren, weil dies eine Konfiguration des Ziels selbst ist. Der Adapter kann jedoch kontrollieren, ob die Nachricht an die MessageBox gesendet wurde oder nicht. Der EMS-Server kontrolliert die maximal zulässige Anzahl der Sendeversuche für eine fehlerhafte Nachricht an eine Warteschlange.
Für Nachrichten, die erneut zugestellt werden, legt der EMS-Server die JMSRedelivered Eigenschaft auf True fest und inkrementiert.JMSXDeliveryCount Beide Eigenschaftenwerte sind für die Orchestrierung verfügbar. Sie können eine Nachricht nicht in die EMS-Warteschlange unzugestellter Nachrichten verschieben, ohne sie dorthin zuzustellen. Diese Vorgehensweise würde die Nachrichteneigenschaften ändern.
Wenn eine Nachricht die konfigurierte maximal zulässige Anzahl für erneute Zustellungen erreicht, bestimmt der EMS-Server, ob die Nachricht gelöscht oder in die Warteschlange $sys.undelivered eingestellt werden soll. Der EMS-Server trifft die Entscheidung basierend auf der JMS_TIBCO_PRESERVE_UNDELIVERED -Eigenschaft. Wenn true, wird die Nachricht an die nicht zugestellte Warteschlange gesendet, oder sie wird gelöscht. Diese Eigenschaft kann in der Orchestrierung vor dem Senden der Nachricht festgelegt werden, Nach der Zustellung kann die Nachrichteneigenschaft nicht mehr geändert werden. An EMS gesendete Nachrichten werden von BizTalk Server bestätigt, wenn sie erfolgreich empfangen wurden. Tritt beim Senden an den EMS ein Fehler auf, werden sie angehalten und für einen erneuten Versuch markiert.
Weitere Informationen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für