Você pode migrar os fluxos de mensagens criados no produto (, ou ) Versão 2.1 e utilizá-lo em .
(Se você estiver migrando do , todas as informações nesse tópico referentes aos plug-ins definidos pelo usuário e ESQL não serão aplicáveis: esses recursos não estão disponíveis em .)
Talvez você queira alterar os fluxos de mensagens migrados para tirar vantagem dos novos nós e recursos que estão disponíveis. Por exemplo, talvez você queira substituir um nó definido pelo usuário que recebe pedidos de serviços da Web pelo nó interno HTTPInput.Para obter informações adicionais sobre as alterações deste release, consulte O que Há de Novo?.
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, você deve ter cuidado para evitar conflitos e para assegurar que a versão mais recente de um fluxo de mensagens múltiplo definido seja o último a ser migrado.
Se você tiver várias versões do mesmo fluxo de mensagens e utilizar esse como um subfluxo em outros fluxos no mesmo diretório de migração, os resultados da importação serão imprevisíveis.
Para migrar um fluxo de mensagens:
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.
Se desejar renomear qualquer um desses fluxos de mensagens ou nós após a importação para ficar de acordo com as convenções de nomenclatura locais, será necessário utilizar os recursos fornecidos pelo para preservar a consistência e integridade de todas as referências.Não renomeie nenhum dos arquivos no sistema de arquivos.
Verifique o nível de compatibilidade padrão do
ESQL na página de preferências do editor de ESQL. O valor padrão para
essa opção é 5.0 que resulta em código de ESQL de tempo de execução
gerado no nível 5.0 quando você inclui um fluxo de mensagens em um
arquivo bar.
Esse código não é compatível com intermediários da versão 2.1. Se
desejar que o arquivo bar inclua o ESQL de tempo de execução versão
2.0, reconfigure a preferência do editor. Se fizer isso, não será
possível incluir as melhorias da versão 5.0 no código de ESQL, mas
será possível implementar os fluxos nos intermediários de versão 2.1
e de versão 5.0.
Consulte Editor ESQL para obter
detalhes adicionais.
Não é necessário repetir todos os processos de exportação e importação.
Como o ESQL e os mapeamentos são tratados de forma diferente na Versão 5.0, o processo de migração substitui alguns dos nós da 2.1 por diferentes nós da 5.0. Os nós substituídos são mostrados na tabela a seguir. O ESQL associado a cada nó é criado como um módulo com um nome padrão e a propriedade do nó definida como o nome desse módulo.
Nó da Versão 2.1 | Nó da Versão 5.0 |
---|---|
Compute | Compute |
Filter | Filter |
Database | Database |
DataDelete | Database |
DataInsert | Database |
DataUpdate | Database |
Extract | Compute |
Warehouse | Database |
Conceitos relacionados
Fluxos de Mensagem
Funções ESQL
Tarefas relacionadas
Abrindo um Fluxo de Mensagens Existente
Definindo o Conteúdo do Fluxo de Mensagens
Desenvolvendo ESQL
Referências relacionadas
Editor ESQL
Nós Internos
Comando mqsimigratemsgflows
Avisos |
Marcas |
Downloads |
Biblioteca |
Suporte |
Feedback
![]() ![]() |
ac02355_ |