Praktische Tipps im Umgang mit PITSS.CON bei größeren Oracle Forms Applikationen

PITSS.CON lässt sich für Oracle Forms Anwendungen jeglicher Größe verwenden. So haben wir in den letzten Monaten PITSS.CON bei Kunden mit nur 5 Oracle Forms Modulen und bei Kunden mit über 2.000 Oracle Forms Modulen installiert.

Abhängig von der Größe und Beschaffenheit der Anwendungen gilt es, PITSS.CON optimal einzusetzen.  Es gibt ein paar Punkte, die zu beachten sind, um schneller und effizienter arbeiten zu können. Das fängt schon bei der Auswahl der richtigen Installationsoptionen für PITSS.CON an.

User und Gruppenstruktur den Erfordernissen anpassen

Zunächst betrachten wir die vereinfachte Architektur von PITSS.CON. Vereinfacht deswegen, weil die Tabellen von MIG (Adminuser) hier nicht berücksichtigt werden.

Das Herzstück von PITSS.CON bildet das Datenbank basierte Repository. Hier laden wir alle Informationen über Module, Reports, Libraries, Pro*C, Pro*Cobol etc. und dem dazugehörigen Databankschema ein.

    G = Gruppe U = User

Abb. 1: Gruppen & User

Sichtbarkeit von Metadaten der User

Nicht nur lizenztechnisch sind die PITSS.CON User von Bedeutung. Es gibt auch direkte technische Auswirkungen. Jeder User kann ein oder mehrere Schemata der Anwendungsdatenbank ins Repository laden. Welche Schemata der Anwendung geladen werden dürfen, wird über die Einstellung im Adminbereich des MIG Users eingestellt.

Eine Gruppe ist wiederum eine Einteilung der User in verschiedene Organisationseinheiten – welche auch ein paar technische Gegebenheiten mit sich bringen:

  • User innerhalb einer Gruppe können nur Datenbank-Metadaten einer Instanz laden
  • User innerhalb einer Gruppe können die geladenen Daten anderer User sehen und analysieren
  • Nur der User mit den geladenen Daten kann die Daten bearbeiten

Bei der Installation muss dies also schon berücksichtigt werden:

  • Falls PITSS.CON für die Unterstützung von mehreren Anwendungen mit unterschiedlichen Datenbanken installiert werden soll, müssen so viele Gruppen erstellt werden, wie es unterschiedliche Datenbanken gibt
  • Falls mehrere User an einer Anwendung Analysen machen wollen, müssen diese User in derselben Gruppe installiert werden

Bei zwei Anwendungen mit jeweils 2 Entwicklern je Anwendungen benötigt man somit:

AAbb. 2: 2 Gruppen mit je 2 Usern = 4 User insgesamt

Ladeprozesse und Berechnungsprozesse reduzieren

Viele unserer Kunden legen besonders viel Wert auf die Analysemöglichkeiten von PITSS.CON.

Bei größeren Anwendungen sind längere Lade- und Parsingzeiten einzuplanen. Wenn jeder Entwickler für sich diese Prozesse startet, wird viel Zeit damit verbraucht nur PITSS.CON vorzubereiten und die tatsächlich geplante Änderung wird verzögert.

Eine gute Möglichkeit ist daher, die vollen Anwendungsdaten nur in einem PITSS.CON User vorzuhalten und die Entwickler greifen zur Analyse auf diesen User zu. Dabei ist es wichtig, dass der „Anwendungsuser“ und die User welche diese Daten analysieren sollen (Entwicklungsuser), in einer Gruppe installiert werden.

Abb. 3: Effiziente Analysefunktion durch einen “Analyseuser” in einer Gruppe

Mit einem „Anwendungsuser“ oder „Analyseuser“ (AU) greifen somit alle „Entwicklungsuser“ (E1 bis E*) auf dessen Daten zu. Nur die Module, die bearbeitet werden, werden im eigenen Repository geladen. Es empfiehlt sich, PITSS.CON Source Control einzusetzen, um Änderungen besser verfolgen zu können. Bei Massenänderungen über alle Module kann man auf den Analyseuser zurückgreifen.

Ladeprozesse und Berechnungsprozesse automatisieren

Die Ladeprozesse und das Parsen kann ganz  normal über „Module Handling“, „DB Handling“ und „Application Analysis“ gestartet werden.

Dies erweist sich aber schnell als zu zeitraubend und ist vor allem Überflüssig. Um diesen Ladeprozess zu vereinfachen und zu beschleunigen bietet PITSS.CON  die Möglichkeit diese Prozesse mit Batchjobs auszuführen.

Abb. 4: Standard Batchjobs in PITSS.CON

Diese Batchjobs können einfach in Skripte zusammengefasst werden und automatisch nach einen  Zeitplan gestartet werden.

Wir empfehlen dabei zwei Skripte wobei jeder Kombination möglich ist:

  • Ein Skript um inkrementell alle geänderten Module etc. zu laden und inkrementell die Anwendung zu parsen
  • Ein Skript um alle Daten zu löschen (truncate) und danach komplett neu zu laden und parsen

Wie oft welcher Batchlauf gestartet wird, ist von den Entwicklungszyklen abhängig.

Haben Sie Fragen zum Thema? Sprechen Sie uns an…