/

ERP integration.

Tu ERP detrás de APIs reutilizables. Sin que cada proyecto pase por SAP.

SAP, Oracle, NetSuite o Dynamics expuestos detrás de System APIs estables. Cada nuevo canal, cada agente, cada partner consume las mismas APIs gobernadas en lugar de pedir desarrollos puntuales al equipo del ERP. Process APIs orquestan los procesos cross-módulo: order fulfillment, customer onboarding, 3-way match, cierre de mes.

Volver a MuleSoft
ERP

¿Qué resuelve ERP integration con MuleSoft?

Cada proyecto digital nuevo (canal, app, agente, partner) suele terminar pidiendo desarrollo al equipo del ERP, que se vuelve cuello de botella y dueño de un backlog que no escala. MuleSoft abstrae el ERP detrás de System APIs estables alineadas al lenguaje de negocio. El ERP queda libre de cada nuevo consumer y la organización gana velocidad para lanzar canales sin romper el core.

  • System APIs estables sobre módulos del ERP (FI, MM, SD, PP, HR).
  • Process APIs orquestan procesos cross-módulo del negocio.
  • Idempotencia y compensación para writes críticos.
  • Bulk loaders y CDC para integración con data warehouse.

Sistemas típicos involucrados

Las familias que conviven en un proyecto serio de ERP integration.

ERP

SAP S/4HANA, SAP ECC, Oracle EBS, Oracle Fusion Cloud, NetSuite, Microsoft Dynamics 365 (Finance & Operations, Business Central).

CRM

Salesforce Sales Cloud y Service Cloud como consumer principal de datos de cliente, crédito y órdenes.

E-commerce y front

Vtex, Magento, Salesforce Commerce, Shopify Plus cuando el ERP alimenta canales digitales con stock, precio y catálogo.

Data Warehouse

Snowflake, BigQuery, Redshift como sink de bulk loads y CDC para reporting y modelos analíticos.

Arquitectura objetivo

Una API por dominio del ERP, no una API gigante. Process APIs orquestan los procesos del negocio.

                       +------------------------+
                       |   Process / Experience |
                       |          APIs          |
                       +-----------+------------+
                                   |
              +--------------------+-----------------------+
              |                    |                       |
              v                    v                       v
+--------------------+  +-------------------+  +---------------------+
| sap-finance-sapi   |  | sap-mm-sapi       |  | sap-sd-sapi         |
| (FI: invoices,     |  | (materials,       |  | (orders, deliveries)|
|  ledger, GL)       |  |  inventory)       |  |                     |
+---------+----------+  +---------+---------+  +----------+----------+
          |                       |                        |
          +-----------+-----------+------------+-----------+
                      |                        |
                      v                        v
              +---------------+        +-----------------+
              |  SAP / Oracle |        |  Anypoint        |
              |  NetSuite /   |        |  Connector       |
              |  Dynamics     |        |                  |
              +---------------+        +-----------------+

System APIs

Una API por dominio del ERP: sap-finance-sapi, sap-mm-sapi, sap-sd-sapi, o el equivalente en Oracle EBS, NetSuite y Dynamics. Contratos limpios alineados al negocio, no al BAPI o al objeto técnico.

Process APIs

order-fulfillment-pa orquesta sales + materials + finance. customer-onboarding-pa orquesta creación de cuenta deudora y master data. month-end-close-pa orquesta procesos batch del cierre.

Experience APIs

mobile-erp-eapi para fuerzas de venta que consultan stock y crean pedidos desde el celular. partner-portal-eapi para distribuidores. bi-feed-eapi para feeds al data warehouse.

Flujo paso a paso

