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.bat) 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 :
Ces 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 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 peuvent uniquement être surveillées sur le site DIVA où les demandes 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 pouvez trouver un exemple de configuration dans le fichier figurant dans :
Program\conf\divanet\templates\ClientAdapterConfig.xml.ProxyOnly.ini
Mode MultiDiva : dans ce mode, 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 les autres systèmes DIVArchive, le cas échéant. Cette fonctionnalité permet (par exemple) la copie du contenu d'un site vers un autre, les restaurations sans connaissance du site donné comportant le contenu 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 DIVAnetUI. 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 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 la même façon.
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 d'utilisateurs ou d'applications donné. 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 nouvelle 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 supposé. 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 plus bas dans la configuration 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 et 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 les commandes Restore, Copy et Delete). Les paramètres pour les nouvelles tentatives, notamment la durée et l'intervalle entre chacune, sont configurables ici. Nombre 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. Celle-ci représente la liste des messages API valides qui peuvent être acceptés par ce profil de workflow. Par exemple, si le message <Archive> ne s'affiche 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 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 par défaut car d'autres profils de workflow peuvent charger leurs mappages à partir du profil de workflow 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 d'archive 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 un chemin de répertoire pour stocker les fichiers relatif à la source/destination choisie. Ce chemin relatif se présente comme suit :
<FilePathRoot> \ <Media (options)> \ <UniqueDirName> \
Le 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 ainsi que toutes les règles d'accès.Les tableaux suivants décrivent les paramètres pouvant figurer dans un fichier de configuration ClientAdapter. Le fichier se présente au format XML. La colonne Valeur par défaut indique la valeur que le paramètre aura si celui-ci 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 un exemple de fichier de configuration ClientAdapter.
Tableau 4-1 Paramètres de niveau supérieur 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 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 thread DIVAnet. Utilisé pour le réglage des configurations d'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 par défaut |
|
|
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 ClientAdapter. |
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 <API Port>
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Il s'agit du 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 (reportez-vous à la section Profil de workflow). S'il n'est pas indiqué, le profil de workflow par défaut sera utilisé. |
par défaut (profil par défaut en mode MultiDiva). |
Dans la balise <DivaManagers>, plusieurs définitions <DivaManager> peuvent s'afficher. Le Tableau 4-3 présente les paramètres pouvant figurer dans une définition <DivaManager>.
Tableau 4-3 Paramètres de configuration <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 jusqu'à ce 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 jusqu'à ce 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 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, identificateur du système Oracle. |
lib5 |
|
|
Nom du service Oracle. Peut être indiqué à la place de |
Aucune (facultatif) |
Le Tableau 4-5 présente les paramètres pouvant figurer dans une section <WorkflowProfile>.
Tableau 4-5 Paramètres <WorkflowProfile>
| Paramètre | Description | Valeur par défaut |
|---|---|---|
|
|
Nom du profil de workflow. |
par défaut |
|
|
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 gestionnaires (Manager). |
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 où l'archivage doit se faire). |
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'elles aboutissent). 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 nouvelles tentatives quand DIVAnet effectue une nouvelle tentative avec le même site. |
5 minutes |
|
|
(Avancé) Délai maximal pendant lequel un site est indisponible avant de router les demandes en file d'attente 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 ayant une liste de 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 par défaut. |
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 <FromSitename> au <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 qui sont utilisées dans le processus d'exécution de la copie intersite.
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 la spécification des mêmes mappages plusieurs fois dans la configuration, vous pouvez définir le paramètre de profil de workflow<UseDefaultMappings>. Le profil de workflow utilisera les mappages du profil de workflow par défaut.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. |
Distant |
|
|
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, et effectué par, le service ManagerAdapter.
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 des demandes de 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. Seul un 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. Vous pouvez l'effectuer à l'aide de l'outil DIVAnetAdmin (reportez-vous au 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 à l'exception des catégories POST2 ou POST3. Seuls les enregistrements d'objet ayant le préfixe de catégorie ou ayant une 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 Valeur par défaut indique la valeur que le paramètre aura si celui-ci 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 du site indiqué doit correspondre à ce qui a été configuré dans les bases de données DIVAnet (locale et distante) ainsi que 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 thread DIVAnet. Utilisé pour le réglage des configurations d'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 du fichier trace 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 <ObjectFilter> Parameters
| 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 (facultative 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 pour le nom du site demandeur. |
Aucune (facultative 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 le service 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 Valeur par défaut indique la valeur que le paramètre aura si celui-ci 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ètre 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 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 du 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 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 s'afficher. Le Tableau 4-11 présente 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 du 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 des règles d'accès, vous devez définir le paramètre <AccessRulesFilename> dans le fichier de configuration ClientAdapter et (ou) 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 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 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 aux demandes spécifiques de DIVArchive et sont détaillées ci-dessous.
Passons à 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é (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 les opérations de copie, de façon explicite, 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'aboutirait pas sauf si vous aviez au moins une règle d'inclusion qui corresponde.
<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 du tout 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 suppression, copie, restauration, restauration de fichiers partielle, annulation et 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 mises en correspondance avec vos 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 vient juste de 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 de suppression 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 ManagerAdapter, les attributs rulesets, 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 joints 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 leur jointure 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 comparé à 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ègle :
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 présente les paramètres pouvant figurer 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 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 dans le jeu de règle. |
Aucune (facultatif) |
|
|
Nom d'utilisateur transmis dans l'API ou spécifié dans la demande Web. Cet attribut fait partie de chaque règle dans le jeu de règle. |
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 dans le jeu de règle. |
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 les attributs de règle qui figurent dans des 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 présente les paramètres pouvant figurer 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 de l'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, ceci 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 (la commande Delete comprend GlobalDelete, SiteDelete et InstanceDelete) en mode MultiDiva. |
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 chacune des utilisations, 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 pour 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.