Saltar ao contido principal
FromNine
Menú

Enxeñaría

Integracións que manteñen os datos en movemento e avisan cando se deteñen.

Conectamos o CRM, o ERP, os sistemas de expedientes e as plataformas das administracións mediante contratos, eventos e unha identidade ben resolta, para que os datos circulen con fiabilidade, os erros se vexan e as novas capacidades, incluída a IA, se poidan conectar con seguridade.

Para empresas e organismos que conectan os seus sistemas coa factura electrónica, coas administracións e cos seus socios.

Fálenos do seu proxectoVer as plataformas que conectamos
Integracións e API: capas de capacidadeCatro capas superpostas en profundidade. De arriba abaixo: os consumidores, como portais, aplicacións e axentes, a pasarela de API con identidade, a columna de eventos e, por debaixo, os sistemas de rexistro.01Portais, aplicacións e axentes02Pasarela de API e identidade03Columna de eventos04Sistemas de rexistro
  1. 01API deseñadas a partir do contrato, con OpenAPI e AsyncAPI, versionadas e documentadas
  2. 02Eventos con orde, idempotencia, cola de erros e reprodución
  3. 03Fluxos supervisados de extremo a extremo e colas de erros a cargo de equipos designados

01 Problemas

Problemas de integración polos que nos chaman

  1. 01

    Conexións punto a punto que ninguén se atreve a cambiar

    Decenas de conexións directas entre o CRM, o ERP e os sistemas a medida. Cambiar un campo obriga a probar dez interfaces.

  2. 02

    Duplicados e fallos silenciosos

    Un reintento crea un segundo pedido. Unha mensaxe fallida desaparece. As persoas do negocio decátanse pola clientela.

  3. 03

    Cada canle nova supón novo traballo de integración

    O portal, a aplicación móbil e agora un asistente de IA necesitan os mesmos datos, e cada un recibe a súa propia extracción.

  4. 04

    Conectar coas administracións é un proxecto en si mesmo

    Cada conexión cunha plataforma pública de intercambio de datos ou cun sistema de identificación electrónica leva meses de traballo de seguridade e de alta.

02 Que entregamos

Que entregamos

  1. 01 Estratexia e xestión de API

    Deseño centrado nas API con contratos OpenAPI e AsyncAPI, unha política de versións, unha pasarela que a fai cumprir e un portal para desenvolvedores no que os equipos atopan e reutilizan o que xa existe.

    Que facemos

    • Mapa das API e dos seus responsables
    • Pautas de deseño e proceso de revisión
    • Políticas da pasarela para seguridade, cotas e versións
    • Portal para desenvolvedores e catálogo de API

    Que recibe

    • Pautas de API adoptadas polos seus equipos
    • Configuración da pasarela como código
    • Catálogo de API documentadas

  2. 02 Integración baseada en eventos

    Intermediarios de mensaxes, captura de cambios e o patrón outbox, cos detalles que deciden se funciona: orde, consumidores idempotentes, cola de erros e reprodución.

    Que facemos

    • Modelo de eventos e convencións de nomes
    • Outbox e CDC nos sistemas de orixe
    • Idempotencia dos consumidores e garantías de orde
    • Colas de erros con ferramentas de reprodución

    Que recibe

    • Columna de eventos en produción
    • Rexistro de esquemas e regras de compatibilidade
    • Manual de reprodución e recuperación

  3. 03 Plataformas de integración, escollidas para cada fluxo

    SAP Integration Suite, MuleSoft e os servizos de integración nativos da nube teñen cada un o seu lugar. Dicímoslle cando un iPaaS é mellor ca o código a medida, e cando non.

    Que facemos

    • Avaliación do middleware existente
    • Elección da plataforma co custo total de propiedade
    • Correspondencias e conectores reutilizables
    • Migración desde middleware herdado

    Que recibe

    • Rexistro da decisión sobre a plataforma de integración
    • Biblioteca de patróns de integración
    • Plan de migración das interfaces existentes

  4. 04 Identidade e confianza entre sistemas

    OAuth 2.0 e OpenID Connect, TLS mutuo, identidade entre servizos e integración coa identificación electrónica de cidadanía e empresas: Cl@ve, o DNI electrónico e os certificados electrónicos cualificados.

    Que facemos

    • Arquitectura de identidade para persoas usuarias e servizos
    • Deseño de tokens, alcances e consentimento
    • Apoio na alta e na homologación cos sistemas de identificación
    • Preparación para as carteiras europeas de identidade dixital

    Que recibe

    • Deseño de identidade e modelo de ameazas
    • Identificación electrónica integrada en produción
    • Identidade de servizo e rotación de segredos en funcionamento

  5. 05 Intero­perabilidade coas administracións

    Conexións coas plataformas e cos puntos de entrada das administracións españolas, como FACe para as facturas á Administración xeral do Estado e o SEF para as da Xunta de Galicia, segundo o Esquema nacional de interoperabilidade, e co sistema técnico europeo «unha soa vez» (OOTS).

    Que facemos

    • Alta e incorporación co operador da plataforma
    • Correspondencia cos estándares de datos nacionais
    • Requisitos de seguridade e de rexistro de cada intercambio
    • Deseño do intercambio de probas «unha soa vez»

    Que recibe

    • Conexión co intercambio validada polo operador
    • Documentación das correspondencias
    • Procedementos operativos acordados co operador

  6. 06 Visibilidade operativa para o negocio

    Seguimento dos fluxos que as persoas do negocio poden ler, conciliación entre sistemas e colas de erros que teñen responsable e se atenden.

    Que facemos

    • Seguimento dos fluxos en termos de negocio
    • Informes de conciliación entre sistemas
    • Clasificación e derivación dos erros
    • Alertas para cada responsable de fluxo

    Que recibe

    • Panel de integración por proceso de negocio
    • Comprobacións de conciliación en produción
    • Mapa de responsables de cada cola de erros

