Uno de nuestros casos de éxito:
¿Cómo automatizamos la contabilización manual de los documentos tributarios electrónicos (dte’s) emitidos por nuestros clientes de los planes API?
Teníamos un equipo dentro de Bsale encargado de revisar uno por uno la cantidad de dte’s generados por cada cliente, para calcular a fin de mes la facturación de nuestros servicios.
Todo partió cuando nuestro equipo interno de Producto, compuesto por desarrolladores que buscan simplificar las tareas del día a día a través del uso de soluciones tecnológicas, recibió un requerimiento: reducir el tiempo de contabilización de documentos. Esteban, del área de Innovación, solía demorarse 3 horas en esta tarea donde ejecutaba un proceso manual que le devolvía la data, el cual hoy, con las mejoras que les vamos a contar, se demora tan solo unos segundos.
Primero, un poco de contexto…
La misión se adjudicó a nuestro equipo de Producto llamado Matrix Team, donde ya tenemos 7 años de experiencia y somos los responsables de la comunicación entre Bsale y las distintas entidades tributarias de los países donde estamos presentes. Existían varias complejidades, entre ellas, y una de las más importantes, era que NO nos servirían las tecnologías tradicionales para automatizar esta tarea, por el gigantesco volumen de información que debía ser procesada.
Nosotros (Manuel, Walter y Víctor) partimos con los primeros intentos: disponibilizando una interfaz que internamente hacía las llamadas necesarias a la API de documentos, lo que nos permitió obtener la data, pero la dificultad era que se saturaba con tantas peticiones ni tampoco soportaba la concurrencia.
Lo que hicimos para resolverlo fue guardar la data en caché. Ahora esa información se consulta desde la interfaz a Redis, y si no está, ahí recién se busca en la API, lo que disminuyó considerablemente la carga de peticiones, las cuales se demoraban 66 segundos para 316 solicitudes y actualmente se logran en 1.5 segundos.
¿Cuál fue la solución?
La verdad es que coincidimos en que fue un resultado de la suma de varias estrategias, destinadas a mejorar la arquitectura del flujo inicial, a través de la incorporación de nuevas tecnologías y funcionalidades como:
- Desarrollar una nueva API de documentos que fuera distinta a la original y que estuviera en otro lenguaje, así pasamos de usar Ruby a Go Lang.
- Ejecutar una tarea programada (Cron-job) en un horario de poca carga.
- Agregar Redis a la lógica, actualizando la información con la tarea programada.
Aquí aprendimos varias cosas y descubrimos incluso nuevas herramientas que no habíamos usado antes, por ejemplo, Postman Flows que nos ayudó a ver cómo pasaban los datos de los clientes mediante endpoints, para ver su fluidez y el tiempo que nos demorábamos.
¿Cómo fue el proceso?
Nos hemos dado cuenta de la importancia de ciertos pasos previos a la codificación que han sido útiles para nosotros, como:
- Enfocarnos en hacer una buena toma de los requerimientos, ya que hemos tenido mejores resultados pensando primero en la solución antes de la implementación.
- Destinar tiempo a crear diagramas del proceso para ver de forma gráfica el flujo, lo que ha facilitado nuestra comunicación, porque ya sabemos cómo funcionará y si hay errores. Esta vez diseñamos algo así:
A partir de varias iteraciones sobre el flujo pasamos luego a una etapa más práctica, donde:
- Nos dedicamos a construir las vistas e interfaces que en este caso eran dos: una para la gestión administrativa interna, y otra, para que nuestros usuarios externos pudiesen visualizar su información.
- Fuimos creando prototipos funcionales que nos ayudarán a minimizar los errores, como la saturación de nuestra API (que les comentamos en un comienzo), que solucionamos probando nuevas tecnologías capaces de procesar grandes volúmenes de información.
Equipo Matrix
Te invitamos a sumarte a nuestra comunidad en LinkedIn para conectar con nosotros y mantenete al tanto de nuestras últimas actualizaciones.
