Um Erro de Comunicação é Emitido Quando Utilizar o Recurso Enfileirado
Cenário: Você utiliza as ferramentas enqueue ou dequeue para colocar uma
mensagem em uma fila, mas uma mensagem de erro é emitida indicando que ocorreu
um erro de comunicação com o nome do gerenciador de filas.
Explicação: O gerenciador de filas
WebSphere MQ não foi iniciado.
Solução: Reinicie o gerenciador de filas
WebSphere MQ.
O Recurso de Enfileiramento Não Está Capturando as Alterações Feitas em uma Mensagem
Cenário: Você está está usando o recurso de enfileiramento de mensagens do
WebSphere Message Broker Toolkit para colocar mensagens em filas do
WebSphere MQ.
Você atualizou uma mensagem e quer colocar a mensagem na
fila, mas as alterações não parecem ter sido apanhadas.
Solução:
Feche, em seguida, reabra seu arquivo de enfileiramento.
Selecione a mensagem que deseja colocar na fila.
Salve e feche o arquivo de enfileiramento.
Selecione o menu junto ao ícone Colocar uma mensagem em
uma fila.
Clique em Colocar Mensagem.
Clique no arquivo de enfileiramento no menu.
Clique em Concluir.
Esta ação coloca a mensagem atualizada na fila.
Você não Sabe Quais Elementos do Cabeçalho Afetam o Enfileiramento
Cenário: Ao usar o editor de Enfileiramento, o token contábil, o ID de correlação, o ID do grupo
e o ID de mensagem no cabeçalho da mensagem não parecem afetar o comportamento.
Explicação: Estes campos não afetam o comportamento, porque eles não são serializados
corretamente.
Os Arquivos de Mensagem Enfileirados Permanecem Listados Após
Terem Sido Excluídos
Cenário: Os arquivos de mensagens de enfileiramento ainda estão listados no menu após terem sido
excluídos.
Explicação: Os arquivos de enfileiramento excluídos não são removidos do menu. Nada acontecerá se
você selecionar estes arquivos.
A Conversão ESQL de uma Mensagem XML Dá Resultados Inesperados
Cenário: Você criou uma mensagem XML que tem o conteúdo semelhante ao seguinte:
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]><doc><I1>100</I1></doc>
Você aplica a conversão ESQL:
SET OutputRoot.XMLNS.doc.I1 = 112233;
Esta conversão gera a mensagem XML (após serialização):
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]<I1>112233<I1>><doc><I1>100</I1></doc>
O novo valor para I1 foi colocado dentro do DOCTYPE
e não substituiu o valor de 100, como você esperava.
Explicação: O XML em sua mensagem contém dois
elementos doc:
O elemento doctype
O xmlElement que representa o corpo da mensagem
O analisador encontrou a primeira instância de um elemento
chamado doc e criou um I1 filho com
o valor 112233.
Solução: Para designar um novo valor ao elemento I1 no elemento do corpo da
mensagem doc, identifique explicitamente o segundo elemento doc, da
seguinte maneira:
SET OutputRoot.XMLNS.(XML.tag)doc.I1 = 112233;
Uma Mensagem XML Perde Caracteres de Retorno de Carro
Cenário: Você está analisando uma mensagem XML de entrada que contém caracteres de retorno de carro ou de alimentação de linha ou está gravando uma mensagem XML de saída que contém caracteres de alimentação de linha de retorno de carro em um elemento XML. No entanto, alguns ou todos os caracteres de retorno de linha não estão presentes na mensagem de saída.
Explicação: Esse comportamento é correto, conforme descrito pela especificação XML e ocorre nos domínios XML, XMLNS ou XMLNSC.
Em XML, o caractere principal separador de linha é um caracteres de alimentação de linha. Os caracteres de
retorno de linha são aceitos em um documento XML, mas um analisador XML normaliza quaisquer caracteres de
retorno de linha e de feed de linha em um único caractere de feed de linha. Para obter informações adicionais, consulte a especificação XML mais recente em XML (Extensible Markup Language), principalmente a Seção 2.11 Manipulação de Fim de Linha.
Este problema não pode ser resolvido integrando seus dados em uma seção CDATA; a especificação XML indica
que uma seção CDATA destina-se apenas a codificar com a função escape blocos de texto que contêm caracteres
que podem ser interpretados como marcação. Além disso, as seções CDATA não são protegidas do analisador.
Você não pode utilizar o atributo xml:space para preservar caracteres de alimentação de linha de retorno de carro; a especificação XML determina que a normalização dos caracteres de retorno de carro e de alimentação de linha seja feita antes da execução de qualquer outro processamento.
Solução: Dados compatíveis com XML não devem depender da presença de caracteres de retorno de
linha e de feed de linha porque, em XML, o caractere de feed de linha é apenas um caractere de feed de linha
e aplicativos ou dados compatíveis com XML devem observar que o analisador normaliza quaisquer caracteres de
retorno de linha e de feed de linha.
O Broker Não Pode Analisar uma Mensagem XML
Cenário: Você recebe um arquivo XML grande e o agrupa em um envelope SOAP para ser transmitido para um serviço da Web .NET. O broker não pode analisar a mensagem XML
Explicação: A mensagem recebida é definida como UTF-8, mas ela contém caracteres UTF-16, como £. A presença desses caracteres causa um problema com o analisador: o broker não pode analisar a mensagem XML, pois ela contém um caractere inválido.
Solução: Force o CCSID (Coded Character Set ID) para 1208 em vez do padrão 437.
São Exibidos Caracteres Inesperados ao Utilizar o Nó XSLTransform
no z/OS
Cenário: Ao usar o nó XSLTransform no z/OS, todos os Os maiúsculos
que estão em um arquivo XML na mensagem recebida são alterados para caracteres
sublinhados.
Explicação: A mensagem de entrada do nó XSLTransform
deve vir como ASCII para que a conversão funcione corretamente. O nó XSLTransform não funciona com
dados XML ou XSL em código EBCDIC. Java™ assume uma conversão de EBCDIC 1047. O WebSphere Message Broker converte
para EBCDIC 500, porque o CCSID está configurado como 500. EBCDIC 1047 e EBCDIC 500 são semelhantes.
Somente O, J e Z maiúsculos
são diferentes. (J e Z também são convertidos incorretamente.) As conversões
deixam uma cadeia ilegível porque ela está realmente em ASCII. Contudo,
o O é convertido de um caractere de EBCDIC 1047 para um caractere de EBCDIC
500.
Solução: Altere seu programa para realizar uma designação de cadeia
sem nenhuma conversão ou especifique que a cadeia está em ASCII ISO-8859-1
(CCSID 819).
A Mensagem de Erro BIP5004 É Emitida pelo Analisador XMLNS
Cenário: A mensagem de erro BIP5004 é emitida, indicando
que o analisador XMLNS encontrou um problema com uma mensagem XML
de entrada.
Explicação: Essa mensagem é emitida por vários motivos. Alguns dos cenários que ocorrem mais comumente quando essa mensagem é emitida são:
Você especificou um caractere XML inválido na mensagem XML de entrada.
Você incluiu dados binários na mensagem XML que, quando tratados como dados de caractere, são inválidos.
A mensagem chegou como parte de uma mensagem do WebSphere MQ e o MQMD.CodedCharSetId não representa corretamente o fluxo de bits de texto XML.
Você utilizou caracteres que são reconhecidos como marcação.
Solução:
Verifique se seu aplicativo de envio está enviando apenas dados válidos.
No entanto, se não for possível impedir que caracteres inválidos sejam incluídos na mensagem XML, represente-a no domínio BLOB e utilize a função ESQL REPLACE para substituir ou remover os caracteres inválidos.
Em seguida, você pode designar o fluxo de bits modificado para o analisador XML necessário.
De acordo com a especificação de XML, uma seção CDATA pode ser utilizada apenas para proteger caracteres que serão interpretados como marcação. Ela não pode ser utilizada para proteger caracteres inválidos ou dados binários do analisador XML.
Se a mensagem XML de entrada contiver dados binários, certifique-se de que o aplicativo de envio seja
alterado para representar estes dados como dados codificados de binário codificado base. Se o aplicativo não puder ser alterado, represente a mensagem no domínio BLOB e extraia e substitua os dados binários antes do fluxo de bits ser designado para o analisador XML necessário.
Verifique se a mensagem XML de entrada está sendo representada pelo MQMD.CodedCharSetId correto.
A Mensagem de Erro BIP5378 É Emitida pelo Analisador MRM
Cenário: A mensagem de erro BIP5378 é emitida, o que relata um problema com um elemento de repetição obrigatório em uma mensagem MRM.
Explicação: Essa mensagem indica que um elemento de repetição obrigatório não está presente na mensagem. Em releases anteriores, essa condição era relatada pela mensagem de erro
BIP5374 que agora relata somente quando um elemento de repetição obrigatório existe na mensagem, mas tem o número de instâncias incorreto.
Se você tiver programado rotinas de verificação de erro automatizadas, revise e altere estas rotinas, se
apropriado.
Solução: Verifique sua definição de mensagem para assegurar que o elemento deve ser obrigatório e repetitivo. A mensagem de erro informa os elementos que ocorrem antes e depois do local esperado do elemento que está faltando. Se a definição estiver correta, a mensagem não foi criada corretamente pelo aplicativo de envio, o que deve ser emendado.
A Mensagem de Erro BIP5005 É Emitida pelo Nó Compute
Cenário Você envia uma mensagem XML simples em um
fluxo de mensagens simples. A mensagem é:
<doc><I1>100</I1></doc>
O nó Compute no fluxo de mensagens contém a seguinte ESQL:
SET OutputRoot.XMLNS.abc = InputBody;
Você espera que a seguinte mensagem de saída seja criada:
<abc><doc><I1>100</I1></doc></abc>
O Nó Compute Gera a Mensagem
de Erro BIP5005 e não Implementa
ESQL.
Explicação: Você está designando um elemento de um
tipo (root) a um elemento de outro tipo
(xmlElement).
O analisador não faz essa atribuição
implícita para você.
Solução: Você mesmo pode fazer a conversão no ESQL
para obter o resultado desejado, utilizando uma das seguintes conversões:
SET OutputRoot.XMLNS.(XML.Element)abc = InputBody;
ou:
SET OutputRoot.XMLNS.(XML.tag)abc = InputBody;
Uma Mensagem É Propagada para o Terminal Failure de um Nó TimeoutControl
Cenário: O nó TimeoutControl recebe uma mensagem com
informações de tempo limite inválidas, danificadas ou ausentes. A mensagem
é propagada para o terminal Failure do nó TimeoutControl
e é gerada uma lista de exceções.
Explicação: As condições de erro a seguir podem
causar a propagação ao terminal de falha:
Um pedido de tempo limite não possui Ação ou Identificador.
Um pedido SET possui um Identificador que corresponde a um pedido
SET existente armazenado para este nó TimeoutControl (identificado
pela propriedade Identificador Exclusivo) e AllowOverwrite do pedido original
é configurado como FALSE.
Um pedido CANCEL possui um Identificador que não corresponde a um
pedido SET existente armazenado para esse nó TimeoutControl
(identificado pela propriedade Identificador Exclusivo).
Um pedido SET possui uma Contagem 0 ou é menor que -1.
O StartDate ou StartTime não está no formato correto (ou uma das
palavras-chave compreendidas).
O tempo limite calculado está no passado.
O Intervalo é menor que 0 ou 0 com uma Contagem de -1.
Solução: Verifique uma ou mais das condições de erro listadas aqui e corrija-as.
O Processamento de Mensagens Falha em um Nó TimeoutNotification
Cenário: Uma mensagem é propagada para o terminal Failure ou Catch
de um nó TimeoutNotification.
Explicação: Se o processamento de um tempo
limite gerar um erro no nó TimeoutNotification,
será gerada uma lista de exceções e uma mensagem será propagada para o terminal Failure. Esta ação será tomada na mesma
transação, se uma estiver sendo utilizada. Se o terminal Failure não estiver conectado, a propagação não
ocorrerá.
Se ocorrer um erro de recebimento de dados
do nó TimeoutNotification após uma propagação
bem-sucedida (para o terminal Out ou Failure), a mensagem será propagada
para o terminal Catch (tudo na mesma transação). Se o terminal Catch não estiver conectado, ou a propagação
no fluxo de Captura falhar, o processamento desse tempo limite será retrocedido.
Solução: Certifique-se de que os terminais Failure e Catch de seu nó
TimeoutNotification tenham sido conectados corretamente.
Uma Mensagem CWF de MRM é Propagada para o Terminal de Falha
Cenário: A mensagem CWF de MRM é propagada para um
terminal de Falha e gera as mensagens de erro BIP5285, BIP5125 e BIP5181 ou as mensagens BIP5285, BIP5125,
and BIP5288.
Explicação: Esses erros relatam uma inconsistência entre
o comprimento da mensagem que está sendo processada e o comprimento da mensagem
definida no modelo da mensagem.
Solução: Assegure-se de que o comprimento da mensagem
definido na camada CWF esteja preciso. Verifique e corrija a definição.
Problemas com Atributos XML
As tags XML são escritas onde os atributos XML são esperados, e vice-versa.
Explicação: Os domínios XML e o Formato de Ligação XML no domínio XML têm sua própria representação de atributos XML.
Os domínios XML baseiam-se na configuração de um tipo de campo de XML.Attribute na árvore de mensagens, pois eles não possuem nenhuma modelo para analisar.
Para o Formato de Conexão XML no domínio MRM, o modelo de mensagem indica se um elemento é um atributo ou uma tag e, dessa forma, a árvore de mensagens não precisa refletir se um campo é um atributo ou uma tag.
Portanto, se os campos forem copiados fora dos domínios XMLNS ou MRM, o fato de que estes campos são
atributos será perdido. Esta perda ocorrerá se eles forem copiados fora um do outro, ou em outra árvore de
mensagens, como a árvore ambiente.
Esse problema geralmente ocorre nas seguintes situações:
Cenário 1: Você está escrevendo uma mensagem XML no domínio MRM e tags XML estão sendo escritas no lugar de atributos XML.
Solução 1: Verifique se a sua árvore de mensagens tem a mesma estrutura e sequência que o modelo de mensagem. Se a árvore de mensagens não corresponder ao modelo de mensagem, o campo será gravado como auto-definitivo e, consequentemente, a propriedade
XML Render não será utilizada.
Ative a validação da mensagem. A validação mostra em que a árvore de mensagens e a definição de mensagem correspondem.
Como alternativa, obtenha um rastreio de depuração do usuário do fluxo de mensagens; as mensagens
BIP5493W indicam quais campos estão sendo gravados como de autodefinição. Utilize essas informações para garantir que a árvore de mensagens corresponda ao modelo. Quando tiver corrigido as discrepâncias, os atributos serão gravados corretamente.
Cenário 2: Uma mensagem MRM foi copiada para um domínio XMLNS e agora os atributos XML
são gravados como tags.
Solução 2: Execute uma destas ações:
Serialize a mensagem XML no domínio MRM, por exemplo usando
a função ESQL ASBITSTREAM, em seguida, use a cláusula ESQL CREATE PARSE
para reanalisar a mensagem usando o domínio XML necessário.
Ao copiar campos entre o domínio MRM e XMLNS, copie os campos de atributo individualmente e especifique XML.Attribute no campo XML de destino.
Cenário 3: Uma mensagem XML foi copiada para outra árvore de mensagens, como Ambiente. Quando a mensagem for copiada novamente para a árvore de mensagens XML, os atributos XML serão vistos como tags de XML.
Solução 3: Serialize a mensagem XML, por exemplo
usando a função ESQL ASBITSTREAM, em seguida, use a cláusula
ESQL CREATE PARSE para reanalisar a mensagem XML na árvore de mensagens de destino
necessária. Consulte Instrução CREATE para obter um exemplo.
Cenário 4: Uma parte de uma árvore de mensagens não XML foi descartada e anexada a uma árvore XML, e agora as tags XML são escritas como atributos XML.
Solução 4: Não descarte nem anexe partes de árvores de mensagens que pertençam a analisadores diferentes. Em vez disso, utilize uma cópia de árvore.
Cenário 5: Uma tag XML é copiada para um atributo XML e o atributo XML não é gravado na mensagem de saída.
Solução 5: Ao fazer referência à tag XML de origem, utilize a função ESQL FIELDVALUE para copiar o valor de campo específico no campo de atributo XML de destino.
Uma Mensagem XML do MRM Exibe Comportamento Inesperado
Cenário: O fluxo de mensagens está processando uma
mensagem que foi modelada no MRM. A árvore de mensagens não foi criada conforme você esperava, a
mensagem XML de saída não tem o conteúdo esperado ou o conteúdo da
mensagem não está sendo validado. Nenhuma mensagem de erro foi emitida.
Explicação: Duas razões podem causar este problema:
Explicação 1: As definições do formato físico
XML de um conjunto de mensagens contém uma propriedade chamada Nome
da Tag Raiz. Essa propriedade assume MRM como padrão para permanecer compatível com os releases
anteriores do produto. Se você não tiver excluído o conteúdo desse campo, o analisador XMLNS
MRM espera que a tag raiz para todas as mensagens XML seja
MRM.
Solução 1: Limpe esse campo ou configure-o
para a tag raiz utilizada por todas as mensagens XML. Se você fornecer um valor nesse campo, a tag raiz não precisará
ser modelada em todas as definições de mensagens.
Explicação 2: Para permanecer compatível com versões anteriores, o broker
reconhece o formato XML e chama o analisador XMLNS com valores padrão específicos. Se tiver criado uma camada física XML para essa mensagem com o nome
XML, o broker utilizará sua definição.
No entanto, se você não tiver criado
uma camada física XML com esse nome, mas tiver especificado XMLNS como o formato no
nó de entrada ou no cabeçalho MQRFH2 (quando o fluxo de bits de entrada é analisado
para uma árvore de mensagens), o broker aceitará o valor especificado e transmitirá
os valores padrão para o analisador a fim de criar a árvore de mensagens.
De forma semelhante, se você
configurar o XML na pasta Propriedades para a mensagem de saída no nó
Compute, este valor será passado para o analisador quando ele
criar o fluxo de bits da mensagem a partir da árvore de mensagens, geralmente no nó de saída.
O uso desses
valores padrão pelo analisador poderá resultar em conteúdo ou estrutura
diferente, ou ambos, para a árvore de mensagens ou a mensagem de saída. Você pode localizar informações sobre a ação tomada pelo
broker no registro de rastreios de usuário no qual estarão gravadas
as seguintes informações:
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: Wire Format 'XML' specified.
Default MRM XML settings are being used because wire format
identifier 'XML' was specified and not found.
This can be due to an incorrect setting of the wire format
identifier in a message.
Solução
2: Se você tiver inserido o identificador do formato que você definiu
incorretamente, corrija seu código e tente novamente. Se você não quiser que a ação padrão seja tomada, defina uma camada
física que produza os resultados requeridos.
O Analisador MRM Falhou em Analisar uma Mensagem Porque Dois Atributos Têm o Mesmo Nome
Cenário: Dois atributos em namespaces diferentes têm nomes
idênticos. A mensagem de erro BIP5117 é emitida.
Explicação: O analisador MRM falhou ao analisar a
mensagem.
Solução: Modifique os nomes dos atributos, para que eles não sejam
idênticos. Este problema é uma limitação conhecida com o analisador.
Você Encontra Problemas Quando as Mensagens Contêm Caracteres de Nova Linha EBCDIC
Cenário: Se sua mensagem de entrada do fluxo de bits contiver caracteres de nova linha (NL)
EBCDIC, poderão ocorrer problemas, se seu fluxo de mensagens alterar o CCSID de destino para um CCSID ASCII. Por exemplo, durante a conversão do CCSID
1047 (EBCDIC utilizado para z/OS Open Edition)
para o CCSID 437 (US PC ASCII), um caractere NL é convertido do hexadecimal
'15' para o hexadecimal '7F', que é um caractere indefinido. O erro ocorre porque não existe nenhum ponto de
código correspondente para o caractere de nova linha na página de códigos ASCII.
Solução: É possível superar o problema nestes
casos:
Em um sistema no qual o gerenciador de filas usa um conjunto de códigos ASCII, certifique-se de que as
mensagens recebidas não contenham nenhum caractere NL EBCDIC:
Especificando que o WebSphere MQ execute a conversão no nó input
Definindo o atributo do gerenciador de filas para converter NL para LF (Avanço de Linha)
Onde o fluxo de bits de entrada for dados de caractere, será possível usar conjuntos de mensagens MRM
Marcados/Delimitados em um nó Compute para substituir o caractere
NL pela saída necessária.
O Analisador MIME Produz um Erro de Tempo de Execução durante a Análise de uma Mensagem
Cenário: Uma mensagem MIME é recebida por um fluxo de mensagens e
produz um erro de tempo de execução quando a mensagem é analisada.
Explicação: Os erros a seguir podem fazer com que o analisador MIME
rejeite uma mensagem:
O cabeçalho MIME não está corretamente formatado.
O bloco de cabeçalho MIME de nível superior ou um bloco de cabeçalho MIME para uma parte de multipartes
aninhadas, não possui um cabeçalho Content-Type válido.
O Content-Type de nível superior possui um tipo de mídia de mensagem.
O Content-Type de nível superior possui um tipo de mídia de multipartes e
nenhuma definição de limite.
Um bloco de cabeçalho MIME não está corretamente finalizado por uma linha em branco.
As partes MIME constituintes não estão corretamente separadas por linhas de limites.
Um valor de parâmetro de limite ocorre no conteúdo de uma parte MIME.
Solução: Verifique na mensagem MIME uma ou mais das condições de erro listadas aqui e corrija-as.
Erros de Tempo de Execução São Emitidos ao Gravar uma Mensagem MIME da Árvore de Mensagens Lógica
Cenário: Você está gravando uma árvore de mensagens lógica MIME como um fluxo de bits e o analisador gera um erro de tempo de execução.
Explicação: Os erros a seguir podem fazer com que o analisador MIME
rejeite uma árvore de mensagens lógica:
A raiz da árvore não é chamada MIME.
O último filho de MIME não é chamado Parts ou Data.
O elemento Parts possui um elemento value-only e este elemento não é o primeiro ou o último filho de
Parts.
O elemento Parts possui filhos que não são elementos value-only ou filhos de Part.
O elemento Parts não possui nenhum filho chamado Part.
O último filho de um elemento Data não é um BLOB.
Solução: Verifique na árvore de mensagens lógica MIME uma ou mais das condições de erro listadas
aqui e corrija-as.
A Mensagem de Saída Tem um Corpo de Mensagem Vazio
Cenário: Você encontrou inesperadamente um corpo de mensagem vazia ou a função ASBITSTREAM gerou um BLOB de comprimento zero.
Explicação: Esse erro pode ocorrer pelos seguintes motivos:
Você criou uma pasta de árvore de mensagens em um nó definido pelo usuário, mas não a associou a um analisador próprio. Um analisador próprio não será associado à árvore de mensagens se você tiver criado elementos padrão utilizando código similar ou equivalente a:
Você utilizou ESQL para criar uma pasta de árvore de mensagens utilizando ESQL CREATE, mas sem configurar um analisador próprio para ela. Você pode ter utilizado código similar ou equivalente a:
CALL CopyMessageHeaders();
DECLARE outRef REFERENCE TO OutputRoot;
CREATE LASTCHILD OF outRef AS outRef NAME 'BLOB';
CREATE LASTCHILD OF outRef NAME 'BLOB' VALUE X'01';
ou a variável de referência
outRef foi passada para uma função ou procedimento ESQL que continha instruções CREATE
semelhantes. Você não especificou um analisador próprio utilizando a cláusula DOMAIN na instrução CREATE.
Uma árvore de mensagens MRM foi construída, em seguida, apenas parte dela
foi transmitida, especificando uma subpasta ou campo, para a função ASBITSTREAM
com a opção do modo do analisador configurada como RootBitStream. Essa combinação não é válida e resulta em um BLOB de comprimento zero.
Você copiou uma árvore de mensagens, ou parte de uma árvore de mensagens, em uma pasta e a associação de analisador próprio não é mantida.
Solução: Dependendo do motivo para o corpo de mensagem vazia ou o BLOB de comprimento zero, verifique se:
Quando você criar uma pasta de árvore de mensagens em um nó definido pelo usuário, associe um analisador próprio a ele. Utilize código similar ou equivalente a:
Quando você utilizar ESQL CREATE para criar uma pasta de árvore de mensagens, utilize a cláusula DOMAIN
para associar um analisador próprio à árvore de mensagens, por exemplo:
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';
Esse código cria uma pasta BLOB com o analisador BLOB associado a ela.
Ao copiar uma árvore de mensagens, ou parte de uma árvore de mensagens, assegure
que a associação do analisador proprietária seja mantida, primeiro serializando,
em seguida, reanalisando a mensagem na árvore de mensagens apropriada. Um exemplo de cenário é onde você criou um campo:
SET Environment.Variables.myMsg = InputRoot.XMLNS;
Agora é necessário passá-lo para a função ASBITSTREAM. A menos que você utilize ESQL similar ou equivalente a:
o resultado é um fluxo de bits de comprimento zero.
A Mensagem de Saída Possui um Corpo de Mensagem Inválido Indicado pela Mensagem de Erro
BIP5005, BIP5016 ou BIP5017
Cenário: Você encontrou inesperadamente um corpo da mensagem com várias raízes ou uma mensagem
sem nenhuma raiz.
Explicação: Este erro pode ocorrer quando você tiver criado uma pasta da árvore de mensagens XML
com várias raízes ou nenhuma raiz:
Utilizando um nó definido pelo usuário
Utilizando um nó MQGet
Utilizando ESQL
Solução: Certifique-se de que a árvore de mensagens de saída final tenha apenas
um nó raiz XML.
Mensagem de Erro BIP5651 é Emitida ao Receber um SOAP
com a Mensagem Anexos de um WebSphere Application
Server Client
Cenário: Quando um WebSphere Application
Server Client
envia um SOAP com a mensagem Anexos no broker sobre JMS, a mensagem de erro BIP5651 é
emitida informando que nenhum cabeçalho Content-Type válido foi localizado.
Explicação: Quando um cliente WebSphere Application
Server
envia um SOAP com a mensagem Anexos ao broker sobre JMS, o valor de Content-Type do MIME
aparece no cabeçalho MQRFH2 e não no corpo da mensagem MIME.
Solução: Para resolver esse problema, o valor de Content-Type
precisa ser copiado do cabeçalho MQRFH2 para o início da mensagem como
um cabeçalho MIME, antes de a mensagem ser analisada. O
ESQL a seguir inclui o valor Content-Type no início da mensagem do WebSphere Application
Server, em seguida, invoca o
analisador MIME no resultado.
create procedure parseWAS_JMS(IN InputMessage reference,IN OutputMessage reference)
/***********************************************************************
* converter uma mensagem WAS/JMS no formato correto do analisador MIME
***********************************************************************/
begin
-- obter os dados como um BLOB
declare body BLOB InputMessage.BLOB.BLOB;
-- obter o valor Content-Type a partir do cabeçalho RFH2. Content-Type é o único
-- cabeçalho que é crítico para o analisador MIME, mas a mesma abordagem pode ser
-- utilizada para todos os cabeçalhos MIME que foram armazenados no cabeçalho RFH2.
declare contentType char InputMessage.MQRFH2.usr.contentType;
-- incluir o contentType no fluxo de bits como parte de um bloco de cabeçalho RFC822
set body = cast(('Content-Type: '||contentType) as blob ccsid 819)||x'0d0a0d0a'||body;
-- chamar o analisador MIME no fluxo de bits modificado
CREATE LASTCHILD OF OutputMessage DOMAIN('MIME') PARSE(body);
end;
Um fluxo de mensagens pode inserir a mensagem JMS no domínio BLOB e chamar o
procedimento mostrado aqui a partir de um nó Compute.
O procedimento pode ser chamado usando a seguinte ESQL a partir de um nó
Compute:
CALL CopyMessageHeaders(); -- procedimento padrão para copiar cabeçalhos
CALL parseWAS_JMS(InputRoot, OutputRoot); -- parse the ‘body' as MIME
O WebSphere Application
Server Produz um Erro no
Recebimento de um SOAP com a Mensagem Anexos
Cenário: Ao enviar um SOAP com mensagem de Anexos a um cliente WebSphere Application
Server utilizando JMS, um erro é gerado informando que o fluxo de bits contém caracteres inesperados.
Solução: Quando o broker envia um SOAP com a mensagem
Anexos para WebSphere Application
Server sobre JMS, o valor
de Content-Type do MIME deve aparecer no cabeçalho MQRFH2 e não no corpo da
mensagem. O procedimento a seguir remove todos os cabeçalhos de estilo MIME da frente
do fluxo de bits de mensagens e inclui o valor de Content-Type no cabeçalho MQRFH2. O valor de limite fornecido permite localizar o início do conteúdo MIME
de multipartes.
create procedure writeWAS_JMS(IN OutputTree reference,IN boundary char)
/***************************************************************************
* Serialize uma árvore MIME como normal, mas, em seguida, remova todos os cabeçalhos iniciais
* e salve o valor Content-Type no cabeçalho RFH2 como esperado pelo WAS/JMS.
* Nota: boundary - deve ser fornecido com o par de hifens inicial
***************************************************************************/
begin
-- converter a subárvore MIME em BLOB
declare body BLOB asbitstream(OutputTree.MIME);
-- localizar a primeira ocorrência de limite e descartar quaisquer dados anteriores
declare firstBoundary integer;
set firstBoundary = position (cast(boundary as blob ccsid 819) in body);
set body = substring(body from firstBoundary);
-- salve o valor Content-Type do MIME no cabeçalho RFH2. Todos os outros
-- cabeçalhos MIME que precisam ser preservados no cabeçalho RFH2 podem ser manipulados
-- da mesma forma
set OutputTree.MQRFH2.usr."contentType" = OutputTree.MIME."Content-Type";
-- limpe a árvore MIME e crie um novo filho BLOB para o corpo modificado
set OutputTree.MIME = null;
CREATE LASTCHILD OF OutputTree DOMAIN('BLOB')PARSE(body);
end
Antes de chamar esse procedimento, o fluxo de mensagens precisa
conseguir obter o valor do limite. Esse valor pode estar disponível somente em um cabeçalho de tipo de conteúdo. O procedimento a seguir permite extrair
o valor Limite:
create procedure getBoundary(IN ct reference,OUT boundary char)
/*****************************************************************
* retornar valor do parâmetro de limite de um 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;
Um nó Compute pode chamar
estes procedimentos para enviar uma mensagem MIME utilizando a seguinte
ESQL:
java_lang_StackOverflowError no AIX ao Processar um Fluxo de Mensagens
que Contém Nós Java e Usa Java 5
Cenário: Você obtém um encerramento de forma anormal no
AIX ao processar um fluxo de mensagens que contém
nós Java e usa Java 5. O arquivo de encerramento de forma anormal mostra que ocorreu um encerramento de forma anormal que
indica uma falha de segmentação, mas uma verificação do arquivo stderr mostra um estouro
de pilha na JVM:
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)
Explicação:Java 5 possui um parâmetro para
ajustar o tamanho de pilha para encadeamentos Java .
O tamanho de pilha do sistema operacional padrão para
Java 5 é de apenas 256 KB. Em alguns fluxos de mensagens
(por exemplo, fluxos que contêm nós definidos pelo usuário Java ou nós
XMLT), este tamanho pode não ser suficiente e, portanto, você vê um erro de estouro de pilha no arquivo
stderr. Use a opção da JVM -Xmso para ajustar a
pilha do sistema operacional para Java. É possível exibir informações sobre a pilha usando o seguinte comando:
export MQSIJVERBOSE=-verbose:stack,sizes
Este comando cria no arquivo
stderr durante a inicialização uma entrada que tem o seguinte conteúdo ou semelhante:
-Xmca32K RAM class segment increment
-Xmco128K ROM class segment increment
-Xmns0K initial new space size
-Xmnx0K maximum new space size
-Xms125000K initial memory size
-Xmos125000K initial old space size
-Xmox250000K maximum old space size
-Xmx250000K memory maximum
-Xmr16K remembered set size
-Xlp0K large page size
available large page sizes: 4K 16M
-Xmso256K OS thread stack size
-Xiss2K java thread stack initial size
-Xssi16K java thread stack increment
-Xss256K java thread stack maximum size
-Xscmx16M shared class cache size
Nota: O padrão do tamanho de pilha é 256 K.
Solução:
Emita o seguinte comando para configurar o tamanho de pilha do sistema operacional para Java como 2 MB:
export IBM_JAVA_OPTIONS=-Xmso2m
Iniciar novamente o broker.
Problemas ao Utilizar Conversão de Página de Códigos no HP-UX
Cenário: Você tem problemas de conversão de páginas de códigos
no HP-UX.
Solução: Consulte o atributo do gerenciador de filas do WebSphere MQCodedCharSetID. O valor padrão para esse atributo é
1051. Altere esse valor para 819 em gerenciadores de filas que hospedam componentes do WebSphere Message Broker.