En praktisk metode for datavalidering og integrasjon

Når du jobber med eksterne datakilder, trenger du god datavalidering og integrasjon. Én feil kan føre til tap av data, feil i systemet – eller kunder. Her får du en praktisk metode som sikrer at dataene er gyldige, håndterbare og klare for import

I denne artikkelen tar vi tar utgangspunkt i en typisk dataflyt hvor data mottas via et API eller en ekstern kilde, lagres som en fil, valideres, håndteres ved feil, og til slutt integreres i et system.

Steg-for-steg prosess for dataintegrasjon

Prosessen med integrasjon av data skjer i tre steg. Det første steget handler om å få dataene inn og få lagret dem som en eller flere filer. I metoden Medalion Architecture har de definert disse tre stegene som bronse, sølv og gull.

I det neste steget handler det om rense dataene, få dem inn i et format din bedrift bruker internt og sikre at dataene har god kvalitet. Dette steget er det viktigste. Du ønsker ikke en situasjon hvor data som ikke har hatt den kvaliteten dere ønsket ødelegger systemet deres på en eller annen måte. Det er aldri gøy å rense et database-system.

I det siste steget importerer dere dataene. Dette kan være inn i en statistikk-database, en kundedatabase eller et produksjonssystem.

1. Innhenting og lagring av data

Dette er det aller første steget i prosessen. Det er mange måter dataene kommer til deres system. Tidligere var det mest vanlig at datafiler ble lagret på FTP-serveren. I dag kan dataene komme til dere gjennom APIer, webhooks, HTTP Push-systemer eller for den sakens skyld lagres i Buckets i AWS.

1.1. Data mottas og lagres som fil

Når vi mottar data, er første steg å lagre det som en fil. Dette gir oss en referanse for debugging. I tillegg lar det oss kjøre prosessen om igjen uten å hente data hos leverandør om nødvendig.

Bruk en strukturert mappestruktur: incoming/, processing/, archived/, errors/.

Avhengig av hva vi har laget, kan det være fornuftig å ha en undermappe under incoming som refererer til filtype. For eksempel /xml, /json eller /csv.

Et viktig steg i denne prosessen er å sjekke at innholdet i filen faktisk er som forventet. Her kan det være lurt å ha en hvitliste over aksepterte filtyper, og en liten sjekk som undersøker om innholdet faktisk er hva dere forventer.
Er filen en JSON-fil, mens innholdet viser seg å være en exe-fil, er det greit å få de filene ut av systemet. Slike hendelser bør også rapporteres.

1.2. Håndtering av store filer

Dersom filene er store, kan vi ikke lese dem rett inn i minnet. I stedet må vi håndtere dem stykkevis for å unngå out of memory-feil.

Denne delingen er viktig dersom det er mye data som kommer. For eksempel over 100.000 datarader. Dette avhenger selvfølgelig av mengden data i de ulike radene, og ikke minst formatet. 100.000 datarader i CSV tar ikke mye minne, men tilsvarende rader i XML eller JSON kan fort skape litt hodebry.

Ved å kutte opp dataene i flere filer er du sikret at systemet vil klare å prosessere dataene selv om leverandøren plutselig skulle øke antallet datarader i dataene du får.

2. Validering, logikk-sjekk og klargjøring

Dataene er nå klare for videre bearbeiding. Systemet har sjekket at filene er korrekte. Store filer er blitt brutt opp i mindre og sikrere håndterbare størrelser.

Nå starter hovedjobben: datavalidering og integrasjon. Dette er steget der dårlige data blir avslørt – før de får ødelegge noe.

2.1. Konvertering til XML for validering

Siden XML har sterkere schema-støtte enn JSON, anbefaler jeg å bruke denne teknologien. Derfor konverterer jeg alltid innkommende data til XML for validering. Dersom din bedrift ikke allerede har det, bør dere enten finne en standard dere kan bruke, eller utvikle et XML-format som brukes internt.

