Ciclo de Vida da Automação

Compreensão do processo

A decisão entre uma automação para Robôs assistidos ou não assistidos é a primeira decisão importante que impacta como os desenvolvedores criam o código, pois a estrutura em execução geral (gatilhos, interação, gerenciamento de exceções do Robô) é diferente. Alternar para o outro tipo de Robôs posteriormente pode ser complicado.

Para processos urgentes, em tempo real e acionados por humanos, como em um call center, um Robô assistido trabalhando lado a lado com um humano pode ser a única opção possível.

Porém, nem todos os processos que precisam de intervenção humana devem ser executados com Robôs assistidos. Se uma decisão dependente de julgamento (não baseada em regras) durante o processo não puder ser evitada, avalie se uma alteração do fluxo é possível, como dividir o processo maior em dois subprocessos menores, quando a saída do primeiro subprocesso se tornar a entrada para o segundo. Embora a intervenção humana seja feita no meio, como validar/modificar a saída do primeiro subprocesso, ambos os subprocessos podem ser disparados automaticamente e serem executados de forma não assistida.

Um caso típico seria um processo que requer uma etapa manual em algum momento durante o processo, como verificar a seção de comentários não estruturados de um tíquete e, com base nisso, atribuir o tíquete a determinadas categorias.

De modo geral, escolher um Robô não assistido garante um uso mais eficiente da carga do Robô e maior retorno sobre o investimento, além de melhorar o gerenciamento e acompanhamento das capacidades robóticas.

Mas esses cálculos devem levar em consideração vários aspectos, como o fato de que um Robô assistido poderia normalmente apenas ser executado nas horas de trabalho normais de uma pessoa, ou ele pode manter a máquina e o usuário ocupados até que a execução seja concluída. Tipos de entradas, volumes de transações, restrições de tempo, a quantidade de Robôs disponíveis e outros fatores também influenciam essa decisão.

Documentação do processo – DSD

A documentação do processo guia o trabalho do desenvolvedor e fornece ajuda no rastreamento das solicitações e na manutenção do aplicativo. É claro, podem haver vários outros documentos técnicos, mas um deles é crítico para uma implementação perfeita, chamado DSD (Documento de Especificação de Desenvolvimento).

O Documento de Especificação de Desenvolvimento deve conter os detalhes do processo automatizado e focar em duas categorias principais: Guia de Runtime e Detalhes de Desenvolvimento.

O Guia de Runtime deve conter um diagrama de runtime de alto nível, além de informações detalhadas sobre a funcionalidade do Robô, como subprocessos, agendamentos, configurações, arquivos de entrada, arquivos de saída, arquivos temporários e ações executadas. Informações adicionais sobre o processo mestre devem ser especificadas, como pré-requisitos, gerenciamento automático e manual de erros, retomada do processo em caso de falha, uso do Orchestrator, registro em log e relatórios, credenciais de gerenciamento e todas as demais informações relevantes relacionadas à segurança ou ao funcionamento.

Os Detalhes de Desenvolvimento devem conter informações sobre os pacotes em uso, o ambiente de desenvolvimento, o nível de registro, o repositório do código-fonte e controle de versão, uma lista dos componentes do fluxo de trabalho com sua descrição e lista de argumentos, uma lista de componentes reutilizáveis, a árvore de invocação do fluxo de trabalho, registros personalizados e campos de registro definidos, snapshots relevantes do fluxograma do processo, o nível de automação em segundo plano versus em primeiro plano, e todos os demais itens de desenvolvimento relevantes ou pendentes.

Desenvolvimento e revisão do código

O Arquiteto de Soluções de RPA é responsável por treinar continuamente os desenvolvedores nas práticas recomendadas. Por isso, revisões frequentes e completas dos códigos são obrigatórias para impor uma altíssima qualidade dos fluxos de trabalho desenvolvidos. Dessa maneira, os desenvolvedores ficam motivados a criar fluxos de trabalho robustos e a seguir o guia de melhores práticas.

Testar

Após cada componente ser criado, o teste de unidade deve ser realizado. Se todos os componentes forem testados minuciosamente, a integração será executada sem problemas, e a depuração durará menos tempo. O REFramework contém uma pasta Test_Framework, na qual todos os arquivos de teste devem ser colocados. Usando o arquivo .xaml, um desenvolvedor pode testar uma sequência contendo vários arquivos RunAllTests.xaml automaticamente, podendo experimentar pequenas integrações entre os componentes e realizar testes de estresse. Um relatório é gerado no fim de cada teste. Normalmente, esses tipos de testes devem ser executados fora do horário de expediente, em ambientes de teste, para otimizar o tempo do desenvolvedor.

A arquitetura UiPath^® recomendada inclui ambientes de Desenvolvimento e Teste que permitem que os processos sejam testados fora dos sistemas de produção ao vivo.

Algumas vezes, os aplicativos parecem ou se comportam de forma diferente entre os ambientes de Desenvolvimento, Teste ou Produção e medidas adicionais devem ser tomadas, eliminando seletores ou até a execução condicional de algumas atividades.

