Integration fejler: Skal I reparere eller erstatte den?

Første skridt: Begræns konsekvensen

Udpeg en ansvarlig, og noter, hvilke systemer, tidsrum og poster der er berørt. Skeln mellem forsinket behandling, manglende data og forkerte handlinger. Det er forskellige problemer og kræver ikke nødvendigvis samme indgreb.

Undgå at trykke gentagne gange på “prøv igen”, før I ved, om målsystemet allerede har modtaget handlingen. Ved eksempelvis fakturaer kan en timeout betyde, at handlingen lykkedes, selv om afsenderen ikke fik et svar.

• Gem relevante fejlbeskeder, tidsstempler og interne reference-id’er.
• Aftal med den ansvarlige, om en berørt del skal sættes på pause. Stop ikke andre fungerende flows uden grund.
• Registrér manuelle rettelser, så de ikke senere bliver gentaget automatisk.
• Del ikke adgangsnøgler, adgangskoder eller fulde kundedata i en almindelig kontaktformular.

Find årsagen — ikke bare symptomet

Start med ét konkret eksempel og følg det fra kilden til målet. Find den seneste kendte vellykkede behandling, og undersøg, hvad der er ændret siden. En ny varetype, en ændret tilladelse eller et udløbet token kan være lige så relevant som ny kode.

At systemerne kan forbindes igen, betyder ikke, at alle mellemliggende poster er behandlet. Afstem bagefter, hvad der faktisk mangler eller er blevet ændret forkert.

Tre veje videre

Reparér, når fejlen er afgrænset

En rettelse er ofte den rigtige vej, hvis årsagen kan forklares, løsningen ellers matcher behovet, og ændringen kan testes. Det kan være en feltregel, en tilladelse eller håndtering af en specifik undtagelse. Kræv en test af det oprindelige fejlscenarie, ikke kun en normal gennemkørsel.

Udskift den svage del, når resten fungerer

Måske er forbindelserne gode, men fejlopsamlingen utilstrækkelig. En afgrænset forbedring af status, alarmer eller behandling kan være mere fornuftig end et helt nyt system. Afklar dog, om den eksisterende løsning tillader og understøtter udvidelsen.

Erstat, når fundamentet ikke matcher kravene

En ny løsning kan være relevant, hvis nødvendige funktioner mangler, ingen kan vedligeholde den, eller dokumentation og adgang ikke kan skaffes. Gentagne fejl er et tegn på behov for undersøgelse — ikke i sig selv bevis for, at alt skal bygges om.

Sammenlign både ændringsarbejde, løbende drift og risiko ved flytning. Læs guiden om integrationspris og forløb, før I sammenligner tilbud.

Genbehandling skal være kontrolleret

En robust løsning må ikke antage, at en besked altid kommer præcis én gang og i rigtig rækkefølge. Shopify dokumenterer eksempelvis både gentagne leveringer og begrænsninger ved rækkefølge og levering. De konkrete garantier skal kontrolleres for hver leverandør.

Aftal, hvordan genforsøg genkendes, og hvordan I opdager poster, som aldrig kom frem. Før en genkørsel skal I vide, hvilke handlinger allerede er udført. Test på et afgrænset udvalg, kontrollér resultatet, og udvid først derefter.

Ved udskiftning skal der desuden være en tydelig overgang: Hvilken løsning ejer hvilke poster hvornår? Hvordan undgår I, at begge skriver samtidig? Hvad gør I, hvis den nye løsning må stoppes?

Det kan I forberede til en fejlafklaring

1. Navnene på systemerne og på den eksisterende integrationsleverandør, hvis I kender den.
2. Et kort eksempel på det forventede og det faktiske resultat.
3. Hvornår problemet begyndte, og om det gælder alle eller enkelte poster.
4. Hvem der har adgang til opsætning, logning og dokumentation.
5. Hvad problemet betyder for driften, og hvordan I håndterer det midlertidigt.

Send først en beskrivelse uden følsomme data. REVL kan derefter afklare, hvilket materiale og hvilken adgang der er nødvendig. En indledende samtale er ikke en garanti for akut fejlretning eller et bestemt svartidsvindue; det skal aftales særskilt.

Brug også tjeklisten til integrationer, når kravene til den videre drift skal på plads.