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á utilizando o recurso de
enfileiramento de mensagens do
Message
Brokers Toolkit para colocar mensagens
nas 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 e depois reabra o 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 de Cabeçalho Têm Qualquer Efeito no Enqueue
Cenário: Ao utilizar o editor Enqueue, o token de contabilidade,
o ID de correlação, o ID de grupo e o ID de mensagem no cabeçalho da mensagem
parece não ter qualquer efeito.
Explicação: Esses campos não têm nenhum efeito, pois 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 mensagem enfileirados ainda permanecem listados
no menu drop-down após terem sido excluídos.
Explicação: Os arquivos enfileirados excluídos não
são removidos do menu drop-down.
A seleção desses arquivos não
tem nenhum efeito.
A Transformação ESQL de uma Mensagem XML Dá Resultados Inesperados
Cenário: Você criou uma mensagem XML que se parece
com esta:
<?xml version ="1.0" standalone="no"?><!DOCTYPE doc
[<!ELEMENT doc (#PCDATA)*>]><doc><I1>100</I1></doc>
Você aplica a transformação ESQL:
SET OutputRoot.XMLNS.doc.I1 = 112233;
Esta transformaçã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 doc do corpo da mensagem, identifique explicitamente o segundo
elemento doc, assim:
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 carro 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 carro são aceitos em um documento XML, mas um analisador de XML normaliza quaisquer caracteres de alimentação de linha de retorno de carro em um único caracteres de alimentação 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.
Observe que não é possível uma solução alternativa para esse problema incorporando seus dados em uma seção CDATA; a especificação XML determina que uma seção CDATA tem a intenção somente de fazer escape de blocos de texto que contêm caracteres que poderiam 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: Os dados compatíveis com XML não devem depender da presença de caracteres
de alimentação de linha de retorno de carro porque, em XML, o caractere de alimentação de linha
é apenas um caractere de alimentação de linha e qualquer aplicativo ou dados compatíveis com XML devem
estar cientes de que o analisador normaliza os caracteres de alimentação de linha de retorno de carro.
O Intermediário 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 intermediário 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 intermediário 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ó XMLTransformation
no z/OS
Cenário: Ao utilizar o nó XMLTransformation
no z/OS, todos os Os
maiúsculos que estão em um arquivo XML na mensagem que chega são alterados para
caracteres sublinhados.
Explicação: A mensagem de entrada do nó XMLTransformation
deve vir como ASCII para que a transformação funcione corretamente. O nó XMLTransformation 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 muito 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, verifique se o aplicativo de envio é alterado para representar isso como dados codificados de binário codificado básico.
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 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: Procure qualquer uma das condições de erro listadas acima
e retifique-a.
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 ligado, 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 ligado ou a propagação pelo fluxo de captura falhar, o processamento desse tempo limite será
recuperado.
Solução: Certifique-se de que os terminais Failure e Catch de seu
nó TimeoutNotification estejam ligados
corretamente.
Uma Mensagem CWF de MRM é Propagada para o Terminal Failure
Cenário: A mensagem CWF de MRM é propagada para um
terminal Failure 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 esses campos são atributos será perdido. Essa 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 seqüê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, conseqüentemente, 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.
Ou então, adote um rastreio de depuração de usuário do fluxo de mensagens; as mensagens BIP5493W indicam quais campos estão sendo gravados como auto-definitivos. Utilize essas informações para garantir que a árvore de mensagens corresponda ao modelo. Depois que você tiver corrigido quaisquer discrepâncias, os atributos deverão estar corretamente gravados.
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, utilizando a função ESQL ASBITSTREAM, e utilize a cláusula ESQL CREATE PARSE para analisar novamente a mensagem utilizando 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, utilizando a função ESQL ASBITSTREAM, e utilize a cláusula ESQL CREATE PARSE para analisar novamente 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: Há duas possíveis razões para isso:
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 intermediário
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 intermediário 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 intermediário aceitará o valor especificado e transmitirá
os valores padrão para o analisador a fim de criar a árvore de mensagens.
Da mesma forma, se você
configurar XML na pasta Propriedades para a mensagem de saída no nó Compute,
este valor será transmitido 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
intermediário 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.BIPv600
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 digitado incorretamente o
identificador do formato definido, corrija o 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 espaços de nomes 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. Esse é um problema conhecido com o analisador.
Problemas Encontrados Quando Mensagens Contêm Caracteres de Avanço de Linha EBCDIC
Cenário: Se sua mensagem de entrada de fluxo de
bits contiver caracteres EBCDIC NL (New Line), podem surgir problemas
se o 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 um
ponto de código correspondente para o caractere de Nova Linha na página de códigos ASCII.
Solução: Você pode superar o problema
nestes casos:
Em um sistema em que o gerenciador de filas utiliza um conjunto de códigos ASCII,
certifique-se de que as mensagens que chegam não contenham nenhum caractere EBCDIC NL fazendo o seguinte:
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 caracteres, você poderá utilizar conjuntos de mensagens
MRM Marcados/Delimitados em um nó Compute
para substituir o caractere NL pela saída desejada.
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: Procure a mensagem MIME para qualquer uma das condições de erro
listadas acima e retifique-a.
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.
Partes possui um elemento de único valor e esse elemento não é o primeiro nem o último
filho de Parts.
Parts possui filhos que não são elementos de único valor ou filhos de Part.
Parts não possui nenhum filho chamado Part.
O último filho de um elemento Data não é um BLOB.
Solução: Procure a árvore de mensagens lógica MIME para qualquer uma das
condições de erro listadas acima e retifique-a.
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 transmitida a uma função ESQL ou procedimento que continha instruções CREATE similares a essas. Você não especificou um analisador próprio utilizando a cláusula DOMAIN na instrução CREATE.
Uma árvore de mensagens de MRM fou construída e apenas uma parte dela foi transmitida, especificando uma subpasta ou um campo, para a função ASBITSTREAM com a opção de modo de analisador configurada para 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-se de que a associação de analisador próprio seja mantida, serializando primeiro e depois analisando a mensagem na árvore de mensagens apropriada. Um exemplo de cenário é onde você criou um campo:
SET Environment.Variables.myMsg = InputRoot.XMLNS;
e agora precisa transmiti-lo para a função ASBITSTREAM. A menos que você utilize ESQL similar ou equivalente a:
o resultado será 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ê criar 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 intermediário 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 intermediário 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
e, em seguida, chama 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 ser utilizado
na mensagem JMS no domínio BLOB e, em seguida, chamar o procedimento acima
a partir de um nó Compute. O procedimento
pode ser chamado utilizando 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 intermediário 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:
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.