Não categorizado

Arquitetura de automação RPA: explorando as entidades

Dentre as diversas ferramentas e nomenclaturas utilizadas pela arquitetura de automação RPA, é importante entendermos como todas essas entidades funcionam, como automação, robô, tarefas, alertas, workspaces, runners, logs, ferramentas de desenvolvimento, entre outras. 

Neste artigo, vamos discutir para que servem e como se relacionam durante o processo de criação, orquestração, gerenciamento e finalização de um robô.

 

O que é arquitetura de automação?

Arquitetura de automação envolve a criação da estrutura de automações e seu gerenciamento, além da definição de como os robôs e entidades do ambiente de automação vão interagir.

Em Robotic Process Automation (RPA), existem diferentes tipos de arquiteturas de automação que definem como as automações são implementadas:

  • Automação assistida (attended automation): quando a automação funciona no dispositivo do usuário e é acionada manualmente.
  • Automação não assistida (unattended automation): neste caso, as automações são executadas em servidores, sem a necessidade de interação humana durante a execução. Os fluxos de trabalho são auto iniciados e podem ser programados para executar em horários predefinidos ou em tempo real. 
  • RPA híbrida: combina automação assistida e não assistida, proporcionando automação tanto para atividades de front-end quanto de back-end. 

Um componente crítico em qualquer arquitetura de automação, seja em RPA ou não, é o orquestrador, que gerencia e escala os robôs de automação incluindo sua implantação, gerenciamento de tarefas, sistema de agendamento, alertas, gerenciamento de erros, credenciais e grupos de usuários com diferentes níveis de acesso.

Mais adiante, vamos explicar como é a relação entre robôs e agentes de automação, e também trazer alguns exemplos práticos de aplicação para RPA.

 

Como a automação e o robô se relacionam para executar as tarefas?

A automação é a tecnologia que utiliza os robôs para processar as tarefas que são necessárias utilizando runners. O runner é a ferramenta que identifica essas tarefas que precisam ser executadas e configura o ambiente na máquina onde a execução acontecerá.

Os robôs são os projetos que desenvolvemos utilizando diversas tecnologias, seja por meio de linguagens de programação como Python, Java, C# etc., frameworks como Selenium, BotCity Framework etc., ferramentas low-code, entre outras.

E são pelas automações que criamos as tarefas, sejam para serem adicionadas na fila de execução no mesmo momento de sua criação ou para agendar. E a execução dessas tarefas é feita pelos runners configurados para a automação.

💡 Saiba mais: Guia sobre como gerenciar a execução das suas automações

No exemplo abaixo, temos uma automação que possui um robô. E a partir da automação, criamos uma tarefa para ser adicionada agora na fila e dois agendamentos para serem executados posteriormente.

fluxo de arquitetura de automação RPA demonstrando o relacionamento entre automação, robô e suas tarefas. Do lado esquerdo um conjunto de runners, Runner 00 e Runner 01. Ambos estão ligados ao conjunto no meio da imagem representando a automação e, dentro dele, o robô. Do lado direito, um conjunto representando as tarefas. Dentro dele tem uma tarefa em execução e um outro conjunto de agendamentos. Dentro do conjunto de agendamentos estão duas tarefas agendadas como exemplo.

Uma automação pode possuir apenas um robô. E por essa mesma automação podem ser criadas diversas tarefas, sejam elas agendadas ou para serem executadas na hora de acordo com a disponibilidade dos runners. Contudo, um robô pode pertencer a mais de uma automação, se necessário.

fluxo de relacionamento da arquitetura de automação RPA demonstrando o relacionamento descrito no artigo. Uma automação pode ser executada em mais de um runner. E um runner pode executar mais de uma automação. Uma automação pode ter n tarefas e uma tarefa pertence a uma automação. Uma automação pode ter um robô. Um robô pode pertencer a mais de uma automação.

Como múltiplos runners podem ajudar a escalar minha arquitetura de automação?

É possível escalar a arquitetura de automação utilizando a tecnologia do paralelismo. Assim, conforme as tarefas forem sendo criadas e/ou agendadas e a disponibilidade dos runners configurados para as automações, a execução poderá ser mais rápida por ocorrer em paralelo. Esse diferencial pode ajudar na escalabilidade e eficiência dos seus robôs.

 

Arquitetura de automação no BotCity Orquestrador

