Notas sobre Migração de Conjuntos de Mensagens

Leia estas notas para ajudá-lo a migrar conjuntos de mensagens para o WebSphere Message Broker Versão 6.0.

Este tópico contém as seguintes seções:

Se você estiver utilizando o Message Brokers Toolkit Versão 5.1, substitua todas as referências nesse tópico para "Versão 5.0" por "Versão 5.1".

Migrando da Versão 2.1

Para migrar conjuntos de mensagens da Versão 2.1 para a Versão 6.0, utilize o comando mqsimigratemsgsets para converter os arquivos de exportação do conjunto de mensagens (.mrp) da Versão 2.1 para projetos do conjunto de mensagens da Versão 6.0. Antes de executar o comando, consulte o tópico Migrando Conjuntos de Mensagens da Versão 2.1, que fornece notas detalhadas sobre sua operação.

Para obter orientação sobre alterações no comportamento de analisadores e para obter informações gerais de migração, consulte as seguintes seções:

Migrando da Versão 5.0

Para migrar conjuntos de mensagens da Versão 5.0 para a Versão 6.0, não são necessários comandos de migração. O Message Brokers Toolkit Versão 6.0 pode ler o conteúdo de um projeto de conjunto de mensagens Versão 5.0 e convertê-lo automaticamente para o formato Versão 6.0 quando for modificado e salvado pela primeira vez.

Para obter orientação sobre alterações no comportamento de analisadores e para obter informações gerais de migração, consulte as seguintes seções:

Alterações Comportamentais no Analisador MRM

    As alterações a seguir são implementadas na Versão 6.0 e são relevantes quando você migra da Versão 5.0 e da Versão 2.1:
    • Formato físico XML. A Versão 6.0 é sensível aos atributos xsi:type o documento XML e modifica seu comportamento de forma apropriada. Os atributos xsi:type não são mais tratados como atributos de definição automática, portanto, eles aparecem na árvore de mensagens com o nome ‘type' em vez de ‘@type'. Se a lógica do fluxo de mensagens considerar atributos xsi:type na árvore de mensagens, altere seu fluxo de mensagens para ficar de acordo com o novo comportamento. Para manter a lógica da pré-Versão 6.0 em seus fluxos de mensagens, configure a variável de ambiente MQSI_IGNORE_XSI_TYPE como qualquer valor e o comportamento da pré-Versão 6.0 será adotado.
    • Formato físico XML. As informações de DOCTYPE em um documento XML não aparecem na árvore de mensagens lógicas quando analisadas, mas são preservadas do documento de entrada para o documento de saída, porque o MRM mantém uma cópia do DOCTYPE internamente. Antes da Versão 6.0, esses dados são uma cópia exata do fluxo de bits. Na Versão 6.0, o processo de cópia causa a perda de alguns espaços em branco de formatação. O exemplo a seguir mostra uma declaração de elemento em um DOCTYPE de entrada:
      <!ELEMENT e0 (e1|e2)+ >
      Na mensagem de saída, a declaração do elemento é alterada:
      <!ELEMENT e0 (e1|e2)+>
      O novo comportamento é consistente com a forma que o formato físico XML processa espaço em branco em todas as demais construções XML.
    • Formato físico TDS. Para um grupo com a propriedade lógica Composição configurada como Opção e a propriedade TDS Separação de Elementos de Dados configurada como Comprimento Fixo, o analisador sempre assumirá que o comprimento dos dados da opção é o do filho mais longo do grupo e sempre lerá e gravará esse número de caracteres. Certifique-se de que suas mensagens estejam de acordo com esta suposição; caso contrário, o analisador tratará os dados que seguem a opção como parte da opção. Antes da Versão 6.0, o analisador não aplica essa regra.
    • Formato físico TDS. Se a propriedade do elemento de TDS Codificação Nula estiver configurada como NullPadFill, ocorrerá uma ação nela apenas se a propriedade Comprimento correspondente estiver sendo utilizada ativamente durante a análise ou gravação. Antes da Versão 6.0, NullPadFill recebe uma ação independentemente da propriedade Comprimento estar sendo utilizada ativamente.
    • Formato físico TDS. A propriedade de TDS Separação de Elemento de Dados está configurada como Todos os Elementos Delimitados ou Elementos de Comprimento Variável Delimitados. Um elemento complexo a partir de agora sempre será tratado como tendo comprimento variável, independentemente de sua própria configuração de Separação de Elemento de Dados. Portanto, é esperado um Delimitador no fluxo de bits da mensagem entre o elemento complexo e qualquer elemento subseqüente e é esperado um Delimitador de Elemento de Repetição entre todas as instâncias de um elemento complexo, mesmo que o elemento complexo tenha um comprimento fixo. Antes da Versão 6.0, o analisador não aplica essa regra e, para Elementos de Comprimento Variável Delimitado, o escritor não exibe delimitadores quando o comprimento do elemento completo é conhecido.
    • Formato físico TDS. A propriedade de TDS Separação de Elemento de Dados está configurada como Utilizar Padrão de Dados. Se a expressão comum especificada para um padrão de dados retornar uma correspondência de comprimento zero, ela será tratada como um elemento com um valor de comprimento zero. Antes da Versão 6.0, uma correspondência de comprimento zero é tratada como um elemento sendo omitido.
    • Formato físico TDS. A propriedade de TDS Separação de Elemento de Dados está configurada como Ativado Delimitado. Um delimitador externo que ocorre após o último filho do grupo no fluxo de bits não é mais tolerado e causará uma exceção de análise. Se este for um problema, é recomendável modelar o delimitador externo utilizando a propriedade TDS Terminador de Grupo. Antes da Versão 6.0, o analisador não aplica essa regra.
    • Formato físico TDS. A propriedade de TDS Separação de Elemento de Dados está configurada como Ativado Delimitado. Na Versão 6.0, ao analisar um grupo Ativado Delimitado, o analisador tenta dar sentido aos grupos nos quais os membros aparecem fora de ordem no fluxo de bits da mensagem, mesmo que a propriedade Composição do grupo esteja configurada como Seqüência ou OrderedSet. No entanto, se o grupo contiver uma mensagem incorporada ou um elemento ou grupo complexo que não pode ser identificado a partir do fluxo de bits, todos os membros do grupo devem aparecer no fluxo de bits na mesma ordem que estão definidos no modelo. Se eles aparecerem fora de ordem, o grupo não será analisado corretamente e terá resultados imprevisíveis. Um sintoma desta condição é a aparência de elementos de autodefinição na árvore de mensagens, causada por uma falha ao corresponder um elemento ao modelo.

      Um exemplo específico desta condição é onde sua mensagem contém uma mensagem integrada e você está utilizando a técnica de Chave de Mensagem ou Identidade da Mensagem para identificar a mensagem integrada. Se o elemento que está fornecendo o valor da chave de mensagem ou da identidade de mensagem não for correspondido com o modelo, o analisador não saberá se seu valor deve ser interpretado como uma chave de mensagem ou uma identidade de mensagem.

      Antes da Versão 6.0, o analisador tenta dar sentido a todos os grupos Ativados Delimitados fora de ordem, com uma conseqüente redução no desempenho. Na Versão 6.0, se este comportamento for um problema, será recomendável modelar o conteúdo não ordenado do grupo como um grupo de filhos integrado com Composição configurada como UnorderedSet.

      Um elemento complexo ou grupo pode ser identificado no fluxo de bits se fornecer um indicador de grupo, uma tag ou um padrão de dados ou se seus membros filhos fornecerem um indicador de grupo, uma tag ou um padrão de dados.

      Apesar de seu nome, em algumas circunstâncias, os membros de um grupo Marcado Delimitado não precisam fornecer uma tag; especificamente, se o membro for uma mensagem integrada ou um elemento complexo ou grupo.

    • Formato físico TDS. A propriedade de TDS Separação de Elemento de Dados está configurada como Comprimento Ativado Codificado. Durante a gravação, o comprimento codificado é gravado como o número de caracteres nos dados, para corresponder à interpretação durante a análise. Antes da Versão 6.0, o comprimento codificado é gravado como o número de bytes nos dados, que não corresponde à interpretação durante a análise se os dados não forem SBCS.
    • Formato físico TDS. Quando os dados são gravados, se o número de repetições de um elemento ou grupo for fixo no modelo, mas as ocorrências em si na árvore de mensagens lógicas exceder o número de repetições e a propriedade Separação de Elemento de Dados não for uma das separações "Ativadas", as ocorrências extras são descartadas e não aparecerão na mensagem de saída. Antes da Versão 6.0, as ocorrências extras aparecem na mensagem de saída. Se for esperado que as repetições extras apareçam na mensagem de saída, especifique maxOccurs=-1 para indicar que o número de repetições seja ilimitado.
    • Todos os formatos físicos. Ao gravar campos dateTime que tê uma propriedade Formato igual a I, o formato da saída dependerá do tipo lógico do campo, conforme descrito em DateTime como Dados de Cadeia. Antes da Versão 6.0, o formato da saída é incorretamente o formato completo yyyy-MM-dd'T'HH:mm:ssZZZ.
    • A validação de mensagens de entrada e de saída foi aprimorada para fornecer detecção adicional de mensagens inválidas. Portanto, na Versão 6.0, uma mensagem pode ser marcada como inválida quando não tiver sido corretamente marcada em versões anteriores.

Informações Gerais de Migração

