Oracle APEX 19 Tutorial Teil 5 – Process and Condition

Dieser Teil des Oracle APEX Tutorials zeigt Ihnen, wie Sie Prozesse und Bedingungen ( Conditions ) in Ihren Anwendungen nutzen können.

Es ist ein wenig Zeit vergangen, seid dem ich den Teil 4 des APEX Einsteiger-Tutorials verfasst habe.  Die bisherigen Beschreibungen basierten noch auf der APEX Version 18.2. Diesem Artikel liegt nun die Version 19.1 zu Grunde, so dass Sie sich direkt mit dieser APEX Version vertraut machen können.

Noch einmal zur Erinnerung. Im letzten Artikel (Teil 4)  habe ich beschrieben, wie Sie für eine Tabelle eine Übersichtsseite und eine Form zum Erfassen und Bearbeiten des Tabelleninhaltes erstellen können.

Abbildung 34: APEX Form
Abbildung 34: APEX Form

Die Abbildung 34 zeigt Ihnen den Ausgangspunkt für dieses Tutorial. Für jede Spalten der Tabelle (NAMEN) wurde in der erstellen Form ein Feld – in APEX Item genannt – eingefügt. Je nach Spaltentyp wurden verschiedene Item-Typen verwendet.

Bei den letzten vier Items der Seite handelt es sich um Audit-Spalten in denen der Ersteller, das Erstellungsdatum sowie den letzten Änderer inkl. Änderungszeitpunkt erfasst werden sollen. 

Life-Cycle

Um zu verstehen, wie und wann ein sogenannter Process in einer APEX-Seite ausgeführt wird, ist es sinvoll sich zu vergegenwärtigen, wie eine Seite erzeugt wird.

Initial wird eine Seite durch einen Seitenaufruf per URL (http get) vom APEX-Web-Server angefordert. Der Web-Server reicht den Aufruf an die Datenbank weiter und führt dabei die PL/SQL Funktion f aus. Die Parameter, die der URL respektive dem http get request mitgegenen wurden, werden als Parameter an f  übergeben. In Abhängigkeit des aktuellen Session-Zustands, welcher im sogenannten Session-Cache gehalten wird, und den übergebenen Parametern, rendert f die neuen HTML-Seite. Diese wird dann als Antwort an den Client zurück geschickt. In anderen Szenarien erfolgt die Anfrage (Requests) mittels http-put, wobei sich der Ablauf aber ähnelt.

Im Rahmen dieses klassischen Anfrage- Antwortzyclusses ermöglicht es APEX Ihnen zu verschiedenen Zeitpunkten sogenannte Processes in der Datenbank auszuführen.

Prozess

Es gibt verschiedene Typen von Prozessen. Sie können z.B. vorgefertigte Prozesse verwenden, um Date aus einer Form in die Tabellen der Datenbank zu übertragen. Sie können eigene PL/SQL – Prozesse erstellen oder auch Web Services aufrufen, Mails versenden und vieles mehr.

Für dieses Beispiel sollen die Audit-Felder automatisch mit den entsprechenden Werten versehen werden.  

PL/SQL-Process erstellen

Eine oft genutzte Variante sind Prozesse, die Sie in PL/SQL erstellen können. Um so einen Prozess anzulegen gehen Sie wie folgt beschrieben vor.

Ausgehend von der Seite 3, welche in Abbildung 34 zu sehen ist, klicken Sie in der Developer Toolbar auf den Button “Edit Page”. 

Abbildung 35: APEX Create process
Abbildung 35: APEX Create process

Im Page Designer finden Sie, wie in Abbildung 35 zu sehen ist, die Möglichkeit einen neuen Prozess zu erstellen. Das geht z.B. über das Kontextmenü des Knotens process.

Geben Sie dem Prozess über seine Eigenschaften einen Namen (ID) und wählen sie als Typ PL/PQL-Code. Im Bereich source können Sie nun Ihren Quellcode unterbringen. 

In diesem Beispiel sollen das Item P3_CHANGED_BY und P3_CHANGED_ON mit einem Wert versehen werden.

Um auf ein Item zuzugreifen, stellen Sie dem Item-Namen einfach ein : voran. So können Sie z.B. über :P3_CHANGED_BY := :APP_USER;  den Namen des angemeldeten Users dem Item zuweisen. Abbildung 36 zeigt den kompletten Quellcode für dieses Beispiel.

Abbildung 36: PL/SQL Process
Abbildung 36: PL/SQL Process

Wie Sie dort sehen können, wird über sysdate noch der aktuelle Zeitpunkt einer Änderung ermittelt. Dieser wird allerdings als Char entsprechend formatiert dem Item zugewiesen. Achten Sie darauf, dass die Formatmaske hier mit der des Items übereinstimmt.

Abbildung 37: Formatmask
Abbildung 37: Formatmask

Anschließend bietet es sich noch an, die beiden Items in der Seite 3 auszublenden.

Abbildung 38: Hidden
Abbildung 38: Hidden

Das können Sie recht einfach bewerkstelligen. Markieren Sie dazu im Page Designer die beiden Items un d ändern Sie den Item-Typ auf Hidden (Ausgeblendet).

Wenn Sie nun über die Seite 3 einen neuen Eintrag erfassen oder einen vorhandenen Eintrag ändern, wird der Zeitpunkt der Änderung und der Name des Users vermerkt.

Conditions – Bedingte Prozesse

Wie Sie sicher bemerkt haben, wird der eben erstellte Prozess bei jeder Änderung in der Seite ausgeführt. Für das Speichern des Erstellzeitpunktes und des Erstellers eines neuen Datensatzes wurden der Seite und der Tabelle die beiden Items P3_CRETED_BY und P3_CREATED_ON zugefügt.

Um die Werte dieser beiden Items über einen weiteren Prozess zu setzten, können Sie wie im vorherigen Beispiel einen Prozess erstellen, der via. PL/SQL die Items setzte. Allerdings soll dieser Prozess nur einmalig ausgeführt werden, wenn ein neuer Datensatz angelegt wird. Für solche Fälle nutzen Sie in APEX sogenannte conditions.

Über eine condition können Sie beispielsweise prüfen, ob ein bestimmter Button gedrückt wurde. Sie können über diese Bedingungen feststellen, ob ein Item null ist oder einen definierten Wert besitzt. Für komplexere Prüfungen nutzen Sie einfach SQL oder PL/SQL.

Abbildung 39: Condition
Abbildung 39: Condition

Eine condition definieren Sie über die Eigenschaften eines Prozesses. Dort finden Sie unter conditions – in der deutschsprachigen Version “Serverseitige Bedingung” genannt – verschiedene Möglichkeiten. Für dieses Beispiel genügt es, den Prozess nur dann ausführen zu lassen, wenn der Button CREATE betätgt wird. 

Redirect Oracle Application Express (APEX)

Nutzen Sie den Wartungsmodus einer APEX Anwendung, um diese umzuleiten. Dies kann z.B. hilfreich sein, um eine neue Version der APEX Anwendung auszurollen.

Möchten Sie in einer Produktivumgebungen eine APEX-Applikation gegen eine neue Version tauschen, haben Sie verschiedene Möglichkeiten dies zu bewerkstelligen.

Erzeugen Sie eine neue Version Ihrer Anwendung vergibt APEX eine neue App-Id, die zum Aufruf des Programms in der URL angegeben werden muss. Damit die Nutzer die neue Version aufrufen können, müssen Sie eine neue URL verteilen. Natürlich gibt es dafür einige Wege.

Ich möchte Ihnen hier eine Variante vorstellen, wie Sie dies elegant mit dem Wartungsmodus einer APEX APP durch Umleitung auf die neue Version der Anwendung erledigen können.

Redirect mittels Wartungsmodus

Legen Sie im ersten Schritt die neue Version der Anwendung in Ihrer Produktivumgebungen an. Es ist egal, ob Sie eine neue Version aus Ihrem Entwicklungssystem per Export/Import transportieren oder eine Kopie der Vorgänger Version anlegen und diese weiter entwickeln.

Abbildung 01: Alte und neue Version einer APEX Anwendung

Der Ausgangspunkt für diesen Tipp ist eine produktive Anwendung und eine parallel installierte neue Version.

Im ersten Schritt ermitteln Sie die URL, mit der Sie das neue Programm aufrufen.

https://apex.oracle.com/pls/apex/f?p=<APP_ID>:LOGIN_DESKTOP::::::

Öffnen Sie nun die alte Anwendung im Application Builder und navigieren Sie zu den Anwendungseigenschaften. (Edit Application Properties)

Abbildung 02: Edit Application Properties

Dort finden Sie im Bereich “Availability” die Select-Liste Status. Dort können Sie eine APEX-Anwendung z.B. in den Wartungsmodus versetzen oder die Nutzung komplett unterbinden. 

Selektieren Sie die Option “Unavailiable (Redirect to URL)”. Im Feld “Message for unavailable application” tragen Sie die URL der neuen Anwendung ein.

Abbildung 03: Unavailable (Redirect to URL)

Jetzt wird beim Aufruf der alten Anwendung ein Redirect auf die neue Version durchgeführt.

Oracle Application Express (APEX) 19.1 Download bereitgestellt – Neue Funktionen

Oracle hat die APEX Version 19.1.0.00.15 zum Download bereitgestellt. Hier finden Sie einen ersten Eindruck der neuen Funktionen.

Formulare

APEX wird auch in diesem Release weiter auf REST-Services getrimmt. Mit den sogenannten REST-Enabled Forms ist es möglich, Schreib- und Lesevorgänge auf Basis von REST Enabled SQL in Web Sources in Seiten bzw. Regionen ohne Programmierung zu verwenden. Sie können also Seiten mit Formularen, Diagrammen, Kalendern und Berichten auf der Grundlage von REST Services erstellen.

Abbildung 1: APEX 19.1 – REST-Enabled Forms

REST Enabbled Database Objects

Auch die Integration des Oracle REST Data Services (ORDS) in APEX wurde optimiert. Es ist nun möglich, aus dem SQL Workshop heraus per Klick für eine Tabelle einen REST API zu generieren. Das Ganze funktioniert auch für Views und Procedures.

Abbildung 2: Erzeuge REST API

Die so erzeugte REST-API wird dann auch in den RESTful Services angezeigt.

Abbildung 3: RESTful Services

Data Loading

