Organização de projetos

Estruturas de alto nível

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 flexível e de alto nível de um processo repetitivo. Ele inclui um bom conjunto de práticas descritas neste guia e pode ser usado facilmente como um ponto de início sólido para o desenvolvimento de RPA com a 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.

Princípios de design

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.

Observação: se colocados dentro da pasta do projeto, eles são replicados durante o processo de implantação (junto com os fluxos de trabalho dos projetos) em todas as máquinas do robô na pasta 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.

Controle de origem

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.

Configurações de controle

Para evitar integrar as configurações externas (como caminhos de arquivo, URLs, etc.) nos fluxos de trabalho, recomendamos que as mantenha em um arquivo .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).

Credenciais

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.

Tratamento de Erro

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).

Mantenha o ambiente limpo

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).

O nome do projeto também é importante. Ele é como o processo vai ser exibido no Orchestrator; portanto, deve estar alinhado com as regras internas de nomenclatura. Por padrão, o ID do projeto é o nome inicial do projeto, mas você pode modificá-lo a partir do arquivo 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.

Reusabilidade de códigos

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.

Exemplo

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.

Observação: use componentes separados para Get Info e Change Info.

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.

Onde armazenar componentes reutilizáveis

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.

É melhor armazenar e manter separadamente os componentes comuns (reutilizáveis), como navegação de aplicativos, login e inicialização, em unidades compartilhadas da rede. A partir dessa unidade, eles podem ser invocados por Robôs diferentes, de processos diferentes. A maior vantagem dessa abordagem é que qualquer alteração feita no componente mestre será refletida imediatamente em todos os processos que o usam.

Importante: projetos do Windows e multiplataforma não são compatíveis com a invocação de .xaml e arquivos .cs fora do local do projeto.

Como verificar a automação da qualidade

• 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.