Última revisión de 06:43 29 ene 2016

Enlaces relacionados:

• Configuraciones útiles

• Resguardo de la información

Organización de los contenidos

Thuban® utiliza un repositorio de archivos para almacenar los contenidos, con el fin de evitar una sobrecarga en la base de datos y una consecuente disminución de su rendimiento.

Cada clase documental define una ubicación propia de almacenamiento. De acuerdo con esa ubicación, el sistema almacena los documentos en subcarpetas, en donde guarda un máximo de archivos predefinido. Una vez que se alcanza ese tope, los archivos subsiguientes se almacenan en otras subcarpetas. Las subcarpetas de un sistema de archivos se denominan Store Units. Cada una de ellas puede ser congelada para evitar posteriores modificaciones y facilitar la gestión de backups.

Los archivos se almacenan dentro del repositorio de datos sin encriptación, respetando su formato original.

No existen restricciones respecto del tipo de archivo que puede almacenar en el sistema de archivos de una clase documental. Sin embargo, siempre es recomendable que el sistema operativo sepa interpretarlo y sepa cómo realizar una previsualización para adquirir una mayor flexibilidad. El espacio para almacenamiento de imágenes bitonales es de aproximadamente 50kb por hoja. Así, si se estima un crecimiento de 500.000 imágenes mensuales, se debe garantizar un espacio de almacenamiento de 24 GB.

Indexación de los contenidos

En Thuban®, todo documento es indexado mediante bases de datos relacionales. Cada clase documental se almacena en una tabla: puede ser la tabla en la que se almacenan los documentos por defecto (THUBAN_INDEXES) o una tabla particular para esa clase documental. Se recomienda utilizar una tabla para cada clase documental con el fin de optimizar la indexación, rendimiento y distribución de la base de datos.

Los campos de una clase documental son configurados en la tabla THUBAN_FIELDS. A diferencia de otras tecnologías de administración y consulta de documentos digitales que trabajan con un único tipo de dato, Thuban® permite definir un conjunto de tipos de datos para los campos de una clase documental. Esto permite esquivar problemas de conversión de datos e incrementar la eficiencia en la búsqueda de documentos, a través del uso de documentos en formato nativo sin conversión en las consultas a la base de datos.

Es recomendable crear índices en la base de datos para mejorar el rendimiento de las búsquedas de documentos. El sistema provee la posibilidad de configurar índices compuestos; esto es, configurar una acción de búsqueda conjunta de dos índices diferentes.

Siempre es aconsejable buscar por un campo índice y refinar la búsqueda con algún campo complementario.

Para obtener mejoras en el rendimiento de la solución general, es posible limitar los resultados de búsquedas por cada usuario o a través de la creación del usuario por defecto (Para obtener más información sobre la configuración de estos usuarios ver Configuración básica de la solución).

Configuración básica de la Solución

Thuban® está diseñada para ser utilizada tanto en ambientes pequeños, donde un mismo administrador configura todos los parámetros del sistema; como en ambientes empresariales, donde existen roles diferenciados para la administración de configuraciones y seguridad informática.

La configuración del entorno es fundamental para asegurar el correcto desempeño de la aplicación. Para su parametrización se debe definir un conjunto de variables. Esto incluye la conexión a la base de datos, la localización de archivos o carpetas dentro del sistema de archivos, la definición de cuentas y/o plantillas de correo electrónico, archivos de Scripting y la configuración de servicios propios para una organización particular.

La estructura de entorno de Thuban® contiene seis carpetas: Context, Forms, Templates, Scripting, Images y Security.

Para comenzar a utilizar Thuban® no se requieren todos los archivos, puesto que existe una configuración mínima que permite iniciar el sistema con la funcionalidad básica.

Para ello se necesitan los siguientes archivos:

1) Configuración de contexto.

2) Configuración de seguridad.

3) Configuración de parámetros de log y carpetas temporales en el servidor.

4) Creación del usuario por defecto.

Carpeta Context

La carpeta Context almacena los archivos relacionados con la configuración del entorno. Permite no sólo la parametrización básica de la solución, sino también la personalización de la instalación.

Por lo general, el contenido de la carpeta incluye los siguientes archivos y subdirectorios:

Por defecto, la ubicación de las carpetas Forms, Images, Scripting y Templates es en la carpeta Context; sin embargo, si se utilizan las siguientes variables, es posible configurar otra ubicación a través del módulo de configuración de parámetros del sistema:

context.properties

Este archivo contiene la configuración del contexto (Base de datos, servidor LDAP, SMTP, carpetas temporales, templates de mails, dirección de soporte, etc.). La ubicación de este archivo en el sistema de archivos no tiene ningún tipo de restricción. El servidor de aplicaciones obtiene la ruta de acceso al mismo mediante la variable de la máquina virtual de Java THUBAN_CONTEXT. Si se utiliza Java 1.5 o superior, puede ser configurada como variable de entorno del sistema operativo.

El contenido del archivo es el siguiente:

#CONFIGURACION DE LDAP
ldap.host= ldap://vmware-2003-2:389
ldap.base= dc\=lat,dc\=ar
ldap.enableGroupSync= true
ldap.rootGroup= Thuban
ldap.enableUserSync= true
ldap.name= LAT
ldap.user.attributeId= sAMAccountName
ldap.user.attributeName= name
ldap.user.attributeDistinguishedName= distinguishedName
ldap.user.attributeMemberOf= memberOf
ldap.user.attributeEmail=
ldap.user.attributeArea=
ldap.user.attributePhone= 

#CONFIGURACION DE JDBC
jdbc.driverClassName= net.sourceforge.jtds.jdbc.Driver
jdbc.url= jdbc:jtds:sqlserver://127.0.0.1:1433/thuban_web

#HEADER MAIL
thuban.mail.alias=Sender

#MAIL TEMPLATES
thuban.mail.template.support.html=supportHtml.vm
thuban.mail.template.support.txt=supportTxt.vm

#THUBAN SUPPORT 
thuban.mail.support=soporte@latin-tech.com

La propiedad thuban.mail.support guarda la dirección de correo a la que el sistema envía los errores producidos en la aplicación. Ante la presencia de errores más o menos graves, el sistema muestra un cuadro de diálogo (ver Imagen a continuación) que da la posibilidad de enviar un mail al Departamento de soporte, para notificar el tipo de error. Ese mail llega a la casilla previamente determinada en context.properties.

Para más información acerca la configuración del contexto, véase el apartado de integración con LDAP.

user-application-context.xml

Permite definir un conjunto de servicios propios de un cliente y externos al núcleo aplicativo. Estos pueden hacer referencia a entidades que describan la lógica particular de un cliente y que son ajenas al sistema. Esas entidades se requieren para recuperar o mantener información en la base de datos del cliente. Este archivo fue creado con el objeto de excluir las entidades externas de Thuban® y mejorar así la interoperabilidad entre Clientes.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">
<bean id="customerService" class="com.latintech.thuban.services.CustomerServiceImpl">
    <property name="sessionFactory" ref="hibernateSessionFactory" />
    <property name="adminService"   ref="adminService"/>
</bean>
</beans>

Carpeta Scripting

La carpeta Scripting almacena los archivos de scripting de clases documentales. Para más información, véase el apartado Personalización de la solución – Scripting de clases documentales.

Carpeta Forms

La carpeta Forms almacena los archivos de scripting de formularios electrónicos. Para más información, véase el apartado Personalización de la solución – Scripting formularios electrónicos.

Carpeta Templates

En esta carpeta se alojan todas las plantillas de e-mail utilizadas por Velocity. Aquí se completan con información dinámica y posteriormente se genera el código HTML que se envía por medio de los servicios internos de correo electrónico de Thuban®. Todos los archivos tienen extensión ".vm".

Existen dos tipos de archivos: los HTML y otros con texto plano para ser interpretado por cualquier tipo de cliente de correo.

Carpeta Images

Incluye un conjunto de imágenes relativas a la aplicación y al cliente. Por ejemplo, logos empresariales o imágenes que contienen palabras o referencias en algún idioma particular de acuerdo al LOCALE que utilice el cliente y que no sea soportado por Thuban®.

Carpeta Security

security.properties

El archivo security.properties posee la configuración de usuarios y contraseñas, de conexión a la base de datos, SMTP de correo y cualquier otro usuario que se utilice en integraciones con otros sistemas. Al igual que el archivo context.properties, se pueden ubicar en cualquier locación y el servidor puede obtener la ruta de acceso mediante la variable de la máquina virtual de Java THUBAN_SECURITY. Si se utiliza Java 1.5 o superior, puede configurarse con variable de entorno del sistema operativo.

El contenido del archivo es el siguiente:

#CONFIGURACIÓN SEGURIDAD
jdbc.username=thuban
jdbc.password=************

Además, es posible encriptar las contraseñas almacenadas en este archivo.

Configuración de parámetros de log y carpetas temporales en el servidor

Thuban® Admin cuenta con un módulo de configuración de parámetros del sistema. Para configurar las rutas de log y las carpetas temporales del sistema se deben establecer los siguientes valores:

Configuración de usuarios por defecto

Para establecer una configuración por defecto para todos los usuarios de Thuban, diríjase a la última pestaña del Panel de políticas de acceso.

Allí verá una serie de cinco pestañas que permiten establecer ciertos parámetros en común para todos los usuarios.

• General: Desde esta solapa se pueden configurar algunas características como un formato estándar para la fecha y hora, o una pantalla de inicio predeterminada.

Para resolver el problema de la incompatibilidad con Internet Explorer puede seleccionar esta opción o visitar la sección HOW TO: Resolver incompatibilidad de Thuban con IE

• Creación: Desde esta pestaña se puede seleccionar la opción para que cuando se cree un documento de una clase documental que tenga vínculos dinámicos, dicho documento se abra en una nueva ventana.

Pestaña Creación

• Búsqueda: Desde esta pestaña se pueden configurar acciones generales sobre la grilla de resultados de la búsqueda.

Pestaña Búsqueda

• Edición: Desde esta pestaña se pueden configurar acciones generales de la pantalla de edición de documentos.

Pestaña Edición

• Bandejas: Desde esta pestaña se pueden configurar acciones generales del Panel de bandejas.

Pestaña Bandejas

• Monitores: Desde esta pestaña se pueden configurar el refresco automático de todos los monitores de Thuban. Si desea modificar el tiempo para un monitor en particular, podrá hacerlo desde Thuban Server.

Pestaña Monitores

Recomendaciones para entornos de producción

Se recomienda establecer el nivel de log de la aplicación en ERROR y eliminar cualquier invocación de System.out que pueda existir en archivos de scripting del sistema. La generación de logs de este tipo con una concurrencia alta de usuarios impacta notablemente en el rendimiento del sistema.

Seguridad

El sistema de seguridad de Thuban® está organizado sobre la base de grupos de usuarios. Cada grupo de usuarios recibe un conjunto de permisos configurados por el administrador; por esa razón no existe la posibilidad de asignar permisos a usuarios particulares de manera directa.

La seguridad de los documentos depende de la clase documental y hay una gran especificidad de acciones que se pueden realizar sobre ellos.

Un usuario puede pertenecer a más de un grupo, lo que facilita la definición y gestión de los perfiles. Además, es posible integrar la asignación a grupos con LDAP; en ese caso, cuando el administrador asigna una persona a un grupo LDAP, le otorga simultáneamente un usuario y un perfil de acceso Thuban®.

La herramienta de administración también permite otorgar permisos sobre cada uno de los módulos del sistema y sobre las funciones que puede realizar en la aplicación un usuario en particular. Es decir, para un grupo de usuarios particular se puede habilitar la búsqueda de documentos y para otro, su creación. Ningún grupo de usuarios puede acceder a una función sin tener el permiso correspondiente.

Los logs ayudan a incrementar la seguridad de la plataforma: permiten almacenar toda la información de bajo nivel que se realiza dentro de la aplicación en un momento determinado. Es posible verificar en qué momento un documento fue modificado, qué tipo de cambios se hicieron sobre los campos, etc.

Configuración de Perfiles de Escaneo

Para configurar los perfiles de escaneo se deben establecer las siguientes entradas:

Luego, por cada nombre de servidor se deben establecer las siguientes entradas:

Además se deberá configurar por lo menos un perfil. Cada perfil contiene las siguientes propiedades:

El <nombrePerfil> es el valor que aparece en el combo de perfiles de escaneo en la interfaz de usuario.

Además se debe configurar si el applet de escaneo visualiza los documentos en alta o baja calidad. Esto no afecta a la imagen en sí, sólo su visualización (se mejora el rendimiento si el valor es false).

Ejemplo de configuración:

Mantenimiento del sistema

Logs

Por cada aplicación desplegada en el servidor de aplicaciones, Thuban® genera un archivo de log exclusivo. El nombre del archivo de log que se genera es igual al nombre del contexto con el que la aplicación fue desplegada en el servidor. Así, si un servidor desplegó a la vez las aplicaciones Thuban® Power DeskWeb y Thuban® Server, tendrá dos archivos diferenciados.

La ruta para acceder a esos logs está unificada y se configura a través de la herramienta Administración (Ver “Configuración básica de la solución”). Además, los archivos de log poseen un límite; cuando se alcanza, el sistema genera un backup y crea un nuevo archivo. El sistema almacena hasta diez backups de archivos de log. El backup se guarda y comienza con uno limpio cuando el servidor (o el contexto de la aplicación) se reinicia.

Además, Thuban® utiliza una tabla de logs (THUBAN_LOGS) para registrar los eventos originados por alguna de las aplicaciones que forman parte de la plataforma.

Los eventos que generan registro de logs son:

- Login de Usuario

- Logout de Usuario

- Creación de un documento

- Modificación de un documento

- Modificación de un campo de documento marcado como auditable. Esto genera una entrada en la tabla Logs para registrar la modificación del valor del campo, en donde se describen el valor original y su nuevo valor.

Todos los registros recogen la fecha, la hora y el usuario que realizó la acción.

Auditoría

La plataforma Thuban® genera los siguientes eventos de auditoría asociados con la herramienta de administración y configuración de la solución. Cada evento de log registra la fecha, la hora, la dirección IP y el usuario que ejecutó la acción. En caso de modificar un permiso de acceso, también se registra la clase documental.

Login/Logout

Administración de Documentos

Administración de usuarios

Administración de grupos

Administración de Configuración

Administración de clases

Administración de Accesos

Administración de Políticas de acceso

Jobs

Los Jobs son procesos que se pueden planificar en Thuban® Server para ser ejecutados según una determinada agenda de trabajo. A continuación se describen los procesos actualmente soportados por la plataforma out of the box ("lista para usar"). Los nombres de clase y parámetros son case sensitive (capaz de distinguir entre mayúsculas y minúsculas).

Además, es posible desarrollar procesos personalizados para cada organización y planificarlos de la misma forma que otros jobs del sistema.

Personalización de la solución

Scripting en Thuban

¿Qué es y para qué sirve el scripting en Thuban?

El scripting es código Java con mezcla de componentes y eventos Web. En Thuban, el scripting se convierte en una forma versátil de personalizar el sistema y de ajustarlo a las necesidades particulares de cada solución.

¿Qué se puede hacer mediante Scripting?

A través del scripting se pueden lograr una gran variedad de acciones: desde ocultar campos de la pantalla y hacer validaciones sobre el contenido de los mismos a medida que el usuario los completa, hasta integraciones con otros sistemas. Cabe resaltar que el scripting en Thuban tiene eventos y firmas determinadas, y que todos ellos tienen retornan un boolean, con el fin de permitir o denegar el flujo de código. Por ejemplo, por defecto cualquier método de scripting debe devolver true, ya que un false implicaría la suspensión de la secuencia de ejecución. Entonces, si se estuviese codificando una validación sobre un campo dado y ésta es exitosa, se retorna un true para que el flujo continué normalmente. Caso contrario, se retorna un false y se interrumpe la ejecución para que usuario tome alguna medida.

Tipos de Scripting en Thuban

• Scripting de clases documentales: es el tipo de scripting que más se utiliza y sirve para personalizar las acciones y el comportamiento del sistema dentro de una clase documental. Por ejemplo, la clase documental “Cliente” puede tener cierto comportamiento mientras el documento esté activo, y la clase documental “Proveedor”, uno totalmente distinto.

Este tipo de scripting estará disponible para todas aquellas ventanas de Thuban donde se haga uso de los documentos de una clase documental: Creación, búsqueda, edición de documentos, entre otras. Para su funcionamiento, deberá crear un archivo .bsh con una estructura predeterminada, cuyo nombre sea el mismo que el de la clase documental. Luego, deberá introducir el .bsh generado dentro de la carpeta Scripting, que se encuentra dentro de la carpeta Context.

• Scripting de Thuban genérico: Este tipo de scripting permite realizar acciones sobre las interfaces de usuario de Thuban, independientemente de la clase documental. Para su funcionamiento, deberá crear un archivo .bsh con una estructura predeterminada, cuyo nombre sea “THUBAN”. Luego, deberá introducir el .bsh generado dentro de la carpeta Scripting, que se encuentra dentro de la carpeta Context.

Ver también UITOOLS: métodos útiles

Eventos de scripting de Clases Documentales

El scripting se ejecuta cuando desde el aplicativo se disparan determinados eventos. A continuación se detallan los eventos de scripting.

• indexesBulkLoad: Se ejecuta al momento de cargar la pantalla de indexación rápida de documentos. En el mapa de parámetros del evento, se incluyen los siguientes componentes. El nombre del parámetro sería como la key del mapa.

- winDocIndex: Es la ventana DocIndex.

- classId: El nombre de la clase documental.

- documentService: El servicio de Thuban para el manejo de documentos.

- applicationContext: El contexto de la aplicación de donde es posible obtener cualquier bean del sistema, ya sean propios del sistema o nuevos definidos en user-application-context.xml

- dataSource: el datasource de conexión a la base de datos de Thuban.

- contextHolder: El contexto de aplicación de spring.

- adminService: Servicio de Thuban con funciones de administración, entre otros servicios, para ejecutar consultas contra la base de datos de Thuban.

• indexesBulkSave: Se ejecuta al finalizar el proceso de actualización de todos los documentos en la ventana de indexación rápida. Lo que se obtiene en el evento es:

- Idem indexesBulkLoad

• indexesBeforeItemSave: Se ejecuta en la ventana de indexación rápida de documentos antes de actualizar cada documento. Es decir, el evento se dispara una vez por documento cada documento que se vaya a actualizar, antes de que el mismo sea actualizado. Lo que se obtiene en el evento es:

- Idem indexesBulkSave más documentId, que es el id Thuban del documento que se está actualizando.

• indexesAfterItemSave: Se ejecuta en la ventana de indexación rápida de documentos luego de actualizar cada documento. Es decir, el evento se dispara una vez por documento a actualizado. Lo que se obtiene en el evento es:

- Idem indexesBulkAfterItemSave

• groupingOpen: Este evento se ejecuta en las ventanas de creación, edición y generación de carátulas de Prescan. Se ejecuta al abrir un formulario y luego de actualizar la lista de formularios. En el evento se obtienen los siguientes elementos:

- classId: El nombre de la clase documental.

- documentService: El servicio de Thuban para el manejo de documentos.

- applicationContext: El contexto de la aplicación de donde es posible obtener cualquier bean del sistema, ya sean propios del sistema o nuevos definidos en user-application- context.xml

- dataSource: el datasource de conexión a la base de datos de Thuban.

- contextHolder: El contexto de aplicación de spring.

- adminService: Servicio de Thuban con funciones de administración, entre otros servicios para ejecutar consultas contra la base de datos de Thuban. Se configura el source del evento, es decir, el groupbox que contiene la grilla de campos del formulario que se abrió.

- documentId: Id del documento (sólo en la pantalla de edición)

- trayName: El nombre de la bandeja desde la cual se abrió el documento (Sólo en pantalla de edición y si el documento fue abierto desde una bandeja de Thuban).

- Ventana: dependiendo de la ventana en la que se esté ejecutando vendrá como parámetro la misma, por ejemplo:

--> mainWindow: DisplayUI -> Ventana Edición

--> newWindow: NewUI -> Ventana Creación

--> prescanWindow: PrescanCoversUI -> Ventana de generación de carátulas.

• itemSave: Este evento puede ser disparado por alguna de las siguientes pantallas y puede ocurrir en distintos tiempos de acuerdo a cada una de ellas:

- Edición de Documentos (DisplayUI): el evento se ejecuta justo antes de persistir los cambios realizados a un documento, esto también quiere decir que se ejecuta previo a las validaciones propias de Thuban sobre los campos.

- Creación de Documentos (NewUI): el evento se dispara al momento de intentar crear el documento, antes de que realmente el mismo sea creado este evento se ejecuta, esto también incluye a las validaciones de Thuban.

- Reclasificación de Documentos (ReclassifierUI): el evento se ejecuta al momento de confirmar la reclasificación del documento, justo antes de reclasificarlo efectivamente, pero luego de la validación de los campos por parte de Thuban.

- Generación de Carátulas (PrescanCoversUI): el evento se ejecuta previo a la generación de la carátula y a las validaciones de checklists, si los hubiera.

En este evento se obtienen los siguientes elementos (ver la aclaración sobre elementos particulares en cada ventana):

- Window : donde Window va a hacer referencia a cada ventana en particular dependiendo desde donde se disparó el evento, por ejemplo en la ventana de creación sería: newWindow : NewUI.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId: Id de Thuban del documento sobre el cual se está trabajando. Sólo para las ventanas de Edición de Documentos (DisplayUI) y Reclasificación de Documentos (ReclassifierUI)

- trayName: Identifica la bandeja de Thuban desde la cual fue accedido el documento, si corresponde. Sólo en la ventana de Edición de Documentos.

• itemLoad: Este evento puede ser disparado al momento de carga de los campos de la clase documental, por alguna de las siguientes ventanas de Thuban:

- Edición de Documentos

- Creación de Documentos

- Generación de Carátulas

- Reclasificación de Documentos

- Búsqueda de Documentos

Los elementos que se pueden obtener del evento son los siguientes:

- Window: donde Window va a hacer referencia a cada ventana en particular dependiendo desde donde se disparó el evento, por ejemplo en la ventana de creación sería: “newWindow: NewUI”. En particular en el caso de la ventana de búsqueda de documentos, la misma debe ser casteada como Window, ya que la pantalla en sí, no lo es.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId: Sólo en Edición de Documentos y Reclasificación de Documentos.

- trayName: Sólo en Edición de Documentos.

• itemSearch: Evento que se ejecuta antes de realizar la búsqueda. Este es un evento que únicamente ocurre en la ventana de Búsqueda de Documentos y puede obtener lo siguiente:

- searchWindow : Window

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

• itemAfterSave: Este evento puede ser disparado por alguna de las siguientes pantallas y puede ocurrir en tiempos distintos de acuerdo a cada una de ellas:

- Edición de Documentos: el evento ocurre luego de haberse persistido los cambios realizados al documento.

- Creación de Documentos: el evento ocurre luego de haberse creado el documento en Thuban.

- Generación de Carátulas: el evento ocurre luego de haberse creado la carátula de la documentación.

- Reclasificación de Documentos: el evento ocurre luego de que el documento haya sido reclasificado exitosamente a su nueva clase documental.

En el evento se obtienen los siguientes elementos para trabajar:

- Window: donde Window va a hacer referencia a cada ventana en particular dependiendo desde donde se disparó el evento, por ejemplo en la ventana de creación sería: “newWindow: NewUI”. En particular en el caso de la ventana de búsqueda de documentos la misma debe ser casteada como Window ya que la pantalla en sí no lo es.

-documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId: Solo en Edición de Documentos, Creación de documentos (el id del documento creado) y Reclasificación de Documentos.

- trayName: Solo en Edición de Documentos.

• itemClose: Este evento, a diferencia del resto, no devuelve una pantalla, sino que ocurre cuando se cierra la ventana del navegador estando en la pantalla de Edición de Documentos, luego de que la aplicación desbloquea el documento que se estaba editando. Adicionalmente, ocurre al ejecutarse la limpieza de ventanas cerradas de Thuban en el proceso de liberación de memoria y aplican las mismas reglas antes mencionadas. En el evento se reciben los siguientes elementos:

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId: Id del documento que se estaba editando antes de cerrar la ventana.

• itemLock: Este evento ocurre sólo en la ventana de Edición de Documentos y se dispara al hacer click sobre el botón de bloqueo del documento. Este evento se ejecuta únicamente cuando se está bloqueando el documento para edición. En el mismo se reciben los siguientes elementos:

- mainWindow: es la ventana DisplayUI.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId

- trayName: si corresponde.

• itemUnlock: Este evento ocurre sólo en la ventana de Edición de Documentos y se dispara al hacer click en el botón de bloqueo del documento. Este evento se ejecuta únicamente cuando se está desbloqueando el documento. En el mismo se reciben los siguientes elementos:

- mainWindow: es la ventana DisplayUI.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId

- trayName: si corresponde.

• itemAfterLock: Este evento ocurre únicamente en la ventana de edición de documentos al momento de bloquear o desbloquear el documento. Puede ocurrir de dos formas: el usuario presiona el botón de bloqueo/desbloqueo del documento, o bien, abre el documento desde una bandeja de Thuban configurada con autolock. En cualquiera de los casos, se obtienen los siguientes elementos en el evento:

- mainWindow: es la ventana DisplayUI.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId

- trayName: si corresponde.

• itemDelete: Este evento se dispara al momento de intentar eliminar un documento, ya sea desde la ventana de edición o desde la de búsqueda de documentos. El evento se dispara luego de que el sistema pide confirmación de la intención de eliminar el documento pero antes del borrado real del mismo. Los elementos que se obtienen en el evento son:

- Window: donde Window va a hacer referencia a cada ventana en particular dependiendo desde donde se disparó el evento.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

• fieldGetFocus: Este evento ocurre en todas las pantallas de Thuban donde se cargue la grilla de campos de clases documentales: creación, edición y búsqueda de documentos, generación de carátulas, reclasificación de documentos, etc. Este evento se dispara cuando uno de los campos de la grilla toma foco y en el evento se obtienen lo siguientes elementos:

- Window: donde Window va a hacer referencia a cada ventana en particular dependiendo desde donde se disparó el evento.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId: si existe

- trayName: Sólo en la ventana de edición de documentos, si corresponde.

• fieldLostFocus: Este evento ocurre en todas las pantallas de Thuban donde se cargue la grilla de campos de clases documentales: creación, edición y búsqueda de documentos, generación de carátulas, reclasificación de documentos, etc. Este evento se dispara cuando uno de los campos de la grilla pierde foco y en el evento se obtienen lo siguientes elementos:

- Window: donde Window va a hacer referencia a cada ventana en particular dependiendo desde donde se disparó el evento.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId: si existe.

- trayName: Sólo en la ventana de edición de documentos, si corresponde.

• itemSent: Este evento ocurre en la ventana de envío de documentos de Prescan. Se dispara cada vez que se procesa una carátula y se deja para enviar. En el evento se obtienen los siguientes elementos:

- prescanEnvioDocumentosWindow: Es la ventana PrescanSendDocumentsUI.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

• onOpenMail: Este evento puede ser disparado por cualquiera de las dos interfaces de envío de mails de Thuban (“wndMail = EMailUI” o “wndSendMail = SendMailUI”). En ambos casos, el evento se lanza al abrir la ventana y se reciben los siguientes elementos:

- Window: donde Window va a hacer referencia a cada ventana en particular dependiendo desde donde se disparó el evento.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId

• uiPaint: Este evento ocurre en todas las pantallas de Thuban donde se cargue la grilla de campos de clases documentales: creación, edición y búsqueda de documentos, generación de carátulas, reclasificación de documentos, etc. Este evento se dispara al finalizar la creación de la grilla de campos y antes de que la misma se complete con los valores de los campos, si los tuviese. En el evento se obtienen lo siguientes elementos:

- Window: donde Window va a hacer referencia a cada ventana en particular dependiendo desde donde se disparó el evento.

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- classId

- documentId: si existe.

- trayName: Sólo en la ventana de edición de documentos, si corresponde.

Eventos de Scripting Thuban Genéricos

El scripting se ejecuta cuando desde el aplicativo se disparan determinados eventos. A continuación se detallan los eventos de scripting.

• onExport: Este evento se dispara al momento de realizar la exportación a PDF de un checklist de Thuban. Se dispara luego de que se realizó la exportación y, por ende, se generó el archivo PDF, pero antes de que el mismo sea presentado al usuario para abrirlo o guardarlo. En el evento se reciben los siguientes elementos:

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

Adicionalmente en el source del evento se puede obtener un mapa con lo siguientes elementos:

- FILE: es el java File que representa el archivo pdf exportado.

- DOC_ID: Es el id de Thuban del documento del cual se está exportando el checklist.

• actionExecuted: Este es un evento genérico que denota que se ha ejecutado una acción en el sistema. El mismo se encuentra presente en las ventanas de Generación de Carátulas de Prescan y de Generación de Reportes. Dependiendo de la ventana en la que se esté, se dispara en distintos momentos y con distintos parámetros que a continuación se detallan:

- Ventana de Generación de Carátulas de Prescan: el evento se dispara en dos instancias distintas:

--> Al presionar el botón Crear: el evento se ejecuta cuando se presiona el botón de creación de la carátula, es decir, previo a realizar cualquier opción en el sistema. Los elementos que se obtienen son:

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- prescanWindow: PrescanCoversUI

Adicionalmente en el source del evento se recibe el botón crear que originó el evento.

--> Al presionar el botón Limpiar: el evento se dispara al presionar el botón Limpiar y se reciben los mismos elementos que en el botón Crear, a excepción del source, donde ahora se encontrará el botón Limpiar, y no Crear.

- Ventana de Generación de Reportes: el evento se dispara al presionar sobre el botón Mostrar para visualizar el reporte. El mismo se ejecuta cuando se valida que haya un reporte seleccionado para ejecutar. En el evento se reciben los siguientes elementos:

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- reportsUI: ReportsUI

- screenLoad: Este evento se ejecuta luego de que la ventana de Thuban haya sido cargada y ocurre únicamente en la ventana de envío de documentos y de seguimiento de Prescan y en la de Generación de Reportes.

En cualquiera de ellas los elementos que se reciben en el evento son los siguientes:

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- Window: donde window puede ser ReportsUI, PrescanSendDocumentsUI o PrescanTracingUI dependiendo de la ventana de Thuban en la que uno se encuentre.

• fieldsLoad: Este evento se ejecuta únicamente en la ventana de Generación de Reportes, luego de que haya seleccionado un reporte y se hayan cargados los campos de ejecución del mismo (si los tuviera). En este evento se reciben los siguientes elementos:

- documentService

- applicationContext

- dataSource

- contextHolder

- adminService

- reportsUI: ReportsUI

Formularios Electrónicos

El manejo de formularios electrónicos es una función de Thuban® que permite manejar formularios en PDF de manera centralizada . Estos formularios permiten llevar adelante procesos simples que no requieren el uso de workflows estructurados.

Ventajas de los formularios electrónicos:

- Permiten incorporar validaciones de tipos de datos, máscara y completitud de datos en línea.

- Permiten definir un diseño de página personalizado para la información que se completa en el formulario.

- Permite indexar automáticamente los documentos en Thuban® y generar un repositorio único.

- Permite controlar que siempre se utilice la última versión de un formulario al momento de generarse.

- Permite incorporar ayudas en línea para indicar de qué manera debe completarse cada campo.

- El tiempo de desarrollo de un formulario PDF es mucho menor que el de construcción de cualquier tipo de workflow (tanto estructurado como colaborativo).

- Permite incorporar la firma digital a la solución dándole valor legal a la información almacenada en el formulario electrónico.

- Se almacena en un formato estándar de aceptación mundial: PDF.

Implementación de formularios electrónicos en Thuban®

En Thuban®, los formularios electrónicos tienen un tratamiento diferencial respecto del resto de los documentos. Existe una diferencia entre una plantilla de formulario electrónico (formulario vacío) y un documento de formulario electrónico (instancia de la plantilla con los datos completos).

En principio, existe una clase documental que contiene las plantillas de los formularios PDF. Estas plantillas son documentos en PDF que, además de contener los campos donde se almacenarán los datos, tiene la inteligencia para comunicarse con el servidor Thuban® mediante llamadas HTTP.

Para configurar una nueva plantilla en el sistema es necesario crear una clase documental que las almacene. Cuando un usuario desea crear un nuevo documento de formulario electrónico, debe consultar la clase documental como si consultara cualquier otro documento del sistema.

La plantilla permite generar el documento PDF final. Por lo general, contiene un botón Enviar que es el encargado de generar el documento resultante en Thuban®. Una vez generado el formulario, se guarda en otra clase documental previamente definida. El nuevo documento es de sólo lectura y no admite modificación.

Construcción de Formularios Electrónicos

Los formularios electrónicos son formularios PDF comunes desarrollados bajo el estándar de PDF 1.6. Sirven de plantillas para la generación de otros documentos. Cuando el usuario crea un nuevo formulario PDF, el archivo se abre utilizando Acrobat Reader. La comunicación con el servidor se realiza mediante HTTP, con la funcionalidad propia del PDF.

Cada formulario debe contener las siguientes variables:

TH_ESTADO: Se utiliza para informar al usuario el estado del formulario PDF. El sistema genera el nuevo documento sólo cuando el estado de las validaciones es OK.

TH_CLASE_ORIGEN: El nombre de la clase documental donde se almacena la plantilla de formularios.

TH_CLASE_DESTINO: El nombre de la clase documental donde se genera el documento destino.

TH_CODIGO_FORMULARIO: El nombre del formulario.

TH_CAMPO_CODIGO: El campo de la clase documental que se utiliza para encontrar el formulario. Por ejemplo:

- TH_CLASE_ORIGEN: E-FORMS

- TH_CLASE_DESTINO: DOC_CLIENTE

- TH_CAMPO_CODIGO: FORM_NOMBRE

- TH_CODIGO_FORMULARIO: INSTRUCCIÓN

Y un botón para enviar la solicitud a Thuban que debe llamarse “btnenviar” y contener la url del servidor de Thuban como acción.

Al presionar el botón Enviar del formulario electrónico, el sistema busca la plantilla para el nuevo PDF en la clase documental E-FORMS por el índice FORM_NOMBRE y el valor INSTRUCCIÓN y genera un nuevo documento de la clase DOC_CLIENTE con los datos cargados por el usuario.

Scripting de Formularios Electrónicos

Los formularios electrónicos son parte de la solución para el manejo de contenido dinámico que ofrece Thuban®. Al igual que las clases documentales, se pueden parametrizar a través de archivos de Scripting ubicados dentro de la carpeta Forms. Tienen una estructura particular para que la aplicación pueda interpretarla. Su nombre representa el formulario sobre el que se va a realizar la personalización.

La definición de scripting es por formulario electrónico y funciona en base a una serie de eventos predefinidos que se ejecutan en determinados momentos. Los eventos son:

customActionPerformed: Este evento toma lugar cuando se ejecuta una acción propia de un formulario electrónico y permite modificar cualquier aspecto del formulario.

saveActionPerformed: Este evento sucede cuando el formulario electrónico se está por guardar y permite modificar el formulario.

saveActionPerformedToScreen: Este evento sucede luego de que el formulario electrónico se guarda y antes de que se retorne a la pantalla del usuario. Le permite al usuario agregar mensajes que no quedan almacenados en el archivo definitivo.

Scripts de Validación y Personalización

Configuración archivo de scripting

Para configurar el archivo de scripting, se debe almacenar el archivo con el nombre de la clase documental y extensión ".bsh" en la carpeta scripting dentro del contexto de la aplicación. Recordemos que el contexto de la aplicación es una carpeta que contiene configuraciones propias de cada instalación y no tiene una ubicación fija, sino que es accedida a través de la variable thuban.context del servidor de aplicaciones.

Por ejemplo:

${thuban.context}\scripting\DOC_CLIENTE.bsh

Para obtener un usuario logueado se debe ingresar:

String user = SecurityContextHolder.getContext().getAuthentication().getName();

Acceso a los servicios Thuban®

Los servicios de Thuban® se acceden a través del mapa de parámetros contenido en el evento de scripting. Allí es posible acceder a los siguientes servicios:

- Admin Service ("adminService")

- Resource Service ("resourceService")

- Document Service ("documentService")

- Mail Service ("mailService")

- Prescan Service ("prescanService")

- Search Service ("searchService")

- Tray Service ("trayService")

- Monitor Service ("monitorService")

- Report Service ("reportService")

- Counter Service ("counterService")

Para más información sobre los servicios consulte el documento de Java de Servicios Thuban®.

Map map = evt.getParameters(); DocumentService documentService = map.get("documentService");

Cada interfaz de usuario agrega una referencia a sí misma en el mapa de parámetros del evento de scripting. Cada interfaz posee su propia key. Si al recuperar esa key del mapa de parámetros, la misma es distinta de nulo, entonces el evento fue generado por esa Interfaz de usuario. Por ejemplo:

Map map = evt.getParameters(); if(map.get("prescanWindow")!= null) {

Clave para cada UI (Interfaz de usuario)

newWindow: Pantalla de creación de nuevos documentos.

prescanWindow: Pantalla de emisión de carátulas.

mainWindow: Pantalla de visualización de documentos.

searchWindow: Pantalla de búsqueda de documentos.

Obtención de referencia a un componente UI

Actualmente, sólo es posible acceder a la grilla de índices del ítem visualizado. Para acceder a cada uno de los campos de Input se utiliza la clase UITools a través del método estático retrieveInputElement que recibe dos parámetros: la referencia a la grilla de campos y el Id del campo índice (como se le asignó a través de la herramienta Thuban® Admin).

Por ejemplo: Si se desea acceder al campo FORM_NOMBRE de la grilla de campos para modificar su valor:

Map map = evt.getParameters(); Grid grid= map.get("fieldsGrid"); InputElement element= grid.retrieveInputElement(grid, "FORM_NOMBRE");

element.setText("MODIFICO EL VALOR DEL CAMPO!");

Thuban® utiliza ZK para los componentes de la UI. Para más información sobre las propiedades y métodos de cada componente consúltese el documento Java de ZK: http://zkoss.org/javadoc/3.6/zk/

Modificación de atributos de un componente de UI

Siguiendo el ejemplo anterior, se puede utilizar la referencia al InputElement para:

Habilitar o Deshabilitar un componente:

- element.setReadonly(true/false);

- element.setDisabled(true/false);

Establecer un estilo CSS (Cascading Style Sheet):

- element.setStyle("left-padding: 5px; color:red;");

Establecer una máscara a un campo. Para por ejemplo validar que una dirección de correo contenga el formato "xxxxx@xxxx.xxx.xx":

- element.setConstraint("/.+@.+\.[a-z]+/: Please enter an e-mail address");

Diálogos con mensaje (Message Box)

Para mostrar diálogos en un evento de scripting es posible utilizar la clase Messagebox de ZK que recibe diversos parámetros y permite parametrizar los siguientes atributos:

- Título

- Mensaje

- Icono

- Botones Posibles

Cuando se ejecuta un diálogo de mensaje, se detiene la ejecución del evento hasta que finalice la interacción con el usuario permitiendo recuperar la opción elegida por el usuario.

Ejemplo: Para mostrar un diálogo con:

Título: Scripting

Test Mensaje: Fecha Invalida. Por favor ingrese una fecha posterior a 12/12/2008

Icono: Warning.

Botones: Ok.

int result= 0;

int result= 0; 
result= Messagebox.show("Bienvenido al scripting!!", "Scripting Test", Messagebox.OK | Messagebox.CANCEL, Messagebox.QUESTION); 
if(result==Messagebox.OK) { 
	  Messagebox.show("Presionó OK", "Scripting Test", Messagebox.OK | Messagebox.CANCEL, Messagebox.INFORMATION);