Hoppa till huvudinnehållet
FromNine
Meny

Programvara och moln

Integrationer som håller uppgifterna i rörelse och visar när de stannar.

Vi kopplar ihop CRM, affärssystem, ärendehantering och offentliga plattformar som Suomi.fi med kontrakt, händelser och ordentligt skött identitet. Uppgifterna flyttas tillförlitligt, felen syns och nya funktioner, också AI, kan anslutas på ett säkert sätt.

För organisationer i Finland som kopplar ihop egna system med partner, Suomi.fi-tjänsterna och Peppol-nätverket.

Berätta om ditt projektSalesforce, SAP och Odoo
Integrationer och API:er: skikten i tjänstenFyra skikt ovanpå varandra. Uppifrån och ned: de som använder uppgifterna, till exempel portaler, appar och agenter, API-gatewayen med identitetshantering, händelseryggraden och längst ned de system där uppgifterna förs.01Portaler, appar och agenter02API-gateway och identitet03Händelse­ryggrad04Källsystem
  1. 01Kontraktet skrivs först, i OpenAPI eller AsyncAPI, och varje API är versionerat och dokumenterat
  2. 02Händelser levereras i rätt ordning, tål dubbletter och kan spelas upp igen ur felkön
  3. 03Varje flöde övervakas från början till slut, och felköerna har namngivna ägare

01 Utmaningar

Typiska skäl till att vi kallas in

  1. 01

    Direktkopplingar som ingen vågar ändra

    Dussintals direkta förbindelser mellan CRM, affärssystem och egna system. Ett ändrat fält kräver tester i tio gränssnitt.

  2. 02

    Dubbletter och fel som ingen märker

    Ett nytt försök ger en dubbel order, ett meddelande som misslyckas försvinner spårlöst och verksamheten hör det först från kunderna.

  3. 03

    Varje ny kanal betyder nytt integrations­arbete

    Portalen, mobilappen och nu en AI-assistent vill ha samma uppgifter, och var och en får sitt eget uttag.

  4. 04

    Fakturor som inte räknas som nätfakturor

    Affärssystemet skickar PDF-fakturor per e-post, men staten tar bara emot nätfakturor och allt fler kunder begär dem. Varje ny mottagare blir ett eget litet projekt.

02 Leveranser

Det här levererar vi

  1. 01 API-strategi och API-hantering

    Kontrakten skrivs först, i OpenAPI och AsyncAPI. Regler för versioner genomdrivs av en gateway, och i en utvecklarportal hittar teamen det som redan finns innan de bygger nytt.

    Det här gör vi

    • Karta över API:erna och deras ägare
    • Riktlinjer för utformning och en 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 tagit i bruk
    • Gatewaykonfiguration som kod
    • Katalog över dokumenterade API:er

  2. 02 Händelsestyrd integration

    Meddelandeförmedlare, ändringsdatafångst och outbox-mönstret, och framför allt detaljerna som avgör om det håller: ordningsföljd, mottagare som tål dubbletter, felköer och uppspelning.

    Det här gör vi

    • Händelsemodell och namngivningsregler
    • Outbox och ändringsdatafångst i källsystemen
    • Idempotenta mottagare och garanterad ordningsföljd
    • Felköer med verktyg för uppspelning

    Det här får du

    • Händelseryggrad i produktion
    • Schemaregister och regler för kompatibilitet
    • Driftinstruktion för uppspelning och återställning

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

    SAP Integration Suite, MuleSoft och molnleverantörernas integrationstjänster passar för olika saker, och vi säger öppet när en iPaaS lönar sig bättre än egen kod och när den inte gör det. Nätfakturor via Peppol går ofta enklast genom en operatör eller en plattform med färdig anslutning.

    Det här gör vi

    • Bedömning av befintliga mellanprogram
    • Val av plattform med totalkostnad över tid
    • Återanvändbara mappningar och kopplingar
    • Migrering från äldre mellanprogram

    Det här får du

    • Beslutsunderlag för valet av integrationsplattform
    • Bibliotek med integrationsmönster
    • Migreringsplan för befintliga gränssnitt

  4. 04 Identitet och förtroende mellan system

    OAuth 2.0 och OpenID Connect, ömsesidig TLS, identiteter för tjänster och integration med identifiering för invånare och företag: Suomi.fi-identifikation, där användaren identifierar sig till exempel med nätbankskoder, mobilcertifikat eller certifikatkort, och Suomi.fi-fullmakter, samt motsvarande lösningar i andra länder.

    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 Suomi.fi-tjänsterna
    • Förberedelser för EU:s digitala identitetsplånbok

    Det här får du

    • Identitetsdesign och hotmodell
    • Identifiering i produktion
    • Tjänsteidentiteter och byte av hemligheter i drift

  5. 05 Samverkan med offentliga plattformar

    Anslutningar till Suomi.fi-tjänsterna, bland dem Suomi.fi-informationsleden för överföring av uppgifter mellan offentliga och privata organisationers system, till Peppol för nätfakturor enligt Europanormen och till EU:s tekniska system för engångsprincipen. Motsvarande nationella plattformar i andra länder ansluts som egna adaptrar.

    Det här gör vi

    • Anslutning i samarbete med den som driver plattformen
    • Mappning till nationella datastandarder
    • Krav på säkerhet och loggning för varje plattform
    • Utformning av utbytet av underlag enligt engångsprincipen

    Det här får du

    • Godkänd anslutning till plattformen
    • Dokumentation av mappningarna
    • Driftrutiner tillsammans med plattformens förvaltare

  6. 06 Överblick över driften för verksamheten

    Övervakning som verksamheten själv kan läsa, avstämning mellan systemen och felköer som har en ägare som arbetar sig igenom dem.

    Det här gör vi

    • Övervakning av flödena i verksamhetens termer
    • Avstämningsrapporter mellan systemen
    • Klassificering och styrning av fel
    • Larm till varje flödes ägare

    Det här får du

    • Integrationsvy för varje verksamhetsprocess
    • Avstämningskontroller i produktion
    • Karta över vem som äger varje felkö

