Migrando Conjuntos de Mensagens 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. Não é necessário utilizar este comando na migração da Versão 5.0 para a Versão 6.0.

Condições do Comando mqsimigratemsgsets

Não modifique o arquivo do conjunto de mensagens manualmente entre a exportação da Versão 2.1 e a importação para o WebSphere Message Broker Versão 6.0, pois isso causa erros, indicados por mensagens de aviso e de erro no relatório: BIP0141, BIP0142 a BIP0157 e BIP0163.

Cada novo arquivo de definição de mensagem .mxsd é um modelo de esquema XML anotado e cada artefato no conjunto de mensagens é recriado e mantém suas propriedades existentes no novo modelo, com as seguintes exceções:
  • O Nome no modelo do WebSphere Message Broker Versão 6.0 é o Identificador do modelo da Versão 2.1. Se o objeto for um elemento com um identificador prefixado, o prefixo será removido, já que o prefixo da Versão 2.1 era uma maneira de indicar que esse elemento era local.
  • Etiqueta, Descrição Abreviada, Descrição Compra e Histórico são mesclados em uma única propriedade de Documentação para o WebSphere Message Broker Versão 6.0
  • Cada tipo composto torna-se um xsd:complexType e um xsd:group associado no WebSphere Message Broker Versão 6.0.
    O xsd:complexType criado dessa forma pode ser local ou global. O padrão é local, mas torna-se global se qualquer uma das condições a seguir for verdadeira:
    • O tipo composto não é referido
    • O tipo composto tem um tipo base MRM Versão 2.1
    • O tipo composto é referido por mais de um elemento
    • Uma mensagem é baseada no tipo composto
    • O parâmetro -g é especificado
    O xsd:group criado dessa forma pode ser local ou global. O padrão é local, mas torna-se global se qualquer uma das condições a seguir for verdadeira:
    • O tipo composto é incorporado diretamente em outro tipo composto.
    • O tipo composto tem um tipo base MRM Versão 2.1.
    • O tipo composto tem uma composição de tipo Versão 2.1 igual a simpleUnorderedSet e um conteúdo de tipo Versão 2.1 igual a closed.
    A composição do tipo igual a simpleUnorderedSet é eliminada do modelo na WebSphere Message Broker Versão 6.0.
    • Se o conteúdo do tipo for closed, então, será substituído pela composição all com uma mensagem de aviso BIP0191.
    • Caso contrário, será substituído pela composição unorderedSet com uma mensagem de aviso BIP0192.
    • A composição do tipo empty é substituída por sequence vazio com uma mensagem de aviso BIP0193.

  • As mensagens incorporadas com minOccurs ou maxOccurs diferentes de 1 têm as ocorrências corrigidas para 1 com uma mensagem de aviso BIP0162.
  • Cada elemento torna-se um xsd:element. O xsd:element criado dessa forma pode ser local ou global, dependendo dos seguintes critérios aplicados na ordem especificada:
    1. Se o elemento não for referido, ele é global.
    2. Se o elemento tiver um identificador com prefixo e for um membro de exatamente um tipo de composto, ele é local.
    3. Se o elemento tiver um identificador com prefixo e o parâmetro -pl for especificado, ele é local.
    4. Se o elemento for do tipo composto com um tipo base MRM Versão 2.1, ele é local.
    5. Se o elemento for um membro de mais de um tipo composto, ele é global.
    6. Se o parâmetro -g for especificado, ele é global.
    7. Caso contrário, o elemento é local.
    O tipo do xsd:element criado dessa forma pode ser:
  • Quaisquer restrições de valores que pertencem ao elemento são processadas da seguinte forma:
    • Uma restrição Padrão configura o atributo padrão do xsd:element.
    • Uma restrição Nulo Permitido configura o atributo nillable do xsd:element.
    • Uma restrição Gabarito de Data altera o xsd:simpleType do xsd:element. (Consulte Mapeamento de Tipos Simples MRM para Tipos Simples de Esquema.)
    • Todas as demais restringem o xsd:simpleType do xsd:element pela aplicação de xsd:facets.

    Qualquer restrição de valor não referida é descartada com uma mensagem de aviso BIP0158, BIP0159 ou BIP0160.

    Qualquer restrição de valor que resulta na criação de um xsd:facet ilegal não é migrada, mas fornece uma mensagem de aviso BIP0165.
    Nota: Para elementos do tipo STRING somente, as restrições de valor MinInclusive e MaxInclusive são importadas como anotações ocultas para finalidades de documentação, pois não há nenhum xsd:facet equivalente.
  • Os qualificadores de elementos são descartados com uma mensagem de aviso BIP0167 única.
  • Cada mensagem torna-se uma mensagem e um xsd:element global associado.
  • Uma mensagem que utilizou qualificadores de elementos tem a qualificação descartada com uma mensagem de aviso BIP0166.
  • Algumas propriedades de formato físico que eram redundantes na Versão 2.1 e foram removidas do novo modelo. Se for encontrada uma dessas propriedades com um valor não padrão, será emitida uma mensagem de aviso BIP0164 (ou outra mais específica).
  • O valor padrão Janela de Século da propriedade do nível do conjunto de mensagens TDS sempre foi configurado para 53 na Versão 2.1. Para o padrão do sistema de mensagens SWIFT isso é incorreto, portanto, o padrão para SWIFT somente está alterado para 80. Isso é refletido em um modelo importado.

