Hoppa till huvudinnehållet
FromNine
Meny

Programvara och moln

Integrationer som håller data i rörelse och visar när den stannar.

Vi kopplar ihop CRM, affärssystem, ärendesystem och offentliga plattformar med kontrakt, händelser och identitet som görs ordentligt, så att data flödar pålitligt, fel syns och nya förmågor, även AI, kan anslutas på ett säkert sätt.

För företag och offentliga aktörer i Sverige som kopplar ihop affärssystem, e-tjänster, Peppol och e-legitimation med varandra och med partner i andra länder.

Berätta om ditt projektSalesforce, SAP och Odoo
Integrationer och API:er: förmågor i lagerFyra lager staplade på djupet. Uppifrån och ned: konsumenterna, som portaler, appar och agenter, API-gatewayen med identitet, händelseflödet och de ursprungliga systemen underst.01Portaler, appar och agenter02API-gateway och identitet03Händelseflöde04Ursprungliga system
  1. 01API:er som utgår från kontraktet, med OpenAPI och AsyncAPI, versionshanterade och dokumenterade
  2. 02Händelser med ordning, idempotens, hantering av felade meddelanden och omspelning
  3. 03Flöden som övervakas hela vägen och felköer som ägs av namngivna team

01 Problem

Integrations­problem som vi kallas in för

  1. 01

    Punkt till punkt-kopplingar som ingen vågar ändra

    Dussintals direkta kopplingar mellan CRM, affärssystem och egenutvecklade system. Att ändra ett fält betyder att tio gränssnitt måste testas.

  2. 02

    Dubbletter och tysta fel

    Ett nytt försök skapar en andra order. Ett misslyckat meddelande försvinner. Verksamheten får veta det från kunderna.

  3. 03

    Varje ny kanal betyder nytt integrations­arbete

    Portalen, mobilappen och nu en AI-assistent behöver samma data, och var och en får sitt eget uttag.

  4. 04

    Anslutningar till offentliga tjänster blir egna projekt

    Att ansluta till e-legitimation, Peppol eller en myndighets gemensamma tjänst tar månader av säkerhets- och anslutningsarbete varje gång.

02 Leveranser

Det här levererar vi

  1. 01 API-strategi och API-förvaltning

    API-design som utgår från kontrakt i OpenAPI och AsyncAPI, en versionspolicy, en gateway som upprätthåller den och en utvecklarportal där teamen hittar och återanvänder det som redan finns.

    Det här gör vi

    • Karta över API:er och deras ägare
    • Designriktlinjer och granskningsprocess
    • Gatewayregler för säkerhet, kvoter och versioner
    • Utvecklarportal och API-katalog

    Det här får du

    • API-riktlinjer som dina team har infört
    • Gatewaykonfiguration som kod
    • Katalog över dokumenterade API:er

  2. 02 Händelsedriven integration

    Meddelandeförmedlare, ändringsdatafångst och utkorgsmönstret, med de detaljer som avgör om det fungerar: ordning, idempotenta konsumenter, hantering av felade meddelanden och omspelning.

    Det här gör vi

    • Händelsemodell och namnkonventioner
    • Utkorg och CDC i källsystemen
    • Idempotenta konsumenter och garantier för ordning
    • Köer för felade meddelanden med verktyg för omspelning

    Det här får du

    • Händelseflöde i drift
    • Schemaregister och regler för kompatibilitet
    • Rutin för omspelning och återställning

  3. 03 Integrations­plattformar, valda per flöde

    SAP Integration Suite, MuleSoft och molnbaserade integrationstjänster har var och en sin plats. Vi säger när en integrationsplattform (iPaaS) slår egen kod, och när den inte gör det.

    Det här gör vi

    • Bedömning av befintlig mellanprogramvara
    • Val av plattform med total ägandekostnad
    • Återanvändbara mappningar och kopplingar
    • Migrering från äldre mellanprogramvara

    Det här får du

    • Dokumenterat beslut om integrationsplattform
    • Bibliotek med integrationsmönster
    • Migreringsplan för befintliga gränssnitt

  4. 04 Identitet och tillit mellan system

    OAuth 2.0 och OpenID Connect, ömsesidig TLS, identitet mellan tjänster och integration med e-legitimation för invånare: BankID, Freja+ och, från den 1 december 2026, den statliga e-legitimationen Sverige-id.

    Det här gör vi

    • Identitetsarkitektur för användare och tjänster
    • Utformning av token, behörigheter och samtycke
    • Stöd vid anslutning till e-legitimation
    • Förberedelser för europeiska digitala identitetsplånböcker

    Det här får du

    • Identitetsdesign och hotmodell
    • E-legitimation integrerad och i drift
    • Tjänsteidentiteter och rotation av hemligheter på plats

  5. 05 Anslutning till offentliga tjänster

    Anslutningar till Peppol för e-fakturor till och från offentliga köpare, till gemensamma grunddata och tjänster inom Ena, Sveriges digitala infrastruktur, och till EU:s tekniska system som bygger på engångsprincipen (OOTS). För verksamheter i flera länder kopplar vi också motsvarande nationella plattformar i andra EU-länder.

    Det här gör vi

    • Anslutning tillsammans med den som driver tjänsten
    • Mappning mot gemensamma standarder och format
    • Krav på säkerhet och loggning för varje anslutning
    • Utformning av utbyte av styrkande handlingar

    Det här får du

    • Godkänd anslutning till tjänsten
    • Dokumentation av mappningar
    • Driftrutiner tillsammans med den som driver tjänsten

  6. 06 Insyn i driften för verksamheten

    Övervakning av flöden som verksamheten kan läsa, avstämning mellan system och felköer som någon äger och arbetar av.

    Det här gör vi

    • Övervakning av flöden i verksamhetens termer
    • Avstämningsrapporter mellan system
    • Klassning och styrning av fel
    • Larm per flödesägare

    Det här får du

    • Integrationsöversikt per verksamhetsprocess
    • Avstämningskontroller i drift
    • Ägarkarta för varje felkö

