Melhores Praticas de Desenvolvimento RPA

Histórico das Revisões

Versão Revisão Autor Descrição

1.0 09/04/2019 Thiago Oliveira Batista Elaboração do documento

2.0 19/10/2021 Thiago Oliveira Batista Atualização credenciais

ÍNDICE
1. Introdução
2. Objetivo
3. Empresas / Áreas envolvidas
4. Macro fluxo
5. Melhores Práticas no Desenvolvimento RPA
5.1. Reutilização de Códigos
5.2. Variáveis
5.2.1. Variáveis "Hard Coded"
5.2.2. Informações Confidenciais
5.3. Nomenclatura do Projeto
5.4. Logica de Retry
5.5. Logica de Timeout e Exceções
5.6. Utilizando APIs de Legados
5.7. Utilizando APIs do RPA (exposição de APIs)
5.8. Utilizando Aplicações
5.9. Utilizando Aplicação SAP
5.10. "Waits" ou "Sleeps" no código
5.11. Quantidade de ações por função/objeto
5.12. Divisão de responsabilidades – fluxos e funções
5.13. Validação de Eficiência
5.14. Alteração de Senha do Usuário Robótico
5.15. Utilização de Filas
5.16. Schedules e Execuções dos robôs
5.17. SendKey e mapeamento por região
6. Documentos Adicionais

Introdução
Este documento descreve os procedimentos e melhores práticas para o desenvolvimento de soluções e projetos que utilizam RPA (Robotic Process
Automation), independente da tecnologia ou da ferramenta de RPA utilizada para o desenvolvimento.

Objetivo
O objetivo deste documento é servir como guia para o desenvolvimento das soluções robóticas dentro da Telefônica. Desenvolvedores das fábricas vão
precisar olhar para este documento e tentar seguir ao máximo todas as boas práticas previstas, com o intuito de melhorar a qualidade, eficiência e
resiliência das automações.
Na validação feita pelo Pipeline DevOps, quando uma boa prática não é atendida, o COE deve questionar a fábrica do porquê as melhores práticas não
foram atendidas. Neste caso, o Squad precisa dar uma explicação dizendo qual o problema dentro do processo ou dentro das ferramentas robóticas que
o impediu de seguir as melhores práticas. Ex: Aplicação com comportamento aleatório, problemas de performance por conta das aplicações envolvidas
etc.

Empresas / Áreas envolvidas

Todas as soluções robóticas desenvolvidos para a Telefônica-Vivo.
Áreas envolvidas: COE e Fábricas.

Macro fluxo
Para garantir que as melhores práticas no desenvolvimento descritas neste documento sejam realizadas de forma assertiva e assegure o alcance dos
resultados definidos, os papéis e responsabilidades dentro da organização para execução destas atividades devem estar claramente definidos e
divulgados.

Atividades DCoE (Thiago Batista)(Dandara Cembranel)(Carolina Canato) Desenvolvedores Squad Líder Squad Arquiteto Squad

Construir norma R I I I

Comunicar norma R I I I

Executar norma I R C I

Monitorar norma I C R R

Validar norma A I C R

(Responsável; Aprovador; Consultado; Informado)

Melhores Práticas no Desenvolvimento RPA

Reutilização de Códigos
É responsabilidade de cada fábrica se certificar se alguma funcionalidade do processo a ser automatizado já foi feita em outra oportunidade/projeto por
outros desenvolvedores. Caso o processo ou objeto a ser reutilizado não atenda 100% a necessidade da nova operação, apenas o "gap" deve ser
desenvolvido, mas sem sobrescrever a versão original.
Neste caso, se eu tenho um objeto "helloworld_v1.0", o desenvolvedor deve copiar este objeto e colocar o nome de "helloworld_v2.0" e desenvolvedor o
gap existente.

Variáveis
Existem algumas boas práticas envolvendo o uso de variáveis e suas nomenclaturas. Dentro da Telefônica, vamos definir um padrão para qualquer
ferramenta de RPA que será implantada.

