Nach Oracle’s Ankündigung den OWB nicht weiter zu supporten stehen viele DWH-Architketen und Entwickler vor der Herausforderung sich mit dem Oracle Data Integrator auseinander zu setzen. Anhand eines Projekts, bei dem Daten von unterschiedlichen mobilen Zeiterfassungen verarbeitet und konsolidiert werden sollen, wird in einem Erfahrungsbericht näher gebracht, was man bei der Arbeit mit dem ODI als OWB-Umsteiger beachten muss. Wo gibt es zum Einstieg Herausforderungen und Probleme? Wo liegen die Vorteile des ODI? Anhand von konkreten Erfahrungen sollen diese Punkte dem Zuhörern aufgezeigt werden.

1. DOAG 2014 BI
Christian Piasecki
!
GESTERN OWB, HEUTE ODI
Ein Erfahrungsbericht eines
OWB - Entwicklers

2. Christian Piasecki
Consultant
ÜBER MICH
Beratung, Training, Entwicklung
Oracle Technologie
Oracle BI Suite
Oracle BI Publisher
Oracle Warehouse Builder
Oracle Apex
Oracle Data Integrator
Blog
Technical http://enpit.blogspot.com
Sonstiges http://www.enpit.de/blog

3. Training DevelopmentConsulting
Oracle Business
Intelligence
Oracle ADF
ADF Mobile
Oracle
WebLogic
Oracle
WebCenter
ENTERPRISE PRAGMATIC IT
Oracle Fusion Middleware

4. DOAG 2014 BI
AGENDA
Aufgabe
Erste Schritte
Umsetzung des Workflows
Unterschiede
Fazit
!

5. DOAG 2014 BI
ES WIRD ZEIT LOSZULEGEN

6. DOAG 2014 BI
AUFGABE
‣ Projektmitarbeiter erfassen ihre Tätigkeiten mit
verschiedenen Systemen z.B. Mobile-Endgeräten
‣ Datenlieferung erfolgen immer Monatsweise mindestens
einmal am Anfang des Folgemonats
‣ Aufwände sollen zentral in einer Datenbank konsolidiert
werden
‣ Es wird nicht ein System zur Erfassung vorgeschrieben,
sondern Datenanlieferungen werden integriert

7. DOAG 2014 BI
ARCHITEKTUR
Zeiterfassung der
Projektmitarbeiter
Datenbereitstellung
durch Projektmitarbeiter
automatische
Datenverarbeitung
mit dem ODI
Konsolidierte Daten
in der Oracle DB
Einwurf Share

8. DOAG 2014 BI
AGENDA
Aufgaben
Erste Schritte
Umsetzung des Workflows
Unterschiede
Fazit

9. NICHT IN DIE LUFT GEHEN

10. DOAG 2014 BI
AUFGABE: EINLESEN EINER
TEXTDATEI
‣ Strukturen schaffen: Quelle und Ziel
‣ Zugriff auf die Datei
‣ Prozess zur Verarbeitung der Datei erstellen
‣ Prozess ausführen

11. DOAG 2014 BI
OWB - EINLESEN EINER DATEI
IN EINE TABELLE
‣ Anlegen eines Moduls mit Speicherort, das auf ein
Datenbank-Verzeichnis zeigt
‣ Anlegen eines Moduls mit Speicherort, das als
Target-Schema in der Datenbank dient
‣ Anlegen eines File-Objekts für die Text-Datei
‣ Erstellen eines Mappings mit dem File-Objekt als
Quelle und einer Tabelle als Ziel-Objekt
‣ optional erstellen und verwenden einer externen
Tabelle als Quelle

12. DOAG 2014 BI
OWB - EINLESEN EINER DATEI
IN EINE TABELLE
‣ Mapping deployen
‣ Mapping ausführen

13. DOAG 2014 BI
ODI - QUELLE DEFINIEREN
‣ In der „Topologie“ einen physikalischen
Speicherort für den Ordner mit den Quelldateien
anlegen

14. DOAG 2014 BI
ODI - LOGISCHES SCHEMA
‣ Ein logisches Schema erstellen und über den
Kontext das physikalische Schema mit dem
logischen Schema verknüpfen

15. DOAG 2014 BI
ODI - MODEL ERZEUGEN
‣ Im Designer ein Modell erstellen, welches auf den
logischen Speicherort verweist

