Migrando um Fluxo de Mensagens

Antes de começar:

Leia o tópico de conceitos sobre condições para um intermediário da Versão 5.0 que participa de um domínio do intermediário da Versão 6.0.

Você pode migrar os fluxos de mensagens criados no produto Versão 2.1 (WebSphere MQ Event Broker, WebSphere MQ Integrator Broker ou WebSphere MQ Integrator) e utilizá-los no WebSphere Message Broker Versão 6.0.

Se você estiver migrando do WebSphere MQ Event Broker Versão 2.1, todas as informações deste tópico que referem-se a plug-ins e ESQL definidos pelo usuário não se aplicam; esses recursos não estão disponíveis no WebSphere MQ Event Broker Versão 2.1.

Se tiver migrado do WebSphere MQ Integrator Broker Versão 2.1, você pode ter gravado fluxos de mensagens que manipulam mensagens XML que utilizam espaços de nomes XML. No Versão 2.1, tais mensagens XML são analisadas de maneira diferente em relação à utilizada pelo WebSphere Message Broker Versão 6.0. Apesar desses fluxos de mensagens continuarem a funcionar corretamente quando hospedados pelo Versão 6.0, é melhor fazer upgrade dos mesmos para que estejam cientes do espaço de nomes seguindo as seguintes etapas em Fazendo um Fluxo de Mensagens Reconhecer Espaços de Nomes.

Você pode querer alterar os fluxos de mensagens migrados para tirar proveito dos novos nós e recursos disponíveis no Versão 6.0. Por exemplo, você pode querer substituir um nó definido pelo usuário que recebe pedidos de serviços da Web com o nó HTTPInput interno.

Para obter informações adicionais sobre as alterações deste release, consulte O Que Há de Novo no Versão 6.0?.

Você pode migrar mais de um fluxo de mensagens de uma vez, se desejar que eles sejam definidos no mesmo projeto do fluxo de mensagens. Você deve migrar os subfluxos e nós definidos pelo usuário com os fluxos de mensagens nos quais eles foram incluídos para assegurar referências consistentes.

Se você tiver definido mais de um fluxo de mensagens com o mesmo nome, ou o fluxo de mensagens tiver sido exportado para mais de um arquivo de exportação, a tarefa de migração sobrescreverá sem aviso qualquer fluxo de mensagens existente pelo próximo fluxo que ela localizar com o mesmo nome. Portanto, tome cuidado para evitar conflitos e assegure que a versão mais recente de um fluxo de mensagens definido de forma múltipla seja o último a ser migrado.

Se você tiver várias versões do mesmo fluxo de mensagens, que é utilizado como um subfluxo em outros fluxos do mesmo diretório de migração, os resultados da importação serão imprevisíveis.

