In diesem Thema wird die Konfiguration der Publisher-Eigenschaften beschrieben.
Der Administrator kann das Caching auf Serverebene so konfigurieren, dass die Daten und das Berichtsdokument im Cache gespeichert werden, wenn Publisher einen Bericht verarbeitet.
Berichtsdesigner können eine Berichtseigenschaft festlegen, um berichtsspezifisches Caching von Datasets zu konfigurieren.
Der Administrator kann die Anzahl von Wiederholungsversuchen beim Herstellen einer Verbindung mit einer Datenquelle konfigurieren.
Wenn Publisher keine Verbindung zu einer Datenquelle über die definierte JDBC- oder JNDI-Verbindung herstellen kann, wechselt Publisher zur Backupdatenbank.
Die folgenden Eigenschaften steuern, wie viele Wiederholungsversuche durchgeführt werden, bevor zur Backupverbindung für die Datenbank gewechselt wird.
Anzahl Wiederholungen
Der Standardwert ist 6. Geben Sie die Anzahl der Wiederholungsversuche zum Herstellen einer Verbindung ein, bevor zur Backupdatenbank gewechselt wird.
Wiederholungsintervall (Sekunden)
Der Standardwert ist 10 Sekunden. Geben Sie die Anzahl der Sekunden für die Wartezeit vor dem Wiederholungsversuch ein.
In diesem Thema werden die Konfiguration und die Diagnose des Schedulers beschrieben.
Sie können die Konfiguration des Schedulers auf der Seite "Systemwartung" prüfen.
Anhand der ausgewählten Compute-Größe (OCPUs) des Service werden die Berichtsverarbeitungslimits für das Generieren pixelgenauer Berichte bestimmt. Sie können die Einstellungen auf der Registerkarte "Scheduler-Konfiguration" nicht bearbeiten. Siehe Welche Größenoptionen sind verfügbar?
Die Seite "Scheduler-Diagnose" zeigt den Laufzeitstatus des Schedulers an.
Auf der Diagnoseseite wird angezeigt, wie viele geplante Berichtsanforderungen bei den JMS-Queues eingegangen sind, wie viele davon nicht erfolgreich waren und wie viele noch ausgeführt werden. Sie können den JMS-Status auf Clusterinstanzebene anzeigen und so entscheiden, ob weitere Instanzen hinzugefügt werden sollen, um JMS-Prozessoren vertikal zu skalieren.
Beispiel: Wenn sich zu viele Anforderungen in der Queue für den E-Mail-Prozessor in einer Instanz befinden, können Sie eine weitere Instanz hinzufügen und für die E-Mail-Verarbeitung aktivieren. Analog dazu können Sie bei der Verarbeitung sehr großer Berichte, die den Status "Wird ausgeführt" in der Berichtsprozessqueue aufweisen, eine weitere Instanz zum vertikalen Skalieren der Berichtsprozesskapazität hinzufügen.
Die Seite "Scheduler-Diagnose" enthält auch den Status jeder Komponente. So können Sie sehen, ob eine Komponente heruntergefahren ist. Sie sehen die Verbindungszeichenfolge oder den JNDI-Namen für die Datenbank, welche Clusterinstanz mit welcher Managed Server-Instanz verknüpft ist, die Toplink-Verbindungspoolkonfiguration usw.
Wenn eine Instanz den Status "Nicht erfolgreich" aufweist, können Sie die Instanz wiederherstellen. Dank des im Cluster eingerichteten JMS-Failover-Mechanismus gehen dabei keine weitergeleiteten Jobs verloren. Nach der Wiederherstellung ist die Serverinstanz unmittelbar wieder im Cluster für den Service verfügbar. Das Entfernen und Hinzufügen von Instanzen wird dynamisch auf der Diagnoseseite angezeigt.
Wenn Sie eine Instanz zum Cluster hinzufügen, erkennt die Seite "Scheduler-Diagnose" die neue Instanz sofort und zeigt den Status der neuen Instanzen sowie alle in den einzelnen Instanzen ausgeführten Threads an. So erhält der Administrator eine leistungsstärkere Monitoringfunktion, um Probleme in Instanzen oder Komponenten des Schedulers zu tracen und zu beheben.
Die Seite "Scheduler-Diagnose" enthält Informationen zu den folgenden Komponenten:
JMS
CLUSTER
Datenbank
Scheduler Engine
Der Abschnitt "JMS" enthält Informationen zu Folgendem:
JMS-Clusterkonfiguration: Dieser Abschnitt enthält Konfigurationsinformationen für das JMS-Setup:
Providertyp (WebLogic/ActiveMQ)
WebLogic-Version
WebLogic JNDI-Factory
JNDI-URL für JMS
Queuenamen
Temporäres Verzeichnis
JMS Runtime: Hier sehen Sie den Laufzeitstatus aller JMS-Queues und -Topics.
Der Abschnitt "Cluster" enthält Details zur Clusterinstanz. Anhand dieser Informationen können Sie die Last jedes Prozessors ermitteln.
Der Abschnitt "Datenbank" enthält Informationen zu diesen Komponenten.
Datenbankkonfiguration: Verbindungstyp, JNDI-Name oder Verbindungszeichenfolge
Toplink-Konfiguration: Verbindungs-Pooling, Loggingebene
Datenbankschema
Der Abschnitt "Quartz" enthält Informationen zu diesen Komponenten, wie in der unten stehenden Abbildung dargestellt.
Quartz-Konfiguration
Quartz-Initialisierung
Auf der Seite "Systemwartung" kann der Administrator die Report Viewer-Eigenschaften auf der Registerkarte "Report Viewer-Konfiguration" festlegen.
Wenn Schaltfläche "Anwenden" anzeigen auf "True" gesetzt ist, zeigen Berichte mit Parameteroptionen die Schaltfläche Anwenden im Report Viewer an. Wenn Sie die Parameterwerte ändern, klicken Sie auf Anwenden, um den Bericht mit den neuen Werten wiederzugeben.
Wenn Schaltfläche "Anwenden" anzeigen auf "False" gesetzt ist, wird die Schaltfläche Anwenden nicht im Report Viewer angezeigt. Wenn Sie einen neuen Parameterwert eingeben, rendert Publisher den Bericht automatisch, nachdem der neue Wert ausgewählt oder eingegeben wurde.
Sie legen diese Eigenschaft auf Berichtsebene fest, um die Systemeinstellung außer Kraft zu setzen.
Auf der Seite "Cache verwalten" können Sie den Servercache löschen.
Der Servercache speichert Berichtsdefinitionen, Berichtsdaten und Berichtsausgabedokumente. Wenn Sie diesen Cache manuell leeren müssen (zum Beispiel nach dem Patching), verwenden Sie dazu die Seite "Cache verwalten".
So löschen Sie Berichtsobjekte aus dem Servercache:
Sie können den Metadatencache eines Themenbereichs löschen.
BI-Themenbereichsmetadaten wie die Dimensions- und Kennzahlnamen werden im Server gecacht, um den Bericht schnell in Report Designer zu öffnen. Sie können diesen Cache manuell löschen, wenn der BI-Themenbereich über eine binäre Datei für semantische Modelle (.rpd) aktualisiert wird.
So löschen Sie den Metadatencache eines Themenbereichs:
Sie können alte Diagnoselogs löschen, um den verfügbaren Speicherplatz auf dem System zu erhöhen.
Der Aufbewahrungszeitraum des Jobdiagnoselogs beträgt standardmäßig 30 Tage. Wenn Sie häufig Diagnoselogs aktivieren, können diese Logs Speicherplatz in der Datenbank belegen. Dann müssen Sie den durch die alten Diagnoselogs belegten Speicher regelmäßig freigeben. Sie können die Jobdiagnoselogs, die älter als der Aufbewahrungszeitraum sind, manuell löschen.
Auf der Seite "Jobdiagnoselog verwalten" können Sie eine alte Jobhistorie löschen.
Der Aufbewahrungszeitraum einer Jobhistorie beträgt standardmäßig 180 Tage. Sie können die Historie von Jobs, die älter als der Aufbewahrungszeitraum sind, manuell löschen. Wenn Sie eine alte Jobhistorie löschen, werden die gespeicherte Ausgabe, die gespeicherte XML, die Jobübermittlungsinformationen und die Jobstatusdetails der alten Jobs gelöscht.
Im Uploadcenter können Sie die konfigurationsspezifischen Dateien für Schriftart, digitale Signatur, ICC-Profil, SSH-Private Key, SSL-Zertifikat und JDBC-Clientzertifikat hochladen und verwalten.