Proyecto Componente Documental Marco de Referencia del Proyecto Definición del Componente Documental dentro del Proyecto Ser.

Presentación del tema: "Proyecto Componente Documental Marco de Referencia del Proyecto Definición del Componente Documental dentro del Proyecto Ser."— Transcripción de la presentación:

1 Proyecto w@ndA Componente Documental W@rdA

2 Marco de Referencia del Proyecto Definición del Componente Documental dentro del Proyecto W@nda W@nda Ser el almacén de los documentos que participan en la tramitación, tanto los generados por el motor de tramitación durante la ejecución de los trámites como los documentos generados externamente y que se anexan a los trámites de los procedimientos. Objetivo COMPONENTE DOCUMENTAL

3 Solución adoptada Utilización de producto de mercado invesdoc corporate server Adecuación a requisitos del proyecto Desarrollo de interfaces con Trew@ (MT-AE) Desarrollo de interfaces con Niw@ (RDP- BUS N1) Desarrollo de interfaces con Archiv@ Nuevas Funcionalidades Cesión de la plataforma invesDoc a la Junta de Andalucía

4 Funcionalidades Básicas (I) Adquisición de documentos Dispositivos de Captura. Cualquier dispositivo de digitalización con driver Twain o soportado por la familia de soluciones Adrenaline de Kofax. Captura de fichero local.

5 Funcionalidades Básicas (II) Caracterización de documentos

6 Funcionalidades Básicas (III) Objeto Documental

7 Funcionalidades Básicas (IV) Almacenamiento de la Información Múltiples sistemas de almacenamiento (FTP, PFS,...) Múltiples ubicaciones (Servidores, Recursos de Red, iScsi, Nas,...)

8 Funcionalidades Básicas (y V) Utilización y administración Clientes Windows y Web (Servidores MS y Java) Incluye visualizador para tipos no soportados nativamente por el cliente (TIFF, BMP.) API Windows (COM+) y Java Construcción de Clientes “ad hoc” Integración con aplicaciones (embebido) Herramientas de administración Caracterización de la información (estructuras documentales) Gestión del Almacenamiento Gestión de Seguridad (usuarios y grupos, permisos, auditoria,...)

9 Arquitectura (II) Componentes Web Engine Servlet Engine (J2EE) Servidor de documentos (Unix, Linux, Windows,..) Servidor de base de datos y motor documental (Oracle, SQLServer, DB2 ) Cliente Navegador de Internet (IE, Mozilla) Clientes 2 capas Aplicaciones consumidoras de Web Services.

10 Arquitectura (I) Plataforma tecnológica Servidores de datos Base de DatosDocumentos Windows, Solaris, AIX, Linux Presentación JSP \ Servlet Cliente Navegador Clientes ActiveX – PlugIn’s Visualización Visualización Captura Captura ImpresiónImpresión Negocio Plataforma J2EE Web Services(XML) Web Services (XML) Plataforma J2EE XML + XSL Servicios de Acceso Administración API interfaces producto Componentes IU Interfaces de servicios Aplicación ‘ad hoc’

11 El proyecto W@rdA Recubrir invesdoc corporate server de los servicios web necesarios para que Trew@, Archiv@ o cualquier otra aplicación puedan acceder de forma simple a las capacidades del Gestor Documental Crear los Interfaces necesarios para que w@rda pueda acceder a Niw@, principalmente, para mantener actualizada la RDP. Añadir aquellas funcionalidades necesarias para el dar cobertura al proyecto w@nda, no presentes en el producto.

12 Visión Global MOTOR DE TRAMITACIÓN Trew@ APLICACIÓN EXTERNA Niw@ (RDP) GESTOR DOCUMENTAL w@nda API invesDoc corporate invesDoc corporate Server (core) Escritorio Web Administración invesDoc Framework invesDoc corporate Programadores (aplicaciones adhoc) Usuarios de acceso directo Administradores MT-AE BUS N1 MT-AE GD-AE @rchivA

13 El mismo documento, distintas visiones Tramitador Una caja negra que : devuelve un ticket cuando le depositamos un documento. cuando le damos un ticket, puede recuperar, modificar o borrar un documento. Catalogo El repositorio físico de documentos administrativos de nuestra organización y el método de acceder a ellos con fines de gestión administrativa y obtención de cuadros de mandos. Archivo Un archivo de oficina de documentos electrónicos.

14 Necesidades @rchivA ¿Que necesita un Archivo de un Gestor Documental? Que el documento esté correctamente descrito, conforme a los Cuadros de Clasificación contemplados. (Organismo, Central, Histórico,..) Que pueda recuperar, almacenar y borrar documentos.

15 Necesidades Niw@ ¿Que necesita un Catalogo de un Gestor Documental? Que el documento esté correctamente descrito. En nuestro caso que cubra todo el conjunto de datos necesario para formar la Relación de Documentos Presentados. Acceder a todos los documentos aportados por el ciudadano, que se incluyen desde un Procedimiento Administrativo.

16 Necesidades Trew@ ¿Que necesita un Tramitador de un Gestor Documental? Almacenar documentos obteniendo un UID del Gestor Documental Recuperar documentos por su UID Borrar documentos por su UID Sustituir documentos por su UID Un tramitador no necesita buscar documentos. ‘sabe’ que documentos componen cada Expediente. Un caso particular de Trew@, podría ser saber si un documento ya ha sido presentado y su validez, pero es Niw@ en su RDP quien tiene esta información. ¿Que necesita un Gestor Documental de un tramitador? Aunque el tramitador no lo necesite, tiene que describir correctamente el documento que almacena.

17 Información del documento (I) Información Propia Relativa al Cuadro de Clasificación Relativa a la Gestión Administrativa Metadatos

18 Información del documento (II) Estática Propia Interna (fechas, autor,...) UID (Trew@) Tipo, Fecha Caducidad,.. (Niw@) Tipo (serie documental...) Aplicación, Formato,.. (Archiv@) Dinámica Relativa a la reserva, bloqueo y liberación (check in, check out) Relativa a su ubicación y situación,....

19 Normalización Archivadores w@nda Recoger el conjunto de metadatos necesario Su uso es compartido por Trew@, Niw@ y Archiv@ @rchivA Recoger el conjunto de metadatos particular Otros fines Aplicaciones de G.D. propias del organismo

20 Productos a obtener Conjunto de metadatos que describan el documento Necesidades Trew@ Necesidades Niw@ Necesidades @rchivA Servicios Web que permitan acceder a w@rda Código base (javascript) que permita digitalizar y visualizar documentos haciendo uso de Componentes Descargados en el cliente. Funcionalidades detectadas en los distintos análisis y que supongan un rediseño o ampliación de funcionalidades

21 Situación Actual, producto estándar w@rdA no es solo un ‘almacen de documentos’ para trew@: Gestor documental de propósito general Clientes Navegador Clientes y Administración 2 Capas Plataforma de desarrollo para integrar GD en aplicaciones existentes o desarrollar aplicaciones de GD ad-hoc. Tanto de cliente como de administración API MS (COM+) API JAVA Es un producto en continua evolución Solo en administración pública +100 instalaciones 100 % disponible Evolución producto Cliente Administración web (solo entornos Java) Incorporación de otros Motores de B.D. Nuevos repositorios de documentos

22 Situación Actual, proyecto w@nda Todos los desarrollos comprometidos están terminados. Preparar el calendarios de formación a desarrolladores Finalizar la documentación El resto de componentes pueden empezar a probar la integración Falta empaquetar en una única distribución Trew@ y w@rdA

23 Planificación 1234567891011 Análisis Primitivas Identificar Primitivas Definir Primitivas Revisar Funcional invesdoc corporate Incorporar las modificaciones (si existiesen) Construir los servicios web Implantar Servidor de pruebas Paquetizar con Trew@ Implantación en Consejerías Formación y Divulgación Entrega y Soporte