Ir al contenido principal
FromNine
Menú

Ingeniería

Integración de sistemas y API para que los datos circulen con fiabilidad

Conectamos CRM, ERP, sistemas de gestión de expedientes y plataformas de la Administración mediante contratos, eventos e identidad bien resueltos, para que los datos circulen de forma fiable, los errores sean visibles y las nuevas capacidades, incluida la IA, se incorporen con seguridad.

Para organizaciones en España cuyos sistemas deben entenderse entre sí y con la Administración: Cl@ve, FACe, sede electrónica y Carpeta Ciudadana.

Hablemos de su proyectoConozca nuestro enfoque
Integraciones y APIs: capas de capacidadCuatro capas superpuestas en profundidad. De arriba abajo: los consumidores, como portales, aplicaciones y agentes; la pasarela de API con la identidad; la columna vertebral de eventos; y, por debajo, los sistemas de registro.01Portales, aplicaciones y agentes02Pasarela de API e identidad03Columna vertebral de eventos04Sistemas de registro
  1. 01API diseñadas a partir del contrato con OpenAPI y AsyncAPI, versionadas y documentadas
  2. 02Eventos con orden garantizado, idempotencia, gestión de mensajes fallidos y reproducción
  3. 03Cada flujo supervisado y cada cola de errores a cargo de un equipo identificado

01 Problemas

Los problemas de integración por los que nos llaman

  1. 01

    Conexiones punto a punto que nadie se atreve a tocar

    Decenas de conexiones directas entre el CRM, el ERP y los sistemas a medida. Cambiar un campo obliga a probar diez interfaces.

  2. 02

    Duplicados y fallos silenciosos

    Un reintento genera un segundo pedido. Un mensaje fallido desaparece. Los usuarios de negocio se enteran por los clientes.

  3. 03

    Cada nuevo canal exige un nuevo trabajo de integración

    El portal, la aplicación móvil y ahora un asistente de IA necesitan los mismos datos, y cada uno recibe su propia extracción.

  4. 04

    Los intercambios con la Administración son un proyecto en sí mismos

    Conectarse a una plataforma nacional de intercambio de datos o a un sistema de identificación electrónica supone, cada vez, meses de trabajo de seguridad y de alta.

02 Qué entregamos

