Arquivos do primeiro Workflow

Para o percurso completo, use a pequena amostra desta edição: quatro clientes sintéticos, três com status=ACTIVE. Baixe a entrada e mantenha o resultado esperado separado.

• active-customers-input.csvEntrada de quatro linhas · CSV · 147 BBaixar
• active-customers-expected.csvResultado esperado de três linhas · CSV · 89 BBaixar
• README.mdInstruções do laboratório · Markdown · 2,0 kBBaixar

Configure Flat File input → Row filter (field=status, operator=equals, value=ACTIVE) → Field selector (fields=customer_id, name, amount) → Flat File output. Publique o Mapping e continue com a Session e o Workflow desta guia. A saída deve conter somente customer_id, name e amount, com D001/Demo Alfa/125.50, D003/Demo Gamma/80.00 e D004/Demo Delta/0.00. Sem Row sort explícito, compare por identificador; não transforme a ordem de leitura em garantia universal. A representação decimal e os fins de linha podem variar: a aceitação confere esquema e valores, não identidade byte a byte. O percurso no navegador não exige um checkout privado do código.

Esta guia apresenta um laboratório que conecta organização, transformação, execução e verificação. O objetivo é gerar um CSV cujo conteúdo possa ser conferido, identificando as versões e as condições de execução. Use dados sintéticos e destinos separados de qualquer processo operacional.

Preparar o espaço de trabalho

Entre com uma identidade autorizada e confira o tenant e o papel ativos no menu da conta. Uma pessoa pode ter acesso a contextos diferentes; apenas o nome do objeto não identifica seu escopo. Abra Repository e localize um Domain e uma Folder destinados ao laboratório. Se seu papel não permitir criá-los, peça ao administrador que prepare esse espaço.

Adote nomes reconhecíveis, por exemplo com o prefixo lab_, e registre a relação entre Mapping, Session e Workflow. Não reutilize identificadores de objetos de produção. Prepare diretórios de entrada e saída acessíveis ao worker escolhido. Um caminho no computador do navegador pode não existir no worker remoto. Configure credenciais em Connections, nunca nos dados de exemplo nem no nome do arquivo.

Desenhar e validar o Mapping

O Mapping define as operações sobre os dados. Comece com Flat File input, uma transformação simples e Flat File output. Confira delimitador, codificação, nomes de colunas e valores vazios. Para estudar uma cadeia maior, siga a demonstração de normalização.

1. Em Mappings, escolha New Mapping e informe nome, Domain e Folder do laboratório.
2. Adicione os componentes pela paleta e configure cada um no painel do componente selecionado.
3. Conecte as portas de origem, transformação e destino na ordem da regra de negócio.
4. Use Validate e corrija os erros apresentados. Arrange e Fit organizam a visualização; não alteram a regra.
5. Escolha Save draft e depois Publish. Confirme a publicação e confira a versão persistida.

Um filtro antes da conversão pode produzir um resultado diferente do mesmo filtro após a conversão. Salvar um rascunho não o publica; publicar não inicia uma execução. Se escolher Run diretamente no Mapping, siga o caminho de upload de arquivo, sem criar os objetos das seções seguintes.

Associar a Session

A Session associa o Mapping ao contexto de execução. Crie uma Session de laboratório, selecione o Mapping publicado e confira sua versão. Defina o ambiente de teste, o perfil de execução e a política de worker. Mantenha o padrão do tenant quando não houver motivo para um override autorizado.

Em File paths, associe cada identificador de origem e destino ao caminho que o worker pode acessar. No exemplo simples, source_csv lê clientes e target_csv grava a saída. Use um destino exclusivo do laboratório. Um arquivo correto associado ao nó errado continua sendo um binding incorreto.

O worker precisa estar habilitado, elegível, compatível e com capacidade disponível. Confira heartbeat e slots em Workers; uma VM ligada não comprova que o agente consegue executar a tarefa. Revise os parâmetros tipados e a prévia de resolução. Salve, valide e publique a Session.

Orquestrar e executar manualmente

Crie um Workflow com Start → Session → End. Selecione sua Session publicada na tarefa, confira a versão e conecte as dependências de sucesso. Um Workflow precisa de exatamente um Start, pelo menos um End e caminhos válidos, sem ciclos, entre eles. Os nomes das tarefas devem ser únicos no desenho.

Valide, salve o rascunho e publique o Workflow. Execute manualmente no laboratório e registre o identificador do novo intento. Overrides informados para esse intento não são edições permanentes da Session ou do Workflow. Adicione Decision ou Timer somente após o caso simples produzir o resultado esperado; Timer aguarda um número de segundos, não cria uma agenda recorrente.

Ainda não habilite uma programação. Primeiro confira o comportamento manual, o destino efetivo e a evidência produzida. Ao atualizar um Mapping ou uma Session depois, revise e publique as dependências consumidoras; o rascunho aberto não substitui silenciosamente a versão fixada em uma execução.

Conferir o resultado e encerrar o teste

Abra Monitor e acompanhe o intento até um estado terminal. Uma solicitação aceita ou em fila não comprova a saída. Expanda as tarefas, consulte o primeiro erro relevante e os registros disponíveis. Quando houver uma saída armazenada e bem-sucedida, use Download output; se o destino for um arquivo no worker ou uma tabela, confira esse recurso autorizado.

Compare cabeçalho, valores, quantidade e ordem das linhas com um resultado esperado independente. Registre tenant, Domain, Folder, versões, identificador do intento, contagem e destino, sem segredos. Se houver diferença, investigue parsing, bindings e ordem das transformações antes de repetir a gravação em um destino compartilhado.

Depois de estabilizar o teste, prepare uma programação em Configuration → Workflow Scheduler com fuso horário explícito. Confira a próxima execução planejada e um intento real separadamente. Ao mover o fluxo para outro ambiente, revise permissões, caminhos, conexões e capacidade. Um teste local das regras não certifica a infraestrutura de destino.

Esta guia começa com um exercício que você pode montar no navegador do Dova 22.0.5. Depois preserva o laboratório local de 1.000 linhas para quem tem um checkout autorizado do motor. São amostras diferentes: mantenha seus arquivos, regras e contagens esperadas separados.

Demonstração CSV: de 18 para 10 linhas

Os arquivos públicos e as capturas pertencem a uma demonstração real preservada do Dova 20.0.4. Os bytes e as contagens foram conferidos nesta edição, e os campos dos componentes foram comparados com o código ativo 22.0.5. Esta guia não afirma que um novo intento 22.0.5 tenha sido executado durante sua preparação.

Baixe o CSV sintético de entrada e guarde a saída de referência separadamente. A entrada contém 18 registros e oito colunas; a saída contém 10 registros e seis colunas. Nomes, zonas e identificadores estão explicitamente marcados como DEMO.

• customers-demo.csvEntrada sintética (18 linhas) · CSV · 2,2 kBAbrir arquivo
• clientes-demo-excel.csvSaída de referência (10 linhas) · CSV · 773 BAbrir arquivo

Um registro antes e depois

O fragmento mostra DEMO-C002, e não o arquivo inteiro. Espaços excedentes são removidos e o texto fica em maiúsculas; HABILITADO passa a ACTIVO. O valor torna-se numérico: 2500.0 e 2500.00 representam o mesmo número nesta amostra.

customer_id,full_name,city,segment,status,credit_limit,demo_row_ref,internal_note
DEMO-C002, cliente   demo beta ,zona demo sur, empresa demo , habilitado ,2500.00,DEMO-R02,MUESTRA SINTETICA; SIN DATOS REALES

cliente_id,cliente_nombre,ciudad,segmento,estado,limite_credito
DEMO-C002,CLIENTE DEMO BETA,ZONA DEMO SUR,EMPRESA DEMO,ACTIVO,2500.0

Configurar os doze componentes

Crie um Mapping no Domain e na Folder do laboratório. Adicione os componentes da tabela e conecte uma cadeia linear nessa ordem. Cada bloco mostra a configuração técnica equivalente aos controles do inspetor; não é um documento de importação nem deve ser colado na visualização Advanced, que é somente leitura. Seu próprio desenho gera os identificadores dos nós.

{
  "format": "csv",
  "delimiter": ",",
  "hasHeader": true,
  "headerRowNumber": 1,
  "columns": [
    "customer_id",
    "full_name",
    "city",
    "segment",
    "status",
    "credit_limit",
    "demo_row_ref",
    "internal_note"
  ],
  "headerMappings": [],
  "encoding": "utf-8"
}

{
  "fields": [
    "customer_id",
    "full_name",
    "city",
    "segment",
    "status",
    "credit_limit"
  ],
  "operations": [
    "trim",
    "collapse_whitespace",
    "upper"
  ]
}

{
  "field": "status",
  "find": "HABILITADO",
  "replacement": "ACTIVO",
  "matchMode": "exact",
  "caseSensitive": true
}

{
  "field": "status",
  "operator": "equals",
  "value": "ACTIVO"
}

{
  "field": "customer_id",
  "operator": "not_empty",
  "value": ""
}

{
  "field": "full_name",
  "operator": "not_empty",
  "value": ""
}

{
  "field": "credit_limit",
  "operator": "not_empty",
  "value": ""
}

{
  "field": "credit_limit",
  "targetType": "number",
  "outputField": "",
  "onError": "fail",
  "defaultValue": ""
}

{
  "mapping": {
    "customer_id": "cliente_id",
    "full_name": "cliente_nombre",
    "city": "ciudad",
    "segment": "segmento",
    "status": "estado",
    "credit_limit": "limite_credito"
  }
}

{
  "fields": [
    "cliente_id",
    "cliente_nombre",
    "ciudad",
    "segmento",
    "estado",
    "limite_credito"
  ]
}

{
  "field": "cliente_id",
  "direction": "asc"
}

{
  "format": "csv",
  "fileName": "clientes-demo-excel.csv",
  "delimiter": ",",
  "includeHeader": true,
  "textQualifier": "double",
  "quoteMode": "minimal",
  "escapeCharacter": "\\",
  "lineEnding": "crlf",
  "encoding": "utf-8-bom",
  "nullValue": ""
}

Há dez transformações entre origem e destino: limpeza, substituição, quatro filtros, conversão, renomeação, seleção e ordenação. Os quatro filtros precisam vir antes de Convert type: a amostra contém um registro inativo com valor inválido, que deve ser excluído antes da conversão. not_empty verifica se o valor limpo está preenchido; não comprova que qualquer texto seja numérico.

Publicar e executar pelo navegador

1. Use Validate e resolva as mensagens; salve com Save draft.
2. Escolha Publish, confirme a publicação e confira a versão persistida. Alterações posteriores exigem salvar e publicar novamente.
3. Clique em Run no Mapping e selecione customers-demo.csv no seletor de arquivo CSV. Este teste direto não exige conexão S3, Session ou Workflow.
4. Acompanhe o intento no Monitor e registre seu identificador. Aguarde o sucesso terminal; queued ou uma solicitação aceita ainda não significam conclusão.
5. Use Download output quando o intento bem-sucedido tiver saída armazenada. Salve o CSV baixado separado do arquivo de referência.
6. Compare o download real com o resultado esperado, sem reordenar nem editar o arquivo para forçar a coincidência.

Critérios de aceitação

Confira o cabeçalho exato, seis colunas e dez registros de dados, identificadores únicos e ordem física crescente por cliente_id, textos normalizados, estado ACTIVO e valores numericamente equivalentes. Verifique que demo_row_ref e internal_note não estejam na saída. O destino configura BOM UTF-8 e CRLF, adequados para abrir ou importar o CSV no Excel. O arquivo continua sendo CSV, e não uma pasta de trabalho XLSX.

Se faltarem linhas, identifique o primeiro filtro que exclui cada registro. Se Convert type falhar, confira os filtros anteriores e o valor aceito. Para colunas incorretas, revise Field mapper e Field selector. Se Download output não aparecer, confira o estado terminal, a saída armazenada e as permissões; publicar não gera o arquivo por si só.

Ver as capturas reais das 16 etapas da demonstração

Laboratório local adicional: 1.000 linhas → 667

O pacote local pertence ao laboratório da edição 6.0.2 e preserva sua verificação original. As 667 linhas são o critério esperado dessa amostra, não um novo intento 22.0.5. Ele exige um checkout autorizado; para aprender apenas pelo navegador, use a demonstração acima.

Material e escopo do laboratório local

O pacote histórico de amostras · laboratorios-dova-6.0.2.zipZIP · 43,8 kBBaixar contém inputs/customers.csv, expected/customer_normalized.csv e definições de Mapping, Session e Workflow. A entrada tem 1.000 registros com customer_id, raw_name, location, amount e status. Inclui espaços repetidos, acentos, localização separada por | e estados ACTIVE, ENABLED e INACTIVE. O resultado de referência contém 667 registros.

O executor requer um checkout autorizado de DovaETL e suas dependências Python, incluindo openpyxl na versão indicada no pacote. O motor não está incluído. O wrapper não instala programas, não inicia servidor, não cria objetos em um tenant e não testa workers remotos. As verificações preservadas pertencem ao laboratório original; não representam um novo teste executado em Dova 22.0.5.

Entender as oito transformações do laboratório

1. Clean: trim, collapse_whitespace e remove_accents em raw_name e location.
2. Replace: substitua exatamente ENABLED por ACTIVE.
3. Split: separe location em city e country usando | e remova o campo original.
4. Concat: forme customer_key com raw_name, # e customer_id.
5. Derive: monte segment com o template ${country}-${status}; é substituição de texto.
6. Convert: converta amount para amount_number, com onError=fail, preservando o original.
7. Filter: mantenha status=ACTIVE.
8. Sort: ordene amount_number em ordem decrescente.

Replace antes de Filter mantém também os registros originalmente ENABLED. Convert antes de Sort ordena números, não sua representação textual. Não misture esta cadeia de oito transformações com as dez transformações da demonstração de 18 linhas.

Executar a verificação local

Extraia o pacote e, na pasta extraída, informe seu checkout autorizado:

python .\run_pocs.py --repo C:\caminho\DovaETL --report .\verification.json

Substitua o caminho ilustrativo pelo real. Consulte o README do laboratório · README.mdMarkdown · 2,5 kBBaixar. O wrapper verifica as duas POCs, força local_json, bloqueia rede e acesso persistente a app/shared, copia os arquivos para um diretório temporário e o remove ao terminar. O relatório opcional contém somente evidência sintética. Integridade dos arquivos, definições e referência de fingerprint são verificadas antes da comparação.

Interpretar o oráculo

O oráculo usa funções Python independentes dos operadores DovaETL: limpa textos, normaliza estados, divide localização, deriva campos, exclui inativos e ordena. Aceite a amostra quando houver 667 linhas e coincidência byte a byte entre motor, oráculo e CSV de referência; o relatório esperado mostra PASS_BYTE_EXACT. Uma exceção ou código diferente de zero significa que o teste não passou no seu ambiente.

A comparação também detecta cabeçalho, ordem, fim de linha e representação numérica. Não substitua o resultado esperado por uma saída ainda não compreendida. Ao alterar a regra, calcule o novo esperado independentemente e preserve a amostra original.

Levar o laboratório à interface

Estude a cadeia em Mappings e os bindings source_csv e target_csv em Sessions. Prepare Domain, Folder, worker e caminhos de laboratório. As definições de exemplo explicam o contrato, mas não substituem a configuração explícita do ambiente.

Publique as dependências, execute manualmente pelo Workflow e confira Monitor. Compare com expected/customer_normalized.csv. Se o teste local passar e o remoto falhar, investigue versão, caminhos, bindings, permissões e worker; uma regra correta não torna o arquivo do computador local acessível em outro host.

Este laboratório relaciona transações sintéticas de um TXT delimitado por | com um catálogo de clientes em Excel. Cada entrada possui 1.000 registros. O processo mantém transações aprovadas, associa cada cliente à sua região e gera um CSV com quatro linhas de dados. Assim, você pode estudar várias origens, diferenças de tipo nas chaves e uma agregação calculável independentemente.

Entradas e resultado esperado

No pacote histórico de amostras · laboratorios-dova-6.0.2.zipZIP · 43,8 kBBaixar, inputs/transactions.txt contém customer_id, amount e status. Identificador e valor são lidos como texto. De forma determinística, cada quinta transação é REJECTED; as demais são APPROVED. Não há pagamentos nem identificadores de sistemas externos.

inputs/customers.xlsx tem a planilha Customers, cabeçalho na primeira linha e 1.000 registros nas colunas A a C: customer_id, customer_name e region. O identificador é interpretado como inteiro. Nomes e regiões incluem espaços e acentos para tornar a limpeza observável. A saída expected/regional_approved_totals.csv conserva somente sales_region e approved_total.

Revisar as oito transformações

Na primeira ramificação, Convert type transforma amount do TXT em amount_number, numérico. Na segunda, Clean text aplica trim, collapse_whitespace, remove_accents e upper ao nome e à região do Excel. Inspecione as origens separadamente antes de atribuir um problema ao Join.

1. Convert type: amount → amount_number, targetType=number e onError=fail.
2. Clean text: normalize customer_name e region na ramificação XLSX.
3. Join: inner, chave customer_id em ambos os lados, keyType=integer, strategy=hash, nullsEqual=false. O lado esquerdo vem da conversão TXT; o direito, da limpeza XLSX.
4. Row filter: mantenha status equals APPROVED.
5. Group aggregate: groupBy=[region], metric=sum, field=amount_number, outputField=total_amount.
6. Row sort: total_amount em ordem decrescente.
7. Field mapper: region → sales_region e total_amount → approved_total.
8. Field selector: mantenha exatamente sales_region e approved_total.

O destino é Flat File output, CSV UTF-8 com cabeçalho e fim de linha LF. O XLSX é uma entrada; a saída não é uma pasta de trabalho Excel. O tipo inteiro na chave do Join permite comparar o identificador textual do TXT com a célula numérica do XLSX. Várias correspondências do mesmo cliente podem multiplicar registros antes da soma.

Executar sem conexões externas

Prepare um checkout autorizado de DovaETL e suas dependências, incluindo openpyxl conforme o pacote. O motor não vem incluído. Extraia a amostra e execute, na pasta extraída:

python .\run_pocs.py --repo C:\caminho\DovaETL --report .\verification.json

Substitua o caminho ilustrativo pelo real e leia o README · README.mdMarkdown · 2,5 kBBaixar. O wrapper verifica também o laboratório de normalização. Ele usa bytes locais: não exige URL nem chave. Bloqueia rede e armazenamento persistente, copia amostras para um diretório temporário e o elimina ao terminar. O relatório opcional conserva apenas nomes de testes, contagens, hashes e comparações sintéticas.

O programa verifica integridade, valida Mapping, Session e Workflow e resolve os bindings source_txt e source_xlsx pelos identificadores reais das definições. Também confere 1.000 linhas reportadas na planilha Customers. Um erro no nome da planilha ou no intervalo de leitura deve ser tratado como entrada, antes de investigar a agregação.

Aceitação e diagnóstico

O oráculo independente monta um dicionário de regiões por identificador inteiro. Percorre as transações, exclui rejeitadas, soma valores por região e ordena. Ele não chama os operadores Join nem Aggregate do motor. A aceitação exige quatro linhas e correspondência byte a byte entre motor, oráculo e CSV esperado; o relatório esperado contém PASS_BYTE_EXACT.

A representação numérica pertence a esta amostra e não define uma política contábil universal. Em dados financeiros, estabeleça precisão, escala, moeda e arredondamento com o responsável pelo processo. O formato visual de uma planilha não comprova essas regras.

• Menos regiões: confira chaves sem correspondência, tipos e modo de Join.
• Totais duplicados: confira a unicidade das chaves do catálogo de clientes.
• Regiões separadas por acentos ou espaços: confira a limpeza antes da agregação.
• Colunas excedentes: confira Field mapper, Field selector e o destino.
• Comparação diferente: examine cabeçalho, ordenação, fins de linha e valores; não substitua o esperado pela saída sem explicar a diferença.

Levar o caso a um Workflow

Construa o desenho em Mappings e configure os dois bindings em Sessions. Um único upload não substitui duas fontes diferentes. O Run do Mapping dispõe de seleção de entradas compatíveis por origem; para o contexto reutilizável, confira os caminhos acessíveis pelo worker. Na CLI, use opções --source repetidas conforme a guia de automação.

Publique as dependências e teste manualmente antes de habilitar o Workflow em uma agenda. Confira estado e tarefas no Monitor, compare os dois campos de saída e registre o intento e suas versões. A validação local das regras não certifica permissões, caminhos remotos, drivers ou capacidade do worker.

Uma operação confiável exige conhecer o contexto autorizado, a versão executada e o estado real das dependências. Esta guia organiza a preparação do intento, a investigação de falhas, a migração de referências e a retirada de um worker. Uma ação administrativa deve ser feita com o papel adequado e evidência suficiente para distinguir solicitação aceita de alteração confirmada.

Identidade, tenant e permissões

Confira o tenant e o papel ativos antes de editar ou executar. A mesma conta pode enxergar objetos diferentes ao trocar de contexto. Separe laboratório e produção e escolha nomes reconhecíveis; nomes parecidos não comprovam que identificador e versão sejam os mesmos.

Em Roles and permissions, atribua apenas as capacidades necessárias. Leitura do Monitor, edição de definições, publicação, execução e administração de infraestrutura são responsabilidades distintas. Se uma opção não aparecer, confira permissões, contexto e estado do objeto. Não tente contornar uma rejeição chamando um endpoint administrativo diretamente.

Mantenha conexões e API keys nos mecanismos próprios. Não coloque credenciais em variáveis de exemplo, arquivos, capturas ou incidentes. Uma chave pessoal identifica uma automação, mas não concede poderes administrativos adicionais. Revogue chaves temporárias quando não forem mais necessárias em Developer Tools.

Preparar uma execução observável

Confira Mapping, Session e Workflow publicados, suas versões e os bindings. Verifique destinos, worker, capacidades e slots. Determine o efeito de enviar os mesmos dados novamente antes de gravar em um destino externo. Uma operação de infraestrutura idempotente não torna automaticamente idempotente a carga de dados.

Registre o identificador do intento e acompanhe Monitor. Distinga fila, atividade e estado terminal. Guarde overrides não sensíveis e os registros necessários. Compare o arquivo ou a tabela com uma regra independente: sucesso técnico não substitui aceitação do esquema, quantidade, valores e regras de negócio.

Diagnosticar antes de recuperar

Localize a primeira tarefa com erro, sua mensagem e o último estado confirmado. Classifique a causa: desenho inválido, entrada indisponível, autorização, credencial, capacidade, dependência ou provedor. Repetir não corrige um caminho incorreto ou uma permissão ausente.

As ações disponíveis dependem do estado e da autorização:

• Cancel: solicita cancelamento de um Workflow em fila.
• Terminate: solicita o encerramento de uma execução ativa; confira o resultado posterior e os efeitos parciais.
• Re-run: inicia outro intento desde o começo com a entrada armazenada e a definição fixada.
• Recover: retoma tarefas falhas ou canceladas a partir do ponto de recuperação disponível; confira a política e o checkpoint real.

Essas ações não são sinônimos. Um timeout do navegador ou cliente não comprova cancelamento no servidor. Antes de repetir, confira arquivos, transações já confirmadas e risco de duplicidade. Um checkpoint não desfaz automaticamente todas as gravações externas anteriores. Se houver ambiguidade, preserve o identificador e esclareça o estado do destino antes do próximo intento.

Migrar referências de um worker

Em Cloud workers, diferencie a política de agendamento do runtime e o estado da VM. Pause scheduling interrompe novas atribuições conforme o fluxo disponível; não equivale a desligar a VM. Confira trabalhos ativos e dependências. Drain permite terminar trabalho ativo sem aceitar novas atribuições quando essa opção estiver disponível.

Use Reassign references para selecionar origem, destino e referências, revisar o plano e aplicar somente uma migração válida. Backups de dependências ajudam a revisar ou restaurar referências pelos controles disponíveis. A operação altera metadados de afinidade e dependências; não copia arquivos, discos, bancos nem credenciais externas. O destino precisa conseguir acessar os recursos das tarefas migradas.

Prepare replacement abre o fluxo de preparação de outro worker. O anterior permanece até sua retirada explícita. Antes de transferir trabalho, confirme compatibilidade, permissões, rede e capacidade do novo runtime. Criar infraestrutura e reatribuir referências são etapas distintas.

Retirar sem perder o controle do recurso

Abra o diálogo de deprovision e revise recursos cloud, referências Dova, execuções e bloqueios. Refresh impact consulta o estado atualizado. Unavailable no provedor não comprova que a VM tenha sido removida; investigue o acesso antes de limpar o registro.

Quando permitido, Stop and deprovision exige uma confirmação explícita das duas ações. O fluxo solicita a parada e consulta novamente o impacto; só pede a exclusão se o servidor a permitir. O provedor pode continuar em estado de parada pendente. Nesse caso, consulte novamente mais tarde, sem presumir conclusão.

Se o provedor falhar, o registro fica disponível para investigação e nova tentativa. Quando a ausência da VM estiver confirmada, Clean up Dova record informa que apenas o registro ativo será limpo. Confira inventário e Audit. Registre o que foi confirmado, o que continua pendente e quem deve resolver. Uma solicitação enviada não é uma retirada concluída.