Use o arquivo UiPath.config ou os ativos do Orchestrator para alternar os sinalizadores ou as configurações do ambiente atual. Um parâmetro do modo de teste (Boolean) pode ser verificado antes de interagir com aplicativos ao vivo. Isso pode ser recebido como uma entrada de ativo (ou argumento). Quando estiver definido como True, durante o teste de depuração e de integração, ele segue a rota de teste, não executa o caso completamente. Por exemplo, o patch de teste pode ignorar o envio de notificações, ignora o botão OK ou Salvar ou pressiona o botão Cancelar ou Fechar ao invés. Quando definido como False, a rota do modo de Produção normal é seguida.

Isso permite que você faça modificações e teste-as em processos que funcionam diretamente em sistemas ao vivo.

Versão

Há várias maneiras de projetar a arquitetura e liberar o fluxo, considerando a configuração da infraestrutura, preocupações sobre a segregação de funções, etc.

Neste modelo proposto, os desenvolvedores da UiPath podem criar seus projetos e testá-los em ambientes de Desenvolvimento no Orchestrator. Eles são autorizados a fazer o check-in do projeto para uma unidade gerenciada por um sistema de controle de versão (VCS), como GIT, SVN ou TFS.

A publicação do pacote e disponibilizá-lo para Teste e Produção é o trabalho de uma equipe diferente, como a de TI.

Os caminhos de implantação no Orchestrator foram alterados de seu padrão para as pastas gerenciadas pelo VCS, alterando o valor do Storage.Location no arquivo UiPath.Orchestrator.dll.config da seção Implantação.

O modelo também contém um repositório de componentes reutilizáveis.

Veja abaixo o fluxo de publicação do projeto, passo a passo:

1. Os desenvolvedores criam o processo, testam e depuram as partes dele localmente (Studio).
2. Após o desenvolvimento da automação ser concluído, o processo será publicado no Orchestrator de Desenvolvimento e testado novamente de ponta a ponta.
3. A pasta do projeto é confirmada (não é criado um paco6te) em uma pasta da Biblioteca Mestre (no VCS).
4. A equipe de operações de TI/RPA cria o pacote de projeto para o controle de qualidade. Esta etapa é destinada a ser uma medida de segurança adicional: o código-fonte da automação será inspecionado (por uma entidade diferente) antes de ser criado o pacote e executado pelos Robôs. Por exemplo, o processo de empacotamento será armazenado na pasta Pacotes de processo (CQ) no VCS, a partir da qual será implantado para os Robôs de CQ e executado.
5. Caso algum problema seja revelado durante os testes, as etapas acima serão repetidas.
6. Após todos os testes de CQ serem aprovados, o pacote é enviado para um ambiente de Produção – Pacotes de processo (Prod).
7. Quando o processo ficar ao vivo, o pacote do processo será implantado nos Robôs de produção e executado.

O Conteúdo reutilizável é criado e implantado separadamente, como código da UiPath (Biblioteca de Códigos Reutilizáveis) e Invocações (Repositório de invocações).

Fluxos de trabalho com código-fonte são arquivos .xaml que contêm atividades para automatizar processos comuns, como Login no SAP:

As Invocações representam fluxos de trabalho compostos apenas de uma atividade Invoke dos fluxos de trabalho do código mencionados acima.

O painel Fragmento de um desenvolvedor do Studio deve apontar para esse repositório de Invocação para fornecer acesso fácil (arrastar e soltar) ao Conteúdo Reutilizável.

A autoridade de design local responsável pela manutenção do Conteúdo Reutilizável atualiza (devido a uma alteração no processo, por exemplo) os fluxos de trabalho com código. As Invocações permanecem inalteradas.

A vantagem dessa abordagem (em contrário à de trabalhar diretamente com a biblioteca do código-fonte) é que quando uma alteração é feita em um componente reutilizável, todos os projetos em execução também refletem essa alteração, porque eles contêm apenas uma atividade Invoke do fluxo de trabalho alterado.

Monitoramento

O uso de atividades Log Message para rastrear a evolução de um processo em execução é essencial para supervisionar, diagnosticar e depurar um processo. As mensagens devem fornecer todas as informações relevantes para identificar com precisão uma situação, incluindo o ID e o estado da transação.

O registro em log deve ser utilizado:

• No início e no fim de cada fluxo de trabalho;
• Quando os dados estiverem vindo de fontes externas;
• Toda vez que uma exceção for capturada no nível mais alto.

Mensagens são enviadas com a prioridade especificada (por exemplo, Info, Trace, Warning) ao Orchestrator e são salvas no arquivo .nlog local.

Campos de log personalizados

Para disponibilizar dados com facilidade no Kibana para fins de relatórios, o Robô pode sinalizar mensagens de log com valores extras utilizando a atividade Add Log Fields. Por padrão, qualquer saída de log da UiPath já tem vários campos, incluindo message, timestamp, level, processName, fileName e a Identidade do Windows do Robô. Os campos de log são persistentes, portanto, se nós não precisarmos marcar todas as mensagens com uma tag, os campos devem ser removidos imediatamente após o registro em log, usando a atividade Remove Log Fields. Não utilize um nome de campo que já existe. É importante especificar o tipo adequado de argumento na primeira vez que você adicionar o campo. É dessa forma que o Elasticsearch o indexa.