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.

Quando os Attended Robots fazem sentido

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.

Reconsiderando Attended Robots

Nem todos os processos que exigem entrada humana devem usar Attended Robots. Se uma decisão de julgamento for instável, considere dividir o processo em subprocessos menores que podem ser executados não assistidos.

Por exemplo, um subprocesso pode coletar dados e, após a validação humana, um segundo subprocesso continua automaticamente.

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.

Benefícios e Considerações Práticas

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.

No entanto, vários fatores afetam essa decisão:

• Attended Robots normalmente são executados apenas durante o horário de trabalho
• Attended Robots mantêm as máquinas e usuários ocupados até que a execução seja concluída
• Tipos de entrada e volumes de transação
• Restrições de tempo e agendamento
• Número de Robôs disponíveis

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 e detalhes sobre a funcionalidade do Robô, incluindo subprocessos, agendamentos, definições de configuração e gerenciamento de arquivos.

Inclua detalhes sobre pré-requisitos, tratamento de erros, retomada do processo, uso do Orchestrator, registro em log, relatórios e gerenciamento de credenciais.

Os Detalhes de desenvolvimento devem incluir pacotes, ambiente de desenvolvimento, níveis de registro em log, informações de controle de origem e componentes do fluxo de trabalho com descrições.

Inclua também componentes reutilizáveis, árvores de invocação, logs personalizados, instantâneos de fluxogramas, níveis de automação e outros detalhes de desenvolvimento.

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, realize testes de unidade. Testes detalhados de componentes garantem uma integração mais suave e depuração mais rápida.

Use a pasta Test_Frameworkdo REFramework para arquivos de teste. O arquivo RunAllTests.xaml permite testes automatizados de vários arquivos .xaml . Execute testes fora do horário de expediente em ambientes de teste para otimizar o tempo do desenvolvedor.

A arquitetura da UiPath recomendada inclui ambientes de Desenvolvimento e Teste que permitem testar os processos 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 sinalizadores específicos do ambiente. Defina um parâmetro booleano de modo de teste para controlar o comportamento durante a depuração.

Quando True, a automação segue rotas de teste e não é executada totalmente. Por exemplo, ignore as notificações e use Cancelar em vez de Salvar. Quando False, segue as rotas de produção normais.

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

Use as atividades Log Message para rastrear a execução do processo para supervisão, diagnóstico e depuração. As mensagens devem incluir IDs de transação e informações de estado para uma identificação precisa.

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.