Einführung:

Durch Konfigurationen kann der Anwender auf einfache Weise zwischen verschiedenen, zusammenhängenden Sätzen von Parameterwerten wechseln.
Jede Konfiguration muß für allen definierten Parameter Werte zuweisen. Damit man nun nicht pro neuer Konfiguration allen Parametern neue Werte zuweisen muß, kann eine Konfiguration auch die Parameterwerte mehrere anderer Konfigurationen “erben”. Im technischen Sinne findet also eine Mehrfachvererbung (multi inheritance) statt.
Da die verschiedenen Parameter meist sowieso zu verschiedenen Funktionsbereichen gehören (etwa Eigenschaften eines Computers, Eigenschaften einer Softwareinstallation, Eigenschaften einer Softwareversion, Eigenschaften einer Kundeninstallation), bietet es sich an, für jeden Funktionsbereich eine oder mehrere Basis-Konfigurationen (“Parent-Configurations”) zu erstellen. Die vom User benutzten Konfigurationen können sich dann weitgehend auf diese abstützen.
Konfigurationen, deren Name mit einem “_” beginnt, sind können für Scriptläufe nicht ausgewählt werden, sie sind unvollständige Basis-Konfigurationen.

Eine gut entworfene Konfigurations-Hierarchie vereinfacht die Pflege der Parameterwerte enorm!

Eingabe:

Die Eingabe findet in der Seite “Edit Configurations” statt.
In der oberen linken Tabelle “Configs” werden Konfigurationen definiert:

Feld	Bedeutung
CONFIG	Eine Konfiguration wird durch Angabe ihres Namens definiert. Beginnt der Name mit einem “_”, ist die Konfiguration “unsichtbar”.
INFO	Wird bei der Konfigurations-Auswahl und in den Logdateien angezeigt.

In der Tabelle rechts daneben sind die “Basis-Konfigurationen” für die aktuellen Konfiguration in “Configs” aufgelistet. Die aktuelle Konfiguration übernimmt die Parameterwerte der angegebenen Basis-Konfigurationen in der Reihenfolge, wie sie aufgelistet sind. Jede Basis-Konfiguration kann wiederum Werte aus anderen Basis-Konfigurationen erben. Hierarchie-Schleifen (Konfiguration A benutzt Konfiguration B, und B benutzt wieder A) werden möglicherweise nicht zuverlässig erkannt und führen zur Katastrophe.

Feld	Bedeutung
PlatzNr	Platz der Basiskonfiguration in der Liste.
PARENT_CONFIG	Name der Basiskonfiguration. Er kann aus der Liste aller definierten Konfigurationen ausgewählt werden.

In der unteren Tabelle “ParmVals” werden für jede Konfiguration Parameterwerte definiert. Geerbte Werte können hier überschrieben werden.

Feld	Bedeutung
PARAMETER	Name des Parameters, dessen Wert hier gesetzt wird
CONFIG	Name der Konfiguration, für die hier der Wert gesetzt wird.
Wert	Der Wert als Textstring. <%=..%>-Ausdrücke sind erlaubt.
Info	Erläuterungen

Im screen-shot sind die Konfigurationen der verschiedenen Datenbankinstanzen von GID -POLARIS zu sehen. Es ist erkennbar, daß die Konfiguration für die Datenbank “GID_EXP4” aus den Basiskonfigurationen “_BASE-ORA92” (für eine Oracle 9.2 Software-Installation), “_SRV_DBSERVER” (für einen bestimmten Datenbank-Server) und “_MD_ALL” (für eine bestimmte Verteilung von Tabellengrößen) besteht. Nur die vier Parameter “DB_VERSION”, “ORACLE_SID”, “SCALE_MEM” und “SERVICE” werden zusätzlich angegeben.

Parametrisierte Konfigurationsnamen

Die Namen von Basiskonfigurationen können <%=..%>-Ausdrücke enthalten (parametrisierter Konfigurationsname). Erst nach dem Auswerten dieses Ausdrucks entsteht der endgültige Konfigurationsname. Der <%=...%>-Ausdruck darf natürlich nur interne Parameter enthalten, da normale Parameter erst nach dem Laden der Konfigurationshierarchie bekannt sind.
 

In die Liste der Konfigurationen muss der parametrisierte und alle endgültigen Konfigurationsnamen,  eingetragen werden. Der parametrisierte Konfigurationsname liefert normalerweise keine Parameterwerte, er muss aber aus zwei Gründen einen Eintrag in der Konfigurationsliste haben:

• Er liefert Defaultparameter, wenn kein Eintrag für den endgültigen Konfigurationsnamen existiert.
• Er muss eingetragen sein, damit man ihn als Basiskonfigurationen auswählen und anderen Konfigurationen zuordnen kann.

Ein Beispiel für die Anwendung: Es werden Basiskonfigurationen erstellt, die abhängig vom PC sind, auf dem Scriptor gerade läuft.
Eine Konfiguration MYCONFIG hat als Basiskonfiguration die parametrisierte Konfiguration
"_HOST_<%=CURRENT_COMPUTERNAME%>"
eingetragen. Läuft SCRIPTOR auf einem PC mit Namen "BIGFOOT", dann wird beim Laden von “MYCONFIG” die endgültige Konfiguration “_HOST_BIGFOOT" dazugeladen, Läuft SCRIPTOR auf dem PC “SMALLFOOT", dann wird "_HOST_SMALLFOOT" geladen.

Obwohl in einen Konfigurationsnamen beliebig viele, beliebig komplexe “<%=...%>”-Ausdrücke eingesetzt werden dürfen, sind wohl nur die Ausdrücke “<%=CURRENT_COMPUTERNAME%>” und “<%=CURRENT_USERNAME%>” sinnvoll.