Padrões para conteúdo de qualidade

Todas as listagens no UiPath Marketplace devem atender às seguintes diretrizes gerais:

Diretrizes	Detalhes
Componentes modulares e reutilizáveis	Os aceleradores de solução devem ser projetados tendo a modularidade em mente, oferecendo uma arquitetura inteligente para modelos de processo, modelos de aprendizado de máquina, bibliotecas reutilizáveis e muito mais. Esses componentes modulares devem ser fáceis de integrar e combinar para criar processos personalizados para o caso de uso específico originalmente em mente ou ter a capacidade de transferir vários componentes reutilizáveis entre os processos. Isso deve reduzir os esforços de duplicação e promover a consistência com as diretrizes de desenvolvimento em diferentes processos.
Parâmetros e configurações configuráveis	Os aceleradores de solução devem fornecer parâmetros e configurações configuráveis que possam ser ajustados para corresponder aos requisitos do usuário final e suas necessidades de negócios. As configurações podem incluir, entre outras, variáveis, limiares, tempos limite, pontos de extremidade, modelos de aprendizado de máquina, humanos nos destinatários do loop e outros parâmetros ajustáveis para permitir a personalização e a adaptabilidade. O arquivo de configuração do processo, os Ativos do Orchestrator e os argumentos de processo são alguns dos meios que você pode usar para obter a configurabilidade.
Arquitetura escalável e adaptável	O design de arquitetura deve ser escalável, adaptável, capaz de lidar com diversos requisitos de automação e permitir uma fácil expansão com mais robôs ou mais processos à medida que as necessidades de negócios evoluem ou novos casos de uso surgem. A arquitetura deve permitir a integração com vários sistemas, aplicativos e tecnologia encontrados dentro da indústria do caso de uso. Os usuários devem ser capazes de trocar facilmente vários componentes do Acelerador de Solução ou integrar novos para atender às necessidades de sua organização.
Recursos de integração	Pre-built Integration Service connectors or connections built using Connector Builder should be utilized, when possible, to enable automation using APIs with an out of the box library of connectors while also providing a standard way to set up and manage connections with standardized authentication. A integração perfeita com sistemas e aplicativos externos simplifica a troca de dados e permite que os Aceleradores de Solução funcionem com a infraestrutura de TI existente, minimizando a necessidade de modificações extensivas ou desenvolvimento personalizado. If API automation is not possible, UI automation should be contained within a GUI Integration Layer / Application Layer as described further below. This should utilize Object Repository within an Application Library.
Extensibilidade e personalização	Os Aceleradores de Solução devem ser desenvolvidos para serem extensíveis e personalizáveis, permitindo que os usuários do Acelerador de Solução adaptem o fluxo de trabalho da automação às necessidades específicas de sua organização. Os aceleradores de solução devem ser desenvolvidos com a ideia de que as organizações devem usar o Acelerador de Solução específico como base para o caso de uso, tendo ao mesmo tempo a capacidade de adaptá-los às suas necessidades exclusivas de negócios.

:::note Through these areas, a Solution Accelerator should provide a structured but flexible framework for building an efficient and scalable automation solution. In summary, your Solution Accelerator should promote modularity, adaptability, best practice compliance, and easy integration with systems and applications to facilitate rapid development and deployment of automation. ::: :::note For a listing to be published on UiPath Marketplace, you must include in the listing's Description all details about the UiPath products that are used in the automation or that are compatible with your automation, and the role that they play.

Partners may not include the names of third parties or third parties' apps or other third party products in the text of their listing or product description on UiPath Marketplace without express authorization from the third party. :::

Standards for solution accelerators

1. Layered architecture

O design de um Acelerador de Solução deve implementar uma separação entre a camada de lógica de negócios (camada de implementação) e a camada de aplicativo (camada de interação com a GUI, se necessário). Isso pode ser alcançado diretamente dentro dos vários fluxos de trabalho do processo ou, se a reusabilidade for necessária, usando bibliotecas.

2. Business logic layer (implementation layer)

• Essa camada é responsável por implementar os fluxos de trabalho de automação e lógica de negócios principais do Acelerador de Solução.
• Ele se concentra nas tarefas e processos específicos que o Acelerador de Solução visa automatizar em um determinado domínio ou caso de uso.
• A camada de lógica de negócios define as regras, condições e ações necessárias para alcançar os resultados de automação desejados.
• Pode envolver manipulação de dados, tomada de decisões, integração com sistemas externos e outras tarefas de processamento.
• Essa camada foi projetada para ser modular e personalizável, permitindo que as organizações adaptem o Solution Accelerator aos seus requisitos específicos de negócios.
• Normalmente, ele usa recursos de automação da UiPath, como atividades, fluxos de trabalho e variáveis para orquestrar o fluxo de automação.

