Desarrollando aplicaciones J2EE sobre Alfresco IV – Aplicativo final

 

Como colofón a la entrega de 'Desarrollando aplicaciones J2EE sobre Alfresco' [1] [2] [3] , vamos a comentar el caso de éxito de la creación de un aplicativo final para uno de nuestros clientes.

En su antigua vertiente, el cliente hacía uso del software propietario Lotus Notes, sistema cliente/servidor de colaboración y correo electrónico.

El principal uso que daban a esta aplicación consistía en:

  • Cliente de correo

  • Gestor de conocimiento, albergando los registros entrantes y salientes de la oficina, así como la generación de expedientes asociados a estos.

  • Almacenamiento de correos electrónicos (con sus correspondientes adjuntos) relacionados con los registros y expedientes en el gestor de conocimiento.

Con la colaboración de Irontec se remplazó dicho software por una combinación basada en software libre; Zimbra 7.1.1 y una aplicación J2EE a medida bajo Alfresco Community 3.4.0.

 

Aplicación a medida

Alfresco Community 3.4d

Desde Zylk.net tenemos una amplia experiencia con este gestor documental, y aunque nuestra primera aproximación fue desarrollar la aplicación sobre el share de Alfresco, optamos por trabajar sobre un terreno conocido, J2EE, mientras nos familiarizábamos con las tecnologías de Alfresco Share; YUI, Surf, Freemarker, JS avanzado, ...

Aplicación web J2EE

La aplicación web, consta de 2 interfaces para dar servicio a un zimlet y a las peticiones síncronas y asíncronas de la aplicación web.

Desde el core de la aplicación tendremos el módulo Alfresco, que se compondrá de una paquetería para las operaciones CMIS (OpenCMIS) y para aquellas operaciones que requieran del uso de los webscripts a medida, un paquete para la gestión de conexiones HTTP (Apache HTTP Commons)

Desde Alfresco haremos uso, desde el binding Atompub, del servicio CMIS que se nos ofrece.

Como comentamos en anteriores entradas, dado que ciertas funcionalidades no las veíamos cubiertas desde este interfaz, optamos por crearnos webscripts Alfresco a medida.

 

El mapa funcional de la aplicación se podría definir en:

  • Registros

    • Listado de registros E/S disponibles en el sistema, paginados y ordenados, con un buscador simple y otro avanzado, para poder realizar una búsqueda por metadatos.

    • Alta de registro de entrada / salida

    • Detalle de registro E/S

      • Características generales

      • Datos de origen/destino

      • Estado de archivado; revisor, responsable de archivo y registros asociados

      • Archivos e Emails relacionados.

  • Expedientes

    • Listado de expedientes disponibles en el sistema, paginados y ordenados, con un buscador simple y otro avanzado, para poder realizar una búsqueda por metadatos.

    • Detalle del expediente

      • Características generales

      • Registros asociados

      • Archivos e Emails relacionados

 

Os dejamos unas cuantas imágenes de la aplicación.

Creación de un nuevo registro

 

Resultados y buscador simple de registros

 

Búsqueda avanzada de registros

 

Asociación entre un registro y expediente

 

Petaña de revisión en el detalle de un registro

 

Registros asociados a un expediente

 

Pestaña 'Documentos de interés' en el detalle de un expediente, en donde se pueden ver documentos e emails adjuntos

Zimlet

Para la integración del gestor de correo con el gestor documental, desarrollamos junto con Irontec un componente zimlet para Zimbra y mediante una capa intermedia en nuestra aplicación J2EE relacionamos el zimlet y Alfresco.

Migración de datos

Para la migración de datos desde un sistema Lotus ↔ Alfresco, hicimos uso de la librería DIIOP (Domino Internet Inter-Orb Protocol) que nos ofrece el mismo producto, para comunicar aplicaciones Java con el servicio de datos Lotus Domino.

Si como ocurrió en nuestro caso, desconocéis el modelo de datos empleado en la aplicación y este ha sufrido variaciones en el transcurso de su uso, el proceso de migración os resultará algo cansino, ya que sólo podréis conocer el contenido de los documentos (objeto genérico de Lotus) con una iteración de propiedades.

Sin embargo, la API DIIOP es muy utilizable, y apenas tendréis problemas en la parte técnica.

Tras las 38 horas que tardó todo el proceso de migración, conseguimos migrar 27.605 documentos con un peso total aproximado de 20Gb.

00

More Blog Entries

0 Comments