Modernisierung von PLSQL und Forms Applikationen Perry Pakull

Modernisierung von PL/SQL und Forms Applikationen Perry Pakull Technology Manager Trivadis Gmb. H DOAG SIG Development Berlin, 26. 03. 2009 Basel · Baden Brugg · Bern · Lausanne · Zürich · Düsseldorf Frankfurt/M. · Freiburg i. Br. · Hamburg · München Stuttgart · Wien

About me § Perry Pakull § Trivadis Gmb. H ú Technology Manager Oracle based Development ú Senior Consultant ú Architekt § DOAG ú Leiter SIG Fusion Middleware 2 Modernisierung von PL/SQL und Forms Applikationen © 2009

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

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 4 Modernisierung von PL/SQL und Forms Applikationen © 2009

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! 5 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 6 Modernisierung von PL/SQL und Forms Applikationen © 2009

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

Der Weg der Modernisierung 8 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 9 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 10 Modernisierung von PL/SQL und Forms Applikationen © 2009

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

Modernisierung als Prozess 12 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 13 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 14 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 15 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 16 Modernisierung von PL/SQL und Forms Applikationen © 2009

Analysen § General Functional Blocks 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 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 17 Modernisierung von PL/SQL und Forms Applikationen © 2009

Listen § Accessing Client Systems 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 18 Modernisierung von PL/SQL und Forms Applikationen © 2009

Existing System Analysis § Ziel = Gesamtbild des bestehenden Systems erstellen § Notwendige Schritte für Forms ú Module komplett zerlegen § ú Identifikation Präsentationslogik, Geschäftslogik und Datenlogik § ú ú 19 PL/SQL Code isolieren 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 © 2009

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 20 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 21 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 22 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 23 Modernisierung von PL/SQL und Forms Applikationen © 2009

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

Layering 25 Modernisierung von PL/SQL und Forms Applikationen © 2009

Layering § Data Layer ú Tabellen § 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 26 Modernisierung von PL/SQL und Forms Applikationen © 2009

Layering § Access 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 27 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 28 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 29 Modernisierung von PL/SQL und Forms Applikationen © 2009

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

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 ú ú 31 Trennung der Schichten Modularisierung Wiederverwendbarkeit Flexibilität Modernisierung von PL/SQL und Forms Applikationen § Nachteile ú Hohe Komplexität ú Hoher Aufwand auch in Forms © 2009

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 32 Modernisierung von PL/SQL und Forms Applikationen © 2009

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) 33 Modernisierung von PL/SQL und Forms Applikationen © 2009

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

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

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 Data Access PL/SQL ORM Storage Tables 36 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 ? ? Java Business Logic PL/SQL Java Data Access PL/SQL ORM Storage Tables Web Service Facade 37 Modernisierung von PL/SQL und Forms Applikationen © 2009

Native Database Web Service (11 g) § 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 38 Modernisierung von PL/SQL und Forms Applikationen © 2009

Native Database Web Service (11 g) § 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 39 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 Adapter Application A Integration Platform Web Service Facade DB Servlet Business Logic PL/SQL Data Access PL/SQL Storage Tables 40 Modernisierung von PL/SQL und Forms Applikationen Tables © 2009

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

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

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

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 44 Modernisierung von PL/SQL und Forms Applikationen © 2009

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 45 Modernisierung von PL/SQL und Forms Applikationen © 2009

Vielen Dank! ? www. trivadis. com Basel · Baden Brugg · Bern · Lausanne · Zürich · Düsseldorf Frankfurt/M. · Freiburg i. Br. · Hamburg · München Stuttgart · Wien