3. Application layer

• A camada de aplicativo serve como a interface entre o fluxo de trabalho de automação e o GUI (interface gráfica do usuário) ou API (interface de programação de aplicativo) dos vários aplicativos e/ou sistemas participantes do processo automatizado.
• Essa camada pode lidar com as interações com os elementos da interface do usuário, como botões, campos, menus e caixas de diálogo, dentro dos aplicativos ou sistemas de destino. Essa camada também pode lidar com a implementação da interface de programação de aplicativos dentro dos aplicativos ou sistemas de destino, como a entrada de dados por meio da comunicação de código em vez de usar a interface do usuário do aplicativo.
• Essa camada pode incluir atividades e componentes que habilitam a automação da interface gráfica, como extração de telas, entrada/saída de dados e navegação. Essa camada também pode incluir a lógica do aplicativo para a implementação programática dos mesmos controles.
• A camada do aplicativo foi projetada para ser adaptável ao aplicativo de destino específico — quaisquer atualizações das APIs ou das interfaces do usuário devem ocorrer em um ponto e depois se adaptar a todas as implementações do componente.
• A Camada de interação com a GUI deve fornecer flexibilidade para lidar com variações em elementos de interface gráfica, layouts de tela e caminhos de navegação.
• Dentro da Camada de Interação da API, a saída de qualquer fluxo de trabalho deve ser consistente com o objetivo do fluxo de trabalho. Por exemplo, se seu fluxo de trabalho for chamado "Recuperar todos os usuários", deve-se esperar que uma coleção de objetos Usuário seja retornada e não um JSON, que seria necessário analisar ainda mais para extrair os dados do usuário necessários.
• Mantenha a duração das chamadas de API no mínimo, usando a paginação e aplicando filtros relevantes sempre que forem implementados pela API de destino.

Observação:

A separação entre uma camada de negócios e uma camada de aplicativo garante uma distinção clara entre a lógica de automação e processo versus os detalhes específicos do aplicativo. Isso possibilita uma arquitetura modular e escalável, na qual alterações no GUI ou na API podem ser gerenciadas separadamente da lógica principal de negócios. A manutenção mais fácil, a reusabilidade dentro do Acelerador de Solução ou a transferência para outros processos e a personalização do Acelerador de Solução são possibilitadas por meio dessa separação. O usuário final do Acelerador de Solução pode substituir facilmente a camada de aplicativo para acomodar quaisquer alterações nos aplicativos de destino sem afetar a lógica do processo subjacente. De maneira similar, a lógica de negócios pode ser modificada ou estendida independentemente do aplicativo para atender à evolução das necessidades de negócios.

Standard architecture types

Transactional / queue based processes

Esse é o modelo Dispatcher-Performer padrão. A Estrutura Empresarial Robótica deve ser utilizada para a implementação de um processo direto baseado em transação.

The Robotic Enterprise Framework is a project template based on State Machines. It is created to fit all the best practices regarding logging, exception handling, application initialization, and others, being ready to tackle a complex business scenario. The template contains several pre-made State containers for initializing applications, retrieving input data, processing it and ending the transaction. All these states are connected through multiple transitions which cover almost every need in a standard automation scenario. There are also multiple invoked workflows, each handling particular aspects of the project.

O modelo Dispatcher e Performer é uma solução pré-projetada para separar os dois estágios principais de um processo, colocando uma fila entre eles. Dessa forma, a produção de itens de transação é totalmente independente de seu consumo. Esse assincronismo quebra a dependência de tempo entre o Dispatcher e o Executador.

Nessa abordagem padrão, um Dispatcher é uma automação para carregar dados em uma fila da UiPath. Ele extrai dados de uma ou várias fontes e usa os mesmos para criar itens de fila para os robôs executores processarem. As informações são enviadas para uma ou mais filas, permitindo que o dispatcher use um formato comum para todos os dados armazenados em itens de fila. Esses dados podem ser processados em uma automação posterior, o Executador. O Executor pode processar os dados conforme necessário, pois os itens de fila são processados um de cada vez. Ele usa mecanismos de tratamento de erros e de repetição para cada item processado. Uma grande vantagem do executor é sua escalabilidade (vários executores podem ser usados com uma única fila).

2. Document Understanding processes

