Files
pruebas-automatizacion-desa…/README.md
Alvar San Martin fdd1de37d7 Los precios ahora son coherentes
El precio segun divisas corresponde con el total, la divisa del SET es
la del origen siempre
2026-01-02 11:42:37 +01:00

3.5 KiB

Proyecto de automatizacion de desarrollo

Tiene como objetivo levantar un servidor de Webhooks para servir al desarrollo de shopify de forma local.

Componentes:

  • Servidor de webhooks que emite peticiones
  • Cliente (servidor express) que escucha al servidor para desarrollo

Objetivos:

  • Generar eventos por API REST
  • Subscripción a topics por API REST
  • Documentación de la API REST con Bruno
  • Firma de mesajes con HMAC sha256
  • Generar eventos periodicos
  • Generar ordenes de shopify proceduralmente
  • Generar ciclos de vida realistas create -> update -> delete
  • Dockerizar
  • Añadir clientes iniciales

Webhooks Soportados:

  • orders/create
  • orders/update
  • orders/delete

Propuestas:

Requisitos

  • Docker (linux) o Docker desktop (widows - WSL)
  • Ubuntu 24 o similar
  • Terminal bash, zsh, sh o compatible

Introduccion

El objetivo es tener un grupo compose con

  • Una BDD para almacenar ejemplos
  • Un servicio que envie peticiones periodicamente

Docker

Este grupo tiene definida una red externa en el docker-compose.yaml que tiene que coincidir con la red de los demás compose ejecutados, por ejemplo:

# Esto tiene que aparecer en el yaml del simulador
name: p-simulador-webhooks
networks:
  default:
    name: network-test # Tiene que coincidir con el compose objetivo
    external: true
# Esto en el yaml del microservicio
name: sf-shopify-orders
networks:
  default:
    name: network-test

Ejecución

Para lanzar los contenedores se ejecuta el script run.local.sh que va a lanzar el compose de la carpeta /development/local. Habrá que ver para los demás entornos.

Configuración de envío periódico de webhooks

La configuración de los webhooks se hace en /src/config/initial_hosts.ts.

En la constante INITIAL_EVENTS están los eventos que se van a emitir periodicamente. Tienen la estructura:

export type ScheduledEvent = {
  topic: string;
  numberOfMessages?: number;
  periodMs?: number;
};

Un ejemplo sería:

{
    topic: "order/create", // Emite mensajes de tipo order/create
    numberOfMessages: -1, // Un numero negativo o indefinido de mensajes, indica que se mandan ilimintados
    periodMs: 5000 // 5s entre mensajes, si fuese indefinido el predefinido es 1s
}

El periodo indica el mínimo entre mensajes, puede pasar mas tiempo si la maquina se realentiza o si el event loop queda bloqueado.

Configuración de los host que reciben webhooks

Para añadir un host nuevo se crea un nuevo objeto en la constante INTIAL_HOSTS tal que:

type InitialHost = {
  topic: string;
  host: string;
  port: string;
  endpoint: string;
  method: "POST" | "PUT" | "DELETE";
  secretkey: string;
};

Por ejemplo si corremos el servicio en un contenedor llamado cliente-webhooks se tiene que añadir un objeto:

{
    topic: "order/create",
    host: "localhost",
    port: "3500",
    endpoint: "/order/create",
    method: "POST",
    secretkey: webhooksConfig.apiSecret || "1234",
}

Esta configuración implica que ese host va recibir una petición HTTP cada vez que se emite un mensaje con el topic order/create, se va a enviar al puerto 3500 y al endpoint order/create mediante el método POST. Tiene un campo "opcional" para la clave para la firma HMAC, si se quiere usar tiene que coincidir en el cliente y el servidor, la clave del servidor se puede guardar en el .env o directamente en el objeto NO SE DEBEN USAR CLAVES REALES DE PRODUCCIÓN, con poner "1234" en los dos servicios la firma ya se hace correctamente.