Variáveis "Hard Coded"

Devemos evitar a criação de variáveis com valores fixos no código da automação. Sempre devemos alimentar uma variável ou um objeto com valores
que podem ser passados como parâmetros pelo operador (em uma operação assistida), ou capturados em algum sistema, aplicação, arquivo ou banco
de dados (como variáveis de ambiente)
Com isso, o código não fica confuso para outros desenvolvedores além de evitar possíveis erros na automação por usar valor com um formato inválido.

Informações Confidenciais
Quando estamos trabalhando com informações confidenciais, como usuário e senha de um sistema ou aplicação e informações pessoais de clientes,
essas informações, em nenhuma circunstância, devem ser salvas dentro de objetos ou variáveis. Neste caso, devem ser usadas apenas para execução
em memória (runtime).
Normalmente, os grandes softwares de automação contêm um repositório para armazenamento de informações confidenciais, e sendo uma
funcionalidade nativa da ferramenta essa é a melhor maneira de transitar tais informações para o "client" (runtime).

Credenciais – Usuários e Senhas

Pelas boas práticas toda informação de credenciais (usuário, senha, informações confidenciais, etc) que forem usadas pelo robô devem ficar
criptografadas em banco. A grande maioria dos sistemas de RPA hoje em dia tem uma funcionalidade nativa para armazenar as informações de
credenciais de forma segura, que deve ser usada por qualquer ferramenta de RPA. Mesmo que a ferramenta não tenha algo nativo para guardar
credenciais, as informações de usuário e senha devem ser criptografadas no banco.

No processo robótico, sempre que é necessário usar as informações de uma credencial, devemos "capturar" essas informações usando a funcionalidade
nativa (realiza a descriptografia automática), ou caso não seja possível pela ferramenta, realizar a descriptografia manual das informações para uso no
processo robótico. Vale lembrar que as informações de credenciais não podem ser guardadas em NENHUM outro lugar, principalmente nas variáveis do
processo robótico.
Caso seja necessário usar uma senha para realizar alguma conexão, por exemplo uma string de conexão para um banco de dados, é necessário
encriptografar toda a informação (incluindo servidor, instancia etc.), salvando a string criptografa em banco e somente descriptografar quando for
necessário o uso no processo do robô.

Nomenclatura do Projeto
Devida a diferença da forma de desenvolvimento das ferramentas da BluePrism e NICE, criamos uma nomenclatura padrão para cada um dos softwares
em relação aos processos robóticos.
Para os projetos desenvolvidos em NICE, vamos utilizar <nome do projeto><fase>_<camada>. Alguns exemplos são: ContasOfflineRoteamento_BL
ContasOfflineFiltro_BE2ViadeFatura_PO2ViadeFatura_Main
Agora para os projetos desenvolvidos na plataforma da BluePrism, segue o documento de padrão de nomenclatura:
Nomenclaturas Globais RPA - Telefônica

Logica de Retry
No desenvolvimento de automações robóticas é necessário fazer uma validação se a ação que a automação deveria realizar foi realmente feita, e se o
robô pode seguir para o próximo passo. Por exemplo, sempre que a automação precisar clicar em um botão ou passar de uma tela para outra, verificar se
existe algum elemento pós ação que confirme a execução com sucesso do passo anterior.

Caso a ação não tenha sido executada de forma correta, também uma boa prática tentar executar pelo menos 2 vezes a ação novamente. Nem todos os
processos e ações vão conseguir implementar esta lógica**, por questões do próprio sistema que roda a automação, mas sempre que possível seguir
esta forma de tratativa.
Esse modelo também se aplica em itens da fila. Se for possível, colocar um retry em todos os itens da fila que deram erro sistêmico ou erro não
mapeado, para que o robô tente executar o item novamente.
**Obs: Para processo como o login em um sistema não é correto fazer uma lógica de retry, pois na maioria dos sistemas, executar o login
incorretamente diversas vezes seguidas causa o block no usuário utilizado.