Most of the processes working with documents have in common their requirement to also "understand" their content. Hence, a dedicated framework specialized in document understanding has been put in place – the Document Understanding (DU) Process Framework.

This framework is essentially a UiPath Studio Project template based on a typical document processing flowchart. The process provides logging, error handling, retry mechanisms, and all the methods that should be used in a DU workflow. The workflow has an architecture decoupled from other connected automations:

• Não importa de onde provêm os arquivos a serem processados ou o que dispara a execução – isso é responsabilidade de um processo upstream.
• Não importa onde a informação extraída deve ser usada – isso é responsabilidade do processo downstream.
• A arquitetura da estrutura é comum tanto para robôs assistidos quanto não assistidos:
• Lógica de compreensão de documentos (digitalização, classificação, extração de dados)
• Human-in-the-loop logic (validation) using *Action Center
• for unattended robots, or a local *Validation Station
• for attended ones

Como resultado desses mecanismos e arquitetura, a grande maioria das automações usando o Document Understanding normalmente combina um modelo Dispatcher-Performer com uma estrutura do Document Understanding entre:

• The *Dispatcher
• gathers documents to be processed from the upstream application or system.
• The *Document Understanding Process
• extracts the necessary information from each document one at a time with scalability because of the Dispatcher method.
• Finally, the *Performer
• utilizes the extracted data from the document to complete the process.

3. Transactional processes with Action Center

This architecture consists of Dispatcher – Performer - Finalizer processes with human in the loop, or Long-Running Workflow, process somewhere in the middle. The standard template for longrunning workflows is the Orchestration Process Template. Long-Running workflows have best practices that need to be followed to support service orchestration, human intervention, and long-running transactions in unattended environments.

Essa arquitetura é utilizada quando a intervenção humana é necessária para aprovar ou monitorar a automação. Como resultado, quaisquer fluxos após tarefas do Action Center devem responder tanto pela aceitação quanto pela rejeição.

4. Further architectures

Outras decisões arquitetônicas podem existir e ser apropriadas com base nas necessidades de automação:

• Um finalizador sempre pode ser considerado para qualquer limpeza necessária em um processo.
• Um relatório que é executado com pouca frequência ou Ad-hoc pode ser considerado para enviar estatísticas de automação para as partes interessadas necessárias
• Os processos de Extrair, Transformar e Carregar (ETL) podem combinar dados de várias fontes em um grande repositório central.
• Other automation frameworks such as the UiPath Attended Framework can be considered if applicable to the process.

Process best practices

É necessário seguir estas práticas recomendadas ao desenvolver qualquer processo da UiPath para um Acelerador de Solução:

• Follow the out of the box Workflow Analyzer rules. When analyzed with this tool, your project should raise minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
  • Não deve haver atrasos embutidos em código.
  • Nenhuma atividade deve ter nomes padrão.
  • Duas atividades não devem ter o mesmo nome dentro de um fluxo de trabalho.
  • Os argumentos precisam seguir a convenção de nomenclatura in_, out_ e io_.
  • As atividades muito aninhadas não devem existir e devem ser consideradas um forte argumento para dividir o fluxo de trabalho em componentes menores.
• Antes de iniciar o desenvolvimento, analise cuidadosamente os requisitos do processo e crie uma solução que atenda às necessidades específicas. Divida o processo em tarefas menores e identifique dependências para garantir um fluxo de trabalho claro e eficiente.
• Identificar componentes ou fluxos de trabalho reutilizáveis que podem ser facilmente mantidos e reutilizados em outros projetos e separá-los desde o estágio inicial. Essa abordagem modular melhora a reusabilidade, simplifica a depuração e incentiva a escalabilidade.
• Implemente mecanismos robustos de tratamento de erros para lidar com exceções e falhas. Use blocos try-catch e forneça mensagens de erro informativas para ajudar na solução de problemas e aprimorar a estabilidade do processo.
  • Os erros devem ser específicos e exibir uma mensagem de erro relevante. Uma exceção de ponteiro nulo não deve ser lançada se uma string tiver que ser preenchida, mas não for como resultado do valor de retorno de um aplicativo – a exceção deve ser classificada como uma exceção de regra de negócios causada pelo aplicativo.