Creación de orden de venta desde el CRM hasta la confirmación en el ERP.

  1. 1 Salesforce dispara un Platform Event cuando una oportunidad pasa a Closed Won. MuleSoft captura el evento vía Salesforce Connector.
  2. 2 La Process API order-fulfillment-pa recibe el evento y lo enruta al flujo de creación de orden.
  3. 3 La Process API consulta sap-finance-sapi para verificar crédito disponible del cliente. Si el crédito es insuficiente, publica order.creditrejected.v1 y notifica al CRM.
  4. 4 Si el crédito es OK, llama a sap-mm-sapi para reservar stock de cada producto. Si no hay stock suficiente, bifurca lógica (backorder, parcial, rechazo) según las reglas del negocio.
  5. 5 Llama a sap-sd-sapi POST /sales-orders con el payload completo. El ERP responde con el número de orden de venta.
  6. 6 Actualiza el CRM con el SAP Order Number en el campo correspondiente del Opportunity, cerrando el loop hacia el comercial.
  7. 7 Publica el evento order.created.v1 en Anypoint MQ. Consumers: data warehouse para snapshot, email service para confirmación, WMS para preparación.
  8. 8 Si en cualquier paso falla, ejecuta saga compensatoria: si reservó stock pero falla la creación del SO, libera stock; si creó SO pero falla el update CRM, agenda retry.
  9. 9 Cada llamada al ERP queda registrada con idempotency key (el ID de Opportunity) para que un re-emit del evento no duplique la orden.
  10. 10 El throttle por adapter mantiene el ERP debajo de su umbral seguro acordado con el equipo Basis o el equipo del ERP del cliente.

Patterns aplicados

Los patrones que sostienen la integración del ERP en producción.

Idempotency keys

El ID de la oportunidad o del request actúa como clave única, evitando duplicados cuando el publisher reemite el mismo evento.

Saga / compensación

Para flujos cross-módulo (crédito, stock, sales order), cada paso tiene su contraparte de rollback bien definida.

Bulk processing

IDOC en SAP, bulk endpoints en NetSuite y Dynamics para cargas masivas en lugar de uno por uno.

Cache aside

Vista materializada para consultas frecuentes (stock por familia, lista de precios) que descargan al ERP.

Event-carried state transfer

Cambios de precio o catálogo se publican como eventos versionados que cada consumer aplica a su ritmo.

Retry con backoff

Para locks de tabla y ventanas de mantenimiento, retry exponencial con tope antes de mover el mensaje a la cola de error.

Cómo lo implementamos

Cinco fases coordinadas con el equipo del ERP del cliente, sin big bang.

1
Discover · 1-3 semanas

Inventario de módulos y procesos

Mapeo de módulos del ERP en uso (FI, MM, SD, PP, HR), inventario de personalizaciones, identificación de quick wins. Entregables: assessment, lista de System APIs candidatas, business case.

2
Design · 2-4 semanas

Contratos por dominio de negocio

Diseño API-Led: una System API por módulo o dominio, contratos OAS/RAML alineados al lenguaje de negocio (no al BAPI), modelo canónico, plan de gobernanza y seguridad.

3
Build · 6-12 semanas

Construcción y throttling

Implementación de System APIs sap-finance, sap-mm, sap-sd o equivalentes en Oracle/NetSuite/Dynamics. Process APIs para procesos cross-módulo. Tests MUnit, throttle configurable, CI/CD a sandbox.

4
Deploy · 2-4 semanas

Hardening y go-live coordinado

Hardening, security review, load testing acordado con el equipo Basis, configuración de monitoring, runbooks. Go-live por dominio: primero finanzas, luego materiales, luego ventas. Hypercare.

5
Evolve · continuo

Reutilización y CoE

Cada nuevo proyecto digital reusa las System APIs existentes en lugar de pedir desarrollo al equipo del ERP. Managed services, capacitación, gobernanza desde el Center of Excellence.

Requisitos del proyecto

Lo que tiene que estar disponible del lado del cliente para arrancar.

Datos mínimos

Acceso técnico al ERP (usuario RFC en SAP, credenciales de Oracle Integration Cloud, SuiteTalk o REST en NetSuite, Data Entities en Dynamics). Lista de BAPIs o endpoints en uso.