Logica de Timeout e Exceções

Sempre que ocorrer alguma exceção ou erro devido a um comportamento inesperado da aplicação, um cenário não mapeado na automação, muitas
tentativas em logicas de retry ou por questões de timeout, deve ser gerado um alerta de erro, contendo uma mensagem clara e objetiva com o status ou
mensagem de erro e em que ponto da automação a exceção ocorreu.

Para ajudar o time de sustentação e produção, ainda é recomendado que o robô tira um PRINT da tela no momento da exceção. Isso pode ajudar a
realizar o troubleshoot mais rápido do problema, pois caso o erro seja um Popup ou um erro que fique claro na tela do sistema, é mais fácil de realizar o
ajuste ou a solução de contorno até que seja alterado código do robô.
Hoje na Telefônica existe uma pasta dentro do Lagoa (file server) que cada um dos projetos deve criar uma subpasta específica para o mesmo. Nesta
pasta específica do projeto deverão ser armazenados logs de erro e prints das exceções causadas no fluxo do robô.

Utilizando APIs de Legados

Pelas novas diretrizes do COE e do time de Segurança Telefônica, todas APIs que são de sistemas legados tem que passar pelo API Gateway, onde é
possível colocar o fator de autenticação oAuth. É recomendado o uso da autenticação oAuth na chamada para autenticação no gateway pois as duas
plataformas (NICE e BLUEPRISM) já tem uma aplicação criada no gateway e é o método de autenticação sugerido pelo time de segurança da Telefônica.

Neste cenário, toda API que ainda não esteja no barramento deve ser virtualizada dentro do gateway:
API REST (com Swagger) – Quando é usado uma API REST e existe também o Swagger da API, é necessário envolver o time de integração da
Telefônica para que eles realizem a virtualização dessa API dentro do Gateway.
API REST (sem Swagger) ou API SOAP – Quando é usado uma API REST e não existe um Swagger da API ou é usado uma API SOAP, é necessário
abrir um JIRA para o time de integração para eles realizarem a estimativa da construção da abstração do serviço ou construção do Swagger, e depois
eles virtualizam isso dentro do API Gateway.

Utilizando APIs do RPA (exposição de APIs)

Alguns projetos têm a necessidade de expor uma API robótica, ou seja, expor uma API pela própria ferramenta do robô (NICE ou Blueprism). Agora com
a ideia de APIficação, processos robóticos com exposição de API estão ficando cada vez mais comuns, e temos que seguir as melhores práticas para
não termos problema com Produção.
Quando é necessário expor uma API a partir de um processo robótico, temos que usar o servidor de IIS para garantir o melhor funcionando da API e
melhor sustentação e operação do robô. Muitos dos casos, a exposição de APIs é o INPUT do processo (produtor), logo é preciso ter alta disponibilidade
e uma melhor governança sobre o serviço.

O serviço do robô exposto deve ter conectividade com a base de negócio do projeto, para que seja possível armazenar as informações que foram
enviadas na REQUEST dentro de tabelas de negócio. Assim, o robô consegue se conectar com a base e ler a tabela para popular a fila de execução,
garantindo que nenhuma REQUEST ficará perdida caso o robô esteja indisponível .O desenvolvimento pode ser feito em qualquer linguagem (.NET, C#,
etc), o importante é garantir que as informações da Request sejam armazenadas e que o processos robótico se conecte com a base para popular a fila de
execução.

Utilizando Aplicações
É muito comum em automações (principalmente em sites web) desenvolver a lógica de fechar e abrir a aplicação ou browser sempre que se começa um
novo item na fila de processamento. Isso acaba impactando a performance e a possibilidade de escalabilidade do robô, pois a automação deve realizar
um login ou um conjunto de ações novamente para começar o novo processo. Em alguns casos isso deve ser feito por políticas de timeout com tempo
bem reduzido, mas devemos olhar caso a caso e, se for possível, implementar uma lógica que ao final da execução de um item, o robô deixa a aplicação
em uma página "home", para que no próximo item o robô não precise realizar o login ou gastar tempo executando outras ações antes de executar
efetivamente o processo.