Auch das Importieren von Daten wurde einer Frischzellenkur unterworfen. APEX unterstützt nun das einfache Laden von CSV, json, nativen Excel Dateien (xlsx) mit mehreren Tabellen und XML. Über das neue Data-Loading können diese Quelldaten in neue Tabellen in die Datenbank importiert werden. Das Importieren in bereits vorhandene Tabellen soll mit Version 19.2 kommen.

Abbildung 4: Import einer JSON Datei

Die Importfunktionen stehen aber nicht nur über die Oberfläche, sondern auch über das PL/SQL Package APEX_DATA_PARSER zur Verfügung.

Interaktives Grid

Dem Interaktiven Grid wurden diverse Eigenschaften hinzugefügt.

Abbildung 5: Neue Eigenschaften des Interactive Grids

Jet Chart

APEX unterstützt in der Version 19.1 jetzt auch JET Status Meter Gauges.

Abbildung 6: JET Status Meter Gauges.

Dark Mode

Einem allgemeinen Trend folgend, wurde APEX auf ein Dark Mode hinzugefügt.

Diesen können Sie über Ihr Benutzerprofil aktivieren.

Abbildung 7: Dark Mode aktivieren
Abbildung 8: APEX Application Builder im Dark Mode:

Deprecated Features

Oracle hat einige Funktionen als deprecated eingestuft. Diese Funktionen werden in zukünftigen Releases von APEX entfernt. Eine genaue Auflistung finden Sie in der Release Notes.

Tipp: Sie können sich für Ihre APEX Anwendungen über den Oracle Application Express Advisor anzeigen lassen, welche der von Ihnen verwendeten Features veraltet sind.

Der Team Developer wird in einer neuen Version durch ein neues System zum Tracken von Rückmeldungen, Problemen und Meilensteinen ersetzt.

Ebenso werden Sie zukünftig auf die Komponenten von AnyChart, AnyMap und AnyGantt verzichten müssen. Hier stellt Ihnen Oracle aber als Alternative die reichhaltige Palette aus dem Oracle JET Framework zur Verfügung. Wie Sie Ihre alten Charts zu Oracle JET überführen können, ist im Apex Benutzerhandbuch beschrieben.

Des Weiteren wird das Template für Pop-up LOVs nicht weiter unterstützt. Hierfür wird es in Apex 19.2 laut Statement of Direction ein Enhanced Pop-up LOV geben.

Oracle APEX 18.2 Tutorial Teil 4 – Page Designer

Im 4 Teil des deutschsprachigen Oracle APEX Einsteiger Tutorial geht es um die Erstellung von Seiten mit dem Page Designer.

Der Page Designer ist das zentrale Werkzeug mit dem in APEX Seiten erzeugt und bearbeitet werden. Gerade bei diesem Tool wird der zentrale Ansatz der Low Code Entwicklung von APEX sichtbar. APEX nutzt in vielen Fällen die Metadaten aus der Datenbank, um daraus Elemente einer Seite zu erzeugen. Die Elemente eines APEX Seite werden über deren Eigenschaften definiert. Deshalb entwickeln Sie Anwendungen mit APEX deutlich schneller als mit herkömmlichen Programmieransätzen.

Öffnen des Page Designers

Es stehen Ihnen verschiedene Möglichkeiten zur Verfügung, den Page Designer zu starten.

Im Letzten Teil des Tutorials habe ich Ihnen den Zugang über die Developer Toolbar gezeigt.

Sie können aber auch einfach über den Application Builder eine Anwendung auswählen. Anschließend werden Ihnen alle Seiten der Anwendung aufgelistet.

Abbildung 22: Application Builder

Von dieser Seitenübersicht können Sie vorhandene Seiten einfach durch anklicken des jeweiligen Links auswählen und im Page Designer öffnen.

Abbildung 23: Page Designer

Neue Seiten mit dem Page Designer erstellen

Ausgehend von der Seitenübersicht (Abbildung 22) können Sie Ihrer Anwendung eine neue Seite über den Button “Create Page >” hinzufügen.

Befinden Sie sich bereits im Page Designer so finden Sie den Einstieg in den Seitenerstellungsassistenten in der Toolbar hinter dem +.

Abbildung 24: Create Page

Im ersten Dialog geben Sie an, welche Art von Seite sie erstellen möchten. Wählen Sie für dieses Beispiel die Seitenart “Form”.

Abbildung 25: Report with Form on Table

Auch bei den Forms gibt es wieder verschiedene Seitenarten. Eine häufig genutzte und wie ich finde vielseitig einsetzbare Variante Daten einer Tabelle zu bearbeiten, besteht aus einer tabellarischen Übersicht des Tabelleninhaltes. Von so einer Übersichtsseite aus können Sie einen Datensatz in einer zweiten Seite für die Bearbeitung öffnen.

Um soche Seiten von APEX erzeugen zu lassen nutzen Sie an dieser Stelle des Wizzards den Eintrag “Report with Form on Table”.

Klicken Sie auf Next >.

Abbildung 26: Definition des Interactive Reports

Nun geht es an die Definition der Report Page. In diesem Beispiel nutzen Sie den sogenannten Interactive Reports. Hinter einem Interactive Report verbirgt sich eine tabellarische Darstellung des Inhaltes einer (oder mehrerer) Datenbanktabelle.

Wählen Sie noch die Titel der Report Page und der Form Page fest. Mit Next > geht es weiter.

Abbildung 27: Navigation Menu

Beim erstellen der Anwendung im Teil 3 des Tutorials, haben Sie bereits sehne können , dass Ihre Anwendung ein Seiten-Menü besitzt. Um diesem Menü einen Link hinzuzufügen, über den die Übersichtsseite die Sie gerade erzeugen, aufzurufen geht es bei dieser Seite des Page-Wizzards.

Lassen Sie APEX einen neuen Menüeintrag über die Option “Create a new navigation menu entry” für Sie erzeugen. Jetzt benennen Sie diesen Menüpunkt noch und klicken Sie dann auf Next >.

Abbildung 28: Select a table

Als Basis für den Inhalt des Interactive Reports und der Form Page geht es im Schritt 5. An dieser Stelle selektieren Sie die Datenbanktabelle CO_COOKING_RECIPE. Jetzt werden Ihnen die Spalten der Tabelle im linken Auswahlfeld des Shuttle-Items aufgelistet. Meine Empfehlung ist es hier nach Möglichkeit alle Spalten zu übernehmen. Es ist später weniger aufwändig, überflüssige Spalten auszublenden bzw. zu entfernen als Neue einzufügen.

Mit Next> geht es zum nächsten Schritt.

Abbildung 29: Primary Key

APEX bietet Ihnen verschiedene Möglichkeiten die einzelnen Zeilen in der Datenbanktabelle anzusprechen. Ich habe gute Erfahrungen damit gemacht einen künstlichen Schlüssel, der über eine Datenbank-Sequence erzeugt wird, zu verwenden.Um so einen surrogate key zu nutzen, wählen Sie die Option “Select Primary Key Coulmn(s)” und dann im Feld “Primary Key Column 1” den Eintrag ID.

Den Inhalt der ID Spalte wird über den bereits angelegten Trigger in der Datenbank erzeugt.

Jetzt haben Sie es geschafft. Klicken Sie auf Create so erzeugt APEX zwei Seiten für Ihre Anwendung, die es in sich haben.

Abbildung 30: Report Form und Edit Form

Report- und Edit Form

Starten Sie jetzt einfach mal Ihre Anwendung über Run Application.

Über den Menüpunkt Cooking recipe können Sie die Report Form öffnen. Da die Datenbanktabelle noch keine Einträge enthält sieht die Seite noch etwas spartanisch aus.

Abbildung 31: Interactive Report Form

Legen Sie über den Create Button einen neuen Eintrag an. Dafür öffnet sich die zweite Seite – die Edit Form.

Abbildung 32: Edit Form

Der Page Wizzard hat diese Seite so erzeugt, dass Sie neue Datensätze erstellen, vorhandene bearbeiten oder löschen können. Die Seite ist von Haus aus responsiv und lässt sich auf einem Rechner genauso gut nutzen wie auf einem Smartphone oder Tablet.

Die Seite ist auch für den Mehrbenutzerbetrieb geeignet. Versuchen zwei User annähernd gleichzeitig den selben Datensatz zu editieren, wird dem zu letzt speichernden Anwender eine entsprechende Fehlermeldung ausgeben.

Tragen Sie doch zum Test einmal ein erstes “Rezept” in die Anwendung ein. APEX öffnet für die Datumsfelder einen Kalender-Picker. Die Memo (Clobs) Felder wurden als mehrzeilige Items erzeugt. Hier spielt APEX einfach seine Stärken aus. Durch die Nutzung der Metadaten aus der der Datenbank, werden bereits bei der Erzeugung von Elementen (Items, Regions,…) sinnvolle Typen gewählt.

Auch not null constraints finden Sie in Form von Eingangevalidierungen in der Seite wieder.

Speichern Sie die Daten, so gelangen Sie wieder in die Report Form.

Abbildung 33: Report Form

Diese Tabelle wirkt auf den ersten Blick etwas unscheinbar. Aber glauben Sie mir, ein Interactive Report bietet dem Anwender eine unglaubliche Zahl an Möglichkeiten.

Sie können Excel gleich auf die Spalten klicken und erhalten einen Autofilter. Die Suchleiste bietet Ihnen eine spaltenübergreifende Suche über die ganze Tabelle. Sie können Sortieren, nach Spalten gruppieren. Die guppierten Daten aggregieren.

Der Interactive Report bietet Ihnen neben der Pivotieriung der Daten auch die Möglichkeit sich diese als Chart anzeigen zu lassen. Über die Downloadfunktion können Sie die Daten “mitnehmen”. Oder lassen Sie sich die Daten per Mail zuschicken. Das geht übrigens auch mittels Subscription zeitgesteuert.

Oft genutze (Filter)einstellungen können Sie Speichern.

Um alle Möglichkeiten genau zu beschreiben, bedarf es einiger Seiten mehr. Die meisten Funktionen sind aber selbsterklärend.

Beitragsreihe

Oracle APEX 18.2 Tutorial Teil 3 – Application Builder

Anwendungen erstellen Sie in APEX mit dem Application Builder. Hierzu mehr im 3. Teil des deutschsprachigem APEX Einsteiger Tutorials.

Application Builder

Der Application Builder ist das Tool in APEX, mit dem Sie Anwendungen erstellen, bearbeiten und verwalten.

Abbildung 14: Application Builder
Abbildung 14: Application Builder