16. DOAG 2014 BI
ODI - DATENSPEICHER UND
FORMAT DEFINIEREN
‣ Einen Dateispeicher erstellen und den Dateinamen
angeben, auf den dieses Objekt verweisen soll
!
!
!
‣ Datei-Attribute, wie Format
und Zeichensatz angeben

17. DOAG 2014 BI
ODI - REVERSE ENGINEERING
DER DATENSTRUKTUR
‣ Mit Hilfe des Reverse Engineering Dateiaufbau
einlesen, so dass das Objekt im Mapping
verwendet werden kann

18. DOAG 2014 BI
ODI - BEWERTUNG DER
QUELLEN INTEGRATION
‣ gleicher Aufwand beim erstmaligen Erstellen von
Speicherorten in beiden Tools
‣ Mit Hilfe des Kontext können im ODI gleichen logischen
Elemente auf unterschiedliche physikalische Elemente
zeigen
-> Im OWB gibt es eine ähnliche Möglichkeit mit den
Dateispeicherorten an den einzelnen Modulen (Multi-
Konfiguration, Control-Center)
‣ Beide Tools unterstützen einen beim Einlesen der Datei-
Metadaten

19. DOAG 2014 BI
ODI - ZIEL-SCHEMA
DEFINIEREN
‣ Erstellen eines physikalischen und logischen
Schemas zur Abbildung der Datenspeicherung

20. DOAG 2014 BI
ODI - IMPORT DER
ZIELDATENSTRUKTUR
‣ Model erstellen, welches auf das logische
Zielschema zeigt
‣ Importieren der Metadaten der Zieltabelle aus der
Datenbank (Selektives Reverse Engineering)
!
!
‣ ggf. Tabelle vorher in der DB anlegen

21. DOAG 2014 BI
ODI - MAPPING
‣ Neues Projekt erstellen
‣ In dem Projekt ein Mapping erstellen und Quell-
und Zielobjekt per Drag&Drop ins Mapping ziehen

22. DOAG 2014 BI
ODI - MAPPING
‣ Zuweisen von Quell-
zu Zielspalten
!
‣ Auswählen des passenden
Integrationstyps (in diesem
Fall „Control Append“)
-> Datensätze werden
nur hinzugefügt

23. DOAG 2014 BI
ODI - LKM
‣ Zuordnen des LKM (Loading Knowledge Modul):
„LKM SQL to SQL “
‣ LKM: Wie werden die
Daten aus der Quelle
extrahiert

24. DOAG 2014 BI
ODI - IKM
‣ Zuordnen des IKM (Integration Knowledge Modul):
„IKM Oracle Insert“
‣ IKM: Wie werden die
Daten in das Ziel
geladen

25. DOAG 2014 BI
ODI - MAPPING
‣ Ausführen des Mappings
und Verarbeitung überprüfen

26. DOAG 2014 BI
ODI - BEWERTUNG
‣ Mapping Designer in beiden Tools sehr ähnlich
‣ Wann wird welches Integration/Loading Knowledge Modul genommen und
warum?
‣ Anlegen von Zieltabellen im ODI nicht sehr komfortabel
‣ Lassen sich nur aus dem Mapping mit Create Table erstellen
(gibt beim 2ten Durchlauf eine Warnmeldung, falls nichts aus)
‣ Partionierung, Indexe in unterschiedlichen Tablespaces
-> Objekte lieber selber direkt in der DB anlegen
-> OWB auf Oracle Datenbank zugeschnitten, ODI kommt aus der Middleware
und ist heterogener aufgestellt

27. DOAG 2014 BI
!
!
!
!
!
-> Umsetzung in beiden Tools sehr ähnlich
ZUSAMMENFASSUNG /
GEGENÜBERSTELLUNG
OWB ODI
Speicherorte
einrichten x x
Quelldatei
einbinden x x
Mapping
erstellen x x
Mapping
deployen x x
Mapping
ausführen x x
Erstellung eines
Szenarios
Code einfrieren

28. DOAG 2014 BI
AGENDA
Das Projekt
Erste Schritte
Umsetzung des Workflows
Unterschiede
Fazit/Ausblick

29. DOAG 2014 BI
SCHAUBILD / ARCHITEKTUR
Zeiterfassung der
Projektmitarbeiter
Datenbereitstellung
durch Projektmitarbeiter
automatische
Datenverarbeitung
mit dem ODI
Konsolidierte Daten
in der Oracle DB
Einwurf Share