O que o Comando mqsimigratemsgsets Cria

Para cada arquivo .mrp encontrado, um novo projeto de conjunto de mensagens é criado com um nome que é derivado do nome e do nível do conjunto de mensagens na Versão 2.1. O utilitário faz isso incluindo um sufixo no nome do conjunto de mensagens para todos os valores de Nível diferentes de 1. Esse processo restaura o mapeamento de um para um e permite que o intermediário localize somente um conjunto de mensagens, fornecido o nome.

Por exemplo, um conjunto de mensagens Versão 2.1 com o nome SWIFT e Nível 1 migra na Versão 6.0 para o nome de conjunto de mensagens SWIFT, enquanto que um conjunto de mensagens Versão 2.1 com nome SWIFT e Nível 2 migra na Versão 6.0 para SWIFT_2.

Uma pasta do conjunto de mensagens e o arquivo messageSet.mset associado são criados no novo projeto. Os pontos a seguir aplicam-se ao conteúdo do conjunto de mensagens:
  • O nome da pasta do conjunto de mensagens é igual ao do novo projeto.
  • O identificador do conjunto de mensagens é o identificador do conjunto de mensagens original da Versão 2.1.
  • O conjunto de mensagens é criado especificando que os espaços de nomes não são suportados.
  • Todas as camadas de formato físico são recriadas no novo conjunto de mensagens.
  • Qualquer camada de ligação de linguagem COBOL é descartada com uma mensagem de aviso BIP0174.
  • Qualquer camada de ligação de linguagem C é descartada com uma mensagem de aviso BIP0173.
  • Qualquer estado finalizado é descartado com uma mensagem de aviso BIP0170.
  • Quaisquer informações básicas são descartadas com uma mensagem de aviso BIP0172.
  • Quaisquer time stamps pendentes são descartados com uma mensagem de aviso BIP0169. Observe que você sempre recebe essa mensagem, pois a operação de exportação Versão 2.1 congela o conjunto de mensagens.
Cada categoria de mensagem encontrada no arquivo .mrp resulta na criação de um novo arquivo .category. Nota:
  • Cada transação é substituída pela categoria de mensagem equivalente, contendo todas as mensagens da transação.
  • Cada categoria de transação é substituída pela categoria de mensagens equivalente, contendo todas as mensagens de todas as transações referidas pela categoria de transação.

Um único arquivo de definição de mensagem .mxsd é criado no conjunto de mensagens com o mesmo nome que o conjunto de mensagens e no espaço de nomes padrão (notarget), a menos que o parâmetro -part esteja presente.

Se -part estiver especificado, vários arquivos .mxsd poderão ser criados se:
  • O número de mensagens, elementos e tipos compostos do arquivo excedem 1000, e
  • O arquivo .mrp puder ser totalmente particionado em subconjuntos de desconexão.

