Configuración y Administración
Enlaces relacionados:
Contenido
- 1 Organización de los contenidos
- 2 Indexación de los contenidos
- 3 Configuración básica de la Solución
- 3.1 Carpeta Context
- 3.2 Carpeta Scripting
- 3.3 Carpeta Forms
- 3.4 Carpeta Templates
- 3.5 Carpeta Images
- 3.6 Carpeta Security
- 3.7 Configuración de parámetros de log y carpetas temporales en el servidor
- 3.8 Configuración usuario por defecto
- 3.9 Recomendaciones para entornos de producción
- 3.10 Seguridad
- 3.11 Configuración de Perfiles de Escaneo
- 4 Mantenimiento del sistema
- 5 Personalización de la solución
- 6 Scripting en Thuban
- 7 Formularios Electrónicos
- 8 Scripts de Validación y Personalizació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:
| Aplicación | Set | Sección | Variable | Descripción |
| THUBAN-SERVER | DEFAULT | CONFIGURATION | imagesDirectory | Indica la ruta del sistema de almacenamiento de imágenes de tips de inicio del sistema. |
| THUBAN-SERVER | DEFAULT | CONFIGURATION | scriptingDirectory | Indica la ruta del sistema de almacenamiento de scripting de clases documentales. |
| THUBAN-SERVER | DEFAULT | CONFIGURATION | formsDirectory | Indica la ruta del sistema de almacenamiento de scripting de formularios electrónicos PDF. |
| THUBAN-SERVER | DEFAULT | CONFIGURATION | templatesDirectory | Indica la ruta del sistema de almacenamiento de plantillas de correo electrónico HTML y texto. |
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.
<source lang="xml"> <?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>
</source>
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:
| Aplicación | Set | Sección | Variable | Descripción |
| THUBAN-SERVER | DEFAULT | CONFIGURATION | attachmentsDirectory | Indica la ruta del sistema de temporales para el almacenamiento de archivos que se transfieren utilizando web services. |
| THUBAN-SERVER | DEFAULT | CONFIGURATION | loggingDirectory | Indica la ruta donde el sistema almacenará los logs del sistema. |
| THUBAN-SERVER | DEFAULT | CONFIGURATION | logLevel | Indica el nivel de log que se desea. Los niveles posibles son:
- DEBUG (registra información detalla de la operación para depuración). - INFO (registra información de la operación). - ERROR (registra solo errores no controlados del sistema). |
| THUBAN-SERVER | DEFAULT | CONFIGURATION | rollingFileSize | Permite indicar el tamaño de los archivos de log del sistema. Por defecto, el log de sistema se registra en un archivo de log del tamaño definido por este parámetro. Cada vez que el archivo de log alcanza ese tamaño, se genera un backup y comienza con un nuevo archivo de log. El sistema guarda los 10 últimos backups de logs. |
| THUBAN-SERVER | DEFAULT | CONFIGURATION | filesPerFileSystem | Permite configurar la cantidad de archivos que se deben almacenar por filesystem antes de generar una nueva sub-carpeta. Esto se utiliza para no sobrecargar los filesystems de archivos. Ver organización del filesystem para más información. |
Configuración usuario por defecto
Para que la configuración por defecto funcione correctamente, se debe crear un usuario cuyo USER_ID sea DEFAULT.
searchTop: Permite poner por defecto el top de resultados de la query de búsqueda. Toma valores posibles menor o igual al tope configurado en Thuban_Config (Tabla) o bien al estático que tiene la aplicación por defecto (500).
searchPreview: permite habilitar ciertas opciones como:
– Mostrar siempre la vista previa del documento (Valor = one o puede ser Null)
– Abrir directamente los ítems que tengan vínculos dinámicos (Valor = two)
– Abrir automáticamente los ítems sin imagen / preview ( Valor = three)
– Desactivar vista previa (Valor = four)
openUniqueResult: Permite abrir un único resultado en vista Edición (true/false).
Variables de Usuario – Display
hideNotes: Permite ocultar las notas (true/false)
originalView: Permite configurar la vista: cuando toma false indica la vista original de Thuban®. Si toma true es la vista por medio de pestañas. (true/false)
collapseTree: Permite colapsar el árbol de vínculos dinámicos (cerrar los vínculos y mostrar las carpetas) (true/false).
notesAndHistoryDialog: Permite habilitar Notas e Historia en forma de diálogo emergente en lugar de estar siempre visible (true/false).
collapseDynLinks: Permite colapsar los vínculos dinámicos cuando se realiza la Creación de un Documento por medio de la vista Edición (un legajo).
Variables de Usuario – General
hideTips: Permite ocultar Tips al inicio (true/false).
mainScreen: Permite definir un pantalla por defecto. Los valores pueden ser:
- Si la aplicación está en español: <Ninguna>, Creación, Búsqueda, Bandejas, Reportes, Adm. Reportes, Prescan, Monitores.
- Si la aplicación está en inglés: <Nothing>, Creation, Search, Trays, Reports, Reports Mng., Prescan, Monitors.
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:
| Aplicación | Set | Sección | Key | Valor |
| PowerDesk | DEFAULT | SCAN | scanServers | <Nombres de servidores separados por coma> |
Luego, por cada nombre de servidor se deben establecer las siguientes entradas:
| Aplicación | Set | Sección | Key | Valor |
| PowerDesk | DEFAULT | SCAN | server.<nombreServidor> | name<Nombre que aparece en el combo de la interfaz de usuario de escaneo> |
| PowerDesk | DEFAULT | SCAN | server.<nombreServidor>.url | <URL del servicio de escaneo o la palabra «TWAIN» para escáneres locales> |
Además se deberá configurar por lo menos un perfil. Cada perfil contiene las siguientes propiedades:
| Aplicación | Set | Sección | Key | Valor |
| PowerDesk | DEFAULT | SCAN | profile.<nombrePerfil>.mode | Lineart |
| PowerDesk | DEFAULT | SCAN | profile.<nombrePerfil>.resolution | 200 |
| PowerDesk | DEFAULT | SCAN | profile. <nombrePerfil>.source | <adf | flatbed> |
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).
| Aplicación | Set | Sección | Key | Valor |
| PowerDesk | DEFAULT | SCAN | scanHighQuality | true |
Ejemplo de configuración:
| Aplicación | Set | Sección | Key | Valor |
| PowerDesk | DEFAULT | SCAN | profile.b&n.mode | Lineart |
| PowerDesk | DEFAULT | SCAN | profile.b&n.resolution | 200 |
| PowerDesk | DEFAULT | SCAN | profile.b&n.source | adf |
| PowerDesk | DEFAULT | SCAN | scanHighQuality | true |
| PowerDesk | DEFAULT | SCAN | scanServers | Local |
| PowerDesk | DEFAULT | SCAN | server.Local.name | Local |
| PowerDesk | DEFAULT | SCAN | server.Local.url | twain |
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
| Evento | Descripción | Registro de Log | Observaciones |
| 1001 | Login | [Nombre de usuario] | Se genera cuando un usuario ingresa al sistema. |
| 1002 | Logout | [Nombre de usuario] | Se genera cuando un usuario sale del sistema. |
| 1100 | Usuario de LDAP creado. | [Nombre de usuario] | Se genera cuando se crea un usuario automáticamente en el mecanismo de login integrado con LDAP. |
| 1101 | Grupo LDAP asignado a usuario. | [Nombre de usuario][Grupo LDAP] | Se genera cuando se asigna un grupo automáticamente en el mecanismo de login integrado con LDAP. |
| 1102 | Grupo LDAP desasignado. | [Nombre de usuario][Grupo LDAP] | Se genera cuando se desasigna un grupo automáticamente en el mecanismo de login integrado con LDAP. |
Administración de Documentos
| Evento | Descripción | Registro de Log | Observaciones |
| 1500 | Ítem creado | Ítem creado | Se genera cuando se crea un documento. |
| 1501 | Ítem guardado | Ítem guardado | Se genera cuando se modifica un campo o la imagen de un documento. |
| 1512 | Modificación de campo auditado | [Valor Nuevo][Valor anterior] | Se genera cuando se modifica un campo marcado como de auditoría en el sistema. |
Administración de usuarios
| Evento | Descripción | Registro de Log | Observaciones |
| 2001 | Generación Usuario | [Nombre del Usuario Creado] | Sólo se registra cuando se trata de usuarios creados manualmente desde el módulo de administración. |
| 2002 | Eliminación Usuario | [Nombre del Usuario Eliminado] | Sólo se registra cuando se trata de usuarios eliminados manualmente desde el módulo de administración. |
| 2003 | Actualización Perfil Usuario | [Nombre del Usuario cuyo perfil se ha modificado] | |
| 2004 | Desconexión de Usuario | [Nombre del Usuario cuya desconexión se vio forzada] | |
| 2005 | Habilitar Usuario | [Nombre del Usuario] | Se genera cuando un administrador de usuarios habilita un usuario cuyo estado estaba deshabilitado (por bloqueo o vencimiento de contraseña). |
| 2006 | Deshabilitar Usuario | [Nombre del Usuario] | Se genera cuando un administrador inhabilita un usuario para ingresar al sistema. |
Administración de grupos
| Evento | Descripción | Registro de Log | Observaciones |
| 2010 | Generación Grupo | [Nombre del Grupo Creado] | Se genera cuando un grupo es creado desde el módulo de administración del sistema. |
| 2011 | Eliminación Grupo | [Nombre del Grupo Eliminado] | Se genera cuando un grupo es eliminado desde el módulo de administración del sistema. |
| 2012 | Modificación Grupo | [Nombre del Grupo Modificado] [Usuario Incluido] | Se genera cuando un usuario es agregado manualmente a un grupo desde el módulo de administración. |
| 2013 | Modificación Grupo – Usuario Incluido | [Nombre del Grupo Modificado] [Usuario Incluido] | Se genera cuando un usuario es agregado manualmente a un grupo desde el módulo de administración. |
| 2014 | Modificación Grupo – Usuario Removido | [Nombre del Grupo Modificado] [Usuario Removido del Grupo] | Se genera cuando un usuario es removido manualmente a un grupo desde el módulo de gestión |
Administración de Configuración
| Evento | Descripción | Registro de Log | Observaciones |
| 2020 | Creación/Modificación de Configuración | [Aplicación\Set\Sección\Variable] [Nuevo Valor] [Valor Anterior] | Se genera cuando un grupo es creado desde el módulo de administración del sistema. |
| 2021 | Eliminar Configuración | [Aplicación\Set\Sección\Variable] | Se genera cuando se elimina un atributo de configuración en el módulo de parametrización del sistema. |
| 2022 | Eliminar Sección | [Aplicación\Set\Sección] | Se genera cuando se elimina una sección completa del módulo de parametrización del sistema. |
| 2023 | Eliminar Sección | [Aplicación\Set] | Se genera cuando se elimina un set completo del módulo de parametrización del sistema. |
Administración de clases
| Evento | Descripción | Registro de Log | Observaciones |
| 2030 | Generación de Clase | [Nombre de Clase Creada] | Se genera cuando se crea una nueva clase documental desde el módulo de administración. |
| 2031 | Eliminación de Clase | [Nombre de Clase Eliminada] | Se genera cuando se elimina una clase documental desde el módulo de administración. |
| 2032 | Actualización de Clase | [Nombre de la clase modificada] | Se genera cuando se modifica un atributo o campo de la clase documental. |
Administración de Accesos
| Evento | Descripción | Registro de Log | Observaciones |
| 2040 | Modificación de Accesos en Grupo | [Nombre del grupo modificado] | Se genera cada vez que se realiza una modificación de un permiso en un grupo. |
| 2041 | Permiso Agregado | [Nombre del Grupo] [Permiso Agregado] | Se genera cuando se agrega un permiso a un grupo desde el módulo de configuración del sistema. |
| 2042 | Permiso removido | [Nombre del Grupo] [Permiso removido] | Se genera cuando se elimina un permiso a un grupo desde el módulo de configuración del sistema. |
| 2043 | Permiso modificado | [Nombre del Grupo] [Nuevo Valor del Permiso] [Valor anterior] | Se genera cuando se modifica un permiso a un grupo desde el módulo de configuración del sistema. |
Administración de Políticas de acceso
| Evento | Descripción | Registro de Log | Observaciones |
| 3000 | Contraseña modificada para el usuario. | [Usuario] | |
| 3001 | Contraseña modificada para el usuario forzada por administrador. | [Usuario] | |
| 3002 | Usuario deshabilitado por contraseñas incorrectas | [Usuario] | |
| 3003 | Usuario desbloqueado. | [Usuario] | |
| 3004 | Intento de login fallido | [Usuario][Cantidad de intentos fallidos] | |
| 3005 | Usuario deshabilitado por administrador. | [Usuario] | |
| 3007 | Política de acceso modificada | [Política Modificada] [Valor Anterior] [Valor Nuevo] | Las políticas de acceso pueden ser:
- userMinLength (Longitud mínima de nombre de usuario). - userMaxLength (Longitud máxima de nombre de usuario). - passMinLength(Longitud mínima de la password). - passMaxLength (Longitud máxima de la password). - passInactivityDays (Cantidad de días de inactividad antes de inhabilitar la cuenta). - passChangeDays (Cantidad de días para forzar cambios de contraseña). - passAlphanum(La contraseña debe tener caracteres alfanuméricos). - passSpecialChar(La contraseña debe contener caracteres especiales). - passUppercase (Debe contener caracteres en minúscula). - passLowercase (Debe contener caracteres en mayúscula). - passPartName (La contraseña no puede ser parte del nombre). |
| 3008 | Evento de log habilitado/deshabilitado | [Código de Evento] [Habilitado/Deshabilitado] |
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).
| Job | Descripción | Parámetros | Nombre de la clase |
| Doc Intro Job | Job que permite planificar procesos de DocIntro del sistema. | “customFileName” <Texto>: Permite definir el nombre del archivo de beans de DocIntro. Por defecto, este valor es “doc-intro-beans.xml” | com.latintech.thuban.docintro.job.DocIntroJob |
| Virtual Printer Job | Job que recupera trabajos de impresión de una cola preestablecida (de una impresora virtual) y los almacena, en formato TIF, en la carpeta de salida correspondiente. | “outputFolder” <Texto>: La ruta de la carpeta de salida donde deja los TIFs de los documentos impresos.
“queueName” <Texto>: El nombre de la cola de impresión. |
com.latintech.thuban.scheduler.job.VirtualPrinterJob |
| Folder Depuration Job | Job que elimina archivos de carpeta que sobrepasan un tiempo de existencia predeterminado. | “age” <Texto>: Representa la edad que deben superar los archivos para ser eliminados. Se expresa en milisegundos.
“folderPath”<Texto>: La ruta de la carpeta de archivos a depurar. |
com.latintech.thuban.scheduler.job.FolderDepurationJob |
| Migrate Document Job | Job que invoca la migración de todos los IDs de documento retornados por la consulta configurada a la base de datos. | “query” <Texto>: la consulta a la base de datos. Debe retornar una única columna con los IDs de los documentos a migrar. | com.latintech.thuban.scheduler.job.MigrateDocumentJob |
| Monitor Job | Job que permite ejecutar monitores para recuperar información para la toma de decisiones. | (Todos los parámetros de este job, separados por coma)
“monitorNames” <Texto>: nombres de los monitores a ejecutar. “registerHistory” <Texto>: True/False si debe registrar historial. “errorMailTo” <Texto>: cuentas de correo a las que se envía correo en caso de error. “errorMailCc” <Texto>: las cuentas de correo a las cuales enviar copia del correo en caso de error. “errorMailCc” <Texto>: las cuentas de correo a las cuales enviar copia oculta del correo en caso de error. |
com.latintech.thuban.scheduler.job.MonitorJob |
| Report Mail Job | Permite ejecutar un reporte y enviarlo por correo. | “mailTo” <Texto>: las cuentas de correo a las cuales enviar el correo separadas por punto y coma.
“mailCC” <Texto>: las cuentas de correo a las cuales enviar copia del correo separadas por punto y coma. “mailCCO” <Texto>: las cuentas de correo a las cuales enviar copia oculta del correo separadas por punto y coma. |
com.latintech.thuban.scheduler.job.ReportMailJob |
| Send Mail Job | Job que permite el envío y eliminación de correos encolados mediante el servicio MailService. | No tiene. | com.latintech.thuban.scheduler.job.SendMailJob |
| SQL Export Job | Job que permite exportar el resultado de una consulta a la base de datos a un archivo del filesystem en formato texto. | “query” <Texto>: la consulta SQL que recupera los datos a exportar.
“separator” <Texto>: el separador a utilizar para separar columnas (Ej. "|", ";", "," ). “outputFilePath” <Texto>: La ruta completa del archivo de salida incluyendo extension. |
com.latintech.thuban.scheduler.job.SQLExportJob |
| Log Depuration Job | Job que permite depurar la tabla de logs del sistema | “months” <Texto>: Representa la cantidad de meses que debe superar para ser eliminados.
“folderPath”<Texto>: La ruta de la carpeta de archivos donde se almacenan los logs antes de ser depurados. “events”<Texto>: Un listado de eventos de logs separados por coma. Ej: 1001,1101 |
com.latintech.thuban.scheduler.job.LogDepurationJob |
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®.
<source lang="xml">Map map = evt.getParameters(); DocumentService documentService = map.get("documentService");</source>
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:
<source lang="xml">Map map = evt.getParameters(); if(map.get("prescanWindow")!= null) {</source>
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:
<source lang="xml">Map map = evt.getParameters(); Grid grid= map.get("fieldsGrid"); InputElement element= grid.retrieveInputElement(grid, "FORM_NOMBRE");</source>
<source lang="xml">element.setText("MODIFICO EL VALOR DEL CAMPO!");</source>
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;
<source lang="xml"> 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); </source>