Qué entregamos

  1. 01 Estrategia y gestión de API

    Diseño API-first con contratos OpenAPI y AsyncAPI, una política de versionado, una pasarela que la hace cumplir y un portal para desarrolladores en el que los equipos encuentran y reutilizan lo que ya existe.

    Qué hacemos

    • Inventario de las API existentes y de sus responsables
    • Pautas de diseño y proceso de revisión
    • Políticas de la pasarela para seguridad, cuotas y versionado
    • Portal para desarrolladores y catálogo de API

    Qué recibe

    • Pautas de API adoptadas por sus equipos
    • Configuración de la pasarela como código
    • Catálogo de API documentadas

  2. 02 Integración orientada a eventos

    Brokers, captura de cambios y el patrón outbox, con los detalles que deciden si funciona o no: orden, consumidores idempotentes, gestión de mensajes fallidos y reproducción.

    Qué hacemos

    • Modelo de eventos y convenciones de nomenclatura
    • Outbox y CDC en los sistemas de origen
    • Idempotencia de los consumidores y garantías de orden
    • Colas de mensajes fallidos con herramientas de reproducción

    Qué recibe

    • Columna vertebral de eventos en producción
    • Registro de esquemas y reglas de compatibilidad
    • Runbook de reproducción y recuperación

  3. 03 Plataformas de integración, elegidas con honestidad

    SAP Integration Suite, MuleSoft y los servicios de integración nativos de la nube tienen cada uno su lugar. Le decimos cuándo un iPaaS supera al código a medida y cuándo no.

    Qué hacemos

    • Evaluación del middleware existente
    • Elección de la plataforma con su coste total de propiedad
    • Transformaciones y conectores reutilizables
    • Migración desde el middleware heredado

    Qué recibe

    • Registro de decisión sobre la plataforma de integración
    • Biblioteca de patrones de integración
    • Plan de migración de las interfaces existentes

  4. 04 Identidad y confianza entre sistemas

    OAuth 2.0 y OpenID Connect, TLS mutuo, identidad de servicio a servicio e integración con los sistemas de identificación electrónica de ciudadanos y empresas: itsme, DigiD y eHerkenning, BundID, FranceConnect, Cl@ve, SPID y CIE.

    Qué hacemos

    • Arquitectura de identidad para usuarios y servicios
    • Diseño de tokens, ámbitos y consentimiento
    • Apoyo en el alta y la certificación de la identificación electrónica
    • Preparación para las carteras europeas de identidad digital

    Qué recibe

    • Diseño de identidad y modelo de amenazas
    • Identificación electrónica integrada en producción
    • Identidades de servicio y rotación de secretos implantadas

  5. 05 Interoperabilidad con la Administración

    Conexiones a plataformas nacionales de intercambio de datos, como el Federal Service Bus y MAGDA en Bélgica, Digikoppeling y Common Ground en los Países Bajos, los estándares XÖV y FIT-Connect en Alemania, PDND en Italia y API Entreprise en Francia, y al sistema técnico de «solo una vez» de la UE.

    Qué hacemos

    • Proceso de alta con el operador de la plataforma
    • Correspondencia con los estándares nacionales de datos
    • Requisitos de seguridad y de registro de cada intercambio
    • Diseño del intercambio de evidencias según el principio de «solo una vez»

    Qué recibe

    • Conexión certificada al intercambio
    • Documentación de las correspondencias
    • Procedimientos operativos acordados con el operador

  6. 06 Visibilidad operativa para los usuarios de negocio

    Una supervisión de los flujos que los usuarios de negocio pueden leer, conciliación entre sistemas y colas de errores que alguien asume y resuelve.

    Qué hacemos

    • Supervisión de los flujos en términos de negocio
    • Informes de conciliación entre sistemas
    • Clasificación y encaminamiento de los errores
    • Alertas para cada responsable de flujo

    Qué recibe

    • Cuadro de mando de integración por proceso de negocio
    • Comprobaciones de conciliación en producción
    • Mapa de responsables de cada cola de errores

03 Arquitectura

Una arquitectura de referencia ilustrativa

De los sistemas de registro salen dos caminos. Las peticiones síncronas pasan por API de sistema y por una pasarela que comprueba identidad, ámbitos y cuotas. Los cambios se publican como eventos mediante un outbox o captura de cambios, y los consumidores los procesan de forma idempotente.

Los mensajes fallidos acaban en una cola de mensajes fallidos con reproducción, no en un fichero de log. Una franja de supervisión muestra cada flujo en términos de negocio, para que los responsables de un proceso vean cuándo se detiene.

Capas del diagrama

Sistemas de registro
El ERP, el CRM y la gestión de expedientes conservan la autoridad sobre sus datos.
API síncronas
API de sistema versionadas tras una pasarela con OAuth 2.0, mTLS y cuotas.
Eventos
Outbox, broker, cola de mensajes fallidos y transformaciones en la plataforma de integración.
Consumidores
Portales, aplicaciones, agentes, socios e intercambios con la Administración, con identificación electrónica cuando intervienen ciudadanos.
Ejemplo ilustrativo

  1. Sistemas de registro

    • ERP, CRM y gestión de expedientes

  2. API síncronas

    • API de sistema
    • Pasarela de API: OAuth 2.0, mTLS, cuotas

  3. Eventos

    • Outbox y CDC
    • Broker de eventos
    • Mensajes fallidos y reproducción
    • Transformaciones en la plataforma de integración

  4. Consumidores

    • Portales, aplicaciones y agentes
    • Intercambios con socios y con la Administración
    • Identidad: OIDC, mTLS, identificación electrónica

  5. Operación

    • Supervisión de flujos, conciliación, colas de errores con responsable
API y una columna vertebral de eventos, en paralelo

Arquitectura ilustrativa, no corresponde a ningún sistema de cliente.

Leer el diagrama como texto

El recorrido principal va desde los sistemas de registro, a través de API de sistema versionadas y una pasarela de API, hasta portales, aplicaciones y agentes.