Para migrar um fluxo de mensagens:

  1. Antes de desinstalar a Versão 2.1, exporte o fluxo ou fluxos de mensagens do Centro de Controle utilizando as ferramentas Versão 2.1 (consulte a documentação da Versão 2.1 para obter informações detalhadas).

    O processo de migração é mais eficiente quando todos os subfluxos referenciados estiverem incluídos no mesmo arquivo de exportação; portanto, exporte todos os fluxos de mensagens que você deseja migrar para um único projeto do fluxo de mensagens em um único arquivo de exportação.

  2. Transfira o arquivo ou arquivos de exportação para o novo sistema no qual você está executando o workbench. Verifique se o diretório no qual você armazena estes arquivos não contém outros arquivos. Armazene os arquivos que deseja importar para um único projeto do fluxo de mensagens em um diretório separado e migre cada diretório separadamente. Certifique-se de não armazenar arquivos em subdiretórios do diretório do projeto, porque esses arquivos são ignorados pelo comando migrar.
  3. Se você tiver uma sessão ativa do workbench, feche-a. Não é possível executar o comando migrar se o workbench estiver em execução.
  4. Em um prompt de comandos, chame o comando mqsimigratemsgflows, especificando o novo nome de projeto e o diretório no qual você armazenou os arquivos de exportação. Quando o comando estiver concluído:
    • Os fluxos de mensagens contidos nos arquivos de exportação no diretório especificado são importados para o projeto do fluxo de mensagens especificado. Se o projeto já existir, os fluxos de mensagens adicionais são incluídos com conteúdo atual, se houver algum. Se o projeto não existir antes de você chamar o comando, ele será criado. É melhor permitir que o comando crie o projeto do fluxo de mensagens para você.
    • Os fluxos e subfluxos de mensagens são criados e suas definições são armazenadas em arquivos denominados flow_name.msgflow. Os nós definidos pelo usuário são criados e suas definições são armazenadas em arquivos denominados node_name.msgnode.

      Se quiser renomear qualquer um desses fluxos de mensagens ou nós após a importação para conformidade com suas convenções locais de nomenclatura, utilize os recursos fornecidos pelo workbench para preservar a consistência e a integridade de todas as referências. Não renomeie nenhum dos arquivos no sistema de arquivos.

    • Se qualquer um dos nós dos fluxos de mensagens contiverem ESQL, esse ESQL é extraído do nó em si e armazenado no arquivo ESQL message_flow_name.esql. O ESQL de cada nó é agrupado entre as instruções CREATE e END MODULE apropriadas (para Compute, Database ou Filter). O comando cria o arquivo ESQL se ele ainda não existir.

      Início da mudançaAo incluir um fluxo de mensagens em um arquivo bar, o código ESQL do tempo de execução é gerado no nível da Versão 6.0. Este código é incompatível com os intermediários Versão 2.1. Se quiser que o arquivo bar inclua ESQL do tempo de execução versão 2.0, selecione a caixa Compilar ESQL para Intermediários Versão 2.1. Se fizer isso, não é possível incluir aprimoramentos da Versão 6.0 no código ESQL, mas é possível implementar os fluxos para intermediários Versão 2.1 e Versão 6.0.Fim da mudança

      Para obter informações adicionais, consulte o tópico Incluindo Arquivos em um Broker Archive.

  5. Verifique o arquivo de relatório mqsimigratemsgflows.report.txt gravado no diretório a partir do qual o comando foi chamado. O comando fornece as seguintes informações:
    • O nome de cada fluxo de mensagens, subfluxo e nó definido pelo usuário migrado. Se algum destes recursos tiver um nome incompatível com a Versão 6.0, o comando atualizará o nome e todas as referências a esse nome para assegurar consistência. Se você migrar um recurso com um nome inválido mais de uma vez, a correção feita no nome sempre será a mesma.
    • O êxito ou falha de cada recurso migrado
    • Uma indicação de um subfluxo que não pode ser localizado (sua definição não está contida em nenhum dos arquivos de exportação, mas está incluída em um ou mais dos fluxos de mensagens migrados). Se isso ocorrer, localize o subfluxo ausente e importe-o para o projeto apropriado. Se, por qualquer motivo, você não puder recuperar o subfluxo ausente, recrie-o com o nome original. Todos os fluxos afetados podem então ser vinculados corretamente ao novo subfluxo.

      Não é necessário repetir todo o processo de exportação e importação.

    • Uma indicação de que um recurso migrado como um fluxo de mensagens e armazenado em um arquivo .msgflow pode ser um nó definido pelo usuário. Se esse aviso ocorrer, verifique se o recurso especificado é um nó definido pelo usuário ou um fluxo de mensagens. Se for um fluxo de mensagens, ele foi migrado corretamente. Se for um nó definido pelo usuário, conclua as ações descritas na etapa 11.
  6. Inicie o workbench e alterne para a Perspectiva do Desenvolvimento de Aplicativos do Intermediário.
  7. Abra o projeto do fluxo de mensagens criado ou atualizado pelo comando migrar clicando com o botão direito do mouse no projeto e clicando em Abrir Projeto.

    Se o projeto já estiver aberto, clique com o botão direito do mouse e clique em Atualizar, em seguida, em Reconstruir Projeto para assegurar que a visualização Navegador reflita o novo conteúdo. A reconstrução também executa uma validação do conteúdo do projeto do fluxo de mensagens.

    Como o ESQL e os mapeamentos são manipulados de maneira diferente na Versão 6.0, o processo de migração substituirá alguns dos nós Versão 2.1 por diferentes nós Versão 6.0. A tabela a seguir lista os nós substituídos. O ESQL associado a cada nó é criado como um módulo com um nome padrão e a propriedade do nó definida é configurada para o nome desse módulo.

    Versão 2.1 Versão 6.0
    Compute Compute
    Filter Filter
    Database Database
    DataDelete Database
    DataInsert Database
    DataUpdate Database
    Extract Compute
    Warehouse Database
  8. Se um fluxo de mensagens incluir um ou mais nós Filter, verifique o módulo ESQL para cada nó no arquivo ESQL para assegurar que a instrução RETURN retorne corretamente uma expressão válida que seja resolvida para um valor Booleano.
  9. Se um fluxo de mensagens incluir um nó com ESQL, os campos de referência ESQL em uma mensagem derivada de um cabeçalho C importado, e você tiver criado o modelo de mensagens importando o cabeçalho C para workbench, verifique as instruções ESQL que se referem a essa mensagem. A importação para o Versão 6.0 workbench pode criar um modelo com convenções de nomenclatura diferentes das criadas pelo importador Versão 2.1 e poderá ser necessário atualizar uma ou mais referências de campo.
  10. Se você tiver promovido a propriedade ESQL de qualquer um dos nós Versão 2.1 que incluía a customização ESQL para reutilizar o ESQL em vários nós, isto não será mantido nos fluxos de mensagens migrados Versão 6.0, porque a promoção de propriedades relacionadas a ESQL não é mais suportada. A visualização Tarefa mostra um erro para cada propriedade ESQL promovida. Para obter o mesmo efeito, crie uma função ESQL e chame essa função a partir de cada módulo ESQL do nó.
  11. Se você tiver migrado um nó definido pelo usuário, apenas o arquivo de definição de interface XML será migrado para um arquivo do nó .msgnode (isso define apenas os terminais e propriedades do nó). Conclua sua migração e sua definição manualmente na Versão 6.0 do produto. As etapas a seguir fornecem um esboço do processo requerido; para obter detalhes completos, consulte Criando a Representação da Interface com o Usuário de um Nó Definido pelo Usuário no workbench.
    1. Crie um novo projeto do nó definido pelo usuário e mova o arquivo .msgnode do projeto do fluxo de mensagens para o novo projeto do nó definido pelo usuário. Quando fizer isso, os arquivos de propriedades associados serão criados.
    2. Opcional: Conclua o desenvolvimento do nó definido pelo usuário no ambiente do Eclipse para criar o plug-in Eclipse do nó definido pelo usuário (a estrutura de diretórios que contém os arquivos que compõem esse nó). Essa tarefa inclui a criação de recursos do nó para ajuda, ícones, editores de propriedades e compiladores, se necessário.
    3. Verifique a existência de erros na lista de tarefas. Eles podem ser gerados, por exemplo, se o nó ou seus nomes de terminais incluírem o caractere espaço (não suportado na Versão 6.0) ou se um fluxo incorporar outro fluxo migrado e a referência não estiver correta. Resolva esses erros corrigindo nomes ou utilizando a opção de menu Localizar subfluxo.
    4. Instale o código de tempo de execução para o nó (o arquivo .lil) nos sistemas dos intermediários apropriados. Não é necessário recompilar o código para seu nó definido pelo usuário ao migrá-lo.
    5. Pare e inicie novamente o intermediário para reconhecer os arquivos novos ou alterados.
Quando tiver migrado seus recursos, consulte Tarefas de Pós-migração da Versão 2.1 para obter informações sobre tarefas que você possa querer executar após a migração.
Conceitos relacionados
Visão Geral de Fluxos de Mensagens
Funções ESQL
Tarefas relacionadas
Fazendo um Fluxo de Mensagens Reconhecer Espaços de Nomes
Abrindo um Fluxo de Mensagens Existente
Definindo o Conteúdo do Fluxo de Mensagens
Desenvolvendo ESQL
Referências relacionadas
Perspectiva do Desenvolvimento de Aplicativos do Intermediário
Editor ESQL
Nós Internos
Comando mqsimigratemsgflows
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ac02355_