Um Ereignisse nach der Implementierung eines Nachrichtenflusses
anzupassen, ohne den Fluss erneut implementieren zu müssen, wird ein konfigurierbaren Service für
Überwachungsprofile verwendet. Mit diesem Service können Sie ein Überwachungsprofil auf einen oder
mehrere Nachrichtenflüsse anwenden.
Ein Überwachungsprofil ist ein XML-Dokument, in dem die Ereignisquellen in einem
Nachrichtenfluss, der Ereignisse ausgeben wird, sowie die Eigenschaften dieser Ereignisse angegeben
sind. Das XML-Überwachungsprofil muss der XML-Schemadatei MonitoringProfile.xsd entsprechen.
Überwachungsprofilentwurf
Dies ist ein Überwachungsprofilentwurf mit nur einer Ereignisquelle zur Darstellung der Struktur:
<p:monitoringProfile
xmlns:p="http://www.ibm.com/xmlns/prod/websphere/messagebroker/6.1.0.3/monitoring/profile" p:version="2.0">
<p:eventSource p:enabled="true" p:eventSourceAddress="SOAPInput.transaction.Start">
<p:eventPointDataQuery>
<p:eventIdentity>
<p:eventName p:literal="" p:queryText=""/>
</p:eventIdentity>
<p:eventCorrelation>
<p:localTransactionId p:queryText="" p:sourceOfId="automatic"/>
<p:parentTransactionId p:queryText="" p:sourceOfId="automatic"/>
<p:globalTransactionId p:queryText="" p:sourceOfId="automatic"/>
</p:eventCorrelation>
<p:eventFilter p:queryText="true()"/> <p:eventUOW p:unitOfWork="messageFlow" /> </p:eventPointDataQuery>
<p:applicationDataQuery>
<p:simpleContent p:dataType="boolean" p:name="" p:targetNamespace="">
<p:valueQuery p:queryText=""/>
</p:simpleContent>
<p:complexContent p:name="" targetNamespace="">
<p:payloadQuery p:queryText=""/>
</p:complexContent>
</p:applicationDataQuery>
<p:bitstreamDataQuery p:bitstreamContent="all" p:encoding="base64Binary"/>
</p:eventSource>
</p:monitoringProfile>
Das Stammelement ist
p:monitoringProfile.
Es enthält ein oder mehrere
p:eventSource-Elemente, von denen jedes eine
Ereignisquelle angibt und deren Eigenschaften definiert.
Jedes
p:eventSource-Element enthält Folgendes:
- Ein p:eventPointDataQuery-Element, das Schlüsselinformationen zu dem Ereignis
liefert.
- Optional: Ein p:applicationDataQuery-Element, wenn die Ereignisnutzdaten Datenfelder einschließen, die aus einer Nachricht extrahiert wurden.
- Optional: Ein p:bitstreamDataQuery-Element, wenn die Ereignisnutzdaten Bitstromdaten aus einer Nachricht einschließen.
Überwachungsprofil erstellen
Um Ihnen die Erstellung von Überwachungsprofilen zu erleichtern, enthält das folgende Beispiel eine XML-Datei mit einem Überwachungsprofilentwurf sowie die XML-Schemadatei für Überwachungsprofile (MonitoringProfile.xsd):
Überprüfen Sie Ihre eigenen Überwachungsprofile anhand des XML-Schemas, um ihre Korrektheit sicherzustellen.
Informationen zu Beispielen können nur bei Verwendung des in das WebSphere Message
Broker Toolkit integrierten bzw. online verfügbaren Information Center angezeigt werden. Muster können nur ausgeführt werden, wenn das im
WebSphere Message
Broker Toolkit integrierte Information Center verwendet wird.
Tipp: Wenn ein Nachrichtenfluss implementiert ist, für den mit dem
Nachrichtenflusseditor Überwachungseigenschaften konfiguriert wurden, können Sie mit dem Befehl
mqsireportflowmonitoring eine XML-Datei mit dem entsprechenden Überwachungsprofil für den
Nachrichtenfluss erstellen. Dieses Profil kann als Ausgangspunkt für die Erstellung weiterer
Überwachungsprofile dienen.
Die folgenden Schritte beschreiben die Vorgehensweise beim
Erstellen eines XML-Überwachungsprofils. Folgen Sie diesen Schritten für jedes p:eventSource-Element.
- Geben Sie das Attribut p:eventSource/@p:eventSourceAddress an.
Dies ist
eine Zeichenfolge, die die Ereignisquelle im Nachrichtenfluss eindeutig identifiziert. Sie muss dem
festen Format für Transaktionsereignisse und Terminalereignisse entsprechen, so wie in der
folgenden Tabelle beschrieben:
Ereignistyp |
Ereignisquellenadresse |
Transaktionsstart |
Knotenbezeichnung.transaction.Start |
Transaktionsende |
Knotenbezeichnung.transaction.End |
Transaktions-Rollback |
Knotenbezeichnung.transaction.Rollback |
Terminalereignis |
Knotenbezeichnung.terminal.<Terminal> |
Anmerkung: Knotenbezeichnung
steht für die Bezeichnung des Knoten, so wie sie den Laufzeitkomponenten des Brokers bekannt ist. Wenn es sich um einen untergeordneten Nachrichtenfluss handelt, geht das aus der Bezeichnung hervor. Wenn beispielsweise Fluss A eine Instanz von Fluss B als untergeordneten Nachrichtenfluss mit der Bezeichnung myB enthält und Fluss B eine Instanz des Compute-Knotens mit der Bezeichnung myCompute,
dann lautet die Knotenbezeichnung für den Compute-Knoten myB.myCompute.
Im ausgegebenen Ereignis ist die Adresszeichenfolge für die Ereignisquelle im Attribut wmb:eventData/@wmb:eventSourceAddress
angegeben.
- Optional: Geben Sie im Element
p:eventPointDataQuery/p:eventIdentity/p:eventName den Namen an, unter dem
Ereignisse aus dieser Ereignisquelle erkennbar sein werden.
- Wenn der Ereignisname eine festgelegte Zeichenfolge ist, vervollständigen Sie das Attribut
p:eventName/@p:literal.
- Wenn der Ereignisname aus einem Feld der Nachricht extrahiert werden soll, vervollständigen Sie
das Attribut p:eventName/@p:queryText, indem Sie eine XPath-Abfrage angeben.
Im ausgegebenen Ereignis ist der Ereignisname im Attribut
wmb:eventPointData/wmb:eventIdentity/@wmb:eventName angegeben.
Wenn das Element p:eventName nicht übergeben wird, nimmt
@wmb:eventName im ausgegebenen Ereignis standardmäßig den Wert
@p:eventSourceAddress an.
- Optional: Vervollständigen Sie das Attribut
p:eventPointDataQuery/p:eventFilter/@p:queryText, indem Sie einen XPath-Ausdruck
angeben, um zu steuern, ob das Ereignis ausgegeben werden soll. Der Ausdruck muss wahr (Ereignis
wird ausgegeben) oder falsch (Ereignis wird nicht ausgegeben) sein. Der Ausdruck kann sich auf
Felder in der Nachrichtenbaumstruktur oder an anderer Stelle im Nachrichtenaufbau beziehen.
Wenn ein Ereignis kein eventFilter-Element enthält, wird das Ereignis immer ausgegeben.
Mithilfe dieser Funktion können Sie die Ereignisausgaben an Ihre Geschäftsanforderung anpassen, indem Sie Ereignisse ausfiltern, die bestimmten Regeln nicht
entsprechen. Auf diese Weise können Sie die Anzahl der ausgegebenen Ereignisse reduzieren und so
die Auslastung der Überwachungsanwendung verringern.
- Optional: Vervollständigen Sie das Element p:applicationDataQuery, wenn das
Ereignis ausgewählte Datenfelder, die aus der Nachricht extrahiert werden, enthalten wird. Sie
können beliebig viele Felder aus den Nachrichtendaten extrahieren und in das Ereignis einschließen. Es kann sich um einfache oder komplexe Felder handeln.
- Geben Sie für jedes einfache Datenfeld ein p:simpleContent-Element an:
- Vervollständigen Sie das Attribut p:simpleContent/p:valueQuery/@p:queryText,
indem Sie eine XPath-Abfrage angeben.
- Vervollständigen Sie die Attribute p:simpleContent/@p:name,
@p:namespace und @p:dataType. @p:dataType muss
den Wert boolean, date, dateTime,
decimal, duration, integer,
string oder time haben.
- Geben Sie für jedes komplexe Datenfeld ein p:complexContent-Element an:
- Vervollständigen Sie das Attribut
p:complexContent/p:payloadQuery/@p:queryText, indem Sie eine XPath-Abfrage angeben.
- Vervollständigen Sie die Attribute p:complexContent/@p:name und
@p:namespace.
Diese Funktion wird häufig zur Kommunikation
wichtiger Geschäftsdaten in einem Geschäftsereignis verwendet. Wenn das Ereignis den
Eingabebitstrom enthält, können mit dieser Funktion auch Schlüsselfelder extrahiert werden. Dies
gibt anderen Anwendungen die Möglichkeit, ein Prüfprotokoll bereitzustellen oder fehlgeschlagene
Nachrichten erneut zu übergeben.
Im ausgegebenen Ereignis sind die extrahierten Daten in den
Elementen wmb:applicationData/wmb:simpleContent und
wmb:applicationData/wmb:complexContent angegeben.
- Optional: Vervollständigen Sie das Element p:bitstreamDataQuery, wenn das
Ereignis Daten aus dem Nachrichtenbitstrom erfassen soll:
- Vervollständigen Sie das Attribut @p:bitstreamContent.
Das Attribut muss den
Wert headers, body oder all haben.
- Vervollständigen Sie das Attribut @p:encoding. Das Attribut muss den Wert
CDATA, base64Binary oder hexBinary haben.
Im ausgegebenen Ereignis sind die extrahierten Bitstromdaten im Element
wmb:bitstreamData/wmb:bitstream angegeben.
- Optional: Vervollständigen Sie das Element
p:eventPointDataQuery/p:eventCorrelation.
Weitere Informationen zur Korrelation finden Sie im Abschnitt Korrelation und Überwachungsereignisse.
Jedes ausgegebene Überwachungsereignis kann bis zu drei Korrelationsattribute enthalten.
Wenn im Überwachungsprofil keine Korrelationsinformationen angegeben sind, werden keine Korrelationsattribute verwendet.
- Optional: Vervollständigen Sie das Element p:localTransactionId.
- Wenn der lokale Korrelationswert aus der Umgebungsbaumstruktur wiederverwendet werden soll,
setzen Sie das Attribut p:localTransactionId/@p:sourceOfId auf
automatic. Falls noch kein lokaler Korrelationswert existiert, wird ein neuer
eindeutiger Wert generiert und in der Umgebungsbaumstruktur gespeichert.
- Wenn Sie einen Wert verwenden möchten, der an einer Position in der Nachricht enthalten ist,
setzen Sie das Attribut p:localTransactionId/@p:sourceOfId auf
query und vervollständigen Sie dann das Attribut
p:localTransactionId/@p:queryText, indem Sie eine XPath-Abfrage angeben. Stellen Sie sicher, dass die angegebene Position einen
Korrelationswert enthält, der für diesen Aufruf des Nachrichtenflusses eindeutig ist.
Der Wert wird in der Umgebungsbaumstruktur gespeichert.
- Optional: Vervollständigen Sie das Element p:parentTransactionId.
- Wenn der übergeordnete Korrelationswert aus der Umgebungsbaumstruktur wiederverwendet werden
soll, setzen Sie das Attribut p:parentTransactionId/@p:sourceOfId auf
automatic. Falls noch kein übergeordneter Korrelationswert existiert, wird kein
übergeordneter Korrelationswert verwendet.
- Wenn Sie einen Wert verwenden möchten, der an einer Position in der Nachricht enthalten ist,
setzen Sie das Attribut p:parentTransactionId/@p:sourceOfId auf
query und vervollständigen Sie dann das Attribut
p:parentTransactionId/@p:queryText, indem Sie eine XPath-Abfrage angeben. Stellen Sie sicher, dass die angegebene Position einen geeigneten
übergeordneten Korrelationswert enthält. Der Wert wird in der Umgebungsbaumstruktur gespeichert.
- Optional: Vervollständigen Sie das Element p:globalTransactionId.
- Wenn der globale Korrelationswert aus der Umgebungsbaumstruktur wiederverwendet werden soll,
setzen Sie das Attribut p:globalTransactionId/@p:sourceOfId auf
automatic. Falls noch kein globaler Korrelationswert existiert, wird kein globaler
Korrelationswert verwendet.
- Wenn Sie einen Wert verwenden möchten, der an einer Position in der Nachricht enthalten ist,
setzen Sie das Attribut p:globalTransactionId/@p:sourceOfId auf
query und vervollständigen Sie dann das Attribut
p:globalTransactionId/@p:queryText, indem Sie eine XPath-Abfrage angeben. Stellen Sie sicher, dass die angegebene Position einen geeigneten
globalen Korrelationswert enthält. Der Wert wird in der Umgebungsbaumstruktur gespeichert.
- Vervollständigen Sie das Element p:eventPointDataQuery/p:eventUOW.
Es legt fest, ob die Ausgabe von
Überwachungsereignissen durch einen Nachrichtenfluss mit der Nachrichtenflusstransaktion
koordiniert wird, in einer unabhängigen Arbeitseinheit erfolgt oder in keiner Arbeitseinheit
enthalten ist.
Setzen Sie das Attribut
p:eventUOW/@p:unitOfWork auf einen
der folgenden Werte:
- messageFlow
- Das Ereignis und alle anderen Ereignisse mit dieser Einstellung werden nur
ausgegeben, wenn der Nachrichtenfluss seine Arbeitseinheit erfolgreich festschreibt.
Wenn das
Transaktionsstartereignis in die Arbeitseinheit des Nachrichtenflusses eingeschlossen werden soll,
die Nachrichtenverarbeitung aber fehlschlägt und diese Arbeitseinheit nicht veröffentlicht wird,
wird das Transaktionsstartereignis in eine unabhängige Arbeitseinheit eingeschlossen. Dadurch wird
sichergestellt, dass Ihre Überwachungsanwendung ein Ereignispaar (Start und Rollback) empfängt und
kein isoliertes Rollback-Ereignis.
- independent
- Das Ereignis wird in einer zweiten Arbeitseinheit ausgegeben, die von der
Hauptarbeitseinheit unabhängig ist. Das Ereignis und alle anderen Ereignisse mit dieser Einstellung
werden unabhängig davon ausgegeben, ob die Hauptarbeitseinheit erfolgreich festgeschrieben wird.
Eine unabhängige Transaktion kann nur gestartet werden, wenn die Haupttransaktion entweder
festgeschrieben oder zurückgesetzt wurde.
Wenn die Eigenschaft
Festschreibungszähler des Nachrichtenflusses größer als 1 ist
(Konfigurierbare Nachrichtenflusseigenschaften) oder die Eigenschaft Festschreibung nach
Nachrichtengruppierung festgelegt ist (Nachrichten in einer WebSphere MQ-Nachrichtengruppierung empfangen), werden die für
die unabhängige Transaktion vorgesehenen Ereignisse stattdessen ohne Synchronisationspunkt
ausgegeben. Dies wird durch die Anzeige einer entsprechenden Nachricht bestätigt.
- none
- Das Ereignis wird ohne Synchronisationspunkt ausgegeben (nicht in einer
Arbeitseinheit). Das Ereignis wird ausgegeben, wenn die Nachricht die Ereignisquelle durchläuft
und kann sofort gelesen werden.
Nicht alle diese Optionen sind für alle Ereignistypen verfügbar. Die verfügbaren Werte sind in der folgenden Tabelle aufgeführt:
Ereignistyp |
Zulässige Werte |
transaction.Start |
- messageFlow
- independent
- none
|
transaction.End |
|
transaction.Rollback |
|
Terminal |
- messageFlow
- independent
- none
|
Wenn Sie das Element
eventUOW nicht für eine Ereignisquelle einfügen, wird die Transaktionalität
mit Ausnahme der Ereignisse des Typs 'transaction.rollback' für alle Ereignisse, die von der betreffenden Quelle ausgegeben werden, standardmäßig auf
messageFlow gesetzt.
Die Transaktionalität für Ereignisse des Typs 'transaction.rollback' nimmt standardmäßig den Wert
independent an.
XPath-Abfragen und XML-Namespaces
Wenn eine XPath-Abfrage eine
Komponente mit einem XML-Namespace enthält, enthält der XPath ein Namespace-Präfix für den
Namespace. Beispielsweise verweist der folgende XPath auf Komponenten in zwei verschiedenen
Namespaces:
<p:localTransactionId p:sourceOfId="query" p:queryText="$Body/soapenv:Header/wsa:messageID" />
Damit der Broker das Namespace-Präfix auflösen kann, muss auch die Namespace-URL übergeben
werden. Übergeben Sie für jeden Namespace ein Präfixzuordnungselement:
<p:localTransactionId p:sourceOfId="query" p:queryText="$Body/soapenv:Header/wsa:messageID">
<p:prefixMapping p:prefix="soapenv" p:URI="http://www.w3.org/2003/05/soap-envelope" />
<p:prefixMapping p:prefix="wsa" p:URI="http://www.w3.org/2005/08/addressing" />
</p:localTransactionId>
Beispiele für Überwachungsprofile
Die folgenden XML-Dokumente
entsprechen dem Überwachungsprofilschema:
Überwachungsprofil 1: Zwei Ereignisquellen, von
denen jede einen Ereignisnamen übergibt
<p:monitoringProfile p:version="2.0">
<p:eventSource p:eventSourceAddress="SOAPInput.transaction.Start">
<p:eventPointDataQuery>
<p:eventIdentity>
<p:eventName p:literal="SOAP start event"/>
</p:eventIdentity>
</p:eventPointDataQuery>
</p:eventSource>
<p:eventSource p:eventSourceAddress="SOAPInput.transaction.End">
<p:eventPointDataQuery>
<p:eventIdentity>
<p:eventName p:literal="SOAP end event"/>
</p:eventIdentity>
</p:eventPointDataQuery>
</p:eventSource>
</p:monitoringProfile>
Überwachungsprofil 2: Übergabe eines alternativen
lokalen Korrelationswerts<p:monitoringProfile p:version="2.0">
<p:eventSource p:eventSourceAddress="SOAPInput.transaction.Start">
<p:eventPointDataQuery>
<p:eventCorrelation>
<p:localTransactionId p:queryText="$Body/soapenv:Header/wsa:messageID" p:sourceOfId="query">
<p:prefixMapping p:prefix="soapenv" p:URI="http://www.w3.org/2003/05/soap-envelope"/>
<p:prefixMapping p:prefix="wsa" p:URI="http://www.w3.org/2005/08/addressing"/>
</p:localTransactionId>
</p:eventCorrelation>
</p:eventPointDataQuery>
</p:eventSource>
</p:monitoringProfile>
Überwachungsprofil 3: Einfügung von zwei einfachen
Feldern aus der Nachricht <p:monitoringProfile p:version="2.0">
<p:eventSource p:eventSourceAddress="MQInput.terminal.out">
<p:applicationDataQuery>
<p:simpleContent p:dataType="integer" p:name="InvoiceNumber">
<p:valueQuery p:queryText="$Body/invoice/invoiceNo"/>
</p:simpleContent>
<p:simpleContent p:dataType="string" p:name="BatchID">
<p:valueQuery p:queryText="$Body/batch/batchNo"/>
</p:simpleContent>
</p:applicationDataQuery>
</p:eventSource>
</p:monitoringProfile>
Überwachungsprofil 4: Einfügung des Bitstroms,
codiert als CDATAStandardmäßig werden Bitströme im base64Binary-Format codiert. Das
folgende Überwachungsprofil ändert die Codierung in CDATA.
<p:monitoringProfile p:version="2.0">
<p:eventSource p:eventSourceAddress="MQInput.terminal.out">
<p:bitstreamDataQuery p:bitstreamContent="body" p:encoding="CDATA"/>
</p:eventSource>
</p:monitoringProfile>
Die CDATA-Codierung ist nicht für alle
Datentypen eignet.
Verwenden Sie CDATA nur, wenn
@p:bitstreamContent="body" ist. Verwenden Sie CDATA nicht, wenn die Nachrichtenbitströme Zeichen enthalten können, die in XML nicht zulässig sind (siehe
http://www.w3.org/TR/2006/REC-xml-20060816/#charsets).