Introducción

Contexto SPIN

SPIN by OXXO nace y crece de manera acelerada. Entre los diversos retos que tiene en su evolución del producto y mejorar la experiencia de sus usuarios, hoy su proceso de autorización de transacciones interbancarias o inter usuarios es validada con un código de seguridad.

Buscan mejorar la experiencia que se tiene con el código de seguridad por dos razones principales: ​

• Incrementar la seguridad migrando del código de seguridad a un token digital​

• Mitigar la problemática existente de bloqueo de transacciones por olvido de código de seguridad y no contar con un proceso de reseteo del mismo.​

Objetivo general

Construir, en una primera fase, el desarrollo del motor generador de un token y, en una fase posterior, integrarlo con las pantallas del nuevo flujo para el front-end para autorización de transacciones vía el token digital para:​

• usuarios nuevos, en su onboarding habilitar su token​

• usuarios existentes, hacer su reemplazo de código de seguridad por token​

• usuarios hoy con código de seguridad bloqueado, resetear y habilitar su token​

Índice

Propuesta de solución

Una vez iniciado el proyecto, el equipo comenzó a analizar y diseñar las bases en las que estaríamos trabajando y lograr el objetivo principal. Para ello, dedicamos tiempo en entender la solución enconjunto con el equipo involucrado en SPIN principalmente.

Se identificaron los siguientes componentes a desarrollar en el tiempo:

Marco tecnológico

Protocolo gRPC

En gRPC, una aplicación cliente puede llamar directamente a un método en una aplicación de servidor en una máquina diferente como si fuera un objeto local, lo que facilita la creación de aplicaciones y servicios distribuidos. Como en muchos sistemas RPC, gRPC se basa en la idea de definir un servicio, especificando los métodos que se pueden llamar de forma remota con sus parámetros y tipos de devolución. En el lado del servidor, el servidor implementa esta interfaz y ejecuta un servidor gRPC para manejar las llamadas de los clientes. En el lado del cliente, el cliente tiene un stub (denominado simplemente cliente en algunos idiomas) que proporciona los mismos métodos que el servidor.

Los clientes y servidores de gRPC pueden ejecutarse y comunicarse entre sí en una variedad de entornos, desde servidores dentro de Google hasta su propio escritorio, y pueden escribirse en cualquiera de los lenguajes compatibles con gRPC. Entonces, por ejemplo, puede crear fácilmente un servidor gRPC en Java con clientes en Go, Python o Ruby. Además, las últimas API de Google tendrán versiones gRPC de sus interfaces, lo que le permitirá incorporar fácilmente la funcionalidad de Google en sus aplicaciones.

¿Por qué querría usar gRPC?
Los principales escenarios de uso:

• Sistemas distribuidos de baja latencia y altamente escalables.

• Desarrollo de clientes móviles que se comunican con un servidor en la nube.

• Diseñar un nuevo protocolo que debe ser preciso, eficiente e independiente del idioma.

• Diseño en capas para permitir la extensión, por ejemplo. autenticación, balanceo de carga, registro y monitoreo, etc.

¿Quién está usando esto y por qué?
gRPC es una base de computación nativa en la nube(Proyecto CNCF).

Google ha estado usando muchas de las tecnologías y conceptos subyacentes en gRPC durante mucho tiempo. La implementación actual se está utilizando en varios de los productos en la nube de Google y en las API externas de Google. También está siendo utilizado por Square, netflix, CoreOS, ventana acoplable, CucarachaDB, cisco, Redes de enebroy muchas otras organizaciones e individuos e incluso en el sector fianciero y bancario.

Fuente: https://grpc.io/docs/what-is-grpc/introduction/

Protocolo REST

¿Qué es REST?
La transferencia de estado representacional (REST) es una arquitectura de software que impone condiciones sobre cómo debe funcionar una API. En un principio, REST se creó como una guía para administrar la comunicación en una red compleja como Internet. Es posible utilizar una arquitectura basada en REST para admitir comunicaciones confiables y de alto rendimiento a escala. Puede implementarla y modificarla fácilmente, lo que brinda visibilidad y portabilidad entre plataformas a cualquier sistema de API.

