Tipps&Tricks zum RS IPS Project Exporter: Umgang mit Config-Script und Projekt-Initialisierung

Naürlich ist es mir auch nicht am ersten Tag des Bestehens des Project Exporters klar gewesen, das brauchte schon ein paar Projekte, um auszureifen. Doch zunächst mal zum eigentlichen

Problem

Projekt Config-Script im Config-Ordner des Projekts

Das Config-Script ist ja dazu gedacht, den User vom eigentlichen Script-Kauderwelsch fern zu halten und evtl. Fehler durch „Codeanpassungen“ seitens des Users zu vermeiden bzw. deren Wahrscheinlichkeit zu verringern. Darüber hinaus hat das Config-Script die Aufgabe, die User-spezifischen Konfigurationsangaben vom Projektcode zu separieren. Das wiederum hat in Kombination mit dem Project Exporter den Vorteil für den User, dass er nach einem Projekt-Update nicht nochmal alle Konfig-Angaben manuell ins Script dengeln muss. So weit, so gut.

Nun ist es aber auch so, dass der Project Exporter prinzipbedingt einige Besonderheiten mit sich bringt. Zum Beispiel werden zyklische Timer bei Installation im Zielsystem immer deaktiviert. Wäre ja auch doof, wenn ein Projekt sofort nach Installation los rennt, ohne die User-Konfiguration abzuwarten.

Stellt sich nun die Frage: wie sorge ich als Projektautor für eine saubere Projekt-Initialisierung im Zielsystem des Users? Doch bevor jeder selbst den eigenen Grübel-Kübel auf trab bringt und evtl. an Selbstversuchen scheitert, hier 

Die Lösung

Beispiel-Code für Projekt-Initialisierung im Config-Script

ist ein Initialisierungs-Code im Config-Script! Problemchen hier ist nur, dass das Config-Script in der Regel via include x-Mal pro Tag (je nach Projekt) aufgerufen wird. Immer dann, wenn die User-Konfigurationsdaten in eben diesem Config-Script von anderen Scripts im Projekt benötigt werden. Nur wäre es ziemlich blöd, wenn dann auch die im Projekt befindliche Initialisierungslogik durchlaufen wird. Genau hier behelfe ich mir mit einem kleinen Trick: der Initialisierungs-Code wird nur dann abgearbeitet, wenn der User das Config-Script manuell via Konsole startet (Beispiel: Bild rechts, Projekt „RS RainRadar Forecast“).

Um das sicher zu stellen, wird die gesamte Initialisierungs-Logik in eine If-Abfrage gesetzt, die nur dann zur Ausführung die Freigabe erteilt, wenn Das Script durch sich selbst aufgerufen wird (ich hab mal den unten folgenden Code etwas freizügig übersetzt)

Als ID hinter dem „$_IPS[‚SELF‘] ==“ wird die  Objekt-ID eben dieses Config-Scripts angegeben.

In diese If-Abfrage kann nun alles Mögliche rein:

• Timer aktivieren
• Bei Updates ggf. nicht mehr benötigte Projekt-Objekte aus früheren Versionen löschen
• Default-Werte in Variablen setzen (um das projekt in einen definierten Ausgangszustand zu bringen, der Project Exporter kopiert nämlich keine Variablen-Inhalte – schon aus Datenschutz-Gründen nicht)
• WFE-Objekte konfigurieren (z.B. Links ein- oder ausblenden)
• das eigentliche Projekt-Script initial starten
• usw. usw.

Und noch eins drauf gesetzt

Arbeitsweise/Ablauf Projekt-Initialisierung

Wer noch einen Schritt weiter gehen will, lagert den Inhalt der If-Abfrage in ein separates Script aus, was nur den Projekt-Initialisierungscode enthält. In die If-Schleife kommt dann nur der Aufruf für dieses Script. Der Vorteil liegt hier darin, dass der User bei einem Projekt-Update gar nichts mehr machen muss (ggf. nicht mal das Hirn einschalten – je nach Projekt).

abgespeckter Code im Config-Script ruft Initialisierungs-Script auf

In der oben geschilderten Vorgehensweise muss nämlich immer dann, wenn sich der Projekt-Initialisierungscode im Config-Script ändert, auch das Config-Script im Zielprojekt ausgetauscht werden. Und wie wir uns dunkel erinnern (etwa nicht??), überschreibt der Project Exporter aus Prinzip keine Objekte, die im Config-Ordner des Projekts liegen….. pöhse, ganz phöse….

IP-Symcon Projekte exportieren…ist doch ganz easy …. ;-)