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.
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.
Qualquer restrição de valor não referida é descartada com uma mensagem de aviso BIP0158, BIP0159 ou BIP0160.
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"
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.
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.
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.
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.
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).
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.
É 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.
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 |
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'.