Deverá ser feita a lógica de fechar/abrir a aplicação somente quando for iniciado a execução do primeiro item, assim o robô não terá problemas de
timeout caso o tempo entre o fim e início do processamento seja muito grande.

Utilizando Aplicação SAP

Quando o processo robótico tiver que executar ações dentro do SAP, deverá ser usado a funcionalidade do SAP Scripting para automatizar o mesmo.
Dessa forma, nosso processo fica mais rápido e performático, além de correr menos risco de falhas dentro do robô. Não é preciso desenvolver o script na
mão, o próprio SAP possui a funcionalidade de gravar as ações e gerar um script com o código pronto.

Para isso, basta seguir as instruções no documento abaixo:

Howto - SAP Scripting

"Waits" ou "Sleeps" no código

Sempre devemos evitar o uso de "Sleeps" ou "Waits" com tempo pré-determinado na codificação da automação. Isso pode deixar o robô lento além de
causar erros caso a ação anterior à espera não seja executada de forma correta. De acordo com as melhores práticas, o certo é implementar uma lógica
de validação com contadores para verificar se uma ação foi executada corretamente pelo robô.

Por exemplo quando vamos executar uma ação em uma aplicação web, seja essa ação por conectividade nativa da ferramenta ou por scripts, quando
vamos clicar em um botão para abrir uma nova página, devemos criar uma lógica para que o robô tente identificar a nova tela e, caso a tela não apareça
após X tentativas (geralmente 3), gerar uma exceção com a mensagem do erro.
Existem processos ou conjunto de ações que o "Wait" com um tempo fixo é necessário para que a automação funcione, mas só devemos usar este
recurso em últimos casos.

Quantidade de ações por função/objeto

Uma das boas práticas mais importantes no desenvolvimento de automações são às responsabilidades de uma função ou um objeto. Sempre temos que
tentar manter um padrão, que todo objeto e função tenha que ser o mais granular e independente possível, evitando fazer várias ações dentro do mesmo.
Por exemplo, se meu robô precisa fazer login em um sistema e entrar em uma tela de um menu, é recomendado separar essas ações em uma função
/objeto de login, e outra função para acessar o menu do sistema. Dessa forma, temos ações independentes e que podem ser reutilizadas.
Desenvolver fluxos e funções que tenham muitas responsabilidades deixa o processo difícil de dar manutenção e muito mais difícil de realizar
troubleshooting de problemas no futuro.

Divisão de responsabilidades – fluxos e funções

Independente da tecnologia ou do software usado para o desenvolvimento, existem divisões de responsabilidades que precisam ser feitas para o melhor
suporte à automação. Uma boa prática é separar a camada de objetos que serão utilizados no processo da camada lógica, que é responsável pela
"inteligência" e o fluxo que automação vai realizar.
Assim, devemos deixar toda a lógica de looping, regras de negócio e validações (IFs) dentro dos processos robóticos, e não dentro das funções e
objetos. Dentro dos objetos e funções só podem existir ações que interajam com o sistema que estamos conectados.
Essa divisão precisa ser feita em todos os projetos, para termos um entendimento padrão de desenvolvimento, onde qualquer Squad consiga ver um
projeto desenvolvido por outras pessoas e rapidamente saber onde estão as logicas do negócio/fluxo e as interações com o sistema. O própria NICE e
Blueprism recomendam um template de divisão de projetos / artefatos que deve ser seguido.

Validação de Eficiência
Antes da entrega do projeto, os desenvolvedores juntamente com o arquiteto do Squad têm a responsabilidade de validar a eficiência da automação, ou
seja, validar se existe alguma melhoria a ser feita para otimizar recursos como tempo, processamento, objetos etc. Muitas vezes o uso de scripts em
páginas web ou em aplicações .NET/JAVA (por exemplo) podem dar ao robô uma velocidade de processamento maior, evitando ainda o risco de erros
por mapeamento e exceções do sistema.
Essa parte da validação é vital para melhorar a escalabilidade da automação, além de gerar redução dos custos envolvidos no processo robótico.

