HOW TO: Configuración de Conectores

De Thubanpedia
Saltar a: navegación, buscar


HOW TO: Configurar un conector

Paso 1 - Agregar librerías correspondientes a cada conector

Cada conector trae asociado un conjunto de librerías que deben ser incluidas en el “classpath” de la maquina virtual del servidor de aplicaciones. Esto puede realizarse de diversas formas:

  • Incluir los archivos en la carpeta “/WEB-INF/lib” del WAR que se desea desplegar (Recomendado).
  • Incluir los archivos en la carpeta de librerías del servidor de aplicaciones.
  • En tomcat la carpeta es “TOMCAT_HOME\shared\lib”.
  • En JBoss la carpeta es “server\default\lib”.

Paso 2 – Configuración de user-application-context.xml

“user-application-context.xml” es un archivo que permite redefinir componentes del sistema para que se ajusten a las necesidades de cada organización. La plataforma utiliza Spring como framework de inyección de dependencias. Esto permite definir de manera declarativa las relaciones entre componentes. Por defecto, este archivo se encuentra vacío. La solución, en su configuración por defecto, se encuentra configurada para utilizar el conector Thuban® únicamente, por lo que, lo primero que debemos hacer, es reemplazar el “Resource Service” por uno que nos permita trabajar con múltiples conectores. Para ello agregaremos en “user-application-context.xml” la siguiente definición del servicio.


<bean id="resourceService" class="com.latintech.thuban.services.locator.ThubanResourceServiceLocatorImpl">
       <property name="migrationStrategy" ref="migrationStrategy"/>
       <property name="migrationService" ref="migrationService"/>
       <property name="defaultResourceService" value="Thuban"/>
       <property name="storeDAO" ref="storeDAO"/>
       <property name="resourceServices">
                 <map>
                      <entry>
                               <key><value>Thuban</value></key>
                               <ref bean="thubanResourceService"/>
                      </entry>
                 </map>		
       </property>
</bean>


Como se puede observar, estamos definiendo un bean que se denomina “resourceService” de la clase “com.latintech.thuban.services.locator.ThubanResourceServiceLocatorImpl” y que cuenta con 6 parámetros:

  • migrationStrategy : Es una clase que determina si un id de documento consultado debe ser migrado y en caso de que si, a que conector debe migrarse.
  • migrationService: Es el servicio que, una vez determinado que un ítem debe migrarse, realizará la migración en sí.
  • defaultResourceService: Es el nombre del conector por defecto definido para la aplicación. Este conector es utilizado cuando el nombre del conector no se encuentra asignado en la tabla STORE de un documento.
  • storeDAO: Es un objeto que realiza el acceso a datos de la base relacional. Este objeto ya viene configurado en la plataforma. Por lo general existirá un DAO por cada tabla que existe en el modelo de base de datos.
  • resourcesServices: Es un mapa nombre-servicio de servicios de recursos con los que cuenta. En este caso se indica que para recuperar aquellos documentos existentes en Thuban® se debe utilizar “thubanResourceService”. El mismo ya se encuentra configurado en Thuban®.

A continuación debemos definir aquellos bean que hemos referenciado en este nuevo “bean” y no vienen configurados en la plataforma por defecto. migrationStrategy:


<bean id="migrationStrategy" class="com.latintech.thuban.services.migration.ConectorMigrationStrategyImpl">
         <property name="storeDAO" ref="storeDAO"/>
         <property name="connectors">
             <map>
                  <entry>
                               <key><value>Global360</value></key>
                               <value>Thuban</value>
                             </entry>
             </map>
         </property>
         <property name="defaultConnector" value="Thuban"/>
</bean>


Como mencionamos anteriormente, la estrategia de migración determina en base al id de un documento, si el mismo debe ser migrado y a que conector. En este caso estamos configurando una estrategia de migración que decide si debe migrar en base al conector donde se encuentra actualmente el documento. La propiedad “connectors” es un mapa que determina conector origen – conector destino. En este caso, solo posee una entrada que indica que todos los documentos que actualmente se encuentran en Global360 serán migrados a Thuban® a medida que sean consultados. La propiedad “defaultConnector” le indica que considere a aquellos documentos que no tienen un conector asignado en el STORE como si fuesen de ese conector. migrationService:

 <bean id="migrationService" class="com.latintech.thuban.services.locator.ThubanMigrationServiceLocatorImpl">
     <property name="migrationServices">
          <map>
                  <entry>
                               <key><value>Global360-Thuban</value></key>
                               <ref bean="global2ThubanMigrationService"/>
                        </entry>
          </map>
     </property>
</bean>


El migrationService es el servicio que, una vez determinado que un ítem debe migrarse, realizará la migración en sí. Para ello configuraremos un servicio de migración genérico que se encargará de delegar al servicio de migración que corresponda. La propiedad migrationServices es un mapa que referencia a cada migrador de documentos. El nombre del migrador debe estar compuesto por [ConectorOrigen]-[ConectorDestino]. De esta manera el servicio de migración sabe que cuando le soliciten migrar un documento del Global360 hacia Thuban® deberá utilizar el servicio de migración “global2ThubanMigrationService”.

global2ThubanMigrationService:


<bean id="global2ThubanMigrationService" class="com.latintech.services.migration.Global2ThubanServiceV6">
       <property name="storeDAO" ref="storeDAO"/>
       <property name="noteDAO" ref="noteDAO"/>
       <property name="fieldDAO" ref="fieldDAO"/>
       <property name="sqlDAO" ref="sqlDAO"/>
       <property name="config" ref="global2ThubanConfig"/>
       <property name="resourceService" ref="resourceService"/>
</bean>

Propiedades:

  • storeDAO, noteDAO, fieldDAO y sqlDAO son objetos que realizan el acceso a datos de la base relacional. Estos objetos ya viene configurados en la plataforma.
  • resourceService: Es una referencia al bean que definimos como primer paso de este tutorial.
  • config: Es un objeto que recupera las configuraciones propias del migrador.

global2ThubanConfig:

<bean id="global2ThubanConfig" class="com.latintech.thuban.config.Global2ThubanConfigImpl">
       <property name="sessionFactory" ref="hibernateSessionFactory"/>
       <property name="application" value="THUBAN-SERVER"/>
       <property name="set" value="DEFAULT"/>
</bean>

Propiedades:

  • sessionFactory: Una referencia a la factory de sesiones de hibérnate. Este objeto ya viene configurado en la plataforma.
  • application: Es el nombre de la aplicación en la configuración de la tabla THUBAN_CONFIG.
  • set: Es el SET de configuración seleccionado de la configuración de la tabla THUBAN_CONFIG.

Paso 3 – Configuración especifica de conectores

Conector On Demand

El conector On Demand permite consultar y almacenar documentos en un repositorio de OnDemand (IBM). El servicio requiere de algunos parámetros en la base de datos para su correcto funcionamiento. Dichos parámetros pueden configurarse a través de la herramienta Thuban® Admin.

APP SET SECTION VARIABLE Descripción
THUBAN-SERVER DEFAULT ONDEMAND Endpoint Endpoint del Web Service que recupera la imágenes para el proceso batch de upload de documentos a a OnDemand.
THUBAN-SERVER DEFAULT ONDEMAND CarpetaTemporal Path completo de la carpeta donde se almacenan los archivos temporales.
THUBAN-SERVER DEFAULT ONDEMAND SelectDeletedFiles El select utilizado para determinar que documentos fueron eliminados en Thuban®.
THUBAN-SERVER DEFAULT ONDEMAND SelectUploadFiles_<CLASE_DOCUMENTAL> El select utilizado para determinar que documentos deben ser subidos al repositorio onDemand. Existe una entrada de este tipo por cada clase documental.
THUBAN-SERVER DEFAULT ONDEMAND OnDemandDeleteOutputFile_<CLASE_DOCUMENTAL> La ruta de salida del archivo con los IDS a eliminar en OnDemand. Existe una entrada de este tipo por cada clase documental.
THUBAN-SERVER DEFAULT ONDEMAND OnDemandDeleteOutputFile_<CLASE_DOCUMENTAL> La ruta de salida del archivo con los IDS a eliminar en OnDemand (incluyendo nombre de archivo y extensión). Existe una entrada de este tipo por cada clase documental.
THUBAN-SERVER DEFAULT ONDEMAND OnDemandUploadOutputFolder_<CLASE_DOCUMENTAL> La ruta de la carpeta de salida de los documentos a subir a OnDemand. Existe una entrada de este tipo por cada clase documental.
THUBAN-SERVER DEFAULT ONDEMAND OnDemandUploadLogPath_<CLASE_DOCUMENTAL> La ruta de salida del archivo de log generado por el UploadManager.

Existe una entrada de este tipo por cada clase documental.

THUBAN-SERVER DEFAULT ONDEMAND OnDemandDeleteLogPath_<CLASE_DOCUMENTAL> La ruta de salida del archivo de log generado por el DeleteManager.

Existe una entrada de este tipo por cada clase documental.

THUBAN-SERVER DEFAULT ONDEMAND OnDemandServerName Nombre del servidor OnDemand.
THUBAN-SERVER DEFAULT ONDEMAND DeletedFilesLog_<CLASE_DOCUMENTAL> Ruta en la cual deposita OnDemand el resultado de la eliminación de documentos.

Existe una entrada de este tipo por cada clase documental.

THUBAN-SERVER DEFAULT ONDEMAND DeletedFilesLogAnalyzerLogPath_<CLASE_DOCUMENTAL> La ruta de salida del archivo de log generado por el DeletedFilesLogAnalyzer.

Existe una entrada de este tipo por cada clase documental.

THUBAN-SERVER DEFAULT ONDEMAND UploadedFilesLog_<CLASE_DOCUMENTAL> Ruta en la cual deposita OnDemand el resultado de la eliminación de documentos.

Existe una entrada de este tipo por cada clase documental.

THUBAN-SERVER DEFAULT ONDEMAND UploadedFilesLogAnalyzerLogPath_<CLASE_DOCUMENTAL> La ruta de salida del archivo de log generado por el UploadedFilesLogAnalyzer.

Existe una entrada de este tipo por cada clase documental.


Migrador Eastman Software - Thuban®

El Migrador Eastman Software – Thuban® permite migrar documentos almacenados en Eastman Software (versión 4 o 6). Funciona tanto en esquemas de single sign-on como por validación de usuarios de Eastman. El servicio migrador solo funciona con un único usuario de Eastman Software. Cuando más de un usuario de Thuban® se encuentra consultando un ítem que debe ser migrado, los pedidos al migrador se encolan. El servicio requiere de algunos parámetros en la base de datos para su correcto funcionamiento. Dichos parámetros pueden configurarse a través de la herramienta Thuban® Admin.

APP SET SECTION VARIABLE Descripción
THUBAN-SERVER DEFAULT Configuration attachmentsDirectory Ruta de la carpeta de temporales para archivos a migrar.
THUBAN-SERVER DEFAULT Configuration CamposMigrables Listado de campos de la clase documental que deben ser migrados junto con el archivo al consultar el ítem.
THUBAN-SERVER DEFAULT Global360 Usuario Nombre de usuario de Global360
THUBAN-SERVER DEFAULT Global360 Password Password del usuario de Global360
THUBAN-SERVER DEFAULT Global360 Dominio Nombre del dominio de Global360


Particularidades

  • Eastman Software Versión 4: Esta versión tiene la particularidad de que las APIs desarrolladas en JAVA requieren además de que las Client Components de Eastman se encuentren instaladas en el servidor y el archivo jal.dll se encuentre en la ruta indicada por la propiedad “java.lib.path” de la maquina virtual del servidor de aplicaciones. Por defecto, esta carpeta es “JAVA_HOME/bin”.
  • Eastman Software Versión 6: Con la configuración indicada anteriormente (user-application-context.xml + parámetros en ThubanConfig) funciona correctamente.

Nota: Es posible utilizar la versión 6 del migrador contra un servidor instalado con la versión 4 de Eastman Software para evitar la instalación de las client components y el uso de librerías nativas pero solo funciona cuando no se utiliza Single Sign-On.

  • Eastman Software (Ambas versiones): A veces es necesario agregar un archivo de configuración regional denominado "LOCALE" en la carpeta "SYSOBJ" de Eastman Software para que la API funcione correctamente. El archivo se debe llamar LOCALE (sin extensión) y debe contener lo siguiente:

DECIMAL=.

GROUPING=,

CHARSET=windows-1252,iso-8859-1

Paso 4 – Validación y Prueba

Lo primero que debemos validar es que no existan errores de sintaxis ni de definición de beans del xml de configuración. Con solo iniciar el servidor de aplicaciones, si el log no reporta errores del tipo BeanDefinitionParsingException o BeanCreationException nos aseguramos que la sintaxis y las relaciones entre componentes que especificamos en el archivo de configuración son correctas. Cabe aclarar que existen errores que podrán manifestarse en tiempo de ejecución, por lo que, la mejor forma de validar que uno o más conector/es están funcionando correctamente es probando cada escenario posible de consulta / migración. Lo más importante a tener en cuenta es que variables utiliza el sistema para saber cuándo migrar o no un documento. La tabla THUBAN_STORE contiene la información común en todos los documentos del sistema (fecha de creación, modificación, cantidad de páginas, etc). En esta tabla existen dos columnas importantes a la hora de testear la configuración de un conector:

  • STORE_CONNECTOR: Representa el nombre del conector en el cual se encuentra almacenado el documento.
  • STORE_CONNECTOR_ID: Representa el ID del documento en el conector que lo almacena.

Utilizando estas 2 columnas se pueden configurar documentos en los distintos conectores para probar los esquemas de consulta y migración de los mismos.