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 MBI. 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 MBI. 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 suivant 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)¶

Il est possible de spécifier une taille maximum à ne pas dépasser pour la pièce jointei grâce au paramètre “Maximum report size”. Si la pièce jointe dépasse la taille paramétrée, un lien de téléchargement est fourni dans le mail.

La publication par mail est spécifique car elle est corrélée aux ACLs définis pour Centreon MBI. Pour qu’un utilisateur non-admin reçoive ou visualise les rapports et/ou des tâches planifiées, vous devez commencer par configurer une règle d’accès. Le fonctionnement des ACL pour Centreon MBI est expliqué ici : Gestion des accès (ACL).

Les règles de gestion s’appliquant à la publication des rapports par mail sont les suivantes :

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.