Aneu al contingut principal
FromNine
Menú

Programari i núvol

Integracions que mantenen les dades en moviment i avisen quan s’aturen.

Connectem CRM, ERP, sistemes d’expedients i plataformes de les administracions amb contractes, esdeveniments i una identitat ben resolta, perquè les dades circulin de manera fiable, els errors siguin visibles i les capacitats noves, també la IA, s’hi puguin connectar amb seguretat.

Per a organitzacions que connecten sistemes, socis i plataformes públiques en més d’un estat membre.

Integracions i API: capes de capacitatsQuatre capes apilades en profunditat. De dalt a baix: els consumidors, com portals, aplicacions i agents, la passarel·la d’API amb la identitat, l’eix d’esdeveniments i, a sota, els sistemes de referència.01Portals, aplicacions i agents02Passarel·la d’API i identitat03Eix d’esdeveniments04Sistemes de referència
  1. 01API dissenyades a partir del contracte amb OpenAPI i AsyncAPI, versionades i documentades
  2. 02Esdeveniments amb ordre, idempotència, gestió de missatges fallits i reproducció
  3. 03Fluxos supervisats de punta a punta i cues d’error a càrrec d’equips designats

01 Problemes

Problemes d’integració per als quals ens criden

  1. 01

    Connexions punt a punt que ningú no s’atreveix a canviar

    Desenes de connexions directes entre el CRM, l’ERP i sistemes a mida. Canviar un camp vol dir provar deu interfícies.

  2. 02

    Duplicats i errors silenciosos

    Un reintent crea una segona comanda. Un missatge fallit desapareix. Les persones del negoci se n’assabenten pels clients.

  3. 03

    Cada canal nou vol dir una integració nova

    El portal, l’aplicació mòbil i ara un assistent d’IA necessiten les mateixes dades, i cadascun té la seva pròpia extracció.

  4. 04

    Els intercanvis amb les administracions són un projecte a part

    Connectar-se a una plataforma d’intercanvi de dades de l’administració, a un punt d’entrada de factures o a un sistema d’identificació electrònica com Cl@ve demana cada vegada mesos de feina de seguretat i d’alta.

02 Què lliurem

Què lliurem

  1. 01 Estratègia i gestió d’API

    Disseny que parteix de les API, amb contractes OpenAPI i AsyncAPI, una política de versions, una passarel·la que l’aplica i un portal per a desenvolupadors perquè els equips trobin i reutilitzin el que ja existeix.

    Què fem

    • Mapa de les API i de les persones responsables
    • Pautes de disseny i procés de revisió
    • Polítiques de la passarel·la per a seguretat, quotes i versions
    • Portal per a desenvolupadors i catàleg d’API

    Què rebeu

    • Pautes d’API adoptades pels vostres equips
    • Configuració de la passarel·la com a codi
    • Catàleg d’API documentades
  2. 02 Integració basada en esdeveniments

    Intermediaris de missatges, captura de canvis i el patró outbox, amb els detalls que decideixen si funciona: ordre, consumidors idempotents, gestió de missatges fallits i reproducció.

    Què fem

    • Model d’esdeveniments i convencions de noms
    • Outbox i captura de canvis als sistemes d’origen
    • Idempotència dels consumidors i garanties d’ordre
    • Cues de missatges fallits amb eines de reproducció

    Què rebeu

    • Eix d’esdeveniments en producció
    • Registre d’esquemes i regles de compatibilitat
    • Procediment de reproducció i recuperació
  3. 03 Plataformes d’integració, triades per a cada flux

    SAP Integration Suite, MuleSoft i els serveis d’integració nadius del núvol tenen cadascun el seu lloc. Us diem quan una iPaaS és millor que el codi a mida, i quan no.

    Què fem

    • Avaluació del middleware existent
    • Elecció de plataforma amb el cost total de propietat
    • Correspondències i connectors reutilitzables
    • Migració des del middleware heretat

    Què rebeu

    • Registre de la decisió sobre la plataforma d’integració
    • Biblioteca de patrons d’integració
    • Pla de migració de les interfícies existents
  4. 04 Identitat i confiança entre sistemes

    OAuth 2.0 i OpenID Connect, TLS mutu, identitat entre serveis i integració amb sistemes d’identificació electrònica per a la ciutadania i les empreses: itsme, DigiD i eHerkenning, BundID, FranceConnect, Cl@ve i el DNI electrònic (DNIe), SPID i CIE.

    Què fem

    • Arquitectura d’identitat per a persones usuàries i serveis
    • Disseny de tokens, abasts i consentiment
    • Suport en l’alta i la certificació dels sistemes d’identificació
    • Preparació per a les carteres europees d’identitat digital

    Què rebeu

    • Disseny d’identitat i model d’amenaces
    • Integració d’identificació electrònica en producció
    • Identitat de servei i rotació de secrets en funcionament
  5. 05 Interopera­bilitat amb les administracions

    A Espanya, connexions amb Cl@ve, amb els punts generals d’entrada de factures electròniques FACe i e-FACT, i amb la Plataforma de Contractació del Sector Públic (PLACSP) i la Plataforma de serveis de contractació pública (PSCP). En altres estats membres, plataformes nacionals d’intercanvi de dades com el Federal Service Bus i MAGDA a Bèlgica, Digikoppeling i Common Ground als Països Baixos, els estàndards XÖV i FIT-Connect a Alemanya, PDND a Itàlia i API Entreprise a França, i l’Once-Only Technical System de la UE.

    Què fem

    • Alta amb l’operador de cada plataforma
    • Correspondència amb els estàndards de dades de cada administració
    • Requisits de seguretat i de registre de cada intercanvi
    • Disseny de l’intercanvi d’evidències segons el principi d’una sola vegada

    Què rebeu

    • Connexió certificada amb l’intercanvi
    • Documentació de les correspondències
    • Procediments operatius acordats amb l’operador
  6. 06 Visibilitat operativa per a les persones del negoci

    Supervisió dels fluxos que les persones del negoci poden llegir, conciliació entre sistemes i cues d’error que algú té a càrrec i resol.

    Què fem

    • Supervisió dels fluxos en termes de negoci
    • Informes de conciliació entre sistemes
    • Classificació i derivació dels errors
    • Alertes per a cada persona responsable de flux

    Què rebeu

    • Quadre de comandament d’integració per procés de negoci
    • Comprovacions de conciliació en producció
    • Mapa de responsables de cada cua d’error

03 Arquitectura

Una arquitectura de referència il·lustrativa

Dels sistemes de referència surten dos camins. Les peticions síncrones passen per API de sistema i per una passarel·la que comprova la identitat, els abasts i les quotes. Els canvis es publiquen com a esdeveniments a través d’un outbox o de la captura de canvis, i els consumidors els processen de manera idempotent.

Els missatges fallits van a una cua de missatges fallits amb reproducció, no a un fitxer de registre. Una franja de supervisió mostra cada flux en termes de negoci, perquè les persones responsables d’un procés vegin quan s’atura.

Capes del dibuix

Sistemes de referència
L’ERP, el CRM i la gestió d’expedients mantenen l’autoritat sobre les seves dades.
API síncrones
API de sistema versionades darrere d’una passarel·la amb OAuth 2.0, mTLS i quotes.
Esdeveniments
Outbox, intermediari, cua de missatges fallits i correspondències a la plataforma d’integració.
Consumidors
Portals, aplicacions, agents, socis i intercanvis amb les administracions, amb identificació electrònica quan hi intervé la ciutadania.
Exemple il·lustratiu
  1. Sistemes de referència

    • ERP, CRM i sistemes d’expedients
  2. API síncrones

    • API de sistema
    • Passarel·la d’API: OAuth 2.0, mTLS, quotes
  3. Esdeveniments

    • Outbox i captura de canvis
    • Intermediari d’esdeveniments
    • Missatges fallits i reproducció
    • Correspon­dències a la plataforma d’integració
  4. Consumidors

    • Portals, aplicacions i agents
    • Intercanvis amb socis i administracions
    • Identitat: OIDC, mTLS, eID
  5. Operació

    • Supervisió de fluxos, conciliació, cues d’error amb responsable
API i un eix d’esdeveniments, un al costat de l’altre

Arquitectura il·lustrativa, no el sistema d’un client.

Llegiu el diagrama en format de text

El recorregut principal va dels sistemes de referència a les API de sistema versionades i a una passarel·la d’API, fins als portals, les aplicacions i els agents.

En paral·lel, els sistemes de referència publiquen els canvis a través d’un outbox i de la captura de canvis cap a un intermediari d’esdeveniments, que els lliura als intercanvis amb socis i administracions i a una plataforma d’integració per a les correspondències. Els missatges fallits van a una cua de missatges fallits amb reproducció. Els serveis d’identitat amb OAuth, mTLS i identificació electrònica protegeixen els intercanvis amb socis.

A sota, una franja de supervisió mostra l’estat dels fluxos, la conciliació i les cues d’error amb persona responsable.

04 Consideracions i límits

Consideracions d’enginyeria i límits

  • L’entrega exactament una vegada és un disseny, no un paràmetre

    Com ho abordem

    Partim de la base que els missatges poden arribar dues vegades o desordenats i dissenyem consumidors idempotents, amb claus i regles d’ordre acordades per a cada tipus d’esdeveniment.

    Límits i dependències

    Alguns sistemes heretats no poden acceptar claus d’idempotència ni informar del que han processat. Al seu voltant hi afegim conciliació en lloc de fer veure que no passa res.

  • Una iPaaS no sempre és la resposta

    Com ho abordem

    Les plataformes guanyen en molts connectors i correspondències estàndard. Els serveis a mida guanyen en lògica complexa, volums alts o latència estricta. Documentem l’elecció per a cada integració.

    Límits i dependències

    Els models de llicència canvien. Una plataforma que avui és barata pot acabar sent la partida més gran del vostre pressupost d’integració, i per això en modelem els costos a diversos anys.

  • Les plataformes de les administracions marquen el seu propi ritme

    Com ho abordem

    Preparem aviat la documentació d’alta, l’evidència de seguretat i els plans de proves, i treballem amb l’operador de la plataforma des de la primera setmana.

    Límits i dependències

    Els terminis de certificació i d’alta els fixa l’operador, no nosaltres. Planifiquem al seu voltant i us diem on són dins del camí crític.

  • Els consumidors d’IA necessiten API estretes

    Com ho abordem

    Els agents i els assistents tenen API pròpies i acotades, amb límits i registre d’auditoria, no el mateix accés ampli que els serveis interns.

    Límits i dependències

    Exposar una API a un agent afegeix risc. Revisem cadascuna amb el vostre equip de seguretat abans que entri en producció.

05 Com treballem

Com treballem

Desfem el nus abans de construir, i deixem cada flux amb una persona responsable.

  1. 01

    Cartografiar els fluxos

    Cada interfície, el seu volum, el seu historial d’errors i la seva persona responsable de negoci.

    ResultatMapa d’integracions i classificació del risc

  2. 02

    Fixar les regles

    Pautes d’API, convencions d’esdeveniments, model d’identitat i elecció de plataforma.

    ResultatPautes d’integració i registres de decisions

  3. 03

    Avançar flux a flux

    Primer els fluxos de més risc, amb la conciliació en paral·lel amb la interfície antiga fins que les xifres quadren.

    ResultatFluxos migrats amb evidència de conciliació

  4. 04

    Operar amb visibilitat

    Quadres de comandament per procés de negoci i cues d’error amb persones responsables designades.

    ResultatMapa de responsables dels fluxos i quadres de comandament

06 Control humà

On les persones mantenen el control

La integració funciona sense supervisió. La responsabilitat del que falla, no.

  • Cada cua d’error té una persona responsable

    Els missatges fallits van a un equip que en respon, amb el context i un botó de reproducció, no a un registre compartit.

  • Els canvis de contracte es revisen

    Els canvis incompatibles en una API o en un esdeveniment passen per una revisió amb els consumidors abans de publicar-se.

  • Les reproduccions són deliberades

    Reproduir missatges cap a un sistema de referència és una acció autoritzada, registrada amb qui l’ha feta i per què.

07 Tecnologies

Tecnologies amb què treballem

Plataformes d’integració
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Serveis d’integració d’AWS i de Google Cloud
Esdeveniments i temps real
  • Apache Kafka
  • RabbitMQ
  • Intermediaris d’esdeveniments al núvol
  • Debezium per a la captura de canvis
API
  • OpenAPI i AsyncAPI
  • Passarel·les d’API i portals per a desenvolupadors
  • GraphQL on encaixa
  • Proves de contracte
Identitat
  • OAuth 2.0 i OpenID Connect
  • TLS mutu
  • Keycloak i proveïdors d’identitat al núvol
  • Sistemes nacionals d’identificació electrònica

Esmentar una tecnologia descriu la nostra experiència d’enginyeria. No implica cap acord de col·laboració amb el fabricant ni cap aval per part seva.

08 Exemple

Un exemple il·lustratiu

Exemple il·lustratiu

Un ERP preparat per a la factura electrònica obligatòria i per a Verifactu

01Situació
Un proveïdor industrial amb un volum d’operacions superior a 8 milions d’euros factura a empreses de tot Espanya i a alguns organismes públics. L’ERP genera factures en PDF, les factures a les administracions es pugen a mà i, a partir del 6 d’octubre del 2027, haurà d’emetre factures electròniques a les empreses.
02Què construiríem
Una capa d’integració que connecta l’ERP amb una plataforma privada d’intercanvi de factures electròniques i amb FACe o l’e-FACT per a les factures al sector públic, retorna a l’ERP l’estat de cada factura i alimenta el mòdul de facturació adaptat a Verifactu.
03On decideix una persona
L’equip de finances aprova la correspondència de les dades fiscals i l’entrada en funcionament per a cada grup de clients. Les factures rebutjades van a la cua d’una persona de comptabilitat designada, que decideix com es corregeixen.
04Què mesuraríem
Proporció de factures emeses electrònicament sense correcció manual, temps per resoldre un rebuig i proporció de factures amb l’estat conegut a l’ERP.

09 Per sectors

En el vostre sector

  • Intercanvi de dades amb fonts autèntiques segons el principi d’una sola vegada, identificació electrònica amb Cl@ve, factures a través de FACe i l’e-FACT, i el registre que demanen les plataformes de les administracions. Vegeu la nostra feina per al sector públic.

  • ERP, MES i portals de proveïdors connectats amb esdeveniments, perquè la planificació, la producció i el servei comparteixin una sola imatge.

  • Sistemes centrals, CRM i API de socis connectats amb una identitat sòlida, registre d’auditoria i una conciliació en què l’equip de finances pot confiar.

Espanya

Interopera­bilitat entre estats membres i factura electrònica a Espanya

Els serveis transfronterers troben en cada país una plataforma nacional d’intercanvi de dades, un sistema d’identificació electrònica i un estàndard de dades diferents. El Reglament sobre una Europa interoperable demana als organismes públics que avaluïn la interoperabilitat transfronterera, i el Reglament eIDAS2 porta les carteres europees d’identitat digital que tots els estats membres han d’oferir.

A Espanya, la factura electrònica té dues capes. Amb les administracions, la Llei 25/2013 obliga, entre d’altres, les societats anònimes i limitades i les persones jurídiques sense nacionalitat espanyola a facturar electrònicament a través del punt general d’entrada que correspongui: FACe per a l’Administració General de l’Estat i les administracions que s’hi han adherit, i l’e-FACT del Consorci AOC per a la Generalitat, el seu sector públic i les administracions catalanes. Les factures es poden encaminar entre l’e-FACT i FACe.

Entre empreses, la factura electrònica obligatòria entre empresaris i professionals s’aplicarà a partir del 6 d’octubre del 2027 a les empreses amb un volum d’operacions superior a 8 milions d’euros l’any natural anterior, i a partir del 6 d’octubre del 2028 a la resta. Les plataformes privades d’intercanvi de factures electròniques enviaran una còpia fidel en format UBL de cada factura a la solució pública de facturació electrònica de l’Agència Tributària; s’admeten Facturae, EDIFACT i les sintaxis de l’EN 16931, i Peppol BIS és vàlid entre plataformes privades. A part, Verifactu fixa requisits per als sistemes informàtics de facturació: els contribuents de l’impost sobre societats els han de complir a partir de l’1 de gener del 2027, i la resta d’obligats, a partir de l’1 de juliol del 2027.

Dissenyem capes d’integració en què les plataformes nacionals, els punts d’entrada de factures i els sistemes d’identificació són adaptadors darrere de contractes interns estables. Connectar FACe i l’e-FACT, afegir una plataforma privada d’intercanvi o incorporar un país nou vol dir afegir un adaptador i fer-ne l’alta, no refer els sistemes que hi ha al darrere.

Preguntes sobre integracions i API

Hem de fer servir una plataforma d’integració o desenvolupar integracions a mida?

Totes dues coses, per a fluxos diferents. Els connectors estàndard, les correspondències i l’alta de socis afavoreixen una plataforma. Els fluxos de gran volum, sensibles a la latència o amb molta lògica sovint afavoreixen serveis a mida. Ho decidim per a cada flux i documentem per què.

Integreu Salesforce, SAP i Odoo?

Sí, sovint, entre ells i amb sistemes a mida i de les administracions. FromNine és partner de totes tres (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), de manera que els nostres equips d’integració treballen al costat d’especialistes de cada plataforma. Vegeu la nostra feina d’integració amb SAP.

Necessitem una integració basada en esdeveniments?

Els esdeveniments ajuden quan diversos sistemes han de reaccionar al mateix canvi o quan cal desacoblar els cicles de publicació. Per a una simple petició i resposta entre dos sistemes, sovint n’hi ha prou amb una API. La majoria d’entorns fan servir totes dues coses.

Podeu integrar sistemes nacionals d’identificació electrònica?

Sí. Integrem sistemes d’identificació electrònica per a la ciutadania i les empreses, com Cl@ve, i dissenyem pensant en les carteres europees d’identitat digital que els estats membres estan introduint d’acord amb el Reglament eIDAS2. Els requisits d’alta varien segons el sistema i els planifiquem des del principi.

Tenim un middleware heretat. L’hem de substituir?

No tot de cop. Fem el mapa del que hi funciona, traslladem primer els fluxos més arriscats o més cars i mantenim la conciliació fins que cada flux migrat queda demostrat.

Porteu-nos la interfície que falla més sovint

Us mostrarem com la faríem observable, idempotent i amb una persona responsable, i què caldria per fer el mateix amb la resta.