- Notas de Versão
- Introdução
- Configuração e Instalação
- Projetos de automação
- Sobre a publicação de projetos de automação
- Projetando automações
- Gerenciamento de pacotes de atividades
- Como definir as configurações do projeto de atividades
- Como assinar pacotes
- Governança
- Como importar entidades
- Experiência de Criação Moderna
- Vincular um projeto a uma ideia no Automation Hub
- Usando o Gerenciador de dados
- Dependências
- Tipos de fluxos de trabalho
- Comparação de arquivos
- Melhores Práticas de Automação
- Integração de controle de origem
- Sobre o controle de versões
- Como gerenciar projetos com o TÁS
- Como gerenciar projetos com o SN
- Dif. do fluxo de trabalho
- Depuração
- A ferramenta de diagnóstico
- Analisador de Fluxo de Trabalho
- Sobre o Analisador de Fluxo de Trabalho
- STN MG-001 - Convenção de nomenclatura de variáveis
- STN MG-002 - Convenção de nomenclatura de argumentos
- STN MG-004 - Duplicação de Nome de Exibição
- STN MG-005 - Variável substitui variável
- STN MG-006 - Variável substitui argumento
- STN MG-008 - Comprimento de variável excedido
- STN MG-009 - Variáveis Catablema de prefixo
- STN MG-011 - Argumentos Catablema de prefixo
- STN MG-012 - Valores padrão de argumentos
- STN MG-016 - Comprimento do argumento excedido
- SR-DB-002 - Contagem alta de argumentos
- SR-DB-003 - Esvaziar bloco catechu
- SR-DB-007 - Múltiplas camadas Com fluxograma
- SR-DB-020 - Propriedades de saída indefinidas
- SR-DB-021 - Tempo limite embutido em código
- SR-DB-023 - Fluxo de trabalho vazio
- SR-DB-024 - Verificação da atividade Persistente
- SR-DB-025 - Pré-requisito de serialidade de variáveis
- SR-DB-026 - Uso da atividade Dela
- SR-DB-027 - Melhores práticas de persistência
- SR-DB-028 - Pré-requisito de serialidade de argumentos
- SR-US-005 - Argumentos de atividades embutidos em código
- SR-US-009 - Variáveis não utilizadas
- SR-US-010 - Dependências não utilizadas
- SR-US-014 - Restrições de pacotes
- SR-US-020 - Mensagens de logue mínimas
- SR-US-024 - Não utilizado e postergado
- SR-US-025 - Uso incorreto do valor salvo
- SR-US-026 - Restrições da atividade
- SR-US-027 - Pacotes necessários
- ST-USG-28 — restringir modelos de invocação de arquivos
- ST-USG-032 — rótulos obrigatórios
- ST-USG-034 — URL do Automation Hub
- Variáveis
- Argumentos
- Namespaces Importados
- Automações codificadas
- Introdução
- Registro de serviços personalizados
- Contextos Antes e Depois
- Gerando código
- Geração de caso de teste codificado a partir de casos de teste manuais
- Automação assistida baseada em gatilho
- Gravação
- Elementos de Interface Gráfica
- Fluxo de controle
- Seletores
- Repo. de Objetos
- Extração de Dados
- Automação de imagem e texto
- Automação de tecnologias Citrino
- Automação RDP
- Automação da Salesforce
- Automação SAP
- Automação do Varear Horizonte
- Geração de logs
- A ferramenta ScreenScrapeJavaSupport
- O protocolo Servodrive
- Test Suite — Studio
- Extensões
- Sobre extensões
- Ferramenta SetupExtensions
- UiPathRemoteRuntime.exe não está sendo executado na sessão remota
- O UiPath Remote Runtime bloqueia a sessão do Citrix de ser fechado
- O UiPath Remote Runtime causa vazamento de memória
- Os pacotes UiPath.UIAutomation.Activities e versões do UiPath Remote Runtime são incompatíveis
- A extensão do UiPath necessária não está instalada na máquina remota
- Configurações de resolução de tela
- Políticas de grupo do Chrome
- Não é possível se comunicar com o navegador
- A extensão do Chrome é removida automaticamente
- A extensão pode ter sido corrompida
- Verifique se a extensão para o Chrome está instalada e habilitada
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Habilite o Acesso às URLs do arquivo e o Modo Anônimo
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- Lista de extensões para Chrome
- Extensão do Chrome no Mac
- Políticas de grupo Edge
- Não é possível se comunicar com o navegador
- A extensão Edge é removida automaticamente
- A extensão pode ter sido corrompida
- Check if the Extension for Microsoft Edge is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and InPrivate mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- Lista de extensões para Edge
- Extensão para Safari
- Extensão para o Varear Horizonte
- Plug-in do SAP Solution Manager
- Suplemento do Excel
- Solução de problemas
- Sobre a solução de problemas
- Suporte e limitações do Microsoft Apo-V
- Solução de problemas do Internet Explorer x64
- Problemas do Microsoft Office
- Como identificar elementos de EU em PDF com opções de acessibilidade
- Reparando o suporte da Active Accessibility
- Validation of large Windows-legacy projects takes longer than expected
Organização de projetos
Começar a partir de uma estrutura genérica (e independente do processo) garante que você lide de forma consistente e estruturada com qualquer processo. Uma estrutura ajuda a começar com a exibição de alto nível e depois você se aprofunda nos detalhes específicos de cada processo.
O Modelo de Estrutura Empresarial Robótica propõe uma visão geral flexível de alto nível de um processo repetitivo e inclui um bom conjunto de práticas descritas neste guia e pode ser usado facilmente como um ponto de partida sólido para o desenvolvimento de RPA com o UiPath®. O modelo foi criado em uma estrutura de Máquina de estado.
Como funciona:
- O Robô carrega as configurações do arquivo de configuração e os ativos do Orchestrator, mantendo-os em um dicionário que deve ser compartilhado entre os fluxos de trabalho.
- O Robô pesquisa as credenciais necessárias e faz login em todos os aplicativos.
- Ele repete isso algumas vezes se algum erro for encontrado, até que tenha êxito ou anule.
- O Robô verifica a fila de entrada ou outras fontes de entrada para iniciar uma transação nova.
- Se não tiverem (mais) dados de entrada disponíveis, configure o fluxo de trabalho para aguardar e tentar novamente, ou encerrar o processo.
- As interações da interface gráfica para processar os dados da transação serão executadas.
- Se as transações forem processadas com êxito, o status da transação será atualizado e o Robô continuará com a próxima transação.
- Se algum erro de validação for encontrado, o status da transação será atualizado e o Robô avançará para a próxima transação.
- Se alguma exceção for encontrada, o Robô tentará processar novamente a transação algumas vezes (se configurado), ou marcará o item como uma falha e reiniciará.
-
No final, um e-mail será enviado com o status do processo, se configurado.
Para processos baseados em transações (como o processamento de todas as faturas de um arquivo do Excel) que não são executados por meio do Orchestrator, as filas locais podem ser criadas usando métodos .NET de enfileirar/desenfileirar.
Em seguida, o fluxo do processo de alto nível (processamento de exceções, nova avaliação, recuperação) pode ser replicado facilmente, com mais facilidade do que agrupar o processo em um loop For Each Row.
Todos os arquivos do REFrameWork, juntamente com sua documentação, podem ser encontrados nesta página.
Dividir projetos em fluxos de trabalho menores e usar atividades Invoke Workflow File é fundamental para o bom design de projeto. Os fluxos de trabalho dedicados permitem testes independentes de componentes, incentivam a colaboração em equipe e aprimoram o desempenho de design e execução, em comparação com projetos organizados em menos arquivos, porém maiores. Recomendamos manter os tamanhos dos arquivos de fluxo de trabalho com menos 5 MB. Os arquivos de fluxo de trabalho acima de 10 MB não são suportados.
Escolha o tipo de layout com cuidado (fluxogramas e sequências). Normalmente, a lógica do processo fica nos fluxogramas, já a navegação e o processamento de dados fica nas sequências.
Ao desenvolver uma lógica complexa dentro de uma sequência, você terá um labirinto de contêineres e blocos de decisões, muito difícil para seguir e atualizar.
Ao contrário, as interações da interface gráfica em um fluxograma o tornam mais difícil de criar e manter.
Os arquivos relacionados ao projeto (como modelos de e-mail) podem ser organizados em pastas locais ou em unidades compartilhadas.
lib/net45
.
Essas pastas também podem ser armazenadas em uma unidade compartilhada, para que todos os Robôs se conectem à mesma origem exclusiva. Dessa maneira, os arquivos relacionados ao processo podem ser verificados e mantidos completamente pelos usuários corporativos, sem a ajuda da equipe de RPA. No entanto, a decisão (pastas compartilhadas ou locais) é complexa e deve considerar vários aspectos relacionados ao processo e ao ambiente: o tamanho dos arquivos, a frequência das alterações, a edição simultânea do mesmo arquivo, as políticas de segurança, etc.
Para melhor gerenciar o controle de versões e compartilhar o trabalho com mais desenvolvedores, recomendamos usar um Sistema de Controle de Versões. O UiPath Studio está integrado diretamente ao GIT, TFS e SVN. Você pode encontrar um tutorial que explica as etapas da conexão e os recursos aqui.
.config
(.xlsx
, .xml
ou .json
) ou no Orchestrator, como ativos, se elas forem alteradas com frequência.
De forma geral, a solução final deve ser extensiva para permitir a variação e alterações nos dados de entrada sem a intervenção de um desenvolvedor. Por exemplo, as listas com os clientes que têm alguns tipos de transação permitidas, e-mails de pessoas a receber as notificações, etc. devem ser armazenados em arquivos externos (como arquivos do Excel) em que as pessoas da empresa ou de outros departamentos podem alterá-los diretamente (adicionar/remover/atualizar).
Para qualquer processo repetitivo, todas as invocações de fluxo de trabalho do loop principal devem ser marcadas com a opção Isolado para se defender contra falhas do Robô (como falta de memória).
Nenhuma credencial deve ser armazenada no fluxo de trabalho diretamente, em vez disso elas devem ser carregadas em lugares mais seguros, como o armazenamento local de credenciais do Windows ou os ativos do Orchestrator. Você pode usá-las nos fluxos de trabalho por meio da atividade GetCredential.
Dois tipos de exceção podem acontecer ao executar um processo automatizado: provavelmente previsíveis ou totalmente inesperadas. Com base nessa distinção existem duas maneiras de lidar com exceções, com ações explícitas executadas automaticamente dentro do fluxo de trabalho ou levando o problema aos operadores humanos.
Em situações em que exceções podem ser encontradas, é útil adicionar um Gerenciador de Exceção Global ao projeto de automação. Apenas um tipo de fluxo de trabalho pode ser adicionado por projeto de automação e o Gerenciador de Exceção Global não fica disponível para bibliotecas.
O fluxo de trabalho pode ser definido para determinar o comportamento do fluxo de trabalho quando uma exceção for encontrada, fazendo com que a execução ignore o erro e continue a partir da próxima atividade, repita a atividade que gerou o erro, anule a execução ou continue e gere o erro novamente.
Além disso, os argumentos contidos no Gerenciador de Exceção Global podem ser definidos para registrar em log o nome da atividade que gerou a exceção ou repetir a atividade algumas vezes. Para obter mais informações sobre como usar seus argumentos, consulte a página do Gerenciador de Exceção Global.
Como uma alternativa ao Gerenciador de Exceção Global, a propagação de exceções pode ser controlada colocando códigos suscetíveis dentro de blocos Try/Catch, nos quais as situações podem ser resolvidas adequadamente. No nível mais alto, o diagrama de processo principal deve definir medidas corretivas amplas para resolver todas as exceções genéricas e garantir a integridade do sistema.
Os gerenciadores de contexto oferecem mais flexibilidade para que os Robôs se adaptem a várias situações e eles devem ser usados para implementar técnicas alternadas, limpeza ou personalização de mensagens de usuário/log. Use o mecanismo de propagação vertical de exceções para evitar gerenciadores duplicados nas seções de captura, avançando alguns níveis do gerenciador, no qual ele possa abranger todas as exceções em um único lugar.
É preciso fornecer detalhes suficientes na mensagem da exceção para que um humano a compreenda e tome as ações necessárias. As mensagens e origens das exceções são essenciais. A propriedade da origem do objeto de exceção indica o nome da atividade que falhou (dentro de um fluxo de trabalho invocado). Novamente, a nomenclatura é muito importante, uma má nomenclatura não dá indicações claras sobre o componente que falhou.
Como você pode ver abaixo, escolher não renomear a atividade Invoke torna a origem da exceção sem sentido no caso de uma falha (como Invoke Workflow File > Invoke Workflow File > Invoke Workflow File > Type Into).
No fluxo do processo, certifique-se de fechar os aplicativos de destino (navegadores, aplicativos) após os Robôs interagirem com eles. Se ficarem abertos, eles vão usar os recursos da máquina e podem interferir com as outras etapas da automação.
Antes de publicar o projeto, verifique novamente os fluxos de trabalho e remova o que não for necessário:
- Remova as variáveis que não são referenciadas.
- Exclua as saídas Write Line temporárias.
- Exclua códigos desabilitados.
- Certifique-se de que a nomenclatura seja significativa e exclusiva.
- Remova os contêineres desnecessários (Clique com o botão direito do mouse em Remover Sequência).
project.json
.
A descrição do projeto também é importante (ela fica visível no Orchestrator). Ela pode ajudar a diferenciar mais facilmente os processos; portanto, também escolha uma descrição significativa.
Durante o desenvolvimento, muitas vezes precisamos automatizar as mesmas etapas em mais de um fluxo de trabalho/projeto, logo, deve ser uma prática comum criar fluxos de trabalho que contêm pequenas partes da automação e adicioná-los à Biblioteca.
Não há uma receita universal indicando como dividir um processo.
No entanto, a separação da lógica de negócios dos componentes de automação é um bom princípio que ajuda a criar um código que pode ser reutilizado de forma eficaz.
Vamos supor que uma parte do seu processo requer a leitura das informações do cliente, e com base nessas informações e nas regras internas de negócios, atualize os detalhes do cliente.
Obter informações do cliente e Alterar informações do cliente devem ser dois componentes de automação distintos, completamente independentes de processos. A lógica (atualizar o tipo do cliente apenas quando o valor total for maior que 100 mil nos últimos 12 meses) deve ser mantida separada da automação. Ambos os componentes podem ser usados mais tarde, separadamente, no mesmo projeto ou em um projeto diferente, com uma lógica diferente. Se necessário, os dados específicos podem ser enviados para esses componentes por meio de argumentos.
Alterar informações do cliente não deve ser invocado a partir de Obter informações do cliente, pois isso torna mais difícil testar, lidar com exceções e reutilizar.
Quando a separação entre ações não for tão óbvia, copiar e colar o código existente de um fluxo de trabalho para outro (ou de um projeto para outro) também é uma boa indicação de que você deve criar um componente separado (fluxo de trabalho) para o código e invocá-lo quando necessário.
Arrastar e soltar o código existente da Biblioteca para um fluxo de trabalho é mais fácil do que criar o código novamente do zero, todas as vezes. Lidar com dados (classificar, filtrar) ou com texto (separar, padrões do Regex) são exemplos do que pode ser adicionado à biblioteca de exemplo. Considere que quando o código for adicionado ao fluxo de trabalho, ele se tornará estático, portanto, ao atualizar o fluxo de trabalho na Biblioteca, isso não será refletido nos processos ao vivo existentes.
-
Modularidade:
- A separação de preocupações com os fluxos de trabalho dedicados permite o desenvolvimento e testes detalhados;
- Extraia e compartilhe os componentes ou fluxos de trabalho reutilizáveis entre projetos.
-
Manutenção:
- Boa estrutura e padrões de desenvolvimento.
-
Legibilidade:
- Estrutura de processos padronizada, incentivando práticas claras de desenvolvimento;
- Nomes significativos para arquivos, atividades, argumentos e variáveis do fluxo de trabalho.
-
Flexibilidade:
- Mantenha as configurações de ambiente em arquivos de configuração externos ou em instâncias do Orchestrator, facilitando a execução da automação em ambientes de teste e produção.
-
Confiabilidade:
- Gerenciamento de exceções e relatórios de erros;
- Atualização do progresso de execução em tempo real.
-
Extensível:
- Pronto para que novos casos de uso sejam incorporados.