ADR / 001

Crear el cliente en el ERP de forma asíncrona

Proteger el flujo comercial de la latencia del ERP, con el estado pendiente y la recuperación explícitos.

Escenario ficticio

Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.

01Contexto

Una organización B2B global exige validación financiera en el ERP antes del primer pedido, pero la aprobación del cliente en el CRM debe seguir siendo utilizable durante el mantenimiento del ERP o con latencia regional.

02Factores de decisión

  1. F01

    Ninguna creación duplicada por error tras un timeout

  2. F02

    Los usuarios comerciales necesitan un estado comprensible

  3. F03

    El ERP sigue siendo la referencia del ID legal del cliente

  4. F04

    Operaciones necesita reprocesamiento y trazabilidad

03Opciones consideradas

Descartada

API síncrona

Flujos inmediatos y de bajo volumen

Coste: Acopla la experiencia de usuario a la disponibilidad del ERP
Elegida

Comando asíncrono gestionado

Latencia variable y operaciones recuperables

Coste: Exige un estado pendiente explícito
Descartada

Batch nocturno

Altas masivas sin urgencia

Coste: Mala visibilidad del proceso

04Decisión

Publicar un comando idempotente CustomerCreationRequested tras la aprobación. La capa de integración valida, envía al ERP, persiste el estado de correlación y devuelve eventos de resultado al CRM.

05Consecuencias

  • El CRM muestra los estados Pendiente, Creado y Requiere intervención.
  • Soporte es responsable de una cola de reprocesamiento con códigos de motivo; los usuarios nunca repiten la creación a ciegas.
  • La entrada de pedidos posterior queda condicionada al identificador canónico del ERP.

06Cuándo revisarla

01

El ERP ofrece un endpoint idempotente de alta disponibilidad con tiempos de respuesta deterministas.

02

El negocio acepta que la aprobación y la creación legal pasen a ser una única acción atómica del usuario.

07Dónde se aplica esta decisión

Casos que adoptan esta decisión, y por qué importa en cada uno.

  1. Caso de arquitectura / 001Diseñar el ciclo de vida del cliente entre CRM y ERPUna arquitectura basada en premisas para una empresa B2B global ficticia: de la intención comercial a un cliente legalmente válido y operativamente recuperable.Arquitectura de Sistemas y CRMDatos e IntegracionesArquitectura de ProcesosEscenario ficticio · 18 min
  2. Caso de sistemas / 05La identidad del cliente entre CRM y ERPSeparar la identidad comercial, la legal y la transaccional, y gobernar cómo se mapean, se fusionan y se retiran entre el CRM y el ERP.Arquitectura de Sistemas y CRMDatos e IntegracionesArquitectura de ProcesosEscenario ficticio · 9 min