Na Versão 2.1, todos os elementos e tipos compostos são globais. Na Versão 6.0, xsd:elements e xsd:complex types podem ser global ou local. Ao migrar um conjunto de mensagens Versão 2.1, provavelmente, você irá descobrir que muitos elementos e tipos compostos que eram globais na Versão 2.1 foram convertidos para xsd:elements e xsd:complex types locais na Versão 6.0, de acordo com as regras definidas acima.

Há duas razões para que você deseje substituir esse comportamento:
  • Você prefere a organização da Versão 2.1 de seu conjunto de mensagens, em que todos os objetos são globais. Se você especificar o parâmetro -g, essa organização será mantida enquanto for prática.
  • Você utiliza o tipo composto Conteúdo do Tipo com um valor igual a Abrir Definido.

Isso significa que o conteúdo válido de um tipo composto pode ser qualquer objeto no conjunto de mensagens, sujeito às regras de propriedade de Composição do Tipo. Geralmente, nesse caso, o tipo composto não foi modelado com nenhum conteúdo explícito.

Isso pode fazer com que o comando mqsimigratemsgsets torne determinados elementos locais incorretamente em vez de globais. Se você utilizar Abrir Definido e verificar que após a migração ocorre um erro de validação do tempo de execução BIP5372E, sendo que anteriormente não ocorria, execute o comando mqsimigratemsgsets novamente com o parâmetro -g.

Identificadores Prefixados

Na Versão 2.1, um identificador com prefixo tinha a intenção de indicar que um elemento é local. No entanto, é possível que um elemento com um identificador prefixado seja realmente utilizado em mais de um tipo composto, tornando-o global. Se for, será criado um xsd:element global, de acordo com as regras precedentes Uma mensagem de aviso BIP0195 também é emitida, pois isso é uma má utilização de identificadores prefixados e pode resultar na criação de xsd:elements globais duplicados. Por exemplo, A^X a B^X, são ambos utilizados mais de uma vez, resultando em dois xsd:elements globais com nome X.

Se forem criadas duplicatas, execute o comando mqsimigratemsgsets novamente, especificando o parâmetro -pl. Isso força a criação de todos os elementos referidos com identificadores prefixados como xsd:elements locais.

Tipo simples incorporado

Os tipos simples incorporados em tipos compostos precisam de tratamento especial, porque o modelo de esquema não pode suportar esta construção. Como os tipos simples incorporados estão obsoletos, substitua-os tirando proveito do atributo mixed do tipo xsd:complex de contenção.

Os tipos simples incorporados eram introduzidos principalmente para modelar um elemento XML complexo que continha valores de dados intercalados entre elementos filhos. Cada valor de dados desse tipo era explicitamente modelado por um tipo simples incorporado, que agia como um sinalizador de substituição para o valor e também fornecia seu tipo simples.

No esquema XML, não existe um equivalente exato. O mais próximo é o atributo mixed de xsd:complexType. No entanto, isso indica somente que o texto pode aparecer antes ou entre elementos filhos. Isso implica em nada sobre o local ou tipo de dados do texto.

Para manter esta semântica, é introduzida uma extensão de esquema, chamada de Tipo Simples Incorporado. Esse é um xsd:element local não denominado do tipo simples apropriado. O próprio tipo é uma restrição do xsd:simple type subjacente real, com um nome especial (começando com ComIbmMrm_Anon).

Tipo Composto com um Tipo Base MRM

Essa situação produz uma mensagem de aviso BIP0161 e precisa de tratamento especial, pois o modelo do esquema não pode lidar com essa construção composta. Elementos compostos estão obsoletos, portanto, substitua a utilização de elementos compostos pela utilização de elementos normais que fazem referência ao xsd:complexType global, conforme descrito em 1 abaixo e tire proveito do atributo misto.

Esses tipos compostos foram introduzidos principalmente para modelar um elemento XML complexo que continha um valor de dados e também elementos filhos. Portanto, um elemento desse tipo complexo possui conteúdo complexo como um elemento complexo normal, mas também possui um valor como um elemento simples (as informações de tipo base MRM).

