Workflowparameter werden zum einen
- über die Benutzer-Oberfläche verwaltet,
- und zum anderen im Hintergrund von den Workflowinstanzen (aktive Workflows) gelesen.
In beiden Fällen muss das Programm wissen,
- welche Konfigurationsspeicher benötigt werden (IACConfigStore),
- in welcher Reihenfolge sie gelesen werden,
- und welches der aktuelle Konfigurationsspeicher ist, unter dem die Parameter gespeichert werden (aktueller Datenkontext).
Dies wird mittels folgender Schnittstellen bewerkstelligt:
A. Benutzeroberfläche
In den Programmen (Businessobjekte) zur Verwaltung von Material-Workflows, Stücklisten, Produktionsaufträgen, Kommissonieraufträgen, etc. gibt es eine Registerkarte in der Workflows grafisch angezeigt werden. Die Parameter, die über den Steuerungsdialog (gip.core.autocomponent.VBBSOControlPW) geändert und hinzugefügt werden, müssen im richtigen Konfigurationsspeicher abgelegt werden. Diese Information erhält der Steuerungsdialog über die Eigenschaft "IACConfigStoreSelection.CurrentConfigStore" des aktuell selektierten grafischen Workflowobjektes (Eigenschaft "VBBSOControlPW.CurrentPWInfo"). Das grafische Objekt wiederum ist eine Instanz einer Klasse, die "gip.core.datamodel.IACComponentPWNode" implementiert:
- PWOfflineNodeMethod: Modellklasse zur Darstellung von Workflowknoten zum Definitionszeitpunkt (nicht aktiver Workflow).
- PWBase: Basisklasse für alle Workflowknoten, die serverseitig instanziiert werden (aktiver Workflow).
- PWNodeProxy: Proxyklasse für PWBase (clientseitige Instanzen).
Mittels der Eigenschaft "IACConfigStoreSelection.MandatoryConfigStores" wird die Überschreibungsfolge definiert. Sie ist eine sortierte Liste von Konfigurationsspeichern (IACConfigStore). Diese Liste müssen also alle IACComponentPWNode bereitstellen, damit der Steuerungsdialog die Konfigurationsspeicher anzeigen kann, bei denen ein bestimmter Parameter überschrieben worden ist.
Damit der richtige Parameter, für den selektierten Workflowknoten, aus dem Konfigurationsspeicher gelesen und geschrieben werden kann, wird die Schnittstellelle IACConfigURL benötigt. Sie dient zur eindeutigen Adressierung eines Konfigurationsparameters innerhalb eines Workflows. Mittels "IACConfigURL.ConfigACUrl" wird in der aktuellen Konfigurationstabelle ("IACConfigStoreSelection.CurrentConfigStore") nach der Eigenschaft "IACConfig.ConfigACUrl" gefiltert. Die ConfigACUrl wird gebildet aus "IACConfig.PreConfigACUrl" und "IACConfig.LocalConfigACUrl".
Die PreConfigACUrl wird benötigt für "Unterprogrammaufrufe" - wenn ein Workflow einen Unterworkflow aufruft, zeigt die PreConfigACUrl auf den aufrufenden Workflow. Diese "Call-Stack-Information" liefert "IACConfigURL.PreValueACUrl". Da IACComponentPWNode von der Schnittstelle IACConfigURL erbt, weiß also die Workflowinstanz selbst von welchem "Eltern-Workflow" der "Unterworkflow" aufgerufen wurde zu dem die Workflowinstanz angehört. Den "Call-Stack" - sprich die Aufrufreihenfolge von Workflows - liefert die Eigenschaft ACConfigMethodHierarchy der Schnittstelle IACConfigMethodHierarchy. IACComponentPWNode erbt ebenfalls von dieser Schnittstelle.
Während der Deklarationsphase, wenn Workflows mittels PWOfflineNodeMethod-Instanzen präsentiert werden, finden tatsächlich keine Unterprogrammaufrufe statt. Dies ist nur während der Laufzeit möglich, wenn PWBase-Ableitungen instanziiert werden. Wenn Konfigurationsänderungen während der Laufzeit erfolgen, müssen die entsprechenden lebenden Workflowinstanzen darüber informiert werden, damit sie Just-In-Time die geänderte Konfiguration aus der Datenbank nachladen können. Da Änderungen erst mit der "Speichern"-taste in die Datenbank übernommen werden, kann es durchaus passieren, dass gleichzeitig mehrere Unterworkflows betroffen sind, in die der Anwender zuvor navigiert hat. Diese Information muss sich das entsprechende BSO merken. Aus diesem Grund müssen BSO's, die Workflows anzeigen, die Schnittstelle IACBSOConfigStoreSelection implementieren. Jedes Mal, wenn ein Konfigurationsparameter über den Steuerungsdialog geändert wird, informiert es das entsprechende BSO, in welchem Workflow (bzw. in welchem Unterprogramm) der Parameter geändert wurde, indem es die Methode "IACBSOConfigStoreSelection.AddVisitedMethods()" aufruft. Das BSO merkt sich dann alle Unterprogrammaufrufe in der Eigenschaft "List<ACClassMethod> VisitedMethods" bis der Speichervorgang auf der Datenbank ausgeführt wird. Bei erfolgreichem Speichervorgangs erfolgt die Benachrichtigung der aktiven Workflows (auf Serverseite) über die Hilfsmethode "ConfigManagerIPlus.ReloadConfigOnServerIfChanged()" - eine Klasse, die die Schnittstelle IACConfigProvider implementiert:
B. Hintergrund
Die unter A. beschriebene Logik ist zum einen umfangreich und zum anderen wird sie auch im Hintergrund benötigt, wenn Workflows bzw. Workflowknoten aktiv sind und Ihre Konfiguration lesen müssen. Letztendlich geht es darum, Konfigurationsparameter zu lesen bzw. zu manipulieren und die Komplexität von Parameterüberschreibungen (Reihenfolge der Konfigurationsspeicher) in Kombination mit Unterprogrammaufrufen zu verbergen.
Dies wird mittels der Schnittstelle IACConfigProvider gewährleistet. Ableitungen von PWBase und der Steuerungsdialog (VBBSOControlPW) verwenden die dort bereitgestellten Methoden. Die Klasse "gip.core.autocomponent.ConfigManagerIPlus" implementiert dieses Interface. ConfigManagerIPlus ist zustandslos und wird als lokaler Service unter der Adresse "\LocalServiceObjects\VarioConfigManager" bereitgestellt. ConfigManagerIPlus arbeitet nur mit Konfigurationsspeichern aus dem Datemodell "gip.core.datamodel". Für "iPlus-MES" dient die abgeleitete Klasse "gip.mes.processapplication.ConfigManagerIPlusMES", die mit Konfigurationsspeichern aus dem datenmodell "gip.mes.datamodel" umgehen kann.