A CLI permite consultar objetos e execuções e realizar ações autorizadas pelo terminal. Esta guia usa os comandos e caminhos do cliente distribuído, sem apresentar todos os endpoints internos como uma API pública universal. A versão da CLI é independente da versão 22.0.5 da plataforma; confira a versão e a ajuda do artefato instalado antes de automatizar.

Preparação e autenticação

Abra Developer Tools, escolha a distribuição da sua plataforma e confira versão, estado de assinatura e SHA-256. Calcule o hash do arquivo baixado e compare com o publicado. Um nome de arquivo correto não substitui a verificação. Instale conforme as instruções do pacote e execute dova --version.

Crie uma API key pessoal para o laboratório e informe a URL autorizada do ambiente:

dova login --url https://dova-lab.example.invalid

O domínio .invalid é propositalmente ilustrativo e não oferece serviço. Substitua-o pelo host de laboratório da organização. A CLI solicita a chave em uma entrada interativa; não a coloque na linha de comando, em exemplos ou histórico compartilhado. Confira a identidade e o tenant retornados antes de continuar.

A configuração autenticada fica no perfil local. Proteja esse perfil e não anexe seu conteúdo a chamados. dova logout remove o login local; revogar a API key no servidor é outra ação. Para impedir uso em qualquer computador, revogue a chave pela interface e revise as automações dependentes.

Primeira verificação somente de leitura

Nos exemplos, Laboratorio é um Domain ilustrativo. Substitua pelo espaço autorizado:

dova status --output json
dova repository list --domain Laboratorio --output json
dova mapping list --name sample --limit 50 --output json
dova workflow list --status published --name sample --output json
dova run list --status failed,cancelled --sort createdAt --descending --output csv

Compare os resultados com Repository, Workflows e Monitor. Uma lista vazia pode ser correta para os filtros. Nomes não são necessariamente únicos; use os identificadores retornados nas ações seguintes. JSON facilita processar campos explícitos e CSV permite revisão tabular autorizada.

Caminhos usados pelo cliente

O cliente usa autenticação Bearer e espera JSON. As coleções não têm uma chave universal: Workflows usa orchestrations e execuções usa runs. Em uma integração direta, valide o esquema, a autorização e os erros esperados. Não converta uma falha de autenticação em lista vazia aparentemente válida. Uma API key continua sujeita ao tenant, papel e permissões do proprietário.

Executar um laboratório publicado

Os laboratórios de clientes e regional também têm uma verificação local histórica sem rede. Executar as regras pelo servidor é outra fase: prepare definições publicadas, permissões e destinos exclusivos. Essa fase comunica com o serviço e pode gravar saídas.

Para um Workflow com uma fonte de arquivo:

dova workflow run ID_WORKFLOW --input transform_workflows/inputs/customers.csv --wait --output json

Em várias fontes, repita --source no formato TASK_ID:SOURCE_NODE_ID=FILE. Use os identificadores reais da tarefa e dos nós:

dova workflow run ID_WORKFLOW --source ID_TAREFA:source_txt=transform_workflows/inputs/transactions.txt --source ID_TAREFA:source_xlsx=transform_workflows/inputs/customers.xlsx --wait --output json

Não combine --input e --source. O cliente também admite --var CHAVE=VALOR e --param CHAVE=VALOR; respeite tipos e definições permitidos pelo Workflow. Não inclua segredos. Registre o intento, confira o estado terminal e compare o CSV real com o oráculo; o término do comando não comprova qualidade dos dados.

Espera, recuperação e encerramento

--wait acompanha o intento até um estado terminal. --poll e --wait-timeout controlam a espera do cliente. Um timeout não prova que o servidor cancelou o trabalho; consulte novamente o mesmo identificador antes de iniciar outro. Cancelar, terminar, repetir e recuperar têm efeitos distintos e dependem do estado e das permissões.

Guarde versão do cliente, ambiente, identificadores, parâmetros não sensíveis, estado e comparação de saída. Proteja relatórios exportados. Encerre o login local quando apropriado e revogue chaves temporárias. Estes exemplos descrevem contratos do cliente; não significam que execuções contra um serviço tenham sido realizadas durante a preparação do manual.

Objetivo e modelo

Overview reúne o estado operacional do workspace: objetos definidos, atividade de execução, integridade e acessos a outras áreas. É um ponto de orientação, não uma reconciliação dos dados de negócio. Um contador de Workflows indica definições; um contador de execuções indica tentativas de processamento. Nenhum deles comprova, isoladamente, quantos clientes, faturas ou movimentos chegaram ao destino.

A visualização pertence ao tenant e ao perfil ativos. Antes de interpretar um número, confira ambos no menu de conta. As informações disponíveis dependem das permissões e capacidades habilitadas. Um usuário de leitura pode consultar uma seção sem ter ações de criação ou execução.

Roteiro recomendado

1. Abra Overview no painel esquerdo.
2. Revise Service health e a referência de sincronização antes de comparar métricas.
3. Observe os cartões Mappings, Workflows, Executions, Rows processed e Workers online, quando disponíveis.
4. Use Open Monitor, Workflows ou Mappings para passar do resumo ao objeto ou à execução que exige investigação.
5. Nos gráficos, selecione o período do incidente. Mantenha o mesmo período ao comparar atividade e resultados.
6. Se a visualização parecer desatualizada, use a recarga e aguarde o resultado; uma solicitação pendente não comprova ausência de atividade.

Também é possível verificar a navegação sem iniciar uma execução: localize um Workflow sintético pelo resumo, abra a definição e compare o identificador da última tentativa com Monitor. Mantenha separadas a definição salva, sua versão publicada e cada execução. Não é necessário gerar outra tentativa para conferir essa relação.

Caso de uso e prova de conceito de observabilidade

Prepare um workspace de laboratório com uma Session publicada e um Workflow que a utilize. A origem deve conter três linhas sintéticas e o destino precisa ser exclusivo do laboratório. Anote nome e versão dos objetos antes de executar.

Realize uma execução manual e preserve seu identificador. Abra Monitor, aguarde um estado terminal e confira o arquivo produzido. Depois volte a Overview e selecione um período que inclua o teste. O resultado esperado é uma atividade compatível com o registro de Monitor; o número exato depende das outras execuções presentes e do momento de atualização do resumo.

Repita a consulta com um perfil de leitura autorizado. A prova de conceito está correta se as métricas acessíveis continuam consultáveis e as ações não autorizadas permanecem restritas. Não é necessário alterar permissões globais: use uma conta de laboratório preparada pelo administrador.

Validação, erros e recuperação

Um gráfico vazio pode indicar ausência de execuções no período, um filtro sem correspondência ou uma consulta incompleta. Revise a mensagem e compare com Monitor antes de executar um processo novamente. Evite execuções duplicadas apenas para “fazer um número aparecer”.

Se houver Workers conectados, mas tarefas pendentes, revise compatibilidade, perfil, exclusões e capacidade em Configuration e Workers. Se a integridade da plataforma indicar problemas, registre horário, módulo e mensagem; não copie credenciais ou conteúdo sensível dos logs.

Relações e alcance

Overview resume informações; os detalhes de versão pertencem a Mappings, Sessions e Workflows, e o diagnóstico por execução pertence a Monitor. A prova de conceito é um procedimento proposto, não um teste executado durante a redação deste manual.

Objetivo e modelo

O Repository organiza o trabalho no tenant ativo por meio de Domains e Folders. Um Domain agrupa atividades relacionadas; cada Folder pertence a um único Domain. Mappings, Sessions, Workflows e Connections mantêm uma localização que ajuda a encontrá-los e compreender suas relações.

A hierarquia não cria outro tenant nem substitui a autorização. Shared within tenant disponibiliza um objeto no escopo permitido dentro do mesmo tenant. Não o publica para outra organização, não muda sua localização proprietária e não cria uma cópia.

Pré-requisitos e navegação

Confirme o tenant e a função ativa no menu da conta. Consultar o repositório, criar localizações e editar ou excluir objetos exigem as permissões correspondentes. A ausência de uma ação pode refletir uma restrição de acesso.

Combine categoria e localização: All, Mappings, Sessions, Workflows, Connections e Shared mostram recortes diferentes. Um objeto pode existir em outra Folder ou estar oculto por um filtro.

Criar uma estrutura de laboratório

1. Abra Repository e selecione New domain.
2. Informe Laboratório ETL e uma descrição indicando que a estrutura contém dados sintéticos.
3. Crie a Folder Clientes Demo e selecione o novo Domain em Parent domain.
4. Abra a Folder e confira o caminho de navegação e a lista antes de criar objetos.
5. No editor de Mapping, selecione o mesmo Domain e a mesma Folder. Salve um pequeno rascunho e localize-o novamente pela categoria Mappings.

Siga as validações de nome e descrição exibidas no formulário. Domains e objetos executáveis têm regras próprias: a aceitação de espaços em um Domain não garante um identificador válido para Mapping ou Session. Parent domain define a propriedade da Folder; não é um diretório de execução.

Interpretar o estado de uma Folder

Congelar e fechar têm efeitos distintos. Abrir um objeto Closed pela lista Shared não contorna seu ciclo de vida. Solicite ao responsável autorizado a revisão do estado; não copie o artefato para evitar a restrição.

Exemplo: propriedade e compartilhamento controlado

Crie as Folders Origem e Consumo no Domain de laboratório. Salve um Mapping em Origem e confira a localização no editor. Se permitido, ative Shared within tenant, escolha um escopo autorizado e salve conforme o ciclo de vida do objeto.

A partir de uma localização consumidora permitida, encontre o Mapping em Shared. Ele deve manter Origem como proprietária e ficar disponível apenas no escopo concedido. Uma identidade sem a permissão necessária deve continuar restrita. Use contas de laboratório autorizadas, sem envolver tenants de outros clientes.

Validação e recuperação

Se a lista estiver vazia, remova filtros e volte à localização superior. Se um nome for inválido, corrija o campo indicado sem recriar a estrutura. Se a exclusão for bloqueada por referências, examine primeiro os consumidores; não suponha uma exclusão em cascata.

Registre o identificador e a localização antes de reorganizar objetos. Nomes facilitam a navegação, mas suas referências não são caminhos comuns do sistema de arquivos. Após salvar, confira a localização persistida e encontre o mesmo objeto novamente.

Purge contents e Delete

Purge contents... remove permanentemente o conteúdo revisado, preservando o Domain/Folder selecionado e o histórico de execução. A prévia pode incluir artefatos, rascunhos, versões e Folders filhas. As abas dos artefatos removidos são fechadas e suas alterações não salvas são descartadas. Delete é outra operação, que remove uma localização vazia elegível.

1. Use um laboratório descartável e a permissão de administração de localizações. Abra o menu da localização correta e selecione Purge contents....
2. Examine o nome do destino, todos os totais e os bloqueios. Se estiver apenas estudando o formulário, use Cancel.
3. Para uma remoção intencional e autorizada, digite exatamente o nome solicitado e confirme que compreende a exclusão permanente.
4. Selecione Purge contents uma vez e aguarde. Se a revisão mudou, use Refresh preview e confirme novamente o alcance atualizado.
5. Se o resultado ficar incerto, use Check result antes de tentar outra remoção.
6. Confira que apenas o conteúdo revisado foi removido e que a localização e o histórico permanecem. Use Delete separadamente se também precisar excluir a localização vazia.

Localizações protegidas e Folders que não estejam Active têm restrições. Não altere registros internos para contornar bloqueios nem suponha que existe uma ação de desfazer. Uma lista filtrada vazia não comprova ausência de dependências.

Relações e limites

Continue em Mappings, Sessions e Workflows. A estrutura do Repository é diferente dos caminhos de arquivos acessíveis ao worker. O exemplo descreve uma verificação de aceitação para seu laboratório, sem afirmar que as permissões do seu tenant já foram testadas.

Objetivo e modelo

Um Mapping descreve como os registros são lidos, transformados e entregues por componentes conectados de origem, transformação e destino. Uma Session fornece o contexto reutilizável de execução; um Workflow coordena Sessions. Em um teste compatível somente com arquivos, Run executa o Mapping diretamente com o arquivo selecionado no navegador; não é obrigatório criar Session e Workflow.

Diferencie editar um rascunho, Save draft, Publish e Run. Salvar conserva o projeto. Publicar estabelece uma versão para consumidores autorizados. Executar processa dados. Os consumidores existentes podem manter uma referência publicada anterior.

Pré-requisitos e controles do editor

Confirme tenant, função e Domain/Folder de laboratório. Consulta, edição, publicação e execução têm permissões distintas. É necessário um worker elegível e compatível; componentes remotos também exigem Connections e acesso de rede no ambiente de execução. Siga a validação de nomes do editor e use um nome técnico como m_ClientesDemo.

Components pesquisa o catálogo; Configuration configura o componente selecionado. Domain, Folder e Shared within tenant definem localização e compartilhamento autorizado. Validate verifica o projeto; Auto arrange mapping, Zoom e Fit ajustam apenas a apresentação.

Arrange posiciona as dependências da esquerda para a direita. Requer pelo menos dois componentes e um grafo sem ciclos; um fluxo extenso pode continuar com rolagem horizontal. Modifica posições do rascunho, não registros nem a versão publicada. Se nada mudar, confira a organização atual, possíveis ciclos e a permissão de edição.

Exemplo: preparar um CSV de clientes

Baixe customers-demo.csvCSV · 2,2 kBAbrir arquivo: 18 registros sintéticos e oito colunas. A demonstração preservada produziu dez registros e seis colunas · clientes-demo-excel.csvCSV · 773 BAbrir arquivo. O resultado é um CSV que pode ser aberto no Excel, não uma pasta de trabalho XLSX.

1. Selecione Mappings → New Mapping. Informe nome e localização autorizada de laboratório.
2. Adicione Flat File input em Components. Em Configuration, selecione CSV, delimitador vírgula, cabeçalho na linha 1 e UTF-8. Confira os oito nomes de coluna.
3. Adicione as transformações da tabela e conecte portas compatíveis na ordem indicada. Selecione cada componente para configurar seus campos.
4. Adicione Flat File output: CSV, clientes-demo-excel.csv, vírgula, cabeçalho incluído, aspas duplas, modo minimal, finais CRLF e UTF-8 with BOM.
5. Use Validate, corrija os problemas e selecione Save draft. Depois use Publish, confirme Publish mapping e confira a versão publicada.
6. Selecione Run e escolha o CSV sintético no seletor de arquivos. Essa execução compatível de um único arquivo não exige uma Session ou um Workflow separado.
7. No Monitor, identifique a tentativa e aguarde seu estado final. Após o sucesso, use Download output quando houver saída armazenada.

Conferir o resultado

Compare contagem, cabeçalho exato, identificadores únicos, valores e ordem física com a referência. Espere dez registros, seis colunas e cliente_id crescente. DEMO-C002 resulta em CLIENTE DEMO BETA, ACTIVO e valor numérico 2500. A linha inativa com NO_NUMERICO deve ser filtrada antes da conversão. Zero é permitido neste exemplo; exigir valor positivo mudaria o contrato.

Compare números pelo valor: 2500.0 não precisa ser serializado como 2500.00. A demonstração preservada comprova esses resultados sintéticos, sem garantir desempenho. O laboratório de normalização de clientes é outro exemplo, com uma cadeia histórica de oito transformações, 1.000 entradas e 667 saídas esperadas.

Projeção e assistência

Field selector preserva linhas e valores dos campos selecionados e remove as outras colunas também do esquema de saída. fileName define o nome do arquivo, não suas colunas. Para campos extras inesperados, confira configuração salva, ramificação conectada, componentes posteriores e a versão realmente executada.

Você pode pedir um projeto configurado ao DovaAI, revisar a proposta e confirmar um rascunho. Criar o rascunho não publica, agenda nem executa o fluxo. Nomes atuais de Mapping têm 2–79 caracteres, começam por letra e usam apenas letras, números ou sublinhados.

Validação, falhas e recuperação

Uma porta conectada não comprova a existência de uma coluna obrigatória. Confira esquema de origem, renomeações anteriores, nulos e compatibilidade do conector. Falhas de conversão podem indicar filtros fora de ordem. Em Sessions com arquivos, revise os vínculos e o acesso do worker; um caminho local do navegador não é um caminho do worker. Mantenha credenciais em Connections.

Após alterar um Mapping usado por Sessions, confira seus avisos de versão e atualize as dependências deliberadamente. Publicar o Mapping não republica todos os consumidores. Preserve uma saída anterior para comparação; o estado de sucesso sozinho não comprova correção funcional.

Referências relacionadas

Consulte a referência de transformações para o catálogo mais amplo, incluindo Unpivot, Run sequence, Field fingerprint e Partition rank. A compatibilidade depende do motor e do worker. Use Monitor para evidências e Open items para navegar sem confundir rascunhos com versões publicadas.

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.

Objetivo e modelo

Um Workflow coordena tarefas, dependências e decisões. A Session associa o Mapping ao contexto de execução; o Workflow determina como essas Sessions são combinadas. O canvas mostra tarefas Start, Session, Decision, Timer e End e suas conexões.

As dependências publicadas têm versão. Uma tarefa Session referencia sua Session e sessionVersion, que por sua vez referencia uma versão de Mapping. Alterar um rascunho anterior não muda silenciosamente uma definição de execução já publicada.

Pré-requisitos

Prepare uma Session publicada e aceita, capacidade elegível e compatível, localização autorizada de laboratório e saída exclusiva. Consulta, edição, publicação, execução e administração de agendamentos exigem suas próprias permissões. Siga a validação de nomes e evite nomes de objetos produtivos nos testes.

Criar e testar um Workflow mínimo

1. Abra Workflows, crie um Workflow de laboratório e informe nome, Domain, Folder e escopo autorizado de compartilhamento.
2. Adicione uma tarefa Session entre Start e End. No inspetor, escolha a definição publicada em Reusable session e confira a versão referenciada.
3. Conecte Start → Session → End arrastando de cada porta de saída até a próxima entrada. Adicionar uma tarefa não a conecta automaticamente.
4. Revise overrides declarados e dependências. Com várias entradas, joinPolicy=any ou all controla o encontro de dependências, não a posição visual.
5. Use Auto arrange workflow e Fit workflow para examinar o grafo. Esses controles ajustam a apresentação, não os dados.
6. Selecione Validate, corrija problemas, use Save draft e Publish. Publicar estabelece a versão aceita sem executá-la.
7. Selecione Run. Se houver configuração de entrada, confira o modo oferecido para cada origem e forneça a entrada autorizada de laboratório. Um arquivo anexado ao chat do DovaAI não é uma entrada de execução.
8. Encontre a tentativa no Monitor e compare tarefas e saída com o resultado esperado.

Temporizadores e decisões complementares

Para uma espera controlada, insira Timer antes da Session e informe 5 em Delay (seconds). O campo aceita 1–604800 segundos. Timer atrasa essa tentativa; não cria um agendamento recorrente.

Em Decision, configure True branch expression (JSON). Declare a variável de Workflow runMode, tipo string, padrão full e valores permitidos full e sample. Esta condição compara seu valor:

{"ref":"variables.runMode","op":"eq","value":"full"}

Conecte as portas True e False a destinos explícitos. False representa a alternativa complementar; repetir a condição True não constitui um teste válido dos dois caminhos. Use a linguagem JSON documentada, não SQL ou scripts arbitrários.

Conferir tarefas e dados

O exemplo mínimo lê registros sintéticos name,amount e grava os campos previstos. Espere uma execução de Session no caminho escolhido e confira a saída independentemente. Registre o identificador da tentativa, versões de Session/Mapping e overrides fornecidos. Um override da tentativa não é uma edição persistente da Session.

Para Decision, teste cada valor de entrada com saídas separadas e confira a ramificação. Uma ramificação ignorada difere de uma tarefa com falha. O laboratório de clientes descreve outro exemplo histórico com 1.000 entradas, 667 saídas esperadas e definições para estudo; esta página não exige uma cópia privada do código.

Agendar após a aceitação manual

Configuration → Workflow Scheduler administra agendamentos reutilizáveis. Crie um agendamento autorizado, confira calendário, timezone e estado habilitado e associe-o ao Workflow publicado correto. A zona do agendador difere da preferência de apresentação de datas em Profile.

Valide primeiro uma execução manual. Depois confira a próxima hora prevista e, separadamente, a tentativa real correspondente. Um agendamento habilitado registra uma intenção futura, não uma execução concluída. Desabilite agendamentos temporários ao terminar.

Validação e recuperação

O validador aceita 2–100 nós e 1–300 links, rejeita ciclos, identificadores repetidos e dependências inválidas e exige caminhos válidos e alcançáveis. Para tarefas em espera, confira predecessores, elegibilidade do worker, slots e exclusões. Para falhas, investigue o primeiro erro relevante no Monitor.

Quando uma Session ou um Mapping mudar, examine os avisos de dependência antes de republicar os consumidores deliberadamente. Retomar um checkpoint depende de estado persistido compatível; não equivale a uma transação sobre todos os destinos externos. Verifique o risco de duplicação antes de repetir ou reutilizar uma entrada armazenada.

Próximas leituras

Consulte Sessions para vínculos e recuperação, Workers para capacidade, Monitor para evidências e a referência de expressões para condições compatíveis.

Objetivo e modelo

Monitor acompanha tentativas de execução e seus resultados. Sua unidade principal é a execução, não a definição salva de um Workflow. Duas tentativas podem usar entradas, parâmetros e dependências publicadas diferentes; compare identificadores e contexto registrado.

Sucesso é o resultado informado pelo motor. A aceitação funcional também exige conferir contagem, esquema, valores e o arquivo ou tabela corretos. Uma falha na entrega da notificação não é automaticamente uma falha de transformação.

Acesso e visualizações

Você precisa de permissão para consultar execuções do tenant ativo. Executar, cancelar, terminar, recuperar e administrar histórico podem exigir autorizações adicionais. Confira cada ação em vez de ampliar o papel de leitura para resolver um problema de visualização.

List, Gantt e Notifications separam registros operacionais, relações temporais e entregas de notificações. List e Gantt compartilham os filtros superiores. History pode expressar uma janela em minutes, hours ou days: confira a unidade antes de interpretar uma lista vazia.

Notifications tem tabela e paginação próprias; uma entrega não representa outra execução do Workflow. Em telas pequenas, tabelas largas podem exigir rolagem horizontal interna.

Investigar uma tentativa

1. Filtre por objeto, estado e horário aproximado. Confirme identificador e data da tentativa.
2. Abra os detalhes ou Operational log quando disponível.
3. Examine dependências e localize a primeira tarefa com erro relevante. Relacione-a ao Mapping, à Session e ao worker efetivos.
4. Revise entradas e parâmetros registrados para a tentativa. Não deduza esses valores apenas do rascunho aberto hoje.
5. Para trabalhos em espera, examine workers elegíveis, slots e predecessores antes de solicitar outra cópia.
6. Confira o destino antes de cancelar, terminar, recuperar ou repetir. Atualize o estado e leia a confirmação específica.
7. Guarde identificador, horário, tarefa e mensagem sem dados sensíveis para suporte; exclua segredos e registros de clientes.

Download e estado incerto

Uma tentativa de Mapping concluída com sucesso e saída armazenada pode oferecer Download output, conforme o acesso. Baixe o artefato daquela tentativa. Uma escrita em banco ou API não produz necessariamente um arquivo para download. Compare o arquivo retornado, não outro arquivo antigo de mesmo nome.

Um timeout do cliente não comprova cancelamento. Consulte a mesma tentativa antes de repetir. Se o estado mudar enquanto uma confirmação estiver aberta, atualize a evidência antes de agir. A janela de History é um filtro, não uma política de retenção.

Exemplo: falha controlada e tentativa corrigida

Use um Workflow sintético pequeno com saída exclusiva. Primeiro configure um caminho de origem inexistente na Session de teste. Espere uma falha final com erro identificável de arquivo ausente e nenhuma saída válida dessa tentativa.

Restaure o vínculo correto, execute uma nova tentativa autorizada e compare os identificadores. Espere sucesso final e saída com cabeçalho, linhas, valores e ordem conhecidos. Separe os arquivos para que uma saída residual não pareça ser o resultado corrigido.

Para recuperação por checkpoint, confirme primeiro estado persistido utilizável e compatível, além do comportamento do destino. Escolher recuperar não desfaz uma escrita externa parcial. Repetir uma carga append pode duplicar registros.

Diagnóstico e manutenção

Uma tentativa pendente pode aguardar capacidade, worker elegível ou dependências. Consulte Configuration e Workers; diferencie agente Offline, VM desligada e provedor Unavailable. Não gere execuções duplicadas porque uma atualização da tabela demorou.

A limpeza do histórico é uma manutenção separada, com alcance e confirmação próprios. Não cancela trabalhos ativos nem substitui uma política de retenção. Confira bloqueios, preserve evidências da ocorrência e não exclua registros para ocultar uma falha ainda não investigada.

Próximas leituras

Overview resume a atividade; Monitor fornece evidências por tentativa. Correções persistentes pertencem a Mappings, Sessions ou Workflows e seguem seu ciclo de publicação. Para problemas não resolvidos, use o suporte da Cloudata com evidências sem dados sensíveis.

Objetivo e modelo