A partir do orquestrador da BotCity, você pode disponibilizar o robô para ser executado através da funcionalidade “Easy Deploy”. O primeiro passo é criar a automação. Feito isso, basta criar o robô relacionado a essa automação, já o terceiro passo é para informar o runner onde o robô da automação será executado.

print da tela do BotCity Orquestrador para demonstrar parte do processo de arquitetura de automação, mostrando a funcionalidade de easy deploy.

 

💡 Saiba mais: Documentação sobre easy deploy

A partir disso, precisamos criar as tarefas para serem executadas. Neste caso, podemos utilizar a funcionalidade “new task”, por exemplo. 

💡 Saiba mais: Gestão da automação e como gerenciar as tarefas RPA

print da tela do BotCity Orquestrador para demonstrar parte do processo de arquitetura de automação, mostrando a funcionalidade de criar nova tarefa.

Ou ainda, como mencionado anteriormente, você pode criar agendamentos para suas tarefas. E no orquestrador da BotCity, basta clicar em “Schedules” no menu “Operation Tools” para fazer os agendamentos:

print da tela do BotCity Orquestrador para demonstrar parte do processo de arquitetura de automação, mostrando a funcionalidade de criar novo agendamento.

💡Saiba mais: Documentação sobre agendamento.

 

Quais entidades e funcionalidades se relacionam às tarefas das automações?

Existem outras entidades que estão relacionadas às tarefas que criamos para executar as automações de seus respectivos processos. Essas entidades são: alertas, erros e arquivos de resultado.

fluxo da imagem de relação na arquitetura da automação com as entidades alerta, erro e arquivo de resultado conectados a tarefa.

Essas relações podem ser criadas a partir da integração por API do BotCity Orquestrador, pelos agendamentos, diretamente pela interface do orquestrador ou ainda por uma chamada vinda do Datapool. Se você ainda não conhece essa última funcionalidade, consulte a documentação sobre Datapool.

print da tela do BotCity Orquestrador para demonstrar parte do processo de arquitetura de automação, mostrando o menu em destaque de "automation control" que possui alertas, erros e arquivos de resultado.

 

Como funcionam os relacionamentos das entidades do workspace ou organization?

O workspace ou organization é a área de trabalho dentro do BotCity Orquestrador. E a essa área de trabalho, podemos relacionar as integrações, a funcionalidade de auditoria e também os runners.

imagem do fluxo da parte da arquitetura de automação RPA que representa a ligação das entidades integração, auditoria e runner ao workspace ou organization.

É importante lembrarmos que um mesmo runner pode executar mais de uma automação, porém o runner pertence ao workspace. Esse é um diferencial de destaque do BotCity Runner. Não tem nenhum relacionamento direto com os repositórios (que dentro da gestão de grupos de usuários são o conjunto das automações criadas). Ou seja, não limita quem pode executar suas automações dentro daquele runner.

Na tela a seguir, temos a demonstração da tela de integrações, com alguns exemplos do que pode ser integrado como o Google Data Studio, Slack e também Microsoft Teams:

print do BotCity Orquestrador para mostrar a tela de integrações que faz parte da arquitetura de automação RPA.

Na tela abaixo podemos acompanhar a tela de auditoria, com alguns filtros e tipos de informações que podem ser registradas:

print do BotCity Orquestrador para mostrar a tela de auditoria que faz parte da arquitetura de automação RPA.

Você pode encontrar mais informações e orientações em nossa documentação sobre integrações e auditoria.

 

Cenários de arquitetura da automação RPA

Vamos verificar como essas entidades todas se relacionam no geral considerando alguns cenários para analisarmos e entendermos o funcionamento.

Na imagem abaixo temos três automações: Automação A, Automação B e Automação C. Acompanhando o modelo, temos a demonstração de como os runners se relacionam entre as automações e o seu workspace correspondente.

fluxo de arquitetura de automação RPA considerando dois robôs diferentes, explicados no texto.

Cenário A

Mais de uma automação para o mesmo robô com mais de um runner:

Como exemplo, vamos explorar um caso hipotético de robô de busca de processos judiciais e qual seria o relacionamento de entidades usando um orquestrador de automações, neste caso o orquestrador de RPA da BotCity.

