Modernisierung von PL/SQL und Forms Applikationen Perry Pakull Technology Manager Trivadis GmbH DOAG SIG Development Berlin, 26.03.2009

About me Perry Pakull Trivadis GmbH DOAG Technology Manager Oracle based Development Senior Consultant Architekt DOAG Leiter SIG Fusion Middleware Modernisierung von PL/SQL und Forms Applikationen

Agenda Warum Modernisieren? Der Weg der Modernisierung Modernisierung als Prozess Szenario Forms Szenario SOA Fazit Daten sind immer im Spiel. Modernisierung von PL/SQL und Forms Applikationen

Warum Modernisieren: Realitäten Viele unternehmenskritische Systeme basieren auf Oracle Forms oder auf PL/SQL Technologien ERP Systeme, Logistik und Lager Die mittlere Lebensdauer einer Unternehmensanwendung beträgt 12 -15 Jahre von Unternehmensdaten beträgt 20 – 30 Jahre Oracle wird sowohl PL/SQL als auch Forms weiter entwickeln Der Weg in die Zukunft ist die Migration der bestehenden PL/SQL und Forms-Applikationen auf moderne Architekturen, Upgrade auf die neuesten Versionen und Integration mit State of the Art- Technologien Modernisierung von PL/SQL und Forms Applikationen

Warum Modernisieren: Realitäten Aus Kundensicht: Neustrukturierung von IT Systemen mit dem Ziel höhere Flexibilität und niedrigere Kosten im Betrieb Aus Kundensicht: Investitionsschutz durch weiter Verwendung bestehender Funktionalität Datenbanknahe Entwicklung: In der Praxis bewährt es sich, datennahe Funktionalität wie beispielsweise die Historisierung, die Weiterverarbeitung und die Konsolidierung von Datenbeständen auch in der Datenbank zu realisieren ABER: Modernisierung bedingt eine Restrukturierung der Anwendung! Modernisierung von PL/SQL und Forms Applikationen

Warum Modernisieren: Aspekte Grundlegende Eigenschaft PL/SQL und Forms: Die Anwendungen sind datenzentriert realisiert Moderne Architekturen: Objekt- oder Komponenten-Modelle, die Geschäftsprozesse abzubilden Konsequenz: Die Realisierung orientiert sich an Prozessen und nicht an Daten Folge: Modernisierung = Restrukturierung von datenzentrierten Umsetzung hin zu loseren für eine prozesszentrierte Lösung geeignete Struktur Modernisierung von PL/SQL und Forms Applikationen

Agenda Warum Modernisieren? Der Weg der Modernisierung Modernisierung als Prozess Szenario Forms Szenario SOA Fazit Daten sind immer im Spiel. Modernisierung von PL/SQL und Forms Applikationen

Der Weg der Modernisierung Modernisierung von PL/SQL und Forms Applikationen

Ausgangslage: Verschiedene Applikationstypen Client – Server Forms Application: Vielzahl verteilter PL/SQL Einheiten, nicht modular, keine oder nur wenige Libraries oder viele Trigger, die Standardverhalten überschreiben Web Forms Application: Oft automatisiert migriert, ohne Logik zu ändern – dieselben Mängel wie Client – Server Forms PL/SQL Application: Gewachsen, funktional sehr mächtig, ohne Strukturierung in Packages, ohne Namenskonventionen, Parametrisierung und Formatierung Structured PL/SQL Application: Anwendungen, deren Package-Struktur auf logischen Einheiten und einer klaren Schichtung wie beispielsweise die Trennung von Datenzugriffs- und Geschäfts-Logik basiert Modernisierung von PL/SQL und Forms Applikationen

Zielsysteme: Verschiedene Typen SOA: Service als Basiskomponente - PL/SQL Packages als Services macht die Integration in neue auf SOA basierenden Anwendungen möglich JAVA und .NET: Gut strukturierte PL/SQL Packages vereinfacht die Modernisierung mit JAVA oder Microsoft .NET Technologien Web Forms: Die Modernisierung in Richtung Web Forms bedeutet neben Auslagerung des PL/SQL Codes in die Datenbank und Strukturierung der Forms Module in Libraries WICHTIG FÜR ALLE: Strukturierung des PL/SQL Code in geschichtete Packages Modernisierung von PL/SQL und Forms Applikationen

Agenda Warum Modernisieren? Der Weg der Modernisierung Modernisierung als Prozess Szenario Forms Szenario SOA Fazit Daten sind immer im Spiel. Modernisierung von PL/SQL und Forms Applikationen

Modernisierung als Prozess Modernisierung von PL/SQL und Forms Applikationen

