© CGI Group Inc.

Oracle Apex als Data Quality Gateway

für das DWH

Bertrand Caradec, CGI Deutschland

09.06.2015, Apex Connect, Düsseldorf

Referent: Bertrand Caradec

Senior Consultant bei CGI Deutschland (Frankfurt)

Dipl. Ing. Informatik

10 Jahre Berufserfahrung

• BI, DWH, ETL, Reporting

• Oracle (DB, PL/SQL, Java, Apex)

• IBM Cognos BI

• Oracle Certified Expert Apex

• Oracle Certified Professional

Advanced PL/SQL

• Sun Certified Java Programmer

• Cognos Professional Designer

Weltweit zuhause:

Das Unternehmen CGI

CGI ist der weltweit

fünft-größte unabhängige

Anbieter von IT- &

Geschäftsprozess-

Dienstleistungen

Erstklassige Business- und

IT-Beratung

End-to-End

IT- und

Geschäftsprozess-

Dienstleistungen

38 Jahre erfolgreiche

Partnerschaft mit

unseren Kunden

Kundennähe

in Kombination mit

unserem globalen

Delivery-Netzwerk

Über 100

führende IP-basierte

Lösungen

Fokussiertes

Branchen- und

Themen-

Know-how

71.000 Mitarbeiter

2.500 in DE

10 Mrd. CAD$ Jahresumsatz

Service für über

10.000 Kunden

von weltweit über

400 Standorten

3

Immer die aktuellen Trends im Auge:

z.B. Agile BI, Big Data,

Multi Device BI, In-Memory

Erfahrenes Beraterteam

mit tiefem fachlichen Verständnis & langjähriger

Erfahrung in komplexen Projekten

Vertrauensvoller Partner für u.a. für Dt. Telekom, Dt. Bahn, Vodafone, KION,

MAN, 1&1, EZB, Gothaer & buch.de

Umfassende BI Betreuung

BI Strategie, BI Methoden & Prozesse, Audits &

Reviews, Organisation- und BICC, Architektur,

ETL-, DWH-, Reporting-Implementierung

Berlin

Hamburg

Bremen

Düsseldorf

Stuttgart

München

Frankfurt/M.

Darmstadt

Köln/Bonn

Mannheim

50 Mitarbeiter

10 Mitarbeiter 64 Mitarbeiter

4 Mitarbeiter

2 Mitarbeiter

10 Mitarbeiter

10 Mitarbeiter

Zusammenarbeit

mit namhaften Partnern

& tiefe Technologie-

Expertise u.a.:

150 Mitarbeiter in DE 4.000weltweit

Business Intelligence: Unser deutsches Team

Agenda

Das DWH Projekt bei DB Schenker

Übersicht der APEX Lösung für Stammdaten

Data Quality Checks

Autorisierung und UTF16 LE Unterstützung

Fazit, Fragen und Diskussionsrunde

1

2

3

4

5

Der Kunde: DB SCHENKER RAIL

• führende Europäische Güterbahn mit innovativen Transport- und

Logistiklösungen

• bedient mehr als 3.100 Gleisanschlüsse für ihre Kunden

• bietet Zugang zu einem der größten Schienennetze Europas

• entlastet den Straßenverkehr jeden Tag mit über 5.000 Zügen und

mehr als 100.000 Güterwagen im Einsatz -> entspricht einer LKW-

Schlange von Hamburg bis Rom

6

Das Projekt: das BICC der DB Schenker Rail

• Ziel: das BICC der DB Schenker Rail inhaltlich zukunftsfähig und mit

herausragender Performance der Data Warehouse Systeme

aufzustellen

7

Fertigstellung des Data Warehouse Blueprint, abgeleitet

von dem CGI BI Framework

• CGI hat mit fachlicher, organisatorischer und technischer Expertise die

Durchführung unterstützt:

Sizing der Hardware, Entscheidung für ein

„Engineered System“: Oracle Exadata

Umsetzung des ersten Projekts:

Reporting für das interne Rechnungswesen

8

• Grundlagen des zukünftigen Unternehmensdatenmodells auf Basis

Data Vault

• Erstellung von 300 ETL Fragmenten mit ODI

