SAP ECC y Oracle E-Business Suite fueron diseñados en una época en que la comunicación con entidades externas se hacía por lotes, no en tiempo real. Integrar estos sistemas con una API REST como la de ECF SSD requiere una capa de adaptación que actúe como intermediario entre el mundo de las transacciones batch y el mundo de los microservicios.
La arquitectura que ha demostrado mayor estabilidad es el patrón Outbox + Worker. En lugar de llamar directamente a la API de ECF desde el ERP, el sistema escribe la factura pendiente en una tabla de salida (outbox) dentro de su propia base de datos. Un proceso independiente lee esa tabla, envía las facturas a la API y actualiza el estado. Esto desacopla el rendimiento del ERP del de la API externa.
En SAP ECC o S/4HANA, el punto de extensión natural es el BADI FI_DOCUMENT_POST o, en implementaciones más modernas, un Business Event que se dispara al confirmar la factura de ventas (VF01). Desde ese punto, el flujo recomendado es:
PENDING.CL_HTTP_CLIENT.Oracle ofrece el motor de Business Events (Oracle Workflow) y los Concurrent Programs como mecanismos equivalentes. La integración se construye sobre un Concurrent Program que invoca la API usando UTL_HTTP o, en versiones más recientes, la integración REST nativa de Oracle Integration Cloud (OIC).
El mayor riesgo en Oracle es la gestión de errores silenciosa: un UTL_HTTP fallido puede quedar registrado solo en los logs del servidor de aplicaciones si no se instrumenta correctamente. Se recomienda usar una tabla de auditoría propia y alertas en tiempo real mediante Oracle Advanced Queuing.
Independientemente del ERP, el certificado digital del emisor nunca debe residir en el servidor de aplicaciones del ERP. La práctica recomendada es delegar la firma al servicio ECF SSD, que maneja el certificado en un HSM (Hardware Security Module) certificado. Esto elimina el riesgo de exposición de claves privadas en entornos con múltiples administradores de sistema.