Connections centraliza definições reutilizáveis de conexão e seus estados. Uma definição reúne tipo de sistema, parâmetros e um método de autenticação compatível. Um item no catálogo não comprova conectividade, licenciamento nem dependências instaladas no worker de execução.

A definição e as credenciais armazenadas são conceitos relacionados, mas distintos. Um indicador de credencial configurada não revela o segredo nem comprova que ele continua válido no sistema externo.

Pré-requisitos

Você precisa de permissão para consultar Connections e da autorização correspondente para criar, editar, testar ou retirar credenciais. Prepare um sistema de laboratório autorizado, uma conta com privilégio mínimo e conectividade a partir do worker que executará o Mapping.

O catálogo de autenticação contempla métodos como usuário e senha, certificados, identidades gerenciadas, credenciais de cliente OAuth e chaves de API. As opções dependem do conector selecionado; não são alternativas equivalentes disponíveis para todas as famílias.

Autenticação e custódia seguem as opções oferecidas pelo conector. Passwordless utiliza uma identidade de execução; a custódia externa exige uma referência protegida resolvível no contexto autorizado. Revise consumidores antes de trocar, revogar ou excluir a conexão. Editar metadados difere de substituir credenciais.

Configurar e verificar uma conexão

1. Abra Connections. Pesquise e confira os filtros antes de criar uma conexão duplicada.
2. Inicie uma nova conexão e selecione o conector correspondente ao sistema real.
3. Informe nome e localização no repositório. Preencha host, banco de dados, endpoint ou outros campos exigidos pelo conector.
4. Escolha um método de autenticação compatível e informe segredos apenas nos campos específicos de credenciais.
5. Salve e corrija as validações de campo. Confira a confirmação; fechar o formulário não comprova que a operação foi concluída.
6. Execute o teste disponível e leia o resultado completo.
7. Se houver consulta de metadados, examine os objetos acessíveis à conta e confirme esquema e colunas.
8. Associe a conexão a um Mapping de laboratório e faça uma pequena leitura ou escrita autorizada em um destino exclusivo de teste.

Exemplo: extração limitada

Prepare uma tabela sintética com três registros e uma conta de origem somente para leitura. Configure a conexão de laboratório, teste-a e consulte os metadados. Crie um Mapping que leia apenas essa tabela e grave um arquivo de teste por meio de uma Session e de um worker compatível.

O resultado esperado contém três linhas com os mesmos valores sintéticos, exceto pelas transformações configuradas explicitamente. A escrita no banco de origem está fora deste exercício e não deve ser concedida para viabilizar o teste.

Para estudar uma falha, use uma definição temporária separada com um endpoint incorreto de laboratório. Registre a categoria do erro e restaure o endpoint. Não altere uma conexão compartilhada nem suas credenciais para provocar o problema.

Diagnóstico e recuperação

Separe falhas de rede, autenticação, autorização e esquema. Uma conta válida pode não ter acesso a uma tabela. Um host acessível pelo computador do navegador pode ser inacessível pelo worker. Verifique os drivers e as capacidades do conector nesse ambiente de execução.

Após trocar credenciais, repita o menor teste e a menor execução relevantes. Um resultado anterior não comprova acesso com o novo segredo. Para suporte, informe o identificador da conexão, a família do conector e uma mensagem sem dados sensíveis; não envie senhas, tokens, certificados privados ou referências internas de segredos.

Relações e limites

Consulte Mappings para formato e lógica, Sessions para contexto e Workers para conectividade. Os campos e limites específicos estão na referência de conectores; não suponha comportamento idêntico entre famílias.

Objetivo e modelo

Notification channels define destinos reutilizáveis para eventos autorizados, como os de Workflows. O canal informa para onde enviar e se está habilitado; a política decide quando gerar e encaminhar o aviso. O template define o conteúdo de email, e SMTP fornece seu transporte de plataforma. Uma configuração correta em uma camada não comprova o resultado das outras.

Confirme conta, tenant e papel. Consultar canais e administrá-los ou testá-los são capacidades diferentes. Use apenas destinatário ou endpoint de laboratório sob seu controle. Endereços e webhooks podem ser sensíveis mesmo sem uma senha visível; não os publique em capturas ou exemplos.

Tipos e campos

Ao editar, um segredo já configurado pode não ser reapresentado. Um campo protegido em branco não significa ausência de credencial armazenada. Leia o indicador e a ajuda antes de substituir. Não coloque segredos no nome, na descrição ou no texto do aviso para contornar o fluxo protegido.

Criar e verificar um canal

1. Abra Notification channels e use Search notification channels para identificar um destino autorizado já existente.
2. Se precisar de outro, selecione New notification channel e informe um nome claro.
3. Escolha Type e preencha somente os campos exigidos por esse tipo; siga sua validação específica.
4. Confira tenant, destino, descrição e estado de Enable this channel. Salve e aguarde a resposta.
5. Reabra o registro para confirmar os dados persistidos que a aplicação permite consultar.
6. Quando disponível e autorizado, use Test com conteúdo sintético. Confira a resposta e o sistema receptor do laboratório.
7. Associe o canal na configuração do Workflow pertinente e escolha os eventos autorizados. Revise também política, severidade, supressão, deduplicação e horários quando aplicáveis.
8. Gere um evento controlado, compare Delivery history com o receptor e restaure as políticas temporárias ao concluir.

Reload, Filters, Clear filters, Columns e Export CSV alteram a consulta ou a apresentação do gerenciador. Exportar o inventário não deve ser tratado como exportação de segredos. Revise referências antes de excluir um canal utilizado por Workflows.

Exemplo: LabOperations

No laboratório, crie LabOperations com uma caixa de email controlada e associe-o a um Workflow sintético pequeno. Configure o evento pretendido e anote um identificador seguro e o horário esperado. O canal deve permanecer salvo, e o resultado informado deve corresponder ao recebimento esperado ou a uma supressão explicada pela política. No email, confira assunto, texto e links sem incluir dados de entrada da execução.

Para verificar a desabilitação, desmarque Enable this channel e repita apenas o ensaio necessário. O canal permanece disponível para administração, mas não recebe eventos de Workflow enquanto desabilitado. Reabilite se esse for o estado final pretendido. Um aviso de sucesso local pode indicar aceitação pelo transporte, não recebimento final.

Conteúdo e SMTP têm responsáveis diferentes

Para email, revise separadamente Execution email template e Email delivery. Use variáveis do catálogo, como %WORKFLOW_NAME%, %STATUS% e %RUN_ID%, sem inventar sintaxe; o corpo de texto deve transmitir o mesmo resultado do HTML. Um preview não testa conexão nem entrega. O gerenciamento global de SMTP exige a autoridade de plataforma correspondente e não deve ser feito adicionando credenciais ao template.

Consulte a política para eventos, severidades, destinatários, deduplicação, resumo e horários silenciosos. Confira fuso e limites de horário. Estados sent, failed, suppressed e acknowledged de Delivery history não são equivalentes; suppressed não é automaticamente falha SMTP.

Erros e recuperação

1. Confirme que o evento foi gerado e que o canal correto estava associado e habilitado.
2. Revise se a política suprimiu ou adiou o aviso antes de alterar o destino.
3. Confira o tipo, destinatários, credencial configurada e mensagem segura de autenticação ou transporte.
4. Se for email, encaminhe um problema global de SMTP à administração autorizada.
5. Se o resultado continuar pendente, consulte seu estado antes de enviar testes repetidos: o receptor pode já ter aceitado a primeira tentativa.

Não diagnostique uma lista filtrada vazia como perda de canal. Limpe filtros e confira o tenant. Uma negativa de permissão exige revisão de acesso; criar uma cópia em outro workspace não corrige o escopo. Para assistência, use o formulário Cloudata, sem incluir endpoints secretos.

Leituras relacionadas

Workflows · Monitor · Templates, SMTP e política.

Objetivo e modelo

Um worker fornece capacidade para execuções compatíveis. O inventário apresenta identidade, estado, recursos e capacidades. Conexão do agente, estado de energia da VM e elegibilidade para uma Session específica são observações diferentes.

Provisionamento e operações do provedor pertencem ao Administrator. Workers no workspace ajuda a compreender a capacidade disponível ao tenant. Um worker público pode oferecer capacidade compartilhada autorizada; atribuir uma Session a ele não publica sua definição, dados ou artefatos para outros usuários ou tenants.

Pré-requisitos

Você precisa de permissão de consulta e de privilégios específicos para registrar ou modificar workers. Prepare um host autorizado e siga as instruções da distribuição vigente. Mantenha tokens de enrollment no fluxo protegido, fora de capturas, chamados e repositórios.

Compare os requisitos do Mapping com tipos de componente, conectores, recursos, isolamento, perfil e acesso de rede do worker. A presença de um conector no editor não instala drivers nem libera rede. Selecionar um worker não copia arquivos locais do navegador para seu sistema de arquivos.

Interpretar o inventário

Os detalhes podem incluir host, plataforma, versão, recursos, último heartbeat, perfis e conectores. Use essas informações para verificar compatibilidade sem divulgar detalhes desnecessários da infraestrutura. O worker integrado de control plane não é elegível para executar Sessions ou Workflows do tenant.

Slots ponderados e concorrência

Slots representam capacidade ponderada. Por exemplo, quatro slots podem admitir quatro trabalhos de peso um ou dois trabalhos de peso dois, sujeitos aos outros limites e à capacidade real informada. A admissão multijob exige capacidade explícita e informações atuais compatíveis; aumentar um limite configurado não torna um agente antigo concorrente.

Avaliar capacidade para uma execução

1. Abra Workers. O painel Dova Worker Agent oferece pacotes, Register worker, pesquisa, filtros, colunas e paginação.
2. Localize o worker de laboratório pelo identificador e tenant/pool autorizado; confira estado e heartbeat recente.
3. Compare tipos de componente, conectores, versão e perfis com o Mapping real. Confira slots disponíveis e requisitos de recursos.
4. Confirme que a identidade do worker resolve Connections e acessa as localizações autorizadas de entrada e saída.
5. Revise o uso do padrão do tenant ou de um override da Session. Uma seleção explícita continua sujeita a elegibilidade e exclusões.
6. Execute um caso sintético pequeno e confira o worker realmente escolhido e o resultado no Monitor.
7. Antes de substituir ou retirar capacidade, examine trabalhos ativos, referências e políticas padrão; use o procedimento suportado no Administrator.

Exemplo: elegibilidade antes de capacidade

Prepare um Mapping de arquivos publicado, uma Session de laboratório e um worker autorizado. Disponibilize três registros sintéticos para esse worker e use uma saída exclusiva. Espere que o worker correto receba a tentativa e produza a saída conhecida. Registre juntos os identificadores do worker e da tentativa.

Como comparação, examine uma Session que exija uma capacidade ausente, sem forçar sua execução. Espere uma restrição de compatibilidade, não uma atribuição permissiva. Isso verifica a seleção, sem comprovar vazão máxima ou disponibilidade permanente.

Recuperação e limites operacionais

Sem heartbeat, verifique o serviço autorizado e a comunicação com o control plane. Se houver inelegibilidade, examine ciclo de vida, capacidades, recursos, exclusões e perfil. Não mude o worker padrão de todo o tenant para resolver um caso isolado sem analisar os consumidores.

Unavailable no provedor não comprova que a VM deixou de existir. Parar uma VM, retirar seu registro e desprovisionar recursos são operações distintas, com verificações de propriedade, referências e execuções ativas. Excluir registros do inventário não substitui esses procedimentos.

Capítulos relacionados

Configuration administra roteamento, perfis e exclusões; Sessions permite herdar ou substituir a seleção do worker. Use Monitor para evidências e as guias de workers do Administrator para instalação ou retirada.

Objetivo e estrutura

Configuration reúne cinco áreas: Dova Integration Runtime, Execution profiles, Workflow Scheduler, Runtime health e Git / DevOps. A política seleciona capacidade autorizada; o perfil define condições de execução; o agendador solicita trabalhos futuros; a saúde informa observações atuais.

Salvar uma política não comprova que existe um worker compatível disponível nem que um trabalho terminou. Em telas estreitas, use a rolagem horizontal interna das tabelas para acessar colunas fora da área visível.

Pré-requisitos e alcance

Confirme tenant e permissões. Consultar configurações, registrar workers, salvar políticas, administrar perfis e editar agendamentos podem exigir privilégios diferentes. Registre os valores atuais antes de um teste e examine as Sessions que herdam configurações globais.

Revisar e configurar a área correta

1. Abra Configuration e identifique a área relacionada à necessidade antes de editar.
2. Em Dova Integration Runtime, confira identidade, estado, modo, worker padrão e capacidades. Runtime inventory oferece pesquisa, atualização e seleção de colunas.
3. Em Tenant routing policy, examine Default worker, Fallback e Save policy. A seleção continua sujeita a elegibilidade, compatibilidade e exclusões; não suponha atribuição automática a qualquer worker disponível.
4. Use as subabas Workers e Exclusion rules para conferir capacidade e restrições. Uma exclusão modifica o roteamento, não remove o worker.
5. Em Execution profiles, procure um perfil adequado antes de criar outro. Revise unidades, limites, herança e consumidores. Perfil de execução difere de perfil de provisionamento cloud no Administrator.
6. Em Workflow Scheduler, prepare um agendamento reutilizável com nome, frequência, timezone e estado habilitado explícitos. Associe-o ao Workflow correto somente após aceitar uma execução manual.
7. Salve apenas a alteração planejada, aguarde a confirmação e reabra para conferir persistência. Save pode permanecer desabilitado quando nada mudou.
8. Consulte Runtime health separadamente e continue em Workers ou Monitor para evidências do worker e da tentativa.

Exemplo: política herdada e override explícito

Crie duas Sessions de laboratório com o mesmo Mapping publicado. Mantenha Use tenant default na primeira; ative Override worker na segunda apenas se houver outro worker elegível. Conserve transformações, entradas e parâmetros equivalentes.

Registre o padrão do tenant e examine o worker efetivo de cada Session. A primeira deve resolver pela política do tenant; a segunda mantém a escolha explícita, sujeita a elegibilidade. Quando autorizado, execute uma entrada sintética pequena e compare os workers realmente escolhidos no Monitor.

Apenas em um tenant exclusivo de laboratório, altere o padrão por Save policy, confira as duas Sessions e restaure o valor original. Não faça esse teste com cargas compartilhadas ativas.

Conferir agendamento e saúde

Para um agendamento, registre separadamente timezone, próxima hora prevista e identificador da tentativa resultante. A zona de apresentação de Profile não é a zona do agendamento. Desabilite os calendários temporários ao terminar; fechar Configuration não os desativa.

Runtime health descreve o ambiente, sem comprovar a correção dos dados. Relacione essas observações ao heartbeat, à capacidade e à saída real de uma tentativa identificada.

Erros e recuperação

Sem worker elegível, examine capacidades, ciclo de vida, recursos, exclusões e perfil antes de aumentar limites. Em divergências de horário, confira timezone, estado habilitado e Monitor. Evite alterar política, perfil e calendário ao mesmo tempo, pois isso dificulta o diagnóstico.

Após erro ao salvar ou alteração concorrente, recarregue com segurança e compare o estado persistido antes de reenviar. Um valor selecionado no formulário não comprova mudança no servidor. Não repita execuções só porque um resumo de saúde ainda não foi atualizado.

Git / DevOps: versões e promoção

A quinta aba, Git / DevOps, apresenta a integração com Bitbucket Cloud. Git → Dova planeja e implanta artefatos revisados em ordem de dependências. Dova → Git exporta versões publicadas e referências fixadas para revisão, sem exportar credenciais.

1. Abra Git / DevOps com a permissão correspondente e confira o estado. Configuration required indica necessidade de configuração; a aba visível não comprova que existe um repositório conectado.
2. Baixe o kit oferecido e examine as instruções e a configuração de exemplo antes de adicioná-lo ao repositório Bitbucket autorizado.
3. Configure workspace de destino e vínculos dos artefatos. Armazene a chave de API do Dova como variável protegida do pipeline, fora de arquivos JSON e commits.
4. Execute primeiro o planejamento sem aplicar alterações, conforme o kit. Revise artefatos, dependências, versões e conflitos antes de habilitar implantação ou exportação programada.
5. Após uma promoção autorizada, confira versões publicadas e referências no Dova. Exportar ou fazer commit com sucesso não substitui uma verificação de execução.

No laboratório, prepare um Mapping e sua Session/Workflow publicados, examine um plano e registre o alcance esperado antes de aplicar. Se estiver apenas aprendendo, pare na revisão. O kit vigente define comandos e configuração exatos; esta página não inventa um comando de implantação nem afirma que a integração do seu tenant está habilitada.

Próximas leituras

Consulte Workers, Sessions, Workflows e Monitor. Os testes descrevem um método de aceitação, sem garantir capacidade ou disponibilidade.

Objetivo e modelo comercial

Plans and subscriptions abre o painel Plans & billing, com as opções comerciais efetivas do tenant ativo, revisão do pedido e histórico de pedidos e pagamentos. A disponibilidade depende de tipo do tenant, ciclo de vida, plano e ofertas autorizadas. Um preço apresentado, um pedido criado, um pagamento informado e uma assinatura ativa representam etapas diferentes.

Confirme sempre importes, moeda, período, quantidade, tributos e condições vigentes na plataforma. Este manual de Dova 22.0.5 não fixa tarifas. Uma oferta por tenant referencia o catálogo global versionado; não duplica o catálogo nem reescreve termos de pedidos anteriores. Uma conversão aceita de trial deve preservar o mesmo workspace operacional e a identidade dos objetos.

Pré-requisitos e escopo

Confirme conta, tenant e papel no menu da conta antes de abrir checkout. Use apenas ofertas e operações permitidas pelo seu escopo. Para aprender, utilize um ambiente de pagamentos de teste autorizado e dados sintéticos. Uma revisão de formulário deve terminar antes de cobrança real. Não recrie o tenant ou mova objetos para simular uma conversão comercial.

Revisar e acompanhar um pedido

1. Abra Plans and subscriptions e confira plano, ciclo de vida e capacidades apresentados. Use Reload quando precisar de dados atuais.
2. Selecione uma opção permitida e leia sua versão, preço, moeda, quantidade, período e termos.
3. Em Review your order, confira os itens e os totais antes de completar os dados.
4. Escolha Receipt type, como Boleta ou Factura quando oferecidos, e informe os dados fiscais aplicáveis.
5. Confira Billing email e Billing address e selecione um Payment method disponível para essa oferta.
6. Revise novamente o resumo antes de Create order. Só confirme uma compra efetivamente autorizada.
7. Quando o fluxo exigir, informe Transfer or payment reference e use Report payment. Informar uma referência não equivale a confirmação bancária.
8. Em Orders & payments, acompanhe o resultado do pedido existente e a assinatura aceita, sem iniciar outra compra apenas porque a tela demorou.
9. Confirme que o identificador do tenant e dos objetos existentes permanece o esperado e que as capacidades correspondem ao contrato ativo.

Remove retira a seleção do carrinho conforme o estado do fluxo. Não representa uma ação universal de cancelamento para pedidos já registrados. Um retorno do navegador, uma fatura emitida ou um estado manual não prova pagamento confirmado.

DPU, DPU-h e condições do contrato

Nos planos habilitados para DPU, DPU mede capacidade de processamento ativo e DPU-h combina capacidade com tempo. Por exemplo, 4 DPU × 15/60 h = 1 DPU-h. Development e Production mantêm fundos e concorrência separados. Os créditos seguem períodos financiados verificados, que não precisam coincidir com meses do calendário. A espera em fila e a validação estrutural não são processamento ativo faturável; o Workflow agrega consumo das tarefas sem cobrar o mesmo trabalho novamente.

Uma assinatura legada conserva seus termos comprados até uma mudança aceita e ativada. Abrir a calculadora ou ver uma nova oferta não converte o contrato. A concorrência contratada não cria workers, e o consumo efetivo ainda depende de recursos e elegibilidade. Consultas DovaAI aceitas possuem quotas por tenant e usuário separadas do DPU; um título administrativo não significa acesso ilimitado.

Exemplo e validação

No sandbox autorizado do tenant Training, selecione uma oferta sintética, confira moeda, tributos e quantidade e cancele antes de pagar se o objetivo for apenas estudar o formulário. Verifique que essa revisão não criou uma assinatura não pretendida. Se a prática incluir uma ordem de teste autorizada, confirme o resultado do sandbox e a continuidade do tenant separadamente; não apresente um teste como aceitação produtiva.

O resultado esperado de uma conversão é um resultado comercial aceito, o mesmo tenant e capacidades consistentes com a assinatura. Compare também identificadores de Repository antes e depois. Um preço novo não deve alterar os termos históricos de um pedido anterior.

Erros e recuperação

Se a oferta não aparecer, confira elegibilidade, ciclo de vida, plano e papel. Se os valores divergirem, revise moeda, quantidade, período e condições antes de enviar. Para um pedido pendente, resolva a operação existente em vez de repetir checkout. Não marque uma fatura como paga apenas para liberar funções. Use o formulário Cloudata para revisão de uma dúvida comercial sem enviar informações de pagamento sensíveis.

Leituras relacionadas

Administração de assinatura e DPU · Catálogo e ofertas · Repository · Monitor.

Objetivo e modelo

Developer Tools reúne distribuições da Dova CLI por plataforma, checksum, informação de assinatura, instruções iniciais e notas de versão. Também fornece acesso ao gerenciamento autorizado de chaves pessoais. A CLI acessa os mesmos objetos e ciclos de execução permitidos ao usuário; não contorna tenant, papéis, limites ou regras da interface.

A versão da CLI pode diferir da versão Dova 22.0.5. Nome do pacote, disponibilidade, integridade e assinatura são propriedades distintas. Use um equipamento de laboratório e a distribuição publicada para seu sistema de destino, que pode diferir do sistema do navegador.

O que conferir antes de instalar

Preparar a CLI com acesso mínimo

1. Abra Developer Tools ou Downloads no menu da conta e selecione a distribuição do sistema de destino.
2. Revise versão, estado de assinatura e checksum; baixe pelo Download apresentado.
3. Calcule SHA-256 com a ferramenta da plataforma e compare exatamente com o catálogo antes de instalar.
4. Siga as instruções do pacote e confira a versão do executável. Se outra instalação existir no PATH, identifique qual está sendo usada.
5. Em API keys, use Create API key somente quando permitido e para uma finalidade definida. Proteja o valor apresentado pelo mecanismo apropriado.
6. Siga o Quick start para autenticar no serviço de laboratório autorizado. Use o prompt interativo para a chave, sem incluí-la em argumentos compartilhados.
7. Confira identidade e tenant e comece por leituras. Compare resultados com o módulo equivalente da interface.
8. Ao terminar, diferencie logout local de revogação no servidor e revise outras automações antes de revogar uma chave em uso.

O inventário pode apresentar nome, prefixo e uso da chave. O prefixo identifica o registro sem expor o valor completo. A credencial permanece sujeita à identidade, ao tenant e aos direitos efetivos; criar outra chave não concede permissões ausentes. Não prometa configuração de expiração ou escopo que o formulário não ofereça.

Exemplo de verificação de integridade e leitura

Em PowerShell, calcule o hash do arquivo obtido, substituindo o nome ilustrativo pelo arquivo real:

Get-FileHash -Algorithm SHA256 -LiteralPath .\dova-cli-baixado.zip

Compare o valor completo, não apenas alguns caracteres. Um hash diferente exige interromper o uso e verificar a origem. Depois de instalar conforme o pacote atual, um ensaio mínimo de leitura documentado é:

dova --version
dova login --url https://dova-lab.example.test
dova status --output json

https://dova-lab.example.test é um marcador reservado e não funciona como serviço. Substitua pela URL HTTPS do laboratório autorizado e introduza a chave no prompt. Confira a ajuda da distribuição instalada antes de adicionar opções ou subcomandos. O resultado esperado é a CLI correta informando a versão e uma consulta autorizada coerente com a identidade e o tenant da interface. Uma lista vazia válida não é um erro de autenticação.

Execuções e ciclo de vida da chave

Comece por status e pelas listas de leitura oferecidas no Quick start. Execuções com arquivos, variáveis, bindings ou recuperação por identificador produzem efeitos e exigem um exercício separado com fontes e destinos exclusivos do laboratório. Revise Sessions, Workflows e Monitor antes de automatizar escrita ou repetição de uma execução.

dova logout limpa o estado de autenticação local conforme a ferramenta. Revoke no gerenciamento do servidor impede novos usos da chave em outros equipamentos. As ações têm escopos diferentes; sair localmente não revoga uma credencial usada por outra automação. Proteja também o perfil local porque ele pode reter autenticação.

Erros e recuperação

Se o download não estiver disponível, leia a mensagem do catálogo sem adivinhar uma URL. Se SHA-256 não coincidir, não execute o pacote. Em 401 ou 403, confira chave ativa, validade informada, identidade, tenant e permissão; não trate a resposta como uma lista vazia. Renovar uma chave não corrige uma autorização ausente.

Um timeout pode deixar trabalho ativo no servidor. Consulte o identificador existente no Monitor antes de repetir um comando com efeitos. Após atualizar a CLI, confira novamente versão e ajuda do pacote. Para suporte, utilize o formulário Cloudata sem enviar chaves, perfis ou tokens.

Leituras relacionadas

