Samenvatting
Bij een grote Nederlandse onderneming op SAP S/4HANA kondigde SAP een beveiligingspatch aan die het protocol blokkeerde waarmee een deel van de data naar het datawarehouse werd gehaald, waaronder de twee zwaarste financiele datasets (grootboekregels en open posten). De meeste bronnen liepen al via een compliant protocol; het probleem zat in een klein aantal views dat voor de incrementele verversing op het geblokkeerde protocol leunde. Na een afweging tussen drie routes is gekozen voor de meest onafhankelijke: rechtstreeks de onderliggende tabellen uitlezen via de bestaande, compliant connector. Omdat die route geen wijzigingsdetectie meebrengt, is een eigen aanpak gebouwd op een watermark, aangevuld met logica die stornerings- en verrekeningsboekingen via hun referentiedocument terugvindt en een periodieke controle op de resterende, datumloze mutaties.
De vraag
Zorg dat de SAP-extractie blijft werken zodra SAP de aangekondigde beveiligingspatch toepast, zonder de betrouwbaarheid van de incrementele verversing te verliezen, en bij voorkeur zonder afhankelijk te worden van een nieuw platform of een trage tussenoplossing.
Wat ik heb gebouwd
- Een impact-analyse die vaststelde dat het merendeel van de bronnen al compliant liep en het risico beperkt was tot een klein aantal views, geverifieerd tegen de live extractie-configuratie in plaats van aangenomen
- Een afweging van drie architectuurroutes (platformmigratie, HTTP-variant van het geblokkeerde protocol, directe tabelextractie) met expliciete voor- en nadelen en een advies
- De eenvoudige masterbronnen omgezet naar directe extractie van hun SAP-tabellen via de bestaande, compliant connector
- Voor de twee zware financiele datasets: een wijzigingsdetectie zonder het geblokkeerde protocol, uit een aanmaakdatum-watermark, een volg-het-referentiedocument-regel voor storneringen en verrekeningen, en een periodieke aanvullende controle
- Een gechunkte initiele volledige lading (per boekjaar en periode) nadat een ongechunkte poging op een geheugenlimiet vastliep
- Een gefaseerde, geverifieerde omschakeling op ontwikkel- en productieomgeving, gevolgd door opruiming van de oude extractielaag
In detail
- Drielaagse wijzigingsdetectie zonder de geblokkeerde functionaliteit: een datumwaterlijn voor nieuwe boekingen, document-volglogica voor storneringen en verrekeningen op bestaande boekingen, en een periodieke controle op systeemwijzigingslogboeken voor de resterende, datumloze aanpassingen
- Oplossing voor een rijbreedte-limiet: een van de financiele tabellen liep vast op de maximale rijgrootte door te veel zelden gebruikte velden, opgelost door de kolomselectie op extractieniveau te versmallen
- Chunk-strategie voor de initiele lading: extractie in porties per boekjaar en periode, telkens ruim onder de geheugengrens van de extractiefunctie
- Orkestratie-versnelling: de verversingsketen omgebouwd van veel losse stappen naar een enkele servergestuurde procedure, met een meetbare doorlooptijdwinst
- Gefaseerde cutover met verificatie: eerst op ontwikkel bewezen, daarna op productie, met controlerapportages voor en na om regressie uit te sluiten
Resultaat
In productie op zowel de ontwikkel- als de productieomgeving; de oude, door SAP geblokkeerde extractielaag is opgeruimd en de verversing draait sindsdien binnen de beoogde tijdvensters.