Evaluating Business Aim Erfassung und Dokumentation der Ziele der Modernisierung eines bestehenden Systems in einem Anforderungskatalog (Target System Requirement Catalog) Definition, Gewichtung und Abnahme aller Kriterien Modernisierung von PL/SQL und Forms Applikationen

Evaluating Target System Architecture Die Zielarchitektur hat Einfluss auf den Strukturierungsprozess Die Schichtung der Packages, welche im Rahmen der Restrukturierung erfolgt, sollte auf die Zielarchitektur ausgerichtet werden Eine kombinierte Nutzung, beispielsweise durch Web Services und durch direkten Aufruf aus einen JAVA oder einem .NET Programm, bedingt die Einführung von Aufrufschnittstellen in Form von zusätzlichen PL/SQL Packages Modernisierung von PL/SQL und Forms Applikationen

Evaluating Target System Architecture Szenarien SOA, Java, .NET, Web Forms oder Kombinationen Beispiele Backoffice Anwendung mit Client-Server Forms  Backoffice mit Web Forms und Extranet Teil mit Java Web Applikation Unstrukturierte, gewachsene PL/SQL Anwendung  Geschichtete und strukturierte Sammlung als Packages zur Ansteuerung über Process Engine und Rule Engine Forms Anwendung  PL/SQL Packages als Basisfunktion für eine neue .NET Anwendung Wichtig Die Zielarchitektur hat Einfluss auf die Art der Strukturierung der PL/SQL Packages Modernisierung von PL/SQL und Forms Applikationen

Existing System Analysis Grobe Analyse des bestehende System bezüglich Mengengerüstes, Grundfunktionalität und Schnittstellen Ziel der Analyse ist ein Gesamtbild des bestehenden Systems als Grundlage für die Restrukturierung Modernisierung von PL/SQL und Forms Applikationen

Analysen General Functional Blocks Overview Technology Overview Der Gesamtaufbau und die wichtigen funktionalen Bereiche des Systems müssen erfasst und dokumentiert werden Technology Overview Die Technologie aller Komponenten wird erfasst. Dabei ist insbesondere die Version der Datenbank oder der Forms Anwendung, die Verteilung und die Schnittstellen sowie die Client-Typen zu dokumentieren Quantity Structure Das Mengengerüst des Systems wird erfasst. Neben der reinen Erfassung der Anzahl Funktionen, Datenbankobjekte steht hier die Unterscheidung zwischen denjenigen Teilen des Systems, die oft benutzt werden und denjenigen Teilen, die selten oder nie benutzt werden, im Vordergrund Modernisierung von PL/SQL und Forms Applikationen

Listen Accessing Client Systems List Existing Documentation List Sämtliche Systeme, die auf das System zugreifen, müssen erfasst werden Existing Documentation List Die eventuell vorhandene Dokumentation wird aufgelistet People with Know-how List Alle Personen, die über das bestehende System bescheid wissen, werden erfasst Modernisierung von PL/SQL und Forms Applikationen

Existing System Analysis Ziel = Gesamtbild des bestehenden Systems erstellen Notwendige Schritte für Forms Module komplett zerlegen PL/SQL Code isolieren Identifikation Präsentationslogik, Geschäftslogik und Datenlogik Abhängigkeiten zu Datenbankobjekten Redundanzen und nicht mehr unterstützte Funktionen Einsatz eines Analysetools nützlich (Scripts oder Produkte) Modernisierung von PL/SQL und Forms Applikationen

PL/SQL Coding in Forms PL/SQL Coding Guidelines für Forms Module Soviel wie möglich PL/SQL Code auslagern Modularisierung und Wiederverwendung So wenig wie möglich in den Forms Triggern programmieren Forms Trigger: Aufruf der ausgelagerten Programmeinheit mit den benötigten Parametern Möglichkeiten in Forms Program Units PL/SQL Code der nur im engeren Kontext des Moduls sinnvoll ist PL/SQL Libraries Generischer PL/SQL Code, der wieder verwendbar ist Stored Procedures Alles, was auch alleine in der Datenbank verwendbar ist Bereitstellung von zusätzlichen Daten, alle DML-Befehle Modernisierung von PL/SQL und Forms Applikationen

PL/SQL Coding in Forms PL/SQL Coding Guidelines erstellen Trennung in Präsentationslogik, Geschäftslogik und Datenlogik Guidelines wo wird welche Logik abgelegt Definitionen erstellen Präsentationslogik (Applikationslogik) Navigation, Verhalten der Benutzeroberfläche, Anpassen von Objekteigenschaften zur Laufzeit Geschäftslogik (Business Logik) Überprüfung der Daten in Bezug auf Geschäftsregeln sowie die entsprechende Fehlerbehandlung Jede Veränderung der Daten Datenlogik Speichern der Daten in der Datenbank Modernisierung von PL/SQL und Forms Applikationen

