Integrationer i affärssystem: API eller filöverföring?

Vad en integration i ett affärssystem faktiskt gör

En systemintegration är en teknisk process som kopplar samman flera system så att de kan kommunicera med varandra. Kopplingen kan göras på olika sätt – till exempel genom att skapa ett API eller använda en integrationsplattform, enligt Fortnox företagsguide om integrationer och API. För att data ska komma fram rätt krävs en brygga som skickar kommunikationen mellan systemen, och informationen måste vara kodad så att mottagaren kan ta emot den. Systemen behöver med andra ord prata samma ”språk”.

Fortnox lyfter fram tre effekter av att koppla ihop sina system: dubbelarbete i olika system försvinner, risken för manuella fel minskar och beslutsunderlaget blir bättre när informationen samlas på ett ställe. Som exempel nämner de hantverkare som får rätt faktura kopplad till rätt projekt, en webbshop med uppdaterat lagersaldo och en restaurang som tar emot bokningar online.

API och filöverföring är två tekniska vägar till samma mål. Vilken som är relevant beror på vad systemet erbjuder för kontaktytor och vilket flöde som ska kopplas – inte på vilken väg som är ”modernast” i allmänhet.

API: direktkontakt med affärssystemet

Ett API är en kontaktyta som låter egna system och tredjepartstjänster hämta och skicka data, enligt Weapp. Fortnox API är organiserat kring REST, vilket innebär resursorienterade URL:er och ett förutsägbart upplägg. I en genomgång av fem svenska affärssystem beskrivs Fortnox API som RESTful med OAuth2 och med dokumentation som är förhållandevis lättillgänglig jämfört med de äldre systemen; slutsatsen där är att den som redan kan REST och OAuth2 sannolikt kommer igång relativt snabbt. Samma genomgång beskriver Visma eEkonomi som ett modernt REST-API i linje med Fortnox, men med något mer fragmenterad dokumentation.

API-mognaden varierar, både mellan leverantörer och inom samma leverantörs produktlinjer. Weapp pekar ut tre saker som avgör hur tungt arbetet blir: hur genomtänkt och komplett gränssnittet är och hur väl det täcker de delar av ekonomisystemet man behöver nå, hur väl dokumentationen beskriver användningen, och rate limits – gränserna för hur ofta API:et får anropas. Hogia beskrivs som en familj produkter med varierande modernitet, där Hogia Lön Plus ofta lyfts fram som ett bra API medan vissa branschanpassningar inte har något API alls. Visma Software Nordic erbjuder gratis tillgång till API:er, demomiljö och dokumentation för sina molnlösningar, riktat till ISV-partners och integratörer.

Ett praktiskt råd från genomgången av de svenska systemen: börja med en läsande integration och lägg på skrivande anrop först när den fungerar. Det minskar risken om ett skrivande anrop skulle bete sig oväntat.

I vilken ordning integrationen bör byggas

Filöverföring och export/import: när API saknas eller inte räcker

Filbaserad integration innebär att data lämnar systemet som en fil – ofta Excel eller ett annat tabellformat – och läses in i mottagande system enligt ett schema. Körningen kan automatiseras med ett skript eller en agent, men överföringen sker vid bestämda tillfällen och inte som ett svar på en händelse i stunden. I vissa fall sker åtkomsten i stället via databasvyer, det vill säga att integrationen läser direkt ur systemets databas.

Genomgången av svenska affärssystem ger flera konkreta exempel på när fil- eller databasvägen blir aktuell. Visma Spcs-familjen är äldre än eEkonomi och vissa integrationer kräver en agent installerad lokalt på kundens server. För Pyramid Business Studio går mycket via SQL-vyer mot databasen direkt; det fungerar, men kan kräva att kunden öppnar nätverkstillgång på ett sätt som en försiktig IT-avdelning tvekar inför. För Hogia gäller att vissa branschanpassningar inte har något API alls och kräver export-import via Excel.

Konsekvensen är att filvägen ofta innebär mer manuell hantering och en fördröjning mellan systemen, men den kan samtidigt vara den enda väg som är praktiskt möjlig i ett äldre eller branschanpassat system. Att vägen är filbaserad betyder inte att den måste vara manuell – den kan schemaläggas och köras automatiskt.

API eller filöverföring? Så skiljer sig vägarna i praktiken

Jämför utifrån era egna förutsättningar: behöver data vara aktuell direkt eller räcker det med en schemalagd körning? Hur stora volymer ska passera, och hur förhåller de sig till API:ets rate limits? Hur ska fel upptäckas och hanteras, och vem larmas? Hur spårar ni vad som överförts? Vilka behörigheter och licensierade användare krävs? Vilken teknisk kompetens finns internt eller hos partner? Och hur lätt blir det att koppla på nästa system?

Rate limits är den punkt som lätt underskattas, enligt Weapp. Snäva gränser för hur ofta API:et får anropas kan bromsa flöden med stora volymer, till exempel när många ordrar eller fakturor ska synkas i ett svep. För en liten verksamhet med få transaktioner spelar det mindre roll, men för en med hög volym kan det bli en flaskhals. Rådet därifrån är att kontrollera gränserna mot sina faktiska volymer innan man bestämmer sig.

Att en integration är API-baserad betyder inte automatiskt realtid. Fortnox beskriver sin integration mot Severa som en synkronisering var femte minut – data är alltså aktuell inom ett intervall, inte vid varje händelse. Den som behöver styra på fördröjning bör därför fråga efter vilket intervall som faktiskt gäller, oavsett teknisk väg.

Valet får konsekvenser längre fram. Ekonomisystemet blir sällan en isolerad ö utan tenderar att bli en central nod som nya butiker, verktyg och affärssystem kopplas mot över tid, enligt Weapp. Ett moget och väldokumenterat API med rimliga gränser gör den första integrationen hanterbar och de följande betydligt enklare; en filväg som byggs för ett specifikt system kan behöva göras om när nästa system tillkommer.

API eller filöverföring – så skiljer sig vägarna i praktiken

Vanliga integrationsflöden och deras svårighetsgrad

Ordersynk innebär att ordrar från en webbutik eller ett affärssystem förs över för fakturering. Enligt Weapp är det ofta ett rättframt flöde, men känsligheten ökar med volymen och med hur mycket data som ska matchas rätt mellan systemen. En webbshop kan exempelvis hantera produkter på ett enda ställe, synka lagersaldon och priser samt skicka över ordrar automatiskt, enligt Knockout Webbyrå.

Fakturaunderlag är enligt Weapp vanligtvis en av de mer lättillgängliga integrationerna: underlag skapas automatiskt i ekonomisystemet i stället för att knappas in för hand, vilket är en av de integrationer som sparar mest manuellt arbete. Fortnox integration mot Severa visar vad ett sådant flöde kan omfatta i praktiken – projekt, kunder, fakturor och kostnader synkroniseras, kunddata och adresser överförs, projektstatus uppdateras, fakturor hanteras utifrån förbestämda statusar och leverantörsfakturor integreras som projektkostnader. Den integrationen kräver Fortnox API-åtkomsträttigheter och att användaren autentiserar sig med sina Fortnox-inloggningsuppgifter.

Löneflöden är känsligare. Weapp pekar på att kraven på korrekthet är höga och felmarginalen liten, vilket gör att sådana integrationer kräver mer omsorg oavsett vilket system man valt. Det hänger alltså i högre grad på datakänsligheten i flödet än på om överföringen sker via API eller fil.

Slutsatsen från Weapps genomgång är att svårighetsgraden inte enbart hänger på systemvalet utan på vilket flöde som byggs: ett enkelt case kan vara smidigt i båda systemen, ett komplext kräver noggrannhet i båda.

Integrationsflöden – från enklast till svårast

Fallgropar som avgör om integrationen lyckas

Behörigheter är den mest underskattade delen. För att en agent ska kunna läsa eller skriva i ett affärssystem behövs en användare med rätt rättigheter, ofta licensierad. Den användaren ska skapas, dokumenteras, tas med i revisioner och bytas ut om någon slutar. Genomgången av de svenska systemen uppskattar – som en egen tumregel snarare än en mätning – att en påtaglig del av tiden för en första integration går åt till behörighetsfrågor snarare än till kod. Fortnox integration mot Severa kräver exempelvis API-åtkomsträttigheter och autentisering med användarens Fortnox-inloggningsuppgifter.

Fråga alltid vilken produkt integrationen gäller. Visma eEkonomi och Visma Spcs är två olika produktlinjer med två olika API:er, och skillnaden i komplexitet mellan dem beskrivs som stor. På samma sätt varierar Hogias produkter i modernitet, där vissa branschanpassningar kräver export-import via Excel i stället för API.

Fragmenterad eller indirekt dokumentation fördyrar arbetet. Visma eEkonomis dokumentation beskrivs som något mer fragmenterad än Fortnox, och Monitors dokumentation pekar ofta på leverantörens eget utvecklarforum snarare än på rena referensmanualer; rådet därifrån är att ta in en konsult parallellt vid den första integrationen. Be därför om att få se API-dokumentationen innan man lovar en kund att data ska in i en automation.

Rate limits kan bromsa stora volymer och utgöra en flaskhals vid synkning i svep. Lokala agenter och SQL-åtkomst via databasvyer löser åtkomsten men kräver installation respektive nätverkstillgång som en försiktig IT-avdelning kan tveka inför. Och oavsett system: börja med ett läsande anrop och lägg på skrivande först när det läsande flödet fungerar.

Rekommendation: välj integrationsväg efter systemets verklighet

Kartlägg systemets faktiska API-mognad, inte marknadsföringens. Granska hur komplett gränssnittet är för de delar ni behöver nå, hur dokumentationen ser ut och vilka rate limits som gäller – och ställ gränserna mot era egna volymer innan ni bestämmer er. Fråga alltid vilken produkt det gäller, eftersom två produktlinjer från samma leverantör kan ha helt olika API:er och olika komplexitet.

Planera för behörigheter tidigt: bestäm vilken användare integrationen ska köra som, säkerställ rätt rättigheter och licens, dokumentera kontot och bestäm vem som äger det när personal slutar. Välj filöverföring när API saknas, när tillgången kräver en lokal agent ni inte kan driftsätta, eller när gränssnittet är för begränsat för era volymer – men räkna då med fördröjning och mer manuell hantering.

Checklista inför beslut: Vilket system och vilken produktlinje gäller det? Finns ett API, och är det REST-baserat med stöd för den autentisering ni kan hantera? Hur ser dokumentationen ut, och har ni läst den? Vilka rate limits gäller, och hur förhåller de sig till er toppvolym? Vilka användare och licenser krävs för integrationen, och vem ansvarar för dem? Vilka flöden ska byggas först, och kan ni börja läsande? Vilken fördröjning är acceptabel i respektive flöde? Hur upptäcks och hanteras fel, och vem larmas? Och hur påverkas nästa system som ska kopplas på?

Checklista inför val av integrationsväg