Los desarrolladores de API pueden diseñar API por medio de varias arquitecturas diferentes. Las API que siguen el estilo arquitectónico de REST se llaman API REST.

Fuente: https://aws.amazon.com/es/what-is/restful-api/#:~:text=La API RESTful es una,llevar a cabo varias tareas.

Pruebas automatizadas con Rest Assured

REST Assured es un DSL de Java para simplificar las pruebas de servicios basados ​​en REST construidos sobre HTTP Builder. Admite solicitudes POST, GET, PUT, DELETE, OPTIONS, PATCH y HEAD y se puede utilizar para validar y verificar la respuesta de estas solicitudes.

Fuente: https://github.com/rest-assured/rest-assured/wiki/Usage

K6

Entregables

A continuación, enlistaremos los entregables comprometidos para este proyecto y la documentación que dejamos como referencia para dar contexto e incluso la continuidad de la siguiente fase de implementación en los procesos que así lo considere SPIN.

Lo que podrán encontrar son los diseños de arquitectura, códigos fuente, documentación específica entre otros.

Token Digital

El Token Digital está compuesto de los siguientes componentes, los cuales se conectan al servicio de agregación que es el que se expone para ser consumido de acuerdo con los intereses que así lo considere SPIN.

A continuación dejamos el diagrama de arquitectura que muestra la conexión entre componentes que brinda nuestra solución:

El detalle de los componentes los encontrarán en las siguientes URLs:

Otros flujos

Estrategia y ejecución de pruebas

Plan de estrategia

Para lograr los resultados esperados y considerar casos positivos y negativos se realizó una estrategia de pruebas para garantizar el uso correcto del framework de QA que se tiene en SPIN, nuestros desarrollos llegarán hasta staging, por lo que garantizar que funcione de acuerdo con lo diseñado, es de suma importancia para este proyecto.

Consulta el detalle del Plan de estrategia: Estrategia de Pruebas - Spin - Token Digital

Casos de prueba

Consulta el detalle de los casos de prueba: Casos de Pruebas

Automatización de pruebas

Consulta el detalle de la automatización de pruebas:

Rest Assured

Performance K6

Ejecución de pruebas

Consulta el detalle de la ejecución de pruebas: Ejecuciones de Pruebas QA

Entregas parciales por sprint

Nuestro proyecto fue planetado realizarse en un tipo de 12 sprints dividios en sprint de 2 semanas cada uno, con el objetivo de entregar valor a través del trabajo comprometido en el equipo.

Es por ello que, en elsiguiente link encontrarán los objetivos comprometidos y los entregables que evidencian nuestras entregas parciales e incrementales: Sprint Review - Entregables

Asimismo, se realizaron 2 revisiones de avances para dar seguimiento estratégico a los principales stakeholders y sponsors del proyecto.

Documentación adicional

Transferencia de conocimiento (KT)

Con la finalidad de garantizar el éxito de la entrega de los compromisos de este proyecto, compartimos el material que se trabajó en nuestro periodo de transferencia de conocimiento con el propósito de mostrar el resultado de lo trabajado.

¿Qué se va a transferir del proyecto?​

• ​Demo funcional E2E de los componentes desarrollados.​

• Contexto y ecosistema técnico de los microservicios desarrollados.​

• Documentación soporte (diagramas, pruebas realizadas, informe/reporte final/resumen, material de capacitación, etc.) que concierne al proyecto

Dinámica

• Se realizaron sesiones previamente programadas, durante 6 días y se invitaron a todo aquel que tuviera interes directo o indirecto en el desarrollo del Token Digital.

• Sesiones de 1h a 2h

• Síncronas con material de grabación post sesión

• Herramienta: Teams

Sesiones

Como resultado, les dejamos el material visto en formato PDF, la grabación de la sesión y la lista de asistencia por cada día.

Dificultades encontradas

Conclusiones generales

PALO-461 - Getting issue details... STATUS