UiPath Documentation
robot
2023.10
false
Guia do admin do Robô
Importante :
A localização de um conteúdo recém-publicado pode levar de 1 a 2 semanas para ficar disponível.

Interrompendo um Processo

Comandos Soft Stop e Kill para encerrar a execução do processo do robô: como cada comando sinaliza, cancela ou encerra de forma forçada uma automação em execução.

A process can either be stopped through Soft Stop or Kill commands.

Comando Soft Stop​

O comando Soft Stop marca o processo em um estado Should Stop. Esse estado pode ser consultado do fluxo de trabalho ainda em execução usando a atividade Should Stop. O fluxo de trabalho deve tratar explicitamente desse estado e finalizar. O fluxo de trabalho não para automaticamente sem lidar com o estado Should Stop. Consulte REFramework para um cenário que aproveita o Soft Stop.

The Stop command is designed for unattended automations and is available only in Orchestrator. In Orchestrator, the Soft Stop command is named Stop.

Comando Kill​

O comando Kill envia primeiro uma solicitação Cancel ao fluxo de trabalho. A solicitação Cancel do fluxo de trabalho é distinta de Should Stop.Cancel é um sinal do fluxo de trabalho tratado automaticamente pelo fluxo de trabalho. O sinal faz com que as atividades sejam canceladas em cascata, enquanto permite que blocos Finally do fluxo de trabalho executem etapas de limpeza. Se o sinal Cancel não parar o fluxo de trabalho em três segundos, o trabalho será encerrado forçando a parada de quaisquer atividades em execução em qualquer ponto em sua execução.

O comando Kill foi projetado para automações Attended e está disponível no Orchestrator e em clientes da área de trabalho e APIs como Assistant, Studio, RobotJS. Em clientes da área de trabalho, o comando Kill é chamado Stop.

O Cenário de Processo REFramework​

O REFramework aproveita o comando Soft Stop.

Quando um processo é interrompido, o bloco que contém a lógica do erro é ignorado e o bloco final é executado.Isso faz com que os valores para o BusinessError e SystemError permaneçam nulle o status geral do processo é considerado bem-sucedido. O comportamento descrito é pretendido.

Cenário Try-Catch​

Durante um fluxo de trabalho Try-Catch, quando um processo é interrompido, o status da transação pode aparecer como bem-sucedido quando ela não foi concluída.

Cancelando um Processo​

Se a execução estiver no bloco Try ou no Catch, quando o comando Cancelar for recebido pelo Robô, ele pula para o bloco Finally que verifica qualquer erro. Se nenhum erro for encontrado, o bloco Finally entende que a execução foi concluída com sucesso, pois não há eventos de falha (eles estão em branco).

Encerrando um Processo​

Se a execução estiver no bloco Try ou no Catch, quando o comando Encerrar for recebido pelo Robô, ele irá primeiro tentar Cancelar o processo, seguindo para o bloco Finally. Se a lógica dentro do bloco Finalmente não for concluída em no máximo 30 segundos desde o recebimento do comando Cancelar, toda a execução é perdida e o processo como um todo é bem-sucedido nos logs como se nenhum erro fosse registrado no bloco Catch, já que ele foi ignorado.

Evitando Falso Positivos​

  • O ajuste do status do Processo para Successful deve ser feito apenas dentro do bloco Try, após a conclusão da Lógica de Negócios.
  • A definição do status para Failed deve ser feita apenas dentro do bloco Catch, após a conclusão da lógica de tratamento de erros.
  • No bloco Finally, deve haver apenas a lógica de limpeza, pois ela é executada independentemente de a execução ter sucesso ou não.

Assegurar que o erro de lógica seja executado​

Se o bloco que contém a lógica de erro for ignorado, os valores para BusinessError e SystemError permanecem null e o status geral do processo é considerado successful, pois nenhum erro foi registrado.

Esta página foi útil?

Conectar

Precisa de ajuda? Suporte(opens in new window)

Quer aprender? Academia UiPath(opens in new window)

Tem perguntas? Fórum do UiPath(opens in new window)

Fique por dentro das novidades