Antes de configurar los servicios de DIVAnet, consulte el Capítulo 2 para obtener una descripción de los servicios de DIVAnet y sobre cómo interactúan con DIVArchive y entre sí.
La configuración del servicio ClientAdapter incluye la configuración de la manera en la que los clientes se conectan con DIVAnet. También incluye la configuración de la manera en la que DIVAnet se conecta con DIVArchive.
Los sitios de DIVAnet se definen como un sistema DIVArchive y como uno o más de los servicios de DIVAnet (ManagerAdapter, ClientAdapter, DbSync). A cada sitio se asigna un nombre de sitio único. Los nombres de sitio se deben configurar en la base de datos de DIVAnet (mediante la utilidad addSites.bat) antes de configurar ClientAdapter. Debe crear nombres de sitio que sean fáciles de leer y que reflejen la ubicación física o la función del sitio. Los nombres de sitio se usarán en cada sitio.
Nota:
Los nombres de sitio distinguen entre mayúsculas y minúsculas.DIVAnet permite la configuración de puertos de socket que las aplicaciones de la API del cliente usan para conectarse a DIVAnet. ClientAdapter permite la configuración de varios puertos de la API. Cada puerto de la API se configura en uno de dos modos: modo directo o modo MultiDiva. Es posible asignar un perfil de flujo de trabajo a cada puerto.
Modo directo: en el modo directo, las conexiones entrantes de la API se enrutan directamente a un sistema DIVArchive individual sin procesamiento adicional. El sitio particular al que se enruta DIVAnet se configura en ClientAdapter de a un puerto por vez. Esta funcionalidad permite que los clientes locales se conecten a un sistema DIVArchive remoto como si fuera local. El sitio de DIVA al que se enrutarán los mensajes se debe configurar en la sección <DivaManagers> del archivo de configuración ClientAdapter. Tenga en cuenta también que los sitios se pueden designar como operativos únicamente en modo directo (consulte Configuración del nombre de sitio de DIVArchive para obtener más información).
Las solicitudes en modo directo no se mostrarán en DIVAnetUI y solamente se pueden supervisar en el sitio de DIVA al que se enrutan las solicitudes.
Algunos flujos de trabajo de DIVAnet no requieren una base de datos de DIVAnet, DIVAnet UI o el modo de procesamiento MultiDiva. Para configurar un servicio de ClientAdapter únicamente para el modo directo, asegúrese de que se hayan definido solamente puertos en modo directo y que no se haya definido <WebServicePort>. Esto desactiva de manera eficaz el uso de la IU de DIVAnet. Se puede encontrar una configuración de muestra en el siguiente archivo:
Program\conf\divanet\templates\ClientAdapterConfig.xml.ProxyOnly.ini
Modo MultiDiva: en el modo MultiDiva, DIVAnet muestra todos los sitios de DIVA como su fueran un sistema de archivos grande. En este modo, las solicitudes entrantes de la API se enrutan directamente a DIVAnet. DIVAnet satisface la solicitud de alto nivel mediante la consulta a otros sistemas DIVArchive según sea necesario. Esta funcionalidad permite (por ejemplo) copiar el contenido de un sitio en otro, realiza restauraciones sin necesidad de conocer cuál sitio determinado tiene el contenido y reintenta en otros sitios si no es posible acceder al contenido del primer sitio. Además, proporciona una vista global del contenido en todos los sitios.
El progreso de una solicitud ejecutada en el modo MultiDiva se puede supervisar en DIVAnetUI. DIVAnet creará sus propios eventos de nivel de solicitud que informarán al usuario acerca de:
La manera en la que DIVAnet procesará la solicitud
Las solicitudes realizadas en los sitios de DIVA
Los errores o las advertencias encontrados
La aplicación DIVAnetUI y la herramienta DivanetAdmin realizan conexiones web a ClientAdapter. Puede configurar el puerto que pone a disposición para estas conexiones en el archivo de configuración ClientAdapter.
Un perfil de flujo de trabajo es un juego de parámetros que define la manera en la que DIVAnet procesará las solicitudes entrantes. Los perfiles de flujo de trabajo proporcionan una manera de agrupar usuarios y sistemas que usan DIVAnet, de manera lógica, en un modo similar.
DIVAnet permite la creación de uno o más perfiles dentro de ClientAdapter. Estos perfiles pueden contener los parámetros necesarios para un juego de usuarios determinado o para un juego de aplicaciones. Los perfiles de flujo de trabajo se asignan según el lugar en el que se recibió la solicitud (el puerto donde se recibió, consulte la sección siguiente).
En el perfil de flujo de trabajo puede personalizar la información, como la lista de mensajes válidos aceptados, los parámetros de reintento, los métodos de copiado de sitio a sitio y otros atributos.
En la sección de puertos de la API, se puede asignar un nombre de perfil de flujo de trabajo a cada puerto definido. Las solicitudes recibidas en el puerto de la API se procesan mediante el perfil de flujo de trabajo asignado. Si no se define ningún nombre, se supone el perfil por defecto. Los puertos en el modo MultiDiva pueden tener nombres de perfil de flujo de trabajo que hacen referencia a la sección del cuerpo del perfil de flujo de trabajo, más abajo en la configuración de ClientAdapter.
Si el puerto está en modo directo, el nombre del perfil de flujo de trabajo es únicamente una etiqueta, no hay un cuerpo de perfil de flujo de trabajo para las conexiones de modo directo. Sin embargo, el nombre puede ser útil en las reglas de acceso (consulte la sección siguiente).
En modo MultiDiva y en modo directo, si no asigna un nombre, la conexión usa un perfil de flujo de trabajo con el nombre default. Todas las secciones del cuerpo del perfil de flujo de trabajo se configuran en ClientAdapterConfig.xml. En las siguientes secciones, se muestran los tipos de información que se pueden configurar en cada perfil de flujo de trabajo.
Algunos comandos de DIVAnet se pueden reintentar (por ejemplo, las solicitudes de restauración, copia y supresión). Los parámetros para los reintentos, incluida la duración del reintento y el intervalo de reintento se configuran aquí. Muchos comandos tienen sus propios ajustes de configuración de reintentos (por ejemplo, los parámetros de reintento del comando Copy son completamente diferentes de los parámetros de reintento del comando Delete). Los timeouts de mensajes y los límites de conexión también se pueden configurar en el perfil de flujo de trabajo. Los ajustes de configuración de reintentos y timeout son específicos del perfil de flujo de trabajo en el que se definen.
En cada perfil de flujo de trabajo, se configura una lista de mensajes. Esto representa la lista de mensajes válidos de la API que puede aceptar este perfil de flujo de trabajo. Por ejemplo, si el mensaje <Archive> no aparece en la lista, los mensajes de archivo no se podrán enviar a DIVAnet mediante la API (al menos para este perfil de flujo de trabajo).
DIVAnet proporciona una manera flexible de configurar la manera en la que se realizan las transferencias de sitio a sitio. En cada perfil de flujo de trabajo, configura los parámetros de asignación para cada ruta de transferencia (una ruta realiza transferencias del sitio A al sitio B, otra del sitio A al sitio C, etc.). Esta tabla se consulta cuando se reciben los comandos Copy, Restore o Partial File Restore.
Es útil definir las asignaciones de sitio a sitio en el perfil de flujo de trabajo default (Por defecto), ya que otros perfiles de flujo de trabajo pueden cargar sus asignaciones desde el perfil de flujo de trabajo default. Esto puede reducir el número de asignaciones en la configuración.
Parámetros: DIVAnet admite varios tipos de transferencias diferentes. Métodos de transferencia de sitio a sitio describe los diferentes tipos. RestoreAndArchive es el tipo de transferencia por defecto. RestoreAndMonitor requiere el supervisor de carpetas de entrega, u otra aplicación que realice una función similar. Otros parámetros incluyen:
Source/Destination (Origen/destino): la ubicación de almacenamiento común para transferencia (accesible desde los sitios de origen y destino).
Default Media (Medio por defecto): el medio de archivo por defecto que se usará cuando se archive en el sitio de destino. Default Media (Medio por defecto) se puede usar si se ha iniciado una copia temporal (por ejemplo, mediante una restauración) o si un usuario inició una copia e indicó que DIVAnet debía seleccionar el medio.
Options (Opciones): los parámetros que se usarán en las solicitudes de restauración, archivo y transferencia.
FilePathRoot (Raíz de ruta de archivo): el directorio principal donde se almacenará el contenido.
Directory Location (Ubicación de directorio): DIVAnet construye una ruta de directorio para almacenar los archivos, que se relaciona con la opción de Source/Destination (Origen/destino) elegida. Esta ruta relativa se construye de la siguiente manera:
<FilePathRoot> \ <Media (options)> \ <UniqueDirName> \
La opción FilePathRoot (Raíz de ruta de archivo) se especifica en las asignaciones de sitio a sitio. Los medios se embeberán en la ruta solamente si la opción AppendMediaToPath está configurada como true en las asignaciones (el valor por defecto es false). Finalmente, DIVAnet genera un nombre de directorio único que se incluye como parte de la ruta. Este nombre único está precedido por el nombre del sitio que inició la solicitud.
Los parámetros especificados en el perfil de flujo de trabajo se pueden cambiar y volver a cargar sin reiniciar ClientAdapter. Se debe evitar el reinicio del servicio ClientAdapter, ya que detendrá todas las solicitudes en ejecución y cerrará todas las conexiones del cliente. La recarga se puede llevar a cabo dentro de la herramienta DivanetAdmin (consulte a continuación para obtener más información sobre DivanetAdmin).
Nota:
Las actualizaciones de recarga actualizan no solamente todos los perfiles de flujo de trabajo, sino también las reglas de acceso.En las siguientes tablas, se describen los parámetros que aparecen en el archivo de configuración ClientAdapter. El archivo está en el formato XML. La columna de valor por defecto indica el valor que tendrá el parámetro si no se especifica el parámetro en el archivo de configuración. La columna también indica si se requiere el parámetro o si es opcional.
Para crear un nuevo archivo de configuración:
Navegue hasta el directorio raíz de DIVAnet (donde está instalado DIVAnet).
Navegue hasta la carpeta Program\conf\divanet\templates.
Copie el archivo ClientAdapterConfig.xml.ini en el directorio principal, pero quite la extensión .ini (..\ClientAdapterConfig.xml).
Mediante el uso de las siguientes tablas como referencia, edite los parámetros del archivo ClientAdapterConfig.xml para configurar ClientAdapter.
Consulte el Apéndice A para obtener un archivo de configuración de ClientAdapter de muestra.
Tabla 4-1 Parámetros de nivel superior de ClientAdapter
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
El nombre de sitio del sitio local de DIVAnet. |
Ninguno (requerido) |
|
|
La carpeta en la que se generarán los archivos log. |
El directorio |
|
|
El nivel de detalle en el que se lleva a cabo el registro del archivo de rastreo (ERROR, WARN, INFO, DEBUG, TRACE). |
INFO |
|
|
El número de segundos de espera para la sincronización de un objeto. |
60 |
|
|
El número de threads de trabajador en las agrupaciones de threads de DIVAnet. Se usa para el ajuste de configuraciones grandes. Si no está seguro, no configure este valor. |
25 |
|
|
Detenga todas las solicitudes de DIVAnet incompletas cuando se inicie DIVAnet, incluso si la solicitud se completó en el nivel de DIVArchive. Las nuevas solicitudes no se verán afectadas. |
false |
|
|
El número total máximo de conexiones de la API permitidas. |
200 |
|
|
El número máximo de solicitudes de DIVAnet pendientes o en ejecución que se pueden aceptar en el sistema. Cuando se alcance este límite, DIVAnet comenzará a rechazar las solicitudes nuevas. |
5000 |
|
|
El ratio base con el que se sondean los sitios en busca de información. Cambie este parámetro únicamente si se encuentran redes o sistemas lentos. |
4000 |
|
|
El puerto usado para enviar mensajes de gestión a ClientAdapter. |
Ninguno (opcional) |
|
|
Verdadero si SSL se deberá aplicar para solicitudes de servicio web. |
true |
|
|
Perfil de flujo de trabajo que se usará para solicitudes web (incluido DivanetUI). |
El perfil default (Por defecto) |
|
|
El nombre de archivo de las reglas de acceso. El nombre de archivo es relativo al directorio donde se encuentra el archivo de configuración del adaptador del cliente. |
Ninguno (si no está configurado, no se aplicarán reglas de acceso). |
Dentro de la etiqueta <ApiPorts>, pueden aparecer varias definiciones de <ApiPort>. En la Tabla 4-2 se muestran los parámetros que pueden aparecer como parte de una definición de <ApiPort>.
Tabla 4-2 Parámetros de <API Port>
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
Este el socket del puerto donde se realizará la escucha. |
Ninguno (requerido) |
|
|
Esto identifica la manera en la que se enrutan las solicitudes (directo o MultiDiva).
|
MultiDiva |
|
|
El sitio al que se enrutará mediante el modo directo. Los sitios se definen en la sección |
Ninguno (se requiere en modo directo) |
|
|
La dirección local que se usa para envíos a este gestor (generalmente la tarjeta de red que se usará). No especifique esta opción si no está seguro. |
Ninguno (opcional) |
|
|
El nombre de perfil de flujo de trabajo que se usará para las solicitudes que atraviesan este puerto (consulte la sección de perfil de flujo de trabajo). Si no se proporciona, se usará el perfil de flujo de trabajo default (Por defecto). |
default (el perfil por defecto en el modo MultiDiva). |
Dentro de la etiqueta <DivaManagers>, pueden aparecer varias definiciones de <DivaManager>. En la Tabla 4-3 se muestran los parámetros que pueden aparecer como parte de una definición de <DivaManager>.
Tabla 4-3 Parámetros de configuración de <DivaManagers>
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
El nombre del sitio donde está instalado el gestor. El nombre de sitio que se muestra debe coincidir con lo que se configuró en la base de datos de DIVAnet y lo que está configurado en el archivo |
Ninguno (requerido) |
|
|
Esto identifica la manera en la que se conectará con el gestor (valores válidos: Socket, WebService). |
Socket |
|
|
La dirección de red (IP o nombre de Internet) del gestor |
localhost |
|
|
El puerto donde los clientes se conectarán con el gestor. |
Ninguno (requerido) |
|
|
La dirección local que se usa para envíos a este gestor (generalmente la tarjeta de red que se usará). No especifique esta opción si no está seguro. |
Ninguno (opcional) |
|
|
El puerto local usado. No especifique esta opción si no está seguro. |
0 |
|
|
La dirección URL del servicio ManagerAdapter si la opción ConnectionType (Tipo de conexión) está configurada en WebService; required (Servicio web, requerido). |
Ninguno (opcional) |
|
|
DIVAnet esperará hasta que el número total de solicitudes del gestor caiga por debajo de este límite antes de enviar más solicitudes. Esto se usa cuando ConnectionType (Tipo de conexión) está configurado en Socket. Si el gestor supera el número de solicitudes en ejecución independientemente del origen (por ejemplo, DIVAnet, SPM, conexión de la API local), DIVAnet no enviará más solicitudes hasta que el número de solicitudes en ejecución del gestor caiga por debajo de este valor de umbral. |
400 |
|
|
DIVAnet esperará hasta que el número de solicitudes que DIVAnet tiene en ejecución en un gestor caiga por debajo de este límite antes de enviar más solicitudes. Si el gestor supera el número de solicitudes en ejecución enviadas únicamente a DIVAnet, DIVAnet no enviará más solicitudes hasta que el número de solicitudes en ejecución del gestor enviadas desde DIVAnet esté por debajo de este valor de umbral. Cero es un valor válido que causa que todos los mensajes se coloquen en cola de manera interna dentro de DIVAnet. El valor -1 indica que no hay ningún límite. |
100 |
En la Tabla 4-4 se muestran los parámetros que pueden aparecer dentro de la sección <DivanetDatabase>.
Tabla 4-4 Parámetros de <DIVAnetDatabase>
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
La dirección IP de la base de datos. |
localhost |
|
|
El puerto que se utiliza para acceder a la base de datos. |
1521 |
|
|
El nombre de usuario del esquema. |
Ninguno (requerido) |
|
|
La contraseña del esquema. |
Ninguno (requerido) |
|
|
El SID de Oracle. |
lib5 |
|
|
El nombre de Oracle Service. Se puede proporcionar en lugar de |
Ninguno (opcional) |
En la Tabla 4-5 se muestran los parámetros que pueden aparecer dentro de la sección <WorkflowProfile>.
Tabla 4-5 Parámetros de <WorkflowProfile>
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
El nombre del perfil de flujo de trabajo. |
default |
|
|
Permite transferencias directas (a Source/Destinations [Origen/destinos]) desde instancias remotas de DIVA. Configure este parámetro en false para crear siempre una copia local del contenido antes de la restauración. |
true |
|
|
El timeout por defecto para los mensajes enviados a los gestores. |
15000 (15 segundos) |
|
|
Cantidad de tiempo que se conservarán las solicitudes antes de que se produzca el timeout (en horas). |
72 |
|
|
Evita solicitudes de archivo nuevas si el objeto existe en un sitio. Si está configurado en true y el objeto existe en un sitio, se rechazarán las solicitudes para archivar ese objeto (incluso si el objeto no está presente en el sitio en el que está archivando). |
true |
|
|
El intervalo entre los reintentos de supresión del flujo de trabajo |
5 minutos |
|
|
El número total de minutos durante los que continuarán los reintentos de supresión del flujo de trabajo. Los reintentos de supresión se realizarán cada |
0 minutos (sin reintento) |
|
|
Tiempo que se esperará antes de reintentar una solicitud de copiado. Este parámetro se aplica solamente para las solicitudes de copiado. |
5 minutos |
|
|
Se continuarán los reintentos de copiado hasta que se alcance el tiempo límite total (o hasta que se realicen correctamente). Este parámetro se aplica solamente para las solicitudes de copiado. |
0 minutos (sin reintento) |
|
|
En caso de fallos, el número máximo de reintentos que se deberá intentar (generalmente, reintentos con contenido que existe en otro sitio). |
3 veces |
|
|
El intervalo entre reintentos cuando DIVAnet realiza un reintento con el mismo sitio. |
5 minutos |
|
|
(Avanzado) Tiempo máximo que un sitio está inactivo antes de enrutar las solicitudes en cola a otro sitio. |
30 |
|
|
Si el sitio local está inactivo durante un período extendido (configurado en |
Ninguno (sin sitio de copia de seguridad) |
|
|
Convierte una solicitud de supresión global en una supresión de sitio en el sitio especificado. |
Ninguno (opcional) |
|
|
Una o más listas de mensajes, cada una con una lista de mensajes válidos para el perfil de flujo de trabajo. |
N/D |
|
|
Uno o más nombres de mensaje válidos:
Se debe especificar al menos una etiqueta de
|
Ninguno (se requiere uno) |
|
|
Verdadero si el perfil de flujo de trabajo deberá incluir todas las asignaciones definidas en el perfil de flujo de trabajo default (Por defecto). |
False |
La etiqueta <Mappings> contiene varias asignaciones de transferencia de sitio a sitio. Una asignación de sitio a sitio define la manera en la que se copiará un objeto de un sitio a otro. Cada asignación contiene los parámetros <FromSitename> y <ToSitename>. Cada asignación define la manera en que se realizarán las copias de <FromSitename> a <ToSitename>.
Cada asignación contiene un parámetro <Type> que indica el método usado para realizar las transferencias (consulte Restauración del flujo de trabajo para obtener más información). Los otros parámetros son parámetros por defecto que se usan en el proceso de ejecución de una copia entre sitios.
DIVAnet usará <FromSrcDest> como área de almacenamiento temporal y, de manera opcional, realizará transferencias al DIVA de destino mediante <ToSrcDest>. Cuando almacena el contenido, DIVAnet proporciona un nombre de carpeta único que se agrega a <FilePathRoot>. Después de almacenar el contenido en <FromSrcDest>, DIVAnet (según el parámetro <Type>):
Archivará el contenido en el sitio de destino.
Esperará a que se haya archivado correctamente el contenido en el sitio de destino.
Finalizará sin otras acciones.
Nota:
Para evitar la especificación de las mismas asignaciones varias veces en la configuración, puede configurar el parámetro de perfil de flujo de trabajo<UseDefaultMappings>. El perfil de flujo de trabajo usará las asignaciones del perfil de flujo de trabajo default (Por defecto).Tabla 4-6 Parámetros de perfil de flujo de trabajo de <SitetoSiteTransfer>
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
Nombre de sitio de origen desde donde se copian los objetos. El valor introducido debe coincidir con uno de los nombres de sitio definidos en la sección |
Ninguno (requerido) |
|
|
Nombre de sitio de destino al que se copian los objetos. El valor introducido debe coincidir con uno de los nombres de sitio definidos en la sección |
Ninguno (requerido) |
|
|
El tipo de transferencia:
|
RestoreAndArchive |
|
|
El Source/Destination (Origen/destino) que se usará en el paso de restauración de la copia. Nota: Oracle recomienda no usar el valor por defecto. |
MISSING_MAPPING_TO + |
|
|
El Source/Destination (Origen/destino) que se usará en el paso de archivo de la copia. |
MISSING_MAPPING_TO + |
|
|
El medio de destino que se asignará cuando se marca una copia temporal o transitoria del objeto (que se realiza en algunas operaciones de restauración). El valor también se usa (según la configuración) cuando la API o los usuarios de IU desean que DIVAnet decida cuáles medios se usarán (la palabra clave any se usa como medio). Si se usa RestoreAndMonitor con esta variable, decida si la opción |
Ninguno (se requiere para RestoreAndArchive) |
|
|
Un segmento de ruta relativo a la raíz de Source/Destination (Origen/destino). Se coloca como prefijo para el nombre de carpeta único generado por DIVAnet. |
Remote |
|
|
Las opciones de DIVA que se usarán en las operaciones de restauración/archivo. |
-axf -rm -delete_fpr -allow_delete_on_source |
|
|
La estrategia que se usará cuando los usuarios de la API o la IU decidan permitir que DIVAnet elija cuáles medios se usarán para copias. Esto se invoca cuando se usa la palabra clave any como medio. StoragePlan (Plan de almacenamiento): usa el nombre del plan de almacenamiento del objeto de origen como medio por defecto. StoragePlanAndSitename (Plan de almacenamiento y nombre de sitio): antepone el nombre del sitio de origen al plan de almacenamiento (separado por un guión bajo). TempMedia (Medio temporal): usa el valor |
TempMedia |
|
|
Es verdadero si el medio de destino se debe agregar, como subdirectorio, después de
Esta opción es útil si se usa el tipo RestoreAndMonitor con el supervisor de carpetas de entrega, ya que este último puede analizar el nombre del medio transmitido de esta manera. |
false |
|
|
Califica esta ruta de transferencia en comparación con otras rutas de transferencia, según el rendimiento, la preferencia. Se usa para elegir sitios para copia y restauración. Rango válido de 0 a 40. Tenga cuidado cuando use valores superiores a 20, ya que comenzará a sustituir otros factores, como disco versus cinta, estado de sitio, etc. El uso incorrecto de esta opción puede causar problemas de rendimiento en las operaciones de restauración y puede contribuir a la congestión de la red WAN. |
El valor por defecto es 10, si es local aumenta 10. |
Cuando DIVAnet calcula cuál sitio usará para las operaciones de restauración, DIVAnet generalmente prefiere el sitio local, siempre que se pueda tener acceso al ajuste de Source/Destination (Origen/destino) desde el sitio local. Sin embargo, hay algunos casos en los que posiblemente se preferirá otro sitio.
La etiqueta <Mappings>puede contener una etiqueta <SrcDest>. Dentro de la etiqueta <SrcDest>, la etiqueta <Name> define un nombre de Source/Destination (Origen/destino). La etiqueta <PreferredSitename> indica el sitio preferido que se usará cuando se solicite Source/Destination (Origen/destino) en una operación de restauración. Pueden estar presentes varias secciones de <SrcDest>.
El archivo de configuración ManagerAdapterConfig.xml contiene la configuración del servicio ManagerAdapter. Use los siguientes pasos junto con la descripción de cada parámetro en la configuración de ManagerAdapter (todas las tablas siguientes tienen esta información) para configurar el servicio ManagerAdapter.
DIVAnet puede colocar un filtro en la información del objeto enviada por el servicio DIVAnet DbSync. Este filtro permite que un sitio seleccione un subjuego de registros de objeto que se sincronizarán con los sistemas DIVAnet descendentes. El filtrado se configura en el servicio ManagerAdapter y es ejecutado por este.
Nota:
Object Filters (Filtros de objeto) y Category Prefix Substitution (Sustitución de prefijo de categoría) son funciones avanzadas que requieren una prueba cuidadosa para implementación en flujos de trabajo de producción. No agregue ni cambie filtros de objeto de manera indiscriminada.Por ejemplo, el sistema DIVAnet en Nueva York está configurado para usar y almacenar activos desde un sitio en los Ángeles. El administrador del sitio en Los Ángeles desea asegurarse de que los usuarios en Nueva York solamente verán los objetos que coincidan con una de tres categorías, AVID, POST1 y POST2. La implementación del siguiente filtro mediante el archivo de configuración ManagerAdapter del sitio de Los Ángeles logra esto:
<LocalSitename>LosAngeles</LocalSitename> <ObjFilter> <RequestingSitename>NewYork</RequestingSitename> <Category>AVID</Category> <Category>POST1</Category> <Category>POST2</Category> </ObjFilter>
Con este filtro, los objetos que coinciden con las categorías especificadas se sincronización con la base de datos de DIVAnet en Nueva York. Los objetos con otras categorías no se sincronizarán. Desde la perspectiva de un usuario del sitio de Nueva York, los únicos registros de objeto que existen en Los Ángeles son los objetos que coinciden con el filtro de categoría configurado. Es posible que aparezcan varias etiquetas <ObjFilter> en ManagerAdapter, cada una con un juego de categorías específico de un sitio solicitante.
Nota:
Los filtros de objeto de categoría no evitan automáticamente que ManagerAdapter acceda a las solicitudes de objetos que no coinciden con el filtro. Las reglas de acceso de ManagerAdapter evitan operaciones en objetos que no tienen determinadas categorías.Para evitar operaciones en objetos que no coinciden con el filtro, cree la siguiente regla de acceso en el archivo de reglas de acceso de ManagerAdapter:
<Include> <SourceSitename>NewYork</SourceSitename> <Operation>*</Operation> <ReqObjectCategory>AVID</ReqObjectCategory> <ReqObjectCategory>POST1</ReqObjectCategory> <ReqObjectCategory>POST2</ReqObjectCategory> </Include>
Esta regla solamente permitirá solicitudes desde Nueva York para objetos que coinciden con una de tres categorías, AVID, POST1 y POST2. El resto de las categorías se denegarán si no se especifican otras reglas de inclusión. Si define reglas de acceso en ManagerAdapter, asegúrese de que ClientAdapter esté configurado para comunicarse con el sitio en el modo WebService (Servicio web).
Hay un problema potencial cuando se usa la sincronización de filtrado por categoría. Continuado con el ejemplo, si Nueva York crea un objeto con una categoría que no está presente en el filtro y copia este objeto en Los Ángeles, es posible que se produzca un conflicto de nombres. Es posible que ya exista un objeto con ese nombre en Los Ángeles porque el sistema DIVAnet de Nueva York no conoce esos objetos. Una solución es proporcionar reglas de acceso en Nueva York que limiten las categorías potenciales que se pueden archivar.
Es posible lograr una solución más flexible mediante la sustitución del prefijo de categoría. Esta función no solamente filtra las entradas que se sincronizan, sino que también agrega un prefijo de categoría a cada solicitud entrante. Esto proporciona una función similar al espacio de nombres para los objetos archivados en el sitio.
En algunos flujos de trabajo de DIVAnet un único sitio deberá aceptar objetos copiados de varios sitios. Esto puede dificultar el establecimiento de un juego de categorías únicas para todos los objetos del sistema. Use una sustitución de prefijo de categoría para solucionar esta situación. El siguiente filtro de objeto de ManagerAdapter garantizará que solamente los objetos en Los Ángeles con categorías que comienzan con NY001 se sincronizarán con la base de datos de DIVAnet de Nueva York.
<LocalSitename>LosAngeles</LocalSitename> <ObjFilter> <RequestingSitename>NewYork</RequestingSitename> <CategoryPrefix>NY001.</CategoryPrefix> </ObjFilter>
Después de aplicar el filtro, pero antes de que el objeto alcance el destino (Nueva York), se elimina el prefijo, los caracteres restantes funcionan como la categoría en la base de datos de DIVAnet en Nueva York. Por ejemplo, si la categoría de un objeto en Los Ángeles es NY001.POST1, la categoría resultante que se envía a Nueva York será POST1. De manera similar, cada vez que el servicio ClientAdapter de DIVAnet en Nueva York envía comandos a Los Ángeles, el prefijo se agrega nuevamente.
Esto permite que Los Ángeles almacene copias de todos los objetos desde Nueva York sin conflictos de nombres. Esta técnica permite que Los Ángeles funcione como sitio de recuperación ante desastres para varios sitios. Nueva York no necesita cambiar su política de nombres. Nueva York hace referencia a objetos de la misma manera que siempre lo ha hecho; por lo tanto, no se necesita un cambio de nombre en Nueva York. Solamente se permite un prefijo de categoría para cada sitio solicitante.
Para que esto funcione, el servicio ClientAdapter de DIVAnet debe estar configurado para conectarse al sitio remoto en el modo WebService (Servicio web). Dado que se cambia el nombre de los objetos cuando se copian en el sitio con una sustitución de prefijo activada, los objetos que se copiaron en el sitio anteriormente no tendrán el prefijo, lo que puede causar un problema. Una solución consiste en proporcionar una lista de categorías adicionales que no se traducen. Otra solución consiste en que los especialistas de instalación de Oracle DIVA cambien el nombre de un subjuego de objetos en el sitio filtrado (es decir, que agreguen el prefijo de categoría a la categoría de cada objeto afectado en la base de datos de DIVA). Si usa una sustitución de prefijo de categoría, es posible que deba desactivar la comprobación de categoría en la configuración de DIVArchive Actor (comuníquese con el soporte de Oracle para obtener instrucciones).
Nota:
Si cambia un filtro de objeto, casi siempre será necesario para que el sistema DIVAnet descendente realice una resincronización del sitio. Puede lograr esto mediante el uso de la herramienta DIVAnetAdmin (consulte el Capítulo 6).Los dos tipos de filtrado de categoría se pueden combinar. El segundo filtro siguiente (para Dallas) realiza una sustitución de prefijo de categoría (mediante DAL01) en todas las categorías, excepto en las categorías POST2 o POST3. Solamente los registros de objeto que tienen el prefijo de categoría o que tienen la categoría POST2 o POST3 se sincronizarán con 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 usa este enfoque híbrido, asegúrese de que los nombres de objeto con categorías que aparecen en la lista (por ejemplo, POST2) no se agreguen nuevamente con el prefijo (por ejemplo, NY001.POST2). Esta política se puede aplicar mediante las reglas de acceso.
En las siguientes tablas, se describen los parámetros que aparecen en el archivo de configuración ManagerAdapter. El archivo está en el formato XML. La columna de valor por defecto indica el valor que tendrá el parámetro si no se especifica el parámetro en el archivo de configuración. La columna también indica si se requiere el parámetro o si es opcional.
Para crear un nuevo archivo de configuración:
Navegue hasta el directorio raíz de DIVAnet (donde está instalado DIVAnet).
Navegue hasta la carpeta Program\conf\divanet\templates, copie el archivo ManagerAdapterConfig.xml.ini en el directorio principal, pero quite la extensión .ini (..\ManagerAdapterConfig.xml).
Mediante el uso de las siguientes tablas como referencia, edite los parámetros del archivo ManagerAdapterConfig.xml para configurar ManagerAdapter.
Aparecerá un archivo de configuración de ManagerAdapter de muestra en el Apéndice A.
Tabla 4-7 Parámetros de ManagerAdapter de nivel superior
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
El nombre del sitio local. El nombre del sitio que se muestra debe coincidir con lo que se configuró en las bases de datos de DIVAnet (local y remota) y debe coincidir con lo que se configuró en los archivos |
Ninguno (requerido) |
|
|
La dirección de red (IP o nombre de Internet) de DIVArchive Manager. |
localhost |
|
|
El puerto donde los clientes se conectarán con DIVArchive Manager. |
Ninguno (requerido) |
|
|
El puerto usado para recibir mensajes web. |
Ninguno (opcional) |
|
|
Verdadero si SSL se deberá aplicar para conexiones de servicio web entrantes. |
true |
|
|
El nombre de archivo de las reglas de acceso. El nombre de archivo es relativo al directorio donde se encuentra el archivo de configuración de ManagerAdapter. |
Ninguno (si no está configurado, no se aplicarán reglas de acceso). |
|
|
El número de threads de trabajador en las agrupaciones de threads de DIVAnet. Se usa para el ajuste de configuraciones grandes. Si no está seguro, no configure este valor. |
50 |
|
|
La carpeta en la que se generarán los archivos log. |
La carpeta |
|
|
El nivel de detalle en el que se lleva a cabo el registro del archivo de rastreo (ERROR, WARN, INFO, DEBUG, TRACE). |
INFO |
Tabla 4-8 Parámetros de <ManagerDatabase>
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
La dirección IP de la base de datos de DIVArchive Manager. |
localhost |
|
|
El puerto que se utiliza para acceder a la base de datos. |
1521 |
|
|
El nombre de usuario del esquema. |
Ninguno (requerido) |
|
|
La contraseña del esquema. |
Ninguno (requerido) |
|
|
El SID de Oracle. |
lib5 |
|
|
El nombre de Oracle Service. Se puede proporcionar en lugar de |
Ninguno (opcional) |
Se puede definir un <ObjFilter> para cada nombre de sitio solicitante en ManagerAdapter. La siguiente tabla muestra los parámetros válidos para el filtro de objeto:
Tabla 4-9 Parámetros de <ObjectFilter>
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
El nombre del sitio que solicita los objetos |
Ninguno (requerido) |
|
|
Los objetos con la categoría proporcionada se sincronizarán con el nombre de sitio solicitante. Pueden aparecer varias categorías. |
Ninguno (opcional si aparece |
|
|
El prefijo precederá todas las solicitudes recibidas mediante ManagerAdapter. Los objetos con el prefijo de categoría se sincronizarán con el nombre de sitio solicitante. |
Ninguno (opcional si aparece |
El archivo de configuración DBSyncConfig.xml contiene la configuración del servicio DbSync. Use los siguientes pasos junto con la descripción de cada parámetro para configurar el servicio DbSync.
Asegúrese de que el servicio DbSync se esté ejecutando cuando use ClientAdapter. Si el servicio DbSync no se está ejecutando, es posible que fallen algunas solicitudes que normalmente serían correctas. Por ejemplo, las restauraciones de DIVAnet de objetos recientemente archivados pueden fallar, incluso aunque las solicitudes de archivo de DIVAnet nuevas sean correctas.
En las siguientes tablas, se describen los parámetros que aparecen en el archivo de configuración DbSync. El archivo está en el formato XML. La columna de valor por defecto indica el valor que tendrá el parámetro si no se especifica el parámetro en el archivo de configuración. La columna también indica si se requiere el parámetro o si es opcional.
Para crear un nuevo archivo de configuración:
Navegue hasta el directorio raíz de DIVAnet (donde está instalado DIVAnet).
Navegue hasta la carpeta Program\conf\divanet\templates, copie el archivo DBSyncConfig.xml.ini en el directorio principal, pero quite la extensión .ini (..\DBSyncConfig.xml).
Mediante el uso de las siguientes tablas de descripción de parámetros como referencia, edite los parámetros del archivo DBSyncConfig.xml para configurar DbSync.
Aparecerá un archivo de configuración de DbSync de muestra en el Apéndice A.
Tabla 4-10 Parámetros de nivel superior de DbSync
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
El nombre de sitio del sitio de DIVAnet local (donde se está ejecutando DbSync). El nombre de sitio que se muestra debe coincidir con lo que se configuró en la base de datos de DIVAnet y lo que está configurado en |
Ninguno (requerido) |
|
|
La carpeta en la que se generarán los archivos log. |
La carpeta |
|
|
El nivel de detalle en el que se lleva a cabo el registro del archivo de rastreo (ERROR, WARN, INFO, DEBUG, TRACE). |
INFO |
|
|
El ratio base con el que se sondean los sitios en busca de información. Cambie este parámetro únicamente si se encuentran redes o sistemas lentos. |
2000 |
|
|
El puerto usado para enviar mensajes de gestión a DbSync. |
Ninguno (opcional) |
|
|
Verdadero si SSL se deberá aplicar para conexiones de servicio web entrantes. |
true |
Dentro de la etiqueta <DivaManagers>, pueden aparecer varias definiciones de <DivaManager>. En la Tabla 4-11 se muestran los parámetros que pueden aparecer como parte de una sección de <DivaManager>.
Tabla 4-11 Parámetros de <DivaManagers> para DbSync
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
Dirección URL del servicio en la plataforma de DIVA Manager para uso con sincronización. Por defecto, esto corresponde a la dirección de red del ManagerAdapter remoto, calificada por el WebServicePort usado por ManagerAdapter. |
Ninguno (opcional) |
|
|
El nombre oficial del sitio desde donde se sincronizará la información del objeto. El nombre de sitio que se muestra debe coincidir con lo que se configuró en la base de datos de DIVAnet y lo que está configurado en |
Ninguno (requerido) |
Configure los parámetros de base de datos DIVAnet como se muestra en la Tabla 4-12.
Tabla 4-12 Parámetros de <DIVAnetDatabase>
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
La dirección IP de la base de datos. |
localhost |
|
|
El puerto que se utiliza para acceder a la base de datos. |
1521 |
|
|
El nombre de usuario del esquema. |
Ninguno (requerido) |
|
|
La contraseña del esquema. |
Ninguno (requerido) |
|
|
El SID de Oracle (identificador del sitio). |
lib5 |
|
|
El nombre de Oracle Service. Se puede proporcionar en lugar de |
Ninguno (opcional) |
En DIVAnet, las reglas de acceso se usan para controlar el acceso que tienen las aplicaciones cliente y los usuarios a las operaciones y los recursos de DIVAnet. Las reglas de acceso se pueden ejecutar de tres maneras:
En las solicitudes de DIVAnet dentro del servicio ClientAdapter (en modo MultiDiva).
En las solicitudes de DIVArchive dentro del servicio ManagerAdapter.
En las solicitudes de DIVArchive que entran a ClientAdapter mediante un puerto de modo directo.
Para ejecutar reglas de acceso, deberá definir el parámetro <AccessRulesFilename> en el archivo de configuración ClientAdapter o ManagerAdapter. Debe proporcionar el nombre de archivo sin la ruta: DIVAnet supone que el archivo estará ubicado en el mismo directorio que el archivo de configuración de ClientAdapter.
Los juegos de reglas de acceso definidos en ClientAdapter (modo MultiDiva) aplican control de acceso en las solicitudes de DIVAnet (que se reciben de manera local). Los juegos de reglas de acceso definidos en la configuración de ManagerAdapter aplican control de acceso en las solicitudes de DIVArchive (que se envían para satisfacer una solicitud de DIVAnet). Dos niveles de control de acceso permiten la configuración de reglas de nivel de servicio donde se originan las solicitudes y la aplicación de reglas específicas del sitio que se aplicarán como excepciones a las políticas de nivel de servicio.
Los juegos de reglas de acceso definidos en ClientAdapter (modo directo) aplican control de acceso en las solicitudes de DIVAnet o en las solicitudes de DIVArchive, según si el sistema remoto está en otra instancia de DIVAnet o en un sistema DIVArchive. En este modo, los tipos de operaciones adicionales están disponibles para uso en juegos de reglas. Estas operaciones corresponden a solicitudes específicas de DIVArchive y se detallan a continuación.
Pasemos rápidamente a un ejemplo para conocer mejor las reglas. Las siguientes reglas permiten operaciones de archivo para los usuarios que se conectan como admin u operator desde DATA_EXP_PDAT1 o VID_FTP_3 de Source/Destination (Origen/destino) y operaciones archivado en medios de HDFeatures o spm (notará que el orden de los atributos no es importante), nombrados mediante una categoría que contiene la palabra 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>
En las siguientes dos reglas, los usuarios invitados del perfil de flujo de trabajo de la GUI no tienen permiso para realizar copias de diva2 a diva3, o viceversa.
<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>
Usó dos reglas aquí porque no deseaba restringir explícitamente las operaciones de copiado que se producen dentro del mismo sitio. Por ejemplo, es posible que alguien en el sitio diva2 desee copiar un objeto (mediante DIVAnet) a una cinta nueva; en este caso el nombre del sitio de origen y destino es diva2. Si tenía una única regla que contenía todos los atributos de <SourceSitename> y <TargetSitename>, deberá excluir las copias de diva2 a diva2 y de diva3 a diva3.
Aún no ha finalizado. La copia no será correcta a menos que tenga por lo menos una regla de inclusión que coincida.
<Include> <Operation>Copy</Operation> <WorkflowProfile>GUI</WorkflowProfile> <Username>guest</Username> <Operation>ApiConnect</Operation> </Include>
En este caso, una regla general de inclusión le otorga lo que desea, la capacidad de copiar en cualquier lugar excepto de diva2 a diva3 y viceversa. De hecho, en realidad no necesitaba una regla de exclusión. Sin embargo, en algunos casos las reglas de exclusión son útiles. Tenga en cuenta que si una regla de exclusión coincide con una operación, se denegará la operación, incluso si una o más reglas de inclusión coinciden.
Para resumir, hay dos tipos de reglas, de inclusión y de exclusión. Se rechaza el acceso de todas las solicitudes, a menos que una regla de inclusión coincida con la operación que se llevará a cabo. Sin embargo, si una regla de exclusión coincide, la operación se rechazará automáticamente, independientemente de las reglas de inclusión que coincidan.
En las solicitudes como Delete (Suprimir), Copy (Copiar), Restore (Restaurar), Partial File Restore (Restauración parcial de archivos), Cancel (Cancelar) y Archive (Archivar), DIVAnet ejecuta un juego completo de reglas de acceso para ver si la operación está permitida. Examina variables como:
Atributos de originador: el perfil de flujo de trabajo de la conexión, el nombre de usuario que envió el mensaje, la dirección IP del originador.
Atributos de solicitud: la opción de Source/Destination (Origen/destino), los nombres de sitio de origen/destino, el medio solicitado, los comentarios, etc. Estos se derivan de la solicitud. A muchos de ellos se les agrega el prefijo Req.
Atributos de objeto: los medios en los que se almacena el objeto, el plan de almacenamiento, el tamaño del objeto, etc. Estos se derivan del objeto que procesa una operación. A muchos de ellos se les agrega el prefijo Obj.
La siguiente regla combina los tres tipos de atributos. Permite a un usuario diva realizar una supresión de sitio en Nueva York solamente si el objeto existe en Los Ángeles.
<Include> <Username>diva</Username> <Operation>Delete</Operation> <SubType>SiteDelete</SubType> <TargetSitename>NewYork</TargetSitename> <ObjOnSite>LosAngeles</ObjOnSite> </Include>
Las solicitudes de DIVAnet se generan cuando se reciben solicitudes en modo MultiDiva. Las reglas de acceso se pueden crear para estas operaciones de DIVAnet. A continuación, se proporcionan los detalles de algunos atributos específicos de las solicitudes de DIVAnet.
Las operaciones de ApiConnect y WebConnect son operaciones especiales que se deben incluir para establecer una conexión con ClientAdapter.
ApiConnect: esta operación determina la capacidad de conectarse a ClientAdapter mediante una conexión de socket de cliente de la API. Esto se requiere para las conexiones de la API de DIVA.
WebConnect: esta operación determina la capacidad de las aplicaciones de conectarse mediante conexiones web (DIVAnetUI y DivanetAdmin). Esto se requiere para las conexiones de DIVAnetUI.
Si estas operaciones coinciden con sus reglas, tenga en cuenta que solamente estarán presentes los atributos de originador en la comparación. Por ejemplo, <TargetSitename> no coincidirá si las reglas de acceso se ejecutan durante la operación de ApiConnect, ya que el atributo simplemente no está presente cuando se conecta un cliente.
La operación de supresión tiene un campo <SubType> que representa un subtipo de operación. Puede incluir el campo <SubType> en las reglas junto con la operación de supresión y, si lo desea, puede proporcionar varios parámetros de <SubType>. Los valores para supresión de <SubType> son:
GlobalDelete: coincide si la operación de supresión que se lleva a cabo es una supresión global de un objeto en todos los sitios. Esto también coincide con una operación de supresión de sitio que suprime todos los objetos restantes en DIVAnet.
SiteDelete: coincide si la operación de supresión es una supresión de todas las instancias en un sitio determinado (el nombre del sitio se puede asociar con las reglas que usan el parámetro <TargetSitename>). Además, usa operación tendrá este <SubType> si el solicitante está suprimiendo una única instancia, pero que es la última instancia del objeto en ese sitio.
InstanceDelete: esta operación de supresión suprime una única instancia en un sitio y hay otras instancias en el sitio.
La especificación de este parámetro en reglas es útil para aplicar el alcance de las operaciones de supresión permitidas.
DIVAnet también permite la ejecución de reglas de acceso en solicitudes de DIVArchive. Las reglas de acceso definidas en ManagerAdapter especifican cuáles operaciones de DIVArchive (que se envían para satisfacer las solicitudes de DIVAnet) se permiten. Solamente las operaciones válidas para las solicitudes de DIVAnet se pueden especificar en los juegos de reglas. En los juegos de reglas de ManagerAdapter, los atributos WorkflowProfile, TargetSitename y SubType no son válidos.
De manera similar a los juegos de reglas de ClientAdapter, se debe garantizar la operación de WebConnect para que se establezcan conexiones con ManagerAdapter. Esto también se extiende a las operaciones de DbSync. El atributo SourceSitename corresponde al sitio específico que realiza una solicitud. La operación ApiConnect no está disponible en las reglas de acceso de ManagerAdapter.
La asociación de reglas involucra la comparación de los atributos de la regla con los valores actuales de cada solicitud, en un objeto coincidente o en el originador de la solicitud. Se permiten los comodines (use un asterisco (*) para los comodines). Los nombres de etiquetas no distinguen entre mayúsculas y minúsculas, pero la mayoría de los valores sí distinguen entre mayúsculas y minúsculas. Se requiere la etiqueta <Operation> en cada regla. Puede proporcionar una etiqueta <Operation> que contenga un asterisco (*) para indicar que la regla se aplica para todas las operaciones. Sin embargo, debe tener cuidado cuando realiza esto porque no todos los atributos son válidos para todas las operaciones.
Diferentes atributos en una regla (una regla de inclusión o exclusión) se unen lógicamente mediante AND en el proceso de asociación. Sin embargo, un único atributo especificado más de una vez en una regla hace que los atributos de unan lógicamente mediante OR en una única expresión.
Cuando se asocia una operación solicitada con una regla de acceso, DIVAnet determina si el atributo de la regla se aplica para la operación que se está realizando. De lo contrario, el atributo no se usará en la comparación.
Las reglas se pueden agrupar en juegos de reglas. Cada regla de inclusión-exclusión debe estar contenida dentro de las etiquetas <Ruleset>. Todas las operaciones entrantes de DIVAnet se asocian con todos los juegos de reglas. Los juegos de reglas son útiles porque pueden tener atributos que funcionan como valores por defecto para todas las reglas contenidas. En el proceso de asociación, cada atributo de juego de reglas por defecto se agrega a cada regla secundaria, como si el atributo se especificara directamente dentro de la regla. Es común usar el perfil de flujo de trabajo como atributo por defecto para juegos de reglas, ya que el perfil de flujo de trabajo se completa en todas las operaciones de DIVAnet solicitadas.
Los siguientes atributos se pueden marcar como atributos por defecto dentro de un juego de reglas:
Username
NetAddress
WorkflowProfile (en reglas de ClientAdapter)
El siguiente ejemplo permite a los usuarios conectados con <WorkflowProfile> de la GUI ver las solicitudes y los activos, y realizar supresiones de instancias individuales en el sitio diva1. Recuerde que <SubType> de InstanceDelete rechazará las supresiones que podrían eliminar la última instancia de un objeto determinado en un sitio.
La segunda parte del ejemplo prohíbe todas las conexiones, ya sea mediante web o conexiones de API, que se originan desde la subred 172.53. Realizará esto para cualquier operación, independientemente del perfil de flujo de trabajo.
<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>
En la Tabla 4-13 se muestran los parámetros que pueden aparecer en la sección <Ruleset>.
Tabla 4-13 Parámetros de juego de reglas
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
Este atributo, definido en la configuración de ClientAdapter, es el nombre de un grupo de trabajo o juego de aplicaciones que acceden a DIVAnet. Este atributo forma parte de todas las reglas en el juego de reglas. |
Ninguno (opcional) |
|
|
El nombre de usuario transmitido en la API o especificado en la solicitud web. Este atributo forma parte de todas las reglas en el juego de reglas. |
Ninguno (opcional) |
|
|
La dirección de red (IP o nombre de Internet) de la conexión remota. Esta puede ser la dirección de una puerta de enlace o enrutador, y no la dirección del originador. Este atributo forma parte de todas las reglas en el juego de reglas. |
Ninguno (opcional) |
|
|
Regla que rechaza el permiso si coincide con la operación de DIVAnet. |
Ninguno (opcional) |
|
|
Regla que admite el permiso si coincide con la operación de DIVAnet. |
Ninguno (opcional) |
Puede especificar los atributos de regla que aparecen en las solicitudes. Por ejemplo, <ReqMedia> coincidirá con el medio o con el plan de almacenamiento especificado en una (operación de) solicitud.
De manera similar, puede especificar los atributos de regla que coinciden con el objeto archivado que la solicitud está procesando. Por ejemplo, si se especifica un determinado objeto en una operación de supresión, <ObjHasMedia> coincidirá con cualquier medio que se parte del objeto archivado, independientemente del objeto archivo transmitido en la solicitud.
En la Tabla 4-14 se muestran los parámetros que pueden aparecer dentro de la sección de la regla <Include> o <Exclude>.
Tabla 4-14 Parámetros operativos de regla (de inclusión o exclusión)
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
El nombre de la operación de DIVAnet que se asociará:
Hay operaciones adicionales disponibles para las operaciones der DIVArchive en el modo directo:
|
Ninguno (opcional) |
|
|
El nombre de usuario del usuario de la API conectado o el usuario del servicio. |
Ninguno (opcional) |
|
|
Nombre del perfil de ClientAdapter. |
Ninguno (opcional) |
|
|
La dirección IP de la aplicación de la API o el usuario. |
Ninguno (opcional) |
|
|
El nombre del sitio de origen de la operación. Algunas operaciones no tienen un nombre de sitio de origen (por ejemplo, Archive tiene Source/Destination como origen). Si se reintenta la solicitud en otro sitio, este valor cambiará y la regla completa se reevaluará. Cuando este atributo aparezca en las reglas de ManagerAdapter, se asociará con el sitio que envió la solicitud. |
Ninguno (opcional) |
|
|
El nombre del sitio de destino de la operación. Algunas operaciones no tienen un nombre de sitio de destino (por ejemplo, Restore tiene Source/Destination como destino). Si se reintenta la solicitud en otro sitio, este valor cambiará y se reevaluará la regla completa. |
Ninguno (opcional) |
|
|
Tipo de operación en modo Multi DIVA (el comando Delete tiene GlobalDelete, SiteDelete e InstanceDelete). |
Ninguno (opcional) |
Tabla 4-15 Parámetros de solicitud de regla (de inclusión o exclusión)
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
Nombre del objeto que se está procesando. |
Ninguno (opcional) |
|
|
Categoría del objeto (en DIVArchive esto es parte del nombre formal del objeto). |
Ninguno (opcional) |
|
|
El Source/Destination (Origen/destino) especificado en la solicitud. |
Ninguno (opcional) |
|
|
El campo de comentarios en la solicitud. |
Ninguno (opcional) |
|
|
Los medios que se solicitaron como parte de la operación/solicitud (el nombre del sitio no se debe agregar). Tenga en cuenta que el plan de almacenamiento se puede transmitir al medio solicitado. |
Ninguno (opcional) |
|
|
El campo de opciones en la solicitud. |
Ninguno (opcional) |
Tabla 4-16 Parámetros de objeto de regla (de inclusión o exclusión)
| Parámetro | Descripción | Valor por defecto |
|---|---|---|
|
|
Se asocia si el objeto existe en el sitio especificado. |
Ninguno (opcional) |
|
|
Se asocia si el objeto NO existe en el sitio especificado. |
Ninguno (opcional) |
|
|
Se asocia con cualquier medio en cualquier sitio. |
Ninguno (opcional) |
|
|
Se asocia con un plan de almacenamiento en cualquier sitio ( |
Ninguno (opcional) |
|
|
Restringe el plan de almacenamiento especificado a un sitio específico. |
Ninguno (opcional) |
|
|
Se asocia si el tamaño total de objeto en GB fraccionales es menor que el valor especificado. |
Ninguno (opcional) |
|
|
Se asocia si el tamaño total de objeto en GB fraccionales es mayor que el valor especificado. |
Ninguno (opcional) |
DIVAnet permite la sustitución de variables en archivos de configuración para facilitar la configuración de varios archivos de secuencia de comandos. Si se encuentra el patrón ${variable_name} en un valor XML (las variables no son válidas en nombres de etiquetas), el valor de la variable se sustituye cuando DIVAnet lee la secuencia de comandos. El valor se puede tomar de una variable del entorno o se puede asignar directamente dentro de la secuencia de comandos.
Si el nombre de la variable de la secuencia de comandos se denomina de la misma manera que la variable del entorno, el valor de esa variable se sustituirá en la secuencia de comandos. De manera alternativa, pude definir valores de variables en la parte superior de cada secuencia de comandos mediante la etiqueta <Variable>. La sintaxis es: <Variable name="LocalSitename" value="diva1"/>. Cuando DIVAnet lee una secuencia de comandos de configuración, comprueba si las variables que se usan dentro de la secuencia de comandos se han definido en la parte superior. De lo contrario, busca una variable del entorno con el mismo nombre que la variable.
Para mayor facilidad de uso, el archivo de secuencia de comandos con el nombre divanetEnv.conf se crea dentro del directorio raíz de DIVAnet, en la subcarpeta Program\conf\divanet\wrapper. Las variables se pueden definir de manera central en este archivo ce configuración y estarán disponibles para todos los servicios de DIVAnet. Si los valores se cambian y se reinicia el servicio, se volverán a leer los cambios. Consulte el archivo divanetEnv.conf para obtener variables de muestra.