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 Message
Brokers 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 Fertigstellen.
Daraufhin wird Ihre aktualisierte Nachricht in die Warteschlange eingereiht.
Sie wissen nicht, welche Headerelemente bei der Einreihung in Warteschlangen eine Wirkung haben
Szenario: Wenn Sie den Editor für Einreihung in Warteschlange verwenden, scheinen die Felder 'Account-Token', 'Korrelations-ID', 'Gruppen-ID' und 'Nachrichten-ID' im Nachrichtenheader keine Wirkung zu haben.
Erläuterung: Diese Felder haben keine Wirkung, da sie nicht richtig serialisiert wurden.
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 Dropdown-Menü aufgeführt.
Erläuterung: Gelöschte Dateien für die Warteschlangeneinreihung werden nicht aus dem Dropdown-Menü entfernt. Das Auswählen dieser Dateien hat keine Auswirkungen.
Die ESQL-Umsetzung einer XML-Nachricht liefert unerwartete Ergebnissen
Szenario: Sie haben eine XML-Nachricht erstellt, die 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, identifizieren Sie das zweite doc-Element explizit. Beispiel:
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 sind einige oder alle der Wagenrücklaufzeichen nicht in der Ausgabenachricht vorhanden.
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.
Wagenrücklaufzeichen werden in einem XML-Dokument akzeptiert, aber ein XML-Parser normalisiert alle Wagenrücklaufzeichen in ein einzelnes Zeilenvorschubzeichen. Weitere Informationen hierzu finden Sie in der neuesten XML-Spezifikation unter Extensible Markup Language (XML), insbesondere in Abschnitt 2.11 (Behandlung des Zeilenendes).
Beachten Sie, dass dieses Problem 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 eine XML-konforme Anwendung oder XML-konforme Daten berücksichtigen müssen, dass der Parser eventuelle Vorkommen von Wagenrücklauf- plus Zeilenvorschubzeichen normalisiert.
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 XMLTransformation-Knotens unter z/OS
Szenario: Bei Verwendung des XMLTransformation-Knotens unter z/OS werden alle großgeschriebenen Os in einer XML-Datei in der ankommenden Nachricht in Unterstriche geändert.
Erläuterung: Die Eingabenachricht im XMLTransformation-Knoten muss im ASCII-Format eingehen, damit die Umwandlung richtig funktionieren kann. Der XMLTransformation-Knoten funktioniert nicht mit XML- oder XSL-Daten in EBCDIC. Javageht 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 sehr
ä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 die 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 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 eines TimeoutControl-Knotens wird eine Nachricht weitergegeben.
Szenario: Der TimeoutControl-Knoten erhält eine Nachricht über eine ungültige, beschädigte oder fehlende Zeitlimitinformation. Die Nachricht wird an das Fehlerterminal des TimeoutControl-Knotens weitergegeben, und es wird eine Ausnahmebedingungsliste generiert.
Erläuterung: Durch die folgenden Fehlerbedingungen kann eine Weitergabe an das Fehlerterminal 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: Halten Sie Ausschau nach irgendwelchen der oben aufgelisteten Fehlerbefunde und bereinigen Sie sie.
Die Nachrichtenverarbeitung in einem TimeoutNotification-Knoten schlägt fehl
Szenario: An das Fehler- oder 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 weitergegeben. Bei Verwendung einer Transaktion wird dieser Vorgang in einer einzigen Transaktion ausgeführt. Wenn keine Verbindung zum Fehlerterminal besteht, wird die Weitergabe nicht ausgeführt.
Wenn hinter einem TimeoutNotification-Knoten nach einer erfolgreichen Weitergabe (entweder an das Ausgabe- oder an das Fehlerterminal) ein Fehler auftritt, wird die Nachricht (in der gleichen Transaktion) an das Catch-Terminal weitergegeben.
Wenn keine Verbindung zum Catch-Terminal vorhanden ist oder die Weitergabe im
Catch-Knoten fehlschlägt, wird die Verarbeitung dieses Zeitlimits rückgängig gemacht.
Lösung: Stellen Sie sicher, dass Fehlerterminal und Catch-Terminal Ihres TimeoutNotification-Knotens korrekt verbunden sind.
Eine MRM-CWF-Nachricht wurde an das Fehlerterminal weitergegeben
Szenario: Ihre MRM-CWF-Nachricht wird an ein Fehlerterminal 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 (z. B. 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 Benutzerdebug-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, sollten die Attribute korrekt geschrieben werden.
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 (z. B. Environment) 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: Dafür gibt es zwei mögliche Gründe:
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 Input-Knoten 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 beim Festlegen von XML im Ordner 'Eigenschaften' für die Ausgabenachricht im Compute-Knoten dieser Wert an den Parser weitergegeben, wenn der Nachrichtenbitstrom von der Nachrichtenbaumstruktur erstellt wird, was normalerweise im Output-Knoten ausgeführt wird.
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.BIPv600
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: Wenn Sie die ID für das Format, das Sie definiert haben, falsch eingegeben haben, berichtigen Sie Ihren 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 ein bekanntes Problem beim Parser.
Sie stoßen auf Probleme, wenn Nachrichten EBCDIC-Zeilenvorschubzeichen enthalten, treten Probleme auf
Szenario: Wenn in Ihrer Bitstromeingabenachricht EBCDIC-NL-Zeichen (Zeichen für neue Zeile) enthalten sind, treten möglicherweise Probleme auf, wenn in Ihrem Nachrichtenfluss die CCSID (ID des codierten Zeichensatzes) des Ziels 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: Sie können das Problem in den folgenden Fällen umgehen:
Auf einem System, auf dem der Warteschlangenmanager einen codierten ASCII-Zeichensatz verwendet, stellen Sie sicher, dass ankommende Nachrichten keine EBCDIC-Zeilenvorschubzeichen enthalten:
Geben Sie an, dass WebSphere MQ die Konvertierung am Input-Knoten 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 NL-Zeichen durch die gewünschte 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: Halten Sie in den MIME-Nachrichten Ausschau nach irgendwelchen der oben aufgelisteten Fehlerbefunde und bereinigen Sie sie.
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:
Die Wurzel des Baums heißt nicht MIME.
Das letzte Kind von MIME heißt nicht 'Parts' oder 'Data'.
'Parts' hat ein nur Werte enthaltendes Element, und dieses Element ist nicht erstes oder letztes Kind von 'Parts'.
'Parts' hat Kinder, die keine nur Werte enthaltenden Elemente oder 'Part'-Kinder sind.
'Parts' hat keine Kinder, die 'Part' heißen.
Das letzte Kind eines 'Data'-Elements ist kein BLOB.
Lösung: Halten Sie in der logischen Nachrichtenbaumstruktur für die MIME-Nachricht Ausschau nach irgendwelchen der oben aufgelisteten Fehlerbefunde und bereinigen Sie sie.
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 oben genannte 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;
Und die anschließende Übergabe an die ASBITSTREAM-Funktion. Sie müssen beispielsweise folgenden ESQL-Code verwenden:
Damit stellen Sie sicher, dass als Ergebnis kein Bitstrom mit der Länge 0 erzeugt wird.
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 dann die obige Prozedur von einem Compute-Knoten aus aufrufen. Zum Aufruf der Prozedur von einem Compute-Knoten aus kann folgender ESQL-Code 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 des MIME-Baums löschen und ein neues BLOB-Kind 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:
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
dieses Attributs ist 1051. Ändern Sie diesen in 819 für Warteschlangenmanager, die WebSphere Message Broker-Komponenten enthalten.