Design do fluxo de trabalho

Diagramas de layout

A UiPath oferece quatro diagramas para integração de atividades em uma estrutura de trabalho ao desenvolver um arquivo de fluxo de trabalho:

• Fluxograma
• Sequência
• Máquina de Estado
• Gerenciador de Exceção Global

Sequência

As sequências têm uma representação linear simples que flui da parte superior para a inferior e são mais adequadas para cenários simples quando as atividades seguem as outras. Por exemplo, elas são úteis na Automação de Interface Gráfica quando a navegação e a digitação acontecem um clique/pressionamento de tecla por vez. Devido às sequências serem fáceis de montar e entender, elas são o layout preferido para a maioria dos fluxos de trabalho.

Fluxograma

Os fluxogramas oferecem mais flexibilidade para conectar atividades e costumam definir um fluxo de trabalho de forma bidimensional simples. Graças ao seu formato livre e recurso visual, os fluxogramas são mais adequados para mostrar pontos de decisão dentro de um processo. As setas que podem apontar para qualquer lugar lembram a instrução de programação não estruturada GoTo e, portanto, tornam os fluxos de trabalho grandes sujeitos a um entrelaçamento caótico de atividades.

Máquina de Estado

Já a máquina de estado é uma estrutura complexa que pode ser exibida como um fluxograma com setas, chamadas de transições. Ela permite uma representação mais compacta da lógica e nós a consideramos adequada para um diagrama de processos de alto nível dos modelos de processo de negócios transacionais.

Gerenciador de Exceção Global

O Gerenciador de Exceção foi criado para ser usado em projetos pequenos e grandes de automação, para identificar erros de execução e, mais importante, determinar o comportamento do fluxo de trabalho quando um erro desse tipo ocorre. Se um erro de execução for encontrado durante a depuração, o Gerenciador de Exceção Global pode ser definido para intervir e permitir que você verifique o comportamento do fluxo de trabalho, de acordo com as opções definidas anteriormente no Gerenciador de Exceção.

Escolhas

As decisões precisam ser implementadas em um fluxo de trabalho para permitir que o Robô reaja de forma diferente em várias condições no processamento de dados e na interação do aplicativo. Escolher a representação mais adequada de uma condição e suas ramificações posteriores têm um grande impacto na estrutura visual e na legibilidade de um fluxo de trabalho.

Atividade If

A atividade If divide uma sequência verticalmente e é perfeita para ramificações lineares curtas e equilibradas. Os desafios aparecem quando mais condições precisam ser ligadas em um modo If… Else If, especialmente quando as ramificações excedem o tamanho da tela disponível em largura ou altura. Como uma diretriz geral, as instruções nested If devem ser evitadas para manter o fluxo de trabalho simples/linear.

Flow Decision

Os layouts de fluxogramas são bons para exibir lógicas de negócios importantes e as condições relacionadas como instruções nested If ou construções If… Else If. Há situações nas quais um fluxograma pode ser bom mesmo dentro de uma sequência.

Operador If

O operador VB If é muito útil para as condições locais ou computação de dados menores, e algumas vezes ele consegue reduzir um bloco inteiro a uma única atividade.

Atividade Switch

A atividade Switch pode ser usada algumas vezes em convergência com o operador If, para simplificar e compactar uma cascata If… Else If com condições e atividades distintas por ramificação.

Flow Switch

A atividade Flow Switch seleciona o próximo nó, dependendo do valor de uma expressão; Flow Switch pode ser exibida como o equivalente da atividade de procedimento Switch nos fluxogramas. Ela pode corresponder a mais de 12 casos, iniciando mais conexões do mesmo nó Switch.

Dados

Os dados vêm em duas variantes com relação à visibilidade e ao ciclo de vida: os argumentos e as variáveis. Embora o propósito dos argumentos seja passar dados de um fluxo de trabalho para outro, as variáveis são vinculadas a um contêiner dentro de um único arquivo de fluxo de trabalho e só podem ser usadas localmente.

Escopo das variáveis

Diferente dos argumentos, que ficam disponíveis em todo lugar em um arquivo de fluxo de trabalho, as variáveis ficam visíveis apenas dentro do contêiner onde elas foram definidas, chamado escopo.

As variáveis devem ser armazenadas no escopo mais interno para reduzir a desorganização no painel Variáveis e mostrar apenas, no preenchimento automático, o que for relevante em um ponto específico no fluxo de trabalho.

Observação: se existirem duas variáveis com o mesmo nome, embora recomendamos altamente contra isso, aquela definida no escopo mais interno tem prioridade.

Argumentos

Lembre-se de que ao invocar fluxos de trabalho com a opção Isolado (que começa a executar o fluxo de trabalho em um [processo do sistema][1] separado), só os tipos serializáveis podem ser usados como argumentos para passar dados de um processo para outro. Por exemplo, os objetos SecureString, Browser e Terminal Connection não podem atravessar com segurança a borda dos processos.

[1]: https://en.wikipedia.org/wiki/Process_(computing)

Valores padrão

As variáveis e os argumentos de entrada têm a opção de serem inicializados com alguns valores estáticos padrão. Isso é muito útil ao testar os fluxos de trabalho individualmente, sem a necessidade de dados de entrada reais ao chamar fluxos de trabalho ou outras fontes externas.

Convenções de Nomes

Nomes significados devem ser atribuídos aos arquivos, atividades, argumentos e variáveis do fluxo de trabalho, a fim de descrever com precisão seu uso ao longo do projeto.

Os projetos devem ter descrições significativas, pois eles também serão exibidos na interface do usuário do Orchestrator e podem ajudar em ambientes de vários usuários.

Para melhorar a legibilidade, os nomes de variáveis e argumentos também devem seguir uma convenção de nomenclatura:

• Snake-case (espaço substituído por caractere sublinhado e com as primeiras letras das palavras minúsculas): First1_Name2, first_name2,
• Camel-case (palavras sem espaços) em letras maiúsculas ou minúsculas: FirstName, lastName,
• Pascal-case (palavras sem espaço com todas começando com letra maiúscula): First1Name2, First1Name,
• Kebab-case (substituição do espaço entre as palavras por um traço): First-Name, First-Name1.

Os nomes de argumentos devem ter um prefixo indicando o tipo de argumento, como in_DefaultTimeout, in_FileName, out_TextResult, io_RetryNumber.

Os nomes de atividades devem refletir resumidamente a ação tomada, como Clique no botão Salvar. Mantenha a parte do título que descreve a ação (Click, Type Into, Element Exists, etc.).

Exceto para o principal, todos os nomes de fluxos de trabalho devem conter o verbo descrevendo o que o fluxo de trabalho faz, como GetTransactionData, ProcessTransaction, TakeScreenshot.

Comentários e anotações

A atividade Comment e as Anotações devem ser usadas para descrever em mais detalhes uma técnica ou as particularidades de um determinado comportamento de interação ou aplicativo. Lembre-se de que outras pessoas podem, em algum momento, encontrar um projeto robótico e você pode tentar facilitar o entendimento delas do processo.