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 causa 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, 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.
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 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.
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.
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.
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).
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.
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.
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 |
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.