Allgemeine PL/SQL Coding Guidelines Die Grundregel für die Organisation von PL/SQL Code ist einfach: Modularisierung mit Hilfe von Packages! Packages gruppieren den vorhandenen PL/SQL Code zu logischen Einheiten Die persistenten Variablen in einer Package Spezifikation oder in einem Package Body sind universell verfügbar Es wird gegen eine Spezifikation im Sinne einer API programmiert, die Implementierung kann sich ändern, berührt die Programme aber nicht Der Memory-Effekt bei Packages ist bekannt, darf aber gerne als Argument für bessere Performance angeführt werden Modernisierung von PL/SQL und Forms Applikationen

Allgemeine PL/SQL Coding Guidelines Vermeide doppelten PL/SQL Code - Probleme zentral an einer Stelle lösen Erstelle einfache und unabhängige Komponenten Erstelle Packages, die den Aufruf von Built-Ins kapseln Parametrisiere Applikationen wo immer möglich Vermeide Parameter durch Überladen der Prozeduren Setze Standard-Werte für Parameter ein Verwende Parameter für Programmeinheiten statt Variablen Modernisierung von PL/SQL und Forms Applikationen

Allgemeine PL/SQL Coding Guidelines Verwendung von Packages Namenskonventionen Einheitliche Parametrisierung Einführung verschiedener Schichten API Packages Service Packages Modernisierung von PL/SQL und Forms Applikationen

Layering Modernisierung von PL/SQL und Forms Applikationen

Layering Data Layer Tabellen Views (pro Tabelle, generiert) Primary Key als Surrogate Key, ID gezogen aus Sequence Audit Felder: CREATOR, CREATION_DATE, EDITOR, EDIT_DATE Keine Trigger, sondern Verwendung der Business Logic Packages Views (pro Tabelle, generiert) 1:1 Abbildung auf die Tabellen Sequence (pro Tabelle, generiert) Liefert ID für Primary Key Object Types (pro Tabelle, generiert) RECORD Struktur als Object Type COLLECTION Type basierend auf RECORD Struktur Optional VPD Packages Modernisierung von PL/SQL und Forms Applikationen

Layering Access Layer Service Layer API Packages (pro Tabelle, generiert) SELECT, INSERT, UPDATE, DELETE, LOCK Prozeduren für Forms Bieten Hooks für Aufruf Business Logic Packages (DELEGATE) Business Logic Packages (pro Tabelle , generiert) Validierung und Error Handling Manipulation der Daten Service Layer Service Packages mit Ausrichtung auf Zielarchitektur Granularität mit Ausrichtung auf Zielarchitektur Generiert pro Tabelle orientiert an Daten Tabellenübergreifend orientiert an Prozessen Modernisierung von PL/SQL und Forms Applikationen

Finalize Target System Die Anwendung wird basierend auf der gewählten Zielarchitektur vollständig umgesetzt Dies bedeutet beispielsweise in einer SOA die Modellierung von Geschäftsprozessen und Geschäftsregeln und die Integration des PL/SQL Packages als Web Service in einen BPEL Prozess In einer auf JAVA oder .NET Technologie basierenden Zielarchitektur bedeutet es die Integration der Schnittstelle in die Anwendung Im Falle von Web Forms bedeutet das die Umstellung der Datenzugriffe von einer direkten Tabellenmanipulation hin zur Verwendung der erzeugten PL/SQL Packages Modernisierung von PL/SQL und Forms Applikationen

State of the Art System Der Modernisierungs-Prozess ist abgeschlossen und das bestehende System wird weiter betrieben Business Logik und Datenlogik befinden sich in Packages in der Datenbank Forms Module sind umgestellt Modernisierung von PL/SQL und Forms Applikationen

Agenda Warum Modernisieren? Der Weg der Modernisierung Modernisierung als Prozess Szenario Forms Szenario SOA Fazit Daten sind immer im Spiel. Modernisierung von PL/SQL und Forms Applikationen

Szenario Forms: Putting it all together Verwendung der modernisierten Strukturen in Forms Data Access mit Views und Instead-of-Triggern Data Access mit Table API Vorteile Trennung der Schichten Modularisierung Wiederverwendbarkeit Flexibilität Nachteile Hohe Komplexität Hoher Aufwand auch in Forms Modernisierung von PL/SQL und Forms Applikationen

Data Access mit Views und Instead-of-Triggern Query und Transaktionen des Data Blocks basieren auf View SELECT wird über die View implementiert Normales Query-Verhalten Instead-of-Trigger der View verwenden das Table API Modernisierung von PL/SQL und Forms Applikationen

