Notas sobre Migração de Conjuntos de Mensagens

Este tópico explica o que é necessário fazer com cada arquivo de definição de mensagens ao migrar.

É necessário estar ciente das seguintes informações sobre cada arquivo de definição de mensagem ao utilizar o Comando mqsimigratemsgsets.

Notas para o Usuário

É altamente recomendável não modificar o arquivo do conjunto de mensagens manualmente entre a exportação da Versão 2.1 e a importação para a Versão 5.0 do , porque os resultados não são garantidos. Isso pode ser indicado pela presença das seguintes mensagens de aviso e de erro no relatório (BIP0141, BIP0142 a BIP0157, BIP0163)

Cada novo arquivo de definição de mensagem .mxsd é um modelo de esquema anotado e cada artefato no conjunto de mensagens é recriado e mantém suas propriedades existentes nesse novo modelo, com as seguintes exceções:
  • O Nome no modelo do Versão 5.0 é o Identificador no modelo da Versão 2.1.Observe que, se o objeto for um elemento com um identificador prefixado, o prefixo será removido, pois o prefixo na Versão 2.1 era uma forma de indicar que esse elemento era realmente local.
  • Rótulo, Descrição Longa e Curta e Histórico são mesclados em uma única propriedade Documentação para o Versão 5.0
  • Cada tipo composto se torna um xsd:complexType e um xsd:group no Versão 5.0.
    O xsd:complexType assim criado pode ser local ou global.O padrão é local, mas será substituído por global se qualquer uma das seguintes condições for verdadeira:
    1. O tipo composto não é referido
    2. O tipo composto possui um tipo base do MRM Versão 2.1
    3. O tipo composto é referido por mais de um elemento
    4. Uma mensagem é baseada no tipo composto
    5. O parâmetro -g é especificado
    O xsd:group assim criado pode ser local ou global.O padrão é local, mas será substituído por global se qualquer uma das seguintes condições for verdadeira:
    1. O tipo composto é incorporado diretamente em outro tipo composto.Consulte Tipo simples incorporado para obter informações adicionais.
    2. O tipo composto possui um tipo base do MRM Versão 2.1. Consulte Tipo Composto com um Tipo Base MRM para obter informações adicionais.
    3. O tipo composto possui uma composição de tipo da Versão 2.1 de 'simpleUnorderedSet' e um conteúdo de tipo da Versão 2.1 de 'closed'

    Observe que a composição de tipo de 'simpleUnorderedSet' é eliminada do modelo no Versão 5.0.Se o conteúdo de tipo for 'closed', ele será substituído por 'all' com uma mensagem de aviso BIP0191; de outra maneira, será substituído por 'unorderedSet' com uma mensagem de aviso BIP0192.

    A composição do tipo 'vazio' é substituída por uma 'seqüência' vazia 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 tiver um tipo composto com um tipo base do MRM Versão 2.1, ele será local
    4. Se o elemento for membro de mais de um tipo composto, ele será global
    5. Se o parâmetro -g estiver especificado, ele será global
    6. De outra maneira, o elemento será local.

    Na Versão 2.1, um identificador prefixado destinava-se a indicar que um elemento era realmente 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 elemento global de acordo com as regras precedentes

    Também é emitida uma mensagem de aviso BIP0195, porque essa é uma utilização incorreta de identificadores prefixados e pode resultar na criação de elementos globais duplicados. Por exemplo, A^X e B^X, mas ambos são utilizados mais de uma vez, resultando em dois elementos globais com o nome X.

    O tipo de xsd:element assim criado é:
    1. Um xsd:complexType global
    2. Um xsd:complexType local anônimo
    3. Um esquema interno xsd:simpleType. Consulte o Mapeamento de Tipos Simples MRM para Tipos Simples de Esquema
    4. Um xsd:simpleType anônimo que restringe um esquema interno xsd:simpleType
  • Quaisquer restrições de valores que pertencem ao elemento são processadas da seguinte forma:
    1. Uma restrição Padrão define o atributo 'default' do elemento;
    2. Uma restrição Nulo Permitido define o atributo 'nillable' do elemento.
    3. Uma restrição Gabarito de Data altera o xsd:simpleType do elemento.Consulte o Mapeamento de Tipos Simples MRM para Tipos Simples de Esquema
    4. Todas as demais restringem o xsd:simpleType do elemento 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 resulte na criação de um xsd:facet inválido não será migrada, com uma mensagem de aviso BIP0165.
    Nota: Para elementos somente do tipo STRING, as restrições de valor MinInclusive e MaxInclusive serão importadas então como anotações ocultas para fins de documentação.
  • Os qualificadores de elementos são descartados com apenas uma mensagem de aviso BIP0167.
  • Cada mensagem se torna uma mensagem e um xsd:element global associado.
  • Uma mensagem que utilizou qualificadores de elementos terá 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 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 adicionando 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 da Versão 2.1 com o nome "SWIFT" e Nível "1" migra na Versão 5.0 para o conjunto de mensagens com o nome "SWIFT", enquanto um conjunto de mensagens da Versão 2.1 com o nome "SWIFT" e Nível "2" migra na Versão 5.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 data e hora pendentes são descartadas com uma mensagem de aviso BIP0169. Observe que você sempre recebe esta mensagem.