En paralelo, los sistemas de registro publican sus cambios mediante un outbox y captura de cambios en un broker de eventos, que los entrega a los intercambios con socios y con la Administración y a una plataforma de integración para las transformaciones. Los mensajes fallidos van a una cola de mensajes fallidos con reproducción. Los servicios de identidad con OAuth, mTLS e identificación electrónica protegen los intercambios con socios.

Una franja de supervisión en la parte inferior muestra el estado de los flujos, la conciliación y las colas de errores con responsable.

04 Consideraciones y límites

Consideraciones de ingeniería y límites

  • «Exactamente una vez» es un diseño, no un parámetro

    Cómo lo abordamos

    Partimos de que los mensajes llegarán dos veces o desordenados y diseñamos consumidores idempotentes, con claves y reglas de orden acordadas para cada tipo de evento.

    Límites y dependencias

    Algunos sistemas heredados no aceptan claves de idempotencia ni informan de lo que han procesado. En torno a ellos añadimos conciliación, en lugar de fingir.

  • Un iPaaS no siempre es la respuesta

    Cómo lo abordamos

    Las plataformas ganan en muchos conectores y transformaciones estándar. Los servicios a medida ganan con lógica compleja, grandes volúmenes o requisitos estrictos de latencia. Documentamos la elección para cada integración.

    Límites y dependencias

    Los modelos de licencia cambian. Una plataforma barata hoy puede convertirse en la partida más alta de su presupuesto de integración, por eso modelizamos los costes a varios años.

  • Los intercambios con la Administración marcan su propio ritmo

    Cómo lo abordamos

    Preparamos pronto los expedientes de alta, las evidencias de seguridad y los planes de pruebas, y trabajamos con el operador de la plataforma desde la primera semana.

    Límites y dependencias

    Los plazos de certificación y de alta los fija el operador, no nosotros. Planificamos en función de ellos y le indicamos dónde se sitúan en el camino crítico.

  • Los consumidores de IA necesitan API acotadas

    Cómo lo abordamos

    Los agentes y asistentes reciben API dedicadas y de ámbito restringido, con límites y registro de auditoría, no el mismo acceso amplio que los servicios internos.

    Límites y dependencias

    Exponer una API a un agente añade riesgo. Revisamos cada una con su equipo de seguridad antes de ponerla en producción.

05 Cómo trabajamos

Cómo trabajamos

Desenredamos antes de construir, y dejamos cada flujo con un responsable.

  1. 01

    Cartografiar los flujos

    Cada interfaz, su volumen, su historial de fallos y su responsable de negocio.

    ResultadoMapa de integraciones y clasificación por riesgo

  2. 02

    Fijar las reglas

    Pautas de API, convenciones de eventos, modelo de identidad y elección de la plataforma.

    ResultadoPautas de integración y registros de decisiones

  3. 03

    Migrar flujo a flujo

    Primero los flujos de mayor riesgo, con una conciliación en paralelo a la interfaz antigua hasta que las cifras cuadren.

    ResultadoFlujos migrados con evidencias de conciliación

  4. 04

    Operar a la vista

    Cuadros de mando por proceso de negocio y colas de errores con responsables identificados.

    ResultadoMapa de responsables de los flujos y cuadros de mando

06 Control humano

Dónde mantienen el control las personas

La integración funciona de forma desatendida. La responsabilidad sobre lo que falla, no.

  • Cada cola de errores tiene un responsable

    Los mensajes fallidos llegan a un equipo que responde de ellos, con contexto y un botón de reproducción, no a un log compartido.

  • Los cambios de contrato se revisan

    Los cambios incompatibles en una API o un evento se revisan con los consumidores antes de publicarse.

  • Las reproducciones son deliberadas

    Reproducir mensajes hacia un sistema de registro es una acción autorizada, que queda registrada con quién la realizó y por qué.

07 Tecnologías

Tecnologías con las que trabajamos

Plataformas de integración
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Servicios de integración de AWS y Google Cloud
Eventos y streaming
  • Apache Kafka
  • RabbitMQ
  • Brokers de eventos en la nube
  • Debezium para la captura de cambios
API
  • OpenAPI y AsyncAPI
  • Pasarelas de API y portales para desarrolladores
  • GraphQL cuando encaja
  • Pruebas de contrato
