RPA sin Licencias

Parte de la motivacion de este blog es la construccion de una solucion RPA sin licencias, principalmente usando herramientas de open source, creatividad y sus propios equipos pagos de infraestructura (esto no se puede evitar).

Entonces esta es el borrador inicial de mi propuesta, que probablemente va a ser mucho mas refindo y modificado a lo largo de mis publicaciones (y hasta ahora tengo planificadas 52).

Entonces como ya mencione en mis dos post anteriores los componentes a planificar son

  • Centro de Control: Una web personalizada que permite agendar, monitorear, construir, bots.
  • Dispositivo de ejecucion: Un dispositivo dedicado que ejecuta tareas, como un equipo de una persona.
  • Mecanismo de programacion de bots: Alguna interfaz grafica de cajitas o pseudocodigo propietario.
  • Mecanismo de ejecucion de bots: Alguna interfaz programable o visual que permite disparar un bot.

Pensando bastante sobre ello, los principales beneficios de una solucion son sus interfaces graficas, su web personalizada que ejecuta tareas remotamente en un equipo con un cliente de software propietario.

Este cliente de ejecucion normalmente usa las caracteristicas del propio sistema operativo (Powershell,Cmd,Bash) e interfaces programaticas o captura de pantalla para ejecutar acciones de usuario.

Donde el control room envia una señal, el Cliente de Bot la recibe, descarga el juego de instrucciones y las ejecuta de forma secuencia sobre el Desktop. Que tiene acceso a todas sus caracteristicas nativas.

Entonces surgen las siguientes preguntas.

¿Si, no importa la interfaz grafica, como podemos controlar nuestra infraestructura, para usar sus recursos de computo, en multiples tareas independientes que no se bloqueen entre ellas?

La primera respuesta para esto son Maquinas Virtuales, pero no queremos tener que crear una VM para cada Bot, lo interesante es la reutilizacion.

Entonces la segunda respuesta es Kubernetes. Que nos permite utilizar Nodos de computo (equipos/vms), para desplegar Pods (que es una unidad minima de computo dentro de los conceptos de kubernetes)

¿Si, ya tenemos un controlador de recursos, como vamos a crear los bots sobre pods, los pods se basan en contenedores?

Excelente pregunta, y vamos a usar contenedores, al crear un contenedor de Docker, no solo podemos crear un paquete de software con dependencias pre-instaladas y unicas para una gran cantidad de actividades mundanas. Sino que podemos tener muchos en paralelo en la misma infraestructura. Lo cual es un problema comun en las soluciones de RPA comerciales. (Normalmente se resuelve con mas infraestructura y costo)

¿Si, podemos crear pods, pero los pods no tienen interfaz grafica, como podemos hacer tareas que requieran de ello?

Esto depende del alcance, podemos hacer muchas tareas en lenguaje de sistema operativo, la mayoria segmentemos las actividades que podria hacer una persona

Actividades sin UI:

  • Crear, Copiar, Borrar archivos: Cmd,Bash,Powershell
  • Navegacion web, Selenium en modo headless
  • Edicion de documentos: herramientas de bulk, python puede ser una buena opcion

Actividades con UI

  • Interfaces Web Flash u otras tecnologias obsoletas que requieren del desktop
  • Uso de perifericos de un equipo fisico, por ejemplo la camara
  • Reaccion a cambios de pantalla.

Todas las activiades con UI no se podrian hacer con un contenedor. Pero nada impide hacer un contenedor con un script, que se conecte a una maquina remota y use la interfaz (Aqui puede ser util python nuevamente).

¿Kubernetes tiene su propio log de pods, si nuestros pods son bots, cada va pod necesita enviar sus datos y registrar sus acciones en algun lugar?

Esto va a requerir un poco (bastante) trabajo manual al momento de construir el pod y el Contenedor. Pero podemos usar en kubernetes almacenamientos persistentes, y diseñar una base de datos que gestione los bots, cada bot, y cualquier necesidad que tengamos. Es un poco de procedimiento extra sobre cada dockerfile y sobre cada script de ejecucion pero todo por el bien mayor.

¿Necesitamos un cliente, y un interprete de comandos dentro de los pods, no vamos a hacer todo en bash/powershell?

Si se puede hacer todo en bash y powershell, pero hay una mejor opcion. Una de ella es robotframework (link pendiente)

Es una iniciativa de software libre, para testing funcional, que podemos empaquetar dentro del contenedor, y nuestro script en lenguaje semi-natural. Con el.

¿Necesitamos un ambiente de programacion?

Y lo tenemos, Un editor de codigo cualquiera, La documentacion de RobotFramework, Un editor de Python (por facilidad), y un Registro de Contenedores.

Cada nuevo bot es un Container Image.

¿Necesitamos crear bots que se ejecuten periodicamente los pods se despliegan y estan en demanda?

Kubernetes puede crear CronJobs y estos CronJobs pueden gestionar Pods.

Y de momento esas son todas las preguntas. Quedariamos con un modelo asi.

Con los siguientes componentes

Kubernetes como control room

Un container Repository, como repositorio de codigo

Un BotClient, compuesto por un Contenedor y un grupo de tecnologias

  • Ubuntu
  • Python
  • xfreerdp
  • RobotFramework
  • ScriptPersonalidad

CronJobs para agendar pods en el tiempo

Un Persistent Storage + Pod Base de datos: Para control del sistema, ejecucion y auditoria (por diseñar)

Un Pod webserver: Que permita hacer Hooks hacia nuestros pods en demanda.

En conclusion, seria factible con algo de trabajo manual y organizacion construir una solucion de rpa en casa, sin pago extra de licencias, y tratando de maximizar el consumo de equipos.

El proximo post del tema, hablare en detalle de las capacidades de Imagenes de Docker como Clientes de Bot.

Leave a comment

Your email address will not be published. Required fields are marked *