• Oracle Apex Masken / Anwendung zur Erfassung von Stammdaten direkt durch den Fachbereich wurde aufgebaut

• Entwicklung von Standard Reports mit BO

Zielarchitektur

9

Stammdaten

Stammdaten

10

• Beispiele:

Kostenstellennummern, Bahnstellennummern,

Übersetzungen für die BI Applikationen,

ETL Look-Up-Tabelle, Zugriffsberechtigungen,

Mengeneinheiten ...

• Ausgangsituation:

kein globales Master Data Management

Stammdaten werden nicht zentral gepflegt oder konsolidiert

-> ein globales Gateway-Tool soll für Stammdaten eingeführt werden

-> Stammdaten werden dann in Foundation Layer versioniert

Agenda

Das DWH Projekt bei DB Schenker

Übersicht der APEX Lösung für Stammdaten

Data Quality Checks

Autorisierung und UTF16 LE Unterstützung

Fazit, Fragen und Diskussionsrunde

1

2

3

4

5

Ziele und Requirements der Anwendung

12

• Erfassung der Stammdaten des DWH durch den Fachbereich

• Soll als international Import / Export File Gateway für Stammdaten dienen

• Ablösung von verschiedenen Excel Files in X Format

-> einheitliches Format

• Datenkorrektur soll im Tool möglich sein

• UTF16 LE soll unterstützt werden

• Quality Checks sind durchzuführen

• Autorisierung (wer darf welche Stammdaten ändern)

Warum APEX?

• schnelle RAD Entwicklung, schnelle Ergebnisse

• performant, direkter Zugriff auf die Daten mit SQL und PL/SQL

• Kostenlos und 100% Browser – Zero Footprint

• APEX hat Zukunft (unterstützt von Oracle, starke Community), gut in Deutschland angekommen

• Schon aktiv benutzt bei der Deutsche Bahn (Small Applications Team von DB Systel, DB Schenker)

• Gutes APEX Know-How bei CGI

13

Übersicht der Anwendung

14

Apex Gateway

1) File Import

DWH Landing Zone

Data Quality Checks

2) Datenkorrektur in APEX Masken Stammdaten

UTF16 Files

3) File Export

Target Tables

DWH Staging Area

DWH Foundation Layer

ETL mit ODI

ETL mit ODI

BG PL

DE

RO

Data Vault

Stammdaten Versionierung

12 Landesgesellschaften

Data Quality Checks

Übersicht der Releases

15

• Release 1: neuer Import/Export in UTF16 Format, PL/SQL code

ausgelagert in einem Package, Checks konfigurierbar

1 Woche Aufwand

• Prototyp: Layout, Navigation, Autorisierungskonzept,

18 Stammdaten-Tabelle

10 Tage Aufwand

• Release 2: 12 neue Stammdaten-Tabelle, fachliche Prüfung,

neuer Import Vorgang, Event Handling für ODI

1 Woche Aufwand

• Release 3: neue Stammdaten-Tabelle, Anmeldung via LDAP,

Mehrsprachigkeit

Ongoing – interne Entwicklung

Oracle 11gR2 Server

Komponenten - Übersicht

16

APEX_040200

Apex Workspace

DWH_LZ

Stammdaten

Konfigdaten des

Gateways

PL/SQL Code

(Business Logik)

Views für

fachliche Prüfung

XML DB HTTP

Server

EPG

(Emmbedded PL/SQL

Gateway) like

mod_plsql

ANONYMOUS

http

server:8080/apex/f?p=App:Page Sql*net

Apex Anwendung

Users

User groups

Parsing Schema

FLOWS_FILES

Storage von uploaded Files als BLOB

BG PL

DE

RO

Landing Zone

Business Logik in PL/SQL Package

17

• Benutzt für den Import, Export , Autorisierung und Validierung von Masken

• Warum ein Package statt Code in Apex PL/SQL Prozess benutzen?

- bessere Wartung des Codes: Code muss nur an einer Stelle geändert werden statt in X PL/SQL Prozess

- bessere Struktur/Lesbarkeit des Codes (Prozedur, Funktion)

- Code ist kompiliert: weniger Fehler, bessere Performance

- das Package kann für andere Anwendungen/Projekte benutzt werden

