x

Die folgenden Schritte beschreiben, was passiert, wenn der Distribution Server einen Zeitplan identifiziert, der ausgeführt werden soll.

1. Der Distribution Server priorisiert den geplanten Job gegenüber Zeitplänen in der Warteschlange des Distribution Servers. Wenn Sie einen Zeitplan erstellen, können Sie einen Prioritäts-Parameter mit einem Prioritätswert von 1 bis 5 angeben, wobei 1 die höchste und 5 die niedrigste Priorität ist. Der Default-Prioritätswert ist 3. Die Warteschlange des Distribution Servers sortiert geplante Jobs nach Priorität und dann nach Zeit. Wenn nach einem Arbeitsablauf des Zeitplans ein Job oder mehrere Jobs in der Warteschlange verbleiben, während der nächste Zyklus beginnt, werden diese Jobs gegenüber neuen Jobs in der Warteschlange priorisiert.
2. Wenn eine Session (Thread) für den Reporting Server verfügbar ist, ruft der Distribution Server Zeitplan-, Parameter- und Alert-Informationen dynamisch aus dem WebFOCUS-Repository ab. Die Anzahl gleichzeitiger Threads für die Job-Ausführung wird durch die Einstellung Maximum Thread-Parameter im ReportCaster-Konsolen-Konfigurations-Tool gesteuert. Jeder in ReportCaster konfigurierte Reporting-Servert hat seine eigene Thread-Zuordnung. Zusätzlich können Threads für Aufgaben zugeordnet werden, die keinen Reporting-Server verwenden. Die Höchstzahl von Threads ist die Summe dieser einzelnen Thread-Einstellungen. Weiterhin werden Reports (WF-Serverprozeduren, Standardreports und Meine Reports) für das Einreichen beim IBFS-System für Sicherheit und WF-Client-Konfigurationsverarbeitung verpackt. Das IBFS-System reicht den geplanten Auftrag an den Reporting-Server weiter.
3. Der geplante Job eines Benutzers kann Folgendes sein:
   • WF-Serverprozedur. A -INCLUDE ruft die Prozedur (FEX) ab. Auf die Prozedur muss über den Serverpfad des Reporting Servers zugegriffen werden können.
   • Managed Reporting. Ruft den Client auf, um die Prozedur (FEX) vom Repository einzuholen.
   • URL. ReportCaster kann eine URL von jedem Webserver planen und den Inhalt an festgelegte Empfänger verteilen.
   • Datei. ReportCaster kann die Verteilung der Dateien planen, die statische Inhalte haben und auf die der ReportCaster Distribution Server Lesezugriff hat. Wenn Sie beispielsweise ein Microsoft® Word®-Dokument verteilen möchten, können Sie es verteilen, indem Sie den vollqualifizierten Pfad und Dateinamen der Datei angeben, z. B. D:\salesforecast\regionalquota.doc.
   • FTP. ReportCaster kann das Abrufen einer Datei von einem beliebigen FTP Server planen.

   Der geplante Job enthält Verteilungsinformationen, Parameterwerte und ReportCaster interne Variablen (wie z. B. Zeitplan-ID, Zeitplan-Prozedurname, Prozeduren für Vor- und Nachverarbeitung und die Benutzer-ID (Besitzer-ID), die den Job plant).

4. Der geplante Auftrag eines Benutzers kann "Datenextrakt aus einem Report" sein, der bei Client die Prozedur aus dem Repository abruft

   Der geplante Job enthält Verteilungsinformationen, Parameterwerte und Variablen (wie z. B. Zeitplan-ID, Zeitplan-Prozedurname, Prozeduren für Vor- und Nachverarbeitung und die Benutzer-ID (Besitzer-ID), die den Job plant).

