Wenn die UC4 Reports von Jobs in die Datenbank geladen werden sollen, tritt bisweilen die Situation auf, daß auf Grund der Größe eines Reports dieser nicht mehr komplett in die Datenbank geladen wird. Als Folge hiervon besteht die Gefahr, daß das Dateisystem, auf dem die Reports abgelegt werden, mit der Zeit volläuft.

Um dieses Problem in den Griff zu bekommen, bieten sich mehrere Lösungsansätze an:

• alle Agenten auf Betriebssystemebene überwachen.
• aus UC4 für alle Agenten Jobs starten, welche die stehengebliebenen Reports suchen und packen/verschieben/löschen.
• gezielt diejenigen Agenten suchen, auf welchen Reports nicht in die UC4 Datenbank geladen werden konnten.
• Suche der Jobs, deren Reports nicht in die Datenbank geladen werden konnten, in der Datenbank selber.

Im folgenden wird die Lösung vorgestellt, mit der gezielt die Agenten bestimmt werden, auf welchen Reports nicht in die Datenbank geladen werden konnten. Diese Lösung hat gegenüber den anderen Ansätzen mehrere Vorteile:

• es werden nur die Agenten behandelt, auf denen tatsächlich Reports stehengelassen wurden. Damit verringert sich der Aufwand für diesen Wartungsablauf deutlich gegenüber Lösungen, welche alle Agenten einer UC4 Installation durchsuchen.
• es werden stabile Schnittstellen verwendet. Änderungen am Datenbank-Design müssen in den Abläufen nicht nachgezogen werden.

Hinweis: der Wert für die Obergrenze von Reportdatein wird übrigens mit dem Eintrag MAX_REPORT_SIZE in der UC4 VARA UC_HOSTCHAR_DEFAULT gesteuert. Defaultmäßig steht dort der Wert 120, so daß max. 120 Blöcke übertragen werden. Die Größe dieser Blöcke wird ihrerseits mit dem Eintrag REPORT_BLKSIZE in der gleichen VARA bestimmt. Der Standardwert hierfür lautet 8000 Bytes.

A. Vorstellen der Lösung

Die Lösung besteht aus zwei getrennten Teilen:

• einem Teil, welcher genau diejenigen Agenten bestimmt, auf denen Reports stehengeblieben sind.
• einem Teil, welcher für jeden gefundenen Agenten einen Job aktiviert, welcher die stehengebliebenen Reports packt, verschiebt oder löscht.

Die Kommunikation zwischen den beiden Teilen erfolgt durch eine temporäre UC4 VARA. In diese VARA werden die im 1. Teil gefundenen Agenten gestellt;  im zweiten Teil wird für jeden Agenten in dieser VARA ein entsprechend parameterierter Bereinigungsjob gestartet.

Voraussetzung dieser Lösung ist, daß die Benutzer, unter denen UC4 Jobs laufen, das Recht haben, im Verzeichnis für die Job-Reporte Dateien zu löschen. Für Unix Agenten wird dies durch die Öffnung dieses Verzeichnisses für group und other erreicht. Für Windows Agenten kann dies durch die Zuweisung administrativer Rechte an die benutzer, unter denen UC4 Windows-Jobs laufen, erreicht.

B. Vorbereitung

Beide Teile laufen in einem Jobplan ab. Dieser Jobplan legt eine temporäre Arbeits-VARA an, die von allen in ihm enthaltenen UC4 Objekten zur Kommunikation verwendet wird.

Teil 1: Bestimmung der Agenten

Die Agenten, auf welchen Jobs mit zu großen Reports abgebrochen sind, werden über ein Java-Programm gesucht. Das Java-Programm öffnet eine generische Suche nach Objekten vom Typ "REP" (Report), welche im fraglichen Zeitraum abgebrochen sind. Für jeden der abgebrochenen Reports wird der Parent bestimmt. Von diesem Parent wird nun der Agent (Host), auf dem das UC4 Objekt gelaufen ist, sowie der Benutzer, unter dem das UC4 Objekt gelaufen ist, festgehalten. Es ist möglich, daß auf einem Agenten UC4 Objekte unter mehreren Benutzern laufen. Zu den Benutzern werden dann noch die Login-Objekte gesucht, in denen der Benutzer vorkommt. Die gefundenen Agenten werden mit den zugehörigen UC4 Login-Objekten in die vom übergeordneten Jobplan erstellten Arbeits-VARA gestellt.

