Migration Hub:Modifique propriedades de agendamento usando o relatório de visão geral na migração de agendamento

O relatório de visão geral (LHMPackageOverview.xls) permite modificar propriedades de agendamento para workflows e nós, além de criar uma lista de bloqueios.

1. O que é o pacote de agendamento padrão do LHM?

O pacote de agendamento padrão é um produto intermediário no processo de migração de agendamento do LHM. Ele atua como uma camada de descrição unificada com uma estrutura de dados padrão para a migração de agendamento N2N.

Esse pacote padrão contém um arquivo de relatório de visão geral (LHMPackageOverview.xls) que resume as informações básicas sobre os workflows, nós, recursos, funções e fontes de dados transformados.

2. Recursos avançados do relatório de visão geral

O LHM permite editar o relatório de visão geral para modificar propriedades comuns de agendamento e gerenciar uma lista de bloqueios.

2,1 Como realizar operações

Execute as operações da seguinte forma:

As operações avançadas no relatório de visão geral entram em vigor durante a fase de inicialização da próxima etapa de migração:

1. Se você modificar o pacote na ferramenta de exportação, a ferramenta de transformação de agendamento recuperará as alterações durante a inicialização e as aplicará.

2. Caso modifique o pacote na ferramenta de transformação, a ferramenta de importação de destino recuperará as alterações durante a inicialização e as aplicará.

2,2 Modifique propriedades de agendamento do workflow

É possível alterar algumas propriedades do workflow no relatório. Os campos editáveis estão destacados em azul.

2,3 Modifique propriedades de agendamento do nó

Algumas propriedades do nó podem ser alteradas no relatório. Os campos editáveis estão destacados em azul.

Nota 1: Para detalhes de uso, consulte a seção 2.3.1, "Gerencie variáveis em nós e código".

2.3.1 Gerencie variáveis em nós e código

2.3.1.1 Diferenças nas variáveis de nó entre mecanismos de agendamento

Mecanismos de agendamento diferentes lidam com variáveis de nó de maneiras distintas. Essas diferenças devem ser tratadas durante a transformação do agendamento. As principais diferenças se enquadram em três categorias:

· Diferenças no formato de chamada

Os formatos de chamada comuns incluem ${param}, $[param] e $(param).

No DataWorks, as variáveis de nó usam principalmente os formatos ${} e $[]. Ao transformar agendamentos, é necessário tratar as referências de variáveis no código do nó.

· Diferenças nas variáveis internas dos mecanismos de agendamento

Os mecanismos de agendamento fornecem várias variáveis internas, sendo as variáveis de tempo as mais comuns. Outras variáveis, como ${workflowName} e ${taskName}, também estão disponíveis. Diferentes mecanismos oferecem conjuntos distintos de variáveis internas, e os formatos das variáveis de tempo também podem variar. Essas diferenças devem ser resolvidas durante a transformação.

O DataWorks exige que você defina variáveis internas na tabela de parâmetros do nó antes de usá-las. No entanto, alguns mecanismos de agendamento, como o WeData, permitem usar variáveis internas diretamente no código do nó. Ao migrar para o DataWorks, adicione essas variáveis às variáveis do nó.

· Diferenças nas referências de parâmetros multinível

As regras para referências multinível a variáveis nos níveis de projeto, workflow e nó podem diferir.

2.3.1.2 Use o relatório de visão geral para modificar variáveis em nós e código

Em um cenário de migração, as variáveis de nó diferem significativamente entre os mecanismos de agendamento de origem e de destino. A ferramenta fornece um recurso geral para simplificar o gerenciamento de variáveis. Essa etapa deve ser executada após a transformação do agendamento e antes da importação do agendamento.

· Conclusão de variáveis de nó

A ferramenta detecta automaticamente variáveis referenciadas no código do nó e as compara com as variáveis existentes no nó. Se uma variável estiver ausente na lista de variáveis do nó, a ferramenta preencherá previamente o parâmetro na coluna de parâmetros do relatório.

A ferramenta detecta variáveis no código do nó pesquisando substrings delimitadas por ${}, $[] ou $() e, em seguida, removendo duplicatas.

Por exemplo, suponha que um script contenha três substrings que parecem ser variáveis: param1, param2 e param3. Essas variáveis não existem na tabela de variáveis personalizadas do nó.

A ferramenta detecta automaticamente essas substrings e exibe um prompt no relatório de visão geral:

A ferramenta cria automaticamente nomes de variáveis. Edite a tabela para adicionar valores a essas variáveis. Se uma variável foi detectada incorretamente, exclua-a ou deixe-a inalterada.

Também é possível adicionar parâmetros de nó adicionais editando a tabela, mesmo que a ferramenta não tenha pré-criado os nomes das variáveis.

· Substitua métodos de chamada de variáveis no código do nó

Como os formatos de chamada diferem, substitua as referências de variáveis no código do nó.

Por exemplo, considere um código de nó que contém três substrings que parecem ser parâmetros: param1, param2 e param3.

A ferramenta detecta automaticamente essas substrings e cria um mapa. Modifique esse mapa para substituir os métodos de chamada de variáveis no código do nó.

A chave (antes dos dois pontos) é a string original no código do nó. O valor (após os dois pontos) é a string de substituição.

Por exemplo, para substituir todas as instâncias de $() e $[] por ${}, modifique a célula da seguinte forma:

{"${param1}":"${param1}","$[param2]":"${param2}","$(param3)":"${param3}"}

A substituição usa o método String.replace(CharSequence target, CharSequence replacement). Expressões regulares não funcionarão.

Edite esta célula também para substituir nomes de variáveis no código. Observe que, se você alterar um nome de variável, deverá modificar correspondentemente a tabela de variáveis de agendamento do nó. Por exemplo, substitua param1 por P1.

2,4 Lista de bloqueios de workflows

Impede que a ferramenta processe determinados workflows excluindo suas linhas da tabela secundária de workflows. Esse recurso é conhecido como lista de bloqueios de workflows.

Nota: Se os workflows tiverem dependências entre si, processe-os no mesmo lote. Não os separe usando a lista de bloqueios, pois separar workflows dependentes causa erros.