Avant de configurer les services DIVAnet, reportez-vous au Chapitre 2 pour une description des services DIVAnet et de leur interaction avec DIVArchive et entre eux.
La configuration du service ClientAdapter implique la configuration du mode de connexion des clients à DIVAnet. Elle concerne également la configuration du mode de connexion de DIVAnet à DIVArchive.
Un site DIVAnet est défini comme un système DIVArchive et un ou plusieurs services DIVAnet (ManagerAdapter, ClientAdapter, DbSync). Un nom unique est affecté à chaque site. Les noms de site doivent être configurés dans la base de données DIVAnet (à l'aide de l'utilitaire addSites) avant la configuration de ClientAdapter. Vous devez créer des noms de site faciles à lire qui reflètent l'emplacement physique ou la fonction du site. Ces noms de site seront utilisés sur chaque site.
Remarque :
Les noms de site tiennent compte de la casse.DIVAnet permet la configuration des ports de socket que les applications API client utilisent pour se connecter à DIVAnet. Le service ClientAdapter permet de configurer plusieurs ports API. Chaque port API est configuré à l'aide d'un des deux modes : Direct ou MultiDiva. Un profil de workflow peut être affecté à chaque port.
Mode Direct : Dans ce mode, une connexion API entrante est routée directement vers un système DIVArchive sans autre traitement. Le site particulier vers lequel DIVAnet effectue le routage est configuré dans le ClientAdapter sur une base par port. Cette fonctionnalité permet à des clients locaux de se connecter à un système DIVArchive distant comme s'il était local. Le site DIVA vers lequel les messages sont routés doit être configuré dans la section DivaManagers du fichier de configuration de ClientAdapter. Notez également qu'un site peut être désigné comme opérationnel en mode Direct uniquement (pour plus d'informations, voir Configuration du nom de site de DIVArchive).
Les demandes en mode Direct ne seront pas affichées dans DIVAnetUI et elles peuvent uniquement être surveillées sur le site DIVA où elles sont routées.
Certains workflows DIVAnet ne requièrent pas de base de données DIVAnet, d'interface utilisateur DIVAnet ou de traitement en mode MultiDiva. Pour configurer un service ClientAdapter pour le mode Direct uniquement, assurez-vous que seuls des ports en mode Direct sont définis et qu'aucun WebServicePort n'est défini. Cela désactive l'utilisation de l'interface utilisateur DIVAnet. Vous trouverez un exemple de configuration dans le fichier suivant :
Program/conf/divanet/templates/ClientAdapterConfig.xml.ProxyOnly.ini
Mode MultiDiva : DIVAnet fait apparaître tous les sites DIVA sous la forme d'un seul grand système d'archivage. Dans ce mode, une demande API entrante est routée directement vers DIVAnet. DIVAnet satisfait la demande de haut niveau en consultant d'autres systèmes DIVArchive, le cas échéant. Cette fonctionnalité permet (par exemple) la copie de contenu d'un site vers un autre, la restauration de contenu sans connaissance du site qui le contient et de nouvelles tentatives sur d'autres sites quand le contenu du premier site est inaccessible. En outre, elle offre une vue globale du contenu de tous les sites.
La progression d'une demande exécutée en mode MultiDiva peut être surveillée dans l'interface utilisateur de DIVAnet. DIVAnet crée ses propres événements au niveau demande pour informer l'utilisateur sur :
le mode de traitement de la demande par DIVAnet,
les demandes qui sont effectuées sur les sites DIVA,
Les erreurs ou avertissements éventuels détectés lors des opérations.
L'application DIVAnetUI et l'outil DivanetAdmin assurent les connexions Web au service ClientAdapter. Vous pouvez configurer le port disponible pour ces connexions dans le fichier de configuration de ClientAdapter.
Un profil de workflow est un ensemble de paramètres qui définit comment les demandes entrantes seront traitées par DIVAnet. Les profils de workflow permettent de regrouper logiquement les utilisateurs et systèmes qui utilisent DIVAnet de manière similaire.
DIVAnet permet la création d'un ou de plusieurs profils dans le service ClientAdapter. Ces profils contiennent des paramètres qui sont requis par un ensemble particulier d'utilisateurs ou d'applications. Les profils de workflow sont affectés selon l'emplacement de réception de la demande (port de réception, voir la section suivante).
Dans le profil de workflow, vous pouvez personnaliser des informations telles que la liste des messages valides acceptés, les paramètres de renouvellement de tentative, les méthodes de copie de site à site ainsi que d'autres attributs.
Dans la section des ports API, un nom de profil de workflow peut être affecté à chaque port défini. Les demandes reçues sur le port API sont traitées à l'aide du profil de workflow affecté. Si aucun nom n'est défini, le profil par défaut (default) est utilisé. Les ports en mode MultiDiva peuvent avoir des noms de profil de workflow qui font référence à une section de corps de profil de workflow située plus bas dans la configuration de ClientAdapter.
Si le port est en mode Direct, le nom du profil de workflow est un libellé uniquement ; il n'y a pas de corps de profil de workflow pour les connexions en mode Direct. Toutefois, ce nom peut s'avérer utile dans les règles d'accès (voir la section suivante).
En mode MultiDiva comme en mode Direct, en l'absence de nom, la connexion utilise le profil de workflow nommé default. Chaque section de corps de profil de workflow est configurée dans le fichier ClientAdapterConfig.xml. Les sections suivantes répertorient les types d'informations configurables dans chaque profil de workflow.
Certaines commandes dans DIVAnet peuvent faire l'objet de nouvelles tentatives (par exemple Restore, Copy et Delete). Les paramètres pour les nouvelles tentatives, notamment la durée et l'intervalle entre chacune, sont configurables ici. Beaucoup de commandes ont leurs propres paramètres pour les nouvelles tentatives (par exemple, ceux de la commande Copy sont totalement différents de ceux de la commande Delete). Les délais d'expiration des messages et les limites de connexion peuvent également être configurés dans le profil de workflow. Les paramètres de nouvelles tentatives et d'expiration sont spécifiques du profil de workflow dans lequel ils sont définis.
Dans chaque profil de workflow, une liste de messages est configurée. Elle représente les messages API valides qui peuvent être acceptés par le profil de workflow considéré. Par exemple, si le message Archive ne figure pas dans la liste, les messages d'archivage ne peuvent pas être envoyés à DIVAnet via l'API (au moins pour ce profil de workflow).
DIVAnet offre un moyen flexible de configurer le mode d'exécution des transferts de site à site. Dans chaque profil de workflow, vous configurez des paramètres de mappage pour chaque chemin de transfert (un chemin pour les transferts du site A au site B, un autre pour les transferts du site A au site C, etc.). Ce tableau est consulté quand des commandes Copy, Restore ou Partial File Restore sont reçues.
Il est utile de définir des mappages de site à site dans le profil de workflow default car d'autres profils de workflow peuvent charger leurs mappages à partir de ce profil par défaut. Cela permet de réduire le nombre de mappages dans la configuration.
Paramètres : DIVAnet prend en charge plusieurs types de transfert. La section Méthodes de transfert de site à site décrit les différents types. RestoreAndArchive est le type de transfert par défaut. RestoreAndMonitor requiert Drop Folder Monitor (DFM) ou une autre application exécutant une fonction similaire. D'autres paramètres incluent :
Source/destination : emplacement de stockage commun pour le transfert (accessible à la fois par les sites source et cible).
Default Media : média par défaut à utiliser lors de l'archivage sur le site cible. Le média par défaut peut être utilisé lorsqu'une copie temporaire a été initiée (par une opération de restauration, par exemple) ou quand un utilisateur a lancé une copie et indiqué que DIVAnet doit sélectionner le média.
Options : paramètres à utiliser dans les demandes de restauration, d'archivage et de transfert.
FilePathRoot : répertoire parent pour le stockage du contenu.
Directory Location : DIVAnet crée pour stocker les fichiers un chemin de répertoire relatif à la source/destination choisie. Ce chemin relatif est de la forme suivante :
{FilePathRoot} / {Media} / {UniqueDirName} /
Le paramètre FilePathRoot est spécifié dans les mappages de site à site. Le média n'est intégré au chemin que si l'option AppendMediaToPath est définie sur true dans les mappages (la valeur par défaut est false). Enfin, DIVAnet génère un nom de répertoire unique qui est inclus dans le chemin. Ce nom unique comprend au début le nom du site qui a lancé la demande.
Il est possible de modifier et de recharger les paramètres spécifiés dans le profil de workflow sans redémarrer le service ClientAdapter. Le redémarrage du service ClientAdapter doit être évité car il arrête toutes les demandes en cours d'exécution et ferme toutes les connexions client. Le rechargement peut être effectué dans l'outil DivanetAdmin (pour plus d'informations sur DivanetAdmin, reportez-vous aux sections ci-après).
Remarque :
Le rechargement met à jour tous les profils de workflow, mais aussi toutes les règles d'accès.Les tableaux suivants décrivent les paramètres pouvant figurer dans un fichier de configuration de ClientAdapter. Le fichier se présente au format XML. La colonne de valeur par défaut indique la valeur que le paramètre aura s'il n'est pas spécifié dans le fichier de configuration. Elle indique également si le paramètre est obligatoire ou facultatif.
Pour créer un nouveau fichier de configuration :
Accédez au répertoire de base DIVAnet (où DIVAnet est installé).
Accédez au dossier Program/conf/divanet/templates.
Copiez le fichier ClientAdapterConfig.xml.ini dans le répertoire parent, sans l'extension .ini (../ClientAdapterConfig.xml).
En utilisant les tableaux ci-dessous comme référence, modifiez les paramètres dans le fichier ClientAdapterConfig.xml pour configurer le service ClientAdapter.
Reportez-vous à l'Annexe A pour examiner un exemple de fichier de configuration de ClientAdapter.
Tableau 4-1 Paramètres de niveau supérieur de ClientAdapter
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom de site du site DIVAnet local. |
Aucune (obligatoire) |
|
|
Dossier dans lequel les fichiers journaux seront générés. |
Répertoire |
|
|
Niveau de détail auquel la journalisation du fichier de suivi intervient (ERROR, WARN, INFO, DEBUG, TRACE). |
INFO |
|
|
Nombre de secondes d'attente pour qu'un objet soit synchronisé. |
60 |
|
|
Nombre de threads actifs dans les pools de threads DIVAnet. Utilisé pour le réglage des configurations de grande envergure. Dans le doute, ne définissez pas cette valeur. |
25 |
|
|
Arrêter toutes les demandes DIVAnet incomplètes au démarrage de DIVAnet, même si la demande est terminée au niveau DIVArchive. Les nouvelles demandes ne sont pas affectées. |
false |
|
|
Nombre total maximal de connexions API autorisées. |
200 |
|
|
Nombre maximal de demandes DIVAnet en attente ou en cours d'exécution pouvant être acceptées dans le système. Quand la limite est atteinte, DIVAnet commence à rejeter les nouvelles demandes. |
5000 |
|
|
Fréquence à laquelle les sites sont interrogés. Ne modifiez ce paramètre qu'en cas de lenteur de réseaux et/ou de système. |
4000 |
|
|
Port utilisé pour l'envoi de messages de gestion au service ClientAdapter. |
Aucune (facultatif) |
|
|
True si SSL doit être utilisé pour les demandes de service Web. |
true |
|
|
Profil de workflow à utiliser pour les demandes Web (notamment DivanetUI). |
Le profil default |
|
|
Nom du fichier des règles d'accès. Ce nom de fichier est lié au répertoire dans lequel le fichier de configuration de ClientAdapter est stocké. |
Aucune (en l'absence de configuration, aucune règle d'accès n'est appliquée). |
Dans la balise ApiPorts, plusieurs définitions ApiPort peuvent s'afficher. Le Tableau 4-2 présente les paramètres pouvant figurer dans une définition ApiPort.
Tableau 4-2 Paramètres de ports API
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Socket de port sur lequel se fait l'écoute. |
Aucune (obligatoire) |
|
|
Mode de routage des demandes (Direct ou MultiDiva).
|
MultiDiva |
|
|
Site vers lequel router si le mode Direct est utilisé. Les sites sont définis dans la section |
Aucune (obligatoire pour le mode Direct) |
|
|
Adresse locale utilisée pour l'envoi à ce Manager (en général, la carte réseau à utiliser). Dans le doute, ne spécifiez pas ce paramètre. |
Aucune (facultatif) |
|
|
Nom du profil de workflow pour les demandes passant par ce port (voir la section Profil de workflow). S'il n'est pas indiqué, le profil de workflow default sera utilisé. |
default (profil par défaut en mode MultiDiva). |
Dans la balise DivaManagers, plusieurs définitions DivaManager peuvent apparaître. Le Tableau 4-3 décrit les paramètres qui peuvent figurer dans une définition DivaManager.
Tableau 4-3 Paramètres de configuration de DivaManagers
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom du site où le Manager est installé. Le nom du site indiqué doit correspondre à ce qui a été configuré dans la base de données DIVAnet ainsi que dans le fichier |
Aucune (obligatoire) |
|
|
Mode de connexion au Manager (valeurs valides : Socket, WebService). |
Socket |
|
|
Adresse réseau (IP ou nom internet) du Manager. |
localhost |
|
|
Port où les clients se connectent au Manager. |
Aucune (obligatoire) |
|
|
Adresse locale utilisée pour l'envoi à ce Manager (en général, la carte réseau à utiliser). Dans le doute, ne spécifiez pas ce paramètre. |
Aucune (facultatif) |
|
|
Port local utilisé. Dans le doute, ne spécifiez pas ce paramètre. |
0 |
|
|
URL du ManagerAdapter si ConnectionType est défini sur WebService; required. |
Aucune (facultatif) |
|
|
DIVAnet attend que le nombre total de demandes du Manager tombe sous cette limite avant d'envoyer de nouvelles demandes. Cette valeur est utilisée quand ConnectionType est défini sur Socket. Quand le Manager dépasse le nombre de demandes en cours d'exécution, quelle que soit la source (DIVAnet, SPM, connexion API locale), DIVAnet n'envoie plus aucune demande jusqu'à ce le nombre de demandes en cours d'exécution sur le Manager soit inférieur à cette valeur de seuil. |
400 |
|
|
DIVAnet attend que le nombre de demandes qu'il a lui-même en cours d'exécution sur un Manager tombe sous cette limite avant d'envoyer de nouvelles demandes. Quand le Manager dépasse le nombre de demandes en cours d'exécution envoyées uniquement depuis DIVAnet, DIVAnet n'envoie plus aucune demande jusqu'à ce le nombre de demandes en cours d'exécution sur le Manager envoyées uniquement depuis DIVAnet soit inférieur à cette valeur de seuil. La valeur zéro a pour effet de mettre tous les messages en file d'attente interne dans DIVAnet. La valeur -1 indique qu'il n'y a aucune limite. |
100 |
Le Tableau 4-4 présente les paramètres pouvant figurer dans la section DivanetDatabase.
Tableau 4-4 Paramètres DIVAnetDatabase
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Adresse IP de la base de données. |
localhost |
|
|
Port utilisé pour accéder à la base de données. |
1521 |
|
|
Nom d'utilisateur du schéma. |
Aucune (obligatoire) |
|
|
Mot de passe du schéma. |
Aucune (obligatoire) |
|
|
SID Oracle. |
lib5 |
|
|
Nom du service Oracle. Peut être indiqué à la place de |
Aucune (facultatif) |
Le Tableau 4-5 décrit les paramètres pouvant apparaître dans une section WorkflowProfile.
Tableau 4-5 Paramètres WorkflowProfile
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom du profil de workflow. |
default |
|
|
Autoriser les transferts directs (vers des sources/destinations) à partir de DIVA distants. Définissez ce paramètre sur false pour toujours créer une copie locale du contenu avant restauration. |
true |
|
|
Délai d'expiration par défaut des messages envoyés aux Managers. |
15000 (15 secondes) |
|
|
Délai de conservation des demandes avant leur expiration (en heures). |
72 |
|
|
Empêcher les nouvelles demandes d'archivage si l'objet existe sur un site. Si ce paramètre est défini sur true, et que l'objet existe sur un site, les demandes d'archivage de cet objet seront rejetées (même si l'objet n'est pas présent sur le site de destination de l'archivage). |
true |
|
|
Intervalle entre deux tentatives de suppression de workflow. |
5 minutes |
|
|
Nombre total de minutes pendant lequel les nouvelles tentatives de suppression de workflow continueront. Les nouvelles tentatives de suppression seront effectuées toutes les |
0 minutes (ne pas effectuer de nouvelle tentative) |
|
|
Temps d'attente avant une nouvelle tentative de demande de copie. Ce paramètre s'applique uniquement aux demandes de copie. |
5 minutes |
|
|
Continuer les nouvelles tentatives de copie jusqu'à ce que la limite de temps totale soit atteinte (ou qu'une tentative aboutisse). Ce paramètre s'applique uniquement aux demandes de copie. |
0 minutes (ne pas effectuer de nouvelle tentative) |
|
|
Dans le cas d'un échec, nombre maximal de nouvelles tentatives à effectuer (en général, nouvelle tentative avec du contenu existant sur un autre site). |
3 fois |
|
|
Intervalle entre les tentatives quand DIVAnet effectue une nouvelle tentative avec le même site. |
5 minutes |
|
|
(Avancé) Durée maximale d'indisponibilité d'un site au bout de laquelle les demandes en file d'attente sont routées vers un autre site. |
30 |
|
|
Si le site local est indisponible pour une période étendue (configurée dans |
Aucune (aucun site de sauvegarde) |
|
|
Convertit une demande de suppression globale en suppression de site sur le site spécifié. |
Aucune (facultatif) |
|
|
Une ou plusieurs listes de messages, chacune contenant les messages valides pour le profil de workflow. |
NA |
|
|
Un ou plusieurs noms de message valides :
Au moins une balise
|
Aucune (une valeur obligatoire) |
|
|
True si le profil de workflow doit inclure tous les mappages définis dans le profil de workflow default. |
False |
La balise Mappings contient plusieurs mappages de transfert de site à site. Un mappage de site à site définit la façon dont un objet est copié d'un site à un autre. Chaque mappage contient des paramètres FromSitename et ToSitename. Chaque mappage définit comment les copies sont effectuées du site FromSitename au site ToSitename.
Chaque mappage contient un paramètre Type qui indique la méthode utilisée pour les transferts (voir Workflow de restauration pour plus d'informations). Les autres paramètres sont des valeurs par défaut utilisées pendant l'exécution de la copie entre sites.
DIVAnet utilisera FromSrcDest comme zone de stockage temporaire et propagera éventuellement vers le site DIVA cible à l'aide du paramètre ToSrcDest. Lors du stockage de contenu, DIVAnet fournit un nom de dossier unique qui est ajouté au FilePathRoot. Après le stockage du contenu dans FromSrcDest, DIVAnet pourra (selon le paramètre Type) :
archiver le contenu dans le site cible ;
attendre que le contenu soit archivé avec succès dans le site cible ;
se terminer sans action supplémentaire.
Remarque :
Pour éviter de spécifier plusieurs fois les mêmes mappages dans la configuration, vous pouvez définir le paramètre de profil de workflowUseDefaultMappings. Le profil de workflow utilisera les mappages du profil de workflow default.Tableau 4-6 Paramètres de profil de workflow SitetoSiteTransfer
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom du site d'origine à partir duquel les objets sont copiés. La valeur entrée doit correspondre à l'un des noms de site définis dans la section |
Aucune (obligatoire) |
|
|
Nom du site de destination vers lequel les objets sont copiés. La valeur entrée doit correspondre à l'un des noms de site définis dans la section |
Aucune (obligatoire) |
|
|
Le type de transfert :
|
RestoreAndArchive |
|
|
La source/destination à utiliser dans l'étape de restauration de la copie. Remarque : Oracle recommande de ne pas utiliser la valeur par défaut. |
MISSING_MAPPING_TO + |
|
|
La source/destination à utiliser dans l'étape d'archivage de la copie. |
MISSING_MAPPING_TO + |
|
|
Média cible à affecter lors de l'exécution d'une copie temporaire ou non persistante de l'objet (effectuée dans certaines opérations de restauration). La valeur est également utilisée (selon la configuration) quand les utilisateurs de l'API ou de l'interface utilisateur veulent que DIVAnet détermine le média à utiliser (le mot-clé any est utilisé comme média). Quand RestoreAndMonitor est utilisé avec cette variable, déterminez si l'option |
Aucune (obligatoire pour RestoreAndArchive) |
|
|
Segment de chemin relatif à la racine source/destination. Préfixé pour le nom de dossier unique généré par DIVAnet. |
Remote |
|
|
Options DIVA à utiliser dans les options de restauration/d'archivage. |
-axf -rm -delete_fpr -allow_delete_on_source |
|
|
Stratégie à utiliser quand les utilisateurs de l'API ou de l'interface utilisateur décident de laisser DIVAnet choisir quel média utiliser pour les copies. Elle est appelée quand le mot-clé any est utilisé en tant que média. StoragePlan : utiliser le nom du plan de stockage de l'objet source comme média par défaut. StoragePlanAndSitename : ajouter au début le nom du site source au plan de stockage (séparé par un trait de soulignement). TempMedia : utiliser la valeur de |
TempMedia |
|
|
True si le média cible doit être ajouté, en tant que sous-répertoire, après
Cette option s'avère utile lors de l'utilisation du type RestoreAndMonitor avec DFM, car DFM peut analyser le nom du média transmis de cette façon. |
false |
|
|
Noter ce chemin de transfert en fonction d'autres chemins de transfert, selon la performance, les préférences. Utilisé dans le choix des sites pour la copie et la restauration. La plage valide est comprise entre 0 et 40. Veillez à utiliser des valeurs supérieures à 20, au risque de remplacer d'autres facteurs tels que disque contre bande, statut du site, etc. Une mauvaise utilisation de cette option peut provoquer des problèmes de performance lors des opérations de restauration et peut contribuer à la congestion du réseau WAN. |
La valeur par défaut est 10, la valeur locale est augmentée par 10. |
Pour calculer le site à utiliser pour les opérations de restauration, DIVAnet préfère en général le site local, dans la mesure où la source/destination est accessible à l'aide du site local. Toutefois, il existe des cas où un autre site est préférable.
La balise Mappings peut contenir une balise SrcDest. Dans la balise SrcDest, une balise Name définit un nom de source/destination. La balise PreferredSitename indique le site préféré à utiliser quand la source/destination est demandée dans une opération de restauration. Plusieurs sections SrcDest peuvent être présentes.
Le fichier de configuration ManagerAdapterConfig.xml contient la configuration pour le service ManagerAdapter. Suivez les étapes ci-après et la description de chaque paramètre dans la configuration ManagerAdapter (chacun des tableaux suivants contient ces informations) pour configurer le service ManagerAdapter.
DIVAnet peut placer un filtre sur des informations d'objet qui sont extraites par le service DIVAnet DbSync. Ce filtre permet à un site de sélectionner le sous-ensemble d'enregistrements d'objet à synchroniser avec les systèmes DIVAnet en aval. Le filtrage est configuré dans le service ManagerAdapter et c'est ce dernier qui l'exécute.
Remarque :
Les filtres d'objet et la substitution de préfixe de catégorie sont des fonctionnalités avancées qui requièrent d'être soigneusement testées avant d'être implémentées dans des workflows de production. N'ajoutez pas ou ne modifiez pas des filtres d'objet, sans discernement.Par exemple, le système DIVAnet à New York est configuré pour utiliser et stocker des actifs d'un site à Los Angeles. L'administrateur du site Los Angeles veut s'assurer que les utilisateurs à New York ne voient que les objets correspondant à l'une des trois catégories suivantes : AVID, POST1 et POST2. L'application du filtre suivant dans le fichier de configuration ManagerAdapter du site Los Angeles a pour résultat :
<LocalSitename>LosAngeles</LocalSitename>
<ObjFilter>
<RequestingSitename>NewYork</RequestingSitename>
<Category>AVID</Category>
<Category>POST1</Category>
<Category>POST2</Category>
</ObjFilter>
Avec ce filtre, les objets correspondant aux catégories spécifiées seront synchronisés avec la base de données DIVAnet à New York. Les objets avec d'autres catégories ne seront pas synchronisés. Pour un utilisateur du site New York, les seuls enregistrements d'objet qui existent sur le site Los Angeles sont ceux correspondant au filtre de catégorie configuré. Plusieurs balises ObjFilter peuvent figurer dans le service ManagerAdapter, chacune avec un ensemble de catégories spécifiques d'un site demandeur.
Remarque :
Les filtres de catégorie d'objet n'empêchent pas automatiquement le service ManagerAdapter d'accepter des demandes pour des objets ne correspondant pas au filtre. Les règles d'accès ManagerAdapter empêchent des opérations sur des objets qui ne comportent pas certaines catégories.Pour empêcher des opérations sur des objets ne correspondant pas au filtre, créez la règle d'accès suivante dans le fichier des règles d'accès ManagerAdapter :
<Include>
<SourceSitename>NewYork</SourceSitename>
<Operation>*</Operation>
<ReqObjectCategory>AVID</ReqObjectCategory>
<ReqObjectCategory>POST1</ReqObjectCategory>
<ReqObjectCategory>POST2</ReqObjectCategory>
</Include>
Cette règle permettra uniquement les demandes du site New York pour des objets correspondant à l'une des trois catégories AVID, POST1 et POST2. Les autres catégories seront refusées si aucune autre règle d'inclusion n'est spécifiée. Si vous définissez des règles d'accès dans le service ManagerAdapter, assurez-vous que le service ClientAdapter soit configuré pour communiquer avec le site en mode WebService.
Un problème peut se poser lors de l'utilisation du filtrage de synchronisation par catégorie. En reprenant notre exemple, si New York crée un objet avec une catégorie qui n'est pas présente dans le filtre, et copie cet objet pour Los Angeles, un conflit de dénomination peut survenir. Un objet portant ce nom pourrait déjà exister sur Los Angeles car le système DIVAnet à New York n'a pas connaissance de ces objets. Une solution consiste à fournir des règles d'accès dans New York qui limitent les catégories potentielles pouvant être archivées.
Vous pouvez parvenir à une solution plus flexible en utilisant la substitution de préfixe de catégorie. Cette fonctionnalité filtre les entrées qui sont synchronisées et ajoute un préfixe de catégorie à chaque demande entrante. Cela fournit une fonctionnalité de type espace de noms pour les objets archivés sur un site.
Dans certains workflows, DIVAnet, un seul site doit accepter les objets copiés à partir de plusieurs sites. Il peut donc être difficile d'établir un jeu de catégories unique pour tous les objets du système. Pour résoudre ce problème, utilisez la substitution de préfixe de catégorie. Le filtre d'objet ManagerAdapter suivant garantit que seuls les objets dans Los Angeles avec des catégories commençant par NY001 sont synchronisés avec la base de données DIVAnet de New York.
<LocalSitename>LosAngeles</LocalSitename>
<ObjFilter>
<RequestingSitename>NewYork</RequestingSitename>
<CategoryPrefix>NY001.</CategoryPrefix>
</ObjFilter>
Après l'application du filtre, mais avant que l'objet n'atteigne la destination (New York), le préfixe est éliminé ; les caractères restants servent en tant que catégorie dans la base de données DIVAnet de New York. Par exemple, si la catégorie d'un objet dans Los Angeles est NY001.POST1, la catégorie résultante envoyée à New York sera POST1. De même, chaque fois que le service ClientAdapter de DIVAnet New York envoie des commandes à Los Angeles, le préfixe est de nouveau ajouté.
Cela permet à Los Angeles de stocker des copies de tous les objets provenant de New York sans conflit de dénomination. Cette technique permet à Los Angeles de servir de site de récupération après sinistre pour plusieurs sites. New York n'a pas à modifier sa stratégie de dénomination. New York référence les objets comme il l'a toujours fait, de sorte qu'aucune nouvelle attribution de nom n'est nécessaire sur New York. Un seul préfixe de catégorie est autorisé pour chaque site demandeur.
Pour que cela fonctionne, le service DIVAnet ClientAdapter doit être configuré pour se connecter au site distant en mode WebService. Comme les objets sont essentiellement renommés lors de la copie vers le site avec une substitution de préfixe activée, les objets qui ont été copiés vers le site préalablement n'auront pas de préfixe, ce qui peut poser problème. Une solution consiste à fournir une liste de catégories supplémentaires qui ne sont pas traduites. Une autre solution consiste à demander à des spécialistes de l'installation d'Oracle DIVA de renommer un sous-ensemble d'objets dans le site filtré (autrement dit, d'ajouter le préfixe de catégorie à la catégorie de chaque objet affecté dans la base de données DIVA). Si vous utilisez la substitution de préfixe de catégorie, vous devrez probablement désactiver la vérification de catégorie dans la configuration DIVArchive Actor (contactez le support technique Oracle pour des instructions).
Remarque :
Si vous modifiez un filtre d'objet, il sera presque toujours nécessaire pour le système DIVAnet en aval d'effectuer une resynchronisation du site. Ce système peut à cet effet utiliser l'outil DIVAnetAdmin (voir le Chapitre 6).Les deux types de filtrage de catégorie peuvent être combinés. Le deuxième filtre suivant (pour Dallas) effectue la substitution de préfixe de catégorie (en utilisant DAL01) sur toutes les catégories sauf POST2 ou POST3. Seuls les enregistrements d'objet présentant le préfixe de catégorie ou la catégorie POST2 ou POST3 seront synchronisés pour Dallas.
<LocalSitename>LosAngeles</LocalSitename>
<ObjFilter>
<RequestingSitename>NewYork</RequestingSitename>
<CategoryPrefix>NY001.</CategoryPrefix>
</ObjFilter>
<ObjFilter>
<RequestingSitename>Dallas</RequestingSitename>
<CategoryPrefix>DAL01.</CategoryPrefix>
<Category>POST2</Category>
<Category>POST3</Category>
<ObjFilter>
Si vous utilisez cette approche hybride, assurez-vous que les noms d'objet avec des catégories figurant sur la liste (par exemple POST2) ne sont pas ajoutés de nouveau avec le préfixe (par exemple NY001.POST2). Cette stratégie peut être appliquée au moyen de règles d'accès.
Les tableaux suivants décrivent les paramètres pouvant figurer dans un fichier de configuration ManagerAdapter. Le fichier se présente au format XML. La colonne de valeur par défaut indique la valeur que le paramètre aura s'il n'est pas spécifié dans le fichier de configuration. Elle indique également si le paramètre est obligatoire ou facultatif.
Pour créer un nouveau fichier de configuration :
Accédez au répertoire de base DIVAnet (où DIVAnet est installé).
Accédez au dossier Program/conf/divanet/templates, copiez le fichier ManagerAdapterConfig.xml.ini vers le répertoire parent mais sans l'extension .ini (../ManagerAdapterConfig.xml).
En utilisant les tableaux ci-dessous comme référence, modifiez les paramètres dans le fichier ManagerAdapterConfig pour configurer le service ManagerAdapter.
Un exemple de fichier de configuration ManagerAdapter figure dans l'Annexe A.
Tableau 4-7 Paramètres de niveau supérieur ManagerAdapter
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom du site local. Le nom de site indiqué doit correspondre à ce qui a été configuré dans les bases de données DIVAnet (locale et distante) ainsi qu'à ce qui a été configuré dans les fichiers |
Aucune (obligatoire) |
|
|
Adresse réseau (IP ou nom internet) de DIVArchive Manager. |
localhost |
|
|
Port où les clients se connectent à DIVArchive Manager. |
Aucune (obligatoire) |
|
|
Port utilisé pour la réception des messages Web. |
Aucune (facultatif) |
|
|
True si SSL doit être utilisé pour les connexions de service Web entrantes. |
true |
|
|
Nom du fichier des règles d'accès. Ce nom de fichier est lié au répertoire dans lequel figure le fichier de configuration ManagerAdapter. |
Aucune (en l'absence de configuration, aucune règle d'accès n'est appliquée) |
|
|
Nombre de threads actifs dans les pools de threads DIVAnet. Utilisé pour le réglage des configurations de grande envergure. Dans le doute, ne définissez pas cette valeur. |
50 |
|
|
Dossier dans lequel les fichiers journaux seront générés. |
Le dossier |
|
|
Niveau de détail auquel la journalisation de fichier de suivi intervient (ERROR, WARN, INFO, DEBUG, TRACE). |
INFO |
Tableau 4-8 Paramètres ManagerDatabase
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Adresse IP de la base de données DIVArchive Manager. |
localhost |
|
|
Port utilisé pour accéder à la base de données. |
1521 |
|
|
Nom d'utilisateur du schéma. |
Aucune (obligatoire) |
|
|
Mot de passe du schéma. |
Aucune (obligatoire) |
|
|
SID Oracle. |
lib5 |
|
|
Nom du service Oracle. Peut être indiqué à la place de |
Aucune (facultatif) |
Un ObjFilter peut être défini pour chaque nom de site demandeur dans le service ManagerAdapter. Le tableau suivant indique les paramètres valides pour le filtre d'objet :
Tableau 4-9 Paramètres ObjectFilter
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom de site du site demandeur d'objets. |
Aucune (obligatoire) |
|
|
Les objets ayant la catégorie indiquée seront synchronisés pour le nom du site demandeur. Plusieurs catégories peuvent s'afficher. |
Aucune (facultatif si |
|
|
Le préfixe sera ajouté au début de chaque demande reçue via le service ManagerAdapter. Seuls les objets avec le préfixe de catégorie seront synchronisés sur le nom de site demandeur. |
Aucune (facultatif si |
Le fichier de configuration DBSyncConfig.xml contient la configuration pour le service DbSync. Suivez les étapes ci-après et la description de chaque paramètre pour configurer le service DbSync.
Assurez-vous que le service DbSync est en cours d'exécution lors de l'utilisation du service ClientAdapter. Si DbSync n'est pas en cours d'exécution, certaines demandes qui aboutiraient normalement pourraient se solder par un échec. Par exemple, des restaurations par DIVAnet d'objets récemment archivés pourraient échouer même si de nouvelles demandes d'archivage DIVAnet pourraient aboutir.
Les tableaux suivants décrivent les paramètres pouvant figurer dans un fichier de configuration DbSync. Le fichier se présente au format XML. La colonne de valeur par défaut indique la valeur que le paramètre aura s'il n'est pas spécifié dans le fichier de configuration. Elle indique également si le paramètre est obligatoire ou facultatif.
Pour créer un nouveau fichier de configuration :
Accédez au répertoire de base DIVAnet (où DIVAnet est installé).
Accédez au dossier Program/conf/divanet/templates, copiez le fichier DBSyncConfig.xml.ini vers le répertoire parent mais sans l'extension .ini (../DBSyncConfig.xml).
En utilisant les tableaux de description de paramètres ci-dessous comme référence, modifiez les paramètres dans le fichier DBSyncConfig.xml pour configurer DbSync.
Un exemple de fichier de configuration DbSync figure dans l'Annexe A.
Tableau 4-10 Paramètres de niveau supérieur de DbSync
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom de site du site DIVAnet local (où DbSync est en cours d'exécution). Le nom de site indiqué doit correspondre à ce qui a été configuré dans la base de données DIVAnet ainsi que ce qui a été configuré dans les fichiers |
Aucune (obligatoire) |
|
|
Dossier dans lequel les fichiers journaux seront générés. |
Le dossier |
|
|
Niveau de détail auquel la journalisation du fichier de suivi intervient (ERROR, WARN, INFO, DEBUG, TRACE). |
INFO |
|
|
Fréquence à laquelle les sites sont interrogés. Ne modifiez ce paramètre qu'en cas de lenteur de réseaux et/ou de système. |
2000 |
|
|
Port utilisé pour l'envoi de messages de gestion à DbSync. |
Aucune (facultatif) |
|
|
True si SSL doit être utilisé pour les connexions de service Web entrantes. |
true |
Dans la balise DivaManagers, plusieurs définitions DivaManager peuvent apparaître. Le Tableau 4-11 décrit les paramètres pouvant figurer dans une section DivaManager.
Tableau 4-11 Paramètres DivaManagers pour DbSync
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
URL du service sur la plate-forme DIVA Manager à utiliser pour la synchronisation. Par défaut, elle correspond à l'adresse réseau du ManagerAdapter distant, qualifié par le WebServicePort utilisé par le ManagerAdapter. |
Aucune (facultatif) |
|
|
Nom officiel du site à partir duquel synchroniser les informations d'objet. Le nom de site indiqué doit correspondre à ce qui a été configuré dans la base de données DIVAnet ainsi que ce qui a été configuré dans les fichiers |
Aucune (obligatoire) |
Configurez les paramètres de base de données DIVAnet comme indiqué dans le Tableau 4-12.
Tableau 4-12 Paramètres DIVAnetDatabase
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Adresse IP de la base de données. |
localhost |
|
|
Port utilisé pour accéder à la base de données. |
1521 |
|
|
Nom d'utilisateur du schéma. |
Aucune (obligatoire) |
|
|
Mot de passe du schéma. |
Aucune (obligatoire) |
|
|
SID Oracle (identificateur du site). |
lib5 |
|
|
Nom du service Oracle. Peut être indiqué à la place de |
Aucune (facultatif) |
Dans DIVAnet, vous utilisez des règles d'accès pour contrôler l'accès que les utilisateurs et applications client ont aux opérations et actifs DIVAnet. Les règles d'accès peuvent être exécutées de trois manières :
Sur des demandes DIVAnet dans le service ClientAdapter (en mode MultiDiva)
Sur des demandes DIVArchive dans le service ManagerAdapter
Sur des demandes DIVArchive qui entrent dans le service ClientAdapter via un port en mode Direct
Pour exécuter les règles d'accès, vous devez définir le paramètre AccessRulesFilename dans le fichier de configuration de ClientAdapter et/ou de ManagerAdapter. Vous devez indiquer le nom du fichier sans le chemin d'accès. DIVAnet suppose que le fichier sera situé dans le même répertoire que le fichier de configuration de ClientAdapter.
Les jeux de règles d'accès définis dans le service ClientAdapter (mode MultiDiva) assurent le contrôle d'accès sur des demandes DIVAnet (reçues localement). Les jeux de règles d'accès définis dans la configuration de ManagerAdapter assurent le contrôle d'accès sur des demandes DIVArchive (soumises pour satisfaire une demande DIVAnet). Deux niveaux de contrôle d'accès permettent aux règles de niveau service d'être configurées où les demandes sont initiées et aux règles spécifiques du site d'être appliquées en tant qu'exceptions aux stratégies de niveau service.
Les jeux de règles d'accès définis dans le service ClientAdapter (mode Direct) assurent le contrôle d'accès sur des demandes DIVAnet ou sur des demandes DIVArchive, selon que le système distant est une autre instance DIVAnet ou un système DIVArchive. Dans ce mode, des types d'opération supplémentaires sont disponibles pour utilisation dans des jeux de règles. Ces opérations correspondent à des demandes spécifiques de DIVArchive et sont détaillées ci-après.
Examinons rapidement un exemple pour mieux comprendre ces règles. La règle suivante permet des opérations d'archivage pour des utilisateurs se connectant en tant qu'administrateur ou opérateur à partir de la source/destination DATA_EXP_PDAT1 ou VID_FTP_3, et d'archiver sur un média HDFeatures ou spm (vous verrez que l'ordre des attributs n'est pas important), nommé avec une catégorie contenant le mot POST.
<Include>
<Operation>Archive</Operation>
<Username>admin</Username>
<Username>operator</Username>
<ReqMedia>spm</ReqMedia>
<ReqObjectCategory>*POST*</ReqObjectCategory>
<ReqSourceDest>DATA_EXP_PDAT1</ReqSourceDest>
<ReqSourceDest>VID_FTP_3</ReqSourceDest>
<ReqMedia>HDFeatures</ReqMedia>
</Include>
Dans les deux règles suivantes, les utilisateurs invités (guest) à partir du profil de workflow GUI ne sont pas autorisés à effectuer des copies de diva2 vers diva3 ou inversement.
<Exclude>
<WorkflowProfile>GUI</WorkflowProfile>
<Username>guest</Username>
<Operation>Copy</Operation>
<SourceSitename>diva2</SourceSitename>
<TargetSitename>diva3</TargetSitename>
</Exclude>
<Exclude>
<Username>guest</Username>
<WorkflowProfile>GUI</WorkflowProfile>
<Operation>Copy</Operation>
<SourceSitename>diva3</SourceSitename>
<TargetSitename>diva2</TargetSitename>
</Exclude>
Vous avez utilisé deux règles ici parce que vous ne vouliez pas limiter de façon explicite les opérations de copie qui se produisent dans le même site. Par exemple, quelqu'un sur le site diva2 veut copier un objet (en utilisant DIVAnet) vers une nouvelle bande ; dans ce cas, les noms des sites source et cible sont tous les deux diva2. Si vous disposiez d'une règle unique contenant tous les attributs SourceSitename et TargetSitename, vous pourriez exclure les copies de diva2 vers diva2 et de diva3 vers diva3.
Vous n'avez pas encore terminé. La copie n'aboutira pas si vous n'avez pas au moins une règle d'inclusion qui correspond.
<Include>
<Operation>Copy</Operation>
<WorkflowProfile>GUI</WorkflowProfile>
<Username>guest</Username>
<Operation>ApiConnect</Operation>
</Include>
Dans ce cas, une règle d'inclusion très générale vous donne la possibilité d'effectuer des copies où vous voulez, sauf de diva2 vers diva3 et inversement. En fait, vous n'aviez pas besoin d'une règle d'exclusion. Parfois, en revanche, il est plus facile d'utiliser des règles d'exclusion. Gardez à l'esprit que si une règle d'exclusion correspond à une opération, cette opération sera refusée, même si une ou plusieurs règles d'inclusion correspondent.
Pour résumer, il existe deux types de règles : inclusion et exclusion. L'accès est refusé pour toutes les demandes sauf si au moins une règle d'inclusion correspond à l'opération sur le point d'être exécutée. En revanche, si une règle d'exclusion correspond, l'opération est automatiquement rejetée, quelles que soient les règles d'inclusion qui correspondent.
Sur des demandes telles que la suppression, la copie, la restauration, la restauration de fichiers partielle, l'annulation et l'archivage, DIVAnet exécute le jeu complet de règles d'accès pour voir si l'opération est autorisée. Il examine des variables telles que :
Attributs d'auteur : profil de workflow de la connexion, nom de l'utilisateur qui a envoyé le message, adresse IP de l'auteur.
Attributs de demande : source/destination, noms des sites source/cible, média demandé, commentaires, etc. Ces attributs sont dérivés de la demande elle-même. La plupart ont le préfixe Req.
Attributs d'objet : média(s) sur lesquels l'objet est stocké, plan de stockage, taille de l'objet, etc. Ces attributs sont dérivés de l'objet en cours de traitement par une opération. La plupart ont le préfixe Obj.
La règle suivante combine ces trois types d'attribut. Elle permet à un utilisateur diva d'effectuer une suppression de site sur New York uniquement si l'objet existe sur Los Angeles.
<Include>
<Username>diva</Username>
<Operation>Delete</Operation>
<SubType>SiteDelete</SubType>
<TargetSitename>NewYork</TargetSitename>
<ObjOnSite>LosAngeles</ObjOnSite>
</Include>
Des demandes DIVAnet sont générées quand des demandes sont reçues en mode MultiDiva. Des règles d'accès peuvent être créées pour ces opérations DIVAnet. Voici les détails de certains attributs spécifiques des demandes DIVAnet.
Les opérations ApiConnect et WebConnect sont des opérations spéciales qui doivent être incluses pour établir une connexion au service ClientAdapter.
ApiConnect : cette opération régit la capacité à se connecter au service ClientAdapter au moyen d'une connexion de socket API client. Elle est obligatoire pour les connexions d'API DIVA.
WebConnect : cette opération régit la capacité des applications à se connecter via des connexions Web (DIVAnetUI et DivanetAdmin). Elle est obligatoire pour les connexions DIVAnetUI.
Quand ces opérations sont confrontées aux règles, gardez à l'esprit que seuls les attributs d'auteur seront présents pour la mise en correspondance. Par exemple, le paramètre TargetSitename ne sera pas mis en correspondance si des règles d'accès sont exécutées lors de l'opération ApiConnect, car l'attribut n'est simplement pas présent quand un client se connecte.
L'opération de suppression comporte un champ SubType qui représente un sous-type de l'opération. Vous pouvez inclure le champ SubType dans des règles avec l'opération de suppression, en indiquant plusieurs paramètres SubType, le cas échéant. Les valeurs pour SubType sont :
GlobalDelete : correspond si l'opération de suppression à effectuer est une suppression globale d'un objet sur tous les sites. Cela correspond également à une opération de suppression de site qui consiste à supprimer tous les objets restants dans DIVAnet.
SiteDelete : correspond si l'opération de suppression est une suppression de toutes les instances sur un site donné (le nom du site peut être mis en correspondance dans des règles à l'aide du paramètre TargetSitename). En outre, une opération aura ce SubType si le demandeur supprime une seule instance, mais qu'il s'agit de la dernière instance de l'objet sur ce site.
InstanceDelete : cette opération supprime une seule instance sur un site, alors qu'il en existe d'autres sur le site en question.
La spécification de ce paramètre dans des règles s'avère utile pour appliquer efficacement la portée des opérations de suppression autorisées.
DIVAnet autorise l'exécution des règles d'accès sur des demandes DIVArchive également. Les règles d'accès définies dans le service ManagerAdapter spécifient quelles opérations DIVArchive (envoyées pour satisfaire des demandes DIVAnet) sont autorisées. Seules les opérations valides pour des demandes DIVAnet peuvent être spécifiées dans des jeux de règles. Dans les jeux de règles ManagerAdapter, les attributs WorkflowProfile, TargetSitename et SubType ne sont pas valides.
Comme dans les jeux de règles ClientAdapter, l'opération WebConnect doit être autorisée pour que des connexions soient établies avec le service ManagerAdapter. Cela s'étend également aux opérations DbSync. L'attribut SourceSitename correspond au site spécifique qui fait une demande. L'opération ApiConnect n'est pas disponible dans les règles d'accès ManagerAdapter.
La mise en correspondance d'une règle implique la comparaison des attributs de la règle aux valeurs réelles de chaque demande, d'un objet de mise en correspondance ou de l'émetteur de la demande. Les caractères génériques sont autorisés (utilisez un astérisque (*) comme caractère générique). Les noms de balise ne sont pas sensibles à la casse, mais la plupart des valeurs font la distinction entre majuscules et minuscules. La balise Operation est requise dans chaque règle. Vous pouvez spécifier une balise Operation contenant un astérisque (*) pour indiquer que la règle s'applique à toutes les opérations. En revanche, vous devez faire attention quand vous procédez ainsi car tous les attributs ne sont pas valides pour toutes les opérations.
Les attributs distincts d'une règle (d'inclusion ou d'exclusion) sont reliés par un opérateur AND logique dans le processus de mise en correspondance. Toutefois, un seul attribut spécifié plus d'une fois dans une règle provoque la jointure de ces attributs par un opérateur OR logique dans une seule expression.
Lors de la mise en correspondance de l'opération demandée avec une règle d'accès, DIVAnet détermine si l'attribut de la règle est applicable pour l'opération à effectuer. Si tel n'est pas le cas, l'attribut n'est pas utilisé dans la comparaison.
Les règles peuvent être regroupées dans des jeux de règles. Chaque règle d'inclusion/d'exclusion doit figurer à l'intérieur de balises Ruleset. Chaque opération DIVAnet entrante est mise en correspondance avec tous les jeux de règles. Les jeux de règles sont utiles car ils peuvent avoir des attributs qui servent de valeurs par défaut pour toutes les règles qu'ils contiennent. Lors de la mise en correspondance, chaque attribut Ruleset par défaut est incorporé implicitement à chaque règle enfant, comme s'il avait été spécifié directement dans la règle. Il est courant d'utiliser un profil de workflow comme attribut par défaut pour les jeux de règles, car le profil de workflow est alimenté pour chaque opération DIVAnet demandée.
Les attributs suivants peuvent être définis par défaut dans un jeu de règles :
Username
NetAddress
WorkflowProfile (dans des règles ClientAdapter)
L'exemple suivant autorise les utilisateurs connectés à un WorkflowProfile ayant la valeur GUI de consulter des demandes et des actifs, et d'effectuer des suppressions d'instances individuelles sur le site diva1. Gardez à l'esprit qu'un paramètre SubType d'une opération InstanceDelete rejettera toute suppression qui risquerait de supprimer la dernière instance d'un objet particulier sur un site.
La seconde partie de l'exemple empêche toutes les connexions, qu'il s'agisse de connexions Web ou d'API, provenant du sous-réseau 172.53. Toutes les opérations sont concernées, quel que soit leur profil de workflow.
<Ruleset>
<WorkflowProfile>GUI</WorkflowProfile>
<Include>
<Operation>WebConnect</Operation>
<Operation>Delete</Operation>
<SubType>InstanceDelete</SubType>
<TargetSitename>diva1</TargetSitename>
</Include>
</Ruleset>
<Ruleset>
<NetAddress>172.53*</NetAddress>
<Exclude>
<Operation>ApiConnect</Operation>
<Operation>WebConnect</Operation>
</Exclude>
</Ruleset>
Le Tableau 4-13 décrit les paramètres qui peuvent apparaître dans la section Ruleset.
Tableau 4-13 Paramètres de jeu de règles
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Cet attribut, défini dans la configuration de ClientAdapter, est le nom d'un groupe de travail ou d'un ensemble d'applications qui accèdent à DIVAnet. Cet attribut fait partie de chaque règle du jeu. |
Aucune (facultatif) |
|
|
Nom d'utilisateur transmis dans l'API ou spécifié dans la demande Web. Cet attribut fait partie de chaque règle du jeu. |
Aucune (facultatif) |
|
|
Adresse réseau (IP ou nom internet) de la connexion distante. Il peut s'agir de l'adresse d'une passerelle ou d'un routeur et non de l'adresse de l'émetteur. Cet attribut fait partie de chaque règle du jeu. |
Aucune (facultatif) |
|
|
Règle qui refuse une autorisation si elle correspond à l'opération DIVAnet. |
Aucune (facultatif) |
|
|
Règle qui permet l'autorisation si elle correspond à l'opération DIVAnet. |
Aucune (facultatif) |
Vous pouvez spécifier des attributs de règle qui figurent dans les demandes. Par exemple, ReqMedia correspondra au média et (ou) au plan de stockage spécifié dans une demande (opération).
De même, vous pouvez spécifier des attributs de règle qui correspondent à l'objet archivé que la demande traite. Par exemple, si un objet donné est spécifié dans une opération de suppression, ObjHasMedia mettra en correspondance n'importe quel média faisant actuellement partie de cet objet archivé, quel que soit le média transmis dans la demande.
Le Tableau 4-14 décrit les paramètres pouvant apparaître dans une section de règle Include ou Exclude.
Tableau 4-14 Paramètres opérationnels de règle (d'inclusion ou d'exclusion)
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom de l'opération DIVAnet à mettre en correspondance :
Il existe des opérations supplémentaires disponibles pour les opérations DIVArchive en mode Direct :
|
Aucune (facultatif) |
|
|
Nom d'utilisateur de l'utilisateur d'API connecté et (ou) de l'utilisateur du service. |
Aucune (facultatif) |
|
|
Nom du profil ClientAdapter. |
Aucune (facultatif) |
|
|
Adresse IP de l'application d'API et (ou) de l'utilisateur. |
Aucune (facultatif) |
|
|
Nom de site source de l'opération. Certaines opérations n'ont pas de nom de site source (par exemple, la commande Archive a une source/destination comme source). Si la demande est retentée sur un autre site, cette valeur changera et la règle entière sera réévaluée. Quand cet attribut figure dans des règles ManagerAdapter, il correspond au site qui a soumis la demande. |
Aucune (facultatif) |
|
|
Nom de site cible de l'opération. Certaines opérations n'ont pas de nom de site cible (par exemple, la commande Restore a une source/destination comme cible, mais pas un site). Si la demande est retentée sur un autre site, cette valeur changera et la règle entière sera réévaluée. |
Aucune (facultatif) |
|
|
Type d'opération en mode MultiDiva (la commande Delete comprend GlobalDelete, SiteDelete et InstanceDelete). |
Aucune (facultatif) |
Tableau 4-15 Paramètres de demande de règle (d'inclusion ou d'exclusion)
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom de l'objet en cours de traitement. |
Aucune (facultatif) |
|
|
Catégorie de l'objet (dans DIVArchive, elle fait partie du nom formel de l'objet). |
Aucune (facultatif) |
|
|
Source/destination spécifiée dans la demande. |
Aucune (facultatif) |
|
|
Champ de commentaires dans la demande. |
Aucune (facultatif) |
|
|
Média qui a été demandé dans le cadre de l'opération/de la demande (le nom de site ne doit pas être ajouté). Gardez à l'esprit que Storage Plan peut être transmis en tant que média demandé. |
Aucune (facultatif) |
|
|
Champ d'options dans la demande. |
Aucune (facultatif) |
Tableau 4-16 Paramètres d'objet de règle (à inclure ou à exclure)
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Correspond si l'objet existe sur le site spécifié. |
Aucune (facultatif) |
|
|
Correspond si l'objet n'existe PAS sur le site spécifié. |
Aucune (facultatif) |
|
|
Correspond à tout média sur tout site. |
Aucune (facultatif) |
|
|
Correspond au plan de stockage sur tout site ( |
Aucune (facultatif) |
|
|
Limite le plan de stockage indiqué à un site spécifique. |
Aucune (facultatif) |
|
|
Correspond si la taille totale de l'objet en Go fractionnaires est inférieure à la valeur spécifiée. |
Aucune (facultatif) |
|
|
Correspond si la taille totale de l'objet en Go fractionnaires est supérieure à la valeur spécifiée. |
Aucune (facultatif) |
DIVAnet autorise le remplacement de variable dans des fichiers de configuration pour faciliter la configuration de plusieurs fichiers script. Quand le modèle ${variable_name} est détecté dans une valeur XML (les variables ne sont pas valides dans les noms de balise), la valeur de la variable est remplacée quand DIVAnet lit le script. La valeur peut être extraite d'une variable d'environnement ou affectée directement dans le script.
Si le nom de variable dans le script est identique à celui d'une variable d'environnement, la valeur de cette variable sera remplacée dans le script. Vous pouvez aussi définir des valeurs de variables au début de chaque script à l'aide de la balise Variable. La syntaxe est : <Variable name="LocalSitename" value="diva1"/>. Quand DIVAnet lit un script de configuration, il vérifie si des variables utilisées dans le script ont été définies au début. Si tel n'est pas le cas, il recherche une variable d'environnement ayant le même nom que la variable.
Pour des raisons de commodité, un fichier script nommé divanetEnv.conf a été créé dans le répertoire de base DIVAnet, dans le sous-dossier Program\conf\divanet\wrapper. Il est possible de centraliser la définition des variables dans ce fichier de configuration afin qu'elles soient disponibles pour tous les services DIVAnet. En cas de modification de valeur et de redémarrage du service, les modifications feront l'objet d'une nouvelle lecture. Reportez-vous au fichier divanetEnv.conf pour des exemples de variables.