Öffnen Sie den App Builder über die gleich benannte Schaltfläche oder über den zugehörigen Menüpunkt, so erhalten Sie eine tabellarische Übersicht aller Anwendungen Ihres Workspaces. Diese werden in einem Interactive Report dargestellt. Dieses bietet Ihnen mannigfaltige Möglichkeiten, die Anwendungen zu filtern, gruppieren, sortieren, usw.

Abbildung 15: Anwendungsübersicht im Application Builder
Abbildung 15: Anwendungsübersicht im Application Builder

Anwendung erstellen

Neue Anwendundungen legen Sie über einen Wizzard an, den Sie über den Create Button – siehe Abbildung 15 – starten.

Im ersten Schritt werden Sie gefragt, welche Art von Anwendung Sie erstellen wollen. Wählen Sie New Application.

Abbildung 16: Create an Application
Abbildung 16: Create an Application

In der nächsten Seite (Abbildung 16) können Sie neben dem Namen der Anwendung auch diverse Eigenschaften festlegen.

Über den Button in der Select-List Appearance können Sie in einem Details-Dialog das Aussehen Ihrer Anwendung festlegen.

Abbildung 17: Appearance
Abbildung 17: Appearance

Wählen Sie neben einem Themen, ein Icon für diese Anwendung und im Navigation-Bereich Side Menü. Speichern Sie die Eingaben.

Sie gelangen wieder zurück zur Hauptseite des Application Wizzards. Wie Sie in Abbildung 16 sehen, wurde bereits eine Home Seite der Anwendung hinzugefügt. Auf das Anlegen weiterer Seiten verzichten ich an dieser Stelle. Auch zusätzliche Features sind für dieses Tutorial nicht von Belang.

Klicken Sie auf Create Application.

Der Wizzard legt nun die Web-Anwendung an und öffnet diese im Application Builder.

Abbildung 18: Cooking with APEX
Abbildung 18: Cooking with APEX

Anwendung ausführen

Starten Sie die Applikation Cooking with APEX durch anklicken des Buttons Run Application.

Es öffnet sich nun in einem neuen Registers Ihres Browsers die App.

Abbildung 19: Sign In
Abbildung 19: Sign In

Anmelden können Sie sich mit Ihrem APEX-Account. Auf Ihrem Rechner wird dabei ein Cookie mit der SessionId erzeugt.

Die Anwendung startet mit der Home -Seite.

Abbildung 20: Cooking with APEX
Abbildung 20: Cooking with APEX

Im Kopfbereich finden Sie links neben dem Anwendungstitels einen Burger-Button über den Sie das Seiten Menü verkleinern können.

Diese Minimaldarstellung des Menüs erhalten Sie auch wenn Sie die Anwendung z.B. auf einem Smartphone öffnen. APEX-Anwendungen, die auf dem aktuellen Universal Theme beruhen, sind von Haus aus responsive. Sie passen Ihr Aussehen also der Device -Größe an.

Da Sie die Anwendung aus der APEX-Entwicklungsumgebung heraus aufgerufen haben, wird Ihnen im Fußbereich der Anwendung die sogenannte Developer Toolbar angezeigt. Diese bietet verschiedene Werkzeuge, die Sie bei der Anwendungsentwicklung unterstützen werden.

Klicken Sie dort bitte einmal auf den Button Edit Page 1. Es öffnet Sie in dem ursprünglichen Register Ihres Browsers indem Sie die APEX-Anwendung geöffnet hatten, der Page Designer.

Abbildung 21: APEX Page Designer
Abildung 21: APEX Page Designer

Dieser zeigt nun alle Bestandteile der eben geöffneten Seite 1 (Home). Hier definieren Sie den Inhalt der Seiten und legen das Verhalten Ihrer Anwendung fest.

Die Seite selbst, können Sie direkt über das Run-Icon der Toolbar – siehe Abbildung 21 – laden. Auf diese Weise können Sie sehr intuitiv zwischen Ihrer Anwendung und der Entwicklungsumgebung hin und her wechseln.

Beitragsreihe

Im Teil 4 wird es um das Erstellen  von Seiten mit dem Page Designer gehen.

 

 

Oracle APEX 18.2 Tutorial Teil 2 – SQL Commands

Im zweiten Teil des Einführungstutorials geht es um die Ausführung von DDL Anweisungen über das Modul SQL Commander. 

In diesem Teil des Tutorials soll der Rest des Datenmodells angelegt werden. Hierzu kommt zu Anschauungszwecken das Werkzeug SQL Commands zum Einsatz.

SQL Commands

Im ersten Teil der Beitragsreihe ging es darum eine Tabelle mit dem Objects Browser zu erzeugen. APEX bietet unter dem SQL-Workshop neben diesem Tool mit dem SQL Commands ein weiteres Werkzeug mit dem Sie direkt mit der Datenbank interagieren können.

Abbildung 9: SQL Commands
Abbildung 9: SQL Workshop – SQL Commands

Über das Tool SQL Commands ist es möglich einfach Freihand SQL Befehle und SQL-Scripte auszuführen.

Abbildung 10: SQL Commands
Abbildung 10: SQL Commands

Im oberen Textfeld können Sie SQL bzw. PL/SQL Befehle eingeben. Über den Button Run führen Sie diese aus.

Mit Find Tables können Sie sich die Tabellen Ihres Workspaces anzeigen lassen. Klicken Sie in der Übersicht von “Find Tables” auf den Tabellennamen wird Ihnen die Struktur der Tabelle präsentiert.

Abbildung 11: Find Tables
Abbildung 11: Find Tables

Die Skripte, die Sie mit SQL Commands erstellt haben, lassen sich in APEX über die Schaltfläche Save speichern. Laden können Sie diese dann über den Tab Saved SQL.

Tabellen und Trigger anlegen

Das folgende SQL-Skript (Listing 1) erzeugt für die noch fehlenden Tabellen ingredients, processing_steps und product_classification. Zu jeder Tabelle wird je ein Trigger angelegt, über den ein künstlicher Schlüssel als Primärschlüssel erzeugt wird.

Das Skript habe ich mit einem weiteren APEX-Tool namens Quick SQL erzeugt. Anschließend habe ich noch einige kleine manuellen Anpassungen vorgenommen. Wenn Sie sich näher mit der schnellen Erzeugung von Datenmodellen beschäftigen möchten, werden Sie doch einfach mal einen (lohnenswerten) Blick auf den Beitrag Oracle Apex – Quick SQL.

-- create tables
create table co_processing_step (
  id number not null constraint co_processing_step_id_pk primary key,
  name varchar2(255),
  description varchar2(4000),
  media_name varchar2(255),
  media_object blob,
  media_filename varchar2(255),
  media_mime_type varchar2(48),
  media_size number,
  media_content_type varchar2(4000),
  order_number number,
  created date not null,
  created_by varchar2(255) not null,
  updated date not null,
  updated_by varchar2(255) not null
)
;

create table co_ingredients (
  id number not null constraint co_ingredients_id_pk primary key,
  processing_step_id number
  constraint co_ingredient_processing_st_fk
  references co_processing_step on delete cascade,
  name varchar2(255),
  quantity number,
  quantity_unit varchar2(10),
  calories number,
  product_classification_id number,
  created date not null,
  created_by varchar2(255) not null,
  updated date not null,
  updated_by varchar2(255) not null
)
;

create table co_product_classification (
  id number not null constraint co_product_classif_id_pk primary key,
  name varchar2(255),
  description varchar2(4000),
  created date not null,
  created_by varchar2(255) not null,
  updated date not null,
  updated_by varchar2(255) not null
)
;

CREATE SEQUENCE co_processing_step_seq ORDER;

CREATE SEQUENCE co_ingredients_seq ORDER;

CREATE SEQUENCE product_classification_seq ORDER;

-- triggers
create or replace trigger co_processing_step_biu
   before insert or update
   on co_processing_step
   for each row
 begin
   if :new.id is null then
      select co_processing_step_seq.nextval into :new.id from dual;
   end if;
   if inserting then
     :new.created := sysdate;
     :new.created_by := nvl(sys_context('APEX$SESSION','APP_USER'),user);
   end if;
   :new.updated := sysdate;
   :new.updated_by := nvl(sys_context('APEX$SESSION','APP_USER'),user);
end co_processing_step_biu;
/

create or replace trigger co_ingredients_biu
   before insert or update
   on co_ingredients
   for each row
  begin
      if :new.id is null then
         select co_ingredients_seq.nextval into :new.id from dual;
      end if;
      if inserting then
        :new.created := sysdate;
        :new.created_by := nvl(sys_context('APEX$SESSION','APP_USER'),user);
      end if;
      :new.updated := sysdate;
      :new.updated_by := nvl(sys_context('APEX$SESSION','APP_USER'),user);
end co_ingredients_biu;
/

create or replace trigger co_product_classification_biu
   before insert or update
   on co_product_classification
   for each row
  begin
    if :new.id is null then
        select product_classification_seq.nextval into :new.id from dual;
    end if;
    if inserting then
      :new.created := sysdate;
      :new.created_by := nvl(sys_context('APEX$SESSION','APP_USER'),user);
    end if;
    :new.updated := sysdate;
    :new.updated_by := nvl(sys_context('APEX$SESSION','APP_USER'),user);
end co_product_classification_biu;
/

-- indexes
create index co_ingredients_i1 on co_ingredients (processing_step_id);
create index co_product_classification_i1 on co_product_classification (ingredient_id);

Listing 1: Create ingredients , processing_steps, …

Kopieren Sie den Inhalt des Skriptes in den Eingabebereich des SQL Commands und klicken Sie dann auf Run.

Abbildung 12: Skript ausführen
Abbildung 12: Skript ausführen

Sie bekommen anschließend eine Zusammenfassung und mögliche Fehlermeldungen angezeigt.

Select-Statements ausführen

Über das Tool SQL Commands lassen sich aber auch Select-Anweisungen entwickeln und ausführen.

Um zu prüfen, welche Tabellen in Ihrem Schema vorhanden sind, können Sie beispielsweise dieses Select-Staement bemühen.


select *
  from user_tables
 where table_name like 'CO%'

Führen Sie es einfach in SQL Commands aus. Das Ergebnis wird Ihnen als Tabelle angezeigt.

Abbildung 13: Select Statement in SQL Commands
Abbildung 13: Select Statement in SQL Commands

Beitragsreihe

Oracle APEX 18.2 Tutorial Teil 1 – SQL Workshop

Deutschsprachiges Einsteiger Tutorial für Oracle APEX 18.2. Tabellen mit dem SQL Workshop erstellen.