Os itens a seguir são relevantes quando você migra da Versão 5.0 e da Versão 2.1:
  • A propriedade do CWF Contagem de Repetições foi substituída pela propriedade lógica Máximo de Ocorrências, alinhando o formato físico do CWF com os formatos físicos TDS e XML, que já utilizam Máximo de Ocorrências para determinar o número de repetições. Aparece um aviso na visualização Problemas do editor de mensagem para cada elemento ou grupo que tinha um conjunto de valores de Contagem de Repetições. Clique com o botão direito do mouse no aviso e clique em Correção Rápida para resolver o problema.

    Na Versão 5.0, se a propriedade do CWF Contagem de Repetições não estiver configurada e Mínimo de Ocorrências não for igual a Máximo de Ocorrências, o número de repetições será assumido como um. Na Versão 6.0, o número de repetições é considerado como Máx. de Ocorrências. Um aviso não pode ser gerado para esta situação. Tal modelo de mensagem não é criado pelos importadores COBOL ou C, portanto, ele pode ocorrer apenas se você tiver criado um modelo de mensagem CWF utilizando o editor de mensagem da Versão 5.0.

  • O formato físico TDS anterior à Versão 6.0 incluía identificação de mensagem incorporada pela Chave de Mensagem. A técnica da Chave de Mensagem foi reprovada e substituída por uma técnica chamada Identidade da Mensagem. Aparece um aviso na visualização Problemas do editor de mensagem para cada mensagem que possui um valor de Chave de Mensagem de TDS e para cada elemento ou atributo que possui uma propriedade Interpretar Valor do Elemento de TDS configurada como Chave de Mensagem. Clique com o botão direito do mouse no aviso e clique em Correção Rápida para resolver o problema.

    Continue utilizando a Chave de Mensagem de TDS se o conjunto de mensagens for implementado sempre para um intermediário da Versão 5.0 ou da Versão 2.1, porque estes intermediários não suportam a técnica de Identidade da Mensagem de identificação de mensagem incorporada.

  • A propriedade de formato físico de TDS Padrão de Dados agora é validada pelo Message Brokers Toolkit para assegurar que ela seja um expressão comum de Esquema XML válida. Aparecem erros na visualização Problemas do editor de mensagem e é necessário corrigi-los manualmente utilizando o editor. Em específico, são emitidos alguns erros na especificação do Esquema XML relacionados ao escape de metacaracteres, que causam erros de validação. Para corrigir os erros, pode ser necessário escapar o caractere hífen (-) os os caracteres chaves ({) e (}), utilizando o caractere barra invertida (\); por exemplo, \{ ou \-. Se você receber tais erros ao utilizar um conjunto de mensagens fornecido pela IBM, entre em contato com a IBM para obter uma versão correta do conjunto de mensagens.
  • O valor padrão ou valor fixo de um elemento ou atributo e os valores de enumeração de um tipo simples agora são verificados nos aspectos de comprimento, comprimento máximo e comprimento mínimo do tipo simples, se fornecido. Se um valor não estiver de acordo com os aspectos, aparecerá um erro na visualização Problemas do editor de mensagem. Clique com o botão direito do mouse no erro e clique em Correção Rápida para resolver o problema, se houver uma correção rápida disponível. Caso contrário, corrija o problema manualmente utilizando o editor. Esse erro mais provavelmente ocorrerá se você importar um copybook COBOL para a Versão 5.0 Fix Pack 2 ou versão anterior do Message Brokers Toolkit.
  • As propriedades CWF e TDS Codificação Nula e Valor de Codificação Nula foram removidas de atributos locais, atributos globais e referências de atributo. No Esquema XML, apenas elementos podem ter uma propriedade Nillable, portanto, um valor nulo não pode ser suportado por um campo de dados modelado como um atributo. Se você tiver especificado valores de CWF ou TDS de Codificação Nula para atributos na Versão 5.0, eles serão ignorados.
  • A propriedade de TDS Delimitador de Elemento de Repetição foi removida de atributos locais e de referências de atributos. No Esquema XML, os atributos não podem ser repetidos. Se você tiver especificado valores de TDS de Delimitador de Elemento de Repetição para atributos na Versão 5.0, eles serão ignorados.
  • Para um elemento ou atributo com tipo simples xsd:gMonth, o valor padrão para a propriedade de CWF, XML e TDS Formato de Datetime agora é "--MM". Na Versão 5.0, o valor padrão é "--MM--". Este valor foi corrigido para ficar em conformidade com uma erra do Esquema XML.
  • Quando estiver migrando, não é necessário implementar novamente seus conjuntos de mensagens, pois o comando mqsimigratecomponents atualiza os dicionários de mensagem no banco de dados do intermediário para o formato da Versão 6.0. No entanto, se você não reimplementar um conjunto de mensagens e observar uma ParserException, como "verificado erro de vetor" ou "violação de acesso", quando utilizar pela primeira vez um fluxo de mensagens que utiliza o conjunto de mensagens, será necessário reimplementar o conjunto de mensagens. Esta situação pode ocorrer se o dicionário de mensagem contiver dados inválidos não detectados anteriormente. Na Versão 6.0, um dicionário de mensagem é verificado na primeira utilização; na Versão 2.1 e Versão 5.0, ele não é.
Tarefas relacionadas
Migrando um Conjunto de Mensagens
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última atualização : 2009-02-13 16:12:37

ah20250_