• Public Prozeduren/Funktionen werden von APEX aufgerufen: is_field_valid(), upload(), download()

Navigation

18

• 86 Seiten:

- Login

- Home

- Upload, Upload Log, View/Modify Redirect , Export

- 40 CHECK Seiten (1 pro Stammdaten-Tabelle)

- 40 MODIFY Seiten (1 pro Stammdaten-Tabelle)

• 2 Tabs

Seiten - Struktur

19

P101

Login

P1

Home

P2

Upload

P3

Upload Log

P4

View/Modify

P5

Export

P401

CHECK_MAN_IFRS_MAPPING

_BG

P440

CHECK_ADM_TRANSLATION_

REPORT

P601

MODIFY_MAN_IFRS_MAPPING_

BG

Tabelle Auswahl

P640

MODIFY_ADM_TRANSLATION_

REPORT

... ...

Redirection

40 CHECK Pages

+

40 MODIFY Pages

LDAP Anmeldung

Home Seite

20

• Anzeige und Auswahl der autorisierten Tabellen für den angemeldeten Apex User

Upload Seite

21

1) Das File wird automatisch auf den Oracle Server upgeloaded, Tabelle

FLOWS_FILES.WWV_FLOW_FILE_OBJECTS$, als BLOB

2) PL/SQL Prozess P_UPLOAD wird aufgerufen

3) Redirection auf die Upload Log Seite

Verarbeitung des Files:

Lesung, Validierung, insert

into target, error tracking

Import Logik

22

• Prozedur pck_apex_tool.upload(p_table_name varchar2)

BLOB File aus APEX View wwv_flow_files extrahieren

Lesung von großen String Blöcken

String Block durchgehen

Felder werden in einem PL/SQL Array gespeichert

End of line: Prozedur import_line(field_values):

is_field_valid?

FOR EACH Feld der Line

JA

Insert Line Into

TP_TARGET_TABLE

NEIN

Error in Tabelle UPLOAD_LOG

protokolieren

Falls Unique Key Constraint Violation:

Error in Tabelle UPLOAD_LOG protokolieren

Kein Fehler in

UPLOAD_LOG? JA

- Alte Daten aus der TARGET_TABLE löschen

- Datenübertragung in TARGET_TABLE aus

TP_TARGET_TABLE

NEIN

Keine Datenübertragung in die

TARGET_TABLE

1) Datenselektion

2) Datenlesung

+

Validierung

3) Datenübertragung

Import Regeln werden evaluiert

Upload Log Seite

23

• APEX Report basiert auf der Tabelle UPLOAD_LOG

• Seite wird automatisch nach dem Upload angezeigt

CHECK_table_name – Seiten 401..440

24

Interactive Report – Read only

1) SQL als Quelle eingeben 2) Formatierung

3) Verlinkung zur MODIFY_table_name

MODIFY_table_name – Seiten 601..640

25

• Standard APEX Prozesses benutzt für die Anzeige und die DML

• Validierung auf jede Spalte anhand gleiche PL/SQL Code wie beim File

Import

1 HTML Item (Text Feld, Text area, oder Datum) pro DB Spalte

Export Seite

26

• Export Knopf -> APEX Prozess P_EXPORT

• PL/SQL Prozedur PCK_APEX_TOOL.download(p_table_name in

varchar2) wird aufgerufen:

Dynamische Erzeugung

eines SQL Statements

für die Tabelle

(Import Regeln benuzt)

Records

Fetching Temporär

BLOB

PL/SQL Gateway

signalisieren: BLOB zum

Download bereit

Agenda

Das DWH Projekt bei DB Schenker

Übersicht der APEX Lösung für Stammdaten

Data Quality Checks

Autorisierung und UTF16 LE Unterstützung

Fazit, Fragen und Diskussionsrunde

1

2

3

4

5

Anforderungen – Beispiel einer Stammdatentabelle

28

Spaltenname Kurzbeschreibung / Format Datentyp

Pflicht-

feld Fachl. Prüf. UK

BI_APPLICATION

BI Applikation (Projekt) für welche die Berechtigung

gültig ist /

ASCII darstellbare Zeichen und Sonderzeichen

außer ; und |

String(255) Ja Ja X

