OWB naar ODI migratie: Een eerste indruk

Jaren lang hebben we OWB succesvol in projecten toegepast, maar langzamerhand beginnen de barstjes in het tool steeds meer op te vallen. De ietwat gedateerde user interface, het ontbreken van een aantal nieuwe database objecten, de integratie met Golden Gate, de certificatie met de 12c  database, maar vooral het gebrek aan flexibiliteit.

Ondanks dat is OWB nog steeds een goed product om datawarehouses mee te bouwen, zeker als je in een Oracle-only-shop werkt. Daarnaast blijft het prettig dat standaard OWB onderdeel is van je database licentie (volledige functionaliteit was tot 11g beschikbaar met de database OWB ETL Option, maar in 12c is dit komen te vervallen en heb je een ODI EE licentie nodig). Nu Oracle Warehouse Builder (OWB) de extended support status heeft bereikt, is de tijd gekomen om eens nader naar de Oracle Data Integrator (ODI) migratie utility te kijken, die sinds OWB 11.2.0.3 beschikbaar is.

Wat zijn de grootste verschillen tussen OWB en ODI?

In de ODI 12c release zijn een aantal wijzigingen aangebracht in de user interface die de overstap  voor een OWB ontwikkelaar behoorlijk vereenvoudigen. We zien veel van de bekende objecten uit OWB terug in de designer en ook het bouwen van mappings lijkt veel op de OWB werkwijze, iets wat Oracle de declarative flow-based user interface noemt.

Ondanks de overeenkomsten zijn er nog grote verschillen.

Zo zullen we moeten wennen aan het concept van een fysieke en logische architectuur die aan elkaar zijn verbonden via een context. We kunnen, door bij het runnen van een mapping de context op te geven, bepalen welke omgeving we gebruiken (bv ontwikkeling of productie). Een mapping zelf heeft ook een logisch en één of meerdere fysieke elementen, waarmee we meerdere fysieke implementaties kunnen creëren voor één logische mapping (bv een initiële en incrementele load).

Een ander element waar wij aan moeten wennen zijn de packages (dit zijn geen database packages) waarin mappings in een soort flow verzameld kunnen worden in combinatie met procedures (wederom geen database procedures). Een package is niet het equivalent van een flow in Oracle Workflow zoals we die kennen in OWB, die heten in ODI Load Plans.  ODI genereerd geen code (behalve tabellen) in de databases, in plaats daarvan wordt de code (insert, update statements e.d.) via een agent rechtstreeks in de database uitgevoerd.

Misschien wel het grootste verschil is de toepassing van zogenaamde Knowledge Modules (KM) in ODI. Een KM bepaalt de implementatie van een logisch element voor een specifieke technologie, zo kan een mutatie van een tabel in Oracle met een MERGE statement worden geïmplementeerd, terwijl dit in SQL Server een apart insert en update statement zal worden. Logisch gezien hetzelfde maar in praktijk een verschillende  implementatie. Deze KM’s worden gekoppeld aan een fysieke implementatie in een mapping. Zo kan één logische mapping meerdere fysieke implementaties hebben die gebruik maken van verschillenden KM’s. Het gebruik van KM’s in ODI is erg krachtig, maar voor OWB ontwikkelaars lastig te doorgronden.

Wat hebben we nodig?

We hebben de volgende software nodig:

• OWB 11.2.0.3 of 11.2.0.4 met patch p18537208 (staat ten onrechte als MSWIN op My Oracle Support, maar is ook voor Linux)
• ODI 12.1.2 of 12.1.3
• Een Oracle database, 10g of 11g voor OWB, 11g of 12c voor ODI

Ik heb beide tools geïnstalleerd op een Oracle Enterprise Linux 6.5 virtual machine met een Oracle Database 11.2.0.3. Beide repositories zitten in dezelfde database. Voor een test omgeving is dat acceptabel, maar in een normale ontwikkel omgeving zullen ze natuurlijk elk in een eigen database draaien. Ik heb gekozen voor een Oracle 11.2.0.3 omdat OWB (nog) niet gecertificeerd is voor de 12c database.

ODI wordt geleverd met een beperkte licentie van Weblogic voor het draaien van de Agent wat voor deze test voldoende is, maar in een productie omgeving zal een volledige Weblogic installatie de voorkeur hebben ivm beheersbaarheid en stabiliteit.

Wat doet de migratie tool niet?

De volgende objecten worden niet gemigreerd (volgens de documentatie):

1. data objects
   • table (partitions, attribute sets, data rules)
   • view (attribute sets, data rules)
   • materialized view (partitions, attribute sets, data rules)
   • external table (data rules, locations)
   • sequence (columns)
2. dimensional modeling metadata (dimensions and facts)
3. Oracle Discoverer metadata and derived Oracle Business Intelligence Suite Enterprise Edition (OBI EE) metadata
4. custom PL/SQL (procedure, package, and so on)
5. queues, streams, CDC (Change Data Capture) configurations, user-defined types
6. process flow
7. mappings using dimension and cube, cursor-based maps, name and address, match-merge, data rules, data auditors, iterators, expand, construct, Anydata Cast, Data Generator
8. data quality, data profiles, data auditors
9. configuration details (security, user extensions, transportable modules, schedules/collections, user folders)
10. OWB Experts
11. OMB*Plus scripts

Het is logisch dat OWB specifieke zaken niet gemigreerd kunnen worden, daarnaast wijkt de implementatie van b.v. Load Plans zodanig af van Workflows dat migratie daarvan niet mogelijk is. We kunnen over het algemeen stellen dat logische zaken van objecten gemigreerd worden, maar fysieke attributen, zoals storage en locations niet altijd meegaan naar ODI. Het is jammer dat er voor Workflows niet op zijn minst een basale migratie is zodat die niet in zijn geheel opnieuw ontwikkeld hoeven worden aangezien die erg complex kunnen worden.

Migratie setup

De software voor de migratie wordt toegevoegd door OWB patch p18537208. Deze patch installeert een aantal java files en shell scripts. Voordat we de migratie kunnen starten moet een OWB repository met minimaal één workspace aanwezig zijn die de te migreren objecten bevat en één ODI master en work repository.

Het migratie proces wordt gestuurd door een configuratie file, een voorbeeld file staat in %OWB_HOME%/owb/bin/admin/migration.config. In deze file moeten een aantal parameters worden gezet zoals: userid’s en een lijst met de te migreren projecten. Verder zijn er parameters om de migratie te sturen: wat voor type migratie, wat te doen in geval van fouten etc. Dit is een overzicht van alle beschikbare parameters. De voorbeeld  configfile bevat een beschrijving van elke parameter.

Nadat  de parameter file is gevuld kan de migratie worden gestart. Het script %OWB_HOME%/owb/bin/unix/migration.sh voert de migratie uit en dat levert een rapport en een log file op terwijl de gemigreerde objecten in de ODI repository worden gecreëerd.

Omdat de migratie utility alleen de logische elementen migreert en niet de fysieke moeten we eerst een koppeling (context) tussen de logische en fysieke laag creëren. Dat doen we in ODI  Studio onder de tab Topology. Daar leggen we de link tussen logisch en fysiek. Bovendien moeten de wachtwoorden van de schema’s opnieuw worden niet gezet omdat die niet worden gemigreerd.

Laten we als voorbeeld eens naar de volgende, eenvoudige mapping, kijken. Deze mapping maakt gebruik van een pre- en post-mapping component, waarin een aantal huishoudelijke zaken worden geregeld zoals: het bijhouden van logging, de voortgangsrapportage en er worden twee waarden opgehaald die later in een filter worden gebruikt.

Uit een bron tabel worden alle records geselecteerd en met een expression wordt de rowscn aan de selectie toegevoegd. De deduplicator is nodig om een bug in OWB op te vangen waarna in een filter wordt gecontroleerd welke records, afhankelijk van de rowscn, geselecteerd moeten worden. Tenslotte wordt de staging tabel m.b.v. een insert/update actie bijgewerkt. OWB genereert op basis van deze definitie een MERGE statement dat via een database link de data ophaalt.

In ODI ziet het logische model van de gemigreerde mapping er als volgt uit:

De pre- en post-mapping objecten zijn verdwenen en de daaraan gekoppelde expressions hangen nu los. De rest van de mapping ziet er nagenoeg hetzelfde uit als in OWB. Zoals eerder gemeld bevat ODI het voor elke mapping een of meerdere fysieke modellen en van deze mapping ziet die er als volgt uit:

Hier kunnen we de implementatie  specifieke zaken aangeven, zo kan een component tussen de source en target group worden verplaatst en afhankelijk van de gekozen implementatie, via de knowledge module, heeft dat invloed op waar de code wordt uitgevoerd. Na even zoeken blijkt dat de pre- en post-mapping code is verplaatst naar de begin mapping command en end mapping command attributen van de fysieke laag. De filter conditie wordt niet goed geconverteerd, dat wordt veroorzaakt door de verplaatsing van de pre- en post-mapping code, waardoor de get_mapping_name en get_audit_id expression nu los hangen. De conditie van filter component was in OWB: INOUTGRP1.C >=  INOUTGRP1.P_PREVIOUS_SCN AND INOUTGRP1.C <  INOUTGRP1.P_CURRENT_SCN, en wordt in ODI: DEDUPLICATOR.C >=  NULL AND DEDUPLICATOR.C <  NULL, hetgeen erop neerkomt dat de conditie effectief is uitgeschakeld.

Samenvattend

Uit deze test blijkt dat deze gemigreerde OWB mapping niet zonder aanpassingen kan werken. In een volgende blog zal ik nader ingaan op de oplossingen voor de verschillende problemen die ik ben tegengekomen.