In dieser Beitragsreihe möchte ich Ihnen anhand einer einfachen Anwendung zur Verwaltung von Kochrezepten eine Einführung in die Anwendungsentwicklung mit der Low-Code Entwicklungsumgebung Oracle Application Express bieten. Um dieses Tutorial nachstellen zu können, benötigen Sie eine lauffähige Apex Installation. Wie Sie APEX einrichten habe ich in dem Beitrag Installation Oracle Apex dieses Blogs beschrieben. Alternativ können Sie sich unter https://apex.orale.com einen Testzugang anlegen und die von Oracle in der Cloud betriebenen APEX-Plattform zu Bildungszwecken nutzen.

Aufgabenstellung

Als Beispiel soll eine einfache Anwendung erstellt werden, mit der Kochrezepte verwaltet werden können. Ein Rezept kann dabei mehrere Zutaten besitzen. Die Verarbeitung der Zutaten soll in einfachen Arbeitsschritten dargestellt werden.

Datenmodell

  • Kochrezepte (cooking_recipe)
    • name
    • description
    • number_of_persons
  • Zutaten (ingredients)
    • name
    • quantity
    • unit
    • product_classification ( bio, vegetarian, vegan, …)
    • calories
  • processing_step
    • name
    • description
    • Pictures/Videos
    • product_id
    • order_number

APEX-Anwendung

Haben Sie sich für eine eigene APEX Installation entschieden, müssen Sie als Erstes als Instanzadministrator einen sogenannten WORKSPACE und eine  Workspace-Developer anlegen. (siehe dazu auch Installation Oracle Apex )

Bei der Nutzung des Server von Oracle apex.oracle.com erfolgt dieser Schritt im Rahmen der Erstanmeldung.

Je nach Variante gibt es verschiedene URLs über die Sie die APEX-Entwicklungsumgebung starten. Sie sollten bei allen Varianten zu der in Abbildung 1 dargestellten Login-Seite gelangen.

Abbildung 1: Anmeldung als APEX-Developer
Abbildung 1: Anmeldung als APEX-Developer

Hier melden Sie sich an Ihrem WORKSPACE an.

Anschließend gelangen Sie zur Startseite der APEX-Entwicklungsumgebung.

Abbildung 2: APEX-Entwicklungsumgebung
Abbildung 2: APEX-Entwicklungsumgebung

Dort können Sie die einzelnen Module von APEX starten. Für den Anfang sind für Sie der APPLICATION BUILDER und der SQL-WORKSHOP von Bedeutung.

Über den SQL-WORKSHOP können Sie mit Hilfe verschiedener Werkzeuge in Ihrem Datenbankschema Objekte wie z.B. Tabellen, Views,… und Daten bearbeiten.

Mit dem APPLICATION BUILDER erstellen Sie die APEX-Anwendungen.

Bei der Entwicklung einer APEX Anwendung werden Sie durch unterschiedliche Wizzards unterstützt. Alle diese Assistenten nutzen massiv die Metadaten Ihrer Oracle Datenbank. Die Metadaten der Datenbankobjekte fungieren quasi als Modell ( im Sinne eines MDA-Ansatzes ) für die Erstellung der Anwendung. Aus diesem Grund, ist es ratsam immer zuerst die zugrunde liegenden Datenbankobjekte anzulegen.

SQL-Workshop

Der SQL-Worshop bietet diverse Werkzeuge zum Bearbeiten von Datenbankobjekten.

Abbildung 3: SQL-WORSHOP
Abbildung 3: SQL-WORKSHOP

Der OBJECT BROWSER zeigt Ihnen alle Datenbankobjekte der Schematas, die dem Apex Workspace zugeordnet sind. Diese können mit diesem Tool bearbeitet werden.

Mit dem Werkzeug SQL COMMANDS können Sie direkt SQL-Befehle ausführen.

Hinter dem Bereich SQL SCRIPTS verbirgt sich ein Verwaltungswerkzeug zum Speichern und Ausführen ganzer SQL Skripte.

Der UTILITIES-Bereich fasst nützliche Datenbankwerkzeuge zusammen.

Das sehr mächtige Modul RESTFUL SERVICES ermöglicht es Ihnen Restfull Web Services auf Basis von SQL und Pl/SQL Anweisungen zu definieren.

Tabelle mit dem OBJECT BROWSER erstellen

Wie bereits erwähnt, sollten Sie mit dem Datenmodell beginnen. Anhand der Tabelle cooking_recipe möchte ich Ihnen das Erstellen einer Tabelle mit dem OBJECT BROWSER zeigen.

Starten Sie als erstes den OBJECT BROWSER.

Abbildung 4: Object Browser
Abbildung 4: Object Browser

Auf der linken Seite können Sie mittels verschiedener Filter unterschiedliche Datenbankobjekte anzeigen lassen. Diese lassen sich selektieren und dann über entsprechende Eingabemöglichkeiten bearbeiten.

Um eine neue Tabelle anzulegen, klicken Sie im rechten Bereich auf + und dann auf Tabelle.

Abbildung 5: Tabelle definieren
Abbildung 5: Tabelle definieren

Legen Sie hier die Spalten der Tabelle fest.

Mit Next > geht es weiter.

Abbildung 6: Sequence und Trigger erzeugen
Abbildung 6: Sequence und Trigger erzeugen

Im nächsten Schritt des Wizzards können Sie definieren, wie der Primärschlüssel der Tabelle erzeugt werden soll. Wie Abbildung 6 zeigt, können Sie durch APEX eine Sequence anlegen lassen.

Klicken Sie auf Next > .

Im nächsten Schritt können Sie Foreign Key Constraints anlegen. In diesem Beispiel überspringen Sie den Punkt mit Next > .

Jetzt folgt eine Seite, über die Sie weitere Constraints für Ihre Tabelle ergänzen können. Auch darauf können Sie hier verzichten. Weiter mit Next > .

Abbildung 7: Create Table
Abbildung 7: Create Table

Abschließend bietet der Assistent Ihnen die Funktion sich das SQL Skript anzusehen.


CREATE table "CO_COOKING_RECIPE" (
   "ID" NUMBER,
   "NAME" VARCHAR2(50),
   "DESCRIPTION" VARCHAR2(2000),
   "NUMBER_OF_PERSONS" NUMBER,
   "CREATED_BY" VARCHAR2(50),
   "CREATED" DATE,
   "CHANGED_BY" VARCHAR2(50),
   "CHANGED" DATE,
  constraint "CO_COOKING_RECIPE_PK" primary key ("ID")
)
/

CREATE sequence "CO_COOKING_RECIPE_SEQ"
/

CREATE trigger "BI_CO_COOKING_RECIPE"
  before insert on "CO_COOKING_RECIPE"
  for each row
 begin
   if :NEW."ID" is null then
     select "CO_COOKING_RECIPE_SEQ".nextval into :NEW."ID" from sys.dual;
   end if;
end;
/

Lassen Sie die Tabelle über Create Table anlegen.

Abbildung 8: Tabelle im Objekt Browser
Abbildung 8: Tabelle im Object Browser

Sie landen nun wieder im Object Browser. Dort können Sie weitere Strukturanpassungen an der Tabelle vornehmen. Für dieses Beispiel ist das aber nicht notwendig.

Die anderen Tabellen werden in den folgenden Beiträgen angelegt, um andere Werkzeuge und Aspekte der Anwendungsentwicklung mit APEX zu verdeutlichen.

Beitragsreihe

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

DSGVO (GDPR) und Oracle Application Express (APEX)

Mal Hand aufs Herz. Haben Sie sich bei der Nutzung von APEX schon einmal mit dem Datenschutz und seit dem 25. Mai 2018 im Speziellen mit der DSGVO ( GDPR ) auseinander gesetzt?

Vielleicht fragen Sie sich wo Sie mit der DSGVO als APEX Entwickler in Berührung kommen?  Durch die Verwendung von APEX-Anwendungen fallen durch die Auditierung personenbezogene Daten an. Dazu kommen noch die personenbezogenen Daten Ihres Programms. Betreiben Sie APEX-Anwendungen auf die Ihre Kunden z.B. über das Internet zugreifen können, schlägt die DSGVO mit voller Härte zu. Aber auch für interne Anwendungen können Sie den Datenschutz nicht außer Acht lassen. Für solche Anwendungen benötigen Sie eine DSGVO (GDPR) konforme Datenschutzerklärung, die von jeder Seite der Anwendung aus zugänglich sein sollte. Mit dem Provider bzw. Cloud Anbieter, der die APEX- bzw. Datenbankinstanz für Sie betreibt, sollten Sie einen entsprechenden Auftragsdatenverarbeitungsvertrag abschließen. Noch komplexer wird das Ganze, wenn das Unternehmen, welches für Sie die Server betreibt, seinen Sitz außerhalb der EU hat. Denken Sie aber auch an Ihre Beispielanwendungen, die Sie über apex.oracle.com öffentlich betreiben. Oft haben diese Beispielapplikationen einen komerziellen Charakter. Auch hier fallen personenbezogene Daten wie z.B. die dynamische IP-Adresse des Clients an.

Die Betrachtungen in diesem Beitrag sind sicher nicht vollständig , stellen auch keine Rechtsberatung dar und sollen als Anregung zur näheren Betrachtung verstanden werden.

Grundsätze

Nach Art 4 DSGVO sind

„personenbezogene Daten“ alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden „betroffene Person“) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung oder zu einem oder mehreren besonderen Merkmalen identifiziert werden kann, […]

Dazu gehören offensichtlich der Name, Anschrift, Login-Daten, EMail-Adresse, Personaldaten aber auch beispielsweise die IP-Adresse und noch vieles mehr.

Verarbeitung und Speicherung personenbezogener Daten

Um der DSGVO gerecht werden zu können, sollten Sie sich im Ersten Schritt darüber bewusst werden, welche personenbezogenen Daten in APEX vorhanden sind. Nach Art. 30 DSGVO sind Sie sowieso verpflichtet ein Verzeichnis von Verarbeitungstätigkeiten aller personenbezogener Daten zu führen. Dieses muss unter anderem den Zweck, Löschfristen und den Rechtsgrund der Verarbeitung beinhalten.

Darüber hinaus sollten Sie sich dem Grundsatz der Datenvermeidung (Art. 5 c DSGVO) nach Gedanken darüber machen, welche personenbezogene Daten Sie wirklich benötigen und APEX datenschutzfreundlich konfigurieren.

