Beslutning
Beslutningen blev at følge den konkluderende indstilling fra nedenstående analyse:
En smal version af FFF behøver ikke være en del af den nye stamdata-indlæsningsarkitektur, og FFF kan dermed i forhold til stamdataindlæsning på NSP stille og roligt udfases i takt med at stamdataindlæserne på NSP overgår til den nye arkitektur, hvilket også vil betone den Camel baserede arkitektur som den fremadrettede.
Analyse
I dag står Netic’s egenudviklede FFF komponent for at hente data i form af udtræksfiler og ”fodre” dem til stamdataindlæserne på NSP. Vi skal afgøre hvorvidt FFF fortsat skal have en rolle med den nye generation af stamdataindlæsere, der realiseres via Apache Camel, og i givet fald hvor stor denne rolle skal være. Dette dokument er et oplæg i forhold til at træffe denne afgørelse.
FFF står i dag, udover ”blot” at gøre udtræksfilerne tilgængelige for stamdataindlæserne, også i nogle tilfælde for forskellige former for forretningslogik, som egentlig burde høre hjemme i selve stamdataindlæseren. Dette skyldes dårligt design og implementering af de pågældende stamdataindlæsere. Det er allerede blevet diskuteret og besluttet på et tidligere møde i det samlede fulde stamdataindlæser-team, at dette skulle ændres med den nye generation af stamdataindlæsere, så FFF højest ville skulle hente udtræksfilerne, og ikke mere. Der er både fordele og ulemper ved at fortsætte med at anvende en sådan smallere version af FFF i den nye stamdataindlæsningsarkitektur:
Fordele:
- Nemt at komme i gang.
- Kan relativt simpelt løse paralleldrift i overgangsperiode mellem ny og gammel importer.
- Mindsker risiko for eksisterende importer i produktion ved introduktion af ny importer.
- Driftoperatørens SFTP site anvendes også af andre end NSP. Alt efter driftoperatørens egne adgangsregler til sit SFTP site, kan FFF være den nemmeste måde at få adgang på.
- Er en velkendt komponent for den nuværende driftsoperatør.
Ulemper:
- Er en ukendt komponent for SDS.
- Camel har de muligheder, der skal til for at hente filerne via SFTP. Hvorfor ikke anvende disse?
- Giver afhængighed fra den nye løsning til den gamle løsning.
- Ikke alt vedrørende stamdataindlæsning vil være indeholdt i det nye framework.
- Man skal fejlsøge to forskellige steder.
- Ved udvikling af nye stamdataimportere skal man huske at FFF også skal konfigureres.
- Giver en hård binding/afhængighed fra SDS til den nuværende driftsoperatør.
FFF kører, ifølge Netic, på de samme servere som stamdataindlæserne gør, så det burde være muligt rent netværksadgangsmæssigt at give Camel mulighed for at hente filerne. Dermed er vi fremme ved, at de to hovedfordele ved at bibeholde en smal version af FFF er paralleldriften samt den mindskede risiko.
Den nye referencearkitektur for stamdataindlæsninger er baseret på Camels implementering af Pipes and Filter EIP’et, og kan illustreres ved følgende figur, der er hentet fra referencearkitekturen:
Modtag sæt er første filter i pipelinen i referencearkitekturen, og som beskrevet i referencearkitekturen står det for at modtage et stamdataudtræk som en fil med et datasæt. Modtag sæt sikrer, at stamdataudtrækket er komplet, så man ikke risikerer, at sende et ikke komplet datasæt videre til næste komponent (Indlæs sæt). Modtag sæt foretager endvidere backup af det modtagne datasæt, og for stamdataindlæsere, hvor der allerede eksisterer en (tidligere version) af stamdataindlæseren, sikres det via en konfigurationsoption at det modtagne datasæt også kopieres videre til den tidligere version af stamdataindlæseren, således at paralleldrift sikres i den periode hvor begge versioner af stamdataindlæsere skal være kørende.
Mulighed for paralleldrift er således allerede tænkt ind i den nye stamdataindlæserarkitektur. Helt konkret vil det blive håndteret i forbindelse med backup af det modtagne datasæt. Det vil godt nok betyde, at FFF vil skulle hente udtræksfilen et andet sted end i dag, så der er en lille ændring af (konfigurationen af) FFF, men hvis paralleldriften skulle sikres af FFF, ville der alligevel skulle en anden lille ændring af (konfigurationen af) FFF til, så FFF også kopierede den modtagne fil videre til den nye stamdataindlæser. Den ekstra risiko for allerede kørende tidligere versioner af en stamdataindlæser vurderes derfor som begrænset ved at lade den nye Camel baserede arkitektur sikre paralleldriften i forhold til at lade FFF sikre den.
I de tilfælde hvor FFF i dag, på grund af dårligt stamdataindlæser design, håndterer noget forretningslogik i forhold til at stoppe indlæsningen ved at lade være med at sende en modtaget fil videre til stamdataindlæseren, fordi indlæseren vil fejle, vil det være fordelagtigt af lade den nye Camel baserede arkitektur sikre paralleldriften. Hvis FFF skulle stå for paralleldriften i disse tilfælde, vil FFF skulle ændres til at holde styr på at kopiere filen videre til den Camel baserede indlæser, men ikke til den tidligere version af indlæseren, hvilket er mere risikofyldt end at lade Camel håndtere paralleldriften og blot ændre FFF til hvor filen skal læses fra (og så i nogle tilfælde stoppe den i forhold til den eksisterende indlæser).
Alt i alt er oplægget derfor at en smal version af FFF ikke behøver være en del af den nye stamdata-indlæsningsarkitektur, og at FFF i forhold til stamdataindlæsning på NSP dermed stille og roligt udfases i takt med at stamdataindlæserne på NSP overgår til den nye arkitektur, hvilket også vil betone den Camel baserede arkitektur som den fremadrettede.