Administração de distribuições e chaves · Repository · Sessions · Workflows · Monitor.

Filtros de leitura da CLI

Essas formas correspondem aos comandos de leitura publicados. Confira a ajuda da versão instalada antes de adicionar opções. Não confunda workflow list com workflow run: o segundo executa trabalho e exige um exercício de laboratório autorizado separado.

Exemplo de consultas filtradas

Após autenticar no laboratório e conferir a identidade, as consultas abaixo apenas leem recursos autorizados. Substitua Domain, nomes e filtros pelos valores sintéticos do seu ambiente:

dova repository list --domain "Laboratório ETL" --output json
dova mapping list --name sample --limit 50 --output json
dova workflow list --status published --name customer --limit 50
dova run list --status failed,cancelled --sort createdAt --descending --output csv

Compare identificadores com Repository e Monitor. Um resultado vazio pode significar que o filtro não corresponde a nenhum registro. Não inclua a chave em nenhum comando compartilhado.

Objetivo e modelo

O menu de conta mostra a identidade autenticada e o contexto de trabalho. Em Dova, permite revisar tenant e perfil, trocar para um workspace autorizado, ajustar a aparência e abrir funções pessoais. É o primeiro lugar a conferir antes de editar ou executar algo quando uma pessoa pertence a mais de um workspace.

O perfil ativo determina as ações disponíveis. Trocá-lo não concede novos privilégios: apenas permite usar um perfil já autorizado. Da mesma forma, a lista de workspaces não é um catálogo aberto de tenants.

Estrutura do menu

A interface pode abreviar nomes longos. Antes de uma operação sensível, confirme identidade e tenant pelos campos disponíveis, não apenas pelas iniciais do avatar.

Dova e Administrator compartilham o desenho do menu, mas suas ações não são todas iguais. Administrator oferece Back to workspace, enquanto Dova dispõe de Profile. As diferenças correspondem ao contexto de navegação.

Antes de trocar de tenant ou perfil, ou de encerrar a sessão, revise Open items e resolva as alterações pendentes com Save ou descarte deliberado. Aguarde a confirmação de salvamento. Uma aba aberta ou uma otimização de memória do editor não substitui a persistência do objeto.

Procedimento seguro para trocar de contexto

1. Abra o controle de conta no cabeçalho.
2. Confira o workspace atual e o perfil.
3. Se precisar de outro workspace, selecione uma associação autorizada.
4. Aguarde a conclusão da troca e confirme novamente tenant e perfil.
5. Abra o módulo necessário e confira se os objetos pertencem ao contexto esperado.
6. Se uma ação desaparecer, revise permissões e associação antes de presumir uma falha de interface.

Para alterar a aparência, selecione Mode e Palette. Os controles nativos mantêm a navegação pelo teclado. Em menus com altura limitada, role dentro do menu para alcançar as ações inferiores, incluindo Sign out.

Prova de conceito: comparar perfis sem alterar dados

Use uma conta de laboratório com dois perfis previamente autorizados: um de leitura e outro de edição. Abra Mappings, anote quais ações estão disponíveis e troque para o perfil de leitura pelo menu.

Resultado esperado: a navegação permitida continua disponível e as ações que exigem edição ficam restritas. Não tente usar solicitações manuais para contornar a restrição. Volte ao perfil de edição e confira o contexto antes de continuar.

Depois alterne entre Light e Dark, percorra o menu pelo teclado e feche com Escape. O foco deve voltar ao controle que abriu o menu. O teste verifica acesso e operação; ele não amplia a autorização da conta.

Validação e recuperação

Se a troca de contexto falhar, preserve a mensagem e confira qual contexto continua ativo. Clicar em uma opção não comprova a troca. Se o workspace esperado não estiver na lista, peça ao administrador para revisar a associação.

Sign out encerra a sessão pelo fluxo da aplicação. Fechar uma aba do navegador não substitui essa ação em equipamentos compartilhados. As alterações de senha têm efeitos adicionais descritos em Profile.

Relações e limites

As preferências pessoais ficam em Profile; distribuições e chaves estão em Developer Tools; os objetos abertos são gerenciados por Open items. A prova de conceito é uma orientação de validação com identidades sintéticas, não uma verificação das permissões de usuários reais.

Objetivo e estrutura

Profile reúne configurações pessoais, informações da conta e ações de privacidade. Não é o editor administrativo de usuários nem um mecanismo para trocar livremente de tenant ou atribuir perfis a si mesmo.

Abra o menu de conta de Dova e selecione Profile. O diálogo mostra identidade e contexto, além das seções de preferências, segurança e dados. Em telas pequenas, o corpo permite rolagem para manter controles e fechamento acessíveis.

Preferências pessoais

Confira nome, e-mail, tenant e perfil antes de alterar algo. Timezone usa um fuso horário, como America/Lima, salvo com Save preferences. A ajuda informa que ele é usado para apresentar datas e horários na experiência da conta.

Não confunda essa preferência com o fuso de um agendamento de Workflow. Mudar a apresentação de uma data não deve ser interpretado como reagendamento automático dos processos. Consulte Configuration para o scheduler.

Use Change photo para selecionar PNG, JPEG ou WebP. O fluxo aceita um arquivo de entrada de até 10 MB, recorta o centro para uma imagem quadrada de 256 pixels e a otimiza antes de enviar. Remove photo remove a foto existente. Aguarde a mensagem de resultado antes de fechar; uma falha no processamento não equivale a salvamento. Teste com uma imagem de laboratório sem informações sensíveis.

Segurança

A interface exige de 12 a 128 caracteres para a nova senha. O servidor pode aplicar verificações adicionais. Não use a mesma senha na documentação e em uma conta real.

O aviso informa que a mudança de senha encerra todas as sessões de navegador e dispositivos confiáveis. Prepare o método de acesso e os fatores de autenticação antes da mudança. Não use essa ação como teste rotineiro em uma conta operacional compartilhada.

Dados e privacidade

Download profile export permite solicitar uma exportação do perfil. Trate o arquivo como informação pessoal e salve-o somente em um local autorizado.

Request profile data deletion e Request account deletion são solicitações diferentes. O fluxo exige confirmação digitando o e-mail e usando Submit request. O aviso informa que as solicitações são revisadas antes de afetar a propriedade compartilhada do tenant ou registros de auditoria retidos.

Portanto, a confirmação de uma solicitação não comprova exclusão imediata. Não prometa a remoção automática de todos os dados associados ao workspace.

Prova de conceito reversível de preferências

Em uma conta de laboratório, anote o fuso atual. Altere Timezone para America/Lima, salve e abra Profile novamente. Resultado esperado: o valor persistido corresponde ao selecionado e as datas pertinentes aparecem conforme a preferência oferecida.

Restaure o fuso anterior ao terminar. Para verificar validações no laboratório, use um fuso claramente inválido e observe a mensagem sem insistir com solicitações repetidas.

Você pode abrir uma solicitação de exclusão para inspecionar a confirmação e cancelá-la com Cancel, sem enviar. Não use Submit request como ensaio se não pretende iniciar o processo.

Erros, recuperação e relações

Se o salvamento falhar, preserve a mensagem e confira o valor persistido antes de repetir. Se a sessão terminar após a mudança de senha, autentique-se novamente pelo fluxo autorizado; isso não significa perda de objetos.

Relações e alcance

Consulte Conta para contexto e aparência e Developer Tools para chaves pessoais. A prova de conceito proposta não foi executada durante a redação e não constitui uma solicitação real de mudança de senha ou exclusão.

Objetivo e modelo

Open items permite alternar entre editores de Mapping, Session e Workflow. Cada aba identifica o tipo de objeto, seu nome e seu estado de edição. A barra organiza o trabalho no navegador; não representa uma nova versão do objeto nem uma cópia dos dados.

Um objeto aberto pode ter alterações pendentes. Mantê-lo visível em uma aba não garante que essas alterações estejam salvas ou publicadas. A distinção é essencial ao alternar entre um Mapping, sua Session e o Workflow consumidor.

Acesso e controles

A barra aparece nas visualizações compatíveis quando há objetos abertos. Em larguras limitadas, More permite acessar os itens que não cabem na linha. O nome pode ser abreviado, enquanto o identificador de tipo ajuda a distinguir objetos com nomes parecidos.

A disponibilidade depende do tipo, da existência do objeto, das permissões e do estado. Uma aba fixada recebe tratamento diferente nas operações de fechamento; isso não protege o objeto contra alterações administrativas.

Ao fechar um editor modificado, interprete Save, Discard e Cancel conforme a confirmação apresentada. Cancel mantém o contexto; descartar alterações locais não exclui o objeto já salvo. Otimizações de memória e navegação entre editores também não substituem Save.

Procedimento recomendado

1. Abra um Mapping pelo seu gerenciador.
2. Abra a Session que o utiliza e depois um Workflow relacionado.
3. Alterne entre os três usando Open items e confirme nome e tipo antes de editar.
4. Salve ou descarte deliberadamente as alterações pendentes.
5. Use o menu de contexto somente após revisar quais abas serão afetadas.
6. Em dispositivos móveis, abra More para localizar os itens que não aparecem na linha.

Antes de usar Reload, confira se existem alterações locais. A recarga consulta o servidor e pode exigir resolver o rascunho; ela não equivale a atualizar apenas um número no cabeçalho.

Prova de conceito: navegar com um rascunho pendente

Prepare três objetos sintéticos vinculados: m_ClientesDemo, s_ClientesDemo_Test e um Workflow de laboratório. Abra seus editores. Modifique um campo permitido do Mapping sem publicar e use a barra para mudar para a Session.

Resultado esperado: a aplicação mantém o estado de edição conforme o fluxo de rascunhos e permite identificar o objeto ativo. Volte ao Mapping e confira o campo alterado antes de decidir se deseja salvar.

Em seguida, tente fechar o objeto com alterações. Observe a confirmação e cancele o fechamento para verificar se o editor continua disponível. Por fim, descarte ou salve explicitamente as alterações do laboratório e feche a aba.

Repita em uma largura móvel com objetos suficientes para exibir More. Confira se é possível localizar o objeto, ativá-lo e alcançar o fechamento por teclado ou toque.

Erros e recuperação

Se Reload informar que o objeto não existe mais, não crie imediatamente outro com o mesmo nome: confira no gerenciador o que aconteceu e quem tem autorização para recuperá-lo. Investigue um erro de ação na aba sem presumir que a definição foi alterada corretamente.

Depois de salvar e fechar, reabra por Repository ou pelo gerenciador e confira identificador, conteúdo e versão. Reabrir corretamente não transforma um rascunho em uma versão publicada. Antes de trocar de tenant ou encerrar a sessão, resolva os pendentes de cada editor.

Bloqueios de edição e permissões continuam valendo enquanto o objeto está aberto. Uma mudança de perfil ou contexto pode alterar as ações disponíveis; revise o menu de conta.

Relações e limites

Open items complementa Mappings, Sessions e Workflows. Não substitui a publicação nem a verificação em Monitor. A prova de conceito verifica rascunhos e navegação; fechar uma aba não implica excluir o objeto do repositório.

Objetivo e alcance

O DovaAI utiliza o tenant autorizado, o módulo e a visualização atual para explicar controles, componentes e configurações do Dova. Pode orientar sobre o catálogo de 36 componentes de Mapping e propor um projeto revisável. O contexto da interface não concede acesso a outros tenants, dados ocultos, credenciais ou operações fora das suas permissões.

As respostas seguem o idioma da mensagem: espanhol, inglês ou português. Você pode pedir explicitamente “em português” ou “in English”. Quando a mensagem não identifica claramente outro idioma, mantém-se a referência disponível. Não é necessário escolher um modo de assistência ou idioma antes de conversar.

Antes de começar

Confirme tenant e permissões. Anexar estrutura exige acesso a Mappings; criar um rascunho exige a autorização correspondente. A configuração do serviço pertence ao responsável autorizado e fica fora da conversa. Nunca cole chaves, senhas, certificados privados ou informações de clientes.

As cotas dependem do plano e do contrato efetivos. Abrir outra conversa não reinicia o consumo nem concede mais capacidade. Um serviço configurado ainda pode recusar solicitações por disponibilidade ou limites.

Solicitar e revisar um Mapping

1. Descreva objetivo, campos e resultado esperado. Por exemplo: “Mantenha name e amount; troque apenas o valor exato jorge por Jorge em name e prepare saída CSV”.
2. Se precisar de contexto do arquivo, use Attach data file e selecione uma amostra sintética CSV, TSV, JSON, JSONL ou XLSX. Confira nomes e tipos inferidos; a inferência não substitui o esquema de negócio.
3. Revise componentes, direção das conexões, ajustes e campos pendentes. Para a troca exata, Replace values deve usar field=name, find=jorge, replacement=Jorge, matchMode=exact e caseSensitive=true. Isso não coloca qualquer nome em maiúscula inicial.
4. Confirme a criação apenas quando a proposta corresponder ao objetivo e à localização autorizada. Uma proposta não é um Mapping executado. Se houver vários rascunhos, examine cada artefato e suas permissões.
5. Abra o rascunho criado e complete manualmente arquivos de execução, Connections, caminhos e parâmetros. Confira os ajustes pendentes; anexar uma amostra ao chat não coloca um arquivo no worker.
6. Siga o ciclo normal de Validate, Save draft e Publish. Depois faça uma execução sintética autorizada e aceite a saída no Monitor. A assistência não publica, agenda nem executa a proposta automaticamente.

O que utiliza do anexo

O serviço inspeciona temporariamente a amostra para obter nome, formato, nomes dos campos, tipos inferidos e ajustes da origem. O contexto enviado ao serviço de IA contém essa estrutura, sem linhas da amostra nem bytes do arquivo original. Nomes de arquivos, colunas e planilhas também podem ser sensíveis: use dados de laboratório.

A estrutura não é salva como entrada de execução. Forneça o arquivo real pelo fluxo de Run ou pelos vínculos apropriados. Um anexo no chat não comprova conectividade, autorização sobre o destino ou compatibilidade do worker.

Conferir o resultado

No exemplo, confira Flat File input → Field selector → Replace values → Flat File output. Field selector mantém somente name e amount nos registros e no esquema; Replace values altera o valor exato indicado. Confira que outras capitalizações e nomes diferentes permaneçam iguais e compare o CSV real após a execução.

Você pode mover, minimizar ou abrir o chat em outra janela quando o navegador permitir. O contexto se adapta ao mudar de módulo no mesmo tenant autorizado. Mudanças de identidade, tenant ou permissões invalidam ações antigas; não há garantia de continuidade após sair da conta ou reiniciar o navegador.

Limites e recuperação

A amostra deve ser não vazia e ter até 15 MiB; JSON e JSONL aceitam até 1 MiB. O esquema exige 1–32 nomes de campo únicos. CSV/TSV precisa de cabeçalho válido e codificação UTF-8. A estrutura anexada expira em 15 minutos e pode ser perdida ao reiniciar o serviço; anexe-a novamente se expirar.

Um esquema amplo demais ou um contexto inválido pode ser rejeitado. Corrija a amostra sem ampliar permissões. Se a cota acabar, consulte o plano. Se a proposta estiver incompleta, esclareça o objetivo e preencha os campos no editor. Se o resultado da criação ficar incerto, encontre o rascunho no Repository antes de confirmar novamente.

Continuar com um teste controlado

Use name,amount,internal_note e duas linhas sintéticas com nomes jorge e Jorge. Espere apenas name e amount na saída; ambos os nomes ficam Jorge, os valores permanecem iguais e internal_note desaparece. Continue em Mappings e Monitor. Para dúvidas não resolvidas, use o formulário de suporte da Cloudata sem segredos ou dados de clientes.

O que o grafo representa

Um Workflow organiza a ordem de execução. O Mapping transforma registros e a Session fornece o contexto de execução. A posição das caixas facilita a leitura do canvas; são as conexões e suas condições que estabelecem as dependências reais. Prepare primeiro uma Session publicada e um worker elegível. Criar ou publicar também exige as permissões adequadas no tenant e na localização do Repository.

O Dova 22.0.5 exige exatamente um Start e pelo menos um End. O grafo deve ser acíclico: nenhum caminho pode voltar a uma tarefa anterior. Todos os nós precisam ser alcançáveis a partir de Start e levar a um End. Adicionar uma caixa sem conectá-la deixa o desenho incompleto.

Escolher cada tarefa

Um Timer de cinco segundos atrasa esse percurso. Ele não cria um agendamento recorrente nem garante um horário exato para iniciar o trabalho seguinte.

Conectar e validar

1. Abra Workflows e crie um desenho de laboratório em uma localização autorizada.
2. Adicione uma tarefa Session entre Start e End. Escolha a Session publicada no inspetor.
3. Arraste da porta de saída para a porta de entrada da tarefa seguinte. A conexão habitual é Success. Adicionar uma tarefa não a conecta automaticamente.
4. Se precisar de uma decisão, adicione Decision e configure True branch expression (JSON). Conecte as duas ramificações a destinos válidos.
5. Use Validate e corrija os problemas antes de Save draft e Publish. A validação aceita 2–100 nós e 1–300 conexões.

Exemplo de decisão verificável

Declare uma variável do Workflow chamada runMode, do tipo string, com valor padrão full e valores permitidos full e sample. Este trecho mostra sua configuração; não é um documento completo para importação:

{"name":"runMode","type":"string","default":"full","enum":["full","sample"]}

Insira a condição abaixo em True branch expression (JSON):

{"ref":"variables.runMode","op":"eq","value":"full"}

Com full, a condição seleciona True; com sample, seleciona False. O editor constrói a negação para False. Não forneça JavaScript, SQL nem uma condição diferente que possa ativar os dois caminhos. A expressão consulta o contexto da execução; ela não conta automaticamente os registros de um CSV.

Condições e convergência

A definição permite conexões success, failure, always e expression. A condição usa o estado ou contexto da tarefa de origem. Uma conexão de Workflow não representa uma transferência de dados entre colunas. No editor, as decisões exibem True/False e uma conexão comum aparece como Success.

Quando uma tarefa tem vários pais, joinPolicy distingue any e all; o padrão é any. Determine quais conexões precisam ser satisfeitas antes de escolher a política. Não exija os dois caminhos mutuamente exclusivos de uma decisão como se ambos fossem executados.

Conferir a execução e resolver problemas

Execute primeiro um percurso mínimo e localize a tentativa no Monitor. Confira tarefas executadas, ramificações ignoradas e versão da Session. Uma tarefa ignorada por uma condição é diferente de uma tarefa com falha. Se o fluxo parar, revise pais, condições, dependências publicadas e capacidade do worker. Ciclo, conexão duplicada ou extremidade inexistente exigem corrigir o desenho; mover as caixas não resolve isso.

Continue em publicação e dependências ou no laboratório CSV completo.

Três objetos com responsabilidades próprias

Um Mapping descreve o fluxo de dados. Uma Session referencia uma versão do Mapping e define vínculos, parâmetros e perfil de execução. Um Workflow seleciona Sessions e organiza suas tarefas. A cadeia publicada precisa ser coerente: um Workflow publicado não corrige uma Session incompleta nem concede acesso a uma Connection.

Trabalhe em uma localização de laboratório e confira separadamente permissões de edição, publicação e execução. Prepare arquivos sintéticos, Connections autorizadas e capacidade de worker antes de aceitar a cadeia.

Salvar, publicar e executar

Salvar um CSV no navegador não coloca o arquivo no sistema de arquivos do worker. Da mesma forma, um rascunho preparado pelo DovaAI não é publicado nem executado nessa etapa de criação.

Publicar uma cadeia controlada

1. Abra o Mapping e confira origem, transformações, destino e esquema. Valide e salve o rascunho.
2. Publique o Mapping e registre a versão escolhida para o laboratório.
3. Abra a Session e confira a referência do Mapping, a versão e os vínculos de entrada e saída. Valide e publique a Session.
4. Abra o Workflow. Em cada tarefa Session, confira Reusable session e a versão consumida. Revise os avisos de dependência.
5. Valide conexões e condições, salve o rascunho e publique o Workflow.
6. Execute manualmente com uma saída de laboratório independente. Registre a tentativa e compare o Monitor com o arquivo ou destino obtido.

Exemplo: alterar uma regra com rastreabilidade

Suponha que m_CustomersActive v1 mantenha status=ACTIVE. A Session v1 e o Workflow v1 foram aceitos com três registros. Você altera o Mapping para descartar também amount=0. Para a amostra do laboratório, o resultado esperado da nova regra passa a ser dois registros.

Publique deliberadamente a nova versão do Mapping, confira a referência mantida pela Session e atualize os consumidores pelas ações disponíveis. Repita a revisão no Workflow e teste novamente. Preserve as duas saídas para explicar a diferença. Não deduza a versão executada pelo rascunho que ficou aberto em outra aba.

Evidência mínima de aceitação

• Nome e versão de cada objeto da cadeia, além do identificador da tentativa.
• Parâmetros e vínculos efetivos do teste, sem copiar segredos.
• Estados das tarefas e primeiro erro relevante, quando houver.
• Esquema, quantidade de registros e regras de negócio verificadas na saída.

As referências do Mapping podem incluir versão e fingerprint; uma execução fixa seu contexto autorizado. Isso identifica o que foi consumido, mas não torna imutável um arquivo externo que pode mudar. Preserve ou identifique também os dados de entrada. A validação bem-sucedida do objeto é apenas uma parte da aceitação.

Atualizar ou voltar a uma referência conhecida

Se uma dependência estiver indisponível, confira publicação, tenant, localização, permissões e versão. Se salvar funcionar, mas Run falhar, investigue worker, caminhos, Connections e dados. Republicar repetidamente não substitui a leitura do erro real.

Para comparar com uma versão aceita, use os mecanismos de versão e referência disponíveis e uma saída separada. Restaurar uma definição não desfaz gravações anteriores em bancos de dados, APIs ou armazenamento. Conclua a revisão do agendamento antes de habilitar execuções recorrentes.

Antes de criar um agendamento

Agende somente um Workflow publicado e testado manualmente. Confirme as permissões para administrar calendários e executar o Workflow, entradas disponíveis sem interação com o navegador, Connections autorizadas e capacidade de worker. Um arquivo anexado no teste manual não se torna uma origem permanente para futuras execuções agendadas.

Abra Configuration → Workflow Scheduler para preparar um calendário reutilizável e associe-o pelo Workflow. Revise recorrência, horário inicial, fuso e estado habilitado no formulário. Mantenha-o desabilitado enquanto verifica os valores.

Preparar uma execução diária

1. Publique e execute manualmente o Workflow de laboratório; confirme a saída.
2. Crie um nome reconhecível, como daily_customers_lima.
3. Escolha recorrência diária às 02:15 e selecione America/Lima. Se usar a representação cron, o equivalente é 15 2 * * *.
4. Confira a próxima execução calculada. O fuso do calendário é independente do fuso de Profile usado para exibir datas.
5. Associe o calendário ao Workflow e revise a concorrência. Habilite o agendamento somente depois de aceitar os valores.
6. Após o horário previsto, localize a tentativa no Monitor. Confira tarefas e saída: uma próxima data calculada não comprova execução bem-sucedida.

Interpretar horário local e cron

Não substitua o fuso IANA por uma abreviação ambígua como CST. Em fusos com horário de verão, confira o comportamento previsto perto da transição. Revise o calendário ao mudar seu fuso; alterar apenas o idioma ou Profile não comprova uma reprogramação da execução.

Separar execuções simultâneas de tarefas paralelas

concurrencyPolicy controla a coexistência de execuções do mesmo Workflow: allow, forbid ou replace; o padrão é forbid. Revise essa política antes de agendar cargas que possam se sobrepor. Substituir uma execução não garante desfazer operações externas já realizadas.

maxParallelTasks limita tarefas paralelas dentro de uma execução: aceita 1–64, com padrão 4. Isso não reserva workers, slots, CPU nem capacidade do destino. A seleção real continua dependendo de recursos, autorização e disponibilidade. Uma sequência simples facilita interpretar a primeira aceitação do laboratório.

Conferir e manter o calendário

• Confira o Workflow e as versões publicadas, o calendário associado e o estado habilitado.
• Revise horário e fuso da próxima execução e compare depois uma tentativa real.
• Confirme qual entrada permanente foi lida e onde a saída foi gravada.
• Ao retirar um calendário, confira tentativas existentes: desabilitar futuros disparos não cancela uma execução ativa.

Quando o horário previsto não produz resultado

Confira primeiro se o calendário está habilitado e associado, se o Workflow está disponível e se a política de concorrência impediu sobreposição. Depois examine fila, worker e erros das tarefas. Não crie calendários duplicados como primeira solução: eles podem iniciar gravações extras quando a causa original for resolvida.

Um Timer espera dentro de um percurso; não substitui o Scheduler. Consulte Monitor e recuperação para escolher a ação adequada ao estado observado.

Localizar a tentativa correta

Abra Monitor e ajuste período, tipo de objeto, estado e worker quando aplicável. Procure o identificador da tentativa, não apenas o nome do Workflow: um objeto pode ter várias execuções. Os filtros de período mudam o que é exibido; não garantem retenção ilimitada da evidência.

Abra os detalhes para conferir tarefas, horários, versões, parâmetros autorizados e eventos ou logs disponíveis. Aceitação na fila não significa que o worker iniciou o trabalho. O estado succeeded ainda exige verificação independente do resultado de negócio.

