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.

Quando utilizar este comando, observe o seguinte

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 causaria 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 e Longa e Histórico são mesclados em uma única propriedade 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 assim criado pode ser local ou global. O padrão é local, mas torna-se global se qualquer uma das seguintes opções 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 assim criado pode ser local ou global. O padrão é local, mas torna-se global se qualquer uma das seguintes opções for verdadeira:
    • O tipo composto é incorporado diretamente em outro tipo composto.
    • O tipo composto tem um tipo base MRM Versão 2.1. Consulte Tipo Composto com um Tipo Base MRM para obter informações adicionais.
    • 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 de tipo 'simpleUnorderedSet' é eliminada do modelo no WebSphere Message Broker Versão 6.0.
    • Se o conteúdo de tipo for 'closed', ele será substituído pela composição 'all' com uma mensagem de aviso BIP0191.
    • Caso contrário, ele será substituído pela composição 'unorderedSet' com uma mensagem de aviso BIP0192.
    • A composição de tipo 'empty' é substituída por um 'sequence' vazio com uma mensagem de aviso BIP0193.

  • As mensagens incorporadas com minOccurs ou maxOccurs não iguais a 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 assim criado pode ser local ou global, dependendo dos seguintes critérios aplicados na ordem especificada:
    1. Se o elemento não for referido, ele será global
    2. Se o elemento tiver um identificador prefixado e for um membro exatamente de um tipo composto, ele será local
    3. Se o elemento for um identificador com prefixo e o parâmetro -pl for especificado, ele é local
    4. Se o elemento tiver um tipo composto com um tipo base MRM Versão 2.1 ele será local
    5. Se o elemento for membro de mais de um tipo composto, ele será global
    6. Se o parâmetro -g estiver especificado, ele será global
    7. De outra maneira, o elemento será local.
    O tipo de xsd:element assim criado pode ser:
  • Quaisquer restrições de valores que pertencem ao elemento são processadas da seguinte forma:
    • Uma restrição Padrão define o atributo 'default' do xsd:element;
    • Uma restrição Nulo Permitido define 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: Somente para os elementos do tipo STRING, restrições de valor MinInclusive e MaxInclusive são importadas como anotações ocultas para finalidades de documentação, já que 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 de 'Janela Século' da propriedade de nível do conjunto de mensagens TDS era sempre definido como '53' na Versão 2.1. Para o padrão do sistema de mensagens 'SWIFT', isso era incorreto, portanto, o padrão para 'SWIFT' é apenas alterado para '80'. Isso é refletido em um modelo importado.

O que o mqsimigratemsgsets Cria

Para cada arquivo .mrp encontrado, é criado um novo projeto do conjunto de mensagens com um nome derivado do nome e nível do conjunto de mensagens na Versão 2.1. O utilitário faz isso incluindo um sufixo ao nome do conjunto de mensagens para todos os valores de Nível diferentes de "1". Este processo restaura o mapeamento um para um e permite que o intermediário localize apenas um conjunto de mensagens sendo especificado 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 do conjunto de mensagens "SWIFT", enquanto que um conjunto de mensagens Versão 2.1 com o 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 itens 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 mensagens 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 da transação é substituída pela categoria de mensagem equivalente, contendo todas as mensagens de todas as transações referidas pela categoria da 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 no arquivo .mrp exceder 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 globais ou locais. 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 é mantida enquanto for prática.
  • Você utiliza um tipo composto Conteúdo do Tipo com um valor igual a Aberto 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, neste 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 Aberto Definido e descobrir que, após a migração, um erro de validação de tempo de execução BIP5372E ocorre, quando não o fazia anteriormente, deverá reexecutar o comando mqsimigratemsgsets com o parâmetro -g.

Identificadores Prefixados

Na Versão 2.1, um identificador prefixado destinava-se a 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 e B^X, mas ambos são utilizados mais de uma vez, resultando em dois xsd:elements globais com o nome X.

Se duplicados tiverem sido criados, é possível executar 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 era explicitamente modelado por um tipo simples incorporado, que agia como um marcador 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 'compound'. Como os elementos compostos foram reprovados, é altamente recomendável substituir a utilização de elementos compostos pela utilização de elementos normais que fazem referência ao xsd:complexType global descrito em 1 abaixo e tirar vantagem do atributo 'mixed'.

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 equivalente mais próximo é a utilização do atributo 'mixed' de xsd:complexType.Mas isso apenas indica que o texto pode aparecer antes e entre (ou entre) elementos filhos. Isso implica em nada sobre o local ou tipo de dados do texto.

Como não existe nenhum equivalente exato no esquema XML, foi feito o seguinte:
  1. Um xsd:complexType global e um xsd:group são criados de forma normal. O xsd:complexType adicionalmente possui o atributo 'mixed' definido e seu conteúdo é apenas 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.

É criado um elemento composto para cada elemento que fez referência ao tipo composto.Observe que isso pode ser feito apenas se o próprio elemento for membro de outro tipo composto.

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

Os tipos de dados especiais criados pelas situações descritas nas seções anteriores, começando com ComIbmMrm estão definidos em um esquema XML chamado .wmq21.mxsd, que é 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, também, 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 restrições de valores de Valor Padrão, Mínimo Inclusivo, Máximo Inclusivo ou Enumeração na Versão 2.1, os valores dos mesmos não correspondem ao espaço léxico para um xsd:time ou xsd:dateTime e, portanto, a validação falha. Eles devem ser corrigidos manualmente utilizando o editor.

O mesmo erro da lista de tarefas também aparece para qualquer tipo DATETIME da Versão 2.1 que forneceu uma restrição de valor de Valor Padrão, Mínimo Inclusivo, Máximo Inclusivo ou Enumeração em que o valor não foi totalmente especificado. Por exemplo, 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 o '-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, 2005 Última Atualização: 04/11/2005
ad15750_