Lokale persistente Objekte

Es geht hierbei um die Definition und Behandlung von lokalen Objekten, deren Inhalt bei Modulende aufbewahrt wird, und deren Inhalt bei Neustart desselben Moduls diesem wieder zur Verfügung gestellt wird.

Hintergrund ist die Notwendigkeit, für Batch-Gevos gleichbleibende Daten als Grundlage bereitzustellen, wobei die Beschaffung dieser Daten unter Umständen kompliziert und/oder langwierig sein kann. Deshalb ist die Idee entstanden, dass spezielle Objekte nicht bei Modul-Ende gelöscht werden, sondern erhalten bleiben, bis die TAA-Infrastruktur (TAA-Server, oder Host-Taaim) beendet wird.

• Das Objekt soll einmalig gefüllt, und mit diesem Inhalt von der Infrastruktur aufbewahrt werden („eingefroren“). Sobald eine neue Instanz desselben Moduls dieses Objekt verlangt, wird ihm das bereits gefüllte Objekt zurückgereicht.

• Das Füllen des Objekts muss durch die Anwendung erfolgen, da die Infrastruktur nicht die Informationen hat, um Objektinhalte selbständig bereitzustellen (Modulschnittstellen-Inhalte, benötigte Schlüsseltabellen, sonstige Anwendungsdaten).

• Es geht nicht darum, Gevo-übergreifend Daten auszutauschen, sondern ausschließlich darum, einmalig beschaffte Daten unverändert wiederholt zur Verfügung zu stellen. Gevo-übergreifender Datenaustausch wäre eine andere Anforderung, die anders gelöst werden müsste.

Bei der Deklaration eines lokalen Objekts wird festgelegt, ob dieses persistent sein soll oder nicht. Default ist nicht-persistent.

Ein persistentes lokales Objekt muss - wie alle anderen lokalen Objekte - immer mit einem Declare angelegt werden, damit es im Modul bekannt ist.

Wenn ein Modul ein persistentes Objekt deklariert, wird dafür wie bisher eine eigene Instanz dieses Objekts angelegt. Dabei wird geprüft, ob beim Server bereits ein Inhalt für dieses Objekt vorhanden ist. Wenn ja, wird dieser Inhalt in das Objekt geladen, sodass das Objekt in dem Modul direkt mit Inhalt zur Verfügung steht.

Sollte noch kein Inhalt für das Objekt vorhanden sein, bekommt das Modul eine leere Instanz. Die Anwendung kann am fehlenden Inhalt feststellen, dass noch keine Objektdaten eingefroren wurden, und die Datenbeschaffung veranlassen. Diese Abfrage auf vorhandenen/nicht vorhandenen Inhalt sollte das Standard-Verhalten von Modulen sein, die mit persistenten lokalen Objekten arbeiten.

Das „Einfrieren“ des Inhalts erfolgt am Ende des Moduls, also beim Unregister des Moduls in dem das Objekt deklariert wurde, bzw. beim Destroy des Objekts, sofern beim Server noch kein Inhalt für dieses Objekt vorliegt.

Die Infrastruktur prüft, ob bei Modulbeginn bereits ein gespeicherter Inhalt zur Verfügung gestellt wurde. Wenn nicht, wird der Inhalt des Objekts bei Modulende aufbewahrt und folgenden Instanzen des Moduls zur Verfügung gestellt.

Dies geschieht auch, wenn das Objekt am Ende des Moduls leer ist - es wird dann ein leerer Inhalt gespeichert.

Wenn mehrere Gevos parallel gestartet werden, wobei mehrere Instanzen des Moduls gleichzeitig den u.U. langwierigen Füllprozess anstarten würden, kann es zweckmäßig sein, das Füllen persistenter Objekte über eine Vorlauf-Gevo und spezielle Ereignisse in den Modulen zu veranlassen.

Ein lokales persistentes Objekt wird angelegt, wenn es in einem Modul das erste mal deklariert wird, und das Modul anschließend verlassen wird. Bei der nächsten Ausführung des Moduls steht der Inhalt der ersten Ausführung nach dem Declare zur Verfügung.

Der Inhalt eines persistenten Objekts wird so lange aufbewahrt, bis entweder der TAA-Server/die Host-Infrastruktur beendet wird, oder es manuell – im LAN über den TAA-Explorer – zurückgesetzt wird.

Die Speicherung des Objektinhalts erfolgt im LAN unter den Schlüsseln Modul, Objektname und Datenstruktur-Version.

Persistente Objekte können auch zurückgesetzt werden, also ein Neu-Füllen zu erzwungen werden, ohne dass dafür die Infrastruktur beeendet werden muss (z.b. Web-Server, der ununterbrochen läuft, weil sonst Makler-Transaktionen unterbrochen werden könnten). Die Notwendigkeit könnte z.B. entstehen durch dringend freizuschaltende Änderungen in Schlüsseltabellen.

Hierfür stellt der TAA-Explorer (LAN) eine Funktionalität bereit: Die persistenten Objekte werden getrennt von anderen Objekten aufgelistet und können dort auch zurückgesetzt werden.

Ggf. ist auch auf dem Host eine entsprechende Funktionalität vorzusehen.

Analog zu der Methode taaomObjDeclare gibt es die neue Methode taaOmObjDeclarePersistent.

sample.c

HTAAOMOBJ hObj = taaOmObjDeclarePersistent(HTAASTME hStme, LPCSTR lpszName, LPCSTR lpszObjt, LPCSTR lpszClas)

Die Declare-Anweisung kennt ein neues Attribut PERSISTENT:

sample.cbl

<EXEC TAA DECLARE <name> TYPE <dstr-name> CLASS <rec|lst|ref> [PERSISTENT]

Die Methode objDeclare kennt ein optionales viertes Argument, welches per Default false ist. Für die Deklaration persistenter lokaler Objekte sollte hier „true“ übergeben werden:

sample.cs

TAAObject obj = <modlenv>.objDeclare(System.String sName, System.String sTyp,System.String sKlasse [ System.Boolean bPersistent)]

In Steuerungen und CTV-Modulen ist die Definition von persistenten Objekte nicht möglich.

Auch für VisualBasic ist die Methode nicht implementiert.

• Wenn ein lokales persistentes Objekt deklariert wird und bei erstmaliger Ausführung des Moduls nicht gefüllt wird, wird dieser (leere) Inhalt gespeichert und bei allen folgenden Ausführung wieder zur Verfügung gestellt. Das Füllen des Objekts bei späteren Ausführungen bewirkt keine neue Speicherung des Objektinhalts!

• Das wiederholte Füllen eines bereits gefüllten Objekts kann zu unerwartet langen Laufzeiten führen, z.B.:

objTaaObject = modlEnv.TAAObjects[taaObjectName];
if (objTaaObject == null) {
    objTaaObject = modlEnv.objDeclare(taaObjectName, typeName, "REF", true);
    objTaaObject.objCompleteRef();
}

Da das Objekt vor dem Declare immer null ist, bewirkt dieser Code, dass das Objekt immer neu gefüllt wird. Im Falle von Schlüsseltabellen bewirkt dies bei der zweiten ff. Ausführung, dass für jeden beim ersten Mal in dem REF-Objekt gespeicherten Satz ein passender Schlüssel in der Schlüsseltabelle gesucht wird. Richtig wäre folgendes:

sample.cs

objTaaObject = modlEnv.objDeclare(taaObjectName, typeName, "REF", true);
if (objTaaObject.objIsEmpty) {
   objTaaObject.objCompleteRef();
}