Escolher a ação conforme o estado

As opções também dependem da sua autorização e do contexto atual. Um botão ausente não concede permissão para recriar a operação por outro caminho.

Investigar antes de tentar novamente

1. Abra a tentativa e localize a primeira tarefa que falhou ou ficou aguardando.
2. Leia seu erro real, definição e versão, parâmetros efetivos, worker e acesso às entradas ou Connections.
3. Confira se o destino recebeu dados, mesmo quando a tentativa global falhou.
4. Corrija a causa na configuração adequada e determine se precisa publicar uma versão nova ou completar uma entrada.
5. Escolha Re-run ou Recover conforme o que deve ser executado novamente e o contexto de recuperação disponível.
6. Identifique a tentativa resultante e confira tarefas, esquema, registros e regras de negócio. Preserve a relação com a tentativa anterior.

Exemplo: uma saída já existe

Uma Session grava um CSV e uma tarefa posterior falha. Repetir todo o Workflow com o mesmo caminho de saída pode sobrescrever ou duplicar resultados, conforme o destino. No laboratório, use uma saída independente e confira seus três registros antes de comparar. Para um destino de banco de dados com append, revise chaves e repetibilidade antes de iniciar outra gravação.

Recover não é uma transação distribuída. O ponto de recuperação e os commits anteriores determinam qual trabalho permanece persistido. Até uma execução encerrada pode ter confirmado lotes antes de receber a instrução. Arquivos e serviços externos também podem ter mudado desde a primeira tentativa.

Aceitar o resultado recuperado

• A nova tentativa tem identificador e uma relação de recuperação ou repetição explicável.
• Tarefas executadas, ignoradas e reutilizadas correspondem à ação escolhida.
• A saída atende colunas, quantidade, chaves e valores esperados, sem duplicatas imprevistas.
• Estados de worker, tarefa e tentativa são coerentes e não resta uma operação desconhecida em andamento.

Esperas e falta de evidência

Quando uma tarefa aguarda, revise pais, condições, políticas de concorrência, recursos e slots do worker. Se faltarem logs ou saída, confira filtros, permissões e evidência retida; não conclua o resultado a partir de um painel vazio. Evite limpar o histórico necessário à investigação. Para obter ajuda, use o formulário da Cloudata com a versão 22.0.5, identificador da tentativa e exemplo sintético, sem credenciais ou dados de clientes.

Objetivo e resultado esperado

Este exercício percorre Mapping → Session → Workflow no Dova 22.0.5. Usa quatro clientes sintéticos e mantém os três cujo estado é ACTIVE. Esse resultado esperado deve ser conferido no seu ambiente; não representa uma nova medição com dados de clientes. Para aprender Run direto com upload pelo navegador, consulte também a demonstração de normalização CSV.

Baixe a entrada · active-customers-input.csvCSV · 147 BBaixar, a saída esperada · active-customers-expected.csvCSV · 89 BBaixar e as instruções dos arquivos · README.mdMarkdown · 2,0 kBBaixar. Eles não contêm credenciais nem importam automaticamente uma definição.

Preparar o laboratório

Você precisa de permissão para projetar, publicar e executar os três objetos, uma localização no Repository e um worker compatível. Coloque a entrada em um caminho autorizado para esse worker e prepare uma saída de laboratório independente. Um caminho no seu computador não é necessariamente visível para um worker remoto. Se o diálogo de execução solicitar um arquivo, complete a entrada conforme o contexto exibido; não suponha que um anexo anterior continue disponível.

customer_id,name,status,amount
D001,Demo Alfa,ACTIVE,125.50
D002,Demo Beta,INACTIVE,40.00
D003,Demo Gamma,ACTIVE,80.00
D004,Demo Delta,ACTIVE,0.00

1. Projetar e publicar o Mapping

1. Crie m_CustomersActive. Adicione Flat File input com formato CSV, delimitador vírgula, cabeçalho e as quatro colunas da amostra.
2. Conecte Row filter: field=status, operator=equals, value=ACTIVE. O filtro usa o valor do registro.
3. Adicione Field selector com customer_id, name e amount. Isso remove status do esquema e da saída.
4. Conecte Flat File output CSV com cabeçalho. Valide o grafo, salve e publique o Mapping.

A cadeia contém quatro componentes. Ela não converte amount em número; o exercício preserva seus valores textuais. Adicione e configure Convert type antes de uma operação que precise comparar ou ordenar valores numericamente.

2. Configurar a Session

1. Crie s_CustomersActive e selecione a versão publicada do Mapping.
2. Configure vínculos de entrada e saída do laboratório e selecione perfil de execução ou worker elegível para seu ambiente.
3. Revise parâmetros e política de falha/repetição. Para a primeira aceitação, evite repetições que ocultem uma causa não resolvida.
4. Valide e publique a Session. Confira se sua referência e esquema correspondem ao Mapping selecionado.

3. Organizar e executar o Workflow

1. Crie wf_CustomersActive. Adicione uma tarefa Session e escolha s_CustomersActive em Reusable session.
2. Conecte Start → Session → End. Valide, salve e publique.
3. Execute manualmente com os arquivos de teste. Registre o identificador da tentativa e abra o Monitor.
4. Aguarde um estado final e abra a tarefa Session para conferir a saída disponível. Ainda não habilite um calendário recorrente.

4. Comparar o resultado

Compare por customer_id. Sem Row sort, não transforme a ordem observada em uma garantia universal. Diferenças de aspas ou quebras de linha do CSV, por si só, não invalidam os valores do exercício. Não afirme igualdade byte a byte quando apenas comparou registros.

Ampliar o exercício e diagnosticar

Depois de aceitar o Workflow mínimo, insira Timer com Delay (seconds)=5 para observar uma espera sem mudar os dados. Para explorar Decision, use runMode e a expressão de Tarefas e conexões. Teste os dois valores em tentativas separadas antes de agendar.

Se restarem quatro registros, confira o filtro e a versão executada. Se faltar uma coluna, confira Field selector e destino. Se não iniciar, revise publicação da Session, caminhos e elegibilidade do worker. Se falhar após gravar, consulte a recuperação antes de repetir.

Objetivo e pré-requisitos

Overview reúne indicadores administrativos de tenants, usuários, assinaturas, faturas, uso e segurança. Use o painel para identificar onde investigar antes de alterar uma configuração. Ele complementa o Monitor de execuções do Dova; um indicador administrativo não confirma o resultado de um Workflow. A conta, o workspace e o papel ativo determinam as informações e ações disponíveis.

Antes da revisão, abra o menu da conta e confirme a identidade e a associação ao workspace. Uma conta com várias associações pode apresentar resultados diferentes conforme o contexto ativo. Os exemplos usam apenas dados sintéticos: laboratorio-documentacao e worker-demo-a não são registros que você deva localizar em produção.

Interpretar os painéis

Em Worker resource history, escolha Worker ou os cartões de comparação. Use Search worker..., provedor, estado e ordenação para localizar o recurso. Os períodos 1h, 6h e 24h alteram a janela de observação. Os controles de zoom mudam o intervalo do gráfico; Reset o restaura e Refresh solicita observações atuais. Ausência de amostras, falha de carregamento e valor zero têm significados diferentes.

Procedimento de revisão diária

1. Abra Administrator e confirme conta, workspace e papel ativo.
2. Selecione Overview e aguarde o fim do carregamento. Anote mensagens de erro ou cobertura insuficiente.
3. Leia os cartões de resumo e identifique a categoria que precisa de investigação.
4. Para recursos, selecione o worker e um período comparável. Verifique várias amostras e a cobertura informada.
5. Abra Users, Subscription & billing ou Cloud workers, conforme o sintoma, e confira o registro de origem.
6. Depois de uma correção autorizada, atualize o módulo responsável e confirme o estado resultante.

Exemplo: aumento de memória em um laboratório

Durante uma transformação CSV fictícia, a memória de worker-demo-a aumenta. Selecione esse worker, compare a janela com o horário da execução e abra o detalhe correspondente no Monitor. O resultado esperado é associar observações ao período e ao worker corretos. Não aumente a capacidade apenas porque um ponto do gráfico foi alto; confirme duração, recorrência e resultado da execução.

Validação e recuperação

Uma revisão concluída identifica tenant, registro afetado, período, sintoma e próximo passo, sem publicar dados pessoais ou segredos. Se um cartão não carregar, preserve a mensagem visível e verifique sessão e conectividade antes de tentar novamente. Se um atalho não aparecer, confira o papel ativo e a permissão do módulo. Uma aba antiga pode precisar de atualização após mudanças.

Consulte também: Cloud workers, Audit, Preferences.

Objetivo e pré-requisitos

Cloud workers contém Workers, Provisioning history, Connections e Profiles. O registro Dova, a VM no provedor e o agente de execução são estados relacionados, mas distintos. Antes de provisionar, confirme tenant, conta cloud autorizada, permissões, regiões e capacidade. Google Cloud, AWS e Azure são tipos de conexão; a operação disponível depende das capacidades efetivas do provedor e do seu papel.

Uma conexão aprovada deve existir e satisfazer as regras de identidade, rede e localização. Um perfil define os recursos solicitados. A estimativa opcional de preço não garante valor de fatura nem disponibilidade de capacidade. Use um laboratório autorizado para praticar; os exemplos não autorizam criar recursos em uma conta de produção.

Preparar a conexão cloud

1. Abra Connections → New connection.
2. Preencha Name, Provider, Account / project ID e Default region.
3. Complete a identidade e a rede específicas do provedor com a configuração aprovada. Use federação ou impersonação temporária conforme o fluxo; não informe senhas cloud ou chaves privadas nesse formulário.
4. Escolha Authorized regions e confirme que a região padrão está incluída.
5. Use Save connection, siga as instruções de verificação e, se necessário, Copy steps. Execute Verify ou Re-verify.
6. Em Capacity, confira a capacidade e a margem para novos workers. Valores indisponíveis ou desconhecidos exigem investigação.

Preparar o perfil

1. Abra Profiles → New profile.
2. Defina Name, Provider, vCPU, Memory (GB) e Disk (GB).
3. Em SKU compatibility, diferencie Exact resources, que requer um tamanho correspondente, de Allow next larger SKU, que permite a seleção maior suportada.
4. Revise Status e as informações opcionais de preço, salve em Save profile e reabra o registro para confirmar os recursos.

Provisionar e verificar

1. Em Workers, selecione Provision worker.
2. Confirme Tenant e Worker access. Leia a diferença entre Private to this tenant e Public shared.
3. Selecione Cloud connection, Worker profile e Maximum concurrent slots.
4. Defina Worker name, Region e Zone quando exigido pelo provedor. Resolva erros de localização pelo controle de atualização suportado.
5. Use Continue e Back para revisar as etapas; solicite Get optional quote apenas se a estimativa for útil.
6. Selecione Create worker uma vez e acompanhe Provisioning history. Confirme separadamente recurso cloud, inscrição do agente, heartbeat e elegibilidade.

Diferenciar Status e Runtime

Use Refresh para atualizar a observação do provedor. Abra More actions ou o menu contextual da linha para as ações autorizadas. O acesso direto da linha abre View details. Ative a coluna opcional Runtime em Columns. Um worker público compartilha capacidade entre tenants autorizados; não torna pública uma Session, seus dados ou suas credenciais.

Operar planejamento, VM e Reset

Pause scheduling interrompe novas atribuições e permite terminar as atuais; Resume scheduling volta a admiti-las. Essas ações não suspendem ou retomam a VM no provedor. Pause scheduling, quando oferecido, é o fluxo de esvaziamento. Start VM e Stop VM dependem do estado e da autorização; Start VM também pode retomar uma VM suspensa quando o provedor permitir. Um worker padrão, ocupado ou público pode bloquear Stop VM.

Reset VM reinicia de forma forçada uma VM GCP Running e exige confirmação. Antes do envio, Dova verifica novamente a ausência de trabalhos, execuções e reservas ativas em todos os tenants autorizados a usar o worker. Um worker padrão ou público pode ser reiniciado se essa verificação completa confirmar inatividade; referências e política de compartilhamento são preservadas. A ação aparece apenas para provedores e estados compatíveis.

Enquanto o Reset não tiver resultado confirmado, novas atribuições e outro Reset ficam bloqueados. Reset pending ou Check reset informa a operação separadamente do Status principal da VM. Use Refresh para consultar, sem reenviar. Running, por si só, não prova conclusão; é necessário resultado da operação nativa e uma observação válida. Após a confirmação, Runtime ainda depende do próximo heartbeat para demonstrar prontidão do processo.

Rede de workers GCP

Novos workers GCP são provisionados apenas com IP privado, sem seletor de IP público. Configure Cloud NAT na região da sub-rede para HTTPS de saída até Dova e os destinos de pacotes e dependências autorizados, como Debian, PyPI e GitHub. Private Google Access atende APIs Google, mas não substitui Cloud NAT para destinos externos. Revise DNS e regras de saída exigidas pelos conectores autorizados.

Para manutenção, use IAP SSH com OS Login quando os papéis IAM e o firewall estiverem configurados. O agente obtém trabalhos e envia heartbeat por conexões de saída; não precisa de uma porta de aplicação aberta para receber trabalhos. A política public_shared trata de capacidade compartilhada e é independente de IP público.

Exemplo e falhas comuns

No laboratório, prepare worker-demo-a, confira Status, Runtime, heartbeat e slots e associe uma Session sintética compatível. Execute uma transformação pequena e confirme o resultado no Monitor. Se uma criação ou Reset demorar, consulte a operação antes de repetir. Para um worker Online, mas inelegível, revise tenant, capacidades e slots. Para uma VM Running com Runtime Offline, revise o serviço e a conectividade sem expor logs sensíveis.

Consulte também: Instalação, Migração e retirada, Overview.

Objetivo e pré-requisitos

Users permite consultar identidades, associações a tenants, papéis e prontidão para acesso. Visualizar contas e gerenciá-las são capacidades distintas. Um administrador que abre a tabela pode não estar autorizado a criar usuários, modificar papéis ou gerar ativações. Confirme o workspace e o papel ativo antes de editar.

Localizar e consultar uma conta

1. Abra Users na navegação lateral.
2. Use Search users, os filtros de coluna ou Filters em telas menores.
3. Ajuste Columns ou use Clear filters para voltar à visão mais ampla.
4. Abra View details e confira email, tenant, papéis, Status e Access.
5. Use Export CSV apenas quando necessário e armazene os dados de contas em local autorizado.

Criar ou editar uma conta

1. Pesquise o email antes de criar uma identidade; uma ativação pendente não exige outra conta.
2. Selecione New user ou Edit user. Preencha Name, Email e Tenant.
3. Escolha Active, Inactive, Suspended ou Disabled, conforme a finalidade e as opções permitidas.
4. Em Select roles, escolha o conjunto mínimo para o tenant. Se disponível, use Add tenant para uma associação autorizada; selecione a associação antes de Set default ou Remove.
5. Para uma conta nova, revise a entrega do primeiro acesso. Copy activation link apresenta o link após a criação; Send reset email envia as instruções ao endereço cadastrado.
6. Envie uma vez, aguarde a resposta e reabra a conta para confirmar associação, papéis e estado.

Gerenciar o primeiro acesso

Em uma conta elegível, abra Manage access e revise Available actions. Conforme o estado, o fluxo pode oferecer Reset access, Resend activation, Send new activation, Create activation ou Revoke activation. Leia o impacto antes de confirmar. Uma nova ativação substitui a anterior conforme o fluxo; emitir repetidamente links não resolve um problema de transporte de email.

Delivery method aparece quando a ação exige ativação local. Selecione Copy activation link ou Send activation email. Confirme o botão que corresponde à ação escolhida, verifique o novo Access e conclua em Done. Links são de uso único e devem seguir um canal privado autorizado, sem capturas, tickets públicos ou documentação.

Convert to local access altera o mecanismo de login; não é apenas reenvio de email. Restore SSO access restaura o caminho de SSO em contas elegíveis, preservando as associações e os papéis. Diagnostique primeiro o provedor e a política. Quando disponível, View as user (read only) cria um contexto de inspeção: confirme a indicação de somente leitura e saia dele antes de administrar.

Exemplo, validação e recuperação

Em um laboratório, prepare Operador de Documentação com um email controlado e um papel limitado. Verifique uma leitura permitida e uma operação administrativa negada. Criar a conta não comprova que o usuário recebeu ou concluiu a ativação: confira Access separadamente. operador@example.test é apenas ilustrativo e não testa entrega real.

Se o salvamento falhar, preserve a mensagem, corrija o campo indicado e confira o registro mais recente antes de repetir. Se Manage access não estiver disponível, verifique estado, permissões e se a conta é a sua própria identidade. Antes de Delete selected, revise todas as contas selecionadas e a confirmação. Fechar o diálogo não desfaz uma solicitação já aceita.

Consulte também: Roles & permissions, Tenants, Autenticação e MFA.

Proteções de identidade e associação

Estado da identidade, estado da associação e prontidão para acesso são conceitos distintos. Alterar associações exige administração de plataforma; consultar ou editar campos de uma conta não autoriza mudar livremente seus tenants. O administrador não pode delegar capacidades que não possui. Essas ações não permitem desativar ou reduzir os privilégios da própria conta nem excluir o último administrador de plataforma ativo.

Uma identidade Active pode ainda precisar de ativação ou MFA. Antes de informar que o acesso está pronto, confira identidade, associação ativa, papel selecionado e primeiro acesso concluído. Uma sessão administrativa existente não comprova que outra identidade consiga entrar.

Sessão e contexto de inspeção

Se a sessão vencer ou o papel ativo mudar, confirme novamente permissões, tenant e valores atuais antes de salvar. View as user (read only) não concede execução ou alteração de registros; saia da inspeção antes de voltar à administração normal. Não inclua cookies, tokens ou material de ativação em pedidos de suporte.

Objetivo e escopo

Um tenant delimita o workspace associado a usuários, ativos de dados e configurações comerciais. Ele não é uma pasta do Repository nem um papel de acesso. Tenants apresenta o diretório de workspaces e sua capacidade. Consultar e gerenciar tenants são permissões distintas e dependem do escopo do administrador. Criar um tenant e criar um usuário também são operações separadas.

Limites representam capacidade concedida; uso representa consumo observado. Aumentar um limite não cria infraestrutura nem transfere arquivos ou definições. O plano exibido deve ser interpretado com a assinatura e os direitos aplicáveis, pois uma condição comercial pode restringir operações mesmo quando há capacidade técnica.

Campos e unidades

Consultar um workspace

1. Abra Tenants e procure o nome ou identificador apresentado.
2. Filtre Type, Status ou capacidade conforme a investigação.
3. Leia Usage / limits com as unidades: não some postos, trabalhos e armazenamento.
4. Abra View details e confira identidade, relação com o revendedor, plano, estado e limites.
5. Ajuste Columns e Rows; use Previous e Next na paginação. Tabelas largas permanecem em sua área de rolagem.

Criar ou manter um tenant

1. Selecione New tenant ou Edit tenant.
2. Preencha Name e selecione o Type apropriado.
3. Escolha Parent reseller somente quando a relação autorizada se aplicar.
4. Revise Status, Plan, Seats, Monthly jobs e Storage MB conforme a capacidade aprovada. Não interprete um campo vazio como ilimitado.
5. Confira o formulário completo, envie uma vez e aguarde.
6. Atualize ou reabra o tenant e confirme valores persistidos, relação e estado.

Suspend tenant e Reactivate tenant alteram disponibilidade administrativa; não migram objetos. Revise o workspace afetado e as obrigações operacionais antes da ação. Antes de uma exclusão em lote, inspecione identidades vinculadas e as condições apresentadas. Reduzir capacidade sem conhecer o consumo pode impedir operações futuras.

Trial e continuidade do workspace

Interprete Trial com datas e condições da assinatura. Para estender um trial elegível, abra Subscription & billing, selecione o mesmo tenant e use Extend trial. A extensão preserva a identidade; não recrie o workspace para mudar a situação comercial. Na passagem para uma assinatura paga, confira separadamente tenant, assinatura, direitos e prontidão da infraestrutura.

Exemplo e recuperação

Em laboratorio-documentacao, revise as unidades e altere somente uma capacidade autorizada. Reabra o registro e confirme o mesmo identificador, o valor salvo e o estado. Uma revisão de acesso deve demonstrar que um operador delegado consulta apenas os workspaces permitidos. Para praticar extensão de trial, use um ambiente de teste sem renovar uma assinatura real.

Se salvar falhar, preserve a mensagem e revise campos, unidades e escopo. Após um conflito, carregue o estado recente antes de repetir. Data Cleanup, em Preferences, é outra operação: mudar Status não comprova exclusão de dados, e excluir um objeto não garante liberação imediata de toda a quota. Corrija uma configuração pelo fluxo administrativo, sem reconstruir identidades ou alterar arquivos de armazenamento.

Consulte também: Subscription & billing, Preferences, Limpeza e ciclo de vida.

Entender o modelo de acesso

Roles & permissions separa papéis atribuíveis do catálogo de permissões. Uma permissão descreve uma operação autorizada; um papel reúne permissões para uma responsabilidade. Escopo, tenant e papel ativo limitam onde essa responsabilidade se aplica. Uma associação secundária com mais poderes não significa que esse seja o contexto ativo da sessão.

Liste as tarefas antes de criar um papel. Por exemplo, consultar usuários e auditoria não exige administrar infraestrutura. A exibição de um botão não comprova autorização, e abrir a tela não permite editar todos os papéis ou atribuí-los a qualquer identidade.

Consultar papéis e o catálogo

1. Abra Roles & permissions → Roles.
2. Pesquise, filtre e abra View details no papel. Revise chave, rótulo, escopo, descrição e atribuições.
3. Selecione Permissions e consulte a capacidade necessária. Diferencie leitura e gerenciamento.
4. Use Columns e Export CSV quando disponíveis e necessários à revisão autorizada.
5. Confira a atribuição em Users; uma permissão listada no catálogo não está automaticamente concedida à conta atual.

Campos do papel

Criar ou editar um papel de tenant

1. Selecione New role ou Edit role em um papel editável.
2. Preencha Key e Label com uma convenção consistente, por exemplo operador_laboratorio.
3. Confirme Scope e Tenant; escreva uma descrição da responsabilidade.
4. Escolha o menor conjunto de permissões que atende às tarefas documentadas.
5. Envie e reabra o papel para conferir o conjunto persistido.
6. Em Users, atribua-o a uma identidade sintética autorizada e valide uma operação permitida e outra que deva ser negada. Confirme o papel ativo durante o teste.

Uma mudança em um papel atribuído a várias contas é compartilhada. Revise o impacto sobre os usuários antes de salvar e mantenha uma matriz de tarefa, permissão e resultado esperado. Papéis de sistema ou imutáveis podem ser consultados sem ações de edição ou exclusão. Não duplique um papel apenas para contornar uma restrição.

Excluir um papel com revisão das atribuições

Delete role aplica-se somente a um papel editável e elegível. Um papel com atribuições não pode ser excluído por essa ação. Inspecione as identidades afetadas, faça a reatribuição autorizada e atualize a contagem antes de confirmar. Não presuma que a exclusão substituirá automaticamente o papel de cada usuário.

Exemplo e recuperação

O laboratório precisa consultar Users e Audit, sem criar workers. Crie um papel de leitura para essas tarefas e use uma conta que tenha apenas o acesso necessário. Confira as consultas dentro do tenant e a indisponibilidade ou negação de gerenciamento em Cloud workers. Uma conta de plataforma não representa esse teste de menor privilégio, pois seus poderes podem ocultar uma configuração incompleta.

Se o formulário rejeitar a chave, ajuste o formato informado. Se o tenant não aparecer, confira o escopo delegado. Em uma negativa de salvamento, revise a sessão e o papel ativo do administrador. Se a exclusão estiver bloqueada, confira atribuições e imutabilidade. Para recuperar um erro de acesso, utilize uma via administrativa autorizada e registre a correção; não compartilhe credenciais.

Consulte também: Users, Tenants, Audit.

Papéis integrados e acesso efetivo

Confira o catálogo atual e o papel efetivo da sessão; os nomes descrevem responsabilidades e não substituem verificações de permissão, tenant e contrato. Papéis personalizados permanecem vinculados ao seu tenant. A isenção de quota DovaAI do administrador mestre único não se estende a todos os administradores: exige identidade persistida ativa, tenant de plataforma ativo, associação e papel selecionado válidos. A disponibilidade do provedor continua necessária.

Objetivo e pré-requisitos

Subscription & billing separa Subscription, DPU & calculator, Payments & invoicing, Licenses, Commerce, Global catalog e Tenant offers. Selecione o Tenant antes de consultar ou alterar informações. Consulta, operação de cobrança e gerenciamento global do catálogo exigem as permissões correspondentes; o catálogo global requer o papel de plataforma autorizado.

Assinatura, fatura, licença, pagamento e pedido comercial são registros distintos. Atualizar manualmente o estado de uma fatura não confirma liquidação bancária. Emitir uma licença não demonstra que uma instalação a ativou. O retorno do navegador após um checkout também não comprova pagamento confirmado. Valide cada resultado no fluxo responsável.

Escolher a área correta

Revisar assinatura e perfil

