Tipps&Tricks zum RS IPS Project Exporter: Projekt-Hygiene

Das Vorspiel

Ich hatte vor einem halben Jahr das „Problem“, dass ich in einem meiner Projekte (nach größerer Umstrukturierung) ein Script übrig hatte, das ich nicht mehr gebrauchen konnte.

Aus dem Reflex heraus hab ich das natürlich gelöscht – in dem Wissen, dass das, was nicht da ist, auch nicht exportiert werden kann.

Doch halt! Was ist mit den Millionen von Anwendern, die auch dieses Projekt auf ihrem IP-Symcon einsetzen?! Wenn man das dann hochrechnet und mit weiteren hunderten von Releases interpoliert, die noch kommen werden – ergibt sich ein Horror-Szenario von Datenmüll, welches ich absolut nicht verantworten kann und möchte. Und am Ende steigt mir noch Greenpeace wegen Festplatten-Verschmutzung auf’s Dach. Das wäre dann der PR-SuperGAU.

Nein, hier muss eine Lösung her!

Nur woher weiß ich beim Erstellen der Lösch-Routine, welches Objekt in den Millionen Anwedner-Installationen welche ID hat – um das richtige Objekt zu löschen?

Überlegung

Ich könnte das zu löschende Objekt rein teorethisch auch über den Objektnamen im Zielsystem identifizieren. Aber was passiert, wenn der Anwender das Script umbenannt hat? Was passiert, wenn der Anwender ein weiteres, genau so benanntes Objekt in seinem System hat? ist mir alles viel zu gefährlich, das muss besser gehen!

Bei Neu-Installationen werden durch das Install-Script neue Objekte im Zielsystem erstellt, die auch eine neue, von IPS vergebene Objekt-ID bekommen. Diese Beziehung („Objekt-ID aus Quellsystem“ zu „Objekt-ID im Zielsystem“) wird genutzt, um auch in den Scripts verwendete Objekt-ID’s gegen die neuen ID’s auszutauschen. Anders formuliert: aus dem Installationsprotokoll weiß das Install-Script, welche „neue“ Objekt-ID das zu löschende Objekt im Zielsystem hat. 

Bei Updates ist das ganz genau so: der RS IPS Project Exporter – respektive das Installer-Script  legt bei jeder Installation im Zielsystem ein Installations-Protokoll an. In diesem Protokoll ist genau diese Beziehung abgelegt. Deswegen ist es auch so wichtig, für Updates auf das Installationsprotokoll zugreifen zu können. Ohne Protokoll kein Update!

Was bedeutet das nun für unser aktuelles Problem?

Die Lösung

Ganz einfach: ich muss mir gar keine Gedanken machen, welche Objekt-ID das zu löschende Objekt im Zielsystem hat. Denn das weiß sowieso nur das vom RS IPS Project Exporter generierte Installer-Script (wenn es im Zielsystem ausgeführt wird).

Ich schreibe ganz einfach eine Lösch-Routine, die das Objekt im Quellsystem löscht (also in dem System, in welchem ich das Projekt entwickle und später exportiere). Dazu verwende ich die Objekt-ID aus dem Quellsystem, um das zu löschende Objekt zu adressieren.

Wenn ich diese Lösch-Routine später mit dem RS IPS Project Exporter exportiere, wird die zu löschende Objekt-ID vom Installer-Script gegen die Objekt-ID des selben Objekts im Zielsystem ausgetauscht. Wenn dann anschließend die Löschroutine ausgelöst wird, wird genau das richtige Objekt gelöscht. Hat darüber hinaus den Vorteil, dass ich die Löschroutine im eigenen System so testen kann, als wäre es ein Zielsystem.

Verblüffend einfach, wa?

Die Umsetzung

Ich hatte in einem anderen Trickkisten-Beitrag  beschrieben, wie hilfreich ein gesondertes „Projekt-Initialisierungsscript“ sein kann, welches den Zweck hat, unmittelbar nach der Installation oder einem Update das Projekt im Zielsystem in einen definierten Zustand zu versetzen. Dieses Initialisierungsscript wird nur dann aufgerufen/ausgeführt, wenn der User das Config-Script manuell ausführt.

Und genau hier bringe ich den Code zum Löschen der Projektleichen unter. Der wird dann auch schön kommentiert, denn dieser Code wird in allen späteren Releases drin bleiben – man weiß ja nie, von welcher Version der Anwender updatet. Wenn der dann 10 Versionssprünge überspringt (und in der 11. Version ist der Lösch-Code nicht mehr drin) – haben wir trotzdem die  Projekthygiene-Vorschriften verletzt und potenziell Greenpeace im Nacken.

Grundsätzlich soll diese Löschroutine bei jeder Scriptausführung prüfen, ob das zu löschende Objekt im System existiert. Tut es das (also existiert das zu löschende Objekt), dann wird gelöscht. Existiert das Objekt nicht, wird auch nicht gelöscht.

So stelle ich sicher, dass a) keine Fehlermeldungen (bei nicht [mehr] vorhandenen Objekten) erzeugt werden und somit Unsicherheit beim Anwender erzeugen und b) kann ich diesen Code in allen weiteren Releases im Script stehen lassen – um sicher zu stellen, dass Anwender, die Releases überspringen, trotzdem hygienisch einwandfreie Projekt-Installationen bekommen.

Ablauf

Die Implementierung der ferngesteuerten Löschung von Objekten in Zielsystemen läuft demnach wie folgt ab (ergänzend dazu Bild rechts):

1. Implementierung des Löschcodes im Projekt-Initialisierungsscript (oder Config-Script) im Quell-Projekt
2. Einbau der Objekt-ID des zu löschenden Objekts aus dem Quellsystem in den Lösch-Code
3. Ausführung des Scripts, welches den Lösch-Code enthält (wir sind noch immer im Quell-System)
4. Export des Projekts aus dem Quellsystem mittels RS IPS Project Exporter
5. fertig

Wenn der Anwender nun diesen Export in sein Zielsystem importiert/installiert und anschließend sein Config-Script startet, wird das zu löschende Objekt in seinem System identifiziert und gelöscht. Optional könnte man noch eine echo-Meldung oder Logfile-Einträge mit einbauen.

Code-Beispiel