Bepaal de juiste laadstrategie bij datamigratie

Een belangrijke overweging bij een datamigratie of dataconversie is de wijze waarop de geconverteerde gegevens in de doelomgeving worden geladen of geïmporteerd. Dit wordt wel de laadstrategie genoemd en deze kent twee uitersten, namelijk bovenlangs en onderlangs converteren. In dit artikel worden de karakteristieken van beide laadstrategieën uiteengezet. Vervolgens worden de voordelen en nadelen besproken. Ten slotte volgt een korte discussie.

Bovenlangs converteren
Onder bovenlangs converteren wordt verstaan:

‘De geconverteerde gegevens worden via gedefinieerde (bericht)formaten aangeboden aan de applicaties-services van de doelomgeving die deze vooraf valideert en incrementeel (1-voor-1) verwerkt. Een voorbeeld is een xml-bericht per te converteren casus die alle geconverteerde gegevens van die casus bevat.’

Karakteristieken:

• Het doelformaat voor de conversie is een gedefinieerd berichtformaat (bijvoorbeeld een xsd in het geval van xml berichten).

• De geconverteerde data wordt aangeboden via berichten die door applicatie-services in de database(s) van het doelsysteem worden geladen. De geconverteerde gegevens worden tijdens het inlezen aan dezelfde applicatie-logica/validatieregels onderworpen als reguliere berichten. Een conversiebericht met gegevens van een bestaande klant wordt bijvoorbeeld net zo behandeld als een regulier bericht met gegevens van een nieuwe klant.

• De verwerking van een specifiek bericht is een atomaire transactie. Een transactie wordt volledig verwerkt óf volledig afgekeurd. Afgekeurde transacties worden als conversie-uitval beschouwd. Hierdoor is de database van het doelsysteem na verwerking altijd consistent.

• De applicatie-services van het doelsysteem regelen automatisch het bijwerken of verrijken van technische tabellen die nodig zijn voor de correcte werking van het doelsysteem. Voorbeelden zijn het aanmaken van logging tabellen of het creëren van audit records.

Onderlangs converteren
Onder onderlangs converteren wordt verstaan

‘De geconverteerde gegevens worden – in bulk – rechtstreeks in de database(s) van de doelomgeving geladen zonder langs de applicatie-logica te gaan. De inhoudelijke controle van de gegevens vindt achteraf plaats via de conversieprogrammatuur en niet in het doelsysteem. Een voorbeeld is het opleveren van importbestanden (bijvoorbeeld csv) die vervolgens rechtstreeks worden ingelezen in de doeldatabase.”

Karakteristieken:

• Het doelformaat voor de conversie is een gegevensstructuur/datamodel van de doeldatabase(s). De geconverteerde data wordt rechtstreeks in de bestanden/tabellen van de doeldatabase geladen. Dit is inclusief het vullen van de noodzakelijke technische tabellen.

• Er wordt achteraf gevalideerd of de doeldatabase consistent is en of de gegevens voldoen aan alle vastgestelde validatieregels. Dit kunnen bestaande regels zijn of regels die specifiek voor conversie zijn opgesteld. Alle data dat niet voldoet aan deze regels wordt als conversie-uitval beschouwd en uitgelijst.

Voordelen en Nadelen

Voordelen van bovenlangs converteren zijn:

1. Hergebruik van (bewezen) applicatie-services en (bestaande) validatieregels voor het inlezen en verwerken van de geconverteerde data. Applicatie-logica en validatieregels hoeven niet te worden (na)gebouwd in de conversieprogrammatuur.
2. De applicatie-services voeren allerlei technische en functionele controles (o.a. referentiële integriteit) automatisch uit waarmee vervuiling wordt voorkomen. De geconverteerde gegevens worden aan dezelfde validatieregels onderworpen als nieuwe gegevens. Dit komt de juistheid van de geconverteerde gegevens ten goede, met name bij een reeds gevulde doeldatabase.
3. Technische en/of afgeleide gegevens, die nodig zijn voor de correcte werking van het doelsysteem, hoeven niet vanuit conversie te worden aangeleverd, maar worden automatisch door de applicatie-services gegenereerd. Aangezien de applicatie-services en de validatieregels zijn gebouwd door specialisten van het doelsysteem komt dit de bruikbaarheid van de geconverteerde gegevens ten goede. Er is na het inlezen altijd een consistente database-situatie.
4. Conversie is niet afhankelijk van (technische) wijzigingen in de gegevensstructuur van de doeldatabase(s), mits de berichtdefinitie gelijk blijft.
5. Het risico dat er ‘iets’ fout gaat of niet wordt opgemerkt is klein, omdat de conversie incrementeel (bericht-voor-bericht) plaatsvindt. De verwerking van elk bericht of casus in de doelomgeving kan individueel worden gevolgd (bijv. via track-and-trace id’s). Conversie-rollback op individueel berichtniveau is makkelijker.

Nadelen van bovenlangs converteren zijn:

1. Het grootste nadeel/risico van bovenlangs converteren is de lagere performance, omdat de conversie incrementeel (1-voor-1, bericht voor bericht) plaatsvindt.
2. Er wordt een groot beslag gelegd op de applicatie-services van de doelomgeving met mogelijke verstoringen van de normale dienstverlening.
3. De applicatie-services regelen de verwerking en het bijwerken van technische tabellen. Daarom is deze functionaliteit voor het conversieteam grotendeels een black box.  Dit maakt de conversiecontrole, waarin de data-inhoudelijke vergelijking van bron tot en met doel  plaatsvindt, moeilijker.

Voordelen van onderlangs converteren zijn:

1. Het grootste voordeel van onderlangs converteren is de hogere performance, omdat er sprake is van een massaconversie waarbij de geconverteerde gegevens – in bulk – in de tabellen/bestanden van het doelsysteem worden weggeschreven.
2. Er wordt minder beslag gelegd op de load van het doelsysteem en vanwege de kortere doorlooptijd hoeft het doelsysteem minder lang ‘uit de lucht’.
3. De conversiecontrole is eenvoudiger, omdat de kennis van zowel het bron- en doelmodel binnen het conversieteam ligt.

Nadelen van onderlangs converteren zijn:

1. Bij afgekeurde records kan er technische inconsistentie ontstaan in de doeldatabase(s), met name als wordt geconverteerd naar een reeds gevulde database.
2. (Technische) wijzigingen in de gegevensstructuur van de doeldatabase(s) zijn van directe invloed op de conversieprogrammatuur.
3. Een eventuele conversie-rollback gebeurt in principe voor de hele bulk en niet per geconverteerde casus.
4. Kennis van de applicatie en datamodellen van de doelomgeving moet worden opgebouwd of opgehaald door het conversieteam en (gedeeltelijk) worden (na)gebouwd in de conversieprogrammatuur.

Bovenlangs versus Onderlangs

Op hoog niveau kan het verschil tussen bovenlangs en onderlangs converteren worden geduid als een meer functionele tegenover een meer technische benadering.

Conversie bovenlangs volgt een meer functionele route. Bij het incrementeel laden via de applicatie-services wordt gebruik gemaakt van de applicatie-logica die ook wordt toegepast op nieuwe data. Tevens wordt de geconverteerde data automatisch verrijkt. Het grootste voordeel is meer zekerheid over de juistheid en volledigheid van de data in het doelsysteem. Het grootse nadeel is de lagere performance.

Conversie onderlangs volgt een meer technische route. De geconverteerde data wordt, via een massaconversie, in bulk rechtstreeks weggeschreven in de tabellen van de doeldatabase(s) zonder langs de applicatie-logica te gaan. Het grootste voordeel is een hogere performance en meer grip op de data-inhoudelijke vergelijking van bron naar doel. Het grootste nadeel is het risico op technische inconsistentie, met name bij een reeds gevulde doeldatabase.

Op basis van de uiteenzetting in dit artikel kunnen de twee laadstrategieën in de praktijk naar inzicht worden aangepast danwel gecombineerd om zo tot de best passende laadstrategie voor een dataconversie te komen. Zo zijn er conversiespecifieke bulkapplicatie-services gebouwd in een bovenlangs dataconversie waar de auteur bij betrokken is geweest. Dit als vervanging van de enkelvoudige reguliere applicatie-services. Via de bulkservices konden grote hoeveelheden berichten in één keer worden verwerkt. Het resultaat was een hogere performance terwijl er toch bovenlangs via de applicatie-logica is geconverteerd. In hetzelfde project is de applicatie-logica gedeeltelijk nagebouwd in de migratiestraat. Dit om op voorhand in de migratiestraat vast te kunnen stellen welke data niet valide was zodat niet onnodig xml-berichten werden gegeneerd en aangeboden aan de applicatie-services van het doelsysteem. In de praktijk is het dus gebruikelijk, soms noodzakelijk, om vanuit één van de twee uitersten naar het midden te bewegen en daarmee tot een soort ‘best of both two worlds’ laadstrategie te komen.

Dit artikel is gebaseerd op de kennis en ervaringen van de auteur met dataconversies en daarom niet uitputtend. Andere experts worden uitgenodigd om te reageren en/of aan te vullen.