Des Weiteren gilt nach Art. 5 a) und b) DSGVO

Personenbezogene Daten müssen

1 auf rechtmäßige Weise, nach Treu und Glauben und in einer für die betroffene Person nachvollziehbaren Weise verarbeitet werden („Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz“);

2 für festgelegte, eindeutige und legitime Zwecke erhoben werden und dürfen nicht in einer mit diesen Zwecken nicht zu vereinbarenden Weise weiterverarbeitet werden; eine Weiterverarbeitung für im öffentlichen Interesse liegende Archivzwecke, für wissenschaftliche oder historische Forschungszwecke oder für statistische Zwecke gilt gemäß Artikel 89 Absatz 1 nicht als unvereinbar mit den ursprünglichen Zwecken („Zweckbindung“);

Das bedeutet für Sie, dass Sie die Rechtmäßigkeit der Verarbeitung sicherstellen müssen. Nach Erwägungsgrund 40 bedeutet das, dass Sie den Anwender vor der Verarbeitung um Erlaubnis bitten müssen oder es einen anderen Rechtsgrund gibt auf dessen Basis die Verarbeitung legitim ist. So können Sie beispielweise Ihrer Anwendung eine entsprechende Abfrage voranstellen und den User um seine Erlaubnis bitten. Dabei sollten Sie aber auch nachträglich in der Lage sein die Abgabe dieser Willenserklärung nachweisen zu können. Dazu protokollieren Sie diese einfach in einer Datenbanktabelle.

Die Verarbeitung muss transparent geschehen. Also sollten Sie auch eine entsprechende Datenschutzerklärung in zugänglicher Form Ihrer Anwendung hinzufügen.

Im Folgenden habe ich Ihnen einige Stellen aufgelistet an denen personenbezogene Daten in APEX anfallen. Die Beurteilung der Handhabung, Notwendigkeit und Zweckbindung  der Speicherung dieser Daten überlasse ich Ihnen.

User Access Log

Hier werden die gültigen und ungültigen Abmeldungen an Ihren Anwendungen protokolliert. Neben den Zeitstempeln und Benutzernamen finden Sie auch hier die Client IP-Adresse.


select * from apex_180100.wwv_flow_user_access_log

APEX-Activity Log

Haben Sie das Logging Ihrer Abwendungen aktiviert, werden alle Seitenzugriffe inkl. User ID und Client-IP-Adresse im Activity Log protokolliert. Das Logging können Sie als APEX-Developer in den Anwendungseigenschaften Ein- bzw. Ausschalten.

Abbildung 1: Logging ausschalten

Das setzt allerdings voraus, dass der Instanzadministrator das “Application Activity Logging” im internal Workspace auf “User Application Setting” gesetzt hat . Ansonsten obliegt es Ihm, das Logging zu aktivieren bzw. zu deaktivieren.

Das Activity Log wird wechselseitig in zwei Tabellen gespeichert


select * from apex_180100.wwv_flow_activity_log1$

select * from apex_180100.wwv_flow_activity_log2$

Developer Aktivitäten

Neben den Anwendern Ihrer Anwendungen hinterlassen auch Sie als Entwickler Ihre Daten in APEX. An verschiedenen Stellen in der Benutzeroberfläche sehen Sie wer wann, welches Objekt geändert hat. Diese Daten werden hier gespeichert.


select * from apex_180100.wwv_flow_builder_audit_trail

Logs löschen

Sie sollten diese Audit-Daten auch in Ihrem Löschkonzept berücksichtigen. Manuell können Sie die Daten als Instanzadministrator  löschen.

Abbildung 2: Audit Logs verwalten

Änderungshistorie

Eine oft in Anwendungen eingesetzte Funktion ist das Protokollieren von Änderungen. Dabei werden neben den eigentlichen Daten in der Regel der Account des Bearbeiters und der Zeitstempel der Änderungen protokolliert. Das sind personenbezogene Daten.

Einen anderen Aspekt betrifft die Daten selbst. Enthalten diese auch personenbezogene Inhalte, so müssen Sie die Änderungshistorie in Ihre Überlegungen zu diesem Thema ebenfalls mit einbeziehen. Neben der Zweckbindung ist besonders ein entsprechendes Löschkonzept von Nöten, welches auch diese Datenhistorie beachtet.

Werkzeuge wie das APEX Tool QuickSql bieten die Möglichkeit bei der Erstellung eines Datenmodells die Auditierung der Änderungen direkt zu berücksichtigen. Quick SQL erzeugt dazu eine Log-Tabelle, in der per Trigger der Quelldaten protokolliert werden. Allerdings fällt der Datenschutz dabei hinten rüber und muss manuell nachgerüstet werden.

Eine andere Möglichkeit Änderungen in APEX-Anwendungen zu protokollieren bietet das PlugIn Audit. Auch hier müssen Sie die Datenschutzaspekte manuell nachrüsten.

Abhängige Datenbankobjekte

Neben den Audit-Daten bleibt Ihnen zu prüfen, welche personenbezogen Daten von Ihrer Anwendung verarbeitet werden und wie diese zu behandeln sind. In APEX können Sie über das Utility Database Object Dependencies ermitteln, welche Tabellen Ihrer Anwendung zugrunde liegen.

Abbildung 3: Abhängige Datenbankobjekte

Neben der manuellen Prüfung der Tabellen bietet Oracle das Oracle Database Security Assessment Tool. Mit diesem Werkzeug können Sie neben der Prüfung der Sicherheit einer Datenbank auch gezielt nach personenbezogenen Daten suchen. Einen ersten Einstieg finden Sie in diesem Blog-Beitrag.

Cookies

Ein weiterer Punkt, der für APEX -Anwendungen zu beachten ist, finden Sie im Erwägungsgrund 30 der DSGVO. Hier wird darauf hingewiesen, dass auch Cookies personenbezogene Daten beinhalten können.

Da APEX für das clientseitige Session-Management Cookies verwendet, müssen Sie auch hier für Transparenz sorgen.

Betroffenenrechte

Die DSGVO räumt den Betroffenen umfangreiche Rechte ein. An dieser Stelle möchte ich nur ein paar Überlegungen dazu anstellen.

Recht auf Datenlöschung (Art. 17 DSGVO)

Betroffene haben das Recht Ihre personenbezogenen Daten Löschen zu lassen, wenn keine anderen rechtlichen Pflichten (z.B. Aufbewahrungspflicht) dagegen stehen. Alleine dieses Thema ist mindestens eine Beitragsreihe wert. An dieser Stelle möchte ich nicht auf die Erstellung eines Löschkonzeptes eingehen.

Als APEX-Entwickler geht es vielmehr darum, so ein Löschkonzept umzusetzen. Technisch lässt sich die Löschung über entsprechende delete-Statements lösen. Diese können natürlich auch zeitgesteuert ausgeführt werden oder Sie stellen den Anwendern eine entsprechende Funktion in der Anwendung zur Verfügung. Dies hätte den Vorteil, dass Sie dort vorab noch eine Prüfung durchführen lassen können.

Recht auf Berichtigung (Art. 16 DSGVO)

Dieser Punkt kann meiner Meinung nach in der Regel manuell über die gewohnten Seiten einer APEX Anwendung erfolgen.

Auskunftsrecht (Art. 15 DSGVO)

Diese Aufgabe ist schon aufwändiger. Gerade wenn die personenbezogenen Daten über verschiedene Bereiche der Datenbank erstrecken und auch die Audit-Logs berücksichtigt werden müssen. Für solche Fälle bietet sich meiner Meinung nach ein Selfservice-Ansatz an. Tragen Sie die Daten in Form einer oder mehrer Abfragen zusammen und bieten Sie den Anwendern diese über eine personalisierte Seite ( … where userid = :APP_USER) an.

Anders verhält es sich, wenn Sie in der Anwendung Daten Dritter verwalten, die selber keinen Zugang zu dem Programm haben. Hier kommen Sie nicht darum herum, eine Exportfunktion – z.B. über die Boardmittel eines Interaktiven Reports – vorzusehen. Mit so einem Ansatz erledigen Sie auch gleich das Recht auf Datenübertragbarkeit (Art. 20 DSGVO).

Sicherheit nach Stand der Technik

Die DSGVO weist darauf hin, dass Systeme nach aktuellem Stand der Technik sicher auszulegen sind. Auch dieses Thema ist uumfänglich zu erörtern, würde aber eher ein Buch als eine  Blog-Beitrag füllen. Aber ich möchte noch kurz auf einige wenige Punkte eingehen.

Sie sollten bei Thema Sicherheit einen ganzheitlichen Ansatz verfolgen. Sorgen Sie dafür, dass der komplette APEX-Stack sicher ausgelegt wird. Das fängt bei der Hardware inkl. Betriebssystem an, geht über die Datenbank und dem Web-Server hin zu APEX. Einige wenige Anregungen zum Thema Sicherheit und der Oracle-Datenbank finden Sie hier in dem Beitrag Oracle Datenbank härten..

APEX selbst bringt bereits vieles mit, um sichere Anwendungen zu erstellen. Die Verzögerungen bei fehlerhaften Anmeldungen gegen BruteForce-Attacken, Hashing der URL gegen URL-Tampering, das Escapen von Inhalten gegen Cross-Site-Scripting, Verwendung von Parametern gegen SQL-Injection und vieles mehr.

Allerdings sollten Sie auch die Kommunikation zwischen Client und Server via SSL Verschlüsseln. Dies wird gerade für offen zugängliche Web-Anwendungen explizit von der DSGVO gefordert.

Konfigurationsmanagement für Oracle APEX -Teil 2 Delta, Merge und Forks

Im zweite Teil der Reihe geht es um das Zusammenführen (merge) von parallelen Entwicklungssträngen (fork) von Oracle APEX-Anwendungen.

Das Zusammenführen zweier paralleler Entwicklungsstränge bringt einiges an Aufwand mit sich. Ich möchte Ihnen in diesem Beitrag ein mögliches Vorgehe beschreiben.

Zu Anfang geht es darum sich das Delta der beiden Releases bewusst zu machen. In welchen Punkten weichen die Datenbank Schemas voneinander ab? Welche Datenbankobjekte müssen in dem Zielschema neu erzeugt werden? Welche werden nicht mehr benötigt oder müssen angepasst werden?

Im zweiten Schritt stellen Sie sich ähnliche Fragen für die eigentliche Anwendung. Welche Anwendungsteile, seien es Seiten, Regionen, Items oder Shared Components, sind neu, entfallen oder wurden geändert?

