Die meisten UC4 Umgebungen kennen das Problem vermutlich: in der Produktion befinden sich UC4 Objekte, die nicht mehr benötigt werden. Allerdings dürfen diese Objekte aus Gründen der Revision nicht einfach gelöscht werden. Das führt dazu, daß die Objekte entweder stehen gelassen werden, oder manuell umbenannt oder verschoben werden. Eine Kombination aus UC4 Scripten, Jobs und Java API kann diese Aufgabe deutlich vereinfachen.

Der Ansatz

Der Lösungsansatz verwendet eine Schnittstelle, die UC4 für das Ausführen von Operationen auf Objekte im UC4 bereitstellt: den Menüeintrag "Senden an". Über diesen Menüpunkt können auf UC4 Objekte Aktionen ausgeführt werden; der Eintrag wird mit der rechten Maustaste auf einem UC4 Objekt erhalten. Dazu muß eine VARA UC_SENDTO im lokalen Mandanten erstellt werden, die einen (oder mehrere) Gültigkeitsbegriff(e) und zugehörige Werte enthält. Der Gültigkeitsbegriff ergibt einen Eintrag im Benutzermenü, der über "Senden an" erreicht werden kann; der zugehörige Wert gibt ein ausführbares UC4 Objekt an, welches bei der Auswahl eines Objektes ausgeführt wird. Diesem Objekt werden über den READ BUFFER mehrere Variablen mitgegeben, die mit :read im aufgerufenen Objekt ausgelesen werden können. Die wichtigsten Werte sind

• der Name des Objektes, welches ausgewählt wurde,
• der Typ des Objektes, welches ausgewählt wurde.

Hinweis: bei der VARA UC_SENDTO handelt es sich um eine referenzierte VARA, d.h. daß im MD 0 eine gleichnamige VARA angelegt ist, welche genommen wird, wenn keine lokale VARA gefunden wird.

Mit dieser Schnittstelle ist es möglich, eine einfache Lösung zu schreiben, die mit der Auswahl eines Objektes über einen Eintrag im Menü "Senden an" genau dieses Objekt verschiebt. Allerdings sollten bei dieser Lösung einige Punkte betrachtet werden:

• es wird der Fall sein, daß jemand viele Objekte verschieben wird. Das kann den Server unnötig belasten und sollte zuverlässig abgefangen werden.
• der Ablauf muß von mehreren Benutzern gleichzeitig, sogar für das gleiche Objekt, aufgerufen werrden können, ohne daß unerwünschte Seiteneffekte auftreten.
• alte Links sollten beim Verschieben gelöscht werden.
• es ist wünschenswert, wenn die Objekte nicht einfach alle in ein einzelnens Verzeichnis verschoben werden, sondern beim Verschieben die ursprüngliche Ordnerstruktur mit abgebildet wird. Vorzugsweise soll diese Ordnerstruktur unter einem eigenen Verzeichnis angelegt werden, bspw. unter __DEPRECATED.
• werden für einen Tag Objekte verschoben, so soll das Verschieben auch eine längere Zeit an dem Tag mit den bereits gestarteten Objekten möglich sein.
• werden für einen Tag keine Objekte verschoben, so sollen auch keine Aktivitäten gestartet werden.

In wesentlichen bedeutet dies, daß die Lösung in zwei Teile zerlegt wird:

• in einem Teil, der die zu verschiebenden Objekte entgegennimmt,
• sowie in einen Teil, der das eigentliche Verschieben durchführt. Dieser Teil wird nur ausgeführt, wenn tatsächlich Objekte verschoben werden sollen.

Die beiden Teile kommunizieren über eine gemeinsame VARA, in die die zu verschiebenden UC4 Objekte eingetragen werden.

Die Lösung

Vorbereitung

In der VARA UC_SENDTO wird ein Eintrag mit dem Gültigkeitsbegriff "TO_DEPRECATED" erstellt. Der zugehörige Wert ist der Name des SCRI, welches die zu verschiebenden Objekte entgegennimmt und in die gemeinsame VARA stellt.

Entgegennahme der zu verschiebenden UC4 Objekte

Die Aufgabe hört sich einfach an: es reicht einfaches SCRI, welches über den READ BUFFER den Namen und den Typ des zu verschiebenden Objektes entgegen nimmt, in eine VARA stellt, und das Verschieben (den "zweiten Teil") anstößt. Zudem prüft das SCRI außerdem, ob der Aufrufer in einer bestimmten Gruppe enthalten ist. Damit wird verhindert, daß nicht berechtigte Benutzer diesen Ablauf nutzen.

Problematisch wird es jedoch, weil der zweite Teil von einem  periodischen Zeitevent gestartet werden soll. Dieses Event soll natürlich nur einmal je Tag laufen. Daher muß das Einstellen der Objekte in die Kommunikations-VARA und das Starten des Events synkronisiert (seriell) erfolgen. Dabei wird geprüft, ob das Event schon gestartet wurde, und dieser Start übersprungen, wenn es bereits aktiv ist.

Verschieben der markierten UC4 Objekte

Das Verschieben der ausgewählten Objekte erfolgt wieder verlgeichsweise gradlinig. Das Zeitevent startet einen Ablauf, welcher das eigentliche Verschieben ausführt. Zuvor kopiert er allerdings alle zu verschiebenden Objekte aus der Kommunikations-VARA in eine work VARA, welche dem Ablauf für das Verschieben als Parameter übergeben wird. In der ursprünglichen VARA werden die übertragenen Einträge gelöscht, und im Fehlerfalle aus der work VARA wieder zurückkopiert.

Der Ablauf selber darf nur einmal laufen (max. parallel == 1), so daß zu jedem Zeitpunkt immer nur ein solcher Ablauf aktiv ist, und immer nur eine work VARA vorhanden ist. Der Ablauf selber besteht aus zwei Java Klassen sowie einem Script:

• die erste Java Klasse bestimmt das Verzeichnis, in welchem ein Objekt steht.
• die zweite Java Klasse setzt vor jedes gefundene Verzeichnis das Präfix für die __DEPRECATED-Ordnerstruktur und legt jedes dieser Verzeichnisse neu an, sofern es noch nicht existiert.
• das Script endlich verschiebt alle gefundenen Objekte. Dabei werden die Objekte jedoch nicht mit :move einfach verschoben - denn dann bleiben alle Links erhalten -, sondern auf dem UC4 Server exportiert und im neuen Verzeichnis unter __DEPRECATED importiert. Der Import überschreibt vorhandene Objekte und löscht alle eventuell vorhandenen Links. Daß das Objekte dann unter __DEPRECATED mit dem Benutzer angelegt wird, der den Ablauf aufgerufen hat, zeigt, wer das Objekt verschoben hat.

LOGIN-Objekte werden nicht mittels Export/Import verschoben, da hierbei die Passwörter entfernt werden. Stattdessen werden LOGIN Objekte mit :move verschoben; eventuell stehenbleibende alte Links werden in Kauf genommen.