Alteração de Senha do Usuário Robótico

Pelas políticas de usuários robóticos da Telefônica, a senha dos usuários robóticos (tanto de TI como de negócio) não expira. Logo, dificilmente vamos
ter que desenvolver um processo extra para reset e validação das senhas dos usuários.
Porém, quando falamos em aplicações departamentais ou que não estejam integradas com o AD da Telefônica, podem existir cenários onde a área de
negócio não concorda com a não expiração de senha ou o sistema realmente não suporte esse tipo de configuração. Neste caso, será necessário (e
obrigado!!) o desenvolvimento de um processo separado ao que foi mapeado para que seja possível realizar o reset de senha assim que necessário.
Hoje existem vários robôs que estão executando processos em sistemas departamentais, logo cada fábrica precisa validar internamente se já não existe
um robô de troca de senhas que possa ser reutilizado para um projeto em desenvolvimento que se enquadre neste cenário.

Utilização de Filas
Pelas boas práticas, todo processo robótico deve ser otimizado para utilização das filas, onde cada transação (BD, chamado, protocolo) a ser executada
é um objeto dentro de uma fila. Pelo conceito da fila, cada item que existe em uma fila precisa ser único, ou seja, ter um ID ou uma "chave" única.
Por exemplo, ao automatizar um processo que a operação disponibilizará um Excel com 2 mil linhas, onde cada linha representa uma transação diferente.
Neste caso é preciso criar uma espécie de "Invoker" ou "Produtor", um robô ou processo separado para ler este Excel e enviar cada linha para uma fila de
automação para execução dos robôs.
Caso não exista alguma informação na linha que seja única, que torne aquela transação única, é possível concatenar com a data e a hora da execução,
assim mesmo que a informação se repetir a data e hora/minuto faz com que aquele item seja único.
Desta maneira, conseguimos assegurar maior eficiência na execução dos processos, aumentar nosso poder de escalabilidade e ainda conseguir
reprocessar somente os itens que apresentarem erros em suas execuções.

Status de itens da fila

Quando um robô insere, processa ou finaliza um item na fila, existem alguns status padrão que é preciso utilizar para conseguir diferenciar facilmente
qual o status que aquele item da fila se encontra, criando assim um índice igual para todas as ferramentas. Assim, conseguimos diferenciar quais
exceções são de negócio ou quais itens foram processados com sucesso, independente de qual processos e sobre qual ferramenta estamos tratamos.
Segue abaixo qual o padrão de fila que utilizamos:

1. Pendente

Quando um item é inserido na fila e está pendente de execução pelo processo robótico

2. Em processamento

Quando um item começa a ser processado pelo robô, em algumas ocasiões é necessário trocar o status do item na fila conforme o robô está executando.
Dessa forma pode ser mais fácil realizar alguma logica de retry do item, para que o robô inicie a execução do item novamente, mas de um ponto futuro no
processo ou ainda para ficar mais fácil no troubleshoot em caso de uma falha repentina do robô.

3. Concluído

Quando o item é finalizado com sucesso pela automação.

4. Exceção de sistema

Quando o item é finalizado com uma exceção causada pelo sistema legado que o robô está acessando (popup, erro ao carregar uma página etc)

5. Exceção de negócio

Quando o item é finalizado com uma exceção conhecido de negócio, mapeada durante o processo de desenvolvimento.

6. Exceção não mapeada

Quando o item é finalizado por uma condição não mapeada, onde a exceção não foi mapeada durante o desenvolvimento do robô por um comportamento
desconhecido do sistema legado.

Schedules e Execuções dos robôs

Apesar de não entrar em questões de desenvolvimento em si, os schedules e o horário de início da execução do processo robótico é um ponto importante
para o bom funcionamento do robô, e existem boas práticas que devem ser seguidas para a efetividade desse ponto.