5. Wenn dem geplanten Job das Folgende zugrunde liegt:
   • eine Prozedur (WF Serverprozedur oder Managed Reporting-Prozedur). werden abgerufene Reports für das Senden an den Reporting Server verpackt. Wenn ReportCaster einen geplanten Auftrag für WF-Serverprozeduren- oder WebFOCUS-Reports (Managed Reporting) vorbereitet und einreicht, sendet es Befehle an das IBFS-System zur Einreichung beim Reporting-Server. Der Resource Analyzer, der verwendet wird, um Anfragen zu verfolgen und Anfragen zu überwachen, die an den Reporting Server gesendet wurden, sowie Ressourcen, die verwendet werden, um den Report zu erstellen, der verteilt wird, ruft dann diese Befehle ab, um die Ressourcen zu überwachen, die verwendet werden, um den Report zu erstellen. Der Reporting Server führt die Prozedur aus, ruft die Daten ab, erstellt den Report und gibt den Report an den IBFS-System zurück, der den Report zurück an den Distribution-Server gibt. Der Distribution-Server verarbeitet die Verteilerinformationen dann und verteilt den Report. Diagrammanfragen werden an den Distribution Server zurückgegeben, der das Diagrammbild erstellt und es dann verteilt.

     Hinweis: Sie können angeben, dass bestimmte Befehle vor der Ausführung ausgeführt werden sollen, indem Sie die Einstellung Universales Profil in der WebFOCUS-Administrationskonsole verwenden. Weitere Informationen entnehmen Sie bitte dem Handbuch WebFOCUS-Sicherheit und -Administration.

   • URL. Der Distribution Server sendet die URL an einen Webserver, der die URL ausführt. Der Inhalt wird dann an den Distribution Server zurückgesendet, der ihn verteilt.
   • Datei. greift der Distribution Server auf die ihm zugeordneten Laufwerke zu, um die Datei abzurufen und sie dann zu verteilen.
   • FTP. greift der Distribution Server auf einen FTP-Server zu und ruft die Reportausgabe ab, die er daraufhin verteilt.
6. Der Distribution-Server verteilt die geplante Ausgabe entweder als E-Mail via FTP oder SFTP an einen Drucker oder als Report in einen Managed Reporting (WebFOCUS repository)-Ordner bzw. an die Reportbibliothek. Sie können die geplante Ausgabe auch an ein Faxgerät senden, indem Sie einen E-Mail/Fax-Service eines Drittanbieters nutzen.

   WF-Serverprozeduren und Managed Reporting unterstützen Bursting, was ermöglicht, dass Sie Teile eines Reports an bestimmte Empfänger senden. Falls Sie einen tabellarischen Burst-Report verteilen, hängt der Burst-Wert vom ersten BY-Feld ab. Falls Sie einen Burst-Diagramm-Report verteilen, hängt der Burst-Wert vom zweiten BY-Feld ab. Der Burst-Wert wird automatisch durch die interne Matrix bestimmt. Die interne Matrix ist ein Speicherbereich, der jeden Datenbank-Feldwert speichert und die Werte berechnet, auf die in einer TABLE- oder GRAPH-Anfrage verwiesen wird.

7. Sobald der Distribution Server die Ausgabe verteilt hat (oder die Ausgabe nicht verteilen kann), verarbeitet er die Log-Informationen und schreibt die Job-Informationen in die Log-Tabellen im WebFOCUS-Repository.

   Hinweis: Das Logging wurde geändert, sodass Meldungen in das WebFOCUS Repository geschrieben werden, wenn sie verfügbar werden, und nicht alle auf einmal am Ende eines Zeitplans. ReportCaster-Protokollinformationen werden in die Protokolltabellen geschrieben, während der Zeitplan läuft. Sie können somit einen Log-Report ausführen, während ein Zeitplan ausgeführt wird, um den Fortschritt des Zeitplans zu bestimmen.

   Fehlerbedingungen in Log-Reports werden in rot angezeigt und Warunungen in orange.

