Workers executam Sessions e Workflows conforme a política do tenant. Heartbeat, estado de energia da VM e elegibilidade são observações diferentes. Um worker público pode oferecer capacidade compartilhada; atribuir uma Session a ele não publica sua definição, dados ou artefatos para outros usuários ou tenants.
Antes de começar
Prepare um host autorizado e conheça seu proprietário. São necessários capacidade compatível, permissões e acesso de rede aos recursos do processo. Os arquivos de entrada precisam estar disponíveis ao worker; selecioná-lo não os copia automaticamente.
Procedimento
- Abra Workers e identifique o registro pelo identificador, tenant ou pool e heartbeat recente. Não dependa apenas do nome.
- Abra os detalhes e examine versão, recursos, conectores e slots. Compare com os requisitos da Session e o Execution profile.
- Se registrar um host, use o enrollment autorizado e mantenha o token no fluxo protegido. Confirme um heartbeat válido.
- Diferencie reiniciar o serviço worker de ligar uma VM no provedor. Provisionamento e controles do provedor pertencem a Administrator.
- Escolha o padrão ou uma atribuição explícita permitida. Confira se a identidade resolve Connections e acessa o arquivo de entrada.
- Execute uma Session sintética e verifique em Monitor qual worker recebeu a tentativa e seu resultado.
- Antes de retirar ou substituir capacidade, examine trabalhos ativos, referências, políticas padrão e dependências.
Verificar o resultado
O registro está atualizado, é elegível para a tarefa e conclui um teste com saída conhecida. Slots são unidades ponderadas: quatro slots podem aceitar quatro trabalhos de peso um ou dois de peso dois, sujeitos a outros limites. Online não significa capacidade ilimitada.
Erros e recuperação
Sem heartbeat, examine serviço e conectividade permitida. Em caso de inelegibilidade, confira políticas, capacidades, recursos e ciclo de vida. Provider unavailable não prova que a VM esteja ausente. Resolva falhas de remoção pelo procedimento suportado; não apague registros para ocultar o problema.
Exemplo sintético
Atribua s_CustomerNames a lab-worker com um CSV sintético disponível nesse host. Confira o identificador do worker e a versão do Mapping utilizados na tentativa.
Escopo da verificação
Use dados sintéticos e a função autorizada para a tarefa. Compare a confirmação visual com o registro salvo ou a tentativa correspondente. Guarde somente identificadores e mensagens seguros para suporte; não compartilhe segredos, informações pessoais nem dados do tenant. Se o resultado de uma operação for incerto, confira seu estado antes de repeti-la.
Contexto de ambiente
Antes de usar este módulo, confirme Tenant, Domain e Environment no menu do usuário. O ambiente inicial é Development. As capacidades do módulo, Domain e ambiente se aplicam juntas; Production fica somente leitura sem autorização explícita. Mudar o seletor não transfere artefatos nem publica ou executa seus dados. Consulte ambientes e recuperação e promoção entre ambientes.
Pool de workers por ambiente
Em Configuration → Dova Integration Runtime, Environment worker pool identifica o ambiente atual. Allowed workers associa workers existentes; Default worker deve fazer parte dessa seleção. Pool policy começa como Dedicated. Escolha Shared somente para compartilhar capacidade explicitamente e quando todos os pools participantes também declararem Shared. Nomes iguais não compartilham um worker físico.
Save environment pool altera apenas a política do ambiente selecionado, sem iniciar execução nem modificar o default global do tenant. A revisão usa uma impressão da configuração; se outro usuário alterá-la, Refresh pool permite carregar e revisar novamente antes de salvar. Os controles exigem administração da configuração e Runtime por ambiente. Built-in não é oferecido como worker de execução.
Production não utiliza automaticamente o pool de Development. Novos trabalhos exigem um pool explícito, exceto pela opção pública de Development para um Trial elegível descrita abaixo. A execução legacy só mantém o worker anterior quando o servidor verifica cadeia publicada exata, configuração e associação permitida. Test e Stage consomem o bucket Development do plano; Production utiliza o bucket Production. Participar do pool não substitui capacidade, estado online, perfil compatível, cotas ou concorrência.
Trial público: pool Development gerenciado
Para um Trial público elegível sem uma política explícita de Development, o Dova deriva um pool público de Development gerenciado pela plataforma. Seleciona apenas workers públicos compartilhados com referências verificadas, autorizados para o Trial e sem associação a outros pools configurados. Não inclui workers privados, cria workers nem salva alterações no Runtime. O Trial não recebe permissão para salvar pools.
Uma política explícita de Development, mesmo com Allowed workers vazio, tem prioridade. Esse mecanismo não se estende a Test, Stage ou Production. Continuam válidas as verificações de capacidade, perfil, isolamento, cotas e concorrência; o acesso público não garante disponibilidade.
Antes de parar ou retirar capacidade
Pause VM e Stop VM mantêm verificações de trabalhos ativos, worker padrão e capacidade compartilhada; revise referências e impacto antes de utilizá-los. Pause scheduling interrompe novas atribuições e permite concluir o trabalho atual. Para retirar a VM definitivamente, use Remove VM and unlink e revise a confirmação: após verificar ausência cloud, o Dova limpa atribuições e mostra Unassigned sem excluir definições nem versões publicadas. Atribua capacidade compatível explicitamente antes de executar novamente.
As ações exigem a permissão do módulo e Runtime do ambiente correspondente, ou uma permissão global concedida explicitamente. Uma VM compartilhada exige autorização em todos os seus ambientes.
Retirada e atribuição posterior
Abra Remove VM and unlink, revise a identidade do recurso e o impacto nas Sessions, execuções e pools e confirme a exclusão pretendida. Para uma VM própria compatível, desmontar cada referência manualmente ou desligá-la antes não é requisito dessa operação. Retirar capacidade pode interromper execuções ativas; planeje a operação conforme a necessidade.
Após confirmar a ausência no provedor, o Dova retira o worker ativo, limpa referências de Runtime e mostra Unassigned nos bindings de Sessions que o utilizavam. Definições, versões publicadas, configuração e histórico de auditoria são preservados. Se a VM for excluída diretamente no provedor, a conciliação aplica o mesmo tratamento após verificar a ausência. Uma falha na consulta ao provedor não comprova que a VM foi excluída.
Antes de executar novamente, escolha capacidade compatível e autorizada e revise o pool do ambiente. Unassigned não seleciona outro worker silenciosamente. Você pode provisionar uma nova VM e atribuí-la explicitamente. Permissões, propriedade do recurso, servidor base protegido e operações pendentes continuam sendo verificadas; a retirada não ignora essas proteções.