Erweiterte Programmierung


Die im Kapitel 2.4. beschriebenen Konfigurations-Eigenschaften nutzen den Konfigurationsmechanismus von iPlus. Dieser ist im Grunde genommen einfach eine Tabelle bzw. eine Entity-Frameworkklasse mit bestimmten Feldern. Welche Felder nötig sind, wird durch das Interface gip.core.datamodel.IACConfig definiert.

Der Konfigurationsmechanismus in iPlus ist jedoch weit mehr als nur das Speichern von Werten von Konfigurationsvariablen. Er löst folgende Problemstellungen:

  1. Ein komplexes Datenbankmodell hat eine Vielzahl von Tabellen die per Fremdschlüssel miteinander verknüpft sind. Oft benötigt man auch "M:N-Relationen" die mittels weiteren Tabellen abgebildet werden. Bei großen Datenbanken könne diese "M:N-Relationen" sehr umfangreich und unübersichtlich werden. In der Praxis werden diese Beziehungen oft gar nicht benötigt und diese Tabellen sind leer. Oft stellt sich erst bei der projektspezifischen Implementierung heraus, dass noch zusätzliche Beziehungen nötig sind, an die man im Vorfeld nicht gedacht hat. Die Folge ist, dass man das Datenbankmodell und somit auch das Entity-Framework-Modell erweitern muss.
  2. Oft benötigt ein Anwendungsprogrammierer nicht nur Verknüpfungen zwischen Entity-Objekten, sondern auch zwischen ACComponent-Instanzen. Dies können entweder Beziehungen innerhalb eines Anwendungsbaumes sein oder abstraktere Beziehungen sein. z.B. für Verknüpfungen zwischen iPlus-Typen (ACClass) aus der Anwendungsdefinition. Evtl. müssen aber auch mehrere Objekte verknüpft werden (z.B. ein Entity-Objekt aus einer Anwendungstabelle mit zwei Instanzen aus den Anwendungsbäumen...).
  3. Workflows bestehen aus einem Netzwerk von dynamischen Instanzen die während der Laufzeit geladen und entladen werden. Diese benötigen ebenfalls eine Konfiguration, die man im Vorfeld speichern muss und die dann während der Instanziierung oder Laufzeit von den Workflow-Knoten (auch ACComponents) gelesen werden. Dabei handelt es sich primär um die Parameter von virtuellen Methoden (entweder von der Workflowklasse selbst oder von Funktionsparametern für PAProcessFunctions). Auch Routing-Regeln müssen gespeichert und gelesen werden.
  4. Hinter Geschäftsprozessen verbergen sich oft viele Datenbanktabellen die in Abhängigkeit des Zustands in bestimmten Reihenfolgen gelesen und verarbeitet werden müssen. Je weiter ein Geschäftsprozess fortgeschritten ist, desto mehr Daten sind angefallen, die miteinander verknüpft worden sind und desto konkreter wird der Informationsgehalt. So verhält es sich auch mit den Konfigurationsdaten - je weiter der Prozess fortgeschritten ist, desto mehr Konfigurationswerte müssen hinzugefügt aber auch vorhergehende verändert werden. Wir nennen dieses Prinzip "strikte Entitätstrennung mit fortschreitender Konkretisierung" oder technisch gesprochen "Überschreiben von Parametern".

Die Lösung dieser Problemstellungen erfolgt nicht alleine durch das Interface IACConfig, sondern durch eine Reihe weiterer Schnittstellen:

Diese Schnittstellen sind bereits im "iPlus-Framework" als auch in "iPlus-MES" implementiert und die Funktionalität kann in den konkreten Klassen verwendet werden. Sie benötigen diese nur, wenn Sie selbst ein eigenes Datenmodell mit Konfigurationsmöglichkeit entwickeln möchten.

In den nachfolgenden Abschnitten wird auf die bereits vorhandene Implementierung in iPlus näher eingegangen.