Aus diesen Analysen ergibt sich eine ToDo Liste der Anpassungen, die Sie durchführen müssen.

Im nächsten Schritt führen Sie die Objekte der Schemas zusammen, so dass Sie ein gemeinsames neues Datenmodell für das neue Release erhalten. Auf dieser Basis passen Sie dann die Supporting Objects im Basisentwicklungsstrang an.

Zu guter Letzt, geht es noch an das Überarbeiten der Anwendung. Dabei müssen Sie neue Seite aus dem parallelen Release in die Basisversion integrieren. Evtl. müssen Sie nicht mehr benötigte Bestandteile entfernen. Der aufwändigste Part wird in der Regel die manuelle Integration von partiellen Änderungen , z.B. in einer vorhandenen Seite sein.

Datenmodelle vergleichen und Unterschiede ermitteln

Es gibt sicher viele Ansätze, mit denen Sie ausgehend von einem Entwicklungsstand eines Datenmodells die Änderungen zu einem neues Release ermitteln können. An dieser Stelle möchte Ich Ihnen zwei Varianten vorstellen.

Änderungen protokollieren

Mit etwas Disziplin könnten Sie jede Änderung, die Sie vornehmen, als DDL-Skript speichern. Ich persönlich finde allerdings, dass man durch solche Verwaltungsaufgaben immer aus seinem Arbeitsfluss gerissen wird. Wenn Sie so ein Vorgehen präferieren, dann schauen Sie sich doch einmal diesen Beitrag Protokollieren von Strukturänderungen an. Dort stelle ich Ihnen eine Möglichkeit vor, wie Sie einen DDL-Trigger nutzen können, der alle Änderungen an einem Schema protokolliert.

Abbildung 1: Änderungshistorie

Auf Basis dieses Protokolls können Sie ein DDL-Skript entwickeln, um damit das Datenmodell eines Releases in das Modell eines neueren Releases zu überführen.

Schema vergleichen

APEX bringt aber auch von Haus aus eine sehr nützliche Funktion für diesen Fall mit. Im SQL Workshop finden Sie im Bereich Utilities den Link Schema Comparison. Da hinter verbirgt sich ein Werkzeug, mit dem Sie die Objekte eines Schemas mit denen eines anderen Schemas vergleichen können. Ihnen werden allerdings nur die Schemas angezeigt, die dem Workspace zugeordnet wurden.

Wie Sie im ersten Teil dieser Beitragsreihe lesen konnten, können Sie einem APEX-Workspace mehrere Schemas zuordnen. Möchten Sie nun für eine neue Version Ihrer Anwendung ein Upgrade-Skript entwickeln, so können Sie wie folgt vorgehen.

Stellen Sie aus Ihrem Anwendungsarchiv die Vorgängerversionen Ihrer Anwendung wieder her.

Abbildung 2: Anwendung in neuem Schema wiederherstellen

Dabei wählen Sie ein anderes Schema als bei der aktuellen Version Ihrer Anwendung. Wenn Sie in Ihrer Anwendung die notwendigen DDL-Skripte als Supporting Objects hinterlegt haben, führen Sie diese bei der Installation aus.

Abbildung 3: Install Supporting Objects

Jetzt haben Sie in Ihrem Workspace das Schema Ihres Basisentwicklungsstrangs und das Schema des Vorgänger Releases im Zugriff.

Den Vergleich der jeweils enthaltenen Objekte können Sie anschließend mit Hilfe des Utilities Schema Comparison durchführen.

Abbildung 4: Schema Vergleichen

Die Handhabung ist einfach. Wählen Sie die zu vergleichenden Schemas aus und legen Sie bei Bedarf noch einen Filter fest. Dann klicken Sie auf Compare.

Abbildung 5: Schemas vergleichen

Als Ergebnis erhalten Sie eine Übersicht der abweichenden Datenbankobjekte. Anhand dieser Liste können Sie die fehlenden DDL-Skripte erstellen.

Anwendungsteile vergleichen, Unterschiede ermitteln

Eine APEX-Anwendung wird durch Ihre Eigenschaften definiert. Diese Daten werden bei APEX in Tabellen gespeichert. Diese strukturierte Ablage der Definition macht es möglich, Anwendungen sehr detailliert vergleichen zu  können.

Im Internet findet man vereinzelt Ansätze, mit denen Sie die Unterschiede zweier Anwendungen ermitteln können. Beispielsweise existiert ein Open Source Projekt auf github namens apex-diff, welches einen Vergleich ermöglicht.

Ein andere Möglichkeit bieten die APEX-Views. Über diese können Sie entsprechende select-Statements  entwickeln, die einzelne Bestandteile zweier Anwendungen miteinander abgleichen. So ein Abgleich – hier für die Pages – kann z.B wie in Listing 1 aussehen.

SELECT
    n.page_id,
    n.page_name,
    'Page was changed ( N: '
    || n.last_updated_on
    || ' , O: '
    || o.last_updated_on || ' )' AS info
FROM
    apex_180100.apex_application_pages n,
    apex_180100.apex_application_pages o
WHERE
    n.application_id = 115
    AND o.application_id = 113
    AND n.page_id = o.page_id
    AND n.last_updated_on <> o.last_updated_on
UNION
SELECT
    n.page_id,
    n.page_name,
    'New page in application ' || n.application_id AS info
FROM
    apex_180100.apex_application_pages n
WHERE
    n.application_id = 115
    AND NOT EXISTS (
        SELECT
            'X'
        FROM
            apex_180100.apex_application_pages o
        WHERE
            o.application_id = 113
            AND n.page_id = o.page_id
    )
UNION
SELECT
    o.page_id,
    o.page_name,
    'Deleted page ' AS info
FROM
    apex_180100.apex_application_pages o
WHERE
    o.application_id = 113
    AND NOT EXISTS (
        SELECT
            'X'
        FROM
            apex_180100.apex_application_pages n
        WHERE
            n.application_id = 115
            AND n.page_id = o.page_id
    );

Listing 1: App 115 mit App 113 vergleichen

Das Ergebnis sieht dann beispielhaft so aus.

Abbildung 6: Abweichende Seiten zweier APEX-Anwendungen

Auf Basis der APEX-Views können Sie auf diese Art und Weise für alle Komponenten einer APEX -Anwendung entsprechende Vergleiche erstellen.

APEX selbst bietet für den Anwendungsvergleich unter seinen WorkspaceUtilities aber auch ein entsprechendes Werkzeug namens Application Comparison.

Abbildung 7: APEX-Anwendungen vergleichen

Dieses liefert Ihnen eine Liste mit abweichenden Objekten.

Zusammenführen von Entwicklungszweigen (fork)

Grundsätzlich müssen Sie hier zwei Bereiche der Anwendung betrachten. Die Datenbankobjekte und die Anwendung.

Datenmodell bzw. Datenbankobjekte

Auf Basis der im vorhergehenden Abschnitt ermittelten Unterschiede können Sie nun das Schema des Basisentwicklungsstrangs auf den benötigten aktuellen Stand bringen.

Zuerst legen Sie die neue Objekte an. Dazu können Sie z.B. ein DDL-Statemit auf Basis des vorhandenen Objektes extrahieren oder Sie ermitteln die DDL- Anweisung wie oben beschrieben mit einem DDL-Trigger aus einer Log Tabelle.

Abweichende Datenbankobjekte (Tabellen, Views , Packages,…) müssen nun von Hand überarbeitet werden. Hier müssen Sie entscheiden, ob eine Version durch eine aktuelle Version komplett ersetzt werden kann oder ob eine manuelle Ergänzung notwendig ist. Als Beispiel seien hier neue Spalten in einer Tabelle oder neue Funktionen in einem PL/SQL Package erwähnt.

Als Ergebnis haben Sie in Ihrem Basisschema abschließend alle benötigten Datenbankobjekte aus beiden Entwicklungssträngen zusammen gefügt.

Supporting Objects

APEX bietet mit den Supporting Objects – wie bereits erwähnt – die Möglichkeit DDL und DML-Skripte in der Anwendung zu hinterlegen, die bei der Installation der Anwendung ausgeführt werden.

Ein einfacher Ansatz ist es ein DDL-Skript zu entwickeln, welches alle benötigten Datenbankobjekte von Grund auf neu erzeugt. Da es aber recht zeitaufwendig und fehleranfällig ist ein komplett neues Installationsskript zu erstellen, können Sie auch einfach ein weiteres DDL-Skript nach dem bereits vorhandenem laufen lassen. Dieses ergänzt dann die neuen Objekte.

Die Migration der bestehenden Daten einer produktiven Vorgängerversion kann in einem zweiten Schritt über ein Upgrade Skript erfolgen. Bei diesem Ansatz fügen Sie dem produktiven Workspace ein neues Schema hinzu in dem Sie die Anwendung inkl. aller Datenbankobjekte des neuen Releases installieren. Abschließend wird dann über die Supporting Objects ein Skript ausgeführt, welches die Daten aus der Vorgängerversion in die neue Tabellen des neuen Schemas überführt.

Dieser Ansatz bietet aus meiner Sicht den Vorteil, dass Sie immer eine sehr einfache Fallback-Variante haben. Die Altdaten und die alte Anwendung werden nicht angetastet und können im Fehlerfall weiter genutzt werden.

Werkzeuge

APEX bietet in seinem SQL Workshop das Werkzeug Generate DDL, mit dem Sie – auch selektiv – für vorhandene Datenbankobjekte DDL-Skripte erzeugen können.

Abbildung 8: SQL Workshop-Generate DDL

Auf dieser Basis können Sie dann  entsprechende Skripte erstellen und diese in den Supporting Objects hinterlegen.

Ein anderes sehr nützliches Tool finden Sie direkt in den Supporting Objects. In dem Bereich Installation Scripts können Sie über die Schaltfläche Create > einen Wizzard starten, der Ihnen zu Beginn u.a. die Option “Create from Database Object’ anbietet.

Abbildung 9: Supporting Objects – Install

Bei dieser Variante können Sie für verschiedene Datenbankobjekte entsprechende DDL Skripte erzeugen lassen und direkt in den Supporting Objects speichern.

Abbildung 10: Create from Database Object

Anwendungsteile zusammen führen

Jetzt müssen Sie sich noch um die Anwendung selbst kümmern. Leider ist auch hier einiges an Handarbeit angesagt. Es sind verschiedene Bereiche zu berücksichtigen.

