Padrões para o 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	Os conectores do Integration Service pré-construídos ou as conexões construídas com o Construtor de Conector devem ser utilizados, quando possível, para habilitar a automação usando APIs com uma biblioteca de conectores prontos para uso, além de fornecer uma maneira padrão de configurar e gerenciar conexões com a autenticação padronizada. 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. Se a automação da API não for possível, a automação da interface gráfica deve ficar contida em uma Camada de Integração de GUI/Camada de Aplicativo, conforme descrito mais abaixo. Isso deve usar o Repositório de Objetos em uma Biblioteca de Aplicativos.
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.

Observação:

Por meio dessas áreas, um Acelerador de Solução deve fornecer uma estrutura estruturada, porém flexível, para a criação de uma solução de automação eficiente e escalável. Em resumo, seu Solution Accelerator deve promover modularidade, adaptabilidade, conformidade com as melhores práticas e fácil integração com sistemas e aplicativos para facilitar o rápido desenvolvimento e implantação da automação.

Atenção:

Para que uma listagem seja publicada no UiPath Marketplace, você deve incluir na Descrição da listagem todos os detalhes sobre os produtos da UiPath que são usados na automação ou que são compatíveis com sua automação, bem como a função que eles desempenham.

Os Parceiros não podem incluir os nomes de terceiros, aplicativos ou outros produtos de terceiros no texto da listagem ou na descrição do produto no UiPath Marketplace sem autorização expressa do terceiro.

Padrões para aceleradores de solução

1. Arquitetura em camadas

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. Camada de lógica de negócios (Camada de implementação)

• 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. Camada de aplicativo

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

Tipos de arquitetura padrão

Processos transacionais / baseados em filas

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.

A Estrutura Empresarial Robótica é um modelo de projeto baseado em máquinas de estado. Ele foi criado para atender às práticas recomendadas de registro em log, gerenciamento de exceções, inicialização de aplicativos e entre outras, pronto para lidar com um cenário de negócios complexo. O modelo contém vários contêineres de estado pré-criados para inicializar aplicativos, recuperar dados de entrada, processá-los e encerrar a transação. Todos esses estados estão conectados por meio de várias transições que abrangem quase todas as necessidades de um cenário de automação padrão. Há também vários fluxos de trabalho invocados, cada um processando aspectos específicos do projeto.

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. Processos do Document Understanding

A maioria dos processos que trabalham com documentos têm em comum sua exigência de também "entender" seu conteúdo. Por isso, uma estrutura dedicada especializada na compreensão de documentos foi implementada - a Estrutura de processo do Document Understanding (DU).

Esse framework é basicamente um modelo de Projeto do UiPath Studio baseado em um fluxograma típico de processamento de documentos. O processo fornece log, tratamento de erros, mecanismos de repetição e todos os métodos que devem ser usados em um fluxo de trabalho DU. O fluxo de trabalho tem uma arquitetura dissociada de outras automações conectadas:

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

• Lógica com participação de seres humanos (validação) usando o Action Center para robôs não assistidos, ou um Validation Station local para robôs assistidos

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:

• O Dispatcher reúne os documentos a serem processados a partir do aplicativo upstream ou sistema.

• O Document Understanding Process extrai as informações necessárias de cada documento, um de cada vez, com escalabilidade devido ao método Dispatcher.

• Por fim, o Executador utiliza os dados extraídos do documento para concluir o processo.

3. Processos transacionais com o Action Center

Essa arquitetura consiste em processos Dispatcher - Executor - Finalizador com humanos no loop, ou fluxo de trabalho de longa duração, processo em algum lugar no meio. O modelo padrão para fluxos de trabalho de longa duração é o Modelo de processo do Orchestration. Os fluxos de trabalho de longa duração têm práticas recomendadas que precisam ser seguidas para dar suporte à orquestração de serviços, intervenção humana e transações de longa duração em ambientes não assistidos.

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. Outras arquiteturas

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.

• Outras estruturas de automação, como o UiPath Attended Framework, podem ser consideradas se forem aplicáveis ao processo.

Melhores práticas de processo

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

• Siga as regras prontas para uso do Analisador de Fluxo de Trabalho . Quando analisado com esta ferramenta, seu projeto deve gerar um mínimo, se não nenhum, alertas. Convenções de nomenclatura, práticas recomendadas de projeto, regras de capacidade de manutenção e legibilidade e regras de uso precisam ser seguidas. Alguns exemplos importantes dessas regras:

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

  • Considere usar o UiPath Test Suite e fornecer fluxos de trabalho de teste para sua automação.

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

Melhores práticas para bibliotecas

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

• Siga as regras prontas para uso do Analisador de Fluxo de Trabalho . Seu projeto deve poder ser executado no Analisador de Fluxo de Trabalho e ter um mínimo, se não zero, de avisos. Convenções de nomenclatura, práticas recomendadas de projeto, regras de capacidade de manutenção e legibilidade e regras de uso precisam ser seguidas. Alguns exemplos importantes dessas regras:

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

• Tratamento de erros: implemente mecanismos robustos de tratamento de erros dentro da biblioteca para lidar com exceções e falhas normalmente. Use blocos try-catch e forneça mensagens de erro informativas para ajudar na solução de problemas.

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

  • Considere usar o UiPath Test Suite e fornecer fluxos de trabalho de teste para sua automação.

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