03 Arquitectura

Unha arquitectura de referencia ilustrativa

Dos sistemas de rexistro saen dous camiños. As peticións síncronas pasan por API de sistema e por unha pasarela que comproba a identidade, os alcances e as cotas. Os cambios publícanse como eventos mediante un outbox ou a captura de cambios, e os consumidores procésanos de forma idempotente.

As mensaxes fallidas van a unha cola de erros con reprodución, non a un ficheiro de rexistro. Unha franxa de seguimento mostra cada fluxo en termos de negocio, para que as persoas responsables dun proceso vexan cando se detén.

Capas do debuxo

Sistemas de rexistro
O ERP, o CRM e a xestión de expedientes seguen sendo a referencia dos seus datos.
API síncronas
API de sistema versionadas detrás dunha pasarela con OAuth 2.0, mTLS e cotas.
Eventos
Outbox, intermediario, cola de erros e correspondencias na plataforma de integración.
Consumidores
Portais, aplicacións, axentes, socios e intercambios coas administracións, con identificación electrónica cando interveñen cidadáns.
Exemplo ilustrativo

  1. Sistemas de rexistro

    • ERP, CRM e sistemas de expedientes

  2. API síncronas

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

  3. Eventos

    • Outbox e CDC
    • Intermediario de eventos
    • Cola de erros e reprodución
    • Correspon­dencias na plataforma de integración

  4. Consumidores

    • Portais, aplicacións e axentes
    • Intercambios con socios e administracións
    • Identidade: OIDC, mTLS, Cl@ve

  5. Operación

    • Seguimento dos fluxos, conciliación, colas de erros con responsable
API e unha columna de eventos, lado a lado

Arquitectura ilustrativa, non é o sistema dun cliente.

Ler o diagrama como texto

A ruta principal vai dos sistemas de rexistro, a través de API de sistema versionadas e dunha pasarela de API, ata os portais, as aplicacións e os axentes.

En paralelo, os sistemas de rexistro publican os cambios mediante un outbox e a captura de cambios nun intermediario de eventos, que os entrega aos intercambios con socios e administracións e a unha plataforma de integración para as correspondencias. As mensaxes fallidas van a unha cola de erros con reprodución. Os servizos de identidade con OAuth, mTLS e identificación electrónica protexen os intercambios con socios.

Unha franxa de seguimento, por debaixo, mostra o estado dos fluxos, a conciliación e as colas de erros con responsable.

04 Consideracións e límites

