Mandantenfähigkeit mit Oracle FGAC - doag.org NRW/2004...© SOPTIM AG - Version 01/Thomas Reff/15.03.2004 Mandantenfähigkeit mit Oracle FGAC Konzept und Erfahrungsbericht

© SOPTIM AG - Version 01/Thomas Reff/15.03.2004

Mandantenfähigkeit mit Oracle FGAC

Konzept und Erfahrungsbericht

2© SOPTIM AG - Version 01/Thomas Reff/15.03.2004

Mandantenfähigkeit mit Oracle FGAC

Thomas Reff

SOPTIM AG

Aachen / Essen

- März 2004 -

Konzept und Erfahrungsbericht


Die SOPTIM AG

� Über 30 Jahre als unabhängiger IT-Dienstleister am Markt

� mehr als 90 Mitarbeiter

� 2 Standorte Aachen und Essen

� Mehr als 1400 IT-Projekte erfolgreich abgewickelt

� Individualentwicklungen

� IT- und Fachberatung

� Produkteinführungen und IT-Dienstleistungen

� Kunden / Auftraggeber

� Energiewirtschaft

� Entsorgungswirtschaft

� andere Branchen


Inhalt

� Mandantenfähigkeit

� Anforderungen an mandantenfähige Software

� Gängiges Realisierungskonzept

� Zusätzliche Anforderungen aus der Praxis

� Praktische Realisierung mit FGAC

� Probleme

Performance


Mandantenfähigkeit

� Mandant:

� Rechtlich selbstständiges Unternehmen

� Konzerngesellschaft

� Mandantenfähigkeit:

� Virtuell exklusiv für einen Mandanten


Anforderung

� Mandant sieht nur seine eigenen Daten

� Aktivitäten anderer Mandanten unsichtbar

� Jeder Datensatz ist genau einem Mandanten zugeordnet

� Mandant kann Daten anderer Mandanten nicht manipulieren

� System verhält sich für jeden Mandanten, als hätte er sein eigenes

System

� Struktur zur Implementierung der Mandantenfähigkeit ist verborgen


Gängiges Realisierungskonzept

� Erweiterung des Datenmodells um Mandantenattribute (PK)

� Lesende und schreibende Zugriffe:

Mandanten in der WHERE-Klausel berücksichtigen

� Lesende Zugriffe: Kapselung durch Views, die den USER auswerten

Noch simpler: jeder User hat seinen eigenen Satz Views

� Schreibende Zugriffe: Über Packages, die Mandantenattribute setzen

� Bei der Anmeldung wird der Mandant festgelegt


Realisierung mittels FGAC

� Erweiterung des Datenmodells um Mandantenattribute (PK)

� Jede Tabelle bekommt Security-Policy die aktionsabhängig

(select / insert / update / delete) zugehörige Security-Function

ausführt

� Security-Function: Frei programmierbarer PL/SQL-Code

� Security-Function liefert String, der als zusätzliches Prädikat der

WHERE-Klausel hinzugefügt wird


SELECT attribute

FROM (SELECT *

FROM table

WHERE <Bedingung>)

SELECT attribute

FROM table

��

Query Rewrite

��

��

SELECT attribute

FROM table

��

SELECT attribute

FROM table


Typische zusätzliche Anforderungen aus der Praxis (I)

� „Globale“ Daten

(Fehlertexte, Systemparameter ...)

� „Nur-public“ - Pfleger

(sieht und pflegt nur globale Daten)

� Mandantenübergreifender Superuser

(Datenbereinigung, Datenpflege, Migration)

� Anwenderspezifische Daten, nicht mandantenspezifisch


Typische zusätzliche Anforderungen aus der Praxis (II)

� Gemischte Tabellen mit mandantenspezifischen und

globalen Daten

� Überschreiben globaler Daten mit mandantenspezifischen Daten und

umgekehrt


Reale Anforderung des Kunden

� Bestehende produktive Anwendung (nicht mandantenfähig)

� Mandantenfähigkeit für andere Konzerngesellschaften gewünscht

� Zugriff auf die Datenbank durch verschiedene Clients

� Aufwand für Realisierung und Regressionstest gering halten