BKU_USERNAME ASCII darstellbare Zeichen und Sonderzeichen

außer ; und | String(100) Ja Ja X

LEGAL_ENTITY

Gesellschaft, für die die Daten hochgeladen

werden sollen /

Zahlen und/oder Großbuchstaben keine

Sonderzeichen z. B. RFD1, SRD

String(4) Ja Nein x

AG850_BST Nummer der Bahnstelle im AG850 /

999999, inkl. führende Nullen String(6) Ja Ja X

VALID_FROM Beginn der fachlichen Gültigkeit /

DD.MM.YYYY Date Ja Nein X

VALID_TO Ende der fachlichen Gültigkeit /

DD.MM.YYYY Date Nein Nein

Format-Prüfung mit

Regular Expression

Typ-Prüfung,

Länge-Prüfung

Pflichtfeld-

Prüfung

Business Check

Eindeutigkeit-

Prüfung

Implementierungsansatz

29

• Die Quality Checks sollen nicht Hard coded sondern konfigurierbar sein

-> bessere Wartung/Anpassung der Anwendung

• Benutzung einer Konfig-Tabelle für die Quality Checks

• Eine PL/SQL API soll die Daten Überprüfung übernehmen

• Die gleiche PL/SQL API wird für die Quality Checks bei dem File Import

und der weiteren Bearbeitung in APEX Masken (APEX Validierungen)

benutzt

• Fachliche Prüfungen (Business Checks) werden in Form von SQL

Statements geschrieben

Definition der Quality Checks

30

• Die Konfiguration Tabelle:

Feld Beschreibung

TABLE_NAME PK

FIELD_NR PK

FIELD_NAME

CHECK_TYPE Art von Format Überprüfung. Mögliche Werte:

LEADING_0_NR – Ziffer mit führenden 0

REGEXP - regular expression

DATE

MONTH

FREE – keine Format Überprüfung

CHECK_FORMAT Abhängig von CHECK_TYPE. Beispiele:

09999 oder 0999999999 für LEADING_0_NR

^[A-Z0-9]{1,2}$ oder ^[1-9]?[0-9]$ für REGEXP

DD.MM.YYYY für DATE

MAX_LENGTH Maximale Größe des Felds

MANDATORY Y: obligatorisches Feld

N: Feld darf leer sein

BUSINESS_CHECK Fachliche Prüfung in Form von SQL Statement

Typ und Format-Prüfungen

31

• Checks per PL/SQL Code

• Date: OK falls to_date() Konvertierung kein Exception feuert

• Regular Expression: Benutzung der PL/SQL Funktion regexp_like

• Selbstgeschriebene Funktionen – Beispiele:

is_number für Check_Type = LEADING_0_NR

is_month für Check_Type = MONTH

Fachliche Prüfungen

32

• Prüfung der Daten (fachliche Stimmigkeit) einzelner, bzw. die

Kombination mehrerer Tabellenattribute

• Fachliche Stimmigkeit erfolgt mithilfe von SQL Statements, die auf

angegebene Views gehen

• Falls das SQL Statement den Wert 1 zurückliefert, ist die fachliche

Prüfung korrekt

Fachliche Prüfungen - Beispiele

33

Abhängige Prüfungen

Spec: Die Werte in UNIVERSE, REPORT und OBJEKT müssen zusammen in View V_BO_Objekte vorkommen

SELECT 1 FROM DUAL WHERE EXISTS (

SELECT 1 FROM V_BO_OBJEKTE

WHERE UNIVERSUM_NAME:FIELD_1_VALUE AND

REPORT_NAME = :FIELD_2_VALUE AND

OBJEKT_NAME = :FIELD_VALUE)

Unabhängige Prüfungen

Spec: Das SCENARIO muss in View V_Szenario enthalten sein

SELECT 1 FROM DUAL WHERE EXISTS (SELECT 1 FROM V_SZENARIO WHERE SZENARIO = :FIELD_VALUE)

FIELD_VALUE entspricht den Wert des Feldes zu überprüfen

FIELD_n_VALUE: Wert vom Feld n

PL/SQL API

34

