Sessions: associar um Mapping publicado ao contexto de execução

Objetivo e modelo

Uma Session associa um Mapping publicado a um contexto executável: ambiente, seleção de worker, perfil, recuperação, parâmetros e caminhos de arquivos. O Mapping define lógica de transformação, formatos e esquema. A Session resolve as localizações acessíveis ao worker para execuções reutilizáveis.

As referências têm versão: a referência do Mapping inclui identificador, versão e fingerprint. Publicar um novo Mapping não atualiza automaticamente todas as Sessions. O Run direto de um Mapping compatível somente com arquivos é outro percurso e não exige criar uma Session.

Pré-requisitos e ciclo de vida

Você precisa de acesso à localização e ao Mapping e das permissões para cada ação. New session, Save draft, Publish session, desabilitar e excluir são operações distintas. File paths exige um Mapping publicado. A presença de um worker no seletor não comprova sua elegibilidade.

O gerenciador oferece pesquisa, filtros de ambiente/estado/runtime, Columns, Export CSV e paginação. Os cartões filtram o inventário sem mudar o estado das Sessions. Antes de uma ação em lote, confira quantidade e nomes selecionados.

Campos por aba

Environment oferece Development, Test, Stage e Production. É uma classificação de contexto: selecionar Production não publica o objeto nem concede permissões. Use tenant default herda a política do worker. Override worker permite uma seleção explícita elegível e autorizada. O perfil pode ser herdado do Workflow. Provedor cloud e região exibidos para o worker são informações somente para leitura.

Revise a política oferecida em Recovery, além de timeout e novas tentativas. Repetir uma execução e retomar um checkpoint são ações diferentes. Um checkpoint só é útil quando existe estado persistido compatível; ele não desfaz automaticamente escritas externas.

As opções atuais de Recovery são Fail immediately, Retry once, Retry up to 3 times e Resume from checkpoint. Selecione o comportamento desejado explicitamente e confira o contrato de repetição do destino.

Configurar e publicar uma Session de laboratório

1. Selecione New session e informe s_ClientesDemo_Test.
2. Em General, selecione o Mapping publicado aceito e o Domain/Folder autorizado. Confira identificador e aviso de versão.
3. Escolha Test em Environment.
4. Em Runtime, mantenha Use tenant default ou habilite um Override worker compatível. Revise perfil e recuperação deliberadamente.
5. Em File paths, preencha todos os vínculos obrigatórios. Um caminho no computador do navegador não fica automaticamente disponível no worker.
6. Em Parameters, informe apenas overrides declarados e de tipos compatíveis. Confira nome, tipo e valor efetivo em Parameter preview.
7. Use Save draft, corrija a validação e selecione Publish session quando estiver pronto. Reabra o registro para conferir referência, vínculos e versão persistidos.

Exemplo de caminhos e parâmetro

Caminhos ilustrativos do worker são /srv/dova-lab/input/customers.csv e /srv/dova-lab/output/customers-test.csv. Substitua-os por localizações autorizadas e preparadas para a identidade do worker; a documentação não cria esses diretórios.

Se o Mapping declarar um parâmetro string chamado region, um override tipado pode ser:

{"region":{"type":"string","value":"DEMO"}}

O valor só afeta dados quando algum componente o utiliza, por exemplo uma Template ${param.region} em Calculated field. Um parâmetro arbitrário não cria uma coluna nem altera o tamanho de lote do motor. Overrides de escopo task pertencem à tarefa do Workflow, não às camadas da Session.

Exemplo: um projeto, dois contextos

Crie Sessions Test e Stage com a mesma versão publicada de Mapping e arquivos sintéticos equivalentes acessíveis ao mesmo worker. Use destinos separados. Execute cada uma por um Workflow de laboratório e compare: entradas e parâmetros equivalentes devem produzir registros transformados equivalentes em arquivos independentes.

Para uma falha controlada, use temporariamente um caminho de origem inexistente apenas em Test. Localize a tentativa no Monitor, identifique o erro de arquivo, restaure o caminho e examine uma nova tentativa. O rótulo de ambiente não transfere arquivos nem implanta código automaticamente.

Versões, falhas e recuperação

Se o worker for inelegível, confira estado, capacidades, perfil e exclusões em Configuration. Se o JSON for inválido, corrija o campo indicado sem descartar os demais ajustes. Depois de mudar a referência do Mapping, revise os Workflows consumidores e publique-os deliberadamente.

O timestamp do destino pode ser herdado, habilitado ou desabilitado. Uma Template opcional resolve %RUN_TIMESTAMP% preservando o diretório. Confira o nome resultante em uma execução pequena. Antes de repetir, verifique se uma escrita anterior pode ser duplicada ou se o estado de recuperação selecionado é utilizável.

Próximas leituras

Consulte Configuration, Workers, Workflows e Monitor. Os exemplos definem verificações de aceitação para seu ambiente; não afirmam que uma nova execução já foi realizada.