Beim Füllen einer Warteschlange tritt ein Kommunikationsfehler auf
Szenario: Sie verwenden die Tools für die Einreihung und Entfernung von Nachrichten in bzw. aus Warteschlangen, doch es wird eine Fehlernachricht ausgegeben, die besagt, dass keine Kommunikation mit dem Warteschlangenmanager des betreffenden Namens möglich ist.
Erklärung: Der Warteschlangenmanager von WebSphere MQ wurde nicht gestartet.
Lösung: Starten Sie den Warteschlangenmanager von WebSphere MQ erneut.
Die Funktion zum Einreihen von Nachrichten in Warteschlangen übernimmt Änderungen, die an einer Nachricht vorgenommen wurden, nicht
Szenario: Sie verwenden die WebSphere Message
Broker Toolkit-Funktion zum Einreihen von Nachrichten in eine Warteschlange, um Nachrichten in WebSphere MQ-Warteschlangen einzureihen.
Sie habe eine Nachricht aktualisiert und möchten die Nachricht in eine Warteschlange einreihen, die Änderungen wurden aber scheinbar nicht übernommen.
Lösung:
Schließen Sie die Datei zur Einreihung in die Warteschlange und öffnen Sie sie anschließend erneut.
Wählen Sie die Nachricht aus, die Sie in die Warteschlange einreihen möchten.
Speichern und schließen Sie die Datei zur Warteschlangeneinreihung.
Wählen Sie das Menü neben dem Symbol Nachricht in Warteschlange einreihen aus.
Klicken Sie auf Nachricht einreihen.
Klicken Sie im Menü auf die Datei zur Warteschlangeneinreihung.
Klicken Sie auf Finish (Fertigstellen).
Daraufhin wird Ihre aktualisierte Nachricht in die Warteschlange eingereiht.
Sie wissen nicht, welche Headerelemente bei der Einreihung in Warteschlangen relevant sind
Szenario: Wenn Sie den Editor für die Einreihung in die Warteschlange verwenden, scheinen die Felder 'Account-Token', 'Korrelations-ID', 'Gruppen-ID' und 'Nachrichten-ID' im Nachrichtenheader das Verhalten nicht zu beeinflussen.
Erläuterung: Diese Felder wirken sich nicht auf das Verhalten aus, da sie nicht ordnungsgemäß serialisiert sind.
Nachrichtendateien für die Warteschlangeneinreihung werden auch nach dem Löschen noch aufgeführt
Szenario: Nachrichtendateien für die Warteschlangeneinreihung werden auch nach dem Löschen noch im Menü aufgeführt.
Erläuterung: Gelöschte Dateien für die Warteschlangeneinreihung werden nicht aus dem Menü entfernt. Bei Auswahl dieser Dateien passiert nichts.
Die ESQL-Umsetzung einer XML-Nachricht liefert unerwartete Ergebnissen
Szenario: Sie haben eine XML-Nachricht erstellt, die etwa folgendermaßen aussieht:
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]><doc><I1>100</I1></doc>
Sie wenden die ESQL-Umwandlung an:
SET OutputRoot.XMLNS.doc.I1 = 112233;
Nach der seriellen Anordnung wird folgende XML-Nachricht generiert:
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]<I1>112233<I1>><doc><I1>100</I1></doc>
Der neue Wert für I1 wurde in DOCTYPE eingefügt und hat nicht wie erwartet den Wert 100 ersetzt.
Erläuterung: In der XML Ihrer Nachricht sind zwei doc-Elemente vorhanden:
Das Element doctype
Das xmlElement, das den Hauptteil der Nachricht darstellt
Der Parser hat die erste Instanz eines Elements mit dem Namen doc gefunden und hat ein untergeordnetes Element I1 mit dem Wert 112233 erstellt.
Lösung: Um dem Element I1 im Nachrichtentextelement doc einen neuen Wert zuzuweisen, ist das zweite doc-Element explizit zu identifizieren. Vorgehensweise:
SET OutputRoot.XMLNS.(XML.tag)doc.I1 = 112233;
Bei einer XML-Nachricht gehen Wagenrücklaufzeichen verloren
Szenario: Sie führen eine Syntaxanalyse für eine Eingabe-XML-Nachricht aus, die Wagenrücklauf- oder Zeilenvorschubzeichen enthält, oder Sie schreiben eine Ausgabe-XML-Nachricht, die Wagenrücklauf- oder Zeilenvorschubzeichen in einem XML-Element enthält. Allerdings fehlen einige oder alle Rücklaufzeichen in der Ausgabenachricht.
Erläuterung: Dieses Verhalten ist korrekt (wie von der XML-Spezifikation beschrieben) und tritt in XML-, XMLNS- oder XMLNSC-Domänen auf.
In XML ist das Trennzeichen der Hauptzeile ein Zeilenvorschubzeichen. Rücklaufzeichen werden in einem XML-Dokument akzeptiert, von einem XML-Parser werden jedoch alle Wagenrücklauf- plus Zeilenvorschubzeichen in ein einzelnes Zeilenvorschubzeichen normalisiert. Weitere Informationen hierzu finden Sie in der neuesten XML-Spezifikation unter Extensible Markup Language (XML), insbesondere in Abschnitt 2.11 (Behandlung des Zeilenendes).
Dieses Problem kann nicht umgangen werden kann, indem Sie Ihre Daten in einen CDATA-Abschnitt einbetten; laut der XML-Spezifikation ist ein CDATA-Abschnitt nur dazu bestimmt, Textblöcke zu verlassen, die Zeichen enthalten, die als Markup-Formatierung interpretiert werden könnten. Zudem sind CDATA-Abschnitte nicht vor dem Parser geschützt.
Das xml:space-Attribut kann nicht verwendet werden, um Wagenrücklauf- plus Zeilenvorschubzeichen beizubehalten; laut der XML-Spezifikation wird die Normalisierung der Wagenrücklauf- und Zeilenvorschubzeichen durchgeführt, bevor eine andere Verarbeitung vorgenommen wird.
Lösung: XML-konforme Daten dürfen sich nicht auf das Vorhandensein von Wagenrücklauf- plus Zeilenvorschubzeichen verlassen, da in XML das Zeilenvorschubzeichen ausschließlich ein Zeilenvorschubzeichen ist und XML-konforme Anwendungen oder Daten berücksichtigen müssen, dass alle Wagenrücklauf- plus Zeilenvorschubzeichen vom Parser normalisiert werden.
Der Broker kann die XML-Nachricht syntaktisch nicht analysieren
Szenario: Sie erhalten eine große XML-Datei und leiten sie in einem SOAP-Umschlag an einen .NET-Webservice weiter. Der Broker kann die XML-Nachricht syntaktisch nicht analysieren.
Erläuterung: Die Nachricht, die Sie erhalten, ist als UTF-8 definiert, enthält jedoch UTF-16-Zeichen wie beispielsweise £. Diese Zeichen führen zu einem Problem mit dem Parser; der Broker kann die XML-Nachricht syntaktisch nicht analysieren, da sie ein ungültiges Zeichen enthält.
Lösung: Zwingen Sie die ID des codierten Zeichensatzes (CCSID) auf den Wert 1208 anstatt auf den Standardwert 437.
Bei Verwendung des XSLTransform-Knotens unter z/OS
Szenario: Bei Verwendung des XSLTransform-Knotens unter z/OS wird der Großbuchstabe O in einer XML-Datei in der ankommenden Nachricht immer in einen Unterstrich geändert.
Erläuterung: Die Eingabenachricht im XSLTransform-Knoten muss im ASCII-Format eingehen, damit die Umwandlung richtig funktionieren kann. Der XSLTransform-Knoten funktioniert nicht mit XML- oder XSL-Daten in EBCDIC. Java™geht von einer Konversion aus EBCDIC 1047 aus. WebSphere Message
Broker konvertiert anschließend in EBCDIC 500, weil die ID des codierten Zeichensatzes (CCSID) auf 500 gesetzt ist. EBCDIC 1047 und
EBCDIC 500 sind ähnlich.
Nur die Zeichen O, J und Z in Großschreibung unterscheiden
sich. (J und Z werden ebenfalls falsch konvertiert). Durch die Konvertierung bleibt eine unleserliche
Zeichenfolge zurück, da sie tatsächlich in ASCII ist. Das O wird jedoch nicht von einem EBCDIC 1047-Zeichen in ein EBCDIC 500-Zeichen konvertiert.
Lösung: Ändern Sie Ihr Programm entweder so, dass es eine Zeichenfolgen-Zuweisung ohne irgendwelche Konversionen vornimmt, oder geben Sie an, dass die Zeichenfolge in ASCII ISO-8859-1 (CCSID 819) steht.
Vom XMLNS-Parser wird Fehlernachricht BIP5004 ausgegeben
Szenario: Fehlernachricht BIP5004 wird ausgegeben, die anzeigt, dass der XMLNS-Parser Probleme mit einer XML-Eingabenachricht hat.
Erläuterung: Hier können verschiedene Gründe vorliegen. Im Folgenden sind einige der Szenarien aufgelistet, die häufig zur Ausgabe dieser Nachricht führen:
Sie haben ein ungültiges XML-Zeichen in der XML-Eingabenachricht angegeben.
Ihre XML-Nachricht enthält binäre Daten, die ungültig sind, wenn sie als Zeichendaten behandelt werden.
Die Nachricht wurde als Teil einer WebSphere MQ-Nachricht empfangen und der XML-Textbitstrom wird durch die MQMD.CodedCharSetId nicht korrekt wiedergegeben.
Sie haben Zeichen verwendet, die als Markup erkannt werden.
Lösung:
Stellen Sie sicher, dass von der Senderanwendung nur gültige Daten gesendet werden.
Wenn ungültige Zeichen in der XML-Nachricht nicht vermieden werden können, sollten Sie diese in der BLOB-Domäne wiedergeben und die ungültigen Zeichen unter Verwendung der REPLACE-Funktion in ESQL ersetzen bzw. entfernen.
Anschließend können Sie den modifizierten Bitstrom zum erforderlichen Parser zuordnen.
Entsprechend der XML-Spezifikation können Sie einen CDATA-Abschnitt verwenden, um Zeichen zu schützen, die ansonsten als Markup interpretiert würden. Er kann nicht verwendet werden, um ungültige Zeichen oder Binärdaten aus dem XML-Parser zu schützen.
Wenn die XML-Eingabenachricht Binärdaten enthält, müssen Sie sicherstellen, dass die sendende Anwendung so geändert wird, dass diese Daten als codierte Basisbinärdaten wiedergeben werden. Wenn die Anwendung nicht geändert werden kann, muss die Nachricht in der BLOB-Domäne wiedergegeben werden und die Binärdaten müssen extrahiert und ersetzt werden, bevor der Bitstrom zum erforderlichen Parser zugeordnet wird.
Stellen Sie sicher, dass die Wiedergabe der empfangenen XML-Nachricht über die korrekte MQMD.CodedCharSetId erfolgt.
Vom MRM-Parser wird Fehlernachricht BIP5378 ausgegeben
Szenario: Fehlernachricht BIP5378 wird ausgegeben, die
besagt, dass ein Problem aufgetreten ist, weil ein obligatorisches sich wiederholendes
Element in einer MRM-Nachricht fehlt.
Erläuterung: Diese Nachricht gibt an, dass ein obligatorisches sich
wiederholendes Element in der Nachricht nicht vorhanden ist. In früheren Releases wurde diese Bedingung durch die Fehlernachricht
BIP5374 angegeben, die jetzt jedoch nur noch ausgegeben wird, wenn
ein obligatorisches sich wiederholendes Element in der Nachricht zwar vorhanden ist,
aber in einer falschen Anzahl von Instanzen auftritt.
Wenn Sie automatisierte Fehlerprüfungsroutinen programmiert haben, überprüfen und ändern Sie diese
bei Bedarf.
Lösung: Überprüfen Sie die Nachrichtendefinition, um sicherzugehen, dass das Element
tatsächlich obligatorisch und sich wiederholend sein muss. In der Fehlernachricht sind
die Elemente angegeben, die vor und nach der erwarteten Position des fehlenden Elements
stehen. Wenn die Definition korrekt ist, wurde die Nachricht von der sendenden Anwendung
nicht ordnungsgemäß erstellt. Dieser Fehler muss behoben werden.
Vom Compute-Knoten wird Fehlernachricht BIP5005 ausgegeben
Szenario: Sie senden eine einfache XML-Nachricht in einen einfachen Nachrichtenfluss. Die Nachricht lautet folgendermaßen:
<doc><I1>100</I1></doc>
Der Compute-Knoten im Nachrichtenfluss enthält folgenden ESQL-Code:
SET OutputRoot.XMLNS.abc = InputBody;
Sie erwarten die Erstellung der folgenden Ausgabenachricht:
<abc><doc><I1>100</I1></doc></abc>
Der Compute-Knoten generiert die Fehlernachricht BIP5005 und implementiert den ESQL-Code nicht.
Erläuterung: Sie verweisen ein Element eines Typs (root)
einem Element eines anderen Typs (xmlElement) zu.
Der Parser führt diese implizite Umwandlung nicht durch.
Lösung: Sie können die Umsetzung selbst im ESQL-Code ausführen, um das gewünschte Ergebnis zu erzielen, indem Sie einen der beiden folgenden Umsetzungsausdrücke verwenden:
SET OutputRoot.XMLNS.(XML.Element)abc = InputBody;
oder:
SET OutputRoot.XMLNS.(XML.tag)abc = InputBody;
An das Fehlerterminal (Failure) eines
TimeoutControl-Knotens wird eine Nachricht weitergegeben.
Szenario: Der TimeoutControl-Knoten erhält
eine Nachricht mit ungültigen, beschädigten oder fehlenden Zeitlimitinformation. Die Nachricht wird
an das Fehlerterminal (Failure) des
TimeoutControl-Knotens weitergegeben und es wird eine
Ausnahmebedingungsliste generiert.
Erläuterung: Durch die folgenden Fehlerbedingungen kann eine Weitergabe an das
Fehlerterminal (Failure) verursacht werden:
Für eine Zeitlimitanforderung ist keine Aktion oder ID vorhanden.
In einer Zuordnungsanforderung ist eine ID enthalten, die mit einer vorhandenen und gespeicherten Zuordnungsanforderung für diesen TimeoutControl-Knoten (gekennzeichnet durch das Merkmal 'Unique Identifier' (eindeutige ID) übereinstimmt, und die Funktion, die ein Überschreiben der ursprünglichen Anforderung zulässt, wurde auf FALSE gesetzt.
In einer Anforderung zum Abbruch ist eine ID enthalten, die nicht mit einer vorhandenen und gespeicherten Zuordnungsanforderung für diesen TimeoutControl-Knoten übereinstimmt (gekennzeichnet durch das Merkmal 'Unique Identifier' (eindeutige ID).
Eine Zuordnungsanforderung hat einen Zähler 0 oder ist kleiner als -1.
Das Startdatum oder die Startzeit haben nicht das korrekte Format (oder eines der gültigen Schlüsselwörter).
Das berechnete Zeitlimit befindet sich in der Vergangenheit.
Das Intervall ist kleiner als 0, oder 0 oder mit einem Zähler von -1.
Lösung: Prüfen Sie, ob eine oder mehrere der hier aufgeführten Fehlerbedingungen zutreffen, und korrigieren Sie diese.
Die Nachrichtenverarbeitung in einem TimeoutNotification-Knoten schlägt fehl
Szenario: An das Fehlerterminal (Failure) oder das Catch-Terminal eines TimeoutNotification-Knotens wird eine Nachricht weitergegeben.
Erläuterung: Wenn bei der Verarbeitung eines Zeitlimits im
TimeoutNotification-Knoten ein Fehler auftritt, wird
eine Ausnahmebedingungsliste generiert und eine Nachricht an das Fehlerterminal (Failure)
weitergegeben. Bei Verwendung einer Transaktion wird dieser Vorgang in einer einzigen Transaktion
ausgeführt. Besteht keine Verbindung zum Fehlerterminal (Failure), erfolgt keine Weitergabe.
Wenn hinter einem TimeoutNotification-Knoten nach
einer erfolgreichen Weitergabe an das Ausgabeterminal oder Fehlerterminal (Failure) ein
Fehler auftritt, wird die Nachricht (in der gleichen Transaktion) an das Catch-Terminal
weitergegeben. Besteht keine Verbindung zum Catch-Terminal oder schlägt die Weitergabe über den
Abfangdatenfluss fehl, wird die Verarbeitung dieses Zeitlimits rückgängig gemacht.
Lösung: Vergewissern Sie sich, dass das Fehlerterminal (Failure) und das Catch-Terminal
Ihres TimeoutNotification-Knotens korrekt verbunden
wurden.
Eine MRM-CWF-Nachricht wurde an das Fehlerterminal (Failure) weitergegeben
Szenario: Ihre MRM-CWF-Nachricht wird an ein Fehlerterminal (Failure) weitergegeben und
generiert die Fehlernachrichten BIP5285, BIP5125 und
BIP5181 oder die Nachrichten BIP5285, BIP5125
und BIP5288.
Erläuterung: Diese Fehler melden eine Inkonsistenz zwischen der Länge der Nachricht, die verarbeitet wird, und der Länge der Nachricht, die im Nachrichtenmodell definiert ist.
Lösung: Stellen Sie sicher, dass die Länge der in der CWF-Schicht definierten Nachricht korrekt ist. Überprüfen und korrigieren Sie die Definition.
Probleme mit XML-Attributen
XML-Tags werden geschrieben, obwohl XML-Attribute erwartet werden und umgekehrt.
Erläuterung: Die XML-Domänen und das XML-Wire-Format in der MRM-Domäne verfügen über eine eigene Darstellung von XML-Attributen.
In XML-Domänen muss der Feldtyp 'XML.Attribute' in der Nachrichtenbaumstruktur gesetzt werden, da es kein Modell für die syntaktische Analyse gibt.
Beim XML-Wire-Format in der MRM-Domäne gibt das Nachrichtenmodell an, ob es sich bei dem Element um ein Attribut oder einen Tag handelt. Aus diesem Grund muss in der Nachrichtenbaumstruktur nicht angegeben sein, ob es sich bei einem Feld um ein Attribut oder einen Tag handelt.
Wenn also Felder aus den XMLNS oder MRM-Domänen kopiert werden, gehen die Informationen darüber, ob es sich bei Feldern um Attribute handelt, verloren. Zu diesem Verlust kommt es, wenn die Felder in die jeweils andere Domäne bzw. in eine andere Nachrichtenbaumstruktur wie z. B. die Umgebungsbaumstruktur kopiert werden.
Dieses Problem tritt normalerweise in den folgenden Situationen auf:
Szenario 1: Sie schreiben eine XML-Nachricht in die MRM-Domäne und anstelle von XML-Attributen werden XML-Tags geschrieben.
Lösung 1: Stellen Sie sicher, dass Ihre Nachrichtenbaumstruktur der Struktur und Reihenfolge des Nachrichtenmodells entspricht. Wenn die Nachrichtenbaumstruktur nicht mit dem Nachrichtenmodell übereinstimmt, wird das Feld als selbstdefinierend geschrieben und deshalb wird die Eigenschaft 'XML Render' nicht verwendet.
Aktivieren Sie die Nachrichtenprüfung. Über die Prüffunktion werden die Stellen identifiziert, an denen die Nachrichtenbaumstruktur nicht mit der Nachrichtendefinition übereinstimmt.
Alternativ können Sie einen Benutzer-Debug-Trace für den Nachrichtenfluss verwenden; BIP5493W-Nachrichten zeigen an, welche Felder als selbstdefinierend geschrieben werden. Mit diesen Informationen können Sie sicherstellen, dass die Nachrichtenbaumstruktur mit dem Modell übereinstimmt. Wenn Sie etwaige Diskrepanzen korrigiert haben, werden die Attribute korrekt geschrieben.
Szenario 2: Eine MRM-Nachricht wurde in eine XML-Domäne kopiert und die XMLNS-Attribute werden jetzt als Tags geschrieben.
Lösung 2: Führen Sie einen der folgenden Vorgänge aus:
Serialisieren Sie die XML-Nachricht in der MRM-Domäne, indem Sie beispielsweise die ESQL-Funktion ASBITSTREAM verwenden. Verwenden Sie anschließend die ESQL-Klausel CREATE PARSE, um die Nachricht unter Verwendung der erforderlichen XML-Domäne erneut syntaktisch zu analysieren.
Wenn Sie Felder zwischen der MRM-Domäne und XMLNS kopieren, kopieren Sie die Attributfelder einzeln, und geben Sie insbesondere XML.Attribute im XML-Zielfeld an.
Szenario 3: Eine XML-Nachricht wurde in eine andere Nachrichtenbaumstruktur wie z. B. die Umgebungsbaumstruktur kopiert. Wenn die Nachricht wieder zurück in die XML-Nachrichtenbaumstruktur kopiert wird, werden XML-Attribute als XML-Tags angezeigt.
Lösung 3: Serialisieren Sie die XML-Nachricht, indem Sie beispielsweise die ESQL-Funktion ASBITSTREAM verwenden. Verwenden Sie anschließend die ESQL-Klausel CREATE PARSE, um die XML-Nachricht in der erforderlichen Zielbaumstruktur erneut syntaktisch zu analysieren. Ein Beispiel finden Sie unter CREATE-Anweisung.
Szenario 4: Ein Teil einer Nachricht, die kein XML-Format aufweist, wurde abgehängt und zu einer XML-Baumstruktur hinzugefügt, und XML-Tags werden jetzt als XML-Attribute angezeigt.
Lösung 4: Sie dürfen Teile von Nachrichtenbaumstrukturen, die zu unterschiedlichen Parsern gehören, nicht abhängen und hinzufügen. Verwenden Sie anstatt dessen eine Baumstrukturkopie.
Szenario 5: Ein XML-Tag wird in ein XML-Attribut kopiert und das XML-Attribut wird nicht in die Ausgabenachricht geschrieben.
Lösung 5: Wenn Sie einen Verweis auf einen XML-Quellentag erstellen, verwenden Sie die ESQL-Funktion FIELDVALUE, um den entsprechenden Feldwert in das XML-Zielattributfeld zu kopieren.
Eine MRM-XML-Nachricht zeigt nicht erwartetes Verhalten
Szenario: Ihr Nachrichtenfluss verarbeitet eine Nachricht, die Sie im MRM modelliert haben. Die Nachrichtenbaumstruktur wurde nicht wie erwartet erstellt, die XML-Ausgabenachricht hat nicht den erwarteten Inhalt, oder der Nachrichteninhalt wird nicht validiert. Es wurde keine Fehlernachricht ausgegeben.
Erläuterung: Dieses Problem kann zwei Ursachen haben:
Erläuterung 1: In den Einstellungen des physischen XML-Formats für eine Nachrichtengruppe ist eine Eigenschaft mit der Bezeichnung 'Kennung der höchsten Ebene - Name' enthalten. Der Standardwert lautet 'MRM', um die Kompatibilität mit früheren Releases des Produkts zu gewährleisten. Wenn Sie den Inhalt dieses Feldes nicht gelöscht haben, erwartet der MRM-XMLNS-Parser, dass die Kennung der höchsten Ebene für alle XML-Nachrichten MRM ist.
Lösung 1: Löschen Sie den Inhalt dieses Feldes, oder legen Sie als Wert die Kennung der höchsten Ebene fest, die von allen XML-Nachrichten verwendet wird. Wenn Sie in diesem Feld einen Wert bereitstellen, muss für die Kennung der höchsten Ebene nicht in allen Nachrichtendefinitionen ein Modell erstellt werden.
Erläuterung 2: Um abwärtskompatibel zu bleiben, erkennt der Broker das Format XML und ruft den XMLNS-Parser mit bestimmten Standardwerten auf. Wenn Sie für diese Nachricht eine physische XML-Schicht mit dem Namen XML erstellt haben, verwendet der Broker Ihre Definition.
Wenn Sie jedoch keine physische XML-Schicht mit diesem Namen erstellt haben, sondern XMLNS als Format im Empfangsknoten oder im MQRFH2-Header angegeben haben (wenn der Eingabebitstrom in eine Nachrichtenbaumstruktur ausgewertet wird), akzeptiert der Broker den angegebenen Wert und übergibt Standardwerte an den Parser, um die Nachrichtenbaumstruktur zu erstellen.
Genauso wird bei Festlegung von XML im Ordner 'Eigenschaften' für die Ausgabenachricht im Compute-Knoten dieser Wert an den Parser weitergegeben, wenn der Nachrichtenbitstrom aus der Nachrichtenbaumstruktur erstellt wird, eine Aktion, die normalerweise im Sendeknoten erfolgt.
Die Verwendung dieser Standardwerte durch den Parser kann entweder für die Nachrichtenbaumstruktur oder die Ausgabenachricht zu unterschiedlichen Inhalten, Strukturen oder beidem führen. Weitere Informationen zu der Brokeraktion finden Sie im Protokoll des Benutzertrace. Dort finden Sie beispielsweise die folgenden Informationen:
XMLWorker::initializeParse file:C:\s000\src\cpi\pwf\xml\xmlworker.cpp
line:126 message:5409.BIPmsgs
No dictionary present have you specified Wire Format 'XML' in error? ,
UserTrace BIP5409E: XML-Worker: Physisches Format 'XML' angegeben. Die standardmäßigen MRM XML-Einstellungen werden verwendet, weil die ID
'XML' für das physische Format angegeben aber nicht gefunden wurde.
Die Ursache dafür kann eine falsche Einstellung der ID für das
physische Format in einer Nachricht sein.
Lösung
2: Falls sie die ID für das von Ihnen definierte Format falsch eingegeben haben, korrigieren Sie den
Code und wiederholen Sie den Vorgang. Wenn die Standardaktion nicht ausgeführt werden soll, definieren Sie eine physische Schicht, die die erforderlichen Ergebnisse erzeugt.
Der MRM-Parser konnte eine Nachricht nicht syntaktisch analysieren, weil zwei Attribute denselben Namen haben
Szenario: Zwei Attribute in verschiedenen Namespaces haben denselben Namen. Die Fehlernachricht BIP5117 wird ausgegeben.
Erläuterung: Der MRM-Parser hat die Nachricht nicht syntaktisch analysieren können.
Lösung: Ändern Sie die Attributnamen so, dass sie nicht mehr identisch sind. Hier handelt es sich um eine bekannte Parsereinschränkung.
Bei Nachrichten mit EBCDIC-Zeilenvorschubzeichen treten Probleme auf
Szenario: Wenn in Ihrer Bitstromeingabenachricht EBCDIC-NL-Zeichen (Zeilenvorschubzeichen) enthalten sind, treten möglicherweise Probleme auf, wenn in Ihrem Nachrichtenfluss die Ziel-CCSID (ID des codierten Zeichensatzes) in eine ASCII-CCSID geändert wird. Bei der Konvertierung von CCSID 1047 (EBCDIC für z/OS Open Edition) in CCSID 437 (US PC ASCII) wird beispielsweise ein Zeilenvorschubzeichen vom Hexadezimalwert '15' in den Hexadezimalwert '7F' konvertiert, der ein nicht definiertes Zeichen ist. Dies ist darauf zurückzuführen, dass es in der ASCII-Codepage keinen entsprechenden Codepunkt für das Zeilenvorschubzeichen gibt.
Lösung: In den folgenden Fällen kann das Problem umgangen werden:
In einem System, in dem der Warteschlangenmanager einen codierten ASCII-Zeichensatz verwendet, ist sicherzustellen, dass ankommende Nachrichten keine EBCDIC-Zeilenvorschubzeichen enthalten:
Geben Sie an, dass WebSphere MQ die Konvertierung am Empfangsknoten ausführt.
Legen Sie das Warteschlangenmanager-Attribut zur Konvertierung von NL in Zeilenvorschub (LF) fest
Wenn es sich bei dem Eingabebitstrom um Zeichendaten handelt, können Sie in einem Compute-Knoten MRM-Nachrichtengruppen mit Kennung/mit Begrenzer verwenden, um das Zeilenvorschubzeichen durch die erforderliche Ausgabe zu ersetzen.
Im MIME-Parser tritt beim Parsen einer Nachricht ein Laufzeitfehler auf
Szenario: Ein Nachrichtenfluss empfängt eine MIME-Nachricht und beim Parsen dieser Nachricht kommt es zu einem Laufzeitfehler.
Erläuterung: Die folgenden Fehler können dazu führen, dass der MIME-Parser eine Nachricht zurückweist:
Der MIME-Header ist nicht korrekt formatiert.
Der äußerste MIME-Headerblock oder ein MIME-Headerblock für einen eingebetteten mehrteiligen Teil hat keinen gültigen Inhaltstyp-Header.
Der äußerste Inhaltstyp hat den Medientyp message.
Der äußerste Inhaltstyp hat den Medientyp multipart und keine Grenzdefinition.
Ein MIME-Headerblock ist nicht korrekt mit einer Leerzeile abgeschlossen.
Die einzelnen MIME-Bestandteile sind nicht korrekt durch begrenzende Zeilen voneinander abgesetzt.
Ein Grenzparameterwert steht im Inhalt eines MIME-Teils.
Lösung: Prüfen Sie die MIME-Nachricht, ob eine oder mehrere der hier aufgeführten Fehlerbedingungen zutreffen, und korrigieren Sie diese.
Beim Schreiben einer MIME-Nachricht aus der logischen Nachrichtenbaumstruktur erhalten Sie Laufzeitfehler
Szenario: Sie schreiben eine logische Nachrichtenbaumstruktur für eine MIME-Nachricht als Bitstrom aus und der Parser generiert einen Laufzeitfehler.
Erläuterung: Die folgenden Fehler können dazu führen, dass der MIME-Parser eine logische Nachrichtenbaumstruktur zurückweist:
Der Root der Baumstruktur heißt nicht MIME.
Das letzte untergeordnete Element von MIME heißt nicht 'Parts' oder 'Data'.
Das Element 'Parts' hat ein nur Werte enthaltendes Element und dieses Element ist nicht erstes oder letztes untergeordnetes Element von 'Parts'.
Das Element 'Parts' hat untergeordnete Elemente, die keine nur Werte enthaltenden Elemente oder untergeordneten 'Part'-Elemente sind.
Das Element 'Parts' hat keine untergeordneten Elemente, die 'Part' heißen.
Das letzte untergeordnete Element eines 'Data'-Elements ist kein BLOB.
Lösung: Prüfen Sie die logische MIME-Nachrichtenbaumstruktur, ob eine oder mehrere der hier aufgeführten Fehlerbedingungen zutreffen, und korrigieren Sie diese.
Nachrichtenhauptteil in Ausgabenachricht ist leer
Szenario: Der Nachrichtenteil ist unerwarteterweise leer, bzw. die ASBITSTREAM-Funktion hat ein BLOB mit der Länge 0 erzeugt.
Erläuterung: Dies kann aus einem der folgenden Gründe geschehen:
Sie haben einen Nachrichtenbaumstrukturordner in einem benutzerdefinierten Knoten erstellt, jedoch keinen Eignerparser zugeordnet. Der Nachrichtenbaumstruktur wird kein Eignerparser zugeordnet, wenn Sie Standardelemente unter Verwendung des folgenden Codes erstellt haben:
Sie haben eine Nachrichtenbaumstruktur unter Verwendung der ESQL-Anweisung CREATE erstellt, jedoch keinen Eignerparser festgelegt. Möglicherweise haben Sie folgenden Code verwendet:
CALL CopyMessageHeaders();
DECLARE outRef REFERENCE TO OutputRoot;
CREATE LASTCHILD OF outRef AS outRef NAME 'BLOB';
CREATE LASTCHILD OF outRef NAME 'BLOB' VALUE X'01';
oder
es wurde die Referenzvariable outRef an eine ESQL-Funktion oder -Prozedur übergeben, die ähnliche CREATE-Anweisungen enthielt. Es wurde kein Eignerparser mithilfe der DOMAIN-Klausel in der CREATE-Anweisung angegeben.
Eine MRM-Nachrichtenbaumstruktur wurde erstellt und anschließend wurde nur ein Teil davon durch Angabe eines Unterordners bzw. Felds an die ASBITSTREAM-Funktion übergeben. Der Parsermodus wurde auf 'RootBitStream' gesetzt. Diese Kombination ist ungültig und hat ein BLOB mit der Länge 0 zur Folge.
Sie habe eine Nachrichtenbaumstruktur oder einen Teil einer Nachrichtenbaumstruktur in einen Ordner kopiert und die Zuordnung des Eignerparsers wird nicht beibehalten.
Lösung: Abhängig von den Ursachen für den leeren Nachrichtenhauptteil bzw. ein BLOB mit der Länge 0 müssen Sie Folgendes sicherstellen:
Wenn Sie einen Nachrichtenbaumstrukturordner in einem benutzerdefinierten Knoten erstellen, müssen Sie dieser einen Eignerparser zuordnen. Verwenden Sie dazu beispielsweise folgenden Code:
Wenn Sie die ESQL-Anweisung CREATE zum Erstellen eines Nachrichtenbaumstrukturordners verwenden, verwenden Sie die DOMAIN-Klausel zum Zuordnen eines Eignerparsers zur Nachrichtenbaumstruktur. Beispiel:
CALL CopyMessageHeaders();
DECLARE outRef REFERENCE TO OutputRoot;
CREATE LASTCHILD OF outRef AS outRef DOMAIN 'BLOB' NAME 'BLOB';
CREATE LASTCHILD OF outRef NAME 'BLOB' VALUE X'01';
Mit diesem Code erstellen Sie einen BLOB-Ordner, dem der BLOB-Parser zugeordnet ist.
Stellen Sie beim Kopieren einer Nachrichtenbaumstruktur oder eines Teils einer Nachrichtenbaumstruktur sicher, dass die Zuordnung des Eignerparsers beibehalten wird, indem Sie zunächst eine Serialisierung ausführen und anschließend die Nachricht in der entsprechenden Nachrichtenbaumstruktur erneut syntaktisch analysieren. Ein Beispielszenario ist die Erstellung eines Felds:
SET Environment.Variables.myMsg = InputRoot.XMLNS;
Jetzt muss die Übergabe an die ASBITSTREAM-Funktion erfolgen. Sie müssen beispielsweise folgenden ESQL-Code verwenden:
Als Ergebnis wird ein Bitstrom der Länge null erzeugt.
Ausgabenachricht hat laut Fehlernachricht BIP5005, BIP5016 oder BIP5017 einen ungültigen Nachrichtenhauptteil
Szenario: Sie sind unerwarteterweise auf einen Nachrichtenhauptteil mit mehreren Stammverzeichnissen oder eine Nachricht ohne Stammverzeichnis gestoßen.
Erläuterung: Dieser Fehler kann auftreten, wenn Sie auf eine der folgenden Arten einen XML-Nachrichtenbaumstrukturordner mit mehreren Stammverzeichnissen oder ohne Stammverzeichnis erstellt haben:
Verwendung eines benutzerdefinierten Knotens
Verwendung eines MQGet-Knotens
Verwendung von ESQL
Lösung: Stellen Sie sicher, dass die endgültige Baumstruktur der Ausgabenachricht nur einen einzigen XML-Stammknoten aufweist.
Beim Empfang einer SOAP-Nachricht mit Anhängen von einem WebSphere Application
Server-Client wird Fehlernachricht BIP5651 ausgegeben
Szenario: Wenn ein WebSphere Application
Server-Client eine SOAP-Nachricht mit Anhängen über JMS an den Broker schickt, wird Fehlernachricht BIP5651 ausgegeben, die besagt, das kein gültiger Inhaltstyp-Header gefunden wurde.
Erläuterung: Wenn ein WebSphere Application
Server-Client eine SOAP-Nachricht mit Anhängen über JMS an den Broker schickt, erscheint der MIME-Inhaltstyp-Wert im MQRFH2-Header und nicht im Hauptteil der MIME-Nachricht.
Lösung: Um dieses Problem zu lösen, muss der Inhaltstyp-Wert vom MQRFH2-Header als MIME-Header an den Anfang der Nachricht kopiert werden, bevor die Nachricht syntaktisch analysiert wird. Der folgende ESQL-Code fügt den Inhaltstyp-Wert am Anfang der WebSphere Application
Server-Nachricht hinzu und ruft anschließend auf dem Ergebnis den MIME-Parser auf.
create procedure parseWAS_JMS(IN InputMessage reference,IN OutputMessage reference)
/***********************************************************************
* WAS/JMS-Nachricht in korrektes Format für den MIME-Parser konvertieren
***********************************************************************/
begin
-- die Daten als BLOB holen
declare body BLOB InputMessage.BLOB.BLOB;
-- den Inhaltstyp-Wert aus dem RFH2-Header holen; der Inhaltstyp (Content-Type) -- ist der einzige Header, auf den es für den MIME-Parser ankommt, aber der gleiche -- Ansatz kann für beliebige unter dem RFH2-Header gespeicherte MIME-Header -- angewandt werden.
declare contentType char InputMessage.MQRFH2.usr.contentType;
-- den contentType als Bestandteil eines RFC822-Headerblocks zum Bitstrom
-- hinzufügen
set body = cast(('Content-Type: '||contentType) as blob ccsid 819)||x'0d0a0d0a'||body;
-- MIME-Parser auf dem modifizierten Bitstrom aufrufen
CREATE LASTCHILD OF OutputMessage DOMAIN('MIME') PARSE(body);
end;
Ein Nachrichtenfluss kann die JMS-Nachricht in die BLOB-Domäne aufnehmen und die hier aufgeführte Prozedur von einem Compute-Knoten aus aufrufen.
Zum Aufruf der Prozedur kann folgender ESQL-Code von einem Compute-Knoten aus verwendet werden:
CALL CopyMessageHeaders(); -- Standardprozedur zum Kopieren von Headern
CALL parseWAS_JMS(InputRoot, OutputRoot); -- Analysieren des ‘Rumpfs' als MIME
Beim Empfang einer SOAP-Nachricht mit Anhängen stellt WebSphere Application
Server einen Fehler fest
Szenario:Beim Senden einer SOAP-Nachricht mit Anhängen per JMS an einen WebSphere Application
Server-Client wird ein Fehler generiert, der besagt, dass der Bitstrom unerwartete Zeichen enthält.
Lösung: Wenn der Broker über JMS eine SOAP-Nachricht mit Anhängen an WebSphere Application
Server schickt, muss der MIME-Inhaltstyp-Wert im MQRFH2-Header erscheinen und nicht im Hauptteil der Nachricht. Die folgende Prozedur entfernt eventuelle MIME-artige Header vom Anfang des Nachrichtenbitstroms und fügt den Inhaltstyp-Wert zum MQRFH2-Header hinzu. Der übergebene Grenzwert ermöglicht es Ihnen, den Beginn des mehrteiligen MIME-Inhalts zu lokalisieren.
create procedure writeWAS_JMS(IN OutputTree reference,IN boundary char)
/***************************************************************************
* Einen MIME-Baum wie gewöhnlich serialisieren, aber danach eventuelle Header* vom Anfang wegnehmen und den Inhaltstyp-Wert wie von WAS/JMS erwartet * im RFH2-Header ablegen.
* Anm.: boundary (Grenze) - muss mit dem einleitenden Bindestrich-Paar* übergeben werden
***************************************************************************/
begin
-- MIME-Teilbaum in BLOB konvertieren
declare body BLOB asbitstream(OutputTree.MIME);
-- erstes Vorkommen der Grenze lokalisieren und alle Daten links davon -- fallen lassen
declare firstBoundary integer;
set firstBoundary = position (cast(boundary as blob ccsid 819) in body);
set body = substring(body from firstBoundary);
-- den MIME-Inhaltstyp-Wert im RFH2-Header ablegen; irgendwelche anderen
-- MIME-Header, die im RFH2-Header bewahrt werden müssen, können auf -- die gleiche Weise behandelt werden
set OutputTree.MQRFH2.usr."contentType" = OutputTree.MIME."Content-Type";
-- den Inhalt der MIME-Baumstruktur löschen und ein neues untergeordnetes BLOB-Element für den -- modifizierten Rumpf anlegen
set OutputTree.MIME = null;
CREATE LASTCHILD OF OutputTree DOMAIN('BLOB')PARSE(body);
end
Vor dem Aufruf dieser Prozedur muss der Nachrichtenfluss den Wert der Grenze herausfinden können. Dieser Wert ist möglicherweise nur einem Inhaltstyp-Header zu entnehmen. Die folgende Prozedur ermöglicht es Ihnen, den Grenzwert zu extrahieren:
create procedure getBoundary(IN ct reference,OUT boundary char)
/*****************************************************************
* Wert des Boundary-Parameters aus einem Inhaltstyp-Wert holen
******************************************************************/
begin
declare boundaryStart integer;
declare boundaryEnd integer;
set boundaryStart = position('boundary=' in ct) + 9;
set boundaryEnd = position(';' in ct from boundaryStart);
if (boundaryStart <> 0) then
if (boundaryEnd <> 0) then
set boundary = substring(ct from boundaryStart for boundaryEnd-boundaryStart);
ELSE
set boundary = substring(ct from boundaryStart);
end if;
end if;
end;
Ein Compute-Knoten kann diese Prozeduren zum Versenden einer MIME-Nachricht mit dem folgenden ESQL-Code aufrufen:
java_lang_StackOverflowError unter AIX
während der Verarbeitung eines Nachrichtenflusses, der Java-Knoten umfasst und
Java 5 verwendet
Szenario: Bei der Verarbeitung eines Nachrichtenflusses, der Java-Knoten
umfasst und Java 5 verwendet, kommt es
unter AIX zu einer abnormalen Beendigung. Aus der Absturzdatei geht hervor, dass es zu einer abnormalen Beendigung gekommen ist, die auf einen Segmentierungsfehler hinweist.
Eine Prüfung der Standardfehlerdatei (stderr) ergibt jedoch einen Stacküberlauf in der
Java Virtual Machine:
Exception in thread "Thread-15" java/lang/StackOverflowError: operating system stack overflow
at com/ibm/broker/plugin/MbOutputTerminal._propagate (Native Method)
at com/ibm/broker/plugin/MbOutputTerminal.propagate (MbOutputTerminal.java:103)
at com/ibm/xsl/mqsi/XMLTransformNode.evaluate (XMLTransformNode.java:1002)
at com/ibm/broker/plugin/MbNode.evaluate (MbNode.java:1434)
at com/ibm/broker/plugin/MbOutputTerminal._propagate (Native Method)
at com/ibm/broker/plugin/MbOutputTerminal.propagate (MbOutputTerminal.java:103)
at com/ibm/xsl/mqsi/XMLTransformNode.evaluate (XMLTransformNode.java:1002)
at com/ibm/broker/plugin/MbNode.evaluate (MbNode.java:1434)
at com/ibm/broker/plugin/MbOutputTerminal._propagate (Native Method)
at com/ibm/broker/plugin/MbOutputTerminal.propagate (MbOutputTerminal.java:103)
at com/ibm/xsl/mqsi/XMLTransformNode.evaluate (XMLTransformNode.java:1002)
at com/ibm/broker/plugin/MbNode.evaluate (MbNode.java:1434)
Erläuterung:In Java 5 gibt
es einen Parameter zur Anpassung der Stackgröße für Java-Threads.
Die standardmäßige Betriebssystem-Stackgröße für
Java 5 beträgt nur
256 KB. In manchen Nachrichtenflüssen (z. B. in Flüssen mit benutzerdefinierten Java-Knoten oder mit XMLT-Knoten) ist diese Größe unter Umständen nicht ausreichend. Es kommt dann zu einem Stacküberlauffehler in der Standardfehlerdatei (stderr). Passen Sie den Betriebssystem-Stack für Java über die JVM-Option
-Xmso an. Informationen zum Stack können mit folgendem Befehl angezeigt werden:
Mit diesem Befehl wird in der Standardfehlerdatei (stderr) beim Start ein Eintrag mit ungefähr folgendem Inhalt erstellt:
-Xmca32K RAM class segment increment (Inkrement des RAM-Klassensegments)
-Xmco128K ROM class segment increment (Inkrement des ROM-Klassensegments)
-Xmns0K initial new space size (anfängliche Größe des Speicherbereichs für neue Objekte)
-Xmnx0K maximum new space size (maximale Größe des Speicherbereichs für neue Objekte)
-Xms125000K initial memory size (anfängliche Speicherkapazität)
-Xmos125000K initial old space size (anfängliche Größe des Speicherbereichs für alte Objekte)
-Xmox250000K maximum old space size (maximale Größe des Speicherbereichs für alte Objekte)
-Xmx250000K memory maximum (Speichermaximum)
-Xmr16K remembered set size (erinnerte Satzgröße)
-Xlp0K large page size (Größe umfangreicher Seiten)
available large page sizes: 4K 16M (verfügbare Größen für umfangreiche Seiten)
-Xmso256K OS thread stack size (Größe des Betriebssystemthread-Stacks)
-Xiss2K java thread stack initial size (Anfangsgröße des Java-Thread-Stacks)
-Xssi16K java thread stack increment (Inkrement des Java-Thread-Stacks)
-Xss256K java thread stack maximum size (maximale Größe des Java-Thread-Stacks)
-Xscmx16M shared class cache size (Größe des gemeinsam genutzten Klassencache)
Note: The stack size defaults to 256K.
(Hinweis: Die Stackgröße beträgt standardmäßig 256 KB.)
Lösung:
Setzen Sie mithilfe des folgenden Befehls die Betriebssystem-Stackgröße für Java auf
2 MB:
export IBM_JAVA_OPTIONS=-Xmso2m
Starten Sie den Broker erneut.
Fehler beim Verwenden der Codepage-Umsetzung unter HP-UX
Szenario: Sie stellen Fehler bei der Codepage-Umsetzung unter HP-UX
fest.
Lösung: Überprüfen Sie das Attribut
CodedCharSetID des WS-Managers
WebSphere MQ. Der Standardwert für dieses Attribut lautet
1051. Ändern Sie diesen in 819 für Warteschlangenmanager, die WebSphere Message
Broker-Komponenten enthalten.