Fejl håndteres på samme måde for alle indlæsere, hvorfor denne beskrivelse ligger under referencearkitektur i stedet for at blive gentaget for alle de enkelte indlæsere.

Fejlsituationer kan ske mange steder i pipelinen fra referencearkitekturen og afhængig af konteksten skal de håndteres på forskellig vis.


Pipelinen har ovenstående forløb og herunder beskrives der hvad der kan gå galt, hvordan situationen håndteres og hvilke meta-data der skal være til rådighed for at kunne foretage den fornødne håndtering.

Hvor der herunder er nævnt at noget rapporteres, forventes det at der forefindes en standard metode/API hvorigennem rapportering i form af  logning og/eller alarmering kan foretages.

Modtag datasæt

Ved Modtag datasæt hentes filen fra den givne lokation som scannes og placeres i en lokal folder.

Scanningen efter filer foretages via en Camel route som poller en given lokation (lokal folder, SFTP eller andet) for forekomsten af en fil der matcher et aftalt mønster (*.xml)

Det som kan gå galt her er:

Indlæs datasæt

Indlæs datasæt henter filen fra den lokale folder og påbegynder processering af filen.

Der er ikke identificeret fejlsituationer i dette trin.

Valider datasæt

Valider datasæt har til formål at sikre at filen er komplet og kan parses som en helhed.

Det som kan gå galt her er:

Parse og split datasæt

Parse og split datasæt har til formål at parse filen og undervejs opdele filen i de enkelte events (=hændelser)

Der er ikke identificeret fejlsituationer i dette trin.

Valider event

Valider event har til formål at sikre at events der læses ind, er gyldige.

Det som kan gå galt her er:

Opret implicitte slette events

Oprete implicitte slette events anvendes kun ved full load og har til formål at undersøge og indsætte eventuelle slette events,  hvis de ikke er med i data sættet.

Det som kan gå galt her er:

Berig event

Berig event tilføjer meta data til eventen så den indeholder data omkring det datasæt der producerede eventen.

Der er ikke identificeret fejlsituationer i dette trin.


Route event

Route event har til formål at pakke eventen og sende den til consumeren/aftageren

Det som kan gå galt her er:

Slette filter

Slette filter anvendes kun ved full load og har til formål at fjerne slette event inden de sendes til eksterne modtager. Ekstern modtager skal alene have de events, som er modtaget i datasættet.

Der er ikke identificeret fejlsituationer i dette trin.

Berig event før persistering

Berig event før persistering har til formål at tilføje manglende informationer inden eventet gemmes. F.eks. sub entiteter der ikke er med i eventet og dermed skal slettes.

Det som kan gå galt her er:

Dublet filter

Dublet filter kontrollerer om eventen allerede eksisterer i helt identisk form i databasen, og i givet fald sorteres eventen fra som en ikke-opdatering.

Det som kan gå galt her er:

Modtag event

Modtag event udpakker eventen og stiller den til rådighed for consumeren/aftageren

Det som kan gå galt her er:

Prevalider event

Prevalider event er ikke en del af den kørende pipeline.

Validering af event indholdet foregår i Valider event og da der indtil videre ikke er andre kanaler der genererer events, vil de ikke kunne være in-valide når de ankommer hertil.

Persister event

Persister event har til formål at foretage skrivningen (slet/opdater/indsæt) til databasen.

Det som kan gå galt her er:

Postvalider event

Postvalider event er ikke en del af den kørende pipeline.

Vi har indtil videre ikke set et behov for at foretage en postvalidering af data.

Kvitter datasæt

Ved Kvitter datasæt oprettes en .done fil i en lokal folder, når hele datasættet er indlæst. (Sker der en fejl undervejs vil exception håndteringen oprette en .fail fil istedet)

Der er ikke identificeret fejlsituationer i dette trin.

Kvitter

Ved Kvitter sendes en .done eller .fail fil fra en lokal folder til en given lokation (feks SFTP).

Det som kan gå galt her er:


Rapportering af og opfølgning på fejl

Hvis en stamdataindlæser melder, at der er fejl i et eller flere event, og de derfor ikke kan indlæses, så vil overvågningsservicen for den pågældende stamdataindlæser fortælle dette i sit svar, når den bliver kaldt. På denne måde bliver der rejst en alarm, som driftsovervågningen bliver opmærksom på. Informationen i fejlbeskeden vil være så detaljeret som mulig i forhold til hvilke events (unikt identificeret), der fejler, og hvad der er gået galt med dem.
Denne detaljerede information kan så anvendes af driftssupporten, når de tager kontakt til ejeren af kildesystemet, hvorfra stamdataudtrækket med fejlene stammer fra. De fejlagtige data rettes efterfølgende op i kildesystemet, og et nyt/opdateret udtræk bliver eksporteret fra kildesystemet, der indlæses af stamdataindlæseren. Såfremt alt går godt, og der således er blevet rettet op på fejlen, ændres svaret for den pågældende stamdataindlæsers overvågningsservice til alt ok.