I nyhetsbransjen er NewsML-G2 svært vanlig. Og selv om det er en standard, er det mange forskjellige implementeringer. Derfor gjør jeg gjerne om XML-filer som bruker denne standarden til en NewsML-G2 som brukes internt. Under er en helt enkel måte å lage XML-filer på.

Fordi vi bruker XML-Schema kan vi raskt og automatisk få beskjed fra systemet dersom filene ikke inneholder korrekt innhold. Dette mener vi er en mer effektiv måte enn å laste inn filer i regneark for å se forskjeller.

Husk: I denne prosessen er det viktig å teste så mye data som mulig. Men selv om du tester en million rader med data, vil det alltid komme en fil som har uventede data som du ikke har tatt høyde for.

2.2. Forretningslogikk-sjekk

Etter XML-validering må vi sjekke forretningsregler. Dette kan være regler som sjekker om en dato er innenfor et gyldig intervall, eller om et felt har riktig format.

I slike situasjoner er det fornuftig å ta en prat med den eller de som er ansvarlige for prosjektet. Hva gjør vi når datoen er ugyldig, som for eksempel at den er fram i tid, eller at den ikke er der i det hele tatt.

Underveis i dette steget av data-innhentingen er det også viktig at det lages såkalte UnitTests av de ulike sjekkene som utvikles. Dette for at du skal være sikker på at det du forventet at skulle skjer, faktisk skjer.

2.3. Klargjøring for import

Når dataene er bitt kontrollsjekket og dere kun sitter igjen med godkjente datasett, gjøres datasettet om til formatet som skal brukes i sluttfasen.

Skal dataene for eksempel inn i et kundesystem (CRM), skal dette systemet mest sannsynlig leveres i CSV (komma- eller semikolon-separert) format.

Dersom artiklene skal inn i et publiseringssystem kan det tenkes at kun artikkel-dataene skal inn i systemet. Da gjøres dataene om til for eksempel HTML5, NITF eller et format for eksempel WordPress bruker.

2.4. Feilhåndtering og karantene-lagring

Feil bør ikke stoppe hele systemet. I stedet lagrer vi feildata i en egen tabell. I tillegg varsler vi de som kan være interessert i denne feilmeldingen. Og vi passer selvfølgelig på at data med feil ikke blir sendt videre i systemet.

Det kan gjøres enten ved at systemet sender en e-post, eller lager en post i f.eks. Slack eller Teams.

3. Integrasjon i systemet

Fordi vi har gjort en grundig jobb i det forrige steget, skal import av dataene være relativt enkelt.

3.1 Dataintegrasjon

Når vi er kommet i denne fasen er datasettet klart. Dere har levert dataene videre i et format som programmer i denne fasen leser.

Da gjenstår det bare å få dem importert inn i en database. Enten gjennom batch-import inn i en database, eller ved å bruke et API – f.eks. hvis dataene skal inn i et CRM-system.

3.2. Rapportering

Når dataene er importert er det viktig at systemet rapporterer dette. En slik rapport trenger ikke å være en e-post, slack-melding eller tilsvarende.

Det holder med en suksess-melding i en logg.

Samtidig er det viktig å huske på at selv om alt arbeidet som ble gjort i steg to skulle sikre at integrasjonen skulle gå bra, kan ting fortsatt gå feil.
I forbindelse med sending av dataene til APIet, kan det ha oppstått feil. Eller at databasen akkurat på dette tidspunktet kjørte en vedlikeholdsoppgave som førte til at dataene ikke ble importert.
Da må dette rapporteres i en logg, og kanskje også varsles gjennom e-post og tilsvarende.

Når det gjelder dette med logging og rapportering. Her finnes det mange løsninger der logger blir overvåket og hvor rette personer eller avdelinger blir varslet dersom en feil skulle oppstå.

Men det er et tema for en helt annen post…