Se emite un error de comunicación cuando utiliza el recurso de
colocación en cola
Escenario: Utiliza las herramientas de colocación en cola
o extracción de la cola para poner un mensaje en una cola, pero se
emite un mensaje de error que indica que se ha producido un error de
comunicación con el nombre del gestor de colas.
Explicación: El gestor de colas de
WebSphere MQ no se ha iniciado.
Solución: Reinicie el gestor de colas de
WebSphere MQ.
El recurso de colocación en cola no captura los cambios realizados
en un mensaje
Escenario: Está utilizando el recurso de colocación de
mensajes en cola del Kit de herramientas de Message
Brokers para
poner mensajes en las colas de WebSphere MQ.
Ha actualizado un mensaje y desea poner el mensaje en la cola, pero parece
que no se han capturado los cambios.
Solución:
Cierre y vuelva a abrir el archivo de colocación en cola.
Seleccione el mensaje que desea poner en la cola.
Guarde y cierre el archivo de colocación en cola.
Seleccione el menú que hay junto al icono Colocar un
mensaje en una cola.
Pulse Colocar mensaje.
Pulse el archivo de colocación en cola en el menú.
Pulse Finalizar.
Esta acción coloca el mensaje actualizado en la cola.
No sabe qué elementos de cabecera tienen efecto en la colocación en cola
Escenario: Cuando utiliza el Editor de colocación en
cola, la señal de contabilidad, el ID de correlación, el ID de grupo y el
ID de mensaje de la cabecera de mensaje no parecen tener ningún efecto.
Explicación: Estos campos no tienen ningún efecto porque
no están serializados correctamente.
Los archivos de mensajes de colocación en cola siguen listándose
después de suprimirse
Escenario: Los archivos de mensajes de colocación en
cola siguen listándose después de suprimirse.
Explicación: Los archivos de colocación en cola
suprimidos no se eliminan del menú desplegable. La selección de estos archivos no tiene ningún efecto.
La transformación ESQL de un mensaje XML tiene resultados
inesperados
Escenario: Ha creado un mensaje XML parecido a éste:
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]><doc><I1>100</I1></doc>
Aplica
la transformación ESQL:
SET OutputRoot.XMLNS.doc.I1 = 112233;
Esta
transformación genera el mensaje XML (tras la serialización):
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]<I1>112233<I1>><doc><I1>100</I1></doc>
El nuevo valor para I1 se ha puesto dentro
de DOCTYPE y no ha sustituido el valor de
100, como se esperaba.
Explicación: El XML en su mensaje contiene dos elementos
doc:
El elemento doctype
El elemento xmlElement que representa el
cuerpo del mensaje
El analizador ha encontrado la primera instancia de un
elemento denominado doc y
ha creado un hijo I1 con el valor
112233.
Solución: Para asignar un nuevo valor al elemento I1
dentro del elemento del cuerpo del mensaje doc,
identifique explícitamente el segundo elemento doc, de
esta manera:
SET OutputRoot.XMLNS.(XML.tag)doc.I1 = 112233;
Un mensaje XML pierde los caracteres de retorno de carro
Escenario: Está analizando un mensaje de entrada XML que contiene caracteres de retorno de carro o de salto de línea o está grabando un mensaje XML de salida que contiene caracteres de retorno de carro o de salto de línea en un elemento XML.
No obstante, algunos o todos los caracteres de retorno de carro no están presentes en el mensaje de salida.
Explicación: Este comportamiento es correcto, como se describe mediante la especificación XML y se produce
en los dominios XML, XMLNS o XMLNSC.
En XML, los caracteres separadores de línea principales son los caracteres de salto de línea.
Los caracteres de retorno de carro se aceptan en un documento XML, pero un analizador XML normaliza los caracteres de salto de línea y retorno de carro en un solo carácter de salto de línea. Para obtener más información, consulte la especificación XML más reciente Extensible Markup Language (XML), en especial, la sección 2.11 End
of Line Handling.
Tenga en cuenta que no puede solucionar este problema intercalando datos
en una sección CDATA. La especificación XML indica que una sección CDATA está ideada simplemente como escape para los bloques de texto que contienen caracteres que se pueden interpretar como marcadores. Asimismo, las secciones CDATA no están protegidas del analizador.
No puede utilizar el atributo xml:space para conservar los caracteres de salto de línea y retorno de carro. La especificación XML indica que la normalización de los caracteres de salto de línea y retorno de carro se lleve a cabo antes de realizar cualquier otro proceso.
Solución: Todos los datos compatibles con XML no deben basarse en
la presencia de caracteres de salto de línea y retorno de carro porque en XML
el carácter de salto de línea es únicamente un carácter de salto de línea y
cualquier aplicación o datos compatibles con XML deben tener en cuenta que el
analizador normaliza los caracteres de salto de línea y retorno de carro.
El intermediario no puede analizar un mensaje XML
Escenario: Recibe un archivo XML grande y lo incluye en un
sobre SOAP para pasarlo a un servicio web .NET. El intermediario no puede
analizar el mensaje XML
Explicación: El mensaje que recibe está definido como UTF-8
pero contiene caracteres UTF-16, tales como £. La presencia de estos
caracteres causa un problema con el analizador: el intermediario no puede
analizar el mensaje XML porque éste contiene un carácter no válido.
Solución: Establezca el ID de juego de caracteres codificado
(CCSID) en 1208 en lugar del valor predeterminado 437.
Aparecen caracteres no esperados al utilizar el nodo
XMLTransformation en
z/OS
Escenario: Al utilizar el nodo XMLTransformation
en z/OS, todas las O mayúsculas
que hay en un archivo XML del mensaje de entrada cambian a caracteres de subrayado.
Explicación: El mensaje de entrada del nodo XMLTransformation
debe venir como ASCII para que la transformación funcione correctamente. El nodo
XMLTransformation no funciona con datos
XML o XSL en código EBCDIC. Java
supone una conversión de EBCDIC 1047. A continuación,
WebSphere Message Broker realiza la conversión a EBCDIC 500, porque el
CCSID está establecido en 500. EBCDIC 1047 y EBCDIC 500 son muy
parecidos. Sólo la O, la J y la Z en mayúsculas
son diferentes. (La J y la Z también se
convierten incorrectamente). Las conversiones dejan una serie de
caracteres ilegible porque realmente está en ASCII. Sin embargo, sí
convierte la O de un carácter EBCDIC 1047 a un carácter EBCDIC
500.
Solución: Cambie su programa para que haga una
asignación de serie de caracteres sin ninguna conversión o especifique que
la serie de caracteres está en ASCII ISO-8859-1 (CCSID 819).
El analizador XMLNS emite el mensaje de error BIP5004
Escenario: Se emite el mensaje de error BIP5004, que indica
que el analizador XMLNS ha encontrado un problema con un mensaje XML de entrada.
Explicación: Este mensaje se emite por varias razones.
Algunos de los casos más comunes en los que se emite este mensaje son:
Ha especificado un carácter XML no válido en el mensaje XML de entrada.
Ha incluido datos binarios en el mensaje XML que, cuando se tratan
como datos de caracteres, no son válidos.
El mensaje ha llegado como parte de un mensaje de
WebSphere MQ y el MQMD.CodedCharSetId no
representa correctamente la corriente de bits del texto XML.
Ha utilizado caracteres que se reconocen como marcación.
Solución:
Compruebe que la aplicación emisora está enviando solamente
datos válidos. No obstante, si no es posible impedir que se
incluyan caracteres no válidos en el mensaje XML, represéntelo en el
dominio BLOB y utilice la función ESQL REPLACE para sustituir o eliminar
los caracteres no válidos. Luego puede asignar la corriente de bits
modificada al analizador XML necesario.
De acuerdo con la
especificación XML, una sección CDATA sólo puede utilizarse para proteger
caracteres que se interpretarán como marcación. No se puede utilizar
para proteger caracteres no válidos o datos binarios del analizador XML.
Si el mensaje XML de entrada contiene datos binarios, asegúrese
de que la aplicación emisora se modifica para representarlos
como datos binarios codificados en base.
Si no se puede modificar la aplicación, represente el mensaje en el
dominio BLOB y extraiga y sustituya los datos binarios antes de que se
asigne la corriente de bits al analizador XML necesario.
Compruebe que el mensaje XML de entrada se representa con el
MQMD.CodedCharSetId correcto.
El nodo Compute emite el mensaje de error
BIP5005
Escenario: Envía un mensaje XML sencillo a un flujo de
mensajes sencillo. El mensaje es:
<doc><I1>100</I1></doc>
El nodo
Compute del flujo de mensaje contiene el
siguiente ESQL:
SET OutputRoot.XMLNS.abc = InputBody;
Usted
espera que se cree el siguiente mensaje de salida:
<abc><doc><I1>100</I1></doc></abc>
El nodo Compute
genera el mensaje de error BIP5005 y no implementa el
ESQL.
Explicación: Está asignando un elemento de un tipo
(root) a un elemento de otro tipo (xmlElement). El
analizador no efectúa esta transformación implícita automáticamente.
Solución: Puede efectuar la transformación usted mismo
en el ESQL para alcanzar el resultado que desea, utilizando una de estas
dos transformaciones:
SET OutputRoot.XMLNS.(XML.Element)abc = InputBody;
o:
SET OutputRoot.XMLNS.(XML.tag)abc = InputBody;
Se propaga un mensaje en el terminal Failure
de un nodo TimeoutControl
Escenario: El nodo TimeoutControl
recibe un mensaje con información de tiempo de espera no válida, corrupta o incompleta. El
mensaje se propaga al terminal Failure (de anomalías) del nodo
TimeoutControl y se genera una lista de
excepciones.
Explicación: Las siguientes condiciones de error pueden
provocar la propagación al terminal Failure:
Una petición de tiempo de espera no tiene Acción o Identificador.
Una petición SET tiene un identificador que coincide con una petición SET almacenada
existente para este nodo TimeoutControl
(identificado por la propiedad de Identificador exclusivo) y el elemento
AllowOverwrite de la petición original se ha establecido en FALSE.
Una petición CANCEL tiene un Identificador que no coincide con una petición
SET almacenada existente para este nodo TimeoutControl
(identificado por la propiedad de Identificador exclusivo).
Una petición SET tiene una Cuenta de 0 o es menor que -1.
StartDate o StartTime no están en el formato correcto (o no son una de las
palabras clave permitidas).
El tiempo de espera calculado está en el pasado.
El Intervalo es menor que 0, o 0 con una cuenta de -1.
Solución: Compruebe si existe alguna de las condiciones de
error listadas anteriormente y rectifíquelas.
El proceso de mensajes falla en un nodo
TimeoutNotification
Escenario: Se propaga un mensaje al terminal Failure o Catch
de un nodo TimeoutNotification.
Explicación: Si el proceso de un tiempo de espera genera un error
en el nodo TimeoutNotification, se genera
una lista de excepciones y se propaga un mensaje al terminal Failure. Esta acción se
realiza bajo la misma transacción, si se está utilizando una. Si el
terminal Failure no está conectado, no se produce la propagación.
Si se produce un error en sentido descendente del nodo
TimeoutNotification después de una propagación
satisfactoria (al terminal Out o Failure), el mensaje se propaga al terminal
Catch (todo bajo la misma transacción).
Si el terminal Catch no está conectado, o falla la
propagación en el flujo de captación, el proceso de ese tiempo de
espera se restituye.
Solución: Asegúrese de que los terminales Failure y Catch del
nodo TimeoutNotification estén conectados
correctamente.
Se propaga un mensaje CWF MRM al terminal Failure
Escenario: Su mensaje CWF MRM se propaga a un terminal Failure
(de anomalías), y genera los mensajes de error BIP5285,
BIP5125 y BIP5181 o los mensajes
BIP5285, BIP5125 y BIP5288.
Explicación: Estos errores informan de una incoherencia
entre la longitud del mensaje que se procesa y la longitud del mensaje
definido en el modelo de mensaje.
Solución: Asegúrese de que la longitud del mensaje tal
como se define en la capa CWF es correcta. Compruebe y corrija la
definición.
Problemas con atributos XML
Se escriben códigos XML donde se
esperan atributos XML y viceversa.
Explicación: Los dominios XML y el Formato físico XML
del dominio MRM tienen su propia representación de los atributos XML.
Los dominios XML utilizan el método de establecer un tipo de
campo XML.Attribute en el árbol de mensaje, ya que no tienen ningún
modelo con el que realizar el análisis.
En el caso del Formato físico XML del dominio MRM, el modelo de
mensaje indica si un elemento es un atributo o un código, por lo
que el árbol de mensaje no necesita reflejar si un campo es un atributo o
un código.
Por consiguiente, si se copian campos de los dominios XMLNS o MRM, se pierde el hecho
de que los campos sean atributos. Esta pérdida sucede si
se los campos se copian entre sí, o en otro árbol de mensaje, como
por ejemplo el árbol Entorno.
Este problema suele aparecer en las siguientes situaciones:
Escenario 1: Está escribiendo un mensaje XML en el dominio MRM
y se están escribiendo códigos XML en lugar de atributos XML.
Solución 1: Compruebe que su árbol de mensaje tiene la misma
estructura y secuencia que el modelo de mensaje. Si el árbol de mensaje
no coincide con el modelo de mensaje, el campo se escribe como
autodefinido y, por consiguiente, la propiedad Devolución de XML no se
utiliza.
Active la validación de mensajes. La validación indica el
lugar donde el árbol de mensaje y la definición de mensaje no coinciden.
O active un rastreo de depuración de usuario del flujo de
mensajes; los mensajes BIP5493W indican qué campos se están escribiendo como
autodefinidos. Utilice esta información para asegurarse de que el árbol de
mensaje coincide con el modelo. Una vez que haya corregido cualquier
discrepancia, los atributos deberían escribirse correctamente.
Escenario 2: Un mensaje MRM se ha copiado en un dominio XMLNS y
los atributos XML se escriben ahora como códigos.
Solución 2: Realice una de estas acciones:
Serialice el mensaje XML en el dominio MRM, por ejemplo utilizando
la función ESQL ASBITSTREAM, y luego utilice la cláusula ESQL CREATE PARSE
para volver a analizar el mensaje utilizando el dominio XML necesario.
Al copiar campos entre el dominio MRM y XMNSL, copie los campos
de atributo individualmente y especifique expresamente XML.Attribute
en el campo XML de destino.
Escenario 3: Un mensaje XML se ha copiado en otro árbol de
mensaje, como por ejemplo Entorno. Cuando el mensaje se copia de nuevo en
el árbol de mensaje XML, los atributos XML se ven ahora como códigos
XML.
Solución 3: Serialice el mensaje XML, por ejemplo utilizando
la función ESQL ASBITSTREAM, y luego utilice la cláusula ESQL CREATE PARSE
para volver a analizar el mensaje XML en el árbol de mensaje de destino
necesario. Consulte la Sentencia CREATE para ver un
ejemplo.
Escenario 4: Una parte de un árbol de mensaje no XML se
ha separado y asociado a un árbol XML, y los códigos XML ahora se
escriben como atributos XML.
Solución 4: No separe y asocie partes de árboles de mensaje
que sean propiedad de analizadores diferentes. En lugar de eso,
utilice una copia de árbol.
Escenario 5: Un código XML se copia en un atributo XML y el
atributo XML no se escribe en el mensaje de salida.
Solución 5: Al hacer referencia al código XML de origen,
utilice la función ESQL FIELDVALUE para copiar el valor de campo
específico en el campo de atributo XML de destino.
Un mensaje XML MRM muestra un comportamiento inesperado
Escenario: El flujo de mensajes está procesando un mensaje que
se ha modelado en el dominio MRM. El árbol del mensaje no se ha creado
como se esperaba, el mensaje XML de salida no tiene el contenido esperado
o el contenido del mensaje no se valida. No se ha emitido ningún mensaje
de error.
Explicación: Hay dos causas posibles para este problema:
Explicación 1: Los valores del formato físico XML para un
conjunto de mensajes contienen una propiedad denominada Nombre de
código raíz. Esta propiedad adopta el valor predeterminado MRM, para
seguir siendo compatible con los releases anteriores del producto. Si no
ha suprimido el contenido de este campo, el analizador XMLNS MRM espera que
el código raíz de todos los mensajes XML sea MRM.
Solución 1:Borre este campo o establézcalo en el código raíz que utilizan todos
sus mensajes XML. Si proporciona un valor en este campo, no es necesario
modelar el código raíz en todas sus definiciones de mensajes.
Explicación 2: Por compatibilidad con releases
anteriores, el intermediario reconoce el formato XML e invoca el
analizador XMLNS con valores predeterminados específicos. Si ha creado una
capa física XML para este mensaje con el nombre XML, el intermediario
utiliza su definición. Sin embargo, si no ha creado una capa física XML
con este nombre, pero ha especificado XMLNS como el formato, en el nodo de
entrada o en la cabecera MQRFH2 (cuando la corriente de bits de entrada se
analiza y convierten en un árbol de mensaje), el intermediario acepta el
valor especificado y pasa valores predeterminados al analizador para crear
el árbol de mensaje.
De forma similar, si establece
XML en la carpeta de Propiedades para el mensaje de salida en el nodo
Compute, este valor se pasa
al analizador cuando éste crea la corriente de bits de mensajes del árbol de mensaje,
generalmente en el nodo de salida.
El uso por
parte del analizador estos valores predeterminados puede dar como
resultado un contenido o una estructura distintos, o ambas cosas a la vez,
para el árbol de mensaje o el mensaje de salida. Puede encontrar más
información sobre la acción que toma el intermediario en las anotaciones
de rastreo de usuario, donde es posible que haya la siguiente
información:
XMLWorker::initializeParse file:C:\s000\src\cpi\pwf\xml\xmlworker.cpp
line:126 message:5409.BIPv600
No diccionario presente, ¿se ha especificado el formato físico 'XML' en error? ,
Rastreo Usuario BIP5409E: Operador XML: se ha especificado el formato físico 'XML'.
Se están utilizando los valores predeterminados XML de MRM debido a que
se especificó el identificador de formato físico 'XML' y no se encontró.
Esto puede deberse a un valor incorrecto del identificador de formato
físico en un mensaje.
Solución
2: Si ha entrado incorrectamente el identificador del formato que ha
definido, corrija el código y vuelva a intentarlo. Si no desea que se
realice la acción predeterminada, defina una capa física que
produzca el resultado requerido.
El analizador MRM no ha podido analizar un mensaje porque dos
atributos tienen el mismo nombre
Escenario: Dos atributos en espacios de nombres distintos
tienes nombres idénticos. Se emite el mensaje de error BIP5117.
Explicación: El analizador MRM no ha podido analizar el mensaje.
Solución: Modifique los nombres de atributo de forma que
no sean idénticos. Este es un problema conocido con el analizador.
Aparecen problemas cuando los mensajes contienen caracteres de
nueva línea EBCDIC
Escenario: Si el mensaje de entrada de corriente de bits
contiene caracteres NL (nueva línea) EBCDIC, pueden producirse problemas
si el flujo de mensajes cambia el CCSID de destino por un CCSID ASCII. Por
ejemplo, durante la conversión de CCSID 1047 (EBCDIC utilizado para
z/OS Open Edition) a CCSID 437 (US PC
ASCII) un carácter NL se convierte de hex '15' a hex '7F', que es un
carácter no definido. El error se produce porque no existe ningún punto de
código correspondiente para el carácter de nueva línea en la página de códigos
ASCII.
Solución: Puede solucionar este problema en
estos casos:
En un sistema en el que el gestor de colas utilice un conjunto de
códigos ASCII, asegúrese de que los mensajes de entrada no contengan
ningún carácter NL EBCDIC:
Especificando que WebSphere MQ realice la
conversión en el nodo de entrada
Estableciendo el atributo de gestor de colas para convertir NL en LF
(salto de línea)
Cuando la corriente de bits de entrada son datos de tipo carácter, puede
utilizar conjuntos de mensajes codificados/delimitados de MRM en un nodo
Compute para sustituir el carácter
NL por la salida deseada.
El analizador MIME genera un error de ejecución mientras analiza un mensaje
Escenario: Un flujo de mensajes recibe un mensaje MIME y
se genera un error de ejecución cuando se está analizando el mensaje.
Explicación: Los errores siguientes pueden hacer que el
analizador MIME rechace un mensaje:
La cabecera MIME no está formateada correctamente.
El bloque de cabecera MIME de nivel superior o un bloque de
cabecera MIME para una parte "multipart" anidada, no tiene una
cabecera Content-Type válida.
El Content-Type de nivel superior tiene el tipo de contenido
message.
El Content-Type de nivel superior tiene el tipo de contenido
multipart y no tiene ninguna definición de límite.
Un bloque de cabecera MIME no está correctamente finalizado con una
línea en blanco.
Las partes MIME constituyentes no están separadas correctamente con
líneas límite.
Aparece un valor de parámetro de límite en el contenido de una parte
MIME.
Solución: Compruebe si en el mensaje MIME existe alguna
de las condiciones de error listadas anteriormente y rectifíquelas.
Se emiten errores de ejecución cuando escribe un mensaje MIME desde
el árbol lógico de mensaje
Escenario: Está escribiendo un árbol lógico de mensaje MIME
como una corriente de bits y el analizador genera un error de
ejecución.
Explicación: Los errores siguientes pueden hacer que el
analizador MIME rechace un árbol lógico de mensaje:
El elemento raíz del árbol no se denomina MIME.
El último hijo de MIME no se denomina Parts o Data.
Parts tiene un elemento value-only y este elemento no es el primer ni
último hijo de Parts.
Parts tiene hijos que no son elementos value-only ni hijos Part.
Parts no tiene ningún hijo denominado Part.
El último hijo de un elemento Data no es un BLOB.
Solución: Compruebe si en el árbol lógico de mensaje MIME
existe alguna de las condiciones de error listadas anteriormente y
rectifíquelas.
El mensaje de salida tiene un cuerpo de mensaje vacío
Escenario: Ha encontrado inesperadamente un cuerpo
de mensaje vacío, o la función ASBITSTREAM ha generado un BLOB de longitud
cero.
Explicación: Este error puede ocurrir por las siguientes
razones:
Ha creado una carpeta de árbol de mensaje en un nodo definido por el
usuario pero no la ha asociado con un analizador propietario. Un analizador
propietario no se asocia al árbol de mensaje si ha creado elementos
estándar utilizando código similar o equivalente al siguiente:
Ha empleado ESQL para crear una carpeta de árbol de mensaje
utilizando ESQL CREATE pero sin establecer un analizador propietario para
la misma. Puede que haya utilizado código similar o equivalente al
siguiente:
CALL CopyMessageHeaders();
DECLARE outRef REFERENCE TO OutputRoot;
CREATE LASTCHILD OF outRef AS outRef NAME 'BLOB';
CREATE LASTCHILD OF outRef NAME 'BLOB' VALUE X'01';
o que la
variable de referencia outRef se haya pasado a una
función o procedimiento ESQL que contenía sentencias CREATE parecidas a estas. No
ha especificado un analizador propietario utilizando la cláusula DOMAIN en
la sentencia CREATE.
Se ha creado un árbol de mensaje MRM y luego sólo se ha pasado una
parte del mismo, especificando una subcarpeta o un campo, a la función
ASBITSTREAM con la opción de modalidad de analizador establecida en
RootBitStream. Esta combinación no es válida y da como resultado un
BLOB de longitud cero.
Ha copiado un árbol de mensaje, o parte de un árbol de mensaje, en
una carpeta y no se mantiene la asociación con el analizador propietario.
Solución: Dependiendo de cuál sea la razón del cuerpo de mensaje
vacío o el BLOB de longitud cero, asegúrese de lo siguiente:
Cuando cree una carpeta de árbol de mensaje en un nodo definido por el
usuario, asocie un analizador propietario a la carpeta. Utilice código
similar o equivalente al siguiente:
Cuando utilice ESQL CREATE para crear una carpeta de árbol de mensaje,
utilice la cláusula DOMAIN para asociar un analizador propietario con el
árbol de mensaje, por ejemplo:
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';
Este
código crea una carpeta BLOB que tiene asociado el analizador BLOB.
Al copiar un árbol de mensaje, o parte de un árbol de mensaje,
asegúrese de que se mantiene la asociación con el analizador propietario;
para ello, primero serialice y luego vuelva a analizar el mensaje en el
árbol de mensaje adecuado. Un caso de ejemplo es cuando ha creado un
campo:
SET Environment.Variables.myMsg = InputRoot.XMLNS;
y
ahora necesita pasarlo a la función ASBITSTREAM. A menos que utilice ESQL
similar o equivalente al siguiente:
el resultado
será una corriente de bits de longitud cero.
El mensaje de salida tiene un cuerpo de mensaje no válido indicado por el mensaje de
error BIP5005, BIP5016 o BIP5017
Escenario: Ha encontrado inesperadamente un cuerpo de mensaje de varias raíces o
un mensaje sin raíz.
Explicación: Este error se puede producir cuando ha creado
una carpeta de árbol de mensaje XML con varias raíces o sin ninguna raíz:
Utilizando un nodo definido por el usuario
Utilizando un nodo MQGet
Utilizando ESQL
Solución: Asegúrese de que el árbol de mensaje de salida final tenga un
solo y único nodo raíz XML.
Se emite el mensaje de error BIP5651 al
recibir un mensaje SOAP con Adjuntos de un cliente de
WebSphere Application
Server
Escenario: Cuando un cliente de
WebSphere Application
Server envía un mensaje
SOAP con Adjuntos al intermediario a través de
JMS, se emite el mensaje de error BIP5651 indicando
que no se ha encontrado una cabecera Content-Type válida.
Explicación: Cuando un cliente
WebSphere Application
Server envía un mensaje SOAP con
Adjuntos al intermediario a través de JMS, el valor Content-Type de MIME
aparece en la cabecera MQRFH2 y no en el cuerpo de mensaje MIME.
Solución: Para resolver este problema, el valor Content-Type
debe copiarse de la cabecera MQRFH2 al principio del mensaje como
cabecera MIME antes de que se analice el mensaje. El ESQL siguiente añade
el valor Content-Type al principio del mensaje de
WebSphere Application
Server y luego invoca el analizador
MIME en el resultado.
create procedure parseWAS_JMS(IN InputMessage reference,IN OutputMessage reference)
/***********************************************************************
* convertir un mensaje WAS/JMS al formato correcto para el analizador MIME
***********************************************************************/
begin
-- obtener los datos como BLOB
declare body BLOB InputMessage.BLOB.BLOB;
-- obtener el valor Content-Type en cabecera RFH2. Content-Type es la única
-- cabecera crítica para el analizador MIME, pero se puede utilizar el mismo
-- método para cabeceras MIME que se han almacenado bajo la cabecera RFH2.
declare contentType char InputMessage.MQRFH2.usr.contentType;
-- añadir contentType a la corriente de bits como parte de un bloque de cabecera RFC822
set body = cast(('Content-Type: '||contentType) as blob ccsid 819)||x'0d0a0d0a'||body;
-- invocar el analizador MIME en la corriente de bits modificada
CREATE LASTCHILD OF OutputMessage DOMAIN('MIME') PARSE(body);
end;
Un flujo de mensajes puede recibir el mensaje
JMS en el dominio de BLOB y, a continuación, invocar el procedimiento anterior
desde un nodo Compute. Se puede llamar al
procedimiento utilizando el siguiente ESQL desde un nodo
Compute:
CALL CopyMessageHeaders(); -- procedimiento estándar para copiar cabeceras
CALL parseWAS_JMS(InputRoot, OutputRoot); -- analizar el ‘cuerpo’ como MIME
WebSphere Application
Server genera un error al
recibir un mensaje SOAP con Adjuntos
Escenario:Al enviar un mensaje SOAP con Adjuntos a un
cliente de WebSphere Application
Server utilizando JMS,
se genera un error que indica que la corriente de bits contiene caracteres
inesperados.
Solución: Cuando el intermediario envía un mensaje SOAP
con Adjuntos a WebSphere Application
Server a través de
JMS, el valor Content-Type de MIME debe aparecer en la cabecera MQRFH2 y no
en el cuerpo del mensaje. El procedimiento siguiente elimina cualquier
cabecera de estilo MIME del principio de la corriente de bits del mensaje y
añade el valor Content-Type a la cabecera MQRFH2. El valor de límite
proporcionado le permite localizar el inicio del contenido MIME de varias partes.
create procedure writeWAS_JMS(IN OutputTree reference,IN boundary char)
/***************************************************************************
* Serializar un árbol MIME como normal, y luego quitar las cabeceras iniciales
* y guardar el valor Content-Type en la cabecera RFH2, como espera WAS/JMS.
* Nota: boundary (límite) - debe proporcionarse con la pareja de guiones iniciales
***************************************************************************/
begin
-- convertir subárbol MIME en BLOB
declare body BLOB asbitstream(OutputTree.MIME);
-- localizar primera aparición de límite y descartar los datos antes del mismo
declare firstBoundary integer;
set firstBoundary = position (cast(boundary as blob ccsid 819) in body);
set body = substring(body from firstBoundary);
-- guardar el valor Content-Type de MIME en la cabecera RFH2. Las otras
-- cabeceras MIME que deben conservarse en la cabecera RFH2 pueden
-- manejarse de la misma manera
set OutputTree.MQRFH2.usr."contentType" = OutputTree.MIME."Content-Type";
-- borrar el árbol MIME y crear un nuevo hijo BLOB para el cuerpo modificado
set OutputTree.MIME = null;
CREATE LASTCHILD OF OutputTree DOMAIN('BLOB')PARSE(body);
end
Antes de llamar a este procedimiento, el
flujo de mensajes debe poder obtener el valor
del límite. Este valor puede estar disponible solamente dentro de una
cabecera Content-type. El procedimiento siguiente le permite extraer el
valor de límite:
create procedure getBoundary(IN ct reference,OUT boundary char)
/*****************************************************************
* devolver el valor del parámetro de límite de un valor Content-Type
******************************************************************/
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;
Un nodo Compute
puede invocar estos procedimientos para enviar un mensaje MIME utilizando el siguiente
ESQL:
Problemas al utilizar la conversión de página de códigos en HP-UX
Escenario: Se producen problemas de conversión de página de
códigos en HP-UX.
Solución: Compruebe el atributo de gestor de colas
CodedCharSetID de
WebSphere MQ. El valor predeterminado para
este atributo es 1051. Cambie este valor a 819 para gestores de colas
que alojen componentes de WebSphere Message Broker.