Cette rubrique décrit la configuration des propriétés Publisher.
Rubriques :
L'administrateur peut configurer la mise en cache au niveau du serveur afin que les données et le document de rapport soient stockés dans le cache lorsque Publisher traite un rapport.
Les concepteurs de rapports peuvent définir une propriété de rapport pour configurer une mise en cache d'ensembles de données propre à chaque rapport.
Les administrateurs peuvent configurer le nombre de tentatives de connexion à la source de données.
Si Publisher ne peut pas se connecter à une source de données via la connexion JDBC ou JNDI définie, il bascule vers la base de données de sauvegarde.
Les propriétés suivantes déterminent le nombre de nouvelles tentatives avant le passage à la connexion de sauvegarde pour la base de données.
Nombre de tentatives
La valeur par défaut est 6. Indiquez le nombre de tentatives de connexion avant passage à la base de données de sauvegarde.
Interv. entre tentatives (secondes)
Valeur par défaut : 10 secondes. Saisissez le nombre de secondes d'attente entre chaque tentative de connexion.
Cette rubrique décrit la configuration et les diagnostics du planificateur.
Vous pouvez examiner la configuration du planificateur sur la page Maintenance du système.
La taille de calcul (OCPU) que vous avez sélectionnée pour le service détermine les limites de traitement de rapport pour la génération de rapports avec une taille de pixel adaptée. Vous ne pouvez pas modifier les paramètres dans l'onglet Configuration du planificateur. Reportez-vous à Quelles sont les options de taille disponibles ?.
La page de diagnostic du planificateur indique le statut d'exécution du planificateur.
La page Diagnostics indique le nombre de demandes de rapport programmées qui ont été reçues par les files d'attente JMS, qui ont échoué et qui sont toujours en cours d'exécution. Le statut JMS est visible au niveau de l'instance de cluster, ce qui permet d'ajouter éventuellement des instances supplémentaires pour augmenter le nombre de ces processeurs JMS.
Par exemple, si les demandes mises en file d'attente pour le processeur de courriel d'une instance sont trop nombreuses, vous pouvez envisager d'ajouter une instance pour gérer le traitement des courriels. De la même façon, pour le traitement des rapports très volumineux qui apparaissent avec le statut En cours d'exécution dans la file d'attente de traitement des rapports, vous pouvez ajouter une autre instance pour augmenter la capacité de traitement des rapports.
La page Diagnostic du planificateur reflète également le statut de chaque composant, pour indiquer si certains sont à l'arrêt. Vous pouvez voir la chaîne de connexion ou le nom JNDI permettant d'accéder à la base de données, les associations entre les instances de cluster et les instances de serveur géré, les configurations de pool de connexions Toplink, etc.
Si une instance a le statut Echec, vous pouvez la récupérer. Grâce au mécanisme de basculement de JMS configuré sur le cluster, aucun travail soumis n'est perdu. Une fois remise en route, l'instance de serveur est immédiatement disponible dans le cluster pour le service. La suppression et l'ajout d'instances sont répercutés de façon dynamique sur la page de diagnostic.
Lorsqu'une instance est ajoutée au cluster, la page Diagnostic du planificateur la reconnaît immédiatement et affiche le statut de la nouvelle instance, ainsi que tous les threads exécutés sur cette instance. Elle propose de puissantes fonctionnalités de surveillance qui permettent à l'administrateur de suivre et de résoudre les problèmes de n'importe quelle instance ou n'importe quel composant du planificateur.
La page Diagnostic du planificateur fournit des informations sur les composants suivants :
JMS
Cluster
Base de données
Moteur de planification
La section JMS fournit des informations sur les éléments suivants :
Configuration de cluster JMS : cette section fournit des informations de configuration pour JMS :
Type de fournisseur (WebLogic/ActiveMQ)
Version WebLogic
Fabrique JNDI WebLogic
URL JNDI pour JMS
Noms de file d'attente
Répertoire temporaire
Exécution JMS : cette section indique le statut d'exécution de toutes les rubriques et files d'attente JMS.
La section Cluster fournit des détails sur l'instance de cluster. Utilisez ces informations pour comprendre la charge sur chaque processeur.
La section Base de données fournit des informations sur les composants.
Configuration de base de données : type de connexion, nom JNDI ou chaîne de connexion
Configuration Toplink : regroupement de connexions en pool, niveau de journalisation
Schéma de base de données
La section Quartz fournit des informations sur ces composants, comme illustré dans la figure ci-dessous.
Configuration Quartz
Initialisation Quartz
Sur la page Maintenance du système, l'administrateur peut définir les propriétés de visualiseur de rapport dans l'onglet Configuration du visualiseur de rapport.
Si la propriété Afficher le bouton Appliquer est définie sur True, les rapports dotés d'options de paramètre affichent le bouton Appliquer dans le visualiseur de rapport. Si vous modifiez les valeurs de paramètre, cliquez sur Appliquer pour afficher le rapport avec les nouvelles valeurs.
Si la propriété Afficher le bouton Appliquer est définie sur False, le visualiseur de rapport n'affiche pas le bouton Appliquer. Si vous saisissez une nouvelle valeur de paramètre, Publisher affiche automatiquement le rapport une fois la nouvelle valeur sélectionnée ou saisie.
Vous définissez cette propriété au niveau du rapport pour remplacer le paramètre système.
Utilisez la page Gérer le cache pour effacer le cache de serveur.
Le cache de serveur stocke les définitions, les données et les documents de sortie de rapport. Si vous devez purger ce cache manuellement (par exemple, après une application de patches), utilisez la page Gérer le cache.
Pour effacer des objets de rapport du cache de serveur, procédez comme suit :
Vous pouvez effacer le cache de métadonnées de domaine.
Les métadonnées de domaine BI telles que les noms de dimension et d'indicateur sont mises en mémoire cache au niveau du serveur pour une ouverture rapide du rapport dans le concepteur de rapports. Vous pouvez effacer manuellement ce cache si le domaine BI est mis à jour via un fichier de modèle sémantique binaire (.rpd).
Pour effacer le cache de métadonnées de domaine, procédez comme suit :
Vous pouvez purger les anciens journaux de diagnostics pour augmenter l'espace disponible sur votre système.
La durée de conservation par défaut pour les journaux des diagnostics de travail est de 30 jours. Si vous activez fréquemment les journaux de diagnostic, ces derniers peuvent utiliser de l'espace dans la base de données, d'où le besoin de libérer régulièrement de l'espace occupé par les anciens journaux de diagnostic. Vous pouvez purger manuellement les journaux de diagnostics de travail antérieurs à la période de conservation définie.
Utilisez la page Gérer le journal des diagnostics de travail pour purger un historique des anciens travaux.
La période de conservation d'un historique des travaux est définie par défaut sur 180 jours. Vous pouvez purger manuellement l'historique des travaux antérieurs à la période de conservation définie. Lorsque vous purgez l'historique des travaux, la sortie enregistrée, le fichier XML enregistré, les informations de distribution de travail et les détails de statut des anciens travaux sont supprimés.
Utilisez le centre de téléchargement afin de télécharger et de gérer les fichiers de configuration pour la police, la signature numérique, le profil ICC, la clé privée SSH, le certificat SSL et le certificat client JDBC.