Todo lo que necesitas para conectar el adapter de ultima milla al Core Service Bus y desplegarlo en
rtp-transversal-dev — arquitectura, payloads, webhooks, secrets y pipeline.
00
Como encaja el adapter
Clic en una caja para ver el detalle →
01
Conectar el CSB con el adapter
1
Registrar los endpoints en el seed del CSB
En rtp-csb (donde el CSB registre servicios externos),
agrega las rutas del adapter con el URL del Cloud Run como destino de Cloud Tasks.
rtp-csb — seed / config de destinations
// URL de Cloud Run (una vez desplegado)const DELIVERY_ADAPTER_URL = 'https://csb-delivery-adapter-XXXX-uc.a.run.app';
// Rutas que Cloud Tasks debe enviar al adapterconst destinations = {
delivery_create_order: `${DELIVERY_ADAPTER_URL}/delivery/create-order`,
delivery_track: `${DELIVERY_ADAPTER_URL}/delivery/track`,
delivery_cancel: `${DELIVERY_ADAPTER_URL}/delivery/cancel`,
};
2
Crear la Cloud Tasks queue apuntando al adapter
La queue necesita la service account del adapter como oidcToken.serviceAccountEmail
para que Cloud Tasks pueda llamar al Cloud Run con IAM.
A diferencia del ERP adapter (solo salida), el delivery adapter tiene un
flujo bidireccional: recibe tareas del CSB
y tambien recibe callbacks de Bringoz cuando el estado de una entrega cambia.
Bringoz
→
POST /webhooks/bringoz
WebhookEventDto
→
WebhooksService
→
PubSubService
delivery.completed.v1
→
CSB
Eventos de webhook soportados
eventType (Bringoz)
Status mapeado
Descripcion
order_accepted
accepted
Orden asignada a un repartidor
order_in_transit
pending
Repartidor en camino al destino
order_delivered
delivered
Entrega confirmada con evidencia
order_rejected
rejected
Orden rechazada por el proveedor
order_cancelled
cancelled
Orden cancelada
POST /webhooks/bringoz — WebhookEventDto (payload de Bringoz)
El endpoint /webhooks/bringoz debe ser accesible desde internet (Bringoz lo llama directamente).
Configurar un Cloud Run con --allow-unauthenticatedsolo para la ruta de webhooks,
o usar un API Gateway / Cloud Endpoints con validacion de firma de Bringoz.
03
Prerequisitos antes del primer deploy
Secrets en Secret Manager
Todos los secrets siguen el patron csb-{env}-{name}. Crealos en rtp-transversal-dev:
Secret
Variable de entorno
Descripcion
csb-dev-bringoz-host
BRINGOZ_HOST
URL base de la API Bringoz
csb-dev-bringoz-api-key
BRINGOZ_API_KEY
API Key para autenticacion
csb-dev-bringoz-tenant-id
BRINGOZ_TENANT_ID
Tenant ID del cliente en Bringoz
csb-dev-pubsub-result-topic
PUBSUB_RESULT_TOPIC
Topic para publicar resultados
csb-dev-delivery-provider
DELIVERY_PROVIDER
bringoz o nexus (default: bringoz)
!
Si se usa Nexus como provider alternativo, tambien se necesitan:
csb-dev-nexus-host, csb-dev-nexus-api-key,
csb-dev-nexus-client-id.
gcloud — crear secrets (shell loop)
# Crear cada secret (reemplaza VAL con el valor real)for name in bringoz-host bringoz-api-key bringoz-tenant-id \
pubsub-result-topic delivery-provider; doecho -n "VAL" | gcloud secrets create "csb-dev-$name" \
--data-file=- \
--project=rtp-transversal-dev
done
Permisos IAM minimos
Service Account
Rol
Para que
csb-delivery-adapter-sa
roles/secretmanager.secretAccessor
Leer secrets en runtime
csb-delivery-adapter-sa
roles/pubsub.publisher
Publicar resultados
csb-delivery-adapter-sa
roles/logging.logWriter
Escribir logs estructurados
csb-delivery-adapter-sa
roles/monitoring.metricWriter
Metricas de Cloud Monitoring
csb-cloudtasks-sa
roles/run.invoker
Cloud Tasks puede llamar al Cloud Run
04
Deploy manual a Cloud Run (primer deploy)
Para el primer deploy antes de tener el pipeline CI/CD conectado al
trigger.
1
Build y push de la imagen
El Dockerfile usa multi-stage build (3 etapas: deps, builder, runner)
con usuario no-root csb y healthcheck incluido.
Solo para el primer arranque manual. El servicio que gobierna Terraform se llama
csb-delivery-adapter-<env>-api (p. ej. csb-delivery-adapter-dev-api):
un deploy con otro nombre crea un servicio aparte que el pipeline no actualiza.
El directorio infra/terraform/ esta creado con 4 modulos y 3 ambientes.
El pipeline de Cloud Build ejecuta terraform init → plan → apply automaticamente.
Modulos
Modulo
Recursos
Descripcion
compute
Cloud Run, Service Account, IAM
Servicio principal con probes, VPC access, secret injection via value_source
networking
VPC, Subnet, Router, NAT, VPC Connector
Red privada con private_ip_google_access y egress NAT
secrets
Secret Manager secrets + IAM
Secrets csb-{env}-* con acceso para la SA de Cloud Run
Crear secrets en Secret Manager (csb-dev-bringoz-*)
pendiente
2
Crear service accounts y permisos IAM
pendiente
3
Crear Artifact Registry repo csb-adapters (compartido con erp-adapter)
pendiente
4
Crear directorio infra/terraform/ con modulos
listo
5
Crear cloudbuild.yaml
listo
6
Crear Dockerfile (multi-stage, non-root)
listo
7
Obtener spec de API de Bringoz
pendiente
8
Implementar llamadas reales en BringozProvider
pendiente
9
Deploy manual (seccion 04) para validar imagen
pendiente
10
Registrar URL del Cloud Run en seed del CSB
pendiente
11
Crear Cloud Tasks queue
pendiente
12
Crear suscripcion Pub/Sub en CSB
pendiente
13
Configurar webhook URL en panel de Bringoz
pendiente
14
Smoke test E2E (seccion 08)
pendiente
✓
27 tests pasando en rama dev (23 unit + 4 e2e).
Codigo scaffolding completo con 6 modulos, infra Terraform (4 modulos, 3 ambientes), Dockerfile multi-stage y
pipeline CI/CD.
Lo pendiente es obtener la spec de Bringoz para implementar las llamadas reales en los providers,
y la configuracion GCP (secrets, IAM, Cloud Build trigger).
⚠
Bloqueante: Los providers (BringozProvider, NexusProvider)
tienen implementaciones stub (retornan datos ficticios). Se necesita la spec de la API de Bringoz
para implementar las llamadas HTTP reales con autenticacion X-API-Key + X-Tenant-ID.