8. Falls eine Benachrichtigung benötigt wird, sendet der Distribution Server eine E-Mail-Benachrichtigung. Der Name des Mailservers, der die E-Mail-Benachrichtigung verarbeitet, wird in der Einstellung Benachrichtigungs-Mailhost im Konfigurations-Tool angegeben. Wenn Mailserver leer ist, verwendet den Default-Mailserver für E-Mail-Zeitplan-Verteilung, der in der Einstellung Mailhost im ReportCaster-Konfigurations-Tool angegeben ist.

   Für Log-Reports oder Benachrichtigungen können Fehlerbedingungen in den folgenden Fällen auftreten:

   • Eine FOC-Fehlermeldung wird an den Distribution Server zurückgegeben.
   • Es gibt keinen Report, der zu verteilen ist.
   • Es ist ein Fehler aufgetreten, als versucht wurde, eine Verbindung mit Diensten herzustellen (E-Mail, (S)FTP, Drucker, Managed Reporting, Reportbibliothek).

   Tipp: Wir empfehlen, dass Sie für die Benachrichtigung und die E-Mail-Verteilung unterschiedliche Mail-Server verwenden. Die Verwendung separater Mailserver stellt sicher, dass Sie Benachrichtigungen erhalten, auch wenn der Default-Mailserver ausfällt.

Nach oben

Beispiel: Einen geplanten Job ausführen

In diesem Beispiel fragt der Distribution Server jede Minute bei der BOTSCHED-Tabelle an, um zu sehen, ob geplante Jobs vorhanden sind. Beachten Sie jedoch, dass es autorisierten Benutzern ermöglicht, das Abfrageintervall für den Distribution Server zu verändern, indem Sie das Leseintervall im ReportCaster-Konfigurations-Tool einstellen. Das Intervall kann zwischen 1 und 999999 Minuten betragen.

1. Um 9:01 Uhr planen Sie einen Job mit einem Start-Datum und einer Start-Zeit von heute um 00:00 Uhr und einem Enddatum und einer Endzeit von 15:00 Uhr am folgenden Tag. Der Job soll alle zwei Stunden ausgeführt werden.
2. Um 9:02 Uhr liest der Distribution Server alle Datensätze von der BOTSCHED-Tabelle mit einer NEXTRUNTIME, die der aktuellen Zeit entspricht. Der Job erfüllt die Bedingungen nicht, da seine Start-Zeit 00:00 Uhr ist.
3. Der Distribution Server fragt danach jede Minute die BOTSCHED-Tabelle ab, um zu sehen, ob Jobs mit einer NEXTRUNTIME vorhanden sind, die vor der aktuellen Zeit liegt.
4. Um 12:00 Uhr liest der Distribution Server die BOTSCHED-Tabelle. Der Job erfüllt die Bedingung, da seine NEXTRUNTIME der aktuellen Zeit entspricht. Der Job wird in die Distribution Server-Warteschlange eingereiht und der Distribution Server aktualisiert seine NEXTRUNTIME auf zwei Stunden später, so dass die nächste NEXTRUNTIME 14:00 Uhr beträgt.
5. Der Distribution Server fragt danach jede Minute die BOTSCHED-Tabelle ab, um zu sehen, ob Jobs mit einer NEXTRUNTIME vorhanden sind, die vor der aktuellen Zeit liegt.
6. Um 14:00 Uhr liest der Distribution Server die BOTSCHED-Tabelle. Der Job erfüllt die Bedingung, da seine NEXTRUNTIME der aktuellen Zeit entspricht. Der Job wird in die Distribution Server-Warteschlange eingereiht und der Distribution Server aktualisiert seine NEXTRUNTIME auf zwei Stunden später, so dass die nächste NEXTRUNTIME 16:00 Uhr beträgt.
7. Dieser Ablauf wiederholt sich. Der Job wird bis um 15:00 Uhr am nächsten Tag alle zwei Stunden ausgeführt. Er wird das letzte Mal um 14:00 Uhr am nächsten Tag in die Warteschlange gesetzt.

