- Notas de Versão
- Introdução
- Configuração e Instalação
- Projetos de automação
- Dependências
- Tipos de fluxos de trabalho
- Comparação de arquivos
- Melhores Práticas de Automação
- Integração de controle de origem
- 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-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
- Variáveis
- Argumentos
- Namespaces Importados
- 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
- 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
- Solução de problemas de aplicativos do JxBrowser
- Monitoração de eventos de usuário
- Solução de problemas da Citrix
- Automação de aplicativos em execução com um usuário diferente do Windows
Design do fluxo de trabalho
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 separado, apenas os tipos serializáveis poderão 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.
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.
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.
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.