No esquema XML, não existe um equivalente exato. O mais próximo é a utilização do atributo misto do xsd:complexType. Mas isso só informa que pode haver texto antes e entre (ou somente entre) elementos filhos. Isso implica em nada sobre o local ou tipo de dados do texto.

Não há nenhum equivalente exato no esquema XML, portanto, as etapas a seguir foram efetuadas:
  1. Um xsd:complexType global e um xsd:group são criados de forma normal. O xsd:complexType ainda possui atributo mixed configurado e seu conteúdo é somente uma referência ao xsd:group global. Isso modela o conteúdo complexo, mas perde as informações do tipo base MRM.
  2. É introduzida uma extensão de esquema específica, o Elemento Composto. Essa é uma combinação de um elemento complexo e de um elemento simples. É implementada em termos de esquema como um elemento com um tipo complexo anônimo, o conteúdo desse tipo sendo:
    • Um xsd:element local do tipo simples apropriado (para modelar as informações do tipo base MRM). O tipo simples é uma restrição do xsd:simple type subjacente real, com um nome especial (começando com ComIbmMrm_BaseValue).
    • Uma referência de grupo ao xsd:group global criado em 1 acima.

Um elemento composto é criado para cada elemento que fez referência ao tipo composto. Observe que isso pode ser feito somente se o elemento era um membro de outro tipo composto.

A combinação dessas duas coisas significa que a utilização significativa desses tipos compostos em uma mensagem é preservada, pois as informações do tipo base MRM são perdidas somente quando nunca tiverem sido utilizadas ativamente em uma mensagem.

Os tipos de dados especiais criados pelas situações descritas nas seções anteriores, começando por ComIbmMrm, são definidos em um esquema XML chamado .wmq21.mxsd que está incluído em cada arquivo de definição de mensagem criado pelo comando mqsimigratemsgsets.

Mapeamento de Tipos Simples MRM para Tipos Simples de Esquema

O mapeamento de tipo simples é o seguinte:
Tipo MRM Tipo de esquema
BINARY xsd:hexBinary
BOOLEAN xsd:boolean
DECIMAL xsd:decimal
DATETIME xsd:dateTime (consulte a tabela a seguir)
FLOAT xsd:float
INTEGER xsd:int
STRING xsd:string
Para o tipo DATETIME, o mapeamento de tipo simples forçosamente é alterado pela presença de uma restrição de valor de Gabarito de Data, da seguinte forma:
Gabarito de Data MRM DATETIME Tipo de esquema
CCYY-MM-DDThh:mm:ss.s xsd:dateTime
CCYY-MM-DD xsd:date
CCYY-MM xsd:gYearMonth
CCYY xsd:gYear
--MM-DD xsd:gMonthDay
--MM xsd:gMonth
---DD xsd:gDay
Thh:mm:ss.s xsd:time

Se o Gabarito de Data não estiver na lista anterior, o DATETIME será mapeado para um xsd:time ou um xsd:dateTime com uma mensagem de aviso BIP0175, dependendo de se o Gabarito de Data tinha somente um componente de tempo. No entanto, observe que este mapeamento pode causar erros na lista de tarefas após a importação.

Se o elemento em questão também tinha as restrições de valor Versão 2.1 Valor Padrão, Mín. Inclusive, Máx. Inclusive ou Enumeração, os valores dessas restrições não correspondem ao espaço léxico de um xsd:time ou xsd:dateTime e, portanto, falham na validação. Devem ser corrigidos manualmente utilizando-se o editor.

O mesmo erro de lista de tarefas também aparece para qualquer tipo DATETIME Versão 2.1 que tenha fornecido uma restrição Valor Padrão, Mín. Inclusive, Máx. Inclusive ou Enumeração na qual o valor não foi completamente especificado. Por exemplo, o Gabarito de Data CCYY-MM, Enumeração 2003 era permitido na Versão 2.1, pois era interpretado como 2003-01 no tempo de execução. No entanto, no novo modelo, o valor deve corresponder ao espaço léxico do tipo simples e, portanto, deve incluir -01.

Conceitos relacionados
Conceitos de Modelagem de Mensagens
Tarefas relacionadas
Migrando um Conjunto de Mensagens
Referências relacionadas
Comando mqsimigratemsgsets
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ad15750_