Uma coisa importante sobre quando o robô deve iniciar sua execução é não deixar que o processo execute em um período onde, dentro do sistema
legado, rodem scripts ou Jobs de atualização/limpeza de base. Isso pode causar uma lentidão nos sistemas e que podem impactar a execução do
processo. Geralmente esses Jobs e scripts rodam na madrugada, mas é necessário validar isso com a área de negócio ou PCP do sistema legado.
Outro ponto a ser considerado é quanto tempo o robô fica rodando sem pausar. Nossas máquinas não são muito grandes (temos no máximo 2vCPUS,
8GB RAM), então é importante não deixar o robô executando por longos períodos. O COE recomenda que o robô fique rodando em média 5 horas, e que
depois dessas 5 horas o processo dê uma pausa na execução (coisa de 5 minutos) para liberar a memória para a próxima execução.
O Squad pode usar a funcionalidade do Blueprism para o robô parar a execução após X itens da fila, e fazer o controle do com base nesses itens. Por
exemplo, se um item da minha fila demora em média 10 minutos para ser executado, seguindo a recomendação do COE, conseguimos executar 30 itens
(300 minutos) antes de estourar o tempo limite. Dessa forma, posso colocar a lógica que após 30 itens o robô pare a execução e espere a próxima
schedule para rodar.

SendKey e mapeamento por região

Em algumas páginas ou aplicações é necessário usar a opção de "SendKey" para conseguir inserir informações ou selecionar um menu, ou ainda é
necessário mapear os campos via "OCR" ou por regiões/pixels, sem utilizar o ID ou a Classe/Texto. Nesses casos, o robô tende a ficar mais frágil,
podendo quebrar ou não conseguir executar o processo completo caso a tela não esteja em primeiro plano.

Com esse tipo de mapeamento, é preciso tomar alguns cuidados para deixar o robô resiliente e mais robusto, para que não dê erro caso apareça alguma
informação diferente na tela. No caso do SendKey, antes de executar qualquer ação e pedir para a automação inserir as palavras é necessário "ativar" a
tela do sistema ou do browser, ou seja, trazê-la para o primeiro plano. Dessa forma o robô não corre o risco de apertar as teclas na tela errada, parando o
processo.

No caso de mapeamento por OCR ou região, além de "ativar" a tela e trazê-la para o primeiro plano, é uma boa prática usar o conceito de Ancoragem. A
ancoragem é o princípio de, em automações por pixels, criar algumas referências na tela quando for necessário clicar nos campos, para que o robô
consiga clicar no botão mesmo se a disposição da tela mude. Por exemplo, temos 2 botões um do lado do outro e no processo é necessário clicar no
botão da esquerda. Com o conceito de ancoragem, é necessário criar uma "ancora" não somente no botão que queremos clicar (esquerda), mas também
mapear o botão da direita e criar uma referência entre os dois, assim o RPA vai entender que o botão da esquerda está a X pixels do botão da direita.
Então mesmo que os dois botões mudem de posição na tela, a automação continua funcionando por conta da ancora que foi referenciada entre eles.

Mapeamento dos elementos

Ao mapear os elementos de um sistema, as ferramentas de RPA utilizam algumas informações capturadas do elemento para que seja possível
reconhecer o mesmo depois, durante a execução do robô. Algumas dessas informações podem vir em branco ou podem atrapalhar a execução do
processo dependendo do conteúdo e da chave que foi escolhida para reconhecimento.
Pela boa prática, devemos sempre "desativar" as chaves que estão em branco e as chaves que podem causar ambiguidade no elemento (por exemplo o
tipo, texto ou elemento pai). É recomendado utilizar chaves que são únicas ou que pertencem exclusivamente ao elemento (como ID e classe).
Existem algumas exceções a regra, mas a ideia é sempre deixar o elemento com menos chaves possível, e somente chaves que garantam que o
elemento vai ser reconhecido em todas as condições da automação.

Documentos Adicionais