APIs REST y servicios
Exponen operaciones o consultas bajo un contrato HTTP. Son apropiadas para interacciones en línea entre ERP, portales, apps móviles y socios. Exigen autenticación, límites de uso y versionado explícito.
Productos / Guía integración
Guía de arquitectura conectada
Integrar es diseñar cómo colaboran los sistemas.
No existe una única forma de conectar. APIs, eventos, procesos de datos, archivos y sensores responden a necesidades distintas de tiempo, volumen y responsabilidad.
Idea central
Una interfaz no es todavía una integración.
Una integración define el significado de los datos, las responsabilidades de cada sistema, la seguridad, los tiempos de respuesta y el comportamiento ante errores. Cuando estos acuerdos no existen, la conexión funciona hasta el primer cambio de versión, feriado bancario o pico de carga.
El objetivo no es mover información: es preservar su sentido y la continuidad del proceso de extremo a extremo.Vista de extremo a extremo
De dónde sale el dato a quién lo usa
Toda integración seria puede dibujarse en esta cadena. Si falta un eslabón, el problema aparece tarde y caro.
- OrigenERP, portal, sensor, banco, planilla o sistema legado que produce el hecho o el archivo.
- ContratoEsquema, API, evento o layout de archivo con reglas de validación y versionado.
- TransporteHTTPS, cola, bus, SFTP o VPN. Define latencia, seguridad y trazabilidad.
- TransformaciónMapeo de códigos, monedas, unidades, estados y reglas de negocio entre sistemas.
- DestinoOtro módulo, data warehouse, tablero, aplicación APEX o proceso de aprobación.
- OperaciónMonitoreo, reintentos, conciliación, alertas y responsables cuando algo se cae de noche.
Mapa de patrones
Seis formas de conectar y cuándo utilizarlas
Mensajes y eventos
Un sistema publica que algo ocurrió y otros reaccionan. Desacopla procesos y absorbe picos, pero exige controlar duplicados, orden, reintentos y mensajes fallidos en cola muerta.
ETL y ELT
Extraen, transforman y cargan grandes volúmenes hacia un repositorio analítico o de consolidación. Priorizan consistencia y escala sobre respuesta inmediata.
Archivos e intercambio por lotes
Siguen siendo válidos con bancos, organismos públicos o sistemas antiguos. Deben incluir validación, cifrado, confirmación de recepción y reproceso ante errores.
Legado y envolturas
Adaptadores, middleware o capas de servicio permiten que plataformas existentes convivan con soluciones nuevas sin reemplazos abruptos ni doble digitación.
IoT y telemetría
GPS, RFID y sensores generan flujos continuos desde terreno. Requieren identidad de dispositivos, buffering, normalización de eventos y conexión con procesos en Oracle o aplicaciones de gestión.
Escenarios habituales
Integraciones que aparecen una y otra vez
En proyectos públicos, industriales y de defensa suelen repetirse estos patrones de negocio — cada uno con distinta criticidad y ritmo.
- ERP y bancos
- Conciliación de pagos, cartolas, nóminas y transferencias con trazabilidad y reproceso ante rechazos.
- Portales de proveedores
- Órdenes de compra, recepciones, facturas y estados de pago entre ERP y canal externo.
- Licitación y tramitación
- Intercambio con plataformas públicas, documentos, plazos y validaciones de cumplimiento.
- Terreno y backoffice
- Telemetría, GPS o sensores alimentando inventario, mantenimiento, alertas o tableros operativos.
- Identidad y firma
- Autenticación, SSO o firma electrónica conectada a flujos de aprobación en APEX o EBS.
- Analítica corporativa
- Extracciones controladas desde transaccional hacia modelos de BI sin sobrecargar el ERP en horario peak.
Decisión frecuente
¿Tiempo real, casi real o por lotes?
No todo necesita respuesta inmediata. Un pago bancario, una alerta de sensor o una consulta de stock pueden exigir segundos; un cierre contable o una carga analítica puede esperar minutos u horas.
Elegir mal el patrón encarece la solución, aumenta el acoplamiento y vuelve frágil lo que debería ser estable. La pregunta correcta es cuánta latencia tolera el proceso — no qué tecnología está de moda.
Una arquitectura madura mezcla patrones: APIs para lo urgente, eventos para desacoplar, lotes para consolidar.Guía de decisión
Las preguntas que definen la arquitectura
- 01¿En línea o diferido?
La necesidad real de inmediatez determina costos, acoplamiento y tolerancia a fallas. Muchos procesos funcionan bien con sincronización programada.
- 02¿Quién es dueño del dato?
Definir el sistema maestro evita versiones contradictorias de clientes, productos, saldos, activos o ubicaciones en terreno.
- 03¿Cómo falla y se recupera?
Reintentos, colas, idempotencia, conciliación manual y alertas deben diseñarse antes del primer incidente en producción.
- 04¿Cómo cambiará mañana?
Versionar contratos, documentar dependencias y observar cada flujo reduce el costo de evolucionar ambos extremos sin cortar la operación.
Señales de alerta
Cuándo la integración ya es un riesgo
- Punto único sin documentación
Solo una persona sabe cómo funciona el script o la interfaz. Si falta, el proceso se detiene.
- Archivos manuales
Exportar y subir planillas cada día es una integración frágil disfrazada de solución.
- Sin conciliación
Nadie verifica si lo enviado coincide con lo recibido hasta que contabilidad o cliente reporta diferencias.
- Errores silenciosos
La interfaz falla pero no alerta; los datos quedan incompletos y el negocio sigue operando a ciegas.
- Acoplamiento directo a tablas
Leer o escribir tablas internas del ERP sin contrato formal rompe upgrades y parches con facilidad.
Siguiente paso