03 Arkitektur

En illustrativ referens­arkitektur

Två vägar leder ut från de ursprungliga systemen. Synkrona anrop går via system-API:er och en gateway som kontrollerar identitet, behörigheter och kvoter. Ändringar publiceras som händelser via en utkorg eller ändringsdatafångst, och konsumenterna behandlar dem idempotent.

Felade meddelanden hamnar i en kö med omspelning, inte i en loggfil. Ett övervakningsband visar varje flöde i verksamhetens termer, så att den som äger en process ser när den stannar.

Lager i bilden

Ursprungliga system
Affärssystem, CRM och ärendehantering behåller ansvaret för sina data.
Synkrona API:er
Versionshanterade system-API:er bakom en gateway med OAuth 2.0, mTLS och kvoter.
Händelser
Utkorg, meddelandeförmedlare, felkö och mappningar i integrationsplattformen.
Konsumenter
Portaler, appar, agenter, partner och offentliga tjänster, med e-legitimation där invånare berörs.
Illustrativt exempel

  1. Ursprungliga system

    • Affärssystem, CRM och ärendesystem

  2. Synkrona API:er

    • System-API:er
    • API-gateway: OAuth 2.0, mTLS, kvoter

  3. Händelser

    • Utkorg och CDC
    • Meddelande­förmedlare
    • Felkö och omspelning
    • Mappningar i integrations­plattformen

  4. Konsumenter

    • Portaler, appar och agenter
    • Utbyten med partner och offentliga tjänster
    • Identitet: OIDC, mTLS, e-legitimation

  5. Drift

    • Flödes­övervakning, avstämning, felköer med ägare
API:er och händelseflöde sida vid sida

Illustrativ arkitektur, inte en kunds system.

Läs diagrammet som text

Huvudflödet går från de ursprungliga systemen via versionshanterade system-API:er och en API-gateway till portaler, appar och agenter.

Parallellt publicerar de ursprungliga systemen ändringar via en utkorg och ändringsdatafångst till en meddelandeförmedlare, som levererar dem till utbyten med partner och offentliga tjänster och till en integrationsplattform för mappningar. Felade meddelanden går till en kö med omspelning. Identitetstjänster med OAuth, mTLS och e-legitimation skyddar utbytena med partner.

Ett övervakningsband underst visar flödenas status, avstämning och felköer med ägare.

04 Överväganden och begränsningar

