DTAP basierte Konfiguration

Speichern von Konfigurationen in der Datenbank hat gegenüber dem Speichern von Konfigurationen in Konstanten gewisse Vorteile. Man kann ausgewählten Benutzern erlauben Konfigurationen anzupassen ohne ihnen direkt Zugriff auf die Konstanten der Anwendung zu geben, man kann Konfigurationen ändern ohne die App neu starten zu müssen,…

Neben all diesen Vorteilen gibt es allerdings auch einen entscheidenden Nachteil. Die Vorteile ergeben sich daraus, dass die Konfiguration in der Datenbank steht. Der Nachteil ist, dass die Konfiguration in der Datenbank steht.

Warum ist das ein Problem?

Für viele Konfigurationen mag das alles überhaupt kein Problem sein. Für manche ist es jedoch mitunter eine Katastrophe. Wird eine Datenbank von einer Umgebung auf einer anderen wiederhergestellt (Lokal eine Production Datenbank zu Debugging zwecken, ACCP wird auf Test aufgespielt um aktuellere Daten zu haben,…) so greifen immer noch die Konfigurationen der Ursprünglichen Umgebung. Dies kann dazu führen, dass ein Testsystem auf eine Produktionsschnittstelle zugreift, dass E-Mails an die falschen Adressen geschickt werden,… Dies kann fatale Folgen haben und es sollte das Ziel jedes Entwicklers sein das zu vermeiden.

Die Lösung – DTAP basierte Konfigurationen

DTAP ist ein Kürzel und steht für:

• Development
• Test
• Acceptance
• Production

Also für die Anwendungsumgebungen die üblicherweise zur Verfügung stehen. Im Mendix AppStore gibt es ein Modul, das dem System mitteilt in welcher dieser Umgebungen es sich gerade befindet. Dies kann sehr praktisch sein wenn man bestimmte Prozesse nur auf bestimmten Systemen zulassen will (Z.B. das automatisierte Anlegen von Fake Test Daten in einem Testsystem), eignet sich aber auch hervorragend zur Lösung unseres Konfigurationsproblemes.

Das Modul findet sich hier:

Aelion – DTAP Environment information

Es stellt über einen Microflow eine Enumeration zur Verfügung, die einem Auskunft darüber gibt auf welchem System man sich befindet.

In einem vorherigen Blogpost habe ich ja bereits über CreateOrRetrieveIfExisting Microflows geredet. Erweitert man diese um das DTAP Modul, so kann man eine Konfiguration nur für das System verfügbar machen auf dem sie ursprünglich erstellt wurde. Das ganze sieht dann so aus:

Dem Settings Objekt wurde ein zusätzliches Enumeration Attribut namens ‚Environment‘ (Entspricht der Environment Enumeration aus dem DTAP Modul) hinzugefügt. Die Retrieve Action enthält hierbei nun folgendes XPath Constraint:

[Environment = $Environment]

Die Create Action setzt das Environment Attribut auf den Wert von Environment.

Über dieses Pattern kann man sicherstellen, dass bei einem Datenbankrestore auf einer anderen Umgebung nicht aus Versehen Produktivkonfigurationen verwendet werden, ohne jedoch den Komfort von Datenbankbasierten Konfigurationen zu verlieren.