Hinweis: Informationen über das Wiederherstellen von Jobs, die in die Warteschlange des Distribution Servers platziert wurden, deren NEXTRUNTIME aber nicht aktualisiert wurde, finden Sie unter Wiederherstellung. Weitere Hinweise zu Zeitplänen finden Sie unter Hinweise zu Zeitzonen und Hinweise zur Zeitumstellung.

x

Benutzer, die auf den von verschiedenen Zeitzonen aus fernzugreifen, müssen Jobs mit der Zeitzone planen, die für den Rechner gültig ist, auf dem sich der ReportCaster Distribution Server befindet. Wenn Zeitpläne für Jobs betrachtet werden, beziehen sich Datum und Zeit auf die Zeitzone des Distribution Servers.

ReportCaster verwendet Java-Technologie, die sich immer automatisch auf die Sommerzeit einstellt, unabhängig davon, wie Windows® eingestellt wurde. Wenn Sie sich in einem Gebiet befinden, in dem nicht auf die Sommerzeit umgestellt wird, werden die geplanten Jobs zur richtigen Zeit ausgeführt. Manche internen Dateien fügen jedoch den Zeitstempeln in diesem Zeitraum eine Stunde hinzu. Diese Dateien sind u. a.:

• Distribution Server-Log- und -Tracedateien.
• Reportzeitinformationen im Log-Report.
• Programme, die auf der Servlet Engine ausgeführt werden, einschließlich Servlet-Tracedateien.

x

Wenn Sie die Auswirkungen der Sommerzeit (DST) auf geplante Jobs von ReportCaster überdenken, ist hauptsächlich zu beachten, dass die Zeitumstellung um 01:59:59 Uhr vorgenommen wird. Daraufhin wird die Uhr entweder auf 03:00 Uhr (zu Beginn der Sommerzeit) oder auf 01:00 Uhr (am Ende der Sommerzeit) umgestellt.

Eine einfach zu merkende Regel ist, dass das Zeitplanintervall unabhängig von der Zeitumstellung gleich bleibt. Das liegt daran, dass die Laufzeit von der verstrichenen Zeit und nicht von der Uhrzeit abhängt.

Die folgende Tabelle listet und beschreibt das zu erwartende Verhalten für Jobs, die vom ReportCaster in der Sommerzeit geplant wurden.

Intervall	Beschreibung	Beispiel:
Der Zeitplan wird einmal zu einer festgelegten Zeit oder jeden Tag, jede Woche, jeden Monat oder jedes Jahr ausgeführt.	Der Zeitplan wird zu dieser Zeit ausgeführt, unabhängig von der Zeitumstellung.	Ein 9:15 Uhr-Zeitplan wird weiterhin um 9:15 Uhr ausgeführt.
Der Zeitplan wird jede Minute oder jede Stunde ausgeführt, sobald die Sommerzeit beginnt.	Der Zeitplan wird um eine Stunde vorgestellt.	Ein Zeitplan, der alle 2 Stunden ausgeführt wird: 00:00 Uhr, 2:00 Uhr, 4:00 Uhr usw. Wird zu den folgenden Zeiten ausgeführt: 00:00 Uhr, 3:00 Uhr, 5:00 Uhr usw. Dies passiert, da um 1:59:59 Uhr die Uhr auf 3:00 Uhr vorgestellt wird.
Der Zeitplan wird jede Minute oder jede Stunde ausgeführt, sobald die Sommerzeit endet.	Der Zeitplan wird um eine Stunde zurückgestellt.	Ein Zeitplan, der alle 2 Stunden ausgeführt wird: 00:00 Uhr, 2:00 Uhr, 4:00 Uhr usw. Wird zu den folgenden Zeiten ausgeführt: 00:00 Uhr, 01:00 Uhr, 03:00 Uhr usw. Dies passiert, da um 1:59:59 Uhr die Uhr auf 1:00 Uhr zurückgestellt wird.