Robô Busca de Processos Judiciais das Automações A e B:

  • Fazemos o deploy do robô “Busca de Processos Judiciais” no orquestrador;
  • A partir desse robô, criamos a “Automação A”;
    • Nessa automação, definimos que ela pode ser executada nos runners:
      • VM_00;
      • VM_01;
    • Criamos a “Tarefa 0” e a “Tarefa 1” para executar a “Automação A”;
  • A partir desse mesmo robô, criamos também a “Automação B”;
    • Nessa automação, definimos que ela pode ser executada no runner:
      • VM_02;
    • Criamos a “Tarefa 2” e a “Tarefa 3” para executar a “Automação B”;
  • Lembrando do relacionamento Robô x Automação x Tarefa x Runner:
    • Um robô pode ser relacionado a mais de uma automação. E as tarefas são criadas a partir da automação. Em orquestradores especializados de automação, é possível definir em qual runner essas tarefas serão executadas.
  • Então o que vai acontecer com o robô “busca de processos judiciais”:
    • Conforme a disponibilidade dos runners VM_00 e VM_01, eles irão puxar as tarefas correspondentes a Automação A, que são Tarefa 0 e Tarefa 1. Pode ser que cada tarefa seja executada em um runner diferente, ou pode ser que um dos runners esteja ocupado e ambas as tarefas sejam executadas no mesmo runner. Isso ajudará bastante no processamento paralelo e escalabilidade.
    • Já o runner VM_03 vai puxar a Tarefa 2 e Tarefa 3 da Automação B para serem ambas executadas nele.

Cenário B

Com apenas uma automação para um único robô e com um único runner:

Robô Conciliação Financeira da Automação C:

  • Fazemos o deploy do robô “Conciliação Financeira” no orquestrador;
  • A partir desse robô, criamos a “Automação C”;
    • Nessa automação, definimos que ela pode ser executada no runner VM_03;
    • Criamos a “Tarefa 4” para executar a “Automação C”;
  • Então o que vai acontecer com o robô “Conciliação Financeira”:
    • Conforme a disponibilidade do runner VM_03, ele vai puxar a Tarefa 4 da Automação C para ser executada nele.

fluxo de arquitetura de automação RPA considerando um robô com duas automações, explicados no texto

 

Cenário C

Com duas automações para um robô com apenas um runner:

Robô Validação de Dados das Automações A e B:

  • Fazemos o deploy do robô “Validação de Dados” no orquestrador;
    • A partir desse robô, criamos a “Automação A”;
      • Esta automação pode ser considerada, por exemplo, para um ambiente de testes;
      • Nessa automação, definimos que ela pode ser executada no runner VM_00;
      • Criamos a “Tarefa 0” e a “Tarefa 1” para executar a “Automação A”;
    • Então o que vai acontecer com o robô “Validação de Dados”:
      • Conforme a disponibilidade do runner VM_00, ele vai puxar as Tarefas 0 e 1 da Automação A para serem executadas nele.
    • A partir deste robô, podemos também criar a “Automação B”:
      • Esta automação pode ser considerada, por exemplo, para o ambiente de produção;
      • Nessa automação, definimos que ela pode ser executada no runner VM_00;
      • Criamos a “Tarefa 2” e a “Tarefa 3” para executar a “Automação B”;
    • A separação de ambientes pode ajudar, por exemplo, na validação e adicionar uma etapa de homologação para garantir a qualidade e segurança dos seus robôs.

 

Relação entre entidades de logs, credenciais e datapool

Essas entidades não têm nenhum relacionamento direto com as demais. Elas podem funcionar separadamente. Exceto pelo Datapool que tem um relacionamento fraco com as tarefas.

entidades demonstradas para a arquitetura de automação RPA: logs, credenciais e datapool

Logs, credenciais e Datapool podem ser criados além das suas automações RPA. Mas você pode relacionar essas funcionalidades, considerando o uso no código do seu robô. Você pode explorar mais sobre essas funcionalidades em nossa documentação dos logs, das credenciais e do Datapool.

Tudo certo para fazer estruturar a arquitetura de automação dos seus projetos RPA?

Você pode explorar todas as funcionalidades criando a sua conta gratuita e também participando da nossa comunidade global de RPA. Para isso, basta entrar no nosso Slack ou ainda entrar em contato pelo nosso fórum

Qualquer dúvida, só chamar a gente! E compartilhe nos comentários conosco como funciona a arquitetura das suas automações.

BotCity Cofounder and CEO

Deixe uma resposta

Descubra mais sobre Blog BotCity - Conteúdo para Automação e Governança

Assine agora mesmo para continuar lendo e ter acesso ao arquivo completo.

Continue reading