1. Abra Subscription & billing e selecione o Tenant correto.
2. Em Subscription, leia o resumo, datas e estado; use Manage quando a atualização for autorizada.
3. Revise Plan e Status antes de Save subscription.
4. Em Edit profile, confira razão social, email de cobrança, identificação fiscal, país e endereço.
5. Salve e recarregue o mesmo tenant para confirmar a persistência. Para um trial elegível, use Extend trial e revise o motivo e o novo término em seu fluxo separado.

Entender DPU e DPU-h

DPU mede capacidade; DPU-h combina capacidade com tempo ativo. No exemplo sintético, 4 DPU × 15/60 h = 1 DPU-h. O consumo é agregado pelas tarefas; o Workflow não cobra novamente o mesmo trabalho. A espera na fila e a validação estrutural não são tempo ativo faturável. Uma estimativa deve declarar capacidade e duração esperadas, sem ser apresentada como uma tarifa fixa ou resultado garantido.

Development e Production mantêm fundos e concorrência separados. Os créditos seguem os períodos financiados verificados, que não precisam coincidir com meses do calendário. A concorrência contratada não cria workers nem substitui os limites físicos e a elegibilidade da execução. Consultas DovaAI aceitas possuem quotas por tenant e usuário, separadas do consumo DPU.

Revisar faturas

1. No inventário de faturas disponível, selecione New invoice quando sua responsabilidade permitir a criação.
2. Preencha Number, Amount, Currency, Due date, Status e Description conforme o formulário. Revise valor e moeda em conjunto.
3. Use Create invoice e reabra o detalhe para confirmar o registro.
4. Quando houver uma alteração de ciclo de vida autorizada, use o diálogo de estado e Update status, representando o processo efetivamente verificado.
5. Confira o registro de pagamento correspondente antes de concluir que houve liquidação.

As moedas oferecidas no editor de faturas não ampliam automaticamente as moedas suportadas pelo catálogo Commerce. Use busca, filtros e Export CSV somente para a revisão necessária. Dados fiscais e de cobrança devem seguir o tratamento aprovado pela organização.

Emitir, ativar ou revogar licenças

Em Licenses → Issue license, revise Reference, Paid invoice, Maximum activations e Expires on. Confirme a fatura e a validade antes de emitir e proteja a chave apresentada. Activate abre o fluxo com License key e Runtime / installation ID; confira a ativação resultante separadamente. Revoke license exige sua confirmação e não significa reembolso financeiro.

Commerce, exemplo e recuperação

Em Commerce, confira Plans available e Order summary. Continue to checkout ou New checkout abre o formulário de pedido. Revise preço, quantidade, forma de pagamento, tipo de cliente, documento fiscal, dados legais e endereço antes do fluxo de pagamento suportado. Use um ambiente de teste autorizado e pare antes de qualquer cobrança real durante os exercícios do manual.

No laboratório, estime 1 DPU-h para quatro DPU durante quinze minutos e compare Development e Production sem transferir fundos reais. Confira tenant, termos, assinatura, fatura e pagamento como resultados separados. Um sandbox de pagamentos ou documentos fiscais não comprova aceitação em produção. Após uma resposta demorada, consulte a atividade recente antes de repetir um pedido, pois uma operação pode já ter sido aceita.

Consulte também: Catálogo e ofertas, Trial e ciclo de vida, Audit.

Revisões habilitadas para DPU

O modelo DPU aplica-se apenas a uma revisão de plano habilitada. Uma assinatura legada mantém seus termos comprados; abrir a calculadora ou publicar uma oferta não a converte. A compra e a ativação verificadas determinam a vigência dos novos termos. Confira as datas do período financiado, mesmo que um rótulo de apresentação mencione mês.

1. Selecione o tenant e abra DPU & calculator.
2. Use Refresh usage e compare valores incluídos, consumidos, disponíveis e reservados de cada ambiente.
3. Revise capacidade, concorrência, moeda e termos da proposta; uma estimativa não altera o contrato ativo.
4. Se publicar uma oferta autorizada, confira seu preço e termos e valide separadamente compra, ativação e consumo observado.

Objetivo e acesso

Audit fornece uma visão de consulta da atividade administrativa disponível para seu workspace e papel. Use os eventos para investigar a ação, o ator, o momento e o registro associado. O histórico administrativo não é o log de execução de um Mapping nem uma cópia dos dados transformados. Para resultados de execução, consulte Monitor e o detalhe correspondente.

Defina primeiro a pergunta: quem alterou o papel de uma conta de laboratório, quando foi registrada uma extensão de trial ou o que ocorreu em uma tentativa de retirada de worker? Confirme conta, tenant e papel antes de pesquisar e mantenha o período e a informação dentro do escopo autorizado.

Localizar e consultar eventos

1. Abra Audit e aguarde o inventário carregar.
2. Use Search audit events para limitar os registros à informação visível relacionada à investigação.
3. Aplique filtros disponíveis, conferindo período e estado quando aplicáveis.
4. Abra View details e leia ação, ator, horário e objeto apresentados.
5. Consulte o módulo do objeto, como Users, Tenants ou Cloud workers, e confirme seu estado atual.
6. Atualize Audit para consultar uma ação recente; registre a observação sem completar campos ausentes por suposição.

Columns altera a apresentação. Clear filters restaura o inventário mais amplo disponível. Rows, Previous e Next controlam a paginação. Em telas menores, use Filters e a área de rolagem da tabela; uma coluna fora da tela não significa que o campo não exista.

Interpretar a sequência registrada

Preparar uma anotação útil

Registre pergunta, escopo, horário apresentado, ação, objeto e resultado observado. Separe o que o evento informa da conclusão obtida em outra tela. Preserve a referência de fuso horário ao comparar sistemas. Uma entrada não demonstra sozinha liquidação bancária, retirada definitiva de uma VM ou sucesso de uma transformação.

Use Export CSV somente quando a investigação exigir uma exportação autorizada. Armazene o arquivo em local aprovado e compartilhe apenas o necessário. Mesmo sem senhas, o resultado pode conter identificadores e informações de contas. Uma captura isolada não substitui o procedimento de preservação de evidência da organização; esta tela não estabelece, por si, retenção indefinida ou garantias forenses adicionais.

Exemplo de laboratório

Altere uma descrição em um papel editável de laboratório pelo fluxo autorizado. Confirme o valor em Roles & permissions, atualize Audit e procure a atividade correspondente, quando registrada e visível ao seu papel. O resultado esperado é que o registro atual e o evento descrevam a mesma ação no mesmo tenant. Não faça outra alteração apenas para tentar produzir um evento visível.

Falhas e recuperação

Se a consulta falhar, preserve a mensagem e um resumo do escopo e horário, verifique conectividade e validade da sessão e tente novamente. Uma negativa de permissão exige revisão autorizada do acesso; trocar de tenant não é uma forma de manter o escopo da investigação. Para uma operação com resultado incerto, volte ao módulo responsável antes de repeti-la.

Consulte também: Users, Roles & permissions, Subscription & billing, Cloud workers.

Objetivo e permissões

Registrations apresenta solicitações de clientes para revisão administrativa. Consultar um pedido e decidir sobre ele são capacidades distintas. Confirme o workspace, o papel ativo e a permissão de decisão antes de agir. Utilize somente solicitações que pertençam ao escopo autorizado.

A aprovação registra uma decisão administrativa. Ela não comprova criação ou preparação de tenant, usuário, licença ou VM. Verifique esses registros nos módulos correspondentes antes de informar que o acesso está pronto. Para prática, use uma solicitação sintética em ambiente de laboratório, sem enviar decisões a clientes reais.

Consultar a solicitação

1. Abra Registrations na navegação lateral.
2. Use Search registrations, filtros de coluna ou Filters em uma tela estreita.
3. Abra View details e confira nome, email, organização, tipo e estado atual.
4. Revise data de recebimento e, quando presentes, data da revisão, responsável e motivo já registrado.
5. Se outro administrador puder ter atuado, use Refresh antes de abrir a decisão.

Columns, Rows, Previous e Next alteram a apresentação e a paginação; não aprovam ou rejeitam registros. Exporte somente o necessário ao processo autorizado. Em nomes e organizações longos, confira a identidade completa no detalhe, em vez de confiar apenas na linha resumida.

Campos de decisão

Aprovar uma solicitação pendente

1. Abra Approve registration na linha elegível.
2. Confira o solicitante no diálogo e informe Reason (optional) se isso ajudar a explicar a revisão.
3. Marque a confirmação e selecione Approve registration uma única vez.
4. Aguarde e confira estado, data, revisor e motivo no inventário atualizado.
5. Continue os processos separados de preparação de tenant e usuário quando aplicáveis.

Rejeitar uma solicitação pendente

1. Abra Reject registration para o pedido correto.
2. Preencha Reason (required) com uma explicação clara do requisito não atendido, sem informações pessoais desnecessárias.
3. Marque a confirmação e selecione Reject registration uma vez.
4. Confira o estado resultante e a explicação persistida. Use Cancel para sair antes de enviar, se a decisão não estiver pronta.

Exemplo, validação e recuperação

Em laboratório, consulte uma solicitação de Pessoa de Demonstração, organização Laboratório de Integração. Verifique que o formulário de rejeição exige motivo e confirmação. Após uma única decisão autorizada, o registro deve apresentar o resultado e as informações de revisão corretas. Um endereço solicitante@example.test é ilustrativo e não testa comunicação real.

Se o registro mudou, feche a revisão antiga, atualize a lista e confira o estado atual. Uma solicitação já decidida deixa de ser elegível para outra decisão ordinária. Após falha de rede, verifique se o resultado foi aceito antes de repetir; fechar o diálogo não cancela uma requisição já recebida. Corrija erros de validação no mesmo contexto. Não recrie o pedido ou altere revisões para contornar um conflito.

Consulte também: Tenants, Users, Audit.

Objetivo e pré-requisitos

Developer Tools reúne o catálogo publicado da Dova CLI, orientações de plataforma e ferramentas de chaves de API. Abrir a tela ou baixar uma distribuição não concede acesso a um tenant e não autoriza comandos administrativos. A versão do pacote CLI pode diferir da versão Dova 22.0.5; confira a versão específica do artefato selecionado.

Escolha o sistema operacional da máquina de destino, que pode ser diferente do computador do navegador. Antes de executar uma ferramenta, identifique o workspace de laboratório, a operação permitida e o escopo necessário. Mantenha credenciais fora de repositórios, capturas, histórico de terminal e documentação compartilhada.

Baixar uma distribuição publicada

1. Abra Developer Tools e aguarde o catálogo de releases.
2. Consulte as plataformas disponíveis e selecione a correspondente à máquina de destino.
3. Confirme que o download principal e Quick start pertencem à mesma distribuição.
4. Leia versão, disponibilidade, checksum e informação de assinatura publicados para aquele artefato.
5. Baixe pelo link apresentado e confira a integridade usando o checksum do arquivo exato.
6. Siga o Quick start incluído na distribuição em um ambiente autorizado.

Configurar acesso autorizado

Use o fluxo de API Keys apenas se o papel e o ciclo de vida da conta permitirem. Antes de criar ou selecionar uma chave, confirme tenant e escopo disponíveis. Se uma credencial for apresentada uma única vez, transfira-a diretamente ao armazenamento seguro aprovado. O material não deve aparecer em exemplos, notas, logs ou capturas.

As chaves preservam o escopo autorizado e não substituem as verificações do servidor. Um acesso revogado ou um vínculo não verificável deve ser tratado pelo ciclo de vida suportado; não altere o armazenamento para recuperar uma chave. Quando a automação deixar de ser necessária, revogue ou retire a credencial pelo fluxo correspondente.

Copie comandos do Quick start da distribuição atual ou da referência CLI vinculada. Não adivinhe subcomandos, flags, nomes de pacote ou URLs. Registre a versão da ferramenta e a finalidade de uma automação, substituindo valores sensíveis por descrições. Um exemplo de configuração não autoriza executar uma mutação em produção.

Exercício de validação

1. Em um catálogo de laboratório, selecione uma entrada Linux e confira se download, metadados e instruções correspondem à mesma plataforma.
2. Selecione uma entrada Windows disponível e repita a comparação, sem instalar arquivos ou criar chaves reais nessa revisão de navegação.
3. Para um teste funcional autorizado, obtenha a distribuição verificada e execute uma única leitura permitida sobre um recurso sintético.
4. Registre separadamente disponibilidade, integridade e resultado de autorização. O sucesso em uma etapa não comprova as outras.

Falhas e recuperação

Se a plataforma não estiver disponível, leia o aviso do catálogo e use uma distribuição suportada, sem inventar o endereço de download. Se o checksum divergir, não execute o arquivo e obtenha o artefato correto pelo processo autorizado. Em erros de autenticação, confira validade da credencial, tenant e escopo. Criar uma chave mais poderosa não deve ser o primeiro passo de diagnóstico.

Consulte também: Instalação de workers, Papéis e permissões, Preferences.

Localizar o escopo correto

Preferences reúne Notifications, Authentication, Limits, Email delivery e Data Cleanup. Cada categoria tem sua própria autoridade e finalidade. Acesso de consulta não autoriza alterar autenticação global, transporte SMTP ou os limites de qualquer tenant. Antes de editar, leia o escopo, o tenant selecionado e as ações disponíveis para o papel ativo.

O menu da conta contém aparência, paleta e mudanças de associação autorizadas. Ajustar o tema claro ou escuro não modifica permissões, contrato ou política de retenção. Em telas menores, use a navegação e a rolagem local dos controles para chegar às opções sem alterar o contexto.

Conta, aparência e navegação

1. Abra o menu da conta na barra superior e confira identidade, associação e papel.
2. Mude para outra associação ou papel permitido somente se esse for o contexto pretendido.
3. Ajuste tema e paleta, confira a seleção e a mensagem de resultado.
4. Use Back to workspace, Downloads, API Keys ou Documentation para o destino relacionado, quando disponível.
5. Pressione Escape para fechar o menu e retornar o foco ao botão. Ao concluir o trabalho, use Sign out.

Consultar e alterar limites

1. Abra Preferences → Limits.
2. Em Configuration scope, diferencie Platform defaults, que fornece padrões herdados, do tenant cujo ajuste você pode administrar.
3. Leia o resumo do escopo e identifique valores herdados e substituições explícitas.
4. Selecione Workers and capacity, Executions and objects, Retention, API and budget ou Security and access.
5. Leia nome, descrição, valor e unidade de cada limite. Slots, memória, execuções e períodos de retenção medem recursos distintos.
6. Altere apenas o valor autorizado dentro da validação exibida. Quando disponível, restaure a herança pelo controle correspondente.
7. Use Save changes após uma alteração efetiva. Reabra o mesmo escopo e confira valor, unidade e herança.

Sem mudanças, o botão de salvar permanece desabilitado. Se você devolver um campo ao valor carregado, pode não restar uma alteração pendente. Ao trocar de escopo, revise Keep editing e Discard changes; navegar não equivale a salvar. Um limite comercial, técnico e de segurança pode atuar simultaneamente, e aumentar uma quota não instala um worker.

Qual categoria usar

Exemplo e recuperação

Em um tenant sintético, altere um único limite permitido e reabra sua política. Confirme o valor e que o padrão de plataforma e outro tenant continuam com seus valores anteriores. Para notificações, pratique separadamente a edição de conteúdo e a política; um preview não testa SMTP.

Se um campo estiver indisponível, verifique escopo e permissão. Se salvar falhar, preserve a mensagem e a edição pendente, atualize a referência quando solicitado e revise antes de repetir. Não use limites para contornar uma suspensão comercial ou de segurança. Se a sessão expirar, autentique-se novamente e complete o desafio exigido antes de continuar.

Consulte também: Notificações e email, Autenticação, Limpeza e ciclo de vida.

Objetivo e autoridade

Preferences → Authentication configura provedores externos de login. Salvar ajustes globais, substituir segredos e testar provedores exige Platform Administrator autorizado. Consultar Preferences não concede essa autoridade. Verifique a permissão informada e o papel ativo antes de alterar um provedor.

SSO estabelece identidade; papéis e associações controlam a autorização; MFA conclui a verificação exigida da conta. Habilitar um provedor não concede administração nem remove MFA. Antes de mudar uma integração, prepare uma via administrativa de recuperação autorizada e uma identidade de laboratório.

Provedores e campos

Authorized callback URL é somente leitura e pode ser copiada. Cadastre exatamente essa URL na aplicação autorizada do provedor, sem adivinhar caminhos ou trocar domínios. Client ID e segredo têm funções diferentes. Nunca publique o segredo, a chave de setup MFA, um desafio real ou códigos de recuperação.

Configurar um provedor externo

1. Abra Preferences → Authentication e selecione o cartão do provedor.
2. Prepare a aplicação aprovada na administração do provedor.
3. Copie Authorized callback URL do Dova e cadastre-a exatamente na integração.
4. Preencha Client ID e os campos específicos, como Tenant ID ou Issuer URL.
5. Use Replace client secret somente quando necessário. Deixar em branco preserva o segredo atual conforme o formulário.
6. Defina a habilitação e use a ação correspondente, como Save Google ou Save Microsoft.
7. Confirme a persistência e use Test discovery ou Test provider, conforme apresentado. O teste usa a configuração salva, não campos ainda editados.
8. Realize um novo login com a identidade autorizada de laboratório e confira usuário, workspace e papel finais.

Um teste de disponibilidade ou discovery não valida sozinho o fluxo completo nem todos os aspectos do segredo. Uma sessão antiga aberta também não comprova o login pela configuração nova. Siga a regra de identidade de cada cartão; não aplique o comportamento de onboarding Google a todos os seis provedores.

Política de autorregistro

Allow self-registration possui uma ação separada, Save registration policy. O autorregistro novo utiliza identidades Google verificadas conforme a política vigente e o fluxo de workspace individual e trial administrado quando aplicável. Não concede papéis de plataforma. Confira o tenant e a identidade resultantes, em vez de presumir um destino pelo texto de ajuda antigo.

Habilitar a opção não converte contas existentes, renova trials ou cancela condições comerciais. Uma negativa por ciclo de vida deve ser investigada em tenant e assinatura, sem atribuir um papel de plataforma como correção.

Concluir MFA

1. Inicie o login pelo método autorizado e siga Verification or recovery code.
2. No primeiro setup, cadastre o QR ou a chave apresentada de forma privada no autenticador correto. Não faça capturas para o manual.
3. Envie o código atual pelo formulário. Se usar um código de recuperação, lembre que ele é de uso único.
4. Guarde os códigos de recuperação em armazenamento seguro aprovado.
5. Escolha Trust this device somente de forma consciente no dispositivo apropriado. Use Use another account se selecionou a identidade errada.
6. Após concluir, confirme o workspace e o papel antes de realizar operações.

Se o fluxo informar mfaRequired, authenticated=false é esperado enquanto o segundo fator está pendente. Não interprete a confirmação da senha ou do provedor como uma sessão plenamente autenticada. Se a verificação vencer, inicie novamente e use o desafio atual; não reutilize desafios de uma aba antiga. Trust this device não desabilita MFA globalmente.

Exemplo e recuperação

Em laboratório, teste uma identidade autorizada, uma identidade não autorizada e um código inválido, sem registrar códigos ou cookies na evidência. Somente o caminho permitido deve chegar ao tenant e papel esperados após MFA. Saia e faça um novo login para verificar a configuração persistida.

Em falhas, separe conexão do provedor, callback ou issuer, correspondência da identidade, MFA e autorização. Se o provedor responder e Dova negar acesso, confira estado da conta, associação e papel. Se não tiver o fator, siga a recuperação autorizada; não altere armazenamento ou política para pular a verificação. Solicite ajuda pelo formulário Cloudata, sem enviar códigos ou segredos.

Consulte também: Users, Roles & permissions, Tenants.

Entender o modelo comercial

Subscription & billing → Global catalog define produtos, planos, versões publicadas e preços compartilhados. Tenant offers aplica condições ao tenant selecionado por referência a essas entidades, sem duplicar o catálogo. Confirme a autoridade de gerenciamento global e o tenant antes de alterar qualquer registro.

Os termos publicados permanecem associados à sua versão. Uma revisão começa como rascunho, e um preço já usado pode exigir New price em vez da edição do valor histórico. Versão comercial, versão de concorrência do registro e versão Dova 22.0.5 representam conceitos diferentes. O manual não estabelece uma tabela de preços fixa: prevalecem o plano e o contrato vigentes.

Entidades e unidades

Criar ou revisar condições do catálogo

1. Abra Global catalog e consulte produtos, planos, versões e preços usando busca, filtros, Columns e View.
2. Quando autorizado, use New product ou New plan e preencha identidade e descrição.
3. Em um plano ou versão elegível, escolha New draft para preparar a revisão.
4. Revise limites e direitos do rascunho. Nos campos JSON, respeite o formato de objeto e os tipos de valor indicados pelo editor.
5. Salve, consulte o rascunho e compare com a revisão anterior. Use Publish ou Publish version somente após a revisão.
6. Use New price para a Published plan version correta.
7. Revise Amount (minor units), Currency, Billing interval, Tax behavior e Tax rate (basis points); confirme o preço salvo.

Não corrija condições publicadas sobrescrevendo contratos históricos. Crie uma nova revisão e um novo preço quando necessário. Retirar disponibilidade pelo fluxo Retire não equivale a apagar o histórico. Antes de publicar, confira o resumo do pedido completo, pois um valor isolado não informa o total final com tributos.

Configurar uma oferta de tenant

1. Selecione o Tenant e abra Tenant offers.
2. Leia o escopo e use Reload offers se outro administrador puder ter alterado registros.
3. Escolha New offer ou edite uma oferta elegível.
4. Selecione Published price e confira a moeda apresentada como somente leitura.
5. Escolha Offer type: desconto em pontos-base ou valor negociado em unidades menores.
6. Defina Valid from (UTC), Valid until (UTC) quando necessário e Status. Confira a janela e a combinação comercial.
7. Salve, recarregue as ofertas do mesmo tenant e valide o preço efetivo na visão comercial aplicável.

Sem oferta elegível, aplicam-se os preços públicos correspondentes. Uma oferta não modifica o preço de outro cliente nem altera retroativamente um pedido anterior. Condições de vigência e sobreposição são validadas pelo fluxo; revise o conflito apresentado em vez de alterar identificadores ou versões manualmente.

Exemplo e recuperação

Em um catálogo de laboratório, publique uma revisão A e um preço fictício em PEN. Crie uma oferta para apenas um tenant e um pedido simulado com esses termos. Prepare uma revisão B e confira que o pedido A preserva as condições originais e que outro tenant continua com o preço aplicável a ele. Use apenas fixtures ou sandbox, sem dados de cartão ou cobrança real.

Se o editor informar mudança concorrente, preserve o que estava sendo proposto, feche, recarregue o catálogo ou as ofertas e revise o registro atual. Se acesso ou tenant mudaram, reabra no escopo autorizado. Uma condição legada incompleta exige revisão comercial, não preenchimento histórico com padrões atuais. Diante de resultado financeiro incerto, confira a operação aceita antes de iniciar outra.

Consulte também: Subscription & billing, Tenants, Audit.

Separar conteúdo, transporte e política

O conteúdo de email, o transporte SMTP e a política de notificações são configurações distintas. Execution email template define assunto e corpos; Email delivery define o transporte de plataforma; Notifications escolhe eventos, canais e condições. Um preview válido não comprova entrega, e uma conexão SMTP aceita não prova que um evento deva gerar uma mensagem.

Confirme tenant, escopo e herança, além da autorização de consulta ou gerenciamento. A administração global de SMTP exige Platform Administrator autorizado. Use dados de execução sintéticos e um destinatário de laboratório sob seu controle, sem enviar testes a clientes reais.

Editar o template de execução

1. Abra Preferences → Notifications → Execution email template.
2. Confira o escopo e a herança antes de alterar um template que possa ser compartilhado.
3. Escolha pelo menos um resultado: succeeded, failed ou cancelled.
4. Preencha assunto e preheader opcional, sem quebras de linha.
5. Edite HTML e texto simples. O texto é obrigatório e deve transmitir o mesmo resultado útil do HTML.
6. Insira variáveis do catálogo do editor na sintaxe com percentuais.
7. Confira preview em largura estreita, títulos, contraste, links e equivalência entre os corpos.
8. Salve, recarregue e confirme a persistência antes de testar o envio.

Campos e variáveis

Esses limites não são metas de tamanho. Prefira mensagens curtas que apontem para o detalhe autorizado, sem logs completos ou informações sensíveis. O preview pode representar imagens remotas de forma restrita; sua ausência não autoriza enfraquecer controles de conteúdo ativo.

Assunto: Resultado %STATUS% de %WORKFLOW_NAME%
Execução: %RUN_ID%
Linhas de saída: %OUTPUT_ROWS%
Detalhe autorizado: %EXECUTION_URL%

Use cada nome entre percentuais, como %WORKFLOW_NAME%. Variáveis desconhecidas são rejeitadas; não invente sintaxe de template ou trate o corpo como código executável. O HTML permitido é restrito e sanitizado.

Configurar o transporte SMTP

