Über Scripting können Metadaten und Masken-Controls um programmierte Funktionalitäten erweitert werden.
Dadurch können zum einen Metadaten als vollwertige Datenelemente mit Kontextfunktionen, Dialogschritten, Referenz- und Eventverarbeitung ausgestattet werden, zum anderen können Masken-Controls mit Funktionalitäten ausgestattet werden, die diese normalerweise nicht besitzen.
Vorbereitung der Scriptverarbeitung
Bei Verwendung der ersten Script-Funktion lädt ActiveSkin die Script-Dll. Diese muss zuvor mithilfe von "sogerpconsole -scriptcompile" übersetzt worden sein. Das Kommando übersetzt alle CSharp Script-Dateien in allen Verzeichnissen die durch die Variable "SOGScriptPath" definiert sind. Ist "SOGScriptPath" nicht gesetzt bricht die Scriptübersetzung ab.
Hinter den Verzeichnisnamen in der Variablen "SOGScriptPath" kann durch Angabe von "?recursive" dafür gesorgt werden, dass das entsprechende Verzeichnis rekursiv durchsucht wird, und auch alle CSharp-Dateien in allen Unterverzeichnissen mit übersetzt werden.
Die Scriptdateien werden alle gemeinsam in ein Ziel-Assembly übersetzt, aus dem heraus Script-Funktionen aufgerufen werden.
Wird eine Script-Datei in mehr als einem Verzeichnis abgelegt, so wird nur die Variante geladen und verwendet, die in dem durch "SOGScriptPath" zuerst definiert Verzeichnis aufgefunden wird.
Übersetzungsfehler führen zu einem Abbruch der Script-Übersetzung. ActiveSkin arbeitet dann ohne Scripting, kann aber Script-basierende Funktionen nicht erfolgreich verwenden.
Scripting in einer Installation mit unterschiedlichen Datenbanken und unterschiedlichen Metadatentabellen oder Scripten
Wird in einer SOG ERP (VACOS) -Installation z. B. durch die Festlegung von zwei unterschiedlichen Firmen, mit unterschiedlichen Datenbanken gearbeitet, die darüber hinaus mit unterschiedlichen Metadaten oder unterschiedlichen Scripten arbeiten, muss die Variable "ActiveSkinScriptName" gesetzt werden.
Ist ActiveSkinScriptName nicht gesetzt, wird für alle Firmen der Name "ActiveSkinScript.dll" verwendet.
Sind die Scripte jedoch für die einzelnen Firmen unterschiedlich, überschreibt die Script-Übersetzung diese Dll jeweils mit der zuletzt übersetzten Variante. In einem solchen Szenario sollte für alle weiteren Firmen die Variable auf einen eindeutigen Namen eingestellt werden. z. B. auf "ActiveSkinScript_firma99.dll" für Firma 99.
Über Scripte kann ActiveSkin in vielen Bereichen erweitert und ergänzt werden. Scripting geht inzwischen sogar so weit, dass vollkommen unabhängige Anwendungen mit eigener Datenhaltung und Maskenverarbeitung möglich sind.
Das zugrunde liegende Programmiermodell ist darauf ausgelegt, nach Möglichkeit kompatibel zu bleiben.
Da jedoch über Scripting auch Zugriff auf Funktionen ermöglicht werden, die eher internen Charakter haben, und da die SOG es sich ausdrücklich vorbehält, auch das zugrunde liegende Programmiermodel zu überarbeiten, zu erweitern oder auch zu vereinfachen, kann eine Kompatibilität von Scripten mit zukünftigen Versionen von SOG ERP (VACOS) nicht absolut sichergestellt werden.
So kann es notwendig werden, nach Installation einer neuen SOG ERP (VACOS) -Version mehr oder weniger geringfügige Anpassungen an den erstellten Scripten durchführen zu müssen.
Die Verantwortung für diese Anpassungen obliegt grundsätzlich dem Ersteller der Scripte. Scripte die durch die SOG erstellt werden, und im Hause SOG gewartet werden, werden im Zuge der allgemeinen Projektpflege an einen neuen SOG ERP-Stand angepasst.
Scripte die durch Kunden oder Dritte erstellt wurden, müssen bei SOG ERP (VACOS) -Aktualisierungen vom Kunden selbst gewartet und angepasst werden. Gerne ist die SOG Ihnen in solchen Fällen bei der Anpassung behilflich.
Auch wenn die technische Möglichkeit besteht, unterliegen die durch Kunden oder Dritte erstellten Scripte folgenden Beschränkungen:
Sie dürfen die SOG ERP Daten nicht verändern.
Sie dürfen die von der SOG ausgelieferte Businesslogik nicht verändern.
Analyse und Mitarbeit der SOG beim Scripting ist nicht durch den Wartungsvertrag abgedeckt.
Der Zugriff auf interne nicht öffentliche Schnittstellen und Daten ist nicht gestattet.
In der Software enthaltene Beschränkungen dürfen nicht umgangen werden (Beispiel: Lizenzen, Rechte)
Reverseengineering und Decompiling ist nicht gestattet.
Die Syntax der Definition von Referenzassemblies entnehmen Sie bitte der Beschreibung des Kommandos hhcsbat.