Data Access mit Table API Data Block basiert für Query auf View SELECT wird über die View implementiert Normales Query-Verhalten Data Block basiert für Transaktionen auf Table API Package Zusätzliche Transaktionstrigger erforderlich (INSERT, UPDATE, DELETE, LOCK) Modernisierung von PL/SQL und Forms Applikationen

Agenda Warum Modernisieren? Der Weg der Modernisierung Modernisierung als Prozess Szenario Forms Szenario SOA Fazit Daten sind immer im Spiel. Modernisierung von PL/SQL und Forms Applikationen

Szenario SOA: Putting it all together Verwendung der modernisierten Strukturen in eine SOA Native Database Web Service (11g) Enterprise Service Bus Modernisierung von PL/SQL und Forms Applikationen

Applikationstypen A: Business Logik und Datenzugriff mit PL/SQL in der Datenbank B: Business Logik implentiert in Java, Datenzugriff implementiert mit PL/SQL in der Datenbank C: Business Logik und Datenzugriff implentiert in Java (JDBC oder O/R Mapper), kein PL/SQL in der Datenbank Application A Application B Application C Business Logic PL/SQL Java Java Data Access PL/SQL PL/SQL ORM Storage Tables Tables Tables Modernisierung von PL/SQL und Forms Applikationen

Nutzung von Services für diese Applikation Für B und C kann eine Web Service Façade in Java implementiert werden Wie kann bestehende PL/SQL Logik als Web Service genutzt werden? Application A Application B Application C Web Service Facade ???? Java Java Business Logic PL/SQL Java Java Data Access PL/SQL PL/SQL ORM Storage Tables Tables Tables Modernisierung von PL/SQL und Forms Applikationen

Native Database Web Service (11g) Servlet in der Datenbank (DBWS) agiert als Gateway: SQL Statements XQuery PL/SQL Application A Web Service Facade DB Servlet Business Logic PL/SQL Data Access PL/SQL Storage Tables Modernisierung von PL/SQL und Forms Applikationen

Native Database Web Service (11g) Vorteile Einfache Implementierung kein zusätzliches Middle Tier, Datenbank als Web Service Provider Nachteile Direkte Publizierung des PL/SQL Interfaces Enge Kopplung zwischen Service Consumer und Service Provider Kein kanonisches Datenmodell Contract last / Code first Modernisierung von PL/SQL und Forms Applikationen

Enterprise Service Bus (ESB) ESB ergänzt eine indirekte Zugriffsschicht Oracle ESB und Adapter Framework ermöglichen Zugriff auf PL/SQL Packages, Datenbank Tabellen ESB ESB ESB Integration Platform Adapter Adapter Application A Application A Application A Web Service Facade DB Servlet Business Logic PL/SQL PL/SQL Data Access PL/SQL PL/SQL Storage Tables Tables Tables Modernisierung von PL/SQL und Forms Applikationen

Enterprise Service Bus (ESB) Vorteile Lose Kopplung Contract First ist möglich Kanonisches Datenmodell Bessere Trennung der Anforderungen Trennung zwischen technischen (Adapter) und geschäftlichen Belangen Nachteile Zusätzlicher Layer erhöht die Komplexität Zusätzliche Transformationen Modernisierung von PL/SQL und Forms Applikationen

Business Process Execution Language (BPEL) Erweiterung mit BPEL Business Process Execution Language (BPEL) Integration Platform ESB Adapter Application A Application B Application C Web Service Facade Java Java Business Logic PL/SQL Java Java Data Access PL/SQL PL/SQL ORM Storage Tables Tables Tables Modernisierung von PL/SQL und Forms Applikationen

Agenda Warum Modernisieren? Der Weg der Modernisierung Modernisierung als Prozess Szenario Forms Szenario SOA Fazit Daten sind immer im Spiel. Modernisierung von PL/SQL und Forms Applikationen

Fazit PL/SQL und Forms Anwendungen lassen sich für moderne Anwendungen umbauen Zentrale Tätigkeit ist die intelligente Restrukturierung des PL/SQL Codes in Packages PL/SQL Coding Guidelines PL/SQL Development Best Practice Generatoren für PL/SQL Code und Objekte Die Umsetzung datennaher Funktionalität ist in jeder modernen Architektur oft die beste Lösung Modernisierung von PL/SQL und Forms Applikationen

Referenzen Praktische Anwendungsentwicklung mit Oracle Forms HANSER Verlag 320 Seiten, Flexibler Einband ISBN: 3-446-41098-8 Architecture Blueprints HANSER Verlag 358 Seiten, Flexibler Einband ISBN: 3-446-41201-8 Modernisierung von PL/SQL und Forms Applikationen

Vielen Dank! ? www.trivadis.com