• Incorpore definições configuráveis ao seu processo, como parâmetros de entrada, para permitir flexibilidade e adaptabilidade. Isso permite que os usuários personalizem facilmente o processo com base em seus requisitos específicos sem modificar o fluxo de trabalho principal.
• Valide as entradas para garantir que atendam aos critérios necessários e trate as exceções de dados inválidos ou inesperados. Implemente técnicas adequadas de manuseio de dados, como limpeza e transformação de dados, para garantir um processamento preciso e confiável.
• Incorpore mecanismos de registro em log para capturar informações relevantes durante a execução do processo. Isso ajuda a solucionar problemas e fornece informações valiosas para a otimização de processos. Use as ferramentas de depuração para identificar e resolver problemas de forma eficiente.
  • Mecanismos de registro em log para geração de relatórios e o UiPath Insights também devem ser considerados.
• Teste minuciosamente o processo para garantir sua funcionalidade e confiabilidade. Usar casos de teste e dados para validar os resultados esperados e lidar com casos extremos. Isso ajuda a identificar e corrigir quaisquer erros ou inconsistências antes da implantação.
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• Revise e aprimore regularmente seus processos com base no feedback, na evolução dos requisitos e nos progressos técnicos. Busque continuamente oportunidades para otimizar o processo, melhorar a eficiência e incorporar novos recursos ou funcionalidades.

Library best practices

É necessário seguir estas práticas recomendadas ao desenvolver qualquer biblioteca da UiPath para um acelerador de soluções:

• Follow the out of the box Workflow Analyzer rules. Your project should be able to be run against Workflow Analyzer and have minimal if not zero warnings. Naming conventions, design best practices, maintainability and readability rules, and usage rules need to be followed. Some key examples of those rules:
  • Não deve haver atrasos embutidos em código.
  • Nenhuma atividade deve ter nomes padrão.
  • Nenhuma atividade deve ter o mesmo nome dentro de um fluxo de trabalho.
  • Os argumentos NÃO devem seguir a convenção de nomenclatura in_, out_ e io_, pois esses argumentos aparecerão como propriedades quando a Biblioteca estiver sendo criada. A regra padrão do analisador de fluxo de trabalho para nomes de argumentos inválidos pode ser ignorada ao criar uma biblioteca.
  • As atividades muito aninhadas não devem existir e devem ser consideradas para dividir o fluxo de trabalho em componentes menores.
• Qualquer interação de interface gráfica deve ocorrer apenas por meio do Repositório de Objetos.
• Divida sua biblioteca em componentes menores e modulares que se concentram em tarefas ou funcionalidades específicas. Isso incentiva a reusabilidade e permite manutenção e atualizações mais fáceis.
• Forneça uma documentação abrangente para sua biblioteca reutilizável, incluindo instruções de uso, descrições de entrada/saída e quaisquer dependências ou pré-requisitos. Uma documentação clara ajuda os usuários a entender como usar a biblioteca com eficiência.
• Error Handling: Implement robust error handling mechanisms within the library to handle exceptions and failures gracefully. Use try-catch blocks and supply informative error messages to aid in troubleshooting.
  • Os erros devem ser capturados dentro dos processos do Acelerador de Solução e não processados dentro da Biblioteca
  • Toda exceção de negócio deve gerar uma exceção de regra de negócios. Todas as exceções de aplicativo devem gerar uma exceção de sistema
• Confirme as entradas e gerencie casos extremos para garantir que a biblioteca funcione corretamente e evite erros inesperados ou resultados indesejados. A validação de entrada adequada aumenta a confiabilidade e a estabilidade da biblioteca.
  • Isso também se aplica a qualquer saída de automação de API.
• Teste minuciosamente o processo para garantir sua funcionalidade e confiabilidade. Usar casos de teste e dados para validar os resultados esperados e lidar com casos extremos. Isso ajuda a identificar e corrigir quaisquer erros ou inconsistências antes da implantação.
  • Consider using UiPath Test Suite and providing test workflows for your automation.
• Revise e atualize regularmente sua biblioteca para incorporar feedback, resolver bugs e aprimorar funcionalidades com base na evolução dos requisitos. A melhoria contínua garante que a biblioteca permaneça relevante e eficaz ao longo do tempo.
• Ao atualizar bibliotecas, crie sua próxima atualização levando em consideração a compatibilidade com versões anteriores.

Exemplo

Alteração ininterrupta: extensão de uma biblioteca com um novo fluxo de trabalho.

Alteração potencialmente interruptiva: ajustar um fluxo de trabalho existente.

Se não tiver certeza, teste a compatibilidade retroativa com uma versão intermediária e, se necessário, mova a atualização para um novo fluxo de trabalho ou biblioteca que possa ser consumido separadamente apenas pelos processos que exigem a atualização. Com o tempo, o fluxo de trabalho antigo pode ser considerado obsoleto.