FUNCTION is_field_valid(

p_tab_field_values in tTabFieldValues default getTabFieldValues,

p_field_nr_to_check in pls_integer,

p_import_rules in tTabImportRules default getTabImportRules,

p_input_type in varchar2 default c_input_mask,

p_error_msg in out varchar2)

RETURN BOOLEAN

File Import Apex Validierung

p_tab_field_values: Collection mit allen Werten des Records

p_field_nr_to_check: Feld Nr zu überprüfen

p_import_rules: Collection mit Quality Checks Information der LZ Tabelle

p_input_type: Quelle der Information (File Import oder Apex Maske)

p_error_msg: Fehlertext für Upload Log oder Apex Validierung

Validierungen in APEX Masken

35

• Jedes Attribut soll validiert werden wenn der User auf Apply Changes oder Create druckt

• Initialisierung der Validierungen

lädt die Import Regeln der Tabelle und kopiert die Werte der HTML Items in globalen PL/SQL Arrays des PCK_APEX_TOOL Packages

• Ausführung der Validierungen

PCK_APEX_TOOL.is_field_valid aufgerufen. Der Hidden Item P_VALID_MSG wird für die Fehlermeldung benutzt.

Apex Item für die Fehlermeldung

Vorteile des Implementierungseinsatz

36

• Bessere Wartung der Validierungen:

Konfigurationsänderung statt Änderung in Apex Code

(keine Apex Kenntnisse nötig)

• Schneller Überblick der Validierungen in der Konfig. Tabelle

• Gleiche Konfiguration, PL/SQL Code und Exceptions für die Validierungen in den Apex Masken und für die File Uploads

• Besseres Unit Testing möglich

• Wiederverwendbarkeit der PL/SQL API für weitere Apex Anwendungen oder ETL Prozesse

Agenda

Das DWH Projekt bei DB Schenker

Übersicht der APEX Lösung für Stammdaten

Data Quality Checks

Autorisierung und UTF16 LE Unterstützung

Fazit, Fragen und Diskussionsrunde

1

2

3

4

5

Autorisierung

38

• Jeder Gateway User hat Zugriff nur auf bestimmten Stammdaten-

Tabelle

• Autorisierung verwaltet durch User Gruppen

• 1 Stammdatentabelle = 1 User Gruppe

• Benutzung von APEX Autorisierung Schema, wird auf jede CHECK_

und MODIFY_ aufgerufen

Unterstützung von UTF16 LE Kodierung

39

• Unicode Kodierung nötig für Stammdaten aus Griechenland, Rumänien …

• Gateway Files werden in UTF16 LE (Low Endian) geliefert

• Oracle DB Character Set: UTF8 (AL32UTF8),

NCHAR Character Set: UTF16 (AL16UTF16) , aber in BE (Big Endian)

-> Komplexe Formatkonvertierung nötig anhand PL/SQL Funktionen

hextoraw(), utl_raw.cast_to_nvarchar2(), to_char()

Beispiel Export DB -> CSV File in UTF16 LE SELECT hextoraw(pck_apex_tool.reverse_hex(rawtohex(utl_i18n.string_to_raw(to_nchar(' || v_list_fields

|| '))))) line

FROM p_table_name ORDER BY row_id

Agenda

Das DWH Projekt bei DB Schenker

Übersicht der APEX Lösung für Stammdaten

Quality Checks mit APEX und PL/SQL

Autorisierung und UTF16 LE Unterstützung

Fazit, Fragen und Diskussionsrunde

1

2

3

4

5

Fazit

41

• Schnelle Entwicklung der Lösung in weniger als 4 Wochen:

- Prototyp in 2 Woche fertig

- Effektive Realisierung von neuen Anforderungen

• Anwendung wurde flexibel und kompakt

geschrieben:

schnelle und kostengünstige Integration von

neuen Stammdaten möglich

• Erfolgreicher APEX Know-How Transfer zu

internen DB Schenker Mitarbeitern durch

Workshop, Schulung und Dokumentation

• APEX wird für weitere Projekte des BICC in

Zukunft benutzt werden

Bertrand Caradec

Senior Consultant

Mobile: +49 151 163 60433

E-Mail: bertrand.caradec@cgi.com

Ich freue

mich auf Ihre

Kommentare &

Fragen!