Meine Empfehlung ist es mit den Shared Components zu beginnen. Da diese von verschiedenen anderen Teilen Ihrer Anwendung verwendet werden. Anschließend sind die Seiten und deren Bestandteile an der Reihe.

Shared Components

Um die Bestandteile der Shared Components von einer Anwendungsversion in eine Andere zu übernehmen, gibt es verschiedene Methoden.

1. Es gibt Komponenten bzw. Einstellungen, die Sie schlicht manuell überführen müssen.

2. Einige der Komponenten können Sie über Create > As a Copy of an … > Copy from Application aus einer anderen Anwendung des Workspaces übernehmen. Wo immer es geht, sollten Sie diese Möglichkeit nutzen. Eine Übersicht der Shared Components, bei denen ich diese Möglichkeit gefunden habe, finden Sie in Abbildung 11.

Abbildung 11: Shared Components mit Kopierfunktion

3. Als Alternative bietet sich für die meisten Shared Components noch der Export und anschließende Import an. Wobei auch dieser Ansatz durch notwendige Anpassungen (Workdpace-Id, App-Id und evtl. ein Offset) an dem Exportfile nicht optimal ist. Beachten sie bitte, dass beim Import Komponenten wie z.B. Seiten durch Seiten mit der gleichen Id überschrieben werden. Mehr dazu finden Sie unter anderem hier.

Pages und Co.

Als letzter Schritt sind jetzt noch die eigentlichen Seiten und deren Inhalte abzugleichen.

Neue Seiten können Sie über den Application Builder aus dem parallelen Release in Ihre Basisanwendung übernehmen. Dazu klicken Sie im Page Designer auf das + in der Toolbar. In dem sich öffnenden Drop-Down-Menü wählen Sie Page as Copy.

Abbildung 12: Seite kopieren

Jetzt folgen ‘Sie nur noch dem Wizzard und geben dabei an, dass Sie eine Seite aus einer anderen Applikation kopieren möchten. (Page in another Application)

Möchten Sie eine bereits vorhandenen Seite komplett ersetzen, so können Sie die neue Seite mit einer anderen PageId erzeugen lassen oder Sie löschen im Vorfeld die ursprüngliche Seite und kopieren die Seite dann mit der herkömmlichen Seitennummer.

Abbildung 13: Seiten können nicht direkt ersetzt werden

Geht es Ihnen darum, nur einzelne Bestandteile einer Seite aus dem Fork zu übernehmen, müssen Sie im ersten Schritt die Quellseite aus dem Fork in die Basisversion als Kopie einfügen. Anschließend öffnen Sie diese Seite und klicken mit der rechten Maustaste auf die Bestandteile der Seite die Sie kopieren möchten. In dem sich öffnenden Kontextmenü wählen Sie den Eintrag Copy to other Page und beantworten anschließend die Fragen des Wizzards.

Abbildung 14: Bestandteile in eine andere Seite kopieren

Wie bereits in dem Abschnitt über das Kopieren der Shared Components erwähnt, bietet APEX die – meiner Meinung nach nicht zu Ende gedachten Funktion – des Komponenten-Exports und -Imports. Über diese Funktion ist es Ihnen möglich selektiv Bestandteile einer Anwendung zu exportieren. Vor dem Import der Komponenten müssen Sie aber auch hier vorab das SQL-Skript manuell anpassen.(s.o.)

Fazit

Es ist schon ein mühsames Geschäft, verschiedene Versionen einer Anwendung zu Verwalten und zu beherrschen. Ich versuche immer parallele Entwicklungsstränge nach Möglichkeit zu vermeiden. Der Aufwand diese Stränge wieder in einem Basisentwicklungsstrangs zusammenzuführen ist mitunter sehr aufwändig.

Allerdings treffen Sie auch auf ähnlich Probleme, wenn Sie versuchen Komponenten aus bereits vorhanden Anwendungen in einer neuen – thematisch vielleicht anders gelagerten – Anwendung zu übernehmen und wiederzuverwenden. Auf Komponentenbasis stehen Ihnen dafür Plug/Ins zur Verfügung. Für zusammenhängende Teile (Module) eine Anwendung, die aus mehreren Seiten, Shared Components und Datenbankobjekten bestehen, bietet APEX kein wirklich praxistaugliches Konzept.

Sie können Funktionalitäten höchsten in kleine, in sich abgeschlossenen Anwendungen aufteilen. Dies funktioniert in der Praxis aber meist nur, wenn Sie auf Single Sign On setzen.

Beitragsreihe

 

Konfigurationsmanagement für Oracle APEX -Teil 1 Versionsverwaltung

Versionsverwaltung und Konfigurationsmanagement ist für den Entwicklungszyklus gerade auch im Rahmen agiler bzw. iterativer Entwicklung von Oracle Application Express (APEX) Anwendungen ein wichtiges aber sicherlich oft vernachlässigtes Thema. Im ersten Teil geht es um die Versionierung und das Betreiben unterschiedlicher paralleler Versionen in einer Entwicklungsumgebung.

Was versteht man unter Konfigurationsmanagement?

Laut Wikipedia versteht man unter Konfigurationsmanagement 

Konfigurationsmanagement (KM; englisch configuration managementCM) ist eine Managementdisziplin, die organisatorische und verhaltensmäßige Regeln auf den Lebenslauf eines Produkts und seiner Konfigurationseinheiten [..] anwendet.

[..]

Es sind vier Teilgebiete (Teilprozesse) des KM zu unterscheiden:

  • Konfigurationsidentifizierung (KI),
  • Konfigurationsbuchführung (KB),
  • Konfigurationsüberwachung (KÜ) und
  • Konfigurationsaudit (KA).

Ihre koordinierte Umsetzung ist für ein erfolgreiches Konfigurationsmanagement unumgänglich.

Quelle: https://de.m.wikipedia.org/wiki/Konfigurationsmanagement, 24.06.2018

Im Rahmen der Entwicklung von Software spricht man von Software-Configuration-Management(SCM).

Wie bei vielen Managementsystemen kommen solche Definitionen meist sehr sperrig daher. Im Rahmen der Anwendungsentwicklung mit APEX soll hier eine pragmatische Umsetzung des Ganzen gezeigt werden.

Agile Softwareentwicklung mit APEX

Beginnt man ein neues APEX-Projekt, so wird man je nach Projektmanagementmethode und Größe des Projektes unterschiedlich an die Sache heran gehen.

Aus meiner Sicht bietet sich aber gerade ein agiles Vorgehen für die Entwicklung von APEX-Anwendungen an. Welches konkrete Vorgehensmodell Sie dabei wählen ist zweitrangig.

Bei einem agilen Ansatz starten Sie mit einem ersten Teil Ihres Datenmodells und entwickeln dann sehr zügig die jeweiligen Seiten in Ihrer Anwendung. So erhalten Sie sofort vorzeigbare Anwendungsteile, die Sie mit Ihren Kunden, Productowner, … durchsprechen und abstimmen können.

Aber auch wenn Sie grossschrittiger vorgehen müssen und Ihren Kunden fertig entwickelte Releases ausliefern, gehen Sie als Entwickler wahrscheinlich itterativ an die Sache heran.

Sie starten also mit einem leeren Schema und einem Workspace, erstellen die ersten Tabellen. Dann kann schon die erste Version der Anwendung per Application Wizzard erzeugt werden. Durch die Nutzung der Metadaten, welche die Datenbank APEX zur Verfügung stellt, fügen Sie die ersten Seiten der Anwendung hinzu. Jetzt erweitern Sie das Datenmodell und ergänzen die zugehörigen Seiten in der Anwendung. Die Businesslogik lagern Sie in PL/SQL-Packages aus. Je nach Komplexität und Umfang des Projektes abstrahieren Sie zwischen Datenmodell und Anwendung noch über Views. Auf diese Weise entstehen sukzessive weitere Datenbankobjekte und Anwendungsteile.

Alle diese Teile sind Bestandteil einer sogenannten Konfigurationseinheit.

Sie erzeugen also eine Kette von Builds, die dann weiter zu einem Release der Anwendung führen.

Anschließend oder auch schon parallel werden Sie die Anwendung in einem Testsystem mehr oder weniger ausgiebig testen (lassen) und dann an Ihren Kunden ausliefern.

Je nach Anwendung entwickeln Sie das System weiter. In Ihrem Entwicklungssystem steht dann mit großer Wahrscheinlichkeit nicht mehr die Version, mit der Sie Ihre Kunden beliefert haben, zur Verfügung. Dies führt bei Supportanfragen Ihres Kunden dazu, dass Sie in einem Supportsystem, das ausgelieferte System mit entsprechendem Releasestand wiederherstellen müssen. Fixen Sie den Fehler in dem (veralteten Release), so muss die so bereinigte Version bei Ihren Kunden eingespielt werden. Zusätzlich müssen Sie nun das Problem auch noch in Ihrem aktuellen Entwicklungsstand der Anwendung beheben.

Noch komplizierter wird dieses Szenario, wenn Sie verschiedene Releasestände an mehrere Kunden ausgeliefert haben, dabei aber evtl. auch noch individuelle Anforderungen einzelner Kunden berücksichtigten mussten.

Aus diesem Lebenszyklus einer Software ergeben sich verschiedene Probleme:

  • Wie Verwalten Sie unterschiedliche Versionen (Releasestände und Builds) Ihrer APEX-Anwendungen ?
  • Wie erstellen Sie Test-, Integrations- und Supportsysteme, in denen Sie verschiedene Versionen Ihrer Anwendung verwalten können ?
  • Wie führen Sie parallele Entwicklungslinieren (Forkes) wieder in Ihrer Basisanwendung zusammen ?
  • Wie dokumentieren und identifizieren Sie die Änderungen an Ihren Anwendungsversionen inkl. aller Bestandteile (Tabellen, Views, Triggers, PL/SQL-Packages,…) ?

Konfigurationseinheiten: Komponenten einer APEX Anwendung

Aus welchen Bestandteilen besteht denn nun eine APEX-Anwendung?

Wenn Sie versuchen, diese Frage zu beantworten, schauen Sie sich doch einfach an, was Sie alles benötigen, um eine APEX-Anwendung in einem Produktivstem zum Laufen zu bringen.

Vorausgesetzt, dass eine laufende Oracle-Datenbank mit eingerichtetem APEX (in der korrekten Version) zur Verfügung steht, benötigen Sie zuerst ein Export-File der APEX-Anwendung. Dabei handelt es sich um ein SQL-Skript, mit dem Sie eine Anwendung in APEX exportieren und importieren können.

