CSA : Maintenance et surveillance dans
PPM classique
(Sur site uniquement)

ccppmop1591
Démarrez et arrêtez des services, ouvrez des ports de serveur, désactivez la surveillance IGMP, exécutez un rapport d'intégrité, vérifiez les fichiers journaux, sauvegardez et restaurez votre installation
PPM classique
, compilez les objets de base de données Oracle, définissez la taille des répertoires de fichiers et définissez des restrictions au niveau des balises GEL.
2
Démarrage et arrêt des services
Procédez comme suit :
  1. Connectez-vous à l'outil d'administration du système.
  2. Cliquez sur Accueil, puis sur Tous les services.
  3. Activez la case à cocher à côté de chaque service à démarrer ou à arrêter.
  4. Pour démarrer les services, cliquez sur Démarrer.
  5. Pour arrêter les services, cliquez sur Arrêter.
Ouvrir les ports du serveur
PPM classique
requiert l'ouverture de plusieurs ports réseau pour les communications client-serveur et serveur-serveur. Par défaut, les ports sont souvent fermés ou bloqués par les pare-feux pour des raisons de sécurité. Les ports sélectionnés pendant l'installation ou la configuration doivent être ouverts.
Ouvrez les ports nécessaires en suivant les instructions incluses dans la documentation fournie pour votre système d'exploitation ou votre pare-feu. La liste ci-dessous indique la valeur par défaut, le type et la description de chaque port utilisé dans
PPM classique
.
Sur les systèmes UNIX, les numéros de ports inférieurs à 1024 sont généralement réservés à l'utilisateur root.
Meilleure pratique :
si vous utilisez un pare-feu logiciel, indiquez une exception au niveau de l'exécutable et non au niveau du port. Cela garantit l'ouverture des ports dynamiques alloués pour la multidiffusion. Pour plus d'informations, consultez la section relative aux
ports éphémères
dans la liste suivante.
  • 80 ou 443
    Définit le numéro de port HTTP ou HTTPS utilisé par le service d'application (app)
    PPM classique
    par défaut.
    Type
    : client vers le serveur d'applications
    PPM classique
  • 8090
    (Serveur d'applications Apache Tomcat uniquement) Définit le numéro de port HTTP utilisé par l'outil d'administration du système.
    Type
    : du client au serveur d'applications
    PPM classique
  • 1433 (MS-SQL) ou 1521 (Oracle)
    Définit le numéro de port JDBC utilisé pour la communication avec la base de données
    Type
    : Serveur à serveur de base de données
  • 23791
    (Serveur d'applications Apache Tomcat uniquement) Définit le numéro de port RMI utilisé par le service d'applications (app)
    PPM classique
    .
    Type
    : Serveur au serveur d'applications
    PPM classique
  • 23792
    (Serveur d'applications Apache Tomcat uniquement) Définit le numéro de port RMI utilisé par l'outil d'administration du système.
    Type
    : Serveur au serveur d'applications
    PPM classique
  • 9090
    Définit le numéro du port de multidiffusion utilisé par l'outil d'administration du système.
    Type
    : Serveur au serveur d'applications
    PPM classique
  • 9091
    Définit le numéro de port RMI utilisé par le service de balises.
    Type
    : serveur à serveur
  • Ports éphémères
    Définit la plage de ports éphémères (courte durée). Tous les systèmes d'exploitation spécifient une plage de ports éphémères par défaut. La plage BSD traditionnelle va de 1024 à 4999. Toutefois, l'IANA (Internet Assigned Numbers Authority) suggère d'utiliser une plage allant de 49152 à 65535. Cette plage varie selon les systèmes d'exploitation et il est possible de la désactiver. Vous pouvez utiliser les valeurs de plage de votre choix dans
    PPM classique
    . Toutefois, vous devez activer une plage. Ce port est utilisé principalement pour assurer le fonctionnement de la multidiffusion.
    Type
    : Serveur à serveur
Surveillance IGMP
Pour que le trafic de multidiffusion soit livré correctement avec les commutateurs Ethernet de Cisco Catalyst, désactivez la surveillance IGMP (ou activez la surveillance IGMP et les requêtes IGMP) pour le réseau local virtuel auquel appartiennent les serveurs
PPM classique
. Auparavant, la multidiffusion IP était en grande partie traitée de la même façon que la diffusion IP et les commutateurs Ethernet saturaient le trafic multidiffusion sur toutes les interfaces. Par défaut, les commutateurs de Cisco Catalyst adoptent l'approche inverse et ne saturent pas le trafic multidiffusion sur toutes les interfaces.
Avec la surveillance IGMP, les commutateurs de couche 2 peuvent prendre des décisions intelligentes de transfert multidiffusion en examinant le contenu de chaque en-tête IP 3 de couche de trame. Le commutateur maintient une liste de groupes de multidiffusion pour livrer uniquement des paquets de multidiffusion aux interfaces appartenant à un groupe particulier.
Exécuter les rapports d'intégrité
Les onglets, boutons et options de rapport d'intégrité de l'outil d'administration du système hérités ont été supprimés dans la version 15.3. Reportez-vous à la section Exécution d'un rapport d'intégrité.
Vérification des fichiers journaux
Si un problème survient lors de l'installation, de la mise à niveau ou de l'utilisation du produit, consultez les fichiers journaux afin d'obtenir une explication du problème et de le résoudre. Par défaut,
PPM classique
écrit uniquement les messages d'erreur dans les fichiers journaux. Si vous faites appel au service de support technique de CA dans le cadre de la résolution d'un problème, il se peut que celui-ci vous demande de configurer le système de façon à afficher les messages de débogage détaillés. Par défaut, les fichiers journaux sont stockés dans le répertoire de journaux sous le répertoire d'accueil de
PPM classique
. Chaque serveur a son propre répertoire de journaux. Vous pouvez également sélectionner un autre répertoire de journaux dans l'outil d'administration du système.
Vous pouvez afficher les fichiers journaux à l'aide d'un éditeur de texte. Si vous disposez d'un cluster de serveurs
PPM classique
, les fichiers journaux de chaque serveur concernent uniquement ce serveur. Vous pouvez configurer les journaux pour y inclure davantage de détails ou pour mettre à jour ou supprimer des entrées. Vous pouvez faire en sorte que les modifications que vous apportez au niveau de la configuration des fichiers journaux prennent effet immédiatement. Dans le cas contraire, vous devez redémarrer les services d'applications (app)
PPM classique
et d'arrière-plan (bg)
PPM classique
pour que les modifications prennent effet.
Le tableau ci-après contient la liste des fichiers journaux communs et par défaut. Le nom, le format et le contenu est répertorié pour chaque fichier journal.
Chaque instance clonée d'un service possède ses propres fichiers journaux. Par exemple, des fichiers journaux délimités par un ID correspondent aux services app2, bg3, et autres. Les instances app et bg initiales ne disposent pas d'un ID.
Nom du fichier journal
Format
Contenu
admin.log
Texte brut
Enregistrement des activités d'administration. Ces activités sont gérées par la commande
admin
ou par une opération CSA équivalente.
app{id}-access-{date}.log
Texte brut
Activité de session (demandes HTTP/HTTPS) pour le service de premier plan.
app{id}-bootstrap-ca.log
Texte brut
Activités d'amorçage du composant ODF, généralement pendant une opération de mise à niveau et d'application d'un patch.
app{id}-ca.log
Texte brut
Journal principal pour toutes les activités réalisées au niveau du service de premier plan.
app{id}-dwh.log
Texte brut
Activité spécifique de l'entrepôt de données du service de premier plan
app{id}-process-engine.log
Texte brut
Evénements enregistrés par l'outil de surveillance du moteur de processus dans le service de premier plan.
app{id}-system.log
Texte brut
Sortie de niveau système écrite directement dans la console (STDOUT) du service de premier plan. Cette sortie prend généralement la forme de messages du système d'exploitation ou de démarrage du service.
beacon-system.log
Texte brut
Sortie de niveau système écrite directement dans la console (STDOUT) du service de balises. Cette sortie prend généralement la forme de messages du système d'exploitation ou de démarrage du service.
bg{id}-bootstrap-ca.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
bg{id}-ca.log
Texte brut
Journal principal pour toutes les activités réalisées au niveau du service d'arrière-plan.
bg{id}-dwh.log
Texte brut
Activité spécifique de l'entrepôt de données du service d'arrière-plan
bg{id}-process-engine.log
Texte brut
Evénements enregistrés par la fonctionnalité de surveillance du moteur de processus du service d'arrière-plan
bg{id}-system.log
Texte brut
Sortie de niveau système écrite directement dans la console (STDOUT) du service d'arrière-plan. Cette sortie prend généralement la forme de messages du système d'exploitation ou de démarrage du service.
completion.log
Propriétés
Enregistrement des étapes d'installation ou de mise à niveau effectuées pour chaque composant. Ne modifiez pas ce journal sans l'aide du service de support de CA.
dbtools-bootstrap-ca.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
dbtools-ca.log
Texte brut
Activité en provenance de l'outil DBTools. L'outil DBTools permet de modifier les entités et les données de base de données lors d'un processus de mise à niveau ou d'application d'un patch.
dbtools-dwh.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
dbtools-process-engine.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
nsa-access-{date}.log
Texte brut
Activité de session (demandes HTTP/HTTPS) pour le service d'administration système.
nsa-bootstrap-ca.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
nsa-ca.log
Texte brut
Journal principal pour toutes les activités réalisées au niveau du service d'administration système.
nsa-dwh.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
nsa-process-engine.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
nsa-system.log
Texte brut
Sortie de niveau système écrite directement dans la console (STDOUT) du service d'administration système. Cette sortie prend généralement la forme de messages du système d'exploitation ou de démarrage du service.
odf-bootstrap-bootstrap-ca.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
odf-bootstrap-ca.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
odf-bootstrap-dwh.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
odf-bootstrap-process-engine.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
upgrade-bootstrap-ca.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
upgrade-ca.log
Texte brut
Messages provenant de scripts de mise à niveau
PPM classique
spécifiques exécutés pendant une mise à niveau.
update-dwh.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
upgrade-process-engine.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
xogAdmin-bootstrap-ca.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
xogAdmin-ca.log
Texte brut
Activité du client d'administration XOG. Le client d'administration XOG permet d'insérer ou de modifier des données lors d'un processus de mise à niveau ou d'application d'un patch.
xogAdmin-dwh.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
xogAdmin-process-engine.log
Vide
Ce fichier est généré automatiquement, mais il est généralement vide.
Modification de la configuration de l'enregistreur
Les fichiers journaux principaux sont ceux de type
ca
. La plupart des informations que le produit enregistre sont stockées dans l'un de ces fichiers. Ces informations incluent les erreurs système ainsi que les messages d'information tels que les messages de débogage. Vous pouvez configurer les messages du journal qui s'affichent dans les fichiers journaux de CA.
Les messages des journaux incluent les deux attributs ci-dessous :
  • Catégorie
    Indique l'emplacement, dans le produit, à partir duquel le message a été enregistré.
  • Niveau
    Indique la sévérité du message.
Vous pouvez ajuster la configuration de l'enregistreur pour filtrer les messages de journal en fonction de leur catégorie et de leur niveau. Le produit signale tous les messages qui appartiennent à la catégorie com.ca et dont le niveau est Erreur ou un niveau supérieur (Irrécupérable). Vous pouvez ajouter des catégories supplémentaires avec des informations ou ajouter des niveaux de débogage pour obtenir davantage d'informations au moment de la résolution d'un problème.
La désactivation de l'ensemble des services sauf celui configuré pour le débogage est utile lorsque plusieurs services d'arrière-plan (bg)
PPM classique
sont en cours d'exécution et que vous avez activé le débogage pour résoudre un problème au niveau d'un service d'arrière-plan (bg)
PPM classique
. Cette opération permet en effet de soumettre l'ensemble des jobs ou des processus à ce service d'arrière-plan (bg)
PPM classique
afin de générer les messages de débogage souhaités. Redémarrez le service d'arrière-plan (bg)
PPM classique
pour que les modifications prennent effet, puis consultez le fichier journal (bg-ca.log).
Procédez comme suit :
  1. Connectez-vous à l'outil d'administration du système.
  2. Cliquez sur Accueil, puis sur Serveurs.
  3. Pour modifier les informations du journal, cliquez sur l'icône Propriétés correspondant au serveur.
  4. Cliquez sur l'onglet Logs.
  5. Cliquez sur le sous-onglet Modifier la configuration.
  6. Dans la section Propriétés, remplissez les champs suivants :
    • Détecter automatiquement les changements de configuration du journal
      Indique que les modifications apportées à la configuration du journal doivent prendre effet immédiatement, lorsque vous activez cette case à cocher. Cette option s'applique aux services d'arrière-plan (bg)
      PPM classique
      et d'applications (app)
      PPM classique
      en cours d'exécution sur le serveur Apache Tomcat.
      Si vous sélectionnez cette option, vous devez redémarrer les services concernés pour que la modification prenne effet.
    • Autre répertoire de journaux
      Définit l'autre répertoire de journaux pour ce serveur. Ce chemin d'accès doit être un chemin d'accès absolu valide menant vers un répertoire présent sur le serveur. Par exemple : /niku/logs (Unix) ou E:\logs (Windows).
    • Seuil de suivi par défaut (en secondes)
      Spécifie le seuil de base sur lequel les informations de suivi sont écrites pour une demande donnée. Cette valeur remplace les niveaux de catégorie logger.xml.
  7. Dans la section Journalisation système, remplissez les champs suivants :
    • Nombre maximum de journaux du système (par service)
      Indique le nombre de fichiers journaux du système à conserver pour chaque service. La modification de cette valeur requiert le redémarrage des services. Par défaut, la valeur est définie sur 5.
    • Taille maximum de chaque journal du système
      Indique la taille, en mégaoctets, des fichiers journaux du système pour chaque service. La modification de cette valeur requiert le redémarrage des services. La valeur par défaut est de 5 Mo.
  8. Dans la section Journalisation Kettle, remplissez le champ suivant :
    • Niveau de journalisation Kettle
      Indique le niveau d'activité du journal à afficher lors de l'exécution des jobs de chargement de l'entrepôt de données et de chargement des droits d'accès à l'entrepôt de données. Les données du journal sont stockées dans les journaux de l'entrepôt de données dans l'outil d'administration du système.
      Valeurs
      : Rien, Erreur, Minimum, Simple, Détaillé ou Ligne.
  9. Dans la section Journalisation de la persistance du moteur de processus, remplissez le champ suivant :
    • Niveau de journalisation de la persistance du moteur de processus
      Indique le niveau d'activité du journal que vous affichez si vous incluez la balise <gel:log> dans le script GEL de processus. Sélectionnez l'une des valeurs suivantes pour configurer le type de messages affichés dans la page Accueil, Organiseur, Processus lancés :
      • Erreur. Cette valeur par défaut indique que seuls les messages <gel:log level=ERROR> s’affichent sous forme de messages dans l’interface utilisateur. Nous recommandons ce paramètre pour limiter la taille de la table BPM_ERRORS.
      • Avertir. Cette valeur indique que les messages <gel:log level=ERROR or gel:log level=WARN> s’affichent sous forme de messages dans l’interface utilisateur
      • Infos. Cette valeur indique que tous les messages, y compris sans niveau de journalisation, apparaissent sous forme de messages dans l’interface utilisateur.
  10. Dans la section Seuils de suivi, cliquez sur Ajouter un seuil et remplissez les champs suivants :
    • Seuil (en secondes)
      Spécifie le nombre de secondes passées lesquelles les actions identifiées par les modèles d'action sont suivies. Une valeur de -1 signifie qu'aucun seuil n'est défini pour les actions données. Cette valeur sert à désactiver les seuils pour les actions qui prennent du temps.
    • Modèles
      Identifie les actions suivies en cas de dépassement du seuil. Entrez le modèle en séparant les différents éléments au moyen d'une virgule, par exemple : webRequest/npt.overview, xogRequest/XOG::project::read, ou serviceRequest/*.
  11. Dans la section Catégories, remplissez les champs suivants :
    • Nom/Autre nom
      Définit la catégorie pour l'ajout ou la modification. Faites votre choix dans la liste déroulante. Pour activer une catégorie qui ne figure pas dans cette liste, entrez-la dans le champ de texte Autre nom.
    • Suffixe
      Dirige la sortie de journalisation vers une destination différente. Pour diriger une catégorie vers un fichier distinct, ajoutez un suffixe STDOUT avec un nom de fichier unique et associez la catégorie au nouveau suffixe.
    • Priorité
      Définit le niveau de débogage. Plus le niveau est élevé, plus la priorité est haute.
      Valeurs
      :
      • Irrécupérable. Indique qu'un service critique n'est pas en cours d'exécution.
      • Erreur. Signale la présence d'un problème susceptible de limiter les fonctions du système.
      • Avertir. Indique que
        PPM classique
        a rencontré un problème, mais continue de s'exécuter.
      • Infos. Indique le statut du système (démarrage du service, par exemple) et parfois un problème.
      • Déboguer. Affiche des informations détaillées vous permettant, à vous ou au service de support technique de CA, de résoudre un problème.
      • Trace. Affiche des informations techniques détaillées. Ce niveau génère de grands volumes de données. Utilisez cette valeur uniquement lorsque le service de support technique de CA vous le demande.
      • Tout. Affiche tous les messages.
    • Additif
      Indique si les nouveaux messages sont ajoutés aux journaux. Pour ajouter des messages, activez cette case à cocher. Si cette case à cocher est vide, le contenu des journaux est de temps en temps remplacé par de nouvelles informations.
  12. Enregistrez les modifications.
  13. Redémarrez les services affectés.
La journalisation peut réduire les performances du système, notamment lorsque son niveau de priorité est élevé (Déboguer ou Trace). Activez la journalisation supplémentaire uniquement lorsque cela est nécessaire ou lorsque vous y êtes invité par le service de support technique de CA. Désactivez la journalisation supplémentaire dès que vous n'en avez plus besoin.
Journalisation propre à l'utilisateur
Vous pouvez activer certaines catégories de journalisation pour des utilisateurs spécifiques. Pour activer la journalisation pour un utilisateur spécifique, ajoutez le nom d'utilisateur à la fin de la catégorie de journalisation standard. Par exemple,
trace.server.user.jsmith
permet de journaliser les performances côté serveur pour l'utilisateur jsmith. Le mot clé user indique que le dernier segment de la catégorie est le nom d'utilisateur. Le nom d'utilisateur est utilisé comme filtre pour la journalisation d'événements sous la catégorie, trace.server, dans notre exemple. Les modifications apportées aux paramètres de journalisation SQL pour un utilisateur spécifique prennent effet uniquement à la connexion de l'utilisateur. L'utilisateur doit donc se reconnecter après chaque modification qu'il apporte au niveau de la configuration de la journalisation pour un utilisateur spécifique.
Suivi d'actions
Procédez à un suivi d'actions (tâche préalablement connue sous le nom de suivi SQL) uniquement à la demande et avec l'assistance du service de support technique de
PPM classique
. Effectuez cette opération uniquement pendant une courte durée et dans le but de résoudre un problème au niveau d'actions particulières. Le suivi d'actions doit alors être désactivé.
Vidéo : Activation de la trace SQL
La vidéo ci-dessous est fournie par CA Technologies.

Pour visionner cette vidéo en mode plein écran, cliquez sur le logo YouTube à droite de l'icône Paramètres au bas de la vidéo.
Sauvegarde d'une installation de
PPM classique
Lorsque vous envisagez d'apporter d'importantes modifications au système de production, vous devez préalablement sauvegarder le système actuel pour pouvoir le restaurer. Utilisez le répertoire de sauvegarde pour le stockage de la sauvegarde de la base de données.
Procédez comme suit :
  1. Connectez-vous à l'outil d'administration du système et vérifiez que tous les services sont arrêtés à l'exception de la base de données. Si le service de base de données n'est pas installé, ignorez cette étape.
  2. Ouvrez une ligne de commande sur le serveur d'applications de l'outil d'administration du système et exécutez la commande suivante :
    admin backup
  3. Pour accepter les valeurs par défaut, appuyez sur Entrée.
    La commande de sauvegarde copie le répertoire d'installation de
    PPM classique
    dans un répertoire de sauvegarde.
Sauvegarde d'une base de données Oracle
Procédez comme suit :
  1. A partir de la ligne de commande du serveur de base de données, utilisez l'utilitaire d'exportation de la base de données Oracle
    expdp
    .
    Pour connaître la procédure détaillée à suivre pour utiliser cet utilitaire, reportez-vous à la documentation Oracle. L'exemple suivant porte sur une commande d'exportation :
    expdp clarity/password FULL=y DIRECTORY=data_pump_dir DUMPFILE=clarity.dmp LOGFILE=myclarityexp.log SCHEMAS=clarity
  2. Copiez les fichiers .dmp et init<SID>.ora dans le répertoire de sauvegarde créé par la commande de sauvegarde.
Sauvegarde d'une base de données Microsoft SQL Server
Sauvegardez une base de données Microsoft SQL à l'aide de l'outil SQL Server Enterprise Manager. Pour plus d'informations, consultez la documentation Microsoft.
Restauration d'une installation de
PPM classique
L'opération de restauration d'une installation utilise la sauvegarde du système de fichiers et de la base de données réalisée avant le lancement de la mise à niveau.
Meilleure pratique
: restaurez une installation de
PPM classique
uniquement après avoir épuisé toutes les autres possibilités.
Procédez comme suit :
  1. A partir de la ligne de commande, arrêtez tous les services.
    service stop all
  2. Restaurez la base de données à l'aide de vos outils de gestion de base de données standard et de la sauvegarde réalisée avant le lancement de la mise à niveau.
  3. Restaurez
    PPM classique
    à l'aide du script de restauration stocké dans le répertoire de sauvegarde :
    (
    Windows
    )
    restore.bat
    (
    UNIX
    )
    restore.sh
    Reportez-vous à la section
    Sauvegarde d'une installation de
    PPM classique
    .
  4. Lorsque vous avez terminé, redémarrez tous les services :
    service start all
  5. (Facultatif) Réinstallez les rapports plus anciens.
    Reportez-vous à la section
    Installation et mise à niveau
    de la version correspondant aux rapports que vous avez installés.
Collecte et analyse des objets de la base de données Oracle existante
Procédez à la collecte et à l'analyse de la base de données dans les circonstances suivantes :
  • Lorsque vous exportez la base de données, puis que vous l'importez dans un autre serveur pour la réalisation de mises à niveau de test
  • Lorsque vous réorganisez la base de données sur votre serveur de production
La compilation et l'analyse garantissent la validité de l'ensemble des objets de base de données. La mise à niveau risque d'échouer si vous ne compilez pas les objets de la base de données avant de mettre à niveau le schéma de
PPM classique
.
Procédez comme suit :
Sur le serveur d'applications de l'outil d'administration du système, ouvrez une ligne de commande, puis exécutez les commandes suivantes :
admin db compile admin db analyze
Les objets de la base de données sont collectés et analysés.
Définir la taille du répertoire de fichiers
Dans l'outil d'administration du système, vous pouvez spécifier une limite de taille de stockage des fichiers au niveau du répertoire. Si une limite est spécifiée, un nouveau répertoire frère est automatiquement créé pour stocker les fichiers ultérieurs une fois que la limite est atteinte. La limite de taille s'applique également aux documents que vous importez dans
PPM classique
à l'aide de l'outil XML Open Gateway (XOG).
Le fait de définir la limite de taille du répertoire n'affecte pas la taille des dossiers pré-existants.
Procédez comme suit :
  1. Connectez-vous à l'outil d'administration du système.
  2. Ouvrez la page d'accueil et cliquez sur Serveurs.
  3. Cliquez sur un nom de serveur.
  4. Cliquez sur le sous-onglet Documents et Recherche.
  5. Dans la section Options du gestionnaire de documents, dans le champ Taille limite du répertoire de stockage des fichiers, spécifiez la taille limite de stockage des fichiers pour un répertoire.
Définition de restrictions au niveau des balises GEL
Pour contrôler les restrictions liées aux balises GEL, utilisez les commandes suivantes :
admin general restrict-gel-tags
Définit la valeur de la propriété gelTagRestriction sur
Activé(e)
.
admin general allow-gel-tags
Définit la valeur de la propriété gelTagRestriction sur
Désactivé(e)
.
La propriété gelTagRestriction est référencée pour déterminer si des balises GEL sont limitées. La propriété est indiquée dans l'élément system, qui est facultatif.
Utilisez les valeurs
Activé(e)
ou
Désactivé(e)
pour définir les limites de balises GEL pour l'environnement. Les valeurs autres que
Désactivé(e)
activent la restriction des balises GEL. Les restrictions liées aux balises GEL sont désactivées par défaut.
La modification des restrictions liées aux balises GEL requiert le redémarrage des services app et bg.
Exemples
Fichier Properties.xml sans restriction au niveau des balises GEL :
<system online="true" multiCurrency="false" licenseTypes="old" singleTenantMode="true"/>
<system online="true" multiCurrency="false" licenseTypes="old" singleTenantMode="true" gelTagRestriction="off"/>
Fichier Properties.xml avec des restrictions au niveau des balises GEL :
<system online="true" multiCurrency="false" licenseTypes="old" singleTenantMode="false" gelTagRestriction="on"/>