Cada categoria de mensagens encontrada no arquivo .mrp resulta na criação de um novo arquivo .category.Observe que o conceito de um:
  • Objeto de transação é eliminado na Versão 5.0 e cada transação é substituída pela categoria de mensagens equivalente
  • Objeto de categoria de transações é eliminado na Versão 5.0 e cada categoria de transações é substituída pela categoria de mensagens equivalente, contendo todas as mensagens em todas as transações referidas pela categoria de transações.

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 5.0, os elementos e tipos complexos podem ser globais ou locais. Ao migrar um conjunto de mensagens da Versão 2.1, é provável que você observe que vários elementos e tipos compostos que eram globais na Versão 2.1 foram convertidos a elementos locais e tipos complexos na Versão 5.0, de acordo com as regras determinadas 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, no qual todos os objetos são globais. Se você especificar o parâmetro -g, essa organização é mantida enquanto for prática.
  • Você utiliza o valor Conteúdo do Tipo do tipo composto 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, neste caso, o tipo composto não foi modelado com nenhum conteúdo explícito.

    Isso pode fazer com que o comando deduza incorretamente que determinados elementos devem tornar-se locais em vez de globais. Se você utilizar Abrir 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 com a opção -g.

Tipo simples incorporado

Nota aos usuários

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 foram reprovados, é altamente recomendável substituir o local de tipos simples incorporados, tirando vantagem do atributo 'mixed' do tipo complexo 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 equivalente mais próximo é a utilização do atributo 'mixed' de xsd:complexType. No entanto, 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.

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

Tipo Composto com um Tipo Base MRM

Nota aos usuários

Esta situação produz uma mensagem de aviso BIP0161 e precisa de tratamento especial, porque o modelo de esquema não pode suportar esta construção 'composta'. 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 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 global 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 elemento local do tipo simples apropriado (para modelar as informações do tipo base MRM). O tipo simples é uma restrição do tipo simples 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 .

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 precedente, DATETIME será mapeado para um xsd:time ou um xsd:dateTime com uma mensagem de aviso BIP0175, dependendo se o Gabarito de Data tem ou não apenas um componente de hora. No entanto, observe que este mapeamento pode causar erros na lista de tarefas após a importação.

Se o elemento referente também tiver as restrições de valores Valor Padrão, Min Inclusive, Max Inclusive ou Enumeração da Versão 2.1, os valores delas não corresponderão ao espaço léxico para um xsd:time ou xsd:dateTime e a validação falhará.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, Min Inclusive, Max Inclusive 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