Règles de publication¶
Vous pouvez définir plusieurs règles de publication pour un même rapport généré à partir d’une tâche planifiée. Les protocoles de publication disponibles sont les suivants:
- Local: pour publier les rapports sur le serveur de reporting.
- CIFS: pour publier les rapports sur un répertoire Windows partagé.
- FTP: pour publier les rapports sur un serveur FTP.
- SFTP: pour publier les rapports sur un autre serveur Linux/Unix en utilisant SSH.
- SMTP: pour publier les rapports par e-mail.
- DropBox: pour publier les rapports sur un compte DropBox.
Les règles de publication sont définies dans le menu:
Liste des règles¶

Description des colonnes:
Column | Description |
---|---|
Name | Nom de la règle de publication |
Protocol | Protocole utilisé pour la publication du rapport |
Global | Une règle globale est appliquée pour chacun des rapports générés avec Centreon BI. Une règle non globale doit être liée à la tâche planifiée afin que sa prise en compte soit effective |
Description | Description de la règle de publication |
Options | Nombre de duplications si l’option “Duplicate” est selectionnée dans le menu “more actions” |
La règle de publication par défaut ne peut être supprimée ou modifiée. Le protocole utilisé dans cette règle doit être configuré de telle sorte que les rapports soient accessibles depuis le menu: Reporting > Business Intelligence > Archives
Ajout / modification¶
Vous pouvez ajouter ou éditer des règles de publication. Les différents protocoles ont des paramètres communs et d’autres spécifiques.
Description des paramètres communs:
Column | Description |
---|---|
Name | Nom de la règle de publication |
Protocol | Protocole utilisé pour la publication du rapport |
Global | Une règle globale est appliquée pour chacun des rapports générés avec Centreon BI. Une règle non globale doit être liée à la tâche planifiée afin que sa prise en compte soit effective |
Description | Description de la règle de publication |
Root directory | répertoire parent de stockage du rapport |
Sub directory | Dans le but d’organiser la génération de rapports, un sous répértoire peut être généré en se basant sur des variables initialisées au moment de la publication. Le tableau suiavnt décrit les différentes variables pouvant être utilisées dans ce champs. |
Variables pouvant êtes utilisées dans la définition du sous répértoire:
Variable | Description |
---|---|
@DAY@ | jour de mois de la publication du rapport |
@MONTH@ | mois de l’année de la publication du rapport |
@YEAR@ | année de publication du rapport |
@PUBLICATIONDATE@ | date de publication du rapport. Format: « AAAAMMJJ » |
@PUBLICATIONDATETIME@ | date et heure de publication du rapport. Format : « AAAAMMJJHi » (« H » représente l’heure et « i » les minutes) |
@JOBNAME@ | nom de la tâche planifiée |
@REPORTMODELNAME@ | nom du modèle de rapport |
Exemple de sous repértoire:
@REPORTMODELNAME@/JOBNAME@/@PUBLICATIONDATE@
Cas de la publication par mail (SMTP)¶
La publication par mail est spécifique car elle est corrélée au ACL défini dans Centreon BI. L’utilisateur recevra un mail pour un job dans le cas suivant :
Cas 1 - Utilisateur = Admin
- L’utilisateur est dans au moins un groupe de contacts associé à la règle de publication
- L’utilisateur est un administrateur
Cas 2 - Utilisateur ∈ Groupe(s) de contacts ∈ Access Group(s) ∈ ACL Rule(s)
- L’utilisateur est dans au moins un groupe de contacts associé à la règle de publication
- Le(s) groupe(s) de contacts de l’utilisateur est(sont) dans un ou plusieurs groupe d’accès, ce(s) groupe(s) est(sont) associés à une ou plusieurs règle(s) d’ACL, associée(s) au moins 1 fois au job en question, que ce soit par le groupe de job ou directement par le job
Cas 3 - Utilisateur ∈ Access Group(s) ∈ ACL Rule(s)
- L’utilisateur est dans au moins un groupe de contacts associé à la règle de publication
- L’utilisateur est directement dans un ou plusieurs groupe d’accès, ce(s) groupe(s) est(sont) associé(s) à une ou plusieurs règle(s) d’ACL, associée(s) au moins 1 fois au job en question, que ce soit par le groupe de job ou directement par le job
Precision complémentaire
Si un utilisateur appartient à plusieurs règles d’ACL, c’est la réunion de tous qui décide si le rapport est envoyé ou non. En d’autre terme, si au moins un chemin existe entre le job et l’utilisateur, l’utilisateur recevra le mail.