Configuration: runtime, perfis, agendamentos e saúde

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.