Identidad
  • OAuth 2.0 y OpenID Connect
  • TLS mutuo
  • Keycloak y proveedores de identidad en la nube
  • Sistemas nacionales de identificación electrónica

La mención de una tecnología refleja nuestra experiencia de ingeniería. No implica ninguna asociación con su fabricante ni su respaldo.

08 Ejemplo

Un ejemplo ilustrativo

Ejemplo ilustrativo

Una sede electrónica conectada a los servicios comunes

01Situación
Una diputación provincial ofrece trámites a sus municipios a través de una sede electrónica que pide al ciudadano documentos que otras administraciones ya tienen, y cada integración se mantiene a mano.
02Qué construiríamos
Una capa de integración que conecta la sede con Cl@ve, consulta datos a través de la Plataforma de Intermediación, envía las facturas a FACe y ofrece API estables a las aplicaciones de gestión.
03Dónde deciden las personas
El responsable de cada trámite aprueba qué datos se consultan y con qué finalidad; cada consulta queda registrada para su auditoría.
04Qué mediríamos
Documentos que el ciudadano ya no tiene que aportar, trámites completados en línea e incidencias de integración al mes.

09 Por sectores

En su sector

  • Sector público y Administración

    Intercambio de datos con fuentes auténticas según el principio de «solo una vez», identificación electrónica para ciudadanos y empresas, y el registro de actividad que exigen las plataformas nacionales. Conozca nuestro trabajo para el sector público.

  • Industria y fabricación

    ERP, MES y portales de proveedores conectados mediante eventos, para que planificación, producción y servicio compartan una misma imagen.

  • Servicios financieros

    Sistemas centrales, CRM y API para socios conectados con una identidad robusta, registro de auditoría y una conciliación en la que confía el área financiera.

España

Interoperabilidad con la Administración española

El Esquema Nacional de Interoperabilidad fija cómo intercambian datos las administraciones españolas, y la Ley 39/2015 reconoce al ciudadano el derecho a no aportar documentos que ya obran en poder de la Administración. En la práctica, eso exige integrarse con Cl@ve para la identificación, con la Plataforma de Intermediación de Datos para las consultas entre organismos, con FACe para la factura electrónica y con la Carpeta Ciudadana para reunir la información en un solo lugar. eIDAS 2 añadirá la cartera europea de identidad digital.

Diseñamos estas integraciones detrás de interfaces estables, para que un cambio en un servicio común no obligue a modificar cada aplicación.

Preguntas sobre integraciones y APIs

¿Conviene usar una plataforma de integración o desarrollar integraciones a medida?

Ambas cosas, para flujos distintos. Los conectores estándar, las transformaciones y el alta de socios favorecen una plataforma. Los flujos de gran volumen, sensibles a la latencia o con mucha lógica suelen favorecer los servicios a medida. Decidimos flujo a flujo y documentamos el motivo.

¿Integran Salesforce, SAP y Odoo?

Sí, con frecuencia, entre sí y con sistemas a medida y de la Administración. FromNine tiene la condición de partner de las tres (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), por lo que nuestros equipos de integración trabajan junto a especialistas de cada plataforma. Conozca nuestro trabajo de integración con SAP.

¿Necesitamos una integración orientada a eventos?

Los eventos ayudan cuando varios sistemas deben reaccionar al mismo cambio o cuando se quieren desacoplar los ciclos de versiones. Para una simple petición y respuesta entre dos sistemas, una API suele bastar. La mayoría de los entornos utilizan ambos.

¿Pueden integrar los sistemas nacionales de identificación electrónica?

Sí. Integramos sistemas de identificación electrónica para ciudadanos y empresas y diseñamos pensando en las carteras europeas de identidad digital que los Estados miembros están introduciendo en virtud de eIDAS 2. Los requisitos de alta varían según el sistema y los planificamos con antelación.

Tenemos un middleware heredado. ¿Debemos sustituirlo?

No de golpe. Cartografiamos lo que se ejecuta en él, migramos primero los flujos más arriesgados o costosos y mantenemos la conciliación hasta que cada flujo migrado está probado.

Traiga la interfaz que más falla

Empezaremos por esa integración: qué la rompe, cómo se vigila y qué contrato de API la haría estable.

Hablemos de su proyectoConozca nuestro enfoque