Gestern OWB, heute ODI

4.629 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
4.629
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
219
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Gestern OWB, heute ODI

  1. 1. DOAG 2014 BI Christian Piasecki ! GESTERN OWB, HEUTE ODI Ein Erfahrungsbericht eines OWB - Entwicklers
  2. 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. 3. Training DevelopmentConsulting Oracle Business Intelligence Oracle ADF
 ADF Mobile Oracle WebLogic Oracle WebCenter ENTERPRISE PRAGMATIC IT Oracle Fusion Middleware
  4. 4. DOAG 2014 BI AGENDA Aufgabe Erste Schritte Umsetzung des Workflows Unterschiede Fazit !
  5. 5. DOAG 2014 BI ES WIRD ZEIT LOSZULEGEN
  6. 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. 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. 8. DOAG 2014 BI AGENDA Aufgaben Erste Schritte Umsetzung des Workflows Unterschiede Fazit
  9. 9. NICHT IN DIE LUFT GEHEN
  10. 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. 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. 12. DOAG 2014 BI OWB - EINLESEN EINER DATEI IN EINE TABELLE ‣ Mapping deployen ‣ Mapping ausführen
  13. 13. DOAG 2014 BI ODI - QUELLE DEFINIEREN ‣ In der „Topologie“ einen physikalischen Speicherort für den Ordner mit den Quelldateien anlegen
  14. 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. 15. DOAG 2014 BI ODI - MODEL ERZEUGEN ‣ Im Designer ein Modell erstellen, welches auf den logischen Speicherort verweist
  16. 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. 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. 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. 19. DOAG 2014 BI ODI - ZIEL-SCHEMA DEFINIEREN ‣ Erstellen eines physikalischen und logischen Schemas zur Abbildung der Datenspeicherung
  20. 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. 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. 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. 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. 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. 25. DOAG 2014 BI ODI - MAPPING ‣ Ausführen des Mappings 
 und Verarbeitung überprüfen
  26. 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. 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. 28. DOAG 2014 BI AGENDA Das Projekt Erste Schritte Umsetzung des Workflows Unterschiede Fazit/Ausblick
  29. 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. 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. 31. DOAG 2014 BI ODI - WORKFLOW (PACKAGE) Auf Datei
 warten Daten löschen Daten laden Datei verschieben
  32. 32. DOAG 2014 BI AGENDA Das Projekt Erste Schritte Umsetzung des Workflows Unterschiede Fazit
  33. 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. 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. 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. 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. 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. 38. DOAG 2014 BI AGENDA Das Projekt Erste Schritte Umsetzung des Workflows Unterschiede Fazit
  39. 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. 40. NICHT DEN KOPF IN DEN SAND STECKEN
  41. 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. 42. VIELEN DANK FÜR IHRE AUFMERKSAMKEIT HABEN SIE NOCH FRAGEN?

×