Die Anwendung basiert natürlich auf Tabellen und verwendet verschiedene anderen Datenbankobjekte. APEX bietet die Möglichkeit, diese Datenbankobjekte über entsprechende DDL-Skripte bei der Installation bzw. dem Import einer Anwendung anlegen zu lassen.

Um diese Tabellen initial mit Stammdaten zu füllen, erstellen Sie entsprechende DML-Skripte.

All diese Skripte können Sie in den sogenannten Supporting Objects hinterlegen, die Sie im Application Builder über die gleichnamigen Schaltfläche aufrufen können.

Abbildung 1: Supporting Objects

Auch für das Upgraden einer produktiven Anwendung, ist es möglich in den Supporting Objects Skripte zu hinterlegen, welche die Änderung zum Vorgänger-Release abdecken.

Natürlich kann man das benötigte Datenmodell über einen Dump oder separate SQL-Skripte in einem Produktivstem einrichten. Da die Supporting Objects aber Bestandteil einer APEX-Anwendung sind und diese mit in dem Anwendungs-Exportfile vorhanden sind, ist es am geschicktesten, diese Möglichkeit zu verwenden. Gerade auch im Hinblick auf die Versionsverwaltung bringt das einige Vorteile mit sich.

Versionierung

Damit Sie den Überblick über die Versionsstände Ihrer Anwendung behalten, ist es ganz hilfreich für etwas Ordnung zu sorgen. APEX bietet Ihnen die Möglichkeit, Ihren Anwendungen beschreibende Eigenschaften mitzugeben. Diese Eigenschaften finden Sie etwas versteckt hinter dem Button Edit Application Properties im Application Builder.

Abbildung 2: Anwendungseigenschaften

Wie Sie hier sehen können, finden Sie ein Textfeld namens Release. Hier können Sie für jede Version Ihrer Anwendung den zugehörigen Releasestand festhalten. Das klingt erst einmal banal, bringt aber den praktischen Vorteil mit sich, dass Sie bei einer archivierten oder  ausgeliederten Anwendung wissen, welche Version Ihrer Anwendung Sie gerade vor sich haben.

Aber wie können Sie eine Versionsnummer konzipieren, die Ihnen einen Überblick verschafft?

Es gibt da sicher verschiedene Möglichkeiten. Ich möchte Ihnen hier die von mir bevorzugte Variante vorstellen.

<Hauptentwicklungslinie>.<Entwicklungszweig>.<Build>

Zu Begin einer Anwendungsentwicklung, also vor dem ersten Release geht es also mit 0.0.1 los.

Nach einer Iteration oder dem erreichen eines Meilensteins erhöhen Sie die Build Nr. auf 0.0.2.

Haben Sie eine releasefähige Version Ihrer Anwendung erreicht, so erhöhen Sie die erste Stelle um 1.

Version 1.0.0

Diese Version nehmen Sie produktiv und entwickeln an der Anwendung weiter.

Es entsteht also Build 1.0.1… 1.0.2 …

Müssen Sie einen Fehler in Version 1.0.0 beheben, erstellen Sie einen Forke Ihrer Anwendung und geben diesem die Version 1.1.0. Änderungen an dieser Version laufen jetzt paralell zu Ihrer Hauptentwicklungslinie (Baseline), die bereits bei Version 1.0.2 angelangt ist.

Für einen anderen Kunden erweitern Sie die Version 1.0.0 um eine individuelle Funktion. Diese ist dann wieder ein Forke der Version 1.0.0 und wird mit 1.2.0 benannt.

Um nun den Aufwand dauerhaft in den Griff zu bekommen und den Überblick nicht zu verlieren, ist es ratsam, die Bugfixes aus den Strang 1.1.x und evtl. die kundenspezifischen Funktionen in den Basisentwicklungsstrang zu integrieren (merge). Was in APEX nicht immer so einfach ist. Aber dazu im zweiten Teil der Beitragsreihe später mehr.

Die neuen Funktionen und Bugfixes fulminieren dann irgendwann in einem neuen Release 2.0.0.

Ihre Entwicklungslinien sehen jetzt so aus.

Abbildung 3: Entwicklungsstränge

Im Application Builder werden Ihnen Ihre Anwendungen über ein Interaktiven Report präsentiert. Blenden Sie dort über Actions >> Columns die Version und evtl. andere für Sie relevante Spalten ein. Anschließend speichern Sie sich über Actions >> Report >> Save Report Ihre individuelle Berichtsansichten.

Abbildung 4: Version anzeigen

Hilfreich finde ich auch die Zuordnung von Anwendungen zu Gruppen. Z.B. können Sie so zwischen Test, Produktiv, Support und Entwicklung unterscheiden.

Anwendungsgruppen (Application Groups) legen Sie über das Menü App Builder >> Workspace Utilities-Database >> Application Groups fest. Über die Anwendungseigenschaften (Button Edit Application Properties) ordnen Sie Ihre Anwendung einer Gruppe zu. Diese Gruppen lassen sich genau wie die Version im Interaktiven Report einblenden.

Abbildung 5: Anwendungen gruppieren

Die Abbildung 5 zeigt ihnen eine aufbereitete Übersicht der Anwendungen in APEX, die bei dem oben skizzierten Projektablauf entstanden sind.

Archivierung von Releaseständen

APEX bietet verschiedene Möglichkeiten Anwendungen zu archivieren. Die Basis für diese Ansätze ist ein Exportfile. Über den Application Builder können Sie alle Eigenschaften eines APEX-Programms in Form eines SQL-Skriptes exportieren.

Abbildung 6: Anwendung exportieren

Diese Datei beinhaltet die komplette Definition aller Seiten, Regionen, Items, Prozesse,… aber auch aller Shared Components wie Dateien oder Listen und – wie bereits erwähnt – die Supporting Objects. Nutzen Sie all diese Möglichkeiten, so können Sie die komplette Anwendung inkl. der Datenbankobjekte in einer einzigen Datei zusammenfassen und später diesen (Release)Stand wiederherstellen.

Somit ergibt sich als einfache Möglichkeit verschiedene Versionen einer APEX-Anwendung zu archivieren, der regelmäßige manuelle Export der Anwendung und Speicherung in einer nach Versionen benannten Ordnern. Diese Idee kann man nun mit einer Software zur Versionsverwaltung wie z.B. SVN oder GIT kombinieren. Im Internet finden Sie verschiedene Beispiele, wie Sie mit verschiedenen Tolles diesen Weg automatisieren können.  In dem Artikel ORACLE APEX DEPLOYMENT:YOU’RE DOING IT WRONG stellt Martin D’Souza die Möglichkeit vor, via. SQLcl zu automatisieren.Mit APEX selbst wird der APEX Java Exporter ausgeliefert, über den Ihnen viele Möglichkeiten zum Exportieren von Anwendungen und Komponenten zur Verfügung stehen.

Wählen Sie beim manuellen Exportieren einer Anwendung das File Format “Database”, so archiviert APEX die Datei im sogenannten Export Repository. Dieses finden Sie in den Workspace Utilities-Database >> Export >> Export Repository (in der rechten Sidebar). Allerdings bietet die Tabelle nicht wirklich viele Informationen zu den archivierten Anwendungen.

Abbildung 7: Export Repository

Einen anderen Ansatz finden Sie in diesem Blog-Beitrag. Dabei werden die einzelnen Bestandteile (Seiten) einer Anwendung separat extrahiert und übersichtlich in einem Verzeichnisbaum bzw. der Datenbank gespeichert. Dieser Ansatz lässt auch automatisieren.

Eine weitere ebenfalls automatisierbare Variante bietet Oracle mit einem seiner Packaged Applications “APEX Application Archive”. Mit dieser Applikation lassen sich Backups Ihrer Anwendungen erstellen, die dann in der Datenbank verwaltet werden. Erweitern Sie das Ganze noch mit Hilfe des Datenbankschedulers ( dbms_schedule ), können Sie die Archivierung komplett automatisieren. Wie Sie das im Einzelnen funktioniert, können Sie sich in dieser Beitragsreihe genau ansehen.

Abbildung 8: Anwendungsarchiv auswählen

Ich persönlich favorisiere diese Möglichkeit, da Sie sich sehr schnell einrichten und anpassen lässt und mit der Package Application “APEX Application Archive” ein Programm zur Verwaltung der einzelnen Releasestände zur Verfügung steht.

Parallele Versionen in APEX betreiben

Aber wie können Sie diese unterschiedlichen Versionen Ihrer Anwendungen in APEX parallel bearbeiten und betreiben?

Eine einfache Möglichkeit ist es eine Kopie Ihrer Anwendung in dem Workspace anzulegen.

Allerdings gehören zu Ihrer Anwendung auch ein Datenmodell und die entsprechenden Datenbankobjekte. Diese werden zwischen den einzelnen Releaseständen Ihrer Anwendungen voneinander abweichen.

APEX bietet für dieses Problem eine einfache aber sehr elegante Lösung. Sie können Ihrem Workspace weitere Datenbank-Schemas zuweisen.

Dazu gehen Sie  so vor.

1. Melden Sie sich am Administration Service als Admin an.

2. Im Menü finden Sie unter Manage Workspace den Eintrag Manage Schema Assignment.

Abbildung 9: Manage Schema Assignment

3. Über Add Schema können Sie nun über einen Wizzard weitere Schemas anlegen.

Hinweis: APEX bietet hier zwei Möglichkeiten. Sie können ein vorhandenes Schema hinzufügen oder ein Neues anlegen. Diese Zweite Version lief in der von mir verwendeten Version auf einen Fehler. Um das Problem zu umgehen, legen Sie also einen User von Hand (z.B. über sqlplus) an und ordnen Sie diesen hier zu.

4. Melden Sie sich wieder als Entwickler an Ihrem Workspace an.

5. Exportieren Sie die Anwendung, die Sie in einem neuen Schema als neues Build/Release anlegen möchten.

6. Importieren Sie die Anwendung und wählen Sie im Import-Wizzard das neue Schema aus.

Abbildung 10: Schema zuordnen

7. Klicken Sie auf Next >.

8. In diesem Schritt wählen Sie die Option “Install Supporting Objects” = YES.

Abbildung 11: Install Supported Objects

9. Setzen Sie die Installation fort und folgen Sie dem Wizzard. Dabei werden nun die DDL-Skripte, welche Sie in den Supporting Objects hinterlegt haben, ausgeführt und somit die benötigten Datenbankobjekte in dem neuen Schema erzeugt.

Beitragsreihe