0
(Noch nicht bewertet)
21. September 2015
DataOne Blog

ODI (Oracle Data Integrator) aus Sicht des OWB-Entwicklers

In einer kleinen Blog-Reihe wird dargestellt, wie ein OWB-Entwickler schnell und problemlos mit dem OWB-Nachfolgeprodukt, dem Oracle Data Integrator (ODI), arbeiten kann.


Zur Blog-Reihe: ODI aus Sicht des OWB-Entwicklers

Hierbei wird nicht unbedingt die systematische Vorgehensweise bei der Entwicklung mit dem ODI betrachtet. Anhand der Entwicklungsschritte im OWB werden die Parallelen oder auch komplett andere Vorgehensweisen im ODI im Detail beschrieben.

Die Blog-Reihe gliedert sich in zwei größere Bereiche, die selbst in einzelne Unterblogbeiträge untergliedert sind – und immer aus Sicht des OWB-Entwicklers:

  • ETL-Entwicklung
    • Projekte
    • Locations und Module
    • Mappings
    • Workflows
    • Deployment
  • Metadaten
    • Repositories
    • Skriptsprachen

Bei der Entwicklung selbst werden, wie schon oben beschrieben, die Parallelen zwischen den beiden ETL-Tools aufgezeigt. Wer mit dem OWB sich im Detail mit den Metadaten auseinandergesetzt hat, um beispielsweise mit SQL-Mitteln die Ausführung von Mappings zu ermitteln, wird im zweiten größeren Teil der Blog-Reihe weit mehr Unterschiede finden. Hier bringt der ODI weit mehr mit als der OWB. Auch wird sich der zweite Teil der Blog-Reihe den Skriptsprachen aus OWB und ODI widmen.

Der Blog-Beitrag richtet sich an folgende Versionen

  • OWB 11g Release 2 (11.2.0.4)
  • ODI 12c (12.1.3)
  1. Das Projekt

Der OWB-Entwickler beginnt seine Entwicklung für ETL-Strecken mit einem Projekt. Die Erstellung ist im OWB unspektakulär. Die Eigenschaften eines OWB-Projektes völlig überschaubar. Im Create-Dialog des Projektes gibt es lediglich zwei Eigenschaften, die es auszufüllen gilt:

 

owb_new_project

 

Auch stellen sich die Eigenschaften im OWB wie folgt dar:

owb_project_properties

 

Im ODI ist es fast wie beim OWB. Um ein neues Projekt anzulegen muss ein Projektname erfasst werden. Alles andere ist optional. Die Erfassung erfolgt im ODI direkt in der Entwicklungsumgebung des ODI-Studios.

odi_new_project

 

Was es im OWB nicht gegeben hat, ist die Möglichkeit, Objekte des Repository zu versionieren. Wer jetzt jedoch denkt, es handelt sich hierbei um eine Versionierung mit Tools wie SubVersion, CVS oder Git, wird enttäuscht werden. Die Versionierung wird über Datenbankmittel sichergestellt.

odi_project_versioning_2

odi_project_versioning

 

Der größte Unterschied bei der Anlage von Projekten liegt jedoch in der Projektorganisation. Im OWB stehen einem Projekt nicht alle Repository-Objekte zur Verfügung. Eine importierte Tabelle in ein Modul im OWB kann nur in dem Projekt für die ETL-Entwicklung genutzt werden, wo das Modul zugeordnet ist. Ist diese Tabelle auch in einem anderen Projekt erforderlich, muss in diesem Projekt auch wieder in die Metadaten des Repository importiert werden. Daher war und ist es immer noch wichtig, sich die Projektorganisation im OWB gut zu überlegen.

Im ODI liegt hier eine komplette Trennung vor. Durch die Erstellung einer Topology, die im nächsten Blogbeitrag zu den Locations beschrieben wird, erfolgt eine strikte Trennung von Projekten und Repository-Objekten. Alle erstellten Projekte nutzen die einmal angelegte physikalische und logische Strukturen zur Entwicklung von Datenintegrationen.

Eine Trennung gibt es für folgende Repository-Objekte jedoch auch im OWB:

  • Location, die die Verbindungsinformationen zu den Quell- und Zielsystemen eines DWH-Systems repräsentieren
  • Alle Objekte aus dem Register „Globals“, wie zum BeispielPublic
    • Transformation
    • Public Experts

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.