03 Arkitektur

En illustrativ referens­arkitektur

Från källsystemen går två vägar. Synkrona anrop passerar system-API:er och en gateway som prövar identitet, behörigheter och kvoter. Ändringar skickas som händelser via en outbox eller ändringsdatafångst, och mottagarna hanterar dem så att en dubblett inte gör skada.

Ett meddelande som inte går fram hamnar i en felkö där det kan spelas upp igen, inte i en loggfil. Längst ned visar ett övervakningsband varje flöde med verksamhetens begrepp, så att processägaren ser när något stannar.

Skikten i bilden

Källsystem
Affärssystem, CRM och ärendehantering behåller ansvaret för sina uppgifter.
Synkrona API:er
Versionerade system-API:er bakom en gateway med OAuth 2.0, ömsesidig TLS och kvoter.
Händelser
Outbox, meddelandeförmedlare, felkö och mappningar i integrationsplattformen.
Mottagare
Portaler, appar, agenter, partner och offentliga plattformar, med Suomi.fi-identifikation där invånare är inblandade.
Illustrativt exempel

  1. Källsystem

    • Affärssystem, CRM och ärendehantering

  2. Synkrona API:er

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

  3. Händelser

    • Outbox och ändrings­datafångst
    • Meddelande­förmedlare
    • Felkö och uppspelning
    • Mappningar i integrations­plattformen

  4. Mottagare

    • Portaler, appar och agenter
    • Partner och offentliga plattformar
    • Identitet: OIDC, mTLS, Suomi.fi

  5. Drift

    • Övervakning av flöden, avstämning, felköer med ägare
API:er och en händelseryggrad sida vid sida

Illustrativ arkitektur, inte ett kundsystem.

Läs diagrammet som text

Bilden visar hur källsystemen når portaler, appar och agenter via versionerade system-API:er och en API-gateway.

Vid sidan av publicerar källsystemen ändringar via en outbox och ändringsdatafångst till en meddelandeförmedlare. Den levererar dem till partner och offentliga plattformar och till en integrationsplattform som sköter mappningarna. Meddelanden som inte går fram hamnar i en felkö med uppspelning, och identitetstjänster med OAuth, ömsesidig TLS och elektronisk identifiering skyddar utbytet med partner.

Ett övervakningsband längst ned visar hur flödena mår, avstämningen och felköerna med sina ägare.

04 Överväganden och gränser

Tekniska avvägningar och gränser

  • Exakt en gång kräver arbete

    Så hanterar vi det

    Vi räknar med att meddelanden kommer dubbelt eller i fel ordning, och mottagarna byggs så att det inte gör något. Nycklar och ordningsregler bestäms för varje typ av händelse.

    Gränser och beroenden

    En del äldre system tar inte emot idempotensnycklar och kan inte berätta vad de har behandlat. Där lägger vi till avstämning i stället för att låtsas att problemet inte finns.

  • En iPaaS passar inte överallt

    Så hanterar vi det

    För standardkopplingar och mappningar vinner ofta en plattform. För tung logik, stora volymer eller hårda krav på svarstid vinner oftare egna tjänster. Valet motiveras skriftligt för varje integration.

    Gränser och beroenden

    Licensvillkoren ändras. Det som är billigt i dag kan bli den största kostnaden i integrationsbudgeten, och därför räknar vi på flera år framåt.

  • Offentliga plattformar har egna tidtabeller

    Så hanterar vi det

    Ansökningar, säkerhetsunderlag och testplaner förbereds tidigt, och vi samarbetar med plattformens förvaltare redan första veckan, till exempel när en tjänst ansluts till Suomi.fi.

    Gränser och beroenden

    Hur lång tid godkännandet och anslutningen tar bestämmer förvaltaren, inte vi. Vi planerar efter det och visar om det ligger på den kritiska linjen.

  • AI-tjänster ska ha smala API:er

    Så hanterar vi det

    Agenter och assistenter får egna API:er med snäva behörigheter, gränser och revisionslogg, inte samma breda åtkomst som interna tjänster har.

    Gränser och beroenden

    Varje API som en agent får använda ökar risken. Innan det tas i drift går vi igenom det med dem som ansvarar för informationssäkerheten.

05 Arbetssätt

Så arbetar vi

Först reder vi ut härvan, sedan bygger vi, och varje flöde får en ägare.

  1. 01

    Kartlägg flödena

    Alla gränssnitt med volym, felhistorik och vem i verksamheten som äger dem.

    ResultatIntegrationskarta med riskrangordning

  2. 02

    Bestäm spelreglerna

    Riktlinjer för API:er, regler för händelser, identitetsmodell och val av plattform.

    ResultatRiktlinjer och beslutsunderlag

  3. 03

    Flytta ett flöde i taget

    De riskablaste flödena först, med avstämning mot det gamla gränssnittet tills siffrorna går ihop.

    ResultatFlyttade flöden och avstämningsresultat

  4. 04

    Synlig drift

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

    ResultatÄgarkarta och översiktsvyer

06 Mänsklig kontroll

Där människor behåller kontrollen

Integrationerna sköter sig själva. Ansvaret när något går fel ligger ändå hos människor.

  • Varje felkö har någon som ansvarar

    Ett meddelande som misslyckas hamnar hos ett ansvarigt team, med underlaget och en knapp för att spela upp det igen, inte i en gemensam logg.

  • Kontrakts­ändringar granskas först

    Ändringar som bryter ett API eller en händelse gås igenom med mottagarna innan de publiceras.

  • Ingen uppspelning av misstag

    Bara den som har behörighet får spela upp meddelanden till ett källsystem, och det loggas vem som gjorde det och varför.

07 Teknik

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
  • Molnleverantörernas meddelandeförmedlare
  • Debezium för ändringsdatafångst
API:er
  • OpenAPI och AsyncAPI
  • API-gatewayer och utvecklarportaler
  • GraphQL där det passar
  • Kontraktstester
Identitet
  • OAuth 2.0 och OpenID Connect
  • Ömsesidig TLS
  • Keycloak och molnleverantörernas identitetstjänster
  • Suomi.fi-identifikation och andra nationella lösningar

Teknikerna nämns för att visa vilken erfarenhet vi har. Det betyder inte att vi är partner till tillverkarna eller att de har gått i god för oss.

08 Exempel

Ett illustrativt exempel

Illustrativt exempel

Nätfakturor från affärssystemet till offentliga köpare

01Utgångsläge
En tillverkare av inredning säljer till kommuner, välfärdsområden och statliga myndigheter. Fakturorna skrivs ut ur ett äldre affärssystem som PDF, och ekonomiavdelningen får dem tillbaka eftersom köparna bara tar emot nätfakturor.
02System
En integration som bildar nätfakturor enligt Europanormen ur affärssystemet och skickar dem via en Peppol-operatör, med mottagarens referenser och beställningsnummer från ordern och en felkö för fakturor som avvisas.
03Mänsklig kontroll
Ekonomiavdelningen godkänner fakturor över ett gränsvärde och alla kreditnotor innan de skickas, och ägaren av felkön bestämmer om en avvisad faktura rättas eller skickas på nytt.
04Det här skulle vi mäta
Andelen fakturor som går ut som nätfakturor utan manuell hantering, antalet avvisade fakturor per månad och tiden från leverans till betalning.

09 Branscher

I din bransch

  • Offentlig sektor

    Uppgifter som hämtas en gång ur den källa där de förs, Suomi.fi-identifikation och Suomi.fi-fullmakter för invånare och företag och den loggning som de offentliga plattformarna kräver. Läs mer om vårt arbete inom offentlig sektor.

  • Tillverkningsindustri

    Affärssystem, MES och leverantörsportaler kopplade via händelser, så att planering, produktion och service delar samma bild och nätfakturorna går ut direkt ur affärssystemet.

  • Finansiella tjänster

    Kärnsystem, CRM och partner-API:er kopplade med stark identitet, revisionsloggning och en avstämning som ekonomiavdelningen litar på.

Finland

Suomi.fi, nätfakturor och EU:s identitets­plånbok

De flesta offentliga e-tjänster i Finland ansluter till Suomi.fi-tjänsterna, som Myndigheten för digitalisering och befolkningsdata (MDB) producerar under finansministeriet. Statliga och kommunala myndigheter ska erbjuda Suomi.fi-identifikation i sina lagstadgade tjänster, och Suomi.fi-informationsleden är ett standardiserat och frivilligt sätt att överföra uppgifter mellan offentliga och privata organisationers system.

Nätfakturan är vardag. Lagen om elektronisk fakturering (241/2019) gäller för staten sedan 1 april 2019, upphandlande enheter ska kunna ta emot och behandla elektroniska fakturor och sedan 1 april 2020 har företag och upphandlande enheter rätt att på begäran få sina fakturor från varandra som nätfakturor. Statskontoret är Finlands Peppol-myndighet.

På EU-nivå ska medlemsstaterna tillhandahålla digitala identitetsplånböcker enligt eIDAS 2 senast 24 december 2026; enligt MDB lanseras plånboksapplikationen i Finland 2027. Förordningen om ett interoperabelt Europa kräver att offentliga organisationer bedömer den gränsöverskridande interoperabiliteten. Vi bygger integrationsskikt där nationella plattformar och identifieringslösningar är adaptrar bakom stabila interna kontrakt, så att ett nytt land eller en ny plattform blir en ny adapter och inte en ombyggnad.

Frågor om integrationer och API:er

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

Både och, beroende på flödet. Standardkopplingar, mappningar och anslutning av nya partner talar för en plattform, medan stora volymer, korta svarstider eller mycket logik oftare talar för egna tjänster. Vi avgör det flöde för flöde och skriver ned motiveringen.

Integrerar ni Salesforce, SAP och Odoo?

Ja, ofta, både med varandra och med egna och offentliga system. FromNine är partner till alla tre (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), så integrationsteamen arbetar tillsammans med specialister på plattformarna. Läs mer om vårt integrationsarbete med SAP.

Kan ni koppla vårt affärssystem till Peppol för nätfakturor?

Ja. Enligt lagen om elektronisk fakturering (241/2019) ska upphandlande enheter kunna ta emot och behandla elektroniska fakturor, och företag och upphandlande enheter har rätt att på begäran få sina fakturor från varandra som nätfakturor. Staten tar endast emot nätfakturor, och en PDF-faktura per e-post räknas inte som nätfaktura. Statskontoret är Finlands Peppol-myndighet. Vi kopplar affärssystemet till Peppol via en operatör, så att fakturorna följer Europanormen (EN 16931), ekonomin godkänner dem innan de skickas och varje avvisad faktura hamnar i en felkö med en ägare.

Kan ni integrera Suomi.fi-identifikation och EU:s identitetsplånbok?

Ja. Statliga och kommunala myndigheter ska erbjuda identifiering via Suomi.fi-identifikation i sina lagstadgade tjänster, och privata aktörer får använda den för lagstadgade uppgifter som de har fått i uppdrag att sköta. Vi förbereder också för EU:s digitala identitetsplånbok enligt eIDAS 2, som medlemsstaterna ska tillhandahålla senast 24 december 2026. Enligt MDB lanseras plånboksapplikationen i Finland 2027.

Vi har ett äldre mellanprogram. Måste vi byta ut det?

Inte på en gång. Vi kartlägger vad som körs i det, flyttar först de flöden som är mest riskabla eller kostar mest och låter avstämningen vara kvar tills varje flyttat flöde har visat att det fungerar.

Vilket gränssnitt krånglar oftast?

Vi visar hur det blir övervakat, tål dubbletter och får en ägare, och vad det skulle kräva att göra samma sak med resten.

Berätta om ditt projektLäs om kundservice