Consideracións técnicas e límites

  • «Exactamente unha vez» é un deseño, non un axuste

    Como o abordamos

    Partimos de que as mensaxes chegan dúas veces ou desordenadas e deseñamos consumidores idempotentes, con claves e regras de orde acordadas para cada tipo de evento.

    Límites e dependencias

    Algúns sistemas herdados non aceptan claves de idempotencia nin informan do que procesaron. Arredor deles engadimos conciliación en vez de finxir.

  • Un iPaaS non sempre é a resposta

    Como o abordamos

    As plataformas gañan en moitos conectores e correspondencias estándar. Os servizos a medida gañan coa lóxica complexa, os grandes volumes ou a latencia estrita. Documentamos a elección para cada integración.

    Límites e dependencias

    Os modelos de licenza cambian. Unha plataforma barata hoxe pode converterse na partida máis grande do seu orzamento de integración, así que modelamos os custos a varios anos.

  • As plataformas públicas marcan o seu propio ritmo

    Como o abordamos

    Preparamos cedo a documentación de alta, as evidencias de seguridade e os plans de probas, e traballamos co operador da plataforma desde a primeira semana.

    Límites e dependencias

    Os prazos de homologación e de alta fíxaos o operador, non nós. Planificamos arredor deles e indicámoslle onde están no camiño crítico.

  • Os consumidores de IA necesitan API estreitas

    Como o abordamos

    Os axentes e os asistentes reciben API propias e acoutadas, con límites e rexistro de auditoría, non o mesmo acceso amplo que os servizos internos.

    Límites e dependencias

    Expoñer unha API a un axente engade risco. Revisamos cada unha co seu equipo de seguridade antes de que entre en produción.

05 Como traballamos

Como traballamos

Desenredamos antes de construír, e deixamos cada fluxo cun responsable.

  1. 01

    Mapear os fluxos

    Cada interface, o seu volume, o seu historial de fallos e a súa persoa responsable no negocio.

    ResultadoMapa das integracións e clasificación por risco

  2. 02

    Fixar as regras

    Pautas de API, convencións de eventos, modelo de identidade e elección da plataforma.

    ResultadoPautas de integración e rexistros de decisións

  3. 03

    Mover fluxo a fluxo

    Primeiro os fluxos de maior risco, coa conciliación funcionando xunto á interface antiga ata que as cifras coinciden.

    ResultadoFluxos migrados con evidencia de conciliación

  4. 04

    Operar con visibilidade

    Paneis por proceso de negocio e colas de erros con responsables designados.

    ResultadoMapa de responsables dos fluxos e paneis

06 Control humano

Onde as persoas manteñen o control

A integración funciona sen vixilancia. A responsabilidade do que sae mal, non.

  • Cada cola de erros ten responsable

    As mensaxes fallidas van a un equipo que responde por elas, co contexto e un botón de reprodución, non a un rexistro compartido.

  • Os cambios de contrato revísanse

    Os cambios incompatibles nunha API ou nun evento pasan por unha revisión cos consumidores antes de publicarse.

  • As reproducións son deliberadas

    Reproducir mensaxes nun sistema de rexistro é unha acción autorizada, que queda rexistrada con quen a fixo e por que.

07 Tecnoloxías

Tecnoloxías coas que traballamos

Plataformas de integración
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Servizos de integración de AWS e Google Cloud
Eventos e streaming
  • Apache Kafka
  • RabbitMQ
  • Intermediarios de eventos na nube
  • Debezium para a captura de cambios
API
  • OpenAPI e AsyncAPI
  • Pasarelas de API e portais para desenvolvedores
  • GraphQL onde encaixa
  • Probas de contrato
Identidade
  • OAuth 2.0 e OpenID Connect
  • TLS mutuo
  • Keycloak e provedores de identidade na nube
  • Sistemas nacionais de identificación electrónica

Mencionar unha tecnoloxía describe a nosa experiencia técnica. Non implica unha asociación co seu fabricante nin o seu respaldo.

08 Exemplo

Un exemplo ilustrativo

Exemplo ilustrativo

O ERP dunha empresa conserveira listo para a factura electrónica entre empresas

01Situación
Unha empresa conserveira cun volume de operacións superior a 8 millóns de euros terá que emitir factura electrónica ás empresas clientes establecidas en España desde o 6 de outubro de 2027, e o seu programa de facturación ten que estar adaptado a Verifactu antes do 1 de xaneiro de 2027. Hoxe factura en PDF desde o ERP, e as facturas a organismos públicos cárganse a man no punto de entrada de cada un.
02Que construiriamos
Unha capa de integración que xera desde o ERP as facturas nun formato admitido, envíaas a través dunha plataforma privada de factura electrónica, recibe os seus estados e leva as facturas ás administracións polo punto xeral de entrada que corresponde, FACe ou o autonómico, coordinada coa adaptación do ERP a Verifactu.
03Onde deciden as persoas
O departamento de administración aproba as regras de correspondencia de cada cliente e revisa as facturas rexeitadas; ningunha factura rectificativa se emite sen a aprobación dunha persoa.
04Que mediriamos
Proporción de facturas emitidas e recibidas en formato electrónico, facturas rexeitadas por erros nos datos e días desde a emisión ata o cobro.

09 Por sector

No seu sector

  • Sector público

    Intercambio de datos «unha soa vez» con fontes auténticas, identificación electrónica para cidadanía e empresas e os rexistros que piden as plataformas públicas. Vexa o noso traballo para o sector público.

  • Fabricación e industria

    ERP, MES e portais de provedores conectados mediante eventos, para que planificación, produción e servizo compartan a mesma imaxe, e a factura electrónica entre empresas lista para 2027 e 2028.

  • Servizos financeiros

    Sistemas centrais, CRM e API de socios conectados cunha identidade sólida, rexistro de auditoría e unha conciliación na que confía o departamento financeiro.

España

Factura electrónica, Cl@ve e intero­perabilidade en España

A factura electrónica entre empresas será obrigatoria en España desde o 6 de outubro de 2027 para as empresas cun volume de operacións superior a 8 millóns de euros no ano natural anterior, e desde o 6 de outubro de 2028 para todas as demais (Lei 18/2022, Real decreto 238/2026 e Orde HAC/1028/2026). Aplícase ás facturas a empresas e profesionais establecidos en España; as facturas simplificadas quedan fóra. Antes diso, os programas de facturación teñen que estar adaptados a Verifactu: antes do 1 de xaneiro de 2027 os dos contribuíntes do imposto sobre sociedades e antes do 1 de xullo de 2027 os dos demais obrigados.

Durante os primeiros doce meses, no grupo de maior volume, a factura electrónica vai acompañada dunha versión PDF lexible, salvo que a empresa destinataria acepte o formato orixinal. As plataformas privadas remitirán unha copia fiel en UBL á solución pública da Axencia Tributaria; admítense Facturae, EDIFACT e as sintaxes da norma EN 16931, e as mensaxes Peppol BIS son válidas entre plataformas privadas.

Coas administracións, a Lei 25/2013 obriga, entre outras, as sociedades anónimas e limitadas e as persoas xurídicas sen nacionalidade española a facturar electronicamente a través do punto xeral de entrada que corresponda: FACe para a Administración xeral do Estado e o SEF para a Xunta de Galicia. Para a identificación, Cl@ve é a plataforma común do sector público administrativo estatal, e o Esquema nacional de interoperabilidade (Real decreto 4/2010) fixa as regras de intercambio.

Deseñamos capas de integración nas que cada formato, punto de entrada e sistema de identidade é un adaptador detrás de contratos internos estables. Cando chega unha data nova ou unha canle nova, engádese un adaptador e a súa alta, sen refacer os sistemas que hai detrás.

Preguntas sobre integracións e API

Usamos unha plataforma de integración ou desenvolvemos integracións a medida?

As dúas cousas, para fluxos distintos. Os conectores estándar, as correspondencias e a incorporación de socios favorecen unha plataforma. Os fluxos de gran volume, sensibles á latencia ou con moita lóxica adoitan favorecer os servizos a medida. Decidimos fluxo a fluxo e documentamos por que.

Integran Salesforce, SAP e Odoo?

Si, con regularidade, entre eles e con sistemas a medida e das administracións. FromNine é socio das tres plataformas (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), así que os nosos equipos de integración traballan xunto a especialistas de cada unha. Vexa o noso traballo de integración con SAP.

Necesitamos integración baseada en eventos?

Os eventos axudan cando varios sistemas teñen que reaccionar ao mesmo cambio ou cando cómpre desacoplar os ciclos de publicación. Para unha simple petición e resposta entre dous sistemas, adoita abondar cunha API. A maioría dos contornos usan as dúas cousas.

Poden integrar Cl@ve e outros sistemas de identificación electrónica?

Si. Integramos sistemas de identificación electrónica para a cidadanía e as empresas, como Cl@ve, e deseñamos pensando nas carteiras europeas de identidade dixital que os Estados membros están a introducir segundo eIDAS 2. Os requisitos de alta varían segundo o sistema, e planificámolos cedo.

Temos middleware herdado. Temos que substituílo?

Non todo de vez. Mapeamos o que funciona sobre el, movemos primeiro os fluxos máis arriscados ou máis caros e mantemos a conciliación ata que cada fluxo migrado demostra que funciona.

Traia a interface que máis falla

Mostrarémoslle como a fariamos observable, idempotente e con responsable, e que levaría facer o mesmo co resto.

Fálenos do seu proxectoVer atención ao público