Transparente Implementierung

� Sicht auf Datenbankstrukturen bleibt

für die Anwendung, die Packages

und die Views erhalten

� Mandantenfähigkeit wird gekapselt

� Idee:

Mandantenfähigkeit auf

tiefstmöglicher Ebene

implementieren

��

��

��

��

��


��

��

E S,I,U,D

�!��

S��"#$��%&'

��()%#$

&��

"��

*��

��

+�� ","��(%�#-�

��.�

-!��

�!��

/%"#$��

� ��

"�� 0��

��

�!��


Realisierung (I)

� Mandantentabelle, Datenmodell mit durchgängig vererbter MND_ID

� P-Views: Abbild der Tabellen, implementieren horizontale

Berechtigungen via FGAC, MND_IDs sind sichtbar

� T-Views: Abbild der P-Views, verbergen MND_IDs:

Alte Sicht auf die Strukturen

� Ein PL/SQL-Package bündelt alle benötigten Funktionen

� Zur Laufzeit kein weiteres SQL


Realisierung (II)

� LOGON-Trigger setzt SYS_CONTEXT (Festlegung des Mandanten)

� Bei Schreibzugriffen: BEFORE INSERT-Trigger pflegen die MND_IDs

� Erweiterung „natürlicher“ PKs und UKs um MND_ID

� Alle bestehenden Packages, Views und der Anwendungscode setzen auf T-Views auf

� Alle Objekte gehören dem APP_OWNER; alle Zugriffe erfolgen als APP_USER_MNDx


Durchführung mittels Skriptmaschine

� Black Box Verfahren

� Regelbasierte Generierung eines Skriptstapels

� Maschine wird parametriert

� Alle notwendigen Daten aus dem Data Dictionary

� Universell, nicht anwendungsbezogen

� Wiederverwendbar und erweiterbar

� Die Skriptmaschine kann beliebig oft ausgeführt werden

� Änderungen in der Architektur schlagen sich in den Generatorskripten wieder und sind gut dokumentierbar


Versionsabhängige Probleme

� 8.1.6 und älter:

Bei Änderung des Kontexts bzw. globaler Variable mit

Prädikatänderung, kein erneutes Parsing eines offenen Cursors

� 8.1.7:

Bei Änderung einer globalen Variable mit Prädikatänderung, kein

erneutes Parsing eines offenen Cursors

� 9.2.0:

Probleme behoben


Probleme (I)

� Debugging:Mandant kein Zugriff auf die Packages, Owner kein Mandantattribut

Prozedur im Mandantenpackage ��

� DDL mit Default-Value / Datenjobs:Trigger führen Code aus, ohne Context entsteht evtl. Fehler

Trigger abschalten

� Data Dictionary:Anwendungen holen Informationen aus dem Data Dictionary

Geänderte View vorschieben


Probleme (II)

� Änderungen am Datenmodell müssen in T-Views und P-Views

nachgezogen werden

� Referentielle Integrität

� Parent-Datensatz gehört anderem Mandanten

� ON DELETE SET NULL / ON DELETE CASCADE


Performance

� Im Allgemeinen gleiche Ausführungszeiten

� Einige Abfragen durch geänderten Ausführungsplan langsamer

� Native-Dynamic-SQL innerhalb einer Schleife:

Jedes Statement wird neu geparsed - Security Funktion wird jedesmal

mit ausgeführt

DBMS_SQL benutzen


[email protected]

www.soptim.de

Vielen Dank für Ihre Aufmerksamkeit

Niederlassung Aachen

Im Süsterfeld 5-7

52072 Aachen

Tel. (02 41) 9 18 79-0

Fax. (02 41) 9 18 79-109

[email protected]

Niederlassung Essen

Heinrich-Held-Straße 33

45133 Essen

Tel. (02 01) 8 42 10-0

Fax. (02 01) 8 42 10-518

[email protected]

Documents

Mandantenfähigkeit mit Oracle FGAC - doag.org NRW/2004...© SOPTIM AG - Version 01/Thomas Reff/15.03.2004 Mandantenfähigkeit mit Oracle FGAC Konzept und Erfahrungsbericht