Tekniska överväganden och begränsningar

  • Exakt en gång är en design, inte en inställning

    Så hanterar vi det

    Vi utgår från att meddelanden kommer fram två gånger eller i fel ordning och utformar konsumenterna så att de är idempotenta, med nycklar och ordningsregler som avtalas per händelsetyp.

    Begränsningar och beroenden

    Vissa äldre system kan inte ta emot idempotensnycklar eller redovisa vad de har behandlat. Runt dem lägger vi till avstämning i stället för att låtsas.

  • En integrations­plattform är inte alltid svaret

    Så hanterar vi det

    Plattformar vinner för många standardkopplingar och mappningar. Egna tjänster vinner för komplex logik, stora volymer eller strikta krav på svarstid. Vi dokumenterar valet per integration.

    Begränsningar och beroenden

    Licensmodeller ändras. En plattform som är billig i dag kan bli den största posten i din integrationsbudget, så vi räknar på kostnaderna över flera år.

  • Offentliga tjänster sätter sin egen takt

    Så hanterar vi det

    Vi tar tidigt fram anslutningsunderlag, säkerhetsunderlag och testplaner och arbetar med den som driver tjänsten från första veckan.

    Begränsningar och beroenden

    Tidplanerna för godkännande och anslutning sätts av den som driver tjänsten, inte av oss. Vi planerar runt dem och visar var de ligger på den kritiska linjen.

  • AI-konsumenter behöver smala API:er

    Så hanterar vi det

    Agenter och assistenter får egna, avgränsade API:er med gränser och granskningsloggning, inte samma breda åtkomst som interna tjänster.

    Begränsningar och beroenden

    Att öppna ett API för en agent ökar risken. Vi granskar varje sådant API med din säkerhetsfunktion innan det går i drift.

05 Så arbetar vi

Så arbetar vi

Vi reder ut innan vi bygger, och varje flöde får en ägare.

  1. 01

    Kartlägg flödena

    Varje gränssnitt, dess volym, dess felhistorik och dess ägare i verksamheten.

    ResultatIntegrationskarta och riskrangordning

  2. 02

    Sätt reglerna

    API-riktlinjer, konventioner för händelser, identitetsmodell och val av plattform.

    ResultatIntegrationsriktlinjer och dokumenterade beslut

  3. 03

    Flytta flöde för flöde

    De mest riskfyllda flödena först, med avstämning bredvid det gamla gränssnittet tills siffrorna stämmer.

    ResultatFlyttade flöden med belägg från avstämningen

  4. 04

    Driv med full insyn

    Översikter per verksamhetsprocess och felköer med namngivna ägare.

    ResultatÄgarkarta för flöden och översikter

06 Mänsklig kontroll

Där människor behåller kontrollen

Integrationer körs utan tillsyn. Ansvaret för det som går fel kan inte göra det.

  • Varje felkö har en ägare

    Felade meddelanden går till ett team som ansvarar för dem, med sammanhang och en knapp för omspelning, inte till en gemensam logg.

  • Ändringar i kontrakt granskas

    Ändringar som bryter API:er eller händelser granskas med konsumenterna innan de publiceras.

  • Omspelning är ett medvetet beslut

    Att spela om meddelanden till ett ursprungligt system är en behörighetsstyrd åtgärd som loggas med vem som gjorde det och varför.

07 Tekniker

Tekniker vi arbetar med

Integrations­plattformar
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Integrationstjänster i AWS och Google Cloud
Händelser och strömmar
  • Apache Kafka
  • RabbitMQ
  • Meddelandeförmedlare i molnet
  • Debezium för ändringsdatafångst
API:er
  • OpenAPI och AsyncAPI
  • API-gateways och utvecklarportaler
  • GraphQL där det passar
  • Kontraktstester
Identitet
  • OAuth 2.0 och OpenID Connect
  • Ömsesidig TLS
  • Keycloak och identitetstjänster i molnet
  • BankID, Freja+ och Sverige-id

Att vi listar en teknik beskriver vår tekniska erfarenhet. Det innebär inte ett partnerskap med leverantören eller att leverantören står bakom oss.

08 Exempel

Ett illustrativt exempel

Illustrativt exempel

E-fakturor via Peppol för en leverantör till offentliga köpare