Vor der eigentlichen Verarbeitung werden in dem Java-Program in dem Mandanten, in dem der Ablauf aktiviert wird, alle Login-Objekte bestimmt. Aus jedem Login-Objekt wird der Agent und der Benutzer extrahiert, und dieser zusammen mit dem Namen des Login-Objektes gespeichert.

Teil 2: Bereinigen der Agenten

Um die stehengebliebenen Job-Reports zu packen oder zu verschieben wird die Arbeits-VARA des Jobplanes im zweiten Schritt von einem Script ausgelesen. Für jeden Eintrag in der Variable

• prüft das Script, ob der Agent schon umgestellt wurde, so daß technische Batchuser ihre Report-Dateien im Report-Verzeichnis löschen können. Dies erfolgt in einer Konfigurations-VARA, in der die Agenten festgehalten sind, auf welchen technische Benutzer im Verzeichnis der UC4 Reports Schreibrechte besitzen. Sofern der Benutzer dies nicht kann, wird der Name des Agenten und der Tag des Bereinigugnslaufes zur Protokollierung in eine eigene UC4 Variable gestellt. Für diesen Agenten erfolgt keine weitere Verabeitung.
• für alle anderen Agenten stellt das Script den Namen des Verzeichnisses, in das die Job-Reports gelegt werden, fest. Dies erfolgt über die Agenten-Variable UC_EX_PATH_JOBREPORT (Beispiel: :set &folder# = get_var('UC_EX_PATH_JOBREPORT', "&agent#"))
• weiter stellt das Script fest, welches Betriebssystem zu dem Agenten gehört.
• in Abhängigkeit vom Betriebssystem aktiviert das Script einen Unix- oder Windows-Job, der die Bereinigung durchführt. Dieser Job erhält als Parameter den Namen des Agenten (sienen Host), das Login-Objekt für die Anmeldung sowie den Namen des Report-Verzeichnisses.

Alle von dem Script aktivierten Jobs laufen in einer Gruppe, welche aus dem Gesamtablauf (Jobplan) aktiviert wird. So kann auf Abbrüche der Bereinigungsjobs im Jobplan reagiert werden.

Jeder der aktiveirten Jobs setzt Host und Login entsprechend der übergebenen Parameter. Dann werden die Dateien im Verzeichnis für die Job-Reports bestimmt, welche gepackt oder verschoben oder gelöscht werden können, und entsprechend dieser Vorgabe verarbeitet. Jeder Job berücksichtigt dabei nur diejenigen Dateien, welche von dem Benutzer, unter dem der Job läuft, angelegt wurden.

Parallel zu diesem Bereinigingsjobläuft ein weiterer Job, der die VARA mit den protokollierten Agenten, die noch nicht umgestellt wurden, auswertet. Dieser Job verschickt eine email, in der alle Agenten mit ihrem Job-Report-Verzeichnissen sowie dem Zeitpunkt, an dem die Protokollierung erfolgte, festgehalten sind.

C. Konfiguration

Der gesamte Ablauf ist konfigurierbar. Die Schwellwerte für das Packen oder Verschieben oder Löschen stehengelassener Job-Reports wie auch die email Adresse sind in einer UC4 VARA individuell konfigurierbar.

Weiter wird eine UC4 VARA angelegt, in der alle Agenten des Mandanten enthalten sind. In dieser VARA wird über den Wert eines Eintrages gesteuert, ob für einen Agent das Verzeichnis für die Job-Reports geöffnet wurde. Ein Wert-Eintrag bedeutet, daß die Umstellung erfolgt ist. Wie bereits gesagt erfolt eine Bereinigung nur für solche Agenten, für die das Job-report-Verzeichnis geöffnet wurde und auf denen technische Batchuser Reports verarbeiten dürfen.