1. Abra Preferences → Email delivery com a autoridade de plataforma exigida.
2. Revise SMTP host, Port, Encryption, Username, From name, From email e Reply-to email.
3. Preencha Replace password somente se for substituir a credencial armazenada; em branco preserva o valor atual conforme a indicação do formulário.
4. Defina Test recipient email com uma caixa controlada.
5. Use Save email e o Test SMTP suportado pelo formulário.
6. Use Send test email e confira recebimento, assunto, texto e leitura dos links, além da aceitação inicial do transporte.

Configurar a política

Em Notifications, revise Show action notifications, Position, Duration (seconds) e Maximum visible. Configure Delivery channels, Events and severity, papéis destinatários, limites, deduplicação, escalonamento e digest conforme a necessidade. Webhooks e endpoints de canais são sensíveis e não devem aparecer em exemplos ou capturas.

Nos horários silenciosos, confira fuso e ambos os limites de horário. Preview, Test channels e Save preferences verificam aspectos diferentes. Consulte Delivery history: sent, failed, suppressed e acknowledged não são equivalentes. Uma entrega suprimida pela política não deve ser diagnosticada automaticamente como falha SMTP.

Exemplo e recuperação

Em laboratório, prepare uma execução fictícia com falha e renderize os dois corpos do template. Confira substituição de variáveis e rejeição de uma variável desconhecida. Em um sandbox separado, envie a uma caixa controlada e verifique conteúdo e recebimento. Registre persistência, política e entrega como resultados separados, sem credenciais ou dados reais de execução.

Se o teste falhar, preserve a mensagem segura e investigue uma camada por vez: conteúdo, conexão e autenticação, depois política. Confira seleção de eventos, horário silencioso e deduplicação antes de repetir. Uma alteração de senha sem identificar a causa pode introduzir outra falha.

Consulte também: Preferences, Users, Audit.

Escolher o caminho de instalação

Você pode instalar Dova Worker Agent em um servidor autorizado existente ou provisionar uma VM por Administrator → Cloud workers. O primeiro caminho usa infraestrutura já disponível; o segundo usa uma conexão cloud e um perfil. Nenhum atribui automaticamente todas as Sessions existentes. Confirme tenant, sistema operacional, capacidade aprovada, conectividade de saída e responsável pelo servidor.

Obtenha o pacote atual no catálogo suportado e confira sua integridade. A versão do agente pode diferir da versão Dova 22.0.5. Siga as instruções incluídas no pacote exato e as geradas para seu sistema. Os comandos abaixo representam o fluxo documentado de laboratório; não os execute em um servidor de produção como simples teste de leitura.

Pré-requisitos e instalação em Linux

O fluxo documentado utiliza Python 3.10 ou posterior, ambiente virtual, systemd, util-linux com flock, acesso administrativo e HTTPS de saída para Dova e o registro de pacotes ou mirror autorizado. O instalador verifica requisitos; não presuma que trocará o Python ou o sistema operacional. Confira os requisitos do pacote publicado, pois eles também precisam ser compatíveis com a máquina de destino.

1. Extraia o pacote verificado no servidor de laboratório.
2. No diretório do pacote, execute a verificação de pré-requisitos e resolva os avisos antes de instalar.
3. Complete a instalação conforme o pacote selecionado.
4. Em Dova, abra Register worker, escolha o sistema, nome e concorrência permitida. Gere as instruções e execute o comando no servidor correto.
5. Forneça o token pelo prompt oculto suportado. Nunca o coloque em argumentos de exemplo, histórico de terminal, notas ou capturas.
6. Depois da inscrição bem-sucedida, habilite e consulte o serviço.

# Diretório do pacote verificado; laboratório Linux.
sudo sh execution-worker/install.sh --check
sudo sh execution-worker/install.sh

# Somente após a inscrição concluída.
sudo systemctl enable --now dovaetl-execution-worker
sudo systemctl status dovaetl-execution-worker

Pré-requisitos e instalação em Windows Server

Use Windows Server de 64 bits suportado, PowerShell 5.1 ou posterior e Python 3.10+ de 64 bits instalado para toda a máquina e acessível à conta de serviço. Um alias da Windows Store ou Python instalado somente para o usuário interativo não é adequado. Confira a documentação da distribuição escolhida antes de prosseguir.

1. Extraia o pacote Windows verificado e abra PowerShell elevado em seu diretório.
2. Siga o instalador incluído e identifique o executável Python real da instalação para toda a máquina. Não desabilite globalmente a política de execução.
3. Gere a inscrição para Windows Server e complete o fluxo de prompt oculto.
4. Após inscrição e instalação concluídas, inicie e consulte o serviço.
5. Confirme que a conta de serviço tem os acessos autorizados aos arquivos e conexões necessários à tarefa.

Set-Service -Name DovaWorkerAgent -StartupType Automatic
Start-Service -Name DovaWorkerAgent
Get-Service -Name DovaWorkerAgent

O serviço usa uma conta virtual dedicada. Limites de processos Windows não tornam seguro executar código arbitrário não confiável. Workers Windows permanecem privados no contrato de compartilhamento suportado; não os trate como capacidade pública isolada.

Capacidade pública isolada

A capacidade pública isolada é Linux e exige habilitação explícita e verificação do runtime aprovado. O processo isolado transforma arquivos CSV e Excel sem rede ou identidade cloud ambiental; a aquisição JSON pública limitada é descrita adiante. O ambiente compartilhado não expõe arquivos do host nem checkpoints persistentes. Uma tarefa incompatível falha explicitamente; não é desviada para um processo sem isolamento. Compartilhar capacidade não publica dados ou definições do tenant.

Cloud, concorrência e validação

Prepare Connections e Profiles e use Provision worker conforme Cloud workers. Acompanhe Provisioning history até distinguir criação de VM e inscrição completa do agente. Para GCP privado, confirme a saída de rede requerida; uma VM criada sem acesso aos destinos necessários pode não concluir o agente.

Concorrência representa unidades de slot, e um trabalho pode reservar mais de uma. No exemplo, quatro slots podem atender quatro trabalhos de peso um ou dois de peso dois. O limite configurado não garante admissão se faltarem recursos físicos, capacidades ou elegibilidade. Confira a capacidade disponível exibida em vez de contar somente os trabalhos.

Use uma Session sintética de transformação CSV pequena. Verifique versão instalada, serviço, heartbeat recente, recursos e tenant. Selecione o worker na Session ou política de execução, execute e confira filas, resultado e arquivo autorizado no Monitor. Inscrição não transfere arquivos nem configura credenciais de banco de dados. Se estiver Offline, examine serviço, conectividade e logs seguros; se Online, mas inelegível, revise escopo, política, capacidade e requisitos. Para atualização, siga o mecanismo documentado do pacote e preserve identidade sem copiar configurações sensíveis entre máquinas.

Consulte também: Cloud workers, Migração e retirada, Developer Tools.

Exemplo do instalador Windows

No diretório do pacote verificado, utilize o instalador incluído e substitua o caminho pelo Python real instalado para toda a máquina. A localização abaixo é ilustrativa:

.\execution-worker\install-windows.ps1 -Python 'C:\Program Files\Python312\python.exe'

A conta do serviço é NT SERVICE\DovaWorkerAgent. Configuração, logs e scratch ficam separados dos releases imutáveis. A atualização preserva a identidade e mantém o release anterior para rollback; não inscreva novamente uma instalação já registrada.

Entrada JSON pública e limites do isolamento

O pacote aprovado também permite uma aquisição HTTPS JSON GET pública, sem autenticação ou paginação, seguida de transformações suportadas e saída CSV. O agente confiável valida o destino público e obtém no máximo 8 MiB. O processo isolado recebe um descritor de entrada somente leitura e um de saída limitado; não recebe acesso de rede. A saída CSV tem limite de 15 MiB e não é transportada como Base64 inline. Conectores de rede diretos e checkpoints continuam rejeitados nessa capacidade compartilhada.

Um heartbeat ou teste local isolado não habilita o pool público. A plataforma precisa verificar a instalação e o runtime aprovados no host administrado. Um worker privado inscrito manualmente não é convertido ou certificado automaticamente para compartilhamento público. Essas verificações não representam atestação criptográfica do kernel.

Escopo e pré-requisitos

A migração de um worker altera referências de execução para uma capacidade autorizada e compatível. Ela não transfere automaticamente arquivos, bancos de dados, credenciais ou sistema operacional. Antes de começar, confirme tenant de origem, destino elegível, autoridade de gerenciamento e janela operacional. O assistente mantém verificações de propriedade, atividade e dependências; um estado de VM desconhecido não autoriza a exclusão.

Um Dependency backup preserva metadados de atribuição e integridade, não uma imagem de VM ou uma cópia completa de dados. Ao restaurar ou reatribuir, confira novamente a existência dos objetos e as capacidades atuais do destino. As conexões e os arquivos precisam ser preparados por seu procedimento autorizado separado.

Inventariar e preparar

1. Abra Cloud workers → Workers e consulte o worker de origem.
2. Use Reassign references, Dependency backups ou Restore/reassign to another worker, conforme a finalidade.
3. Confira origem, tenant e referências atuais. Diferencie inventário vazio de inventário incompleto.
4. Revise uso como worker padrão, execuções ativas ou em fila, Sessions, Workflows e dependências de conexões e credenciais.
5. Use Pause scheduling ou Pause scheduling quando o objetivo for impedir novas atribuições e aguardar as atuais.
6. Resolva inventários desconhecidos, bloqueios e erros de observação do provedor antes de tentar retirar.

Gerar preview e aplicar

1. Selecione o Destination worker suportado e as referências pretendidas.
2. Confirme Destination credentials have been configured and verified somente após verificar a configuração real do destino.
3. Use Preview changes e leia alterações, avisos e bloqueios.
4. Se destino, seleção ou configuração relevante mudar, gere outro preview.
5. Aplique o plano permitido com Apply reassignment e confira a quantidade e o resultado das alterações.
6. Atualize origem e destino e consulte o backup de dependências gerado quando aplicável.

A interface gerencia identificadores de preview e tentativas. Não os altere para aceitar um plano antigo. Download metadata copy contém apenas o escopo de metadados indicado, sem ser uma cópia portátil de todos os conteúdos ou segredos. Um conflito exige nova revisão do estado, não modificação manual das referências no armazenamento.

Resolver Sessions e retirar a infraestrutura

O fluxo pode oferecer Replace worker, Distribute Sessions ou Disable affected Sessions. A substituição exige destino compatível com todas as Sessions afetadas; a distribuição exige atribuição completa e sem duplicação. Desabilitar Sessions altera sua execução e pode produzir erro de dependência nos Workflows relacionados. Revise o efeito antes de escolher essa opção.

Abra o diálogo de retirada e atualize o impacto: recursos cloud, referências e atividade. Resolva worker padrão, atividade e política pública. A retirada pública revisa referências entre tenants e versões históricas ainda usadas; versões históricas inacessíveis são preservadas e não bloqueiam por si só. Se o fluxo oferecer Stop and deprovision the VM, leia a ação, preencha Type to confirm e o reconhecimento apenas após satisfazer as condições e envie uma vez.

O registro Dova é retirado após ausência confirmada no provedor e verificação final das referências. Uma falha preserva o registro para diagnóstico e nova tentativa. Clean up Dova record aplica-se à ausência confirmada; Unknown ou Unavailable não significa Absent. Se parar a VM falhar ou novas dependências surgirem, resolva e atualize antes de prosseguir.

Exemplo e recuperação

No laboratório, reatribua uma Session sintética de worker-origem-demo para um destino compatível. Confira referências publicadas, backup e impacto atualizado da origem antes de qualquer retirada. A validação de um conflito deve demonstrar que um preview antigo não é aplicado após mudança de dependência. Use um simulador para falhas de provedor, sem provocar falhas em recursos reais.

Depois de erro de rede, reabra a operação e confira o estado atual antes de repetir. Fechar o diálogo não cancela uma solicitação já aceita pelo provedor. Não anuncie remoção ou economia cloud até confirmar o resultado do provedor e o estado Dova correspondente. Após restauração, revalide compatibilidade e publicação, pois o destino atual pode diferir do momento do backup.

Consulte também: Cloud workers, Instalação de workers, Audit.

Escolher a operação correta

Excluir dados ETL, estender um trial, suspender acesso e cancelar uma assinatura têm finalidades diferentes. Preferences → Data Cleanup remove os registros ETL do tenant selecionado preservando as identidades e os registros indicados. Não exclui uma VM cloud nem cancela automaticamente uma assinatura. Confirme tenant, finalidade, permissões e processo de retenção antes de agir.

Pratique em um workspace sintético isolado. Um tenant individual administrado pode rejeitar a limpeza genérica e exigir seu processo separado de ciclo de vida. Não altere tipo de tenant, gestão da assinatura, revisões ou controles para habilitar uma ação bloqueada. O vencimento comercial não apaga automaticamente os objetos.

Revisar o escopo da limpeza

A lista de categorias explica a operação, mas não comprova que cada categoria contém dados. Uma execução ativa bloqueia a limpeza. Inventário incompleto, conflito ou escopo inelegível também exige resolução antes da confirmação. O formulário não cria automaticamente um backup completo do tenant; mantenha separadamente a cópia autorizada e sua recuperação verificada.

1. Abra Preferences → Data Cleanup e selecione Tenant.
2. Use Refresh inventory e leia contagens, escopo e bloqueios.
3. Obtenha e verifique o backup aprovado para a operação.
4. Abra Clean tenant ETL data e compare tenant e resumo com o inventário revisado.
5. Preencha Type to confirm e o reconhecimento do efeito irreversível.
6. Use Delete ETL data uma vez e aguarde a resposta verificada.
7. Atualize o inventário, confira as categorias afetadas e confirme separadamente os registros preservados.

Se o inventário mudou, atualize e revise novamente. Uma falha ou revisão antiga não autoriza excluir arquivos de armazenamento ou alterar o valor de revisão enviado pelo formulário. Após erro de rede, consulte o estado atual antes de repetir uma ação destrutiva.

Estender um trial elegível

1. Abra Subscription & billing, selecione o mesmo tenant e use Subscription → Extend trial.
2. Leia datas, ciclo de vida e elegibilidade atuais.
3. Escolha 7 days, Custom days ou Exact date and time, conforme o diálogo.
4. Para dias personalizados, respeite a faixa permitida. Para data exata, confira o fuso exibido e o novo término.
5. Preencha Reason, revise o resultado e selecione Extend trial uma vez.
6. Confira o término aceito e a continuidade da identidade do tenant, objetos, assinatura e histórico original.

Para trial em andamento, a extensão em dias parte do término atual; para um trial expirado elegível, parte da aceitação. O diálogo apresenta a zona local e preserva o instante de forma consistente. A extensão não recria o workspace, reinicia quotas ou concede direitos adicionais. Trials pagos, cancelados, suspensos administrativamente ou inconsistentes dependem das regras de elegibilidade e podem não permitir a ação.

Estados comerciais e leitura segura

Um trial expirado ou tenant em atraso pode manter as leituras seguras, exportações e acesso de cobrança previstos, enquanto novas mutações e execuções ficam restritas. Development e Production, direitos e períodos financiados seguem o contrato. Leitura disponível não autoriza recriar objetos, inscrever infraestrutura ou gerar trabalho novo. Reativação comercial não remove uma suspensão administrativa ou de segurança.

Exemplos e recuperação

Use exercícios separados. Para limpeza, gere objetos fictícios em um tenant elegível, revise o inventário e confirme a preservação de usuários após uma limpeza autorizada. Para trial, registre identidade e término antes e depois de uma extensão de laboratório; a identidade e as quotas não devem ser recriadas. Um tenant individual administrado deve seguir seu próprio processo, sem ser convertido apenas para praticar a limpeza.

Depois de falha de rede, confira o estado antes de repetir. Uma nova tentativa idêntica de extensão não deve somar duas vezes. Um conflito exige recarregar e decidir sobre os dados atuais. A passagem para uma assinatura paga preserva o workspace e os objetos; não recrie o tenant como solução para uma dúvida comercial. Use o formulário de suporte Cloudata para uma revisão que exija assistência.

Consulte também: Tenants, Subscription & billing, Retirada de workers.

Alcance e critérios de compatibilidade

Uma Connection reúne endereço, metadados, método de autenticação e custódia das credenciais. Um componente de Mapping seleciona essa conexão e define a operação sobre um recurso. O Worker executa a operação com suas capacidades e permissões efetivas. São três contratos distintos: criar uma conexão não garante que um provedor ofereça todas as formas de leitura, gravação ou recuperação.

Use esta matriz para preparar os dados do formulário Connections. Os identificadores em código ajudam a reconhecer configurações e interpretar erros. Um asterisco indica um campo obrigatório no catálogo do formulário; outros campos podem se tornar obrigatórios pela autenticação, pelo protocolo ou pela validação do provedor. As portas são valores iniciais, não orientações para abrir acesso de rede indiscriminadamente. O endpoint precisa pertencer ao ambiente autorizado da organização.

Matriz do catálogo de conexões

A matriz reúne as entradas declaradas pelo formulário. A oferta efetiva da instalação vem do catálogo disponível e pode ser menor. Ela não afirma que uma identidade vinculada funcione fora de sua nuvem nem que qualquer Worker tenha o driver instalado. PostgreSQL aparece na interface; o registro genérico de conectores não é o único mecanismo de integração com PostgreSQL.

Interpretação dos métodos

O catálogo geral de autenticação também define oracle_wallet, oci_resource_principal, web_identity e instance_profile. Eles não são opções independentes nas entradas desta matriz; sua existência não permite selecioná-los para qualquer conector. Para Amazon S3, aws_iam contempla a identidade já vinculada ao runtime.

Variações que mudam a preparação

Em BigQuery, Database significa Project ID e Schema significa Dataset. Em Oracle, Database aparece como Service name. Databricks exige HTTP path e Catalog. Snowflake solicita Database e Warehouse; Role e Schema completam o contexto. Nome de banco, caminho HTTP e identificador de projeto têm significados diferentes, mesmo sendo textos.

Salesforce parte da API version v65.0; exige a URL My Domain e a configuração correspondente de aplicativo e integração. Dynamics 365 solicita Directory (tenant) ID e deriva o scope do ambiente. Odoo identifica explicitamente sua API JSON-2 da versão 19 ou posterior. SharePoint acrescenta Site ID ou caminho relativo do site. Essas diferenças pertencem ao contrato do conector, não a uma opção genérica de SQL.

A entrada FTP / SFTP permite selecionar o protocolo. SFTP inicia na porta 22; FTP e FTPS, na 21. A chave SSH só fica disponível para SFTP. A opção TLS é ajustada conforme o protocolo: FTP não equivale a uma conexão criptografada. Mantenha a política de transporte exigida pela organização.

Custódia e preparação segura

Dova Worker Agent mantém o segredo no ambiente do cliente. Customer vault armazena uma referência ao segredo em um cofre externo. Passwordless usa uma identidade de execução sem armazenar um segredo reutilizável. Dova Vault é uma modalidade de exceção com entrada criptografada que não volta a mostrar o valor. Managed reference identifica referências gerenciadas existentes.

Os provedores de referências reconhecidos pelo formulário incluem AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, CyberArk Conjur e Kubernetes Secret. Cada um valida seu próprio formato de referência. Uma URI válida não comprova que o Worker consiga resolvê-la: confira identidade, rede e autorização do cofre. Nunca substitua uma referência pelo valor do segredo em nomes, descrições ou arquivos de evidência.

O seletor de autenticação depende da custódia. Passwordless filtra os métodos sem segredo; a modalidade protegida oferece os métodos correspondentes. Se uma combinação não tiver métodos válidos, ajuste a custódia ou o conector conforme o projeto, sem forçar valores ocultos do formulário.

Prova de conceito de conectividade e resultados esperados

Prepare um recurso isolado com dois registros sintéticos e uma identidade limitada à leitura. Crie a conexão no tenant de testes, preencha endpoint e metadados, selecione a custódia e salve. Execute a verificação de conexão pela interface. Registre conector, Worker, horário e resultado, sem material secreto. Depois selecione a Connection no componente de origem correspondente e leia somente o recurso de teste.

O resultado esperado tem dois níveis: a verificação confirma as condições que o conector testa; a leitura confirma o acesso ao objeto e a projeção dos dois registros. Uma conexão aprovada não comprova uma gravação aprovada. Para avaliar um destino, use outro recurso descartável, teste o modo escolhido e compare chaves, quantidade e conteúdo. Esta sequência é uma prática reproduzível, não um resultado de conectividade já obtido no seu ambiente.

Diagnóstico e limites

Em uma rejeição de autenticação, confira método, identidade, validade e permissões. Para um objeto inexistente, confirme catálogo, banco, esquema ou caminho. Em um timeout, revise primeiro o Worker e seu acesso de rede. Se faltar um modo de gravação, consulte as capacidades efetivas do conector: o componente genérico não garante todos os modos de cada provedor. Um timeout não comprova credenciais incorretas; não copie respostas que possam conter dados da origem.

Continue com componentes de Mapping, transformações e permissões por ação.

Do projeto à execução

Um Mapping transforma registros por meio de um grafo de componentes. As fontes produzem registros; as transformações projetam, enriquecem ou validam; os destinos gravam resultados. Uma Session associa o projeto a parâmetros, arquivos e execução. Um Workflow coordena Sessions e decisões. Essa separação permite trocar um arquivo de entrada ou um Worker sem criar outro projeto para cada variação operacional.

Os componentes de arquivo incorporados são diferentes daqueles que exigem um Worker compatível. Database, API e Object storage declaram o runtime compatible_worker; selecionar um nó não instala drivers, concede permissões nem cria uma conexão automaticamente. Consulte conectores e autenticação antes de configurar esses componentes.

Esta referência apresenta as fontes e os destinos do catálogo de Mapping. Os nomes técnicos ajudam a identificar configurações; a interface apresenta os rótulos da primeira coluna. As opções listadas pertencem ao componente genérico. A conexão e o Worker podem oferecer um subconjunto menor.

Catálogo de fontes

Arquivos delimitados e JSON

Flat File input interpreta CSV, TSV e texto delimitado. Configure o delimitador real e informe se há cabeçalho. Header row number é uma posição física contada a partir de um; não confunda um cabeçalho deslocado com linhas de dados que precisam ser preservadas. Se não houver cabeçalho, informe Field names. Header mapping relaciona posições ou cabeçalhos aos campos lógicos e seus tipos. Encoding distingue UTF-8 de UTF-8 with BOM.

JSON input aceita um array JSON ou JSON Lines. Record path localiza o array dentro de um documento; Field mapping projeta caminhos aninhados em campos lógicos. Um JSON válido pode ter uma estrutura incompatível com a coleção esperada. Comece com um documento pequeno, com quantidade conhecida de registros, e confirme que a projeção obtém os campos corretos.

Excel

Excel input oferece detecção automática, XLSX, XLSM e XLS. Read sheets permite selecionar uma planilha, uma lista, um padrão, uma expressão regular ou todas. Inclua planilhas ocultas explicitamente quando necessário. Header row number, Data starts at row, Start column e End column delimitam a região. Skip empty rows controla as linhas vazias; Include sheet name preserva a procedência no campo configurado, inicialmente _sheet_name.

A opção Password protected indica que a senha é fornecida na execução; ela não deve ser armazenada no Mapping. Ler um arquivo XLSM não autoriza a execução de macros. Antes de incluir todas as planilhas, confirme que elas têm a mesma estrutura. Uma planilha de observações ou totais pode gerar registros fora do conjunto esperado.

Fontes remotas

Database input oferece Table or view e SQL query para leitura. Selecione conexão, esquema e objeto, ou configure a consulta. Fetch size e Query timeout controlam aspectos operacionais; não substituem filtros de negócio. Selected fields permite uma projeção explícita. Use consultas de leitura sobre recursos autorizados; a existência do campo SQL não garante compatibilidade universal entre dialetos.

API input declara GET, Resource path, Record path e Field mapping. A paginação pode ser None, Page number, Offset ou Cursor. Page size, Retries e Timeout precisam ser compatíveis com o serviço. Uma primeira página correta não comprova a leitura da coleção inteira: o teste deve ultrapassar deliberadamente o tamanho de uma página.

Object storage input seleciona Connection e Object key. Os formatos declarados são CSV e JSON Lines. Selected fields e CSV delimiter completam a configuração. A chave do objeto não é um caminho local do navegador. Confira o prefixo e o recurso final para evitar a leitura de outro arquivo com nome semelhante.

Catálogo de destinos

Representação e gravação

Flat File output define nome, delimitador, cabeçalho, qualificador de texto, política de aspas, escape, fim de linha, codificação e representação de nulos. Esses parâmetros fazem parte do contrato de troca de dados. Se o consumidor exige CRLF ou BOM, registre isso antes de comparar os arquivos. JSON output distingue array de JSON Lines, oferece formatação legível e permite decidir se os campos nulos serão mantidos.

Database output declara Append, Replace e Upsert; chaves, criação de tabela, lotes, intervalo de commit e timeout completam a configuração. Confirme se o conector efetivamente oferece o modo escolhido. Teste Replace somente em uma tabela descartável. Upsert exige chaves bem definidas; não é um mecanismo genérico para corrigir duplicatas históricas.

API output declara POST, PUT e PATCH, modos Append ou Upsert, chaves e uma confirmação de unicidade imposta pelo provedor. Success status codes parte de 200, 201, 202 e 204. O código 202 pode indicar aceitação assíncrona pelo serviço externo, sem confirmar o processamento final. Avalie os reenvios em conjunto com a semântica de idempotência do destino.

