Traitement de ReportCaster

Dans cette section :

Référence :

L'image suivante montre les composants ReportCaster et le traitement qui a lieu lorsque ReportCaster accède à un référentiel SQL pour créer, exécuter et distribuer une tâche planifiée.

Le serveur de distribution est une application Java régissant les processus de soumission et de distribution d’une tâche planifiée. Vous pouvez installer le serveur de distribution sur la même plateforme que le serveur de génération de rapport et les composants (qui résident sur le serveur Web ou le serveur d'applications), ou il peut être installé sur une plateforme différente.

Le serveur de génération de rapport traite une demande planifiée, récupère des données et renvoie le rapport vers le serveur de distribution qui ditribue la sortie. ReportCaster prend en charge plusieurs serveurs de génération de rapport (spécifiés dans l'outil de configuration ReportCaster), et un référentiel (spécifié dans la configuration du client dans la console d'administration).

Lorsque vous créez un planning ReportCaster, une des propriétés du planning défini par ReportCaster est la prochaine date/heure d'exécution de ce planning (NEXTRUNTIME). Le serveur de distribution cherche les plannings du référentiel dont la prochaine heure d'exécution est inférieure ou égale à l'heure actuelle. Une fois que la tâche est exécutée, la fonction NEXTRUNTIME est mise à jour pour la prochaine fois où le planning sera exécuté.


Haut de page

x
Référence : Traitement par ReportCaster d'une tâche planifiée

Les étapes suivantes décrivent ce qui se passe lorsque le serveur de distribution identifie une planification à exécuter :

  1. Le serveur de distribution hiérarchise la tâche planifiée avec d'autres tâches planifiées dans la file d'attente du serveur. Lors de la création d'un planning, il y a un paramètre Priorité qui vous permet de spécifier une valeur de priorité allant de 1 à 5, où 1 est la plus grande priorité et 5 la plus petite priorité. La valeur de priorité par défaut est 3. La file d'attente du serveur de distribution trie les tâches de planification par priorité puis par heure. Si au cours d'un cycle de planification une ou plusieurs tâches demeurent dans la file d'attente lorsque le prochain cycle de planification débute, ces tâches sont reprioritarisées pour inclure toute nouvelle tâche qui entre dans la file d'attente.
  2. Lorsqu'une session (filière) vers le serveur d'applications est disponible, le serveur de distribution récupère dynamiquement la planification, le paramètre et les informations d'alerte dans le référentiel WebFOCUS. Le nombre de fils de discussion disponibles pour l'envoi de tâches est contrôlé par le paramétrage Maximum Thread dans l'outil Configuration Console ReportCaster. Tout Serveur de Rapports configuré dans ReportCaster possède sa propre allocation de thread. De plus, les threads peuvent être alloués pour des travaux n'utilisant pas un serveur de rapports. Le nombre maximum de threads représente le total de ces paramètres de threads séparés. De plus, les rapports (Procédures Serveur WF, Rapports Standards, et Mes Rapports) sont regroupés pour soumission au système IBFS pour traitement de configuration sécurité et client WebFOCUS. Le système IBFS soumet la tâche planifiée au serveur de rapports.
  3. La tâche planifiée d'un utilisateur peut être :
    • Procédure de serveur WF. Une commande -INCLUDE récupère la procédure (FEX). La procédure peut être accessible à partir du chemin de serveur du serveur de génération de rapport
    • Managed Reporting. Invite le à obtenir la procédure (FEX) à partir du référentiel
    • URL. ReportCaster peut planifier une adresse URL depuis n'importe quel serveur Web et distribuer son contenu à des destinataires spécifiés.
    • Fichier. ReportCaster peut planifier la distribution de fichiers qui contiennet du contenu statique pour lesquels le serveur de distribution ReportCaster dispose d'un accès en écriture. Par exemple, si vous souhaitez distribuer un document Microsoft® Word®, vous pouvez le faire en spécifiant le chemin d'accès pleinement qualifié du fichier, par exemple, D:\salesforecast\regionalquota.doc.
    • FTP. ReportCaster peut planifier la récupération d'un fichier à partir de n'importe quel serveur FTP.

    La tâche planifiée comporte des informations de distribution, des valeurs de paramètre et des variables internes ReportCaster (telles que l'identifiant de planification, le nom de la procédure de planification, les procédures de pré- et post-traitement, et l'identifiant de l'utilisateur (owner ID) qui a planifié le job).

  4. Lorsque la tâche planifiée est un(e) :
    • Une procédure (procédure de serveur WF ou procédure Managed Reporting). Les rapports récupérés sont mis en paquet pour la soumission au serveur de rapports. Quand ReportCaster prépare et transmet une tâche planifiée pour procédure serveur WF ou rapports WebFOCUS (Managed Reporting), il envoie des commandes au système IBFS pour transmission au serveur de rapports. Resource Analyzer, qui est utilisé pour suivre et surveiller les requêtes soumises au serveur de rapports et les ressources utilisées pour créer un rapport à distribuer, va alors récupérer ces commandes dans le but de surveiller les ressources utilisées pour créer le rapport. Le serveur de rapports exécute procédure, récupère les données, crée le rapport, puis renvoie ce dernier au système IBFS qui le retourne au serveur de distribution. Le Serveur de distribution traite alors l'information de distribution, puis distribue le rapport. Pour les demandes de graphiques, les données sont renvoyées au Serveur de distribution qui crée l'image graphique et la distribue.

      Remarque : vous pouvez spécifier que certaines commandes ne soient pas exécutées avant l'exécution de la tâche planifiée en utilisant le paramètre profil universel dans la console d'administration WebFOCUS. Pour plus d'informations, consultez le manuel Administration et Sécurité WebFOCUS.

    • URL. Le serveur de distribution soumet l'URL à un serveur Web, qui exécute l'URL. Le contenu est renvoyé au serveur de distribution, qui le distribue.
    • Fichier. Le serveur de distribution accède à ses unités mappées afin de récupérer le fichier, qu'il distribue ensuite.
    • FTP. Le serveur de distribution accède à un serveur FTP où il récupère la sortie du rapport, qu'il distribue ensuite.
  5. Le serveur de distribution distribue la sortie de procédures planifiées en tant que message e-mail, par FTP ou SFTP vers une imprimante, en tant que rapport vers un dossier Managed Reporting (référentiel WebFOCUS) ou vers la Bibliothèque de Rapports. Vous pouvez également distibuer la sortie planifiée vers un télécopieur à l'aide d'un fournisseur tiers d'email vers fax.

    Les procédures du serveur WF et Managed Reporting prennent en charge la fonction d'envoi en rafale, ce qui vous permet d'envoyer les portions d'un rapport à des destinataires spécifiques. Si vous distribuez un rapport tabulaire, la valeur d'envoi en rafale est déterminée par le premier champ BY. Si vous distribuez un tableau de rapport graphique, la valeur d'envoi en rafale est déterminée par le second champ BY. La valeur d'envoi en rafale est automatiquement déterminée par la matrice interne. La matrice interne est une zone de mémoire qui enregistre chacune des valeurs de champs de base de données et calcule les valeurs référencées par la requête TABLE ou GRAPH.

  6. Lorsque le serveur de distribution a distribué la sortie (ou lorsqu'il n'est pas en mesure de le faire), il traite les informations de journal écrit les informations relatives à la tâche dans les tables de journal du référentiel WebFOCUS.

    Remarque : le traitement de la connexion à été modifié pour que les messages soient écrits dans le référentiel WebFOCUS dès qu'ils sont disponibles, plutôt qu'en une seule fois à la fin d'un planning. L'information du journal ReportCaster est écrite dans les tables de journal quand le planning progresse. Par conséquent, vous pouvez exécuter un rapport de journal pendant l'exécution d'un planning afin d'en déterminer le progrès.

    Dans les rapports de journal, les conditions d'erreur s'affichent en caractères rouges et les avertissements en orange.

  7. Si une notification est requise, le serveur de distribution envoie un email à cet effet. Le nom du serveur de messagerie qui traite la notification e-mail est spécifié dans le paramètre Notifier Hôte de serveur de messagerie dans l'outil de configuration. Dans l'espace vide, utilise le serveur de messagerie par défaut utilisé pour distribuer une planification e-mail, spécifié par le paramètre Mailhost dans l'outil de configuration ReportCaster.

    Les conditions d'erreur ont lieu pour les rapports de journal ou de notification lorsque :

    • Un message d'erreur FOC est renvoyé vers le Serveur de distribution
    • Il n'y a pas de rapports à distribuer.
    • Une erreur s'est produite lors de la communication avec un service (client e-mail, protocole (S)FTP, imprimante, Managed Reporting, Bibliothèque de rapports).

    Conseil : vous vous conseillons d'utiliser différents serveurs de messagerie pour la notification et la distribution d'emails. Le fait d'utiliser des serveurs de messagerie distincts vous assure d’être tenu informé lors d’une panne du serveur de messagerie par défaut.



Exemple : L'exécution d'une tâche planifiée

Dans cet exemple, le Serveur de distribution sonde la table BOTSCHED toutes les minutes à la recherche des tâches planifiées. Toutefois, notez que permet aux utilisateurs autorisés de changer l'intervalle d'interrogation pour le serveur de distribution grâce au paramètre Reader interval (Intervalle de lecteur) de l'outil de configuration ReportCaster. Vous pouvez définir un intervalle de 1 à 999999 minutes.

  1. A 9h01, vous avez planifié une tâche avec une date/heure de démarrage d'aujourd'hui à midi et une date/heure de fin demain à 15h00 de l'après-midi. La tâche est prévue toute les deux heures.
  2. A 9h02, le serveur de distribution lit tous les enregistrements de la table BOTSCHED avec un NEXTRUNTIME égal à l'heure actuelle. La tâche n'est pas admissible, car son heure de début est 12h00.
  3. Le serveur de distribution sonde alors la table BOTSCHED toutes les minutes à la recherche de tâches dont la valeur NEXTRUNTIME est inférieure ou égale à l'heure actuelle.
  4. A 12h00, le serveur de distribution lit la table BOTSCHED. La tâche est admissible puisque son paramètre NEXTRUNTIME est égal à l'heure actuelle. La tâche est placée dans la file d'attente du Serveur de distribution et le Serveur de distribution met à jour son paramètre NEXTRUNTIME de deux heures afin que le NEXRUNTIME soit à 2h:00.
  5. Le serveur de distribution sonde alors la table BOTSCHED toutes les minutes à la recherche de tâches dont la valeur NEXTRUNTIME est inférieure ou égale à l'heure actuelle.
  6. A 2h00, le serveur de distribution lit la table BOTSCHED. La tâche est admissible puisque son paramètre NEXTRUNTIME est égal à l'heure actuelle. La tâche est placée dans la file d'attente du Serveur de distribution et le Serveur de distribution met à jour son paramètre NEXTRUNTIME de deux heures afin que le NEXRUNTIME soit à 4h:00.
  7. Ce processus se répète. La tâche sera exécutée toutes les deux heures jusqu'à 3h00 le lendemain. La tâche sera mise dans la file d'attente d'exécution pour la dernière fois demain à 14h00.

Remarque : pour des informations sur la récupération de tâches placées dans la file d'attente du serveur de distribution mais dont la valeur NEXTRUNTIME n'a pas été mise à jour, voir Récupération. pour d'autres considérations sur les plannings, reportez-vous à Considérations sur le fuseau horaire et à Considérations sur l'heure d'été.


Haut de page

x
Considérations sur le fuseau horaire

Les utilisateurs qui accèdent à distance depuis une zone horaire différente doivent planifier les tâches à l'aide de la zone horaire de la machine sur laquelle le Serveur de distribution ReportCaster est situé. Lors de la consulation des tâches planifiées, la date et l'heure affichées sont celles de la zone horaire du serveur de distribution.

ReportCaster utilise la technologie Java, qui s'ajuste toujours pour l'heure d'été, indépendamment des paramètres de Windows®. Si vous êtes dans une région qui ne respecte pas l'heure d'été, les tâches seront effectuées au moment adéquat. Cependant, certains fichiers internes ajoutent une heure aux estampilles pendant cette période. Ces fichiers comprennent notamment :


Haut de page

x
Considérations sur l'heure d'été

Si l'on considère l'effet de l'heure d'été (l"heure d'été) pour les tâches panifiées par ReportCaster, la principale chose à retenir est que 1:59:59 est l'heure à laquelle le changement se produit. Par conséquent, l'horloge temps est réglé soit à 3h00 (lorsque l'heure d'été commence) ou à 1h00 (lorsque l'heure d'été prend fin).

Une règle simple à se rappeler est que, quel que soit le changement d'heure, le calendrier intervalle reste le même. Ceci est du au fait que la tâche planifiée exécutée repose sur le temps écoulé plutôt que sur l'horloge du temps réel.

Le tableau ci-dessous liste et décrit le comportement prévu des tâches planifiées dans ReportCaster pendant l'heure d'été.

Intervalle

Description

Par exemple :

Le planning s'exécute une fois à une heure spécifique ou tous les jours, semaines, mois ou ans.

Le planning s'exécute à cette heure quelque soit le changement d'heure.

Un planning créé à 9h15 sera exécuté à 9h15.

Le planning s'exécute toutes les minutes ou heures dès le début l'heure d'été.

Le planning est avancé d'une heure.

Un planning exécuté toutes les deux heures : 12h00, 2h00, 4h00, etc.

S'exécutera aux heures suivantes : 12h00, 3h00, 5h00, etc.

Ceci se produit parce qu'à 1:59:59, l'horloge est avancée à 3h00.

Le planning s'exécute toutes les minutes ou heures dès la fin de l'heure d'été.

Le planning est retardé d'une heure.

Un planning exécuté toutes les deux heures : 12h00, 2h00, 4h00, etc.

S'exécutera aux heures suivantes : 12h:00, 1h:00, 3h:00, etc.

Ceci se produit parce qu'à 1:59:59, l'horloge est remise à 1h00.


WebFOCUS