La fecha límite de entrega del proyecto es el 7 de marzo de 2022 a las 11:59 PM Hora Colombia (GMT-5).

Siga las instrucciones a continuación para crear los entregables que serán calificados en el proceso de evaluación.

Prerrequisitos

Para cumplir con las actividades del proyecto es necesario que cuente con ciertas herramientas instaladas en su máquina personal.

• Postman (https://www.postman.com/)
• Git (https://git-scm.com/). No olvide configurar su usuario de git para que las entregas estén marcadas con este.
• Python 3.9 (https://www.python.org/)
• IDE de su elección. Puede definirlo con su equipo de trabajo.
• Docker https://www.docker.com/
• gcloud sdk https://cloud.google.com/sdk/docs/install

Objetivos

• Aplicar los conceptos de arquitecturas serverless vistos en el curso en la solución de un problema concreto.
• Utilizar los servicios serverless de un proveedor en la nube para aplicar los patrones y conceptos vistos en el curso.
• Aplicar patrones de arquitecturas dirigidas por eventos en la solución de un problema concreto.

En esta entrega se requiere implementar el soporte al proceso que ocurre luego de la compra de uno de los bienes solicitados por el cliente.

En el proceso participan 4 actores:

• Proveedor de pagos: Tiene la responsabilidad de procesar solicitudes de pago que se hacen desde la Aplicación a través del uso de un API basado en webhooks. Su participación es completamente automática.
• Aplicación: Es la aplicación que hemos estado construyendo desde el entregable 1. Interactú a automáticamente con todos los otros actores.
• Proveedor de envíos: Tiene la responsabilidad de procesar solicitudes de envío que se hacen desde la aplicación a través de un API definido. Su participación es completamente automática.
• Vendedor: Es uno de los clientes del sistema que tiene por objetivo la venta de bienes dentro de la aplicación. Su participación es manual e interactúa con la Aplicación a través de una terminal de cliente que interactúa con los APIs del sistema.

El proceso funciona de la siguiente manera:

1. Al completar la transacción en la pasarela de pagos, el procesador de transacciones notifica el resultado mediante el llamado a un webhook expuesto para tal propósito.
2. Una vez se ha procesado el pago de la compra por parte del cliente, si el pago fue exitoso, se debe enviar una notificación al vendedor indicando el estado del pedido.
3. El vendedor debe iniciar la gestión de la orden de compra e indicarle al cliente una fecha tentativa de finalización de la fabricación. Esta fecha debe ser enviada al cliente a través de una notificación.

4. Al finalizar la fabricación, el vendedor debe actualizar el estado de la orden a "Lista para despacho". El sistema se integra con el proveedor de mensajería para solicitar la recolección del paquete.

5. Una vez el proveedor de mensajería hace el agendamiento, este notifica mediante el consumo de un webhook que se debe exponer. Se debe notificar al cliente y al vendedor la fecha tentativa de entrega. El proveedor de mensajería hace el agendamiento por lotes, de manera que se espera que cada que termina una planeación de ruta, llame simultáneamente para varios pedidos el endpoint de notificación.

6. El proveedor nos notificará a través del webhook el estado del envío. Una vez llegue al estado de "Entregado", se debe notificar al cliente e iniciar el proceso de facturación. Estas notificaciones del proveedor se hacen individualmente para cada pedido en proceso de entrega.

7. El proceso de facturación consiste en generar la factura de servicios al vendedor y notificar a este cuando se encuentre disponible. El documento debe ser generado con la fecha en la que se hizo la entrega por asuntos regulatorios.

Para esta entrega del proyecto debe hacer un diseño asíncrono y orientado a eventos para este proceso. Debe utilizar las estrategias y patrones vistos durante las semanas 5 y 6 para la solución del problema.

Para esta entrega del proyecto usted debe realizar un diseño de componentes que permita soportar el proceso descrito en el enunciado. Para lograrlo debe tener en cuenta las siguientes consideraciones:

• Se debe tener la capacidad de procesar 1 millón de transacciones exitosas por mes.
• La orquestación de la lógica de negocio debe ser asíncrona y dirigida por eventos.
• La composición de servicios/funciones puede ser síncrona o asíncrona, sin embargo debe estar justificada en el diseño.
• No debe validarse autenticación ni autorización de los llamados hechos a los webhooks.
• La especificación de los APIs de proveedores no incluye parámetros de seguridad, por lo tanto no deben tenerse en cuenta.
• Tanto el monolito como los microservicios disponibles en la aplicación deberán ser utilizados para ser integrados. Si bien no vamos a extender el monolito, se deberá desplegar para hacer las pruebas correspondientes, al igual que en la segunda entrega.

Para la integración de los servicios necesarios para el proceso de negocio es mandatorio implementar puntos de conexión con un tercero. El curso cuenta con endpoints de prueba que pueden ser utilizados para probar esta integración. Su tarea incluye la implementación de estas integraciones.

Las integraciones se dividen en dos:

Webhooks

Son los endpoints que usted debe exponer para que un tercero consuma. Estos endpoints deberán cumplir con una especificación y deberán ser consumidos a través de Postman para las pruebas del proceso.

En el siguiente vínculo encuentra un archivo OpenAPI que se puede visualizar con swagger y que contiene la especificación de los endpoints que debe exponer.

Swagger webhooks

APIs de proveedores

endpoints que deben ser consumidos desde la aplicación para el envío de correos, agendamiento de envíos y generación de facturas. Cada endpoint debe estar integrado y debe ser llamado según el diagrama del proceso presentado en el enunciado.

En el siguiente vínculo encuentra un archivo OpenAPI que se puede visualizar con swagger y que contiene la especificación de los endpoints del API que debe integrar:

Swagger endpoints

A continuación encuentra unas generalidades que debe tener en cuenta en la integración de estos APIs.

APIs de facturación

Contiene dos endpoints que deben ser integrados.

El primer endpoint permite iniciar el proceso de creación de una factura para una venta dado su identificador. Este proceso se hace en background y el endpoint retorna el id del proceso de creación de la factura.

El segundo endpoint recibe el identificador retornado por el primer endpoint y sirve el archivo. Existe la particularidad de que el endpoint retorna 500 cuando el proceso de facturación no ha sido completado. Debe tener en cuenta este comportamiento en la integración.

API de mensajería y entrega de paquetes

Contiene un endpoint que permite solicitar el agendamiento del envío. El agendamiento se realiza en background y es completado mediante el llamado del webhook expuesto para tal fin.

El endpoint de solicitud de agendamiento tiene una tasa de errores bastante alta. Ante un fallo, se debe reintentar la solicitud en unos segundos. Las solicitudes se deben reintentar hasta obtener una respuesta exitosa.

Con el id retornado por este endpoint, se realiza el llamado al webhook de mensajería cuando la solicitud de entrega cambia de estado. Los cambios de estado están detallados en el swagger asociado a ese webhook.

API de notificaciones

Contiene un endpoint para el envío de notificaciones a un dispositivo. El envío de notificaciones se basa en templates definidos del lado del proveedor. Cada template tiene un id que debe ser enviado a este endpoint para que el proveedor pueda construir la notificación con la información entregada en el objeto de extras.

Para esta entrega, usted deberá exponer los APIs que desarrolle a través de un API Gateway que resuelva las rutas hacia las funciones y/o componentes que desarrolle.

En el gateway y en su solución debe exponer suficientes endpoints para al menos cubrir los siguientes punto de integración con la aplicación de cliente:

• Notificar la fecha estimada de finalización de fabricación del producto. Esto se puede ver en la parte 3 del proceso.
• Notificar la finalización de la fabricación del producto. Esto se puede ver en la parte 4 del proceso.

Ambos endpoint deberán recibir el token de sesión y validarlo contra el API de sesiones disponible en el monolito desde la entrega 1 del proyecto.

Servicios actuales

Otro equipo de desarrollo ha estado construyendo un conjunto de microservicios que responden a algunas entidades del negocio y que usted debe aprovechar para cumplir con estos requerimientos.

Las imágenes ya se encuentran en un registro de contenedores y la documentación de su funcionamiento, así como los archivos de despliegue se encuentran en el siguiente enlace.

repositorio

Se recomienda primero leer la documentación descrita en el archivo README del proyecto, realizar el despliegue de cada uno en su infraestructura y probar que su funcionamiento sea correcto.

55 puntos

Como parte de la solución, debe realizar un documento de arquitectura y diseño en el que haga un levantamiento de la información del problema, proponga una solución y explique los racionales detrás de las decisiones de diseño tomadas.

Responda las preguntas orientadoras que aparecen a continuación y utilice el formato de Diseño y arquitectura para completar el entregable.

• 20 puntos: Haga un diagrama de componentes en el que se vea cómo los microservicios/funciones propuestos interactúan con los otros componentes del sistema para resolver el problema planteado por el enunciado. Adicionalmente, cada componente debe estar listado con la siguiente información:

• 15 puntos: Haga un diseño de cada microservicio/función propuesto para la solución. Debe utilizar la tabla a continuación para documentar los patrones de diseño utilizados:

• 20 puntos: Para cada comunicación o relación que ocurra entre componentes documente los siguientes elementos

Evaluación

Los siguientes criterios se tendrán en cuenta en el proceso de evaluación y validación de este entregable:

• Completitud funcional: Se evaluará que el diseño propuesta resuelva funcionalmente la problemática planteada en el enunciado. Deben haber componentes suficientes para cada uno de los puntos de interacción del sistema y en su conjunto deben dar soporte al caso de negocio presentado en el enunciado.
• Justificación: Se evaluará que cada decisión de diseño relacionada con los patrones y temas vistos en la semana esté presente y sea correcta.
• Efectividad: Se evaluará que el diseño presentado resuelva las necesidades no funcionales planteadas por negocio y que las decisiones de diseño tomadas cumplan con ese objetivo.

30 puntos

Basado en el diseño del entregable I, debe realizar una implementación funcional de los componentes incluidos en el diseño. Para la implementación de los componentes tenga en cuenta los siguientes lineamientos:

• Utilice un solo repositorio de GitHub para almacenar el código fuente de todos los componentes. En el curso de DevOps se verán buenas prácticas sobre la forma de almacenar y gestionar el ciclo de vida del código.
• Incluya un README.md en la carpeta de cada subcomponente. En este incluya al menos los siguientes elementos: El identificador del componente según el entregable 1, el nombre del componente y las instrucciones que usó para desplegar el componente vía gcloud.
• Debe incluir el archivo de OpenAPI utilizado para desplegar el API en el API gateway.

Evaluación

Los siguientes criterios se tendrán en cuenta en el proceso de evaluación y validación de este entregable:

• [15 puntos] Completitud y exactitud respecto al diseño: Se verificará que la solución entregada contenga la implementación de las decisiones de diseño planteadas en el Entregable I.
• [10 puntos] Solución del problema: Se verificará la correspondencia entre la solución entregada y el problema planteado en el enunciado. El código fuente entregado debe exponer endpoints y ejecutar lógica de negocio que dé soporte al proceso planteado.
• [4 puntos] Calidad de código: Se evaluará que el código esté bien documentado y que sea fácil de leer. Trate de agregar comentarios a los archivos, funciones y definiciones que permitan entender su propósito y responsabilidad.
• [1 puntos] Adicionales: Se entrega el archivo de postman que puede ser utilizado para probar los servicios en producción.

15 puntos

Debe realizar un video en el que muestre lo siguiente:

• Los componentes desplegados en la consola de GCP.
• Una prueba del proceso de post compra hecha con postman.

El video no debe tener una duración superior a los 20 minutos.

Evaluación

Los siguientes criterios se tendrán en cuenta en el proceso de evaluación y validación de este entregable:

• [5 puntos] Componentes desplegados: En el video se evidencia el despliegue de los componentes diseñados en el Entregable I. Se deben ver en las listas de recursos de la consola del proveedor.
• [10 puntos] Prueba de funcionalidad: Se muestra el sistema funcionando según el problema planteado en el enunciado y el diseño entregado en el entregable I. El archivo de postman con el que se exhibe y prueba la funcionalidad corresponde al entregado en el Entregable II.

Esta sección contiene la información de los cambios que se han realizado a este enunciado desde su publicación.