Object storage output usa Conditional replace, exige Idempotency key e oferece Create only when absent, Expected ETag e Expected generation. Essas condições protegem a intenção de gravação em relação às versões do objeto. Não retire uma precondição apenas para transformar um conflito em sucesso: recupere o estado esperado e confirme se a nova gravação continua válida.

O catálogo atual de destinos de Mapping não contém um componente Excel output. Para entregar um arquivo que o Excel consiga abrir, use CSV com codificação, delimitador e fim de linha adequados. Um CSV com BOM continua sendo texto delimitado: não é um arquivo XLSX, não contém planilhas e não preserva fórmulas nem formatação de células.

Prova de conceito do contrato de arquivo

Crie um CSV sintético com o cabeçalho id,name e duas linhas: 1,Ana e 2,Luis. Projete Flat File input → Flat File output, selecione vírgula e cabeçalho nas duas pontas e associe o arquivo de entrada a uma Session. Execute em um ambiente de testes autorizado. A saída esperada mantém dois registros e dois campos; aspas e fim de linha podem variar conforme a configuração de saída.

Repita com um arquivo JSON Lines contendo dois objetos equivalentes. Use JSON input e JSON output, selecione JSON Lines e confira duas linhas de dados. Essa segunda variante separa falhas de transporte de falhas de representação. Os passos descrevem uma verificação reproduzível; registre o resultado real antes de aceitar o contrato.

Para um Mapping simples com um arquivo compatível, também é possível iniciar a execução manual em Mapping → Run e selecionar a entrada solicitada. Uma Session reutiliza bindings e configurações operacionais; ela não é um requisito universal para esse teste manual. Confira a tentativa e o arquivo real em Monitor.

Validação, falhas e recuperação

Primeiro revise a estrutura do grafo, as conexões entre nós e os campos obrigatórios. Depois verifique nomes lógicos, tipos e parâmetros. Se a leitura falhar, mantenha uma amostra sintética equivalente e reduza o problema a uma fonte e um destino. Se a gravação falhar, identifique possíveis efeitos parciais antes de tentar novamente; o erro do Workflow não comprova ausência de alterações no destino.

Use Monitor para correlacionar a execução e suas tarefas, e Sessions para conferir arquivos, perfil e Worker. Uma execução pequena valida estrutura e acesso, sem demonstrar capacidade para qualquer volume. Aumente o conjunto gradualmente e mantenha uma contagem esperada independente.

Objetivo e contrato dos registros

As transformações incorporadas trabalham sobre os registros recebidos de seus componentes anteriores. Uma operação pode alterar campos, valores, quantidade de linhas ou ordem. Antes de conectar um destino, defina quais propriedades precisam ser preservadas. Qualidade não significa apenas um Mapping válido: um grafo correto pode produzir um resultado de negócio incorreto se as chaves ou o tipo de junção não representarem a relação real.

O catálogo a seguir reúne os componentes das categorias Transform e Quality. Os identificadores reconhecem a configuração; os rótulos são os apresentados ao usuário. Os campos descrevem o contrato do componente, não funções de uma linguagem de programação aberta. Para fontes e destinos, consulte componentes de Mapping.

Catálogo completo

Projeção e enriquecimento

Field selector mantém a lista de campos escolhida. Field mapper relaciona nomes de origem e destino; use-o para estabelecer um esquema de saída reconhecido pelo consumidor. Verifique colisões antes de renomear: dois conceitos diferentes não devem acabar representados pelo mesmo nome lógico.

Calculated field cria um campo usando um modelo de texto. ${customer} obtém o valor de uma coluna e ${param.region} obtém um parâmetro. A substituição produz texto; não interpreta fórmulas aritméticas nem executa JavaScript ou SQL. Consulte expressões e variáveis para distinguir esse modelo de uma condição de Workflow.

Convert type oferece String, Integer, Number, Boolean, Date e Date and time. Output field vazio substitui o campo de origem; outro nome preserva o valor inicial. On conversion error permite falhar, definir nulo, manter o original ou usar um valor padrão. Manter originais pode deixar uma coluna heterogênea: valide a saída antes de gravar em uma tabela tipada.

Limpeza de texto

Clean text aplica uma lista ordenada de operações: trim, collapse_whitespace, lower, upper e remove_accents. Por padrão, remove espaços nas extremidades e reduz espaços repetidos. Aplique uma política coerente nos dois lados de uma chave de junção. Não remova acentos de um nome que precisa ser preservado legalmente apenas para facilitar uma comparação; crie um campo normalizado separado quando necessário.

Replace values distingue conteúdo, valor exato, prefixo e sufixo; Case sensitive controla maiúsculas e minúsculas. Split field divide por delimitador e atribui Output fields, com opções para manter a origem e remover espaços das partes. Concatenate fields define separador, campo de saída e tratamento de valores vazios. Esses componentes não são interpretadores de expressões regulares arbitrárias.

Quantidade, ordem e agrupamento

Row filter aceita Equals, Does not equal, Contains, Starts with, Ends with, comparações de maior ou menor com ou sem igualdade e Is not empty. A lista de operadores difere da usada nas decisões de Workflow. Converta números antes de compará-los quando a origem for texto e valide os limites com registros exatamente iguais ao valor de corte.

Limit rows combina Maximum rows e Rows to skip. É útil para uma janela controlada, mas uma amostra não valida toda a população. Row sort ordena por Field e Direction. Group aggregate agrupa por Group fields e calcula Count, Sum ou Average, com Value field e Output field conforme a operação. Medianas, percentis e várias métricas implícitas não fazem parte deste catálogo.

Deduplicate configura Match fields. Trata-se de uma regra de identidade: teste registros iguais na chave e diferentes em outros atributos. Confirme qual registro permanece antes de usar o componente na reconciliação; ele não implica uma política de “última atualização” que não foi modelada explicitamente.

Junções

Join declara Inner, Left, Right e Full, componentes esquerdo e direito, chaves e condições adicionais AND. Key type pode ser automático ou explícito. Strategy oferece Automatic hash, Hash e Sorted merge. Case sensitive, Trim strings e Match nulls alteram a equivalência das chaves. Right collision prefix, inicialmente right_, distingue nomes repetidos.

Verifique unicidade e cardinalidade antes da junção. Duas ocorrências à esquerda e três à direita podem multiplicar registros; isso não indica necessariamente uma falha do mecanismo. Prepare casos sem correspondência, com correspondência única, com duplicatas e com nulos. Um Left join preserva a intenção de manter os registros da esquerda, mas a quantidade exata depende das correspondências de cada chave.

Reestruturação, sequências, impressões digitais e classificação

Unpivot: de colunas para linhas

Unpivot transforma as colunas de fields em registros. Cada registro mantém keepFields, grava o nome da coluna em keyField e o valor em valueField. Se Keep fields estiver vazio, mantém os demais campos de entrada. Campos mantidos e colunas transformadas não podem se sobrepor; os nomes de saída precisam ser diferentes e não podem colidir com nenhum campo de entrada.

Por exemplo, a entrada {"region":"SUR","jan":10,"feb":null} com Value columns jan,feb, Keep fields region, Column name field month e Value field amount produz {"region":"SUR","month":"jan","amount":10} e {"region":"SUR","month":"feb","amount":null}. Drop null values elimina somente o segundo registro: zero, falso e texto vazio são mantidos. Confira o aumento esperado de linhas; a execução em memória deste operador rejeita uma saída com mais de 250000 registros.

Run sequence: numeração de uma execução

Run sequence adiciona um inteiro a cada registro conforme start + index × step, com o primeiro índice igual a zero. Start 100 e Step 10 atribuem 100, 110 e 120 a três linhas. Step não pode ser zero e o cálculo precisa permanecer no intervalo seguro de inteiros de ±9007199254740991. O campo de saída não pode colidir com um existente.

A sequência reinicia em cada execução. Ela não é um identificador global, uma sequência persistida no banco de dados nem uma garantia de unicidade entre tentativas. Se a ordem dá significado ao número, ordene os registros antes e documente o critério de desempate.

Field fingerprint: detectar mudanças em campos escolhidos

Field fingerprint calcula uma impressão digital SHA-256 a partir dos nomes e valores tipados de fields e a grava em outputField, inicialmente fingerprint. O cálculo usa JSON canônico com nomes ordenados e valores que mantêm seus tipos; nulo, texto vazio e a string "1" em comparação com o número 1 são diferentes. Use um campo de saída novo. A impressão digital compara versões dos atributos escolhidos; ela não criptografa nem anonimiza os dados.

Para comparar duas extrações de clientes, escolha os mesmos campos de negócio, normalize o texto antes do cálculo e relacione os registros por uma chave de cliente independente. Exclua horários de extração que mudam em cada execução quando não representam mudanças de negócio. Não use a impressão digital como substituta do controle de acesso nem como prova de autenticidade de um arquivo externo.

Partition rank: posições dentro de grupos

Partition rank classifica o campo numérico field dentro de cada grupo de partitionBy; uma lista vazia classifica toda a entrada. Direction é ascendente ou descendente. Para os valores 100,100,80 em ordem descendente, Dense rank produz 1,1,2; Rank with gaps produz 1,1,3; Row number produz 1,2,3. Os empates de Row number seguem a ordem de entrada.

O componente adiciona as posições preservando a ordem original das linhas; acrescente Row sort para apresentar a saída em ordem de classificação. Ele aceita números finitos e suas representações textuais válidas; rejeita nulos, vazios e booleanos. Exige classificação com armazenamento intermediário e não faz qualquer grafo usar memória constante. Teste partições diferentes, empates e um valor inválido antes de aceitar a saída.

Regras de qualidade

Default value preenche um campo nulo, vazio ou ambos, conforme Apply when. Quality check controla o percentual máximo de nulos. Required fields verifica o preenchimento de uma lista. Type check valida o tipo declarado e pode permitir vazios. Pattern check aplica um padrão. Range check define mínimo, máximo e inclusão dos limites. Allowed values restringe o domínio e permite distinguir maiúsculas de minúsculas.

Os percentuais são limites de aceitação; eles não definem uma saída automática de quarentena. Não apresente uma regra como separação de registros válidos e inválidos se o projeto não fizer isso. Use zero quando nenhuma violação for aceitável e teste o comportamento com uma linha inválida conhecida.

Prova de conceito de limpeza e controle

Prepare um CSV com id,name,amount: dois registros válidos e um terceiro com amount vazio. Conecte Flat File input → Clean text em name → Convert type em amount → Required fields em id e amount → Flat File output. Use trim e upper; configure Set null na conversão e Maximum invalid percent igual a zero na regra de qualidade.

A expectativa é uma falha de qualidade causada pelo terceiro registro; essa execução não deve ser considerada uma carga aceita. Corrija o dado sintético, repita e confira três registros, nomes normalizados e valores numéricos compatíveis com a saída. Se houver um destino remoto, use um recurso descartável e verifique efeitos parciais antes de tentar novamente.

Para ampliar o exercício, prepare outra fonte com duas chaves e uma descrição, adicione Join e confira o resultado esperado manualmente. Registre as quantidades antes e depois, as chaves sem correspondência e as duplicatas. É um teste de aceitação a executar no seu ambiente; ele não comprova a validação prévia de um destino real.

Três mecanismos diferentes

Dova separa os modelos de texto dos campos de Mapping, os parâmetros tipados de execução e as condições JSON de Workflow. Cada mecanismo tem sintaxe e alcance próprios. Um modelo ${field} não é uma condição de decisão; um booleano JSON não é a string "true"; um parâmetro secreto é uma referência protegida, não uma senha para inserir em um arquivo.

Use parâmetros para representar variações de ambiente e tarefa que não alteram a estrutura do processo. Use variáveis de Workflow quando a definição de orquestração as incluir. Use condições para escolher ramificações com base nos valores ou estados disponíveis. A seção Sessions explica onde editar esses valores, e Workflows mostra sua relação com as tarefas.

Definição de parâmetros

Cada definição aceita name, type, description, required, sensitive, overridable, scopes, default, enum, minimum, maximum e maxLength. O contrato aceita até 100 definições com nomes únicos. O nome começa com uma letra, tem até 64 caracteres e pode conter letras, números, sublinhado, ponto e hífen. Os prefixos sys. e dova. são reservados.

Description tem limite de 300 caracteres. Max length aceita valores entre 1 e 32768. Minimum não pode superar Maximum. Enum precisa conter de 1 a 50 candidatos, é normalizado conforme o tipo e não está disponível para JSON ou Secret. Um parâmetro Sensitive precisa usar o tipo Secret: marcar uma string comum não a transforma em um segredo protegido.

As referências Secret reconhecem os esquemas gcp-secret, aws-secretsmanager, azure-keyvault, vault e worker-secret. Essa sintaxe pertence aos parâmetros de orquestração; não deve ser confundida com as formas específicas de Customer vault em Connections. A resolução de uma referência depende da infraestrutura e das autorizações correspondentes.

Camadas e precedência

Uma camada posterior substitui o valor anterior conforme as regras de validação. Scopes limita as camadas aceitas e Overridable participa do controle de substituição. Required exige um valor após a resolução dos padrões e das camadas. O resultado preserva a procedência do valor, permitindo diagnosticar por que o valor esperado pelo autor não foi aplicado.

Por exemplo, defina REGION como String com o padrão NORTE. Uma camada Environment com SUR deve prevalecer sobre esse padrão; uma camada Task permitida com CENTRO deve prevalecer sobre ambas. Não remova restrições de escopo para contornar um erro sem conferir quem tem autoridade sobre essa configuração.

Modelos de Calculated field

O modelo reconhece ${nombre} para campos do registro e ${param.nombre} para parâmetros. A substituição produz texto com limite de 4000 caracteres. Um identificador reconhecido, mas ausente, é substituído por uma string vazia. O nome do campo é procurado como chave do registro; um ponto no nome não garante acesso a um objeto aninhado.

Com uma linha contendo name = Ana e o parâmetro region = SUR, o modelo Cliente ${name} / ${param.region} produz Cliente Ana / SUR. A expressão ${amount} * 2 produz texto com * 2; ela não calcula uma multiplicação. Use os componentes de transformação adequados, sem inserir código esperando avaliação dinâmica.

O resolvedor de valor parametrizado reconhece uma referência completa ${param.nombre}. Isso não significa que todos os campos de todos os conectores aceitem interpolação parcial. Confira o contrato do componente antes de transferir um modelo de um campo para outro.

Condições JSON de Workflow

Uma condição simples contém ref, op e, com exceção de dois operadores, value. As referências aceitas são parameters.nombre, variables.nombre, tasks.identificador.status e tasks.identificador.outputs.nombre. Elas não permitem acesso arbitrário a propriedades do servidor nem código executável.

Se uma referência não existir, as comparações comuns retornam falso. Exists distingue ausência de um valor existente, porém vazio. In e Not in exigem uma lista como valor esperado. Os números precisam continuar sendo números JSON; a comparação não garante conversão automática de texto.

Os grupos all e any combinam de 1 a 20 expressões; not nega uma expressão. São rejeitados níveis superiores a cinco e árvores com mais de 40 nós. O valor de comparação tem limite de 4096 bytes. Esses limites favorecem condições revisáveis; divida decisões complexas em tarefas claras.

{
  "all": [
    {"ref": "parameters.RUN_MODE", "op": "eq", "value": "full"},
    {"ref": "tasks.load.status", "op": "eq", "value": "succeeded"}
  ]
}

A referência load precisa corresponder ao identificador real de uma tarefa. As saídas só podem ser consultadas quando estiverem presentes no contexto. O exemplo não declara uma saída universal de contagens nem presume nomes de campos de um conector.

Decisões e estados

Os tipos de tarefa são Start, Session, Decision, Timer e End. Os vínculos oferecem Success, Failure, Always e Expression. Uma decisão exige ramificações True e False complementares: uma expressão e sua negação direta. A interface constrói a ramificação falsa com not da verdadeira; não escreva duas condições independentes que possam ser verdadeiras ou falsas ao mesmo tempo.

Os estados terminais reconhecidos incluem Succeeded, Failed, Skipped, Cancelled e Terminated. Ready, Queued, Running, Waiting e Retry wait são estados ativos. A preparação de uma tarefa considera seus antecessores terminais e a política de junção. Always não permite ignorar todos os requisitos de orquestração.

Prova de conceito e diagnóstico

Prepare um Workflow sintético com uma Session que processe duas linhas, uma Decision e duas ramificações de finalização. Defina RUN_MODE como String com os valores permitidos full e sample. Use uma condição de igualdade sobre parameters.RUN_MODE, execute primeiro com full e depois com sample, e confira a troca da ramificação ativa, mantendo a complementaridade.

Depois teste um valor fora de Enum e um booleano onde se exige String. O resultado esperado é uma rejeição de validação, não uma conversão silenciosa. Execute em um ambiente autorizado e registre o resultado observado. Se uma ramificação não for ativada, revise tipo JSON, nome técnico, camada efetiva, estado do antecessor e existência da referência antes de alterar a lógica.

Como interpretar uma autorização

A autorização depende do usuário autenticado, do tenant ativo, do perfil ativo, das permissões efetivas e das restrições do recurso. Exibir um módulo é uma decisão de navegação; executar uma ação exige a verificação correspondente. Um usuário com vários perfis atribuídos não deve presumir que pode usar todos os privilégios ao mesmo tempo sem selecionar o contexto adequado.

A assinatura e a elegibilidade dos recursos também participam da decisão. Uma permissão de execução não garante um Worker disponível, capacidade do plano ou acesso a uma conexão. O modo somente leitura por assinatura inativa não se resolve adicionando permissões indiscriminadamente. Esta referência descreve o catálogo de permissões e a relação entre rotas e ações; as verificações adicionais do recurso continuam obrigatórias.

Matriz de Dova

Configuration pode aparecer com qualquer permissão de consulta de Configuration, Runtime ou Scheduler. As abas aplicam regras próprias. Essa alternativa não concede as demais permissões: poder consultar agendamentos não permite alterar políticas de execução.

A consulta de domínios também pode atender aos seletores de Mappings, Sessions, Workflows e Connections com suas respectivas permissões de leitura. Essa consulta auxiliar não autoriza a criação de pastas. Da mesma forma, a consulta de bloqueios de edição aceita permissões de leitura dos tipos de artefato; alterar bloqueios exige permissões de gestão e as verificações do recurso.

Matriz de Administrator

As duas permissões de Registrations são exclusivas da plataforma. Além disso, a gestão do catálogo comercial global e das ofertas de tenant verifica simultaneamente o perfil ativo de plataforma e billing.manage. Um perfil de faturamento de tenant não autoriza alterações nos produtos globais.

Perfis incorporados

Esses são conjuntos incorporados, sem afirmar que toda organização mantém exatamente as mesmas atribuições. Confira perfis personalizados e permissões efetivas em Roles & permissions. A compatibilidade de perfis do navegador não é fonte de autoridade: o servidor obtém e verifica as permissões da sessão.

Public Trial inclui consulta e gestão de Domains, Mappings, Sessions, Workflows e Connections; execução de Workflows; consulta de Monitor; consulta e gestão de Runtime; e consulta de Billing e Overview. A lista não inclui gestão de Scheduler, gestão de Monitor nem término de Workflows. A validade do acesso e o isolamento do tenant continuam sendo condições independentes.

Do nome do módulo à operação

A interface chama de Workflows a orquestração de Sessions. As rotas de orquestração usam permissões etl.workflows.*. Há rotas históricas com workflows no nome que correspondem ao projeto de Mapping e usam etl.mappings.*, exceto a ação específica de execução. Para integrar ou auditar, confira o contrato da ação; deduzir permissões apenas de uma palavra da URL pode produzir uma conclusão incorreta.

Quando uma rota declara permissões alternativas, basta uma delas na verificação inicial. Depois podem existir validações mais específicas de artefato, tenant, assinatura ou estado. A matriz não permite ignorar essas validações nem constitui uma promessa de API pública estável.

Prova de conceito de privilégio mínimo

Em um tenant de laboratório, prepare um Mapping, uma Session e um Workflow com duas linhas sintéticas. Atribua a uma conta um perfil de consulta equivalente a ETL Viewer. Confira se ela consegue abrir os módulos permitidos e consultar o projeto, mas não salvar alterações nem iniciar uma execução. Use a sessão dessa conta, sem reutilizar credenciais administrativas.

Troque para o perfil de operador autorizado e verifique se ele pode executar o Workflow e consultar Monitor, sem ganhar gestão do projeto apenas por essa atribuição. Depois use um perfil de desenvolvimento para editar e validar o projeto; teste separadamente as restrições de término e gestão de Monitor. Registre cada ação, contexto e resultado sem copiar tokens ou dados pessoais.

O resultado esperado é uma separação reproduzível entre consultar, projetar e operar. Execute o teste no ambiente da organização; esta referência não afirma que as atribuições de uma conta específica já foram verificadas. Se uma ação falhar, revise primeiro tenant e perfil ativos, depois permissão efetiva, assinatura e estado do recurso. Não resolva toda rejeição atribuindo o curinga da plataforma.

Relação com navegação e auditoria

Consulte conta para entender a troca de contexto e Repository para distinguir estrutura e artefatos. Após alterações sensíveis, revise a auditoria disponível e confirme que o resultado pertence ao tenant correto. Ocultar um botão melhora a navegação; o controle de acesso efetivo permanece no servidor.

Escopo desta edição

Este manual descreve as capacidades do Dova 22.0.5. Confira a versão informada pelo seu ambiente antes de seguir um procedimento: uma versão da documentação ou um arquivo baixado não comprova qual código está ativo na instalação. Aceitar uma mudança exige verificar também seu resultado, não apenas o número da versão. Use um destino de laboratório separado nas verificações seguintes.

Navegação e canvas

O editor reduz trabalho repetido por meio de uma instantânea limitada de geometria e da coordenação das atualizações visuais. Essa otimização corresponde à apresentação do canvas; não transforma documentos de API, resultados de execução nem dados de tenants em uma cache compartilhada. Ela não altera o significado de salvar, publicar ou executar.

Para conferir, abra um Mapping de laboratório, selecione componentes, mova-os, conecte portas e redimensione os painéis. Revise alinhamento das conexões, seleção, inspector e comportamento maximizado. Desfazer e refazer devem preservar a edição esperada. A rapidez depende do grafo, dispositivo e carga; não há promessa de tempo universal, e memória adicional não substitui processamento de CPU.

DovaAI e projeto assistido

O DovaAI utiliza internamente o tenant autorizado e a visualização atual. O idioma acompanha a conversa, e o histórico continua ao trocar de módulo dentro do contexto permitido. O chat oferece apresentação compacta e controles de janela; as orientações indicam ações concretas com mensagens breves.

O assistente conhece a finalidade e a configuração dos 36 componentes atuais. Por exemplo, para trocar exatamente jorge por Jorge, pode recomendar Replace values com correspondência exata; isso não equivale a colocar a inicial maiúscula em qualquer nome. Field selector mantém somente os campos escolhidos nas linhas e no esquema.

Você pode anexar um arquivo compatível e descrever um objetivo para preparar um Mapping configurado. O contexto de projeto utiliza metadados do esquema, não uma entrada permanente de execução. Revise componentes, conexões, configurações e informações pendentes antes de confirmar a criação. Criar um rascunho não o publica nem executa. Cotas do plano e verificações de autorização continuam válidas.

Preservar controles operacionais

Mapping, Session e Workflow mantêm finalidades diferentes: transformação, contexto de execução e orquestração. Salve e publique suas versões conscientemente; revise dependências antes de atualizar consumidores. Um worker público compartilha capacidade, não acesso a Sessions nem dados de terceiros. Uma publicação bem-sucedida também não comprova a correção da saída.

Lista de aceitação

1. Confirme versão, tenant, função e localização.
2. Teste o canvas com dados sintéticos e confira a edição salva após recarregar.
3. Peça uma recomendação concreta ao DovaAI e revise a proposta antes de aplicá-la.
4. Execute uma tentativa controlada e compare Monitor, esquema e saída esperada.
5. Em caso de falha, preserve evidências autorizadas e consulte o estado antes de repetir ações com efeitos externos.

Referência verificada para 22.0.5

Esta edição usa o Dova 22.0.5 como referência. A inspeção do produto ativo confirma os 36 componentes do catálogo de Mapping e as tarefas Start, Session, Decision, Timer e End. Consulte a referência de transformações para Unpivot, Sequence, Hash fields e Rank, incluindo campos, condições de erro e exemplos. Revise uma proposta do assistente como qualquer rascunho antes de publicar ou executar.

Configuration contém Runtime, Execution profiles, Workflow Scheduler, Runtime health e Git / DevOps. As ações disponíveis dependem das suas permissões e configuração. Nos workers cloud, o estado da VM e o Runtime do agente são verificações distintas: uma VM iniciada não comprova elegibilidade nem execução bem-sucedida.

Siga o laboratório de Session e Workflow para aprender a cadeia completa. Os dados sintéticos contêm quatro registros de entrada e três resultados esperados, com verificações de colunas e valores. A demonstração de normalização também explica a cadeia real CSV com 18 entradas e 10 saídas. Exemplos históricos mantêm sua identificação original; não são novas execuções no seu ambiente.