WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Überwachungsprofil

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

    1. 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.
    2. 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.
    3. 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.
  7. 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
    • messageFlow
    • none
    transaction.Rollback
    • independent
    • none
    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 CDATA
Standardmäß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).
Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:20:17


ReferenzthemaReferenzthema | Version 8.0.0.5 | ac37900_