Licencias y capacidades

Anypoint Platform, SAP Connector u Oracle / NetSuite / Dynamics Connectors según el caso, AsyncAPI o módulo de eventos cuando se publican cambios al ecosistema.

Integraciones típicas

CRM (Salesforce), e-commerce y front digital, WMS / TMS, data warehouse, sistemas de partners B2B y portales de distribuidores.

Pre-requisitos organizacionales

IT lead disponible, equipo Basis o equivalente del ERP comprometido para acordar throttle y ventanas, sponsor del proceso de negocio (típicamente CFO, COO o supply chain).

KPIs operativos

Las métricas que típicamente mejoran tras implementar la capa de integración del ERP.

KPIQué midePor qué importa
BAPI / endpoint call P95 latencyLatencia P95 de cada operación contra el ERP, separada por dominio.Detecta degradación temprana en SAP, Oracle, NetSuite o Dynamics antes de que el negocio lo sienta.
Bulk load durationTiempo total de procesos batch (catálogos, masas de pedidos, conciliaciones).Define la ventana operativa disponible y el cumplimiento del cierre nocturno.
Lock / retry countCantidad de locks en tabla y reintentos por colisión.Identifica cuellos de botella estructurales del ERP que requieren throttle o reordenamiento.
Transaction failure ratePorcentaje de transacciones que requieren intervención manual.Costo operacional del proceso, especialmente en order-to-cash y procure-to-pay.
API reuse ratePorcentaje de proyectos digitales que consumen System APIs existentes en lugar de pedir desarrollo nuevo en el ERP.Es la métrica que materializa el ROI de la capa de integración.
Saga compensation ratePorcentaje de transacciones que requieren rollback compensatorio.Calidad del flujo cross-módulo y estabilidad del proceso end-to-end.

Time-to-value: primer dominio (típicamente finanzas o materiales) en producción tras 12 a 16 semanas, con métricas observables a las 4 semanas siguientes.

Cómo se mide: dashboard sobre Anypoint Monitoring por BAPI o endpoint, integrado con Splunk, Datadog o Grafana cuando ya existe ese stack del lado del cliente.

Preguntas frecuentes

Sí. La mayoría del parque LATAM sigue en ECC y el SAP Connector de Anypoint Platform soporta ambas versiones. Las System APIs se construyen con el mismo enfoque: BAPIs y RFCs en ECC, OData y APIs SAP Gateway en S/4HANA. Cuando el cliente migra a S/4HANA, las APIs hacia el resto del ecosistema permanecen estables.

Las personalizaciones se exponen como cualquier otra capacidad: si hay un BAPI custom o una tabla específica, se modela en la System API correspondiente. La regla es que el contrato de la System API hable el lenguaje del negocio, no el de la personalización. Eso permite que el ERP evolucione sin romper a los consumers.

Acotado y medible. Cada adapter tiene throttle configurable acordado con el equipo Basis, observabilidad granular por BAPI o endpoint, y un circuit breaker que protege al ERP de cascadas. Cuando la métrica detecta degradación, el sistema se autorregula antes de que el ERP se vea afectado.

El despliegue se hace por dominio, no por big bang. Primero un módulo en producción (típicamente finanzas o materiales), con el resto del flujo en bypass. Validación, hypercare, y luego se incorporan los siguientes módulos. Las ventanas de mantenimiento del ERP se respetan: los flows toleran respuestas 503 con Retry-After y se reagendan.

Al contrario, su rol cambia y se libera. En lugar de atender pedidos puntuales de cada nuevo proyecto digital, el equipo del ERP se concentra en el core (módulos, personalizaciones, procesos). MuleSoft expone las capacidades existentes detrás de APIs estables y los consumers nuevos pasan por ahí, no por desarrollo en el ERP.

Tu ERP detrás de APIs reutilizables.

Hablemos de tu stack ERP y diseñamos juntos el roadmap de integración.

Ver los 17 casos de uso