Ce chapitre décrit la prise en charge de l'API DIVArchive de DIVAnet et fournit des informations sur la spécification d'informations propres à DIVAnet à l'aide de l'API DIVArchive. Il est destiné à être utilisé avec la documentation de l'API DIVArchive C++, de l'API DIVArchive Java, ou de l'API DIVArchive Web Service.
DIVAnet prend en charge un sous-ensemble du jeu complet de commandes de l'API DIVArchive. Certaines commandes de l'API DIVArchive (telles que EjectTape) seront rejetées en mode MultiDiva de DIVAnet. DIVAnet 2.0 ne prend pas en charge les connexions client des clients de l'API DIVArchive des versions 7.3 et antérieures. Toute nouvelle fonctionnalité ajoutée à l'API après la version 7.3 ne sera pas prise en charge par DIVAnet 2.0.
Les appels d'API DIVA sur un serveur DIVAnet sont très similaires aux appels sur DIVArchive. Il y a toutefois quelques différences. DIVAnet accepte parfois les paramètres connus de l'API DIVA de façon légèrement différente. En outre, le contenu des champs renvoyé par DIVAnet peut être légèrement différent de DIVArchive, ou avoir un autre format. Cette section décrit ces différences.
DIVAnet 2.0 requiert que les sites DIVArchive connectés soient installés avec une version DIVArchive 7.3.1 ou ultérieure. Il est possible de mettre à niveau les sites DIVArchive sans procéder à la mise à niveau de DIVAnet.
Cette section décrit les demandes qui impliquent le transfert (ou la suppression) du contenu archivé, notamment les demandes d'archivage, de restauration, de suppression et de copie. Ces commandes peuvent être appelées au moyen de l'API DIVArchive. Certaines peuvent l'être à partir de DIVAnetUI. Reportez-vous à la documentation Oracle DIVArchive C++ API Reference Manual pour plus d'informations concernant le résultat de chaque commande dans l'API DIVArchive.
Remarque :
En mode MultiDiva, les demandes DIVAnet nécessitent souvent des informations que les demandes émises directement vers DIVArchive ne requièrent pas.Les demandes DIVAnet requièrent souvent des informations supplémentaires à cause de la fonctionnalité prise en charge. Par exemple, vous pouvez utiliser la commande Copy dans DIVAnet pour copier du contenu d'un système DIVA vers un autre. DIVAnet doit savoir, au minimum, quel est le site cible. Cependant, la commande de l'API DIVA CopyToGroup ne contient pas de paramètre de site cible (target site). Les sections ci-après décrivent comment indiquer ces informations supplémentaires. Pour plus d'informations sur la configuration du mode MultiDiva de DIVAnet, voir Configuration des ports API client.
Le Tableau 7-1 identifie les demandes de contenu de l'API DIVArchive qui sont prises en charge par DIVAnet. Les clients qui émettent ces demandes reçoivent un ID de demande en retour, qui permet l'interrogation périodique du statut de la demande.
Tableau 7-1 Demandes de contenu DIVArchive prises en charge
| Demande | Comportement dans DIVAnet |
|---|---|
|
Archive |
Archivage sur le site DIVArchive local ou, éventuellement sur un autre site sélectionné. Pour plus d'informations, voir Demandes d'archivage. |
|
Restore Restore Instance |
Restaurer un objet archivé vers une source/destination spécifique. Une instance spécifique et (ou) un site donné peut être utilisé comme contenu source pour la restauration. DIVAnet détermine s'il faut (1) restaurer un objet à partir du DIVArchive local, (2) restaurer directement un objet à l'aide d'un DIVArchive distant, ou (3) extraire un objet à partir du DIVArchive distant puis le transférer vers la source/destination choisie. Une commande Restore Instance permet de restaurer une instance spécifique sur un site donné. En cas d'échec, vous pouvez configurer DIVAnet pour de nouvelles tentatives sur d'autres sites. Pour plus d'informations, voir Demandes de restauration. |
|
Partial Restore Partial Restore Instance |
Restauration partielle d'un objet, similaire à une restauration complète. Une instance (sur un site donné) peut être utilisée comme source pour la restauration de fichiers partielle. En cas d'exécution d'une restauration de fichiers partielle sur un système distant, ce site DIVA doit être configuré pour une restauration partielle similaire pour le site local. Pour plus d'informations, voir Demandes de restauration de fichiers partielle. |
|
Copy (CopyToGroup) |
Copier du contenu d'un site DIVA vers un autre (copie intersite), ou créer une autre instance d'un objet sur un site DIVA (équivaut à exécuter une commande Une instance spécifique peut être copiée sur un site cible. Le message Pour plus d'informations, voir Demandes de copie. |
|
Delete DeleteInstance |
Supprimer du contenu de tous les sites, d'un site spécifique, ou supprimer une instance spécifique d'un site donné. Si des objets sont verrouillés sur les sites à supprimer, vous pouvez configurer DIVAnet pour de nouvelles tentatives pendant une période donnée. Pour plus d'informations, voir Demandes de suppression. |
Une demande d'archivage permet à l'appelant d'archiver du contenu qui existe sur une source/destination donnée (configurée dans DIVArchive). L'API DIVA organise un transfert à partir de la source/destination vers DIVArchive. Ceci diffère d'une API cloud basée sur Web où le contenu est transféré directement du demandeur via HTTPS. Par défaut, DIVAnet effectue l'archivage sur le site local.
Les demandes d'archivage émises à DIVAnet sont similaires à celles émises directement à DIVArchive, avec toutefois quelques ajouts au paramètre Target Sitename, soit le site DIVArchive où le contenu sera archivé. En général, DIVAnet effectuera l'archivage sur le site local. Cependant, il est possible d'effectuer l'archivage directement sur un autre site, de l'une des deux façons suivantes :
En indiquant l'option -site [sitename] dans le champ d'options. Un exemple serait -site diva1.
En préfixant le nom de site de destination pour le paramètre de média dans la demande d'archivage. Par exemple, sitename1_TapeGroup1 indique un site de destination appelé sitename1, et un média de TapeGroup1.
DIVAnet ne prend pas en charge les nouvelles tentatives continues pour des commandes Archive, mais prend en charge une option <BackupArchiveSite>, qui fournit un site d'archivage alternatif en cas d'indisponibilité du site principal.
Une demande de restauration permet au client de restaurer du contenu qui existe dans le système d'archivage. Le contenu arrive sur la source/destination sélectionnée dans la demande. L'API DIVA organise un transfert à partir d'un site DIVArchive directement vers une source/destination (telle qu'un disque FTP ou CIFS). Ceci diffère d'une API cloud basée sur Web où le contenu est transféré directement vers le demandeur via HTTPS.
Lors de la restauration du contenu à l'aide de DIVAnet, l'appelant doit savoir quel système DIVA détient le contenu. En outre, en cas d'échec lors de la récupération du contenu à partir d'un site DIVA, un autre site DIVA peut automatiquement être consulté pour extraire le contenu.
DIVAnet prend en charge la restauration vers n'importe quelle source/destination disponible sur le site local. DIVAnet extrait du contenu des sites distants, comme nécessaire, pour satisfaire la demande, avant de transférer le contenu vers la source/destination cible.
Les demandes de restauration émises à DIVAnet sont similaires à celles émises directement à DIVArchive, avec toutefois quelques ajouts au paramètre Source Sitename, soit le site DIVArchive à partir duquel le contenu sera restauré.
-site : en général, DIVAnet choisit le site à partir duquel effectuer la restauration. Cependant, vous pouvez tenter une restauration à partir d'un site donné en indiquant l'option -site [sitename] dans le champ d'options de la demande. Si, en fait, le contenu ne figure pas sur le site choisi, l'opération échouera.
Instance Id : si vous avez besoin d'un contrôle complet sur la source, vous pouvez indiquer un numéro d'instance dans la demande de restauration. Ceci vous permettra de choisir le site source et l'instance DIVA à partir de laquelle effectuer la restauration (voir la section suivante). Vous pouvez obtenir l'ID d'instance en exécutant un appel d'API getObjectInfo() et en indiquant le nom de l'objet à copier.
Dans ces deux cas, les nouvelles tentatives sont désactivées.
Pour satisfaire une demande de restauration, DIVAnet utilise les méthodes de restauration décrites dans le Tableau 7-2. DIVAnet sélectionnera de façon dynamique le workflow de restauration à utiliser en fonction des paramètres tels que la source/destination cible et l'objet source. Pour déterminer les sites à utiliser pour les restaurations, DIVAnet pose une série de questions, telles que :
L'objet est-il disponible sur le système DIVArchive local ?
L'objet comporte-t-il une instance de disque ?
La source/destination est-elle accessible à partir du système DIVArchive distant ?
La source/destination est-elle accessible à partir du site local ?
DIVArchive est-elle en cours d'exécution sur les sites source ou cible ?
Un site est-il privilégié par rapport à un autre dans le fichier de configuration ?
Tableau 7-2 Méthodes de restauration DIVAnet
| Méthode | Description |
|---|---|
|
Locale |
Utilisée quand un objet existe sur le site local. Le site local est le nom de site du système DIVArchive auquel vous envoyez des messages. Un système DIVArchive local est également considéré comme partie du site local. |
|
Distante directe |
DIVAnet peut faire en sorte qu'un système DIVA distant effectue une opération de restauration. Ceci n'arrive que si la source/destination cible est également configurée dans le système DIVA distant. Les noms de source/destination doivent correspondre et doivent tous les deux faire référence au même serveur ou disque (et au chemin sur ce disque, le cas échéant). Si elle est disponible, DIVAnet préfère cette méthode à l'exécution d'une restauration à l'aide de la copie intersite. |
|
Utilisation de copie intersite |
Si le contenu n'est pas local, et si un système DIVA distant ne peut pas effectuer une restauration directe sur une source/destination cible, DIVAnet peut faire en sorte que le contenu soit livré en deux étapes. Tout d'abord, le site DIVA distant effectue la restauration vers une source/destination partagée entre les sites distant et local. Puis, le site DIVA local archive l'objet et effectue la restauration vers la source/destination cible. Ainsi, les demandes futures de contenu seront extraites beaucoup plus rapidement. DIVAnet ne livre pas le contenu à l'aide de ce processus vers une source/destination qui existe uniquement sur un site DIVA distant. Si vous souhaitez toujours effectuer des restaurations distantes en créant une copie de proximité, définissez |
|
Utilisation de transfert intersite |
Dans certains cas, quand DIVAnet n'est pas en mesure d'effectuer une restauration distante directe, DIVAnet livre le contenu en deux étapes (restauration à l'aide de la copie intersite) mais n'archive pas réellement le contenu en local. Un de ces cas implique la fonction Oracle Partial File Restore. Tout d'abord, DIVAnet indique au DIVA source de transférer le contenu vers la source/destination accessible à la fois par les sites DIVA source et cible. Ensuite, le site DIVA transfère le contenu vers la source/destination cible sans l'archiver. |
DIVAnet vous permettra d'effectuer la restauration sur une source/destination qui est disponible sur le site local. DIVAnet peut transférer du contenu d'un site à un autre si le site source site et le site cible partagent un nom de source/destination commun. DIVAnet suppose que si une source/destination existe sur les sites source et cible, les deux configurations pointent vers le même Server\Device\Path physique. Par défaut, les utilisateurs doivent faire preuve de circonspection envers les noms qui sont affectés aux sources/destinations sur les sites.
Si un système DIVA distant ne peut pas effectuer une restauration directe sur une source/destination cible, DIVAnet peut faire en sorte que le contenu soit livré en deux étapes (voir Restauration à l'aide du transfert intersite). DIVAnet ne procède ainsi que si la source/destination existe sur le site local, et que celui-ci est le site préféré pour la source/destination donnée (voir Mappages source/destination préférés).
Vous pouvez configurer la commande Restore pour effectuer de nouvelles tentatives plusieurs fois en cas d'échec de la première restauration. Si le contenu à restaurer existe sur plusieurs sites, DIVAnet tentera automatiquement la restauration avec ces sites. Vous pouvez configurer le nombre maximal de nouvelles tentatives. Dans certains cas, DIVAnet décidera de refaire une tentative avec le même site avant de passer à d'autres. Dans ce cas, DIVAnet examinera la valeur <RestoreRetryIntervalMins> pour déterminer le délai d'attente avant d'effectuer une nouvelle tentative sur le même site.
DIVAnet 2.0 prend en charge un sous-ensemble de l'API DIVArchive. Pour obtenir une liste des messages pris en charge, reportez-vous au chapitre correspondant.
DIVAnet 2.0 offre une prise en charge restreinte pour les restaurations multiples. DIVAnet n'autorise pas les restaurations multiples pour des sources/destinations distantes, et ne permet ni la consultation ni la surveillance des sources/destinations multiples au moyen de l'interface utilisateur. Il est possible d'utiliser la restauration multiple si l'objet existe localement mais est inaccessible (par exemple, il a été externalisé localement).
DIVAnet 2.0 ne prend pas en charge les relations de site P2P, y compris l'équilibrage de la charge.
Outre les restaurations de contenu complètes, DIVAnet prend également en charge les restaurations de fichiers partielles. DIVAnet détermine le site où le contenu est situé et permet d'en restaurer une partie.
Si un objet existe sur un système DIVA distant, et que la source/destination cible de la restauration n'est pas accessible par un système DIVA distant, DIVAnet transfère le contenu en deux étapes, tout d'abord en utilisant le site DIVA distant afin d'obtenir le contenu pour le site DIVA local (sans transférer l'objet entier), puis en utilisant le site DIVA local pour restaurer le contenu vers la source/destination cible.
Comme pour la restauration, vous pouvez indiquer le numéro d'instance ou le paramètre -site pour effectuer une restauration à partir d'un site spécifique, ou spécifier de nouvelles tentatives en cas d'échec du site initial. De même, la restauration vers des destinations multiples dans une même demande de restauration n'est pas prise en charge.
Une demande de copie crée une nouvelle instance de contenu archivé à partir d'une instance existante. DIVAnet permet de copier du contenu d'un site DIVA vers un autre. La commande d'API DIVArchive CopyToGroup (1) copie un objet d'un site DIVA vers un autre, ou (2) crée simplement une nouvelle instance sur un seul site. Pour des copies, DIVAnet doit dériver certains paramètres qui ne sont pas disponibles dans l'API DIVA. Le Tableau 7-3 décrit ces paramètres.
Tableau 7-3 Paramètres dérivés de copie DIVAnet
| Attribut dérivé | Description |
|---|---|
|
Target Sitename |
Indique le site vers lequel l'objet doit être copié. Le nom de site cible n'existe pas en tant que champ architecturé dans l'API DIVA. Vous pouvez l'indiquer pour DIVAnet de deux façons :
Si vous ne spécifiez aucun nom de site, le site local est supposé. Le mot-clé -site ne fonctionnera qu'avec une API version 7.3 ou supérieure. |
|
Media |
Media indique le type de média à utiliser pour stocker l'objet copié. DIVAnet permet également d'indiquer un plan de stockage DIVA comme nom de média. Storage Plan fonctionnera uniquement si la copie est une copie intersite. Vous pouvez préfixer le nom de site cible pour le média pour indiquer aussi le nom de site cible. Si vous ne savez pas quel média indiquer, vous pouvez spécifier un média ayant la valeur any pour laisser le système choisir le média sur lequel effectue le stockage sur le site cible. Par exemple, un média diva1_any copie vers le site diva1, mais DIVAnet choisit le média. La valeur par défaut que fournit DIVAnet peut ne pas convenir pour certains cas d'utilisation. Si l'objet est déjà sur le site cible et que la valeur any est spécifiée, le système renverra simplement un message de succès. |
|
Source Sitename |
En général, DIVAnet choisit le site à partir duquel effectuer la copie. Toutefois, si vous avez besoin d'un contrôle complet sur la source, vous pouvez indiquer un numéro d'instance dans la demande de copie. Ceci vous permet de choisir le site source, de façon implicite, et l'instance DIVA à partir de laquelle effectuer la copie (voir la section suivante). Vous pouvez obtenir cet ID en exécutant un appel d'API |
Dans une demande de copie DIVAnet, si le site source est le même que le site cible, DIVAnet peut simplement émettre une commande CopyToGroup au site DIVA cible. Pour des copies intersite, DIVAnet permet de configurer la méthode utilisée pour effectuer ces copies. Pour chaque paire de noms de site source et cible (par exemple, site1 vers site2), le Tableau 7-4 répertorie les méthodes de transfert disponibles.
Outre la méthode de copie, chaque paire de noms de site source et cible contient la source/destination utilisée pour la zone de stockage commune. Le média de destination par défaut (pour RestoreAndArchive), les paramètres d'option (transmis à DIVArchive) et d'autres paramètres sont également configurables.
Tableau 7-4 Méthodes de copie de site à site
| Type | Description |
|---|---|
|
RestoreAndArchive |
Avec cette option, DIVAnet restaure le contenu du site source, vers une source/destination commune aux sites cible et source. Puis, DIVAnet indique au système DIVArchive cible d'archiver le contenu dans la zone de stockage commune. Il s'agit d'une alternative à l'utilisation des dossiers de dépôt. |
|
RestoreAndMonitor |
A l'aide de cette méthode, DIVAnet effectuera la copie en restaurant d'abord le contenu vers une destination spécifique. DIVAnet passera ensuite à la surveillance du système DIVArchive cible pour déterminer quand le contenu sera archivé avec succès sur le site cible. La demande aboutira uniquement quand le contenu sera archivé avec succès sur le site cible. Ceci s'appuie évidement sur un autre processus ou programme qui prendra le contenu et l'archivera dans le système DIVA cible. Cette option s'avère utile en combinaison avec le logiciel DIVArchive Drop Folder Monitor (DFM). Chaque dossier DFM est configuré pour l'archivage à l'aide d'un média présélectionné, ce qui signifie que quand DFM est utilisé pour des copies, le paramètre de média est ignoré. |
|
Restore |
A l'aide de cette méthode, DIVAnet effectuera la copie en restaurant vers une destination spécifique, puis en renvoyant un message de succès. Cette méthode ne confirme pas que le contenu a été archivé avec succès sur le site cible et risque de provoquer des échecs en cas de tentatives de workflows pour la restauration à l'aide de la copie intersite. |
La commande Copy de DIVAnet renverra un message de succès si une instance de l'objet existe déjà dans le site cible sur le média demandé. Dans ce cas, DIVArchive mettra fin à la demande.
Si un objet doit être copié vers un site où l'objet existe déjà, mais qui n'a pas le média demandé, DIVAnet créera une autre instance de l'objet sur ce site à l'aide du média spécifié dans la demande. Toutefois, il existe une exception si la valeur any est indiquée en tant que média. Dans ce cas, DIVAnet ne créera pas une autre instance.
Dans DIVAnetUI, une option permet à DIVAnet d'affecter le média cible sur une opération de copie (utilisation d'un média <Selected By DIVAnet>). Vous pouvez parvenir au même résultat dans une demande d'API DIVA en indiquant un média avec la valeur any dans la demande de copie. DIVAnet utilisera sa configuration pour déterminer le média à utiliser pour la copie (voir Mappages de site à site pour plus d'informations).
Quand la valeur any est transmise, et que l'objet existe déjà sur le site cible, DIVAnet ne créera pas une autre instance de l'objet. Aucune action supplémentaire ne sera effectuée et la demande aboutira.
DIVAnet prend également en charge de nouvelles tentatives périodiques sur des copies. Si cette option est activée dans le profil de workflow, DIVAnet retentera les opérations de copie qui ont échoué. Dans le profil de workflow, vous pouvez configurer la fréquence à laquelle DIVAnet retentera la demande, ainsi que le délai d'attente entre les nouvelles tentatives. Pour plus d'informations, voir Configuration des profils de workflow.
Une demande de suppression DIVArchive permet à l'appelant de retirer un objet archivé. Une demande de suppression DIVAnet, par défaut, supprimera l'objet de tous les sites DIVArchive. Une demande de suppression d'instance (DeleteInstance) DIVAnet peut supprimer une ou plusieurs instances d'un seul site DIVA. En réalité, DIVAnet peut donc effectuer trois types de suppression. Le Tableau 7-5 décrit les types de suppression et les paramètres qu'ils requièrent.
Tableau 7-5 Types de suppression
| Type | Attributs dérivés | Description |
|---|---|---|
|
Global Delete |
NA |
Supprime toutes les instances de l'objet sur tous les sites. Dans l'API, l'absence de spécification de média ou d'ID d'instance dans la demande provoque la suppression de l'objet spécifié de tous les sites. |
|
Instance Delete |
Target Sitename |
Supprime une seule instance d'objet sur un site donné. Dans l'API, spécifiez un ID d'instance ou un média pour supprimer une instance d'objet spécifique d'un site donné. Si vous spécifiez un ID d'instance, vous ciblez une instance spécifique sur un site donné. La transmission des paramètres de média ou d'options n'est pas nécessaire. Si vous indiquez un média, DIVAnet doit connaître le site à partir duquel vous voulez effectuer la suppression. Vous pouvez spécifier le site de trois façons :
|
|
Site Delete |
Target Sitename |
Supprime toutes les instances d'un objet sur un site donné. Vous pouvez le faire de trois façons :
|
Comme indiqué dans le tableau précédent, si un nom de site est fourni et qu'un média a la valeur any, toutes les instances de l'objet seront supprimées du site sélectionné. Vous pouvez également indiquer l'option -site [sitename] dans le champ d'options.
DIVAnet n'autorisera pas l'aboutissement d'une commande Instance Delete lors d'une tentative de suppression de la dernière instance d'un objet archivé (à savoir, la dernière instance qui existe dans la base de données DIVAnet). Dans ce cas, une commande Global Delete ou Site Delete devra être émise. Notez cependant qu'une commande Site Delete autorisera la suppression de la ou des dernières instances. Vous pouvez utiliser des règles d'accès pour prévenir des commandes Instance Delete ou Site Delete qui sont effectivement des demandes Global Delete (voir Configuration des règles d'accès pour plus d'informations).
Par ailleurs, si un utilisateur envoie une demande de suppression directement à DIVArchive, il peut exister une période pendant laquelle DIVAnet ne peut pas assurer la protection de la dernière instance.
Si une commande Delete est reçue par DIVAnet, et que DIVAnet est en cours d'exécution d'une copie intersite de l'objet, la demande DIVAnet qui a déclenché la copie sera annulée. La copie peut être le résultat d'une commande Copy ou d'une commande Restore qui effectue une copie pour satisfaire la restauration. D'autres types de demandes DIVAnet ne seront pas annulées.
Si une demande DIVArchive st en cours d'exécution pour le compte d'une demande DIVAnet, DIVArchive verrouille l'objet pour empêcher sa suppression. Ainsi, si un objet est verrouillé avant que DIVAnet puisse envoyer un message de suppression à DIVArchive, la demande de suppression échoue.
DIVAnet prend en charge de nouvelles tentatives périodiques de suppression en cas d'échec de suppression. Si cette option est activée dans le profil de workflow, DIVAnet essaiera d'effectuer des suppressions sur des sites où (par exemple) des instances/objets à supprimer sont verrouillés. Vous pouvez configurer la fréquence des nouvelles tentatives dans DIVAnet.
Le tableau Tableau 7-6 identifie les commandes d'API DIVArchive qui ne sont pas liées à du contenu. Ces commandes obtiennent des informations sur les objets et les demandes et aucun ID de demande ne leur est assigné.
Tableau 7-6 Autres commandes DIVArchive non liées à du contenu prises en charge
| Demande | Description | Comportement dans DIVAnet |
|---|---|---|
|
|
Annuler une demande DIVAnet. |
L'option -site ne s'applique pas à cette commande. |
|
|
Utiliser la base de données DIVAnet pour obtenir des informations sur un objet archivé. DIVAnet renvoie toutes les instances de l'objet sur tous les sites DIVAnet. Vous indiquez le nom et la catégorie de l'objet (Object Name et Object Category) (vous pouvez ne pas renseigner la catégorie mais si plusieurs objets ont le même nom, l'appel échouera). DIVAnet utilise la base de données DIVAnet pour renvoyer des informations sur l'objet archivé. Dans la réponse |
L'option -site n'est pas prise en charge pour cette commande. |
|
|
Extraire des informations concernant une demande DIVAnet à partir de la base de données DIVAnet. Remarque : Le paramètre Additional Information présente des limites. Les informations supplémentaires sont fournies par DIVArchive et représente des informations provenant de la dernière demande DIVA traitée. Les informations ne reflètent pas les autres sites dans le réseau DIVAnet. |
Quand DIVAnet reçoit un appel L'option -site ne s'applique pas à cette commande. |
|
|
Extraire des informations directement à partir de DIVArchive concernant les fichiers et dossiers figurant dans un objet archivé donné. |
Accepte l'option -site pour interroger un site donné ou aucun site pour laisser DIVAnet choisir (option recommandée). |
|
|
Extraire des informations à partir de DIVArchive concernant les objets et les événements d'objet. DIVAnet extrait les informations d'objet directement à partir de chaque système DIVArchive, un site à la fois, à tour de rôle, un batch par site. Chaque batch contient des informations provenant d'un site DIVA. Si le même objet existe sur deux sites, vous recevrez l'objet deux fois (une fois pour chaque site), une fois dans chaque batch. Remarque : l'ordre des entrées renvoyées n'est pas garanti. Si un site DIVA est indisponible, |
Vous pouvez extraire des informations d'un site en préfixant le nom du site pour le champ de média séparé par un trait de soulignement (_). Si vous ne voulez pas que le média soit interrogé, mais que vous voulez extraire des informations d'un site, il vous suffit d'indiquer le nom du site dans le champ de média. Cette commande n'accepte pas l'option -site. |
|
|
Interroge la base de données DIVAnet pour obtenir une liste des catégories et noms d'objet ( |
La prise en charge de cette commande est limitée dans DIVAnet. Les interrogations des informations de bande ne sont pas prises en charge ; en outre, il existe des limites concernant le nombre d'interrogations simultanées. L'option -site n'est pas prise en charge. |
|
|
Renvoie une liste des noms de baie à partir de tous les sites incluant les disques qui composent chaque baie, avec la capacité de disque actuelle. |
Le paramètre -site transmis dans le champ des options, peut renvoyer des informations pour un site spécifique. |
|
|
Renvoie une liste des noms de groupe de bandes à partir de tous les sites. Le nom du site est préfixé pour le nom de groupe. |
Remarque : Cette commande ne comporte pas de champ d'options. En conséquence, l'option -site n'est pas prise en charge. |
|
|
Renvoie une liste des informations de source et de destination à partir de tous les sites. |
Dans la liste renvoyée, le nom de site de la source ou de la destination est préfixé pour le nom de la source ou de la destination, séparé par un trait de soulignement (_). Le paramètre -site transmis dans le champ des options, peut renvoyer des informations pour un site spécifique. |
|
|
Extrait le statut d'un site DIVArchive unique (par défaut, le site local est renvoyé). Elle ne renvoie pas une vue globale de tous les sites. |
Le paramètre -site transmis dans le champ des options, sélectionne le site à partir duquel les informations sont collectées. Par exemple, -site diva1 routera la demande |
Pour des raisons de compatibilité d'application, ces commandes renverront toujours un message de succès, même si DIVAnet n'effectue aucune action pour les satisfaire.
Modification de priorité
Verrouillage d'objet
Déverrouillage d'objet
Liaison d'objets
Demande d'instance
Libération d'instance
DIVAnet renvoie des codes de statut qui sont similaires à ce que DIVArchive renvoie. Toutefois, DIVAnet acceptera parfois des demandes que DIVArchive mettrait automatiquement en échec, car souvent DIVAnet ne dispose des informations nécessaires pour effectuer la vérification que très tard lors du traitement de la demande.
En outre, DIVAnet renverra le statut ACCESS_DENIED pour de nombreuses commandes. Ce statut n'est pas renvoyé par DIVArchive. DIVAnet rejettera les demandes qui ne passent pas les vérifications des règles d'accès et rejettera les messages non configurés dans le profil de workflow. Pour des raisons de compatibilité, l'API version 5.8 et antérieure renvoie le statut INVALID_PARAMETER au lieu du statut ACCESS_DENIED.