- Notas de Versão
- Introdução
- UiPath Assistant
- Instalação e atualização
- Tipos de Robô
- Componentes do Robô
- Licenciamento
- Conectar Robôs ao Orchestrator
- Processos e Atividades
- Geração de logs
- Robot JavaScript SDK
- Cenários Específicos
- Reinicialização de componentes dos Robots
- Sessões do Windows
- Login usando o Sistema de Credenciais Thales Luna
- Login usando o Provedor de Armazenamento de Chaves nShield
- Redirecionando Robôs por meio de um Servidor de Proxy
- Executando tarefas em uma Janela RDP Minimizada
- Usando Unidades de Rede Mapeadas
- Interrompendo um Processo
- Desabilitar o Botão Parar
- Pastas de Pacote Personalizados e Caminhos de Rede
- Integração do CrowdStrike
- Virtualização de aplicativos Robot Citrix
- Solução de problemas
- Erros de conexão comuns
- Robô sem resposta sobre RDP
- Logs de Execução Duplicados
- Erros de Robô Frequentemente Encontrados
- Aumento da Duração da Execução do Processo
- Verificação Forçada de Assinatura do Pacote
- Mensagem muito grande para processar
- Erros ao Executar como Administrador
- Pacotes do NuGet não acessíveis após a migração
- Prompt de Controle de Acesso do Usuário e de Automação de Atividades da Interface Gráfica
- .NET necessário durante a instalação
- Montagem não pode ser carregada da rede ou do Azure File Share
- As atividades não podem encontrar o .NET Runtime
Interrompendo um Processo
Um processo pode ser interrompido por meio dos comandos Soft Stop ou Kill.
O comando Soft Stop marca o processo em um estado Should Stop. O estado pode ser consultado de um 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.
O comando Stop foi projetado para automações Unattended e está disponível apenas no Orchestrator. No Orchestrator, o Comando Soft Stop é chamado Stop.
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.
REFramework aproveita o comando Soft Stop
BusinessError
e SystemError
permaneçam null
e 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 apresentar como bem-sucedido, quando na verdade ele não foi concluído.
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 três segundos desde a recepção 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 foi saltado.
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.