OWB naar ODI migratie: Zorgen dat het werkt!

Blog: OWB naar ODI Migratie: Zorgen dat het werkt!
Auteur: Leon Parren (Oracle BI Consultant)

In mijn vorige blogpost heb ik laten zien hoe we objecten van Oracle Warehouse Builder (OWB) kunnen migreren naar Oracle Data Integrator (ODI). De gemigreerde mappings kunnen niet zonder meer worden gedraaid, er zullen nog een paar aanpassingen moeten plaatsvinden voordat een interface zonder problemen kan worden gestart. Ik zal in deze post laten zien wat er moet gebeuren om een en ander aan de praat te krijgen.

Wat migreert het tool niet?

Zoals ik in de vorige post heb laten zien worden de fysieke attributen van OWB objecten niet gemigreerd. Locations vinden we alleen terug in de Logical Architecture. In ODI zijn de logische en fysieke laag gescheiden en worden aan elkaar gekoppeld middels een context. Het eerste wat we in ODI dan ook moeten doen is het definiëren van de fysieke laag.

In de tab Topology creëren we eerst één of meerdere Data Servers onder Technologies->Oracle met daaronder één of meerdere Physical Schemas die daarmee de link vormen naar de database accounts.

Daarna worden in de context de fysieke en de logische laag met elkaar verbonden.

Nu we dit hebben gedaan kunnen we verder met het gemigreerde object.

Een eerste oplossing

De te migreren OWB mapping ziet er als volgt uit:

Gemigreerd ziet hij er zo uit:

Nu we de fysieke laag hebben gedefinieerd kunnen we de mapping valideren en dat levert de volgende meldingen op:

We missen dus de pre- en post-mapping blokjes, die zijn verplaatst naar  de Physical Properties tab onder Begin Mapping Command en End Mapping Command. De GET_MAPPING_NAME en GET_AUDIT_ID hebben geen verbinding meer met de rest van de mapping.  Procedure start_run_step wordt aangeroepen in de pre-mapping en bevat één invoer en drie uitvoer parameters:

GET_MAPPING_NAME.MAPPING_NAME wordt in de pre-mapping gebruikt om de logging tabel bij te werken, bovendien wordt daar het run nummer (een sequence nummer dat aan elke run wordt toegekend) opgehaald en de range van SCN’s (System Change Numbers) bepaald waarmee de gewijzigde records worden geselecteerd. De mapping naam kan in ODI worden opgehaald middels de odiref functie getpop(<%=odiRef.getPop(“POP_NAME”)%>). Variabelen teruggeven naar ODI gaat een stuk moeilijker. Hoewel het mogelijk is in ODI een variabele te definiëren, is het niet mogelijk daar vanuit een plsql block direct een waarde aan toe te kennen. Een ODI variabele kan vanuit Oracle alleen via een sql statement worden gevuld. We kunnen de waardes uit de database procedure alleen vanuit een sql statement benaderen door een zogenaamde getter–functie te definiëren die de waarde teruggeeft. Daarvoor moet de waarde wel beschikbaar zijn in een database variabele. De werkwijze is dan als volgt:

1.       Creëer een package variabele (database)

2.       Vul de package variabele in de procedure (database)

3.       Definieer een odi variabele die wordt gevuld via sql: select <package>.<variabele getter> from dual

4.       Gebruik de variabele in ODI mappings en procedures.

De eerste 2 stappen zouden er zo uit kunnen zien:

De definitie van de ODI variabele ziet er als volgt uit:

Omdat we de ODI variabelen niet in een mapping kunnen verversen, maar we er wel voor moeten zorgen dat die op het juiste moment gevuld zijn, kunnen we niet langer gebruik maken van de Begin Mapping Command property. De verwerking moet worden gesplitst over meerdere stappen:

Creëer een procedure voor de aanroep van owc_dwh_runs_mgr.start_run_step

2. Creëer een ODI package dat eerst ODI procedure start_run_step aanroept, daarna de 3 variabelen ververst en uiteindelijk de gemigreerde mapping aanroept.

3. Verwijder GET_MAPPING_NAME en GET_AUDIT_ID uit de mapping en maak Begin Mapping Command en End Mapping Command leeg.

4. Pas de filter conditie aan zodat die de ODI variabelen gebruikt.

Na deze aanpassingen hebben we weer een werkend laadproces.

Een betere aanpak

In de eerste oplossing heb ik geprobeerd de structuur van de mapping zo beperkt mogelijk te wijzigen, maar ondanks dat heb ik toch veel extra moeten doen om de zaak aan de praat te krijgen. Aangezien we toch het een en ander moeten aanpassen is het waarschijnlijk beter om voor een iets andere oplossing te kiezen. Daarvoor moet de mapping structuur worden gewijzigd, maar het leidt uiteindelijk tot een oplossing  die beter en overzichtelijker is.

Net als in de eerste oplossing worden GET_MAPPING_NAME en GET_AUDIT_ID  verwijderd en wordt de Begin Mapping Command en End Mapping Command verplaatst naar een procedure in een package, maar er worden geen variabelen gedefinieerd. Dat kan omdat het run nummer en de current en previous scn, die nodig zijn voor de selectie, ook zijn opgeslagen in een tabel. We voegen deze tabel daarna toe aan de mapping (met een filter op lopende runs) en verbinden die aan de deduplicator met een cross join (cartetisch product), waarna er een filter wordt toegevoegd die de data selectie uitvoert. Het resultaat ziet er dan als volgt uit:

De Running only filter zorgt ervoor dat er maar maximaal één record uit de dwh_runs tabel wordt geselecteerd:

De join condition is een cartetisch product (een join conditie is niet nodig):

Het tweede filter zorgt ervoor dat de juiste data worden geselecteerd:

Het package wordt ook eenvoudiger omdat er geen variabelen ververst hoeven worden:

Kan het nog beter?

Jazeker. In de OWB mapping wordt een heleboel housekeeping en logging gedaan die enkel is toegevoegd om tekortkomingen in OWB op te vangen. ODI heeft veel betere logging en monitoring tools dan OWB. Is al die extra logging nog wel nodig? In OWB maken we gebruik van het SCN om een selectie uit het bronsysteem te maken, dat wordt gedaan om een vorm van Change Data Capture te implementeren. Het werken met SCN ‘s op deze manier kent wat nadelen en is alleen ingebouwd omdat de standaard versie van OWB geen standaard vorm van CDC ondersteund. ODI heeft dat wel en het is daarom beter om die functionaliteit te gebruiken. Maar goed, hoe meer ODI functionaliteit we gaan gebruiken hoe meer we in de richting gaan van redesign in plaats van migratie, wat de beste aanpak is zal voor elk project opnieuw moeten worden bekeken.