ik heb geen document om te delen over deze geneste loops, en ik ben geen deel meer van het projectteam, dus alles wat ik erover kan vertellen is uit mijn hoofd. Dus ik hoop dat je begrijpt waarom ik hier niet te veel details kan vertellen.
in principe moest ik drie verschillende soorten lookup uit te voeren op dezelfde tafel voor een zogenaamde aangepaste regel in de Test Data Management software (TDM). Deze aangepaste regels worden geà mplementeerd als mapplets, en ze moeten alleen passieve transformaties bevatten. Geen routers, geen filters, geen aggregators, geen actieve Java transformaties, alleen expressies, Lookup transformaties, en dergelijke.
voor de twee meest complexe aangepaste regels, moest ik verschillende hulptabellen implementeren die deze opzoekgegevens bevatten op verschillende niveaus van aggregatie. Het vullen van deze tabellen van PowerCenter was niet al te gemakkelijk omdat het bronbestand bestaat uit 4,5 GB tekst (app. 43 miljoen records); de lookup tabellen bevatten gegevens op drie verschillende niveaus van aggregatie met verschillende lookup criteria. En ik wilde de mapping niet in drie delen. Dus ik moest zorgen voor de identificatie van “dezelfde” gebaseerde record op mijn eigen, ik kon Aggregators niet alleen gebruiken.
voor zover ik me herinner had ik in een traditionele programmeertaal als Java tot vijf geneste lussen nodig om de brongegevens te analyseren en de respectievelijke opzoekrecords van deze invoergegevens aan te maken. Het uitvoeren van verschillende niveaus van aggregatie met verschillende variabele poorten in een enkele EXP is niet al te gemakkelijk te onderhouden, maar mijn eerste proeven hebben aangetoond dat dit nog steeds de beste keuze was; zoals gezegd had ik de mapping in drie kunnen splitsen, maar elke mapping zou bijna hetzelfde niveau van complexiteit hebben gehad als de ene “general” EXP, dus ik vond het niet de moeite waard om drie verschillende laadpaden in deze mapping te behouden.
ik ben ervan overtuigd dat iedereen met enige ervaring in PowerCenter kan – na enige gedachte – komen met een vergelijkbaar verhaal van niet-triviale mapping eisen uit zijn/haar eigen praktijk. We zijn ons misschien niet eens bewust van zo ‘ n complexiteit, maar het is er nog steeds.
neem bijvoorbeeld een thread uit 2014 of 2015 waar iemand vroeg hoe priemgetallen in PowerCenter te genereren. Niet zo makkelijk. Wie zo ‘ n oplossing bouwt moet buiten de bekende wegen denken (en werken). Dat is zonder twijfel een buitengewone prestatie in PowerCenter. Dit is misschien geen groot voorbeeld, maar het kan een goed voorbeeld zijn van complexere karteringslogica.
als een ander voorbeeld, kijk naar elk systeem om de uitvoering van workflows in een bepaalde volgorde te coördineren. Misschien met een aantal extra voorwaarden, zoals “aantal records met eigenschap XYZ is gelijk aan waarde ABC”. Al deze dingen kunnen willekeurig complex worden, en – zoals hierboven vermeld – Ik ben ervan overtuigd dat veel mensen iets gelijkaardig complex een of meerdere keren hebben gebouwd, zelfs als ze het niet herkennen.