30. DOAG 2014 BI
ODI - WORKFLOW
‣ Dateien werden in einem zentralen Ordner als txt-/csv-Datei
(gleicher Aufbau) abgelegt
‣ Ein Prozess überwacht diesen Ordner und verarbeitet die
abgelegten Dateien automatisch
‣ Löschen von Daten die für die Ressource und Monat schon da sind
‣ Daten laden
‣ Datei verschieben

31. DOAG 2014 BI
ODI - WORKFLOW (PACKAGE)
Auf Datei
warten
Daten
löschen
Daten laden
Datei
verschieben

32. DOAG 2014 BI
AGENDA
Das Projekt
Erste Schritte
Umsetzung des Workflows
Unterschiede
Fazit

33. DOAG 2014 BI
DB-FUNKTIONEN/PROZEDUREN
‣ keine Möglichkeit diese zu importieren und direkt
einzubinden
‣ 2 Möglichkeiten:
1. In einer Expression
aufrufen
2. ODI-Prozedur als
Wrapper erstellen
!
!
-> Nachteil: Kein Import der Objekte und Unterstützung in der IDE

34. DOAG 2014 BI
PRE-/POST-MAPPING
‣ Im ODI gibt es kein Pre-/Post-Mapping Operatoren
‣ Im ODI muss diese Funktion mit anderen Mitteln
umgesetzt werden
‣ Die einfachste Möglichkeit ist, die Prozeduren in einer
Package vorher aufzurufen
!
-> Testen der Verarbeitung muss über eine Package
durchgeführt werden

35. DOAG 2014 BI
WORKFLOW - PACKAGES /
LOAD PLANS
‣ Im OWB wird die Ausführung mehrerer Mappings
durch Workflows gesteuert (seriell, parallel)
‣ Im ODI gibt es Packages und Load Plans
‣ Unterscheiden sich z.B. in der
Transaktionssteuerung und bieten nicht die
gleichen Funktion (z.B. Load Plans bei paralleler
Ausführung verwenden, Packages bei Schleifen)
-> Einarbeitung nötig (es gibt auch keine Migration von
Workflows)

36. DOAG 2014 BI
MEHRERE TABELLEN
BEFÜLLEN
‣ Es ist wie im OWB möglich mehrere Tabellen in
einem zu befüllen
‣ Ein Splitt-Operator steht zudem zur Verfügung
‣ Allerdings gibt es keine Target-Load-Order um
die Tabellen in einer bestimmten Reihenfolge
zu befüllen
-> Aufspaltung in mehrere Mappings nötig

37. DOAG 2014 BI
ODI - SZENARIEN
‣ ODI-Objekte werden als Szenarien bereitgestellt
‣ Szenarien können von unterschiedlichen Objekten
erstellt werden (Mappings, Prozeduren, Packages)
‣ Der Code des Objekts wird „eingefroren“ und
bereitgestellt (Entwicklung -> Produktion)
‣ Bei Änderungen in den Objekten, muss ein neues
Szenario erstellt und wiederum bereitgestellt
werden

38. DOAG 2014 BI
AGENDA
Das Projekt
Erste Schritte
Umsetzung des Workflows
Unterschiede
Fazit

39. DOAG 2014 BI
BEWERTUNG DER
PRODUKTIVITÄT
‣ Durch Flowbased Mappings und Packages ist die
Konzeption mit dem OWB vergleichbar
‣ Produktivität leidet im Moment, da
‣ DB-Objekte (Packages, Prozeduren,
Funktionen) extra gewrappt werden müssen
‣ Testen über Packages und nicht Mappings
erfolgen muss
‣ Nützliche Komponenten in den ODI-Packages
(filewait, Variablen deklarieren, erhöhen)

40. NICHT DEN KOPF IN DEN SAND
STECKEN

41. DOAG 2014 BI
FAZIT
‣ ODI ist kein Hexenwerk, allerdings muss man sich wie mit
jeder neuen Technologie intensiv damit auseinander setzen
‣ In heterogenen Projekten hat der ODI seine Vorteile
‣ In reinen Oracle-Umgebungen ist der OWB besser geeignet
!
‣ Selber loslegen und eigene Erfahrungen
sammeln

42. VIELEN DANK FÜR IHRE
AUFMERKSAMKEIT
HABEN SIE NOCH FRAGEN?