Integrationer og workflows

Et integrationsworkflow skal vise, hvilke data der flyttes, hvad der starter overførslen, og hvordan I ser, om handlingen blev gennemført.

Begynd med ét konkret forløb fra kildepost til resultat i målsystemet.

Beskriv hele forløbet

Antag, at en godkendt kundeordre skal oprette en intern arbejdsopgave. Definér først, hvad »godkendt« betyder i kildesystemet. Angiv de nødvendige felter, deres ejere og den reference, der forbinder ordre og opgave.

Følg kæden udløser → kontrol af data → oprettelse eller opdatering → kontrol af resultat → håndtering af fejl. En kvittering for modtagelse af en besked beviser ikke, at opgaven blev oprettet.

Integrationsskridt fra kundeordre til intern arbejdsopgave

Vælg en passende udløser

En webhook kan give besked om en understøttet hændelse. Planlagte API-kald søger efter ændringer med et aftalt interval.

Vælg ud fra den forsinkelse, arbejdet kan tåle, og undersøg den konkrete leverandørs hændelser, søgemuligheder og begrænsninger. En periodisk afstemning kan lede efter poster, som ikke nåede frem via en webhook.

Udløseren bør kun sætte relevante handlinger i gang. GitHub anbefaler eksempelvis kun at abonnere på nødvendige webhook-hændelser og at kontrollere både hændelsestype og handling, før payloaden behandles.

Hvis GitHub-webhooks indgår, anbefaler GitHub også en hemmelig nøgle til at kontrollere leveringen, HTTPS og aktiveret SSL-verifikation. Det er leverandørspecifikke kontrolpunkter, så undersøg altid, hvilke tilsvarende muligheder den valgte løsning giver.

Udløsere i integrationer: Webhooks vs. Planlagt API-kald

Brug af webhook vs. planlagt afstemning – fordele og ulemper

Fastlæg data og ansvar

Skriv en feltoversigt med betydning, format, tilladte værdier og gældende kilde. »Dato« er for upræcist, hvis det ene system mener oprettelsesdato og det andet leveringsdato. Beslut, hvad der sker ved tomme felter og ukendte statusværdier.

Kontrollér både format og betydning før videresendelse. Send kun de oplysninger, modtageren behøver. Hvis forløbet omfatter personoplysninger, skal formål, dataminimering og rigtighed vurderes for den konkrete behandling.

Når workflowet behandler personoplysninger, skal formålet være klart ved indsamlingen, og oplysningerne må ikke senere bruges til formål, der er uforenelige med det oprindelige. Datatilsynet fremhæver også, at behandlingen skal begrænses til det nødvendige, at oplysninger skal ajourføres, og at urigtige oplysninger skal slettes eller berigtiges.

Planlæg, hvem der må rette en oplysning, og hvilket system der efter rettelsen er gældende kilde. Tag stilling til, hvornår oplysninger ikke længere er nødvendige, så de kan anonymiseres eller slettes, og hvordan adgangen begrænses, så oplysninger ikke kommer uvedkommende til kendskab eller går tabt.

Checkliste til sikker håndtering af personoplysninger i integrationer

Planlæg for gentagelser og usikre svar

En besked kan blive leveret igen, og et oprettelseskald kan lykkes, selv om svaret går tabt. Knyt derfor genforsøg til en stabil reference for den samme logiske handling.

Undersøg målsystemets muligheder for opslag, unik reference eller idempotensnøgle samt funktionernes konkrete vilkår. Ved ukendt udfald bør resultatet afklares før et nyt kald med væsentlig virkning.

Afklar, hvad beskeden betyder

Skeln mellem en kommando og en hændelse. En kommando beder et andet system om at udføre en bestemt handling, mens en hændelse blot fortæller, at noget er sket; modtagere kan reagere uafhængigt af hinanden.

Valget påvirker, hvad afsenderen skal kunne følge op på. Ved en kommando kan afsenderen have brug for en kvittering med handlingens resultat, mens en hændelse ikke i sig selv indebærer, at modtageren udfører noget bestemt.

Hvis flere systemer skal reagere på samme hændelse, afklar hvilke modtagere der er interesserede, og om alle forventes at behandle den. En beskedmægler kan formidle beskeder mellem afsender og modtagere, så systemerne ikke behøver kommunikere direkte.

Aftal, hvornår forløbet er afsluttet

Beskriv særskilt, hvad der tæller som modtagelse af beskeden, og hvad der tæller som gennemført forretningshandling. Ved en kommando kan afsenderen have brug for operationens resultat retur for at afgøre, hvad der skal ske videre.

Aftal på forhånd, hvem der ejer definitionen af et korrekt resultat, og hvem der må beslutte, om en sag skal rettes eller genindsendes. Det viser, om en afvigelse skal løses i kildesystemet, i målsystemet eller ved at ændre workflowet.

Giv fejl en ejer

En midlertidig netværksfejl kan egne sig til et begrænset genforsøg. Et manglende felt kræver normalt rettelse. Registrér berørt post, årsag, seneste forsøg, ansvarlig og næste skridt i en synlig undtagelseskø. En teknisk fejlkø kan opbevare beskeden, men afgør ikke selv, hvem der retter den.

Brug fiktive prøveposter med et normalforløb, et manglende felt, en dublet og et usikkert svar. Angiv det forventede resultat på forhånd, og kontrollér både kilde, målsystem og fejlhåndtering i den konkrete opsætning.

Hvis en besked ikke kan leveres eller behandles, skal den kunne undersøges, og I skal kunne beslutte, om den skal rettes og sendes igen. I Azure Service Bus kan en dead-letter-kø holde sådanne beskeder, men de fjernes ikke automatisk: de bliver liggende, indtil de hentes og afsluttes eksplicit. Afklar derfor, hvem der har ansvar for at følge op på den valgte tekniske løsning.