Välja integrationsplattform
Börja med flödena, felbilden och förvaltningsansvaret. Produktlistan kommer senare.
Inventera innan ni jämför
Skriv en rad per verkligt flöde: avsändare, mottagare, format, volym, toppbelastning, svarstid, dataägare och vad verksamheten gör när flödet står still. Markera även batchfönster, certifikat, IP-regler och partnerberoenden. En plattform kan inte bedömas mot ordet ”integration”; den måste bedömas mot denna lista. Microsofts arkitekturguidning skiljer uttryckligen mellan direkta API-anrop, asynkron meddelandehantering, event och orkestrering.
Gör driftkraven mätbara
Krav som ”bra övervakning” går inte att prova. Skriv i stället hur ett misslyckat meddelande hittas, vem som larmas, hur nytt försök görs och hur en operatör ser att mottagarsystemet faktiskt uppdaterades. Bestäm återställningstid och tillåten dataförlust per flödesklass. Fråga sedan leverantören vilka loggar, köer och replay-funktioner som ingår och vilka som kräver ytterligare tjänster.
Jämför samma målbild
En offert för en enda molntjänst kan inte jämföras med en offert som även innehåller API-gateway, meddelandekö, nätverk och övervakning. Rita en enkel målbild och låt alla kandidater fylla samma funktioner: ingress, autentisering, transformation, orkestrering, kö, felhantering, loggning och deployment. Då blir frånvaron av en komponent synlig i stället för gömd i ett produktnamn.
Kör en pilot som kan misslyckas
Välj ett representativt flöde med minst ett riktigt felvillkor: dubblett, timeout, ogiltigt meddelande eller mottagare nere. Microsofts retry-vägledning varnar för att ett nytt försök kan utföra en icke-idempotent operation två gånger. Piloten ska därför visa både lyckad körning och kontrollerad återhämtning. Mät arbetstid, driftsättning och felsökning; räkna inte bara antal byggda steg.
Fatta beslutet med en ägare
Namnge vem som äger plattformen efter projektet, vem som uppgraderar runtimes och connectorer och vem som betalar den gemensamma driften. Om svaret är konsulten har ni inte köpt bort förvaltning; ni har lagt den utanför organisationen. Dokumentera också exit: exportformat, källkod, testfall, hemligheter, historik och hur ett flöde flyttas utan att båda versionerna skriver samtidigt.
Ett exempel: från orderflöde till kortlista
Anta att ett team ska föra order från en webbshop till ett ERP och fånga upp fel när ERP-systemet är nere. Exemplet är ett arbetssätt att prova, inte ett kundprojekt eller ett betyg på någon leverantör.
| Krav | Vad ni provar | Underlag för beslut |
|---|---|---|
| Rätt order i ERP | Skicka en testorder och följ affärsnyckeln hela vägen. | Spara fältmappning och mottagarens resultat för kandidat A och B. |
| Återhämtning | Stoppa mottagaren. Återställ den och skicka samma order igen. | Visa hur felet hittas och hur en dubbel order undviks. |
| Förvaltning | Låt en kollega deploya och felsöka med er instruktion. | Notera steg, arbetstid, behörigheter och vem som äger driften. |
Fyll först i kravbilden och kortlistan (CSV). Markera vilka krav som måste uppfyllas innan ni väljer kandidater i matrisen. Skriv öppna frågor som frågor, så att en katalogpost inte råkar bli ett godkänt test.
Prova sedan båda kandidaterna med samma data och felvillkor i pilotprotokollet (CSV). Välj utifrån de krav som blev uppfyllda, det arbete som återstår och vem som ska förvalta lösningen. Om ingen kandidat klarar ett avgörande krav behöver ni ändra kortlistan eller kravbilden innan ni går vidare.
Ett ifyllt pilotprotokoll: vad behöver bli bättre?
Här fortsätter orderexemplet med två tänkta kandidater, A och B. Namnen står inte för några produkter. Alla utfall är illustrativa och visar hur ett protokoll kan fyllas i; inga tester mot leverantörernas plattformar har utförts.
Vi föreslår att piloten omfattar korrekt orderhantering, säkra återkörningar och ett flöde som en kollega kan ta över. Sätt godkännandekriterierna tillsammans före demonstrationen och använd samma testdata för båda kandidaterna.
| Test | Kriterium i exemplet | Illustrativt utfall |
|---|---|---|
| Normalflöde | 100 unika order ger 100 rätt order i ERP. | A och B uppfyller kriteriet i exemplet. |
| Timeout efter skrivning | ERP sparar ordern men svaret försvinner. Retry ska lämna en order per affärsnyckel. | A skapar en extra order. B använder samma nyckel och behåller en order. |
| Dubblett och replay | Skicka samma order igen och återspela den från felkön. Ingen ytterligare affärseffekt. | A behöver en gemensam dubblettkontroll. B håller samma nyckel genom replay. |
| Felaktig data | En order utan artikelnummer stoppas med ett begripligt fel och går att hitta. | Båda stoppar ordern. A saknar affärsnyckel i larmet. |
| Deployment och rollback | Versionsbyte ska kunna backas med dokumenterade steg och rätt konfiguration. | A har en beskriven rollback. B behöver exportera och versionshantera miljökonfigurationen. |
| Drift och exit | En annan kollega ska kunna hitta felet, återställa flödet och ta över materialet. | A behöver bättre larminstruktioner. B behöver ett komplett överlämningspaket. |
Timeouttestet är särskilt värt att prova. Microsoft beskriver hur en operation kan ha lyckats även när svaret inte kommer fram. Ett nytt försök kan då upprepa affärseffekten om operationen inte är idempotent. Microsofts retry-mönster (läst 2026-10-03).
Beslutet i det här exemplet
A behöver åtgärda dubblettkontrollen och visa att hela felvägen använder samma affärsnyckel. B behöver visa versionshantering och en överlämning som går att följa. Båda får därför konkreta uppgifter inför en ny kontroll. Kostnaden får vägas in när de nödvändiga kraven är uppfyllda.
Hämta ifyllt pilotprotokoll (CSV)
Filen innehåller tio testfall per kandidat, med kriterium, illustrativt utfall, arbetstid, bevis som ska samlas in och nästa steg. Ersätt exempeluppgifterna med era egna körningar och loggreferenser. Använd det tomma protokollet när piloten börjar.
Koppla sedan resultaten till offertkalkylen. Extra arbete med larm, återställning och överlämning behöver också få plats i budgeten.
Ansvarig utgivare: Andreas Wänqvist, Axonis AB. Sidan uppdaterades .
Ansvarig för andragranskning: Nicklas Andersson, Integrationsarkitekt Axonis AB.