01Utgångsläge
Ett medelstort grossistföretag levererar till kommuner, regioner och statliga myndigheter. Fakturorna skapas i affärssystemet men skickas via en separat tjänst där uppgifter förs över för hand, och fakturor som saknar köparens referens kommer tillbaka.
02Det här skulle vi bygga
Affärssystemet kopplas till en Peppol-åtkomstpunkt så att utgående fakturor skickas i Peppol BIS Billing 3 med köparens referens från ordern, och inkommande e-fakturor från leverantörer matchas mot beställningar innan de går till attest.
03Här beslutar människor
Ekonomiavdelningen attesterar inkommande fakturor enligt företagets attestordning, och en namngiven ägare hanterar fakturor som avvisas eller inte kan matchas.
04Det här skulle vi mäta
Andel fakturor som skickas som e-faktura, antal fakturor som kommer tillbaka från offentliga köpare och tid från leverans till betalning.

09 Branscher

I din bransch

  • Offentlig sektor

    Gemensamma grunddata inom Ena, e-legitimation för invånare, e-fakturor via Peppol och den loggning som gemensamma tjänster kräver. Läs mer om vårt arbete inom offentlig sektor.

  • Tillverkningsindustri

    Affärssystem, MES och leverantörsportaler som kopplas ihop med händelser, så att planering, produktion och service delar samma bild.

  • Finansiella tjänster

    Kärnsystem, CRM och API:er mot partner som kopplas ihop med stark identitet, granskningsloggning och avstämning som ekonomifunktionen litar på.

Sverige

E-faktura, e-legitimation och Ena

Sedan den 1 april 2019 ska leverantörer fakturera upphandlande myndigheter och enheter med e-fakturor enligt europeisk standard (EN 16931), enligt lag (2018:1277). Upphandlingsmyndigheten rekommenderar Peppol BIS Billing 3 via Peppolnätverket och är sedan den 1 juli 2026 Sveriges Peppol Authority. Ett krav på e-faktura mellan företag finns inte i dag. Regeringen utreder hur ViDA ska föras in i svensk rätt, och utredningen redovisar senast den 30 november 2027; för gränsöverskridande transaktioner inom EU blir e-fakturering obligatorisk från den 1 juli 2030.

Från den 1 december 2026 ska offentliga aktörers e-tjänster för enskilda godta godkända e-legitimationer, däribland Sverige-id på tillitsnivå 4. Enligt eIDAS 2 ska EU-länderna erbjuda europeiska digitala identitetsplånböcker senast den 24 december 2026, och förordningen om ett interoperabelt Europa ber offentliga aktörer bedöma gränsöverskridande interoperabilitet. Vi bygger integrationslager där Peppol, e-legitimation och Ena är adaptrar bakom stabila interna kontrakt, så att en ny anslutning inte kräver ändringar i systemen bakom.

Frågor om integrationer och API:er

Ska vi använda en integrationsplattform eller bygga egna integrationer?

Båda, för olika flöden. Standardkopplingar, mappningar och anslutning av partner talar för en plattform. Flöden med stora volymer, krav på kort svarstid eller mycket logik talar ofta för egna tjänster. Vi beslutar per flöde och dokumenterar varför.

Integrerar ni Salesforce, SAP och Odoo?

Ja, regelbundet, med varandra och med egenutvecklade system och offentliga tjänster som Peppol. FromNine har partnerstatus hos alla tre (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), så våra integrationsteam arbetar sida vid sida med plattformsspecialister. Läs mer om vårt arbete med SAP.

Behöver vi händelsedriven integration?

När flera system behöver reagera på samma ändring, eller när du vill frikoppla releasecyklerna, hjälper händelser. För enkla anrop och svar mellan två system räcker ofta ett API. De flesta systemmiljöer använder båda.

Kan ni integrera e-legitimation?

Ja. Vi integrerar BankID, Freja+ och, från den 1 december 2026, Sverige-id, och vi utformar för de europeiska digitala identitetsplånböcker som medlemsstaterna ska erbjuda enligt eIDAS 2. Kraven för anslutning skiljer sig mellan e-legitimationerna, och vi planerar för dem tidigt.

Vi har äldre mellanprogramvara. Måste vi byta ut den?

Inte på en gång. Vi kartlägger vad som körs i den, flyttar de mest riskfyllda eller dyraste flödena först och behåller avstämningen tills varje flyttat flöde har visat sig fungera.

Ta med gränssnittet som fallerar oftast

Vi visar hur vi skulle göra det övervakat, idempotent och ägt, och vad som krävs för att göra detsamma för resten.

Berätta om ditt projektLäs om kundservice