NORMATIVA PARA EL DESARROLLO DE APLICACIONES CON EL SISTEMA DE GESTIÓN DOCUMENTAL DOCUMENTUM

(1)

NORMATIVA PARA EL DESARROLLO DE APLICACIONES CON EL

SISTEMA DE GESTIÓN DOCUMENTAL DOCUMENTUM

Versión 2.3 Fecha: 05-2010

(2)

Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc Página 2 de 50

ÍNDICE

1. Sobre el documento ...4

1.1. Objetivos y Alcance ...4

1.2. Audiencia ...4

1.3. Histórico de Cambios ...4

2. Glosario...6

3. Referencias ...8

4. Conceptos básicos de Documentum...9

5. Introducción...11

6. Entornos de ICM ...12

6.1. Entorno de Desarrollo/Integración ...12

6.2. Entorno de Mantenimiento ...13

6.3. Entorno de Validación ...13

6.4. Entorno de Formación. ...13

6.5. Entorno de Producción...13

7. Entorno de proveedor ...16

7.1. Instalación de servicios web...16

7.2. Instalación de docapp con tipos documentales básicos de ICM...17

8. Requerimientos de Desarrollo...18

8.1. Framework de gestión documental de ICM ...18

8.2. Criterios de Desarrollo bajo la plataforma Documentum ...19

8.3. Utilización de Repositorios ...22

8.4. Nomenclatura y ubicación en la docbase de los objetos ...23

8.4.1. Nombre de tipos documentales y atributos...24

8.4.2. Nombre de grupos. ...25

8.4.3. Nombre de tablas y columnas. ...25

8.4.4. Permission Set Templates (Plantillas de Permisos) ...26

8.4.5. Workflows ...27

8.4.6. Ciclos de vida ...27

8.4.7. Ejecutables ...27

8.4.8. Relaciones entre tipos de documentos...28

8.4.9. Roles ...29

(3)

8.4.11. Modulos TBO ...29

8.4.12. Librerías Java...29

8.4.13. Estructura de Carpetas (Data Objects) ...30

8.4.14. Plantillas (Data Objects)...30

8.4.15. Formatos ...31

8.5. Metodología de control de versiones ...31

8.5.1. Control de Versiones ...32

8.6. Desarrollo de Java Métodos...32

8.7. Desarrollo de Programa Java para Carga Inicial en Documentum...33

8.8. Desarrollo de TBO’s...33

8.9. Desarrollo de SBO ...34

8.10. Personalización del Cliente Estándar de Documentum Webtop ...34

8.11. Acceso de usuarios y aplicaciones...37

8.12. Acceso a base de datos externas...39

8.12.1. Configuración ...39

8.12.2. Administación de la base de datos de la aplicación ...39

9. Procedimiento de entrega de aplicaciones DCTM...40

9.1. Formato de entrega de las aplicaciones DCTM en ICM. ...42

(4)

1. Sobre el documento

1.1. Objetivos y Alcance

ICM, dentro del marco de servicios tecnológicos existentes actualmente, ofrece un Framework de servicios documentales a partir de los cuales se crearán aplicaciones basadas en la plataforma EMC Documentum.

El objetivo del presente documento es especificar las normativas, procedimientos y en general todos aquellos aspectos que han de ser utilizados en el desarrollo e implantación de un proyecto de gestión Documental.

Este libro está encargado de recoger los procedimientos técnicos a seguir, además de la definición de buenas prácticas para la administración de soluciones documentales, su implantación en la plataforma tecnológica actual, y su relación con los procedimientos de despliegue corporativos existentes actualmente en la Comunidad de Madrid.

1.2. Audiencia

Este documento va dirigido, a los desarrolladores, gestores de proyecto y gestores tecnológicos que quieran implantar una solución basada en Documentum en ICM, o deseen conocer los requerimientos a tener en cuenta para una correcta implantación.

1.3. Histórico de Cambios

Versión Fecha Autor Descripción

1.1 24/05/2007 ICM Primera Versión

1.2 25/09/2007 ICM Se completa la nomenclatura y rutas de

los objetos en la docbase.

Se añade el apartado para desarrollos SBO

1.3 05/02/2008 DAMADI AIAA Se actualizan los siguients apartados:

Entorno del proveedor, Entregables, gráficos entorno de validación y

(5)

produción.

1.4 20/01/2009 DAMADI AIAA Indicar que los nombre de todos los

objetos documentales deben ir en minusculas.

Modificar normativa para Plantillas Incluir apartado de Java métodos y Carga Inicial de Datos

Modificar apartado 7 Procedimiento de Entrega.

2.0 06/10/2009 DAMADI AIAA Apartado 3. Añadir referencia R10

Apartado 4: Incluir definición de docapp, Aplication Builder, Aplication Instaler, Java Métodos, tbo, docu_ws, docu_lib, docu_util_lib, esquemas xml y wsdl Modificación apartado 5 Marco Genral. Modificación apartado 5.2.1 Entorno de proveedor.

Incluir apartado 6.1 Framework

documental de icm

Modificación apartado 6.2 Criterios de

Desarrollo bajo la plataforma

documentum.

Modificación apartado 6.3 Utilización de Repositorios.

Modificar apartado 6.6 y 6.7

Incluir apartado 6.8 Desarrollo de TBO’s Eliminar Apartado Front de la aplicación Modificar Apartado Procedimiento de entrega…

2.1 03/11/2009 DAMADI AIAA Modificación apartado 9.1 Formato de

entrega de las aplicaciones DCTM en ICM (Se ha incluido referencia a

(6)

ejemplo de script de marcha atrás colgado en Soja )

Incluir apartado 8.10 Personalización del Cliente Estándar de Documentum Webtop

Modificar apartado 8.11 Acceso de

usuarios y aplicaciones (Incluir

Usuarios Genéricos de aplicación.)

2.2 10/03/2010 DAMADI AIAA Modificar apartado 8.6 para establecer

las librerías autorizadas para la ejecución de los java métodos.

2.3 17/05/2010 DAMADI AIAA Incluir apartado 8.4.15 Formatos

Modificación apartado 8.4.1.Nombre de tipos documentales y atributos.

Incluir apartado 9 Trazabilidad de Accesos a Datos de Alto Nivel de Seguridad

2. Glosario

ACL: Access Control List

API: Application Programming Interface. BOF: Bussiness Object Framework. BPM: Business Process Manager. CIS: Content Intelligence Services CTA: Content Transfer Applet.

CTS: Documentum Content Transformation Services DAB: Documentum Application Builder

DAM: Digital Asset Management. DQL: Document Query Language. ECM: Enterprise Content Management.

(7)

J2EE: Java 2 Platform, Enterprise Edition LDAP: Lightweight Directory Access Protocol RAC: Real Application Clusters

RDBMS: Relational Database Management System. RM: Record Management.

SAN: Storage Area Network WCM: Web Content Management

WDK: Documentum Web Development Kit WSF: Web Services Framework

(8)

3. Referencias

R.1 Documentum System Sizing Guide

R.2 Application Builder Installation Guide and Release Notes. R.3 Documentum Business Process Manager Release Notes R.4 Business Process Manager Installation Guide

R.5 Web Development Kit Release Notes. R.6 Administrator User Guide

R.7 Distributed Conguration Guide. R.8 Content Server Administrator’s Guide

R.9 Documentum Content Server DQL Reference Manual R.10 Documentum Foundation Classes V6. Development Guide

Toda la documentación indicada anteriormente referente a Documentum puede encontrarse en la siguiente URL:

http://powerlink.emc.com

en el apartado: Home > Support > Knowledgebase Search > Documentation and White Papers Search previa autentificación con un usuario de soporte válido proporcionado por EMC.

(9)

4. Conceptos básicos de Documentum

La plataforma EMC Documentum es una extensa suite de productos para la gestión documental que proporciona servicios para la creación, gestión, distribución y archivo de cualquier tipo de contenido empresarial.

Los conceptos más comúnmente utilizados de la plataforma Documentum son:

 Content Server: Es el núcleo de la plataforma Documentum. Como tal, ofrece toda la funcionalidad de la plataforma, seguridad, gestión de procesos o gestión de contenidos entre otros.

 Connection Broker: también conocido como docbroker, es un proceso que proporciona la información necesaria a cada cliente sobre el servidor documental al que se va a conectar desde un repositorio documental dado.

 Docbase: Una Docbase es un repositorio donde son almacenados todo el contenido gestionado por la plataforma Documentum. Cada Docbase proporciona seguridad, servicios y herramientas para compartir el contenido entre los diferentes usuarios. Para las versiones más actuales, es también utilizado en su lugar el concepto de repositorio.  DFC: Es el acrónimo de Documentum Foundation Classes Son las APIs principales de

Documentum, basadas en la plataforma J2EE y dan acceso a la funcionalidad de Documentum desde cualquier aplicación.

 ACL: es la lista de control de acceso aplicada a cada uno de los objetos residentes en el repositorio documental, y definen el tipo de operación que cada usuario puede realizar sobre el mismo.

 WDK (Web Development Kit): proporciona un Framework sobre el que construir aplicaciones Web que accedan a toda la funcionalidad de la plataforma Documentum.  Webtop: Es la aplicación cliente estándar de Documentum. Se trata de un cliente web,

construido a partir de WDK, que reúne las principales funcionalidades de la plataforma Documentum.

 DOCAPP: fichero que encapsula todos los objetos documentales de una aplicación (tipos documentales, listas de control de acceso, ciclos de vida, workflows, etc.) Permite migrar la aplicación entre distintos entornos.

 Aplicatión Builder: es un entorno gráfico de desarrollo que permite la creación y el mantenimiento de cualquier aplicación basada en la plataforma EMC Documentum. Todos los objetos se empaquetarán en un fichero docapp.

 Aplicatión Instaler: herramienta que permite la instalación de las aplicaciones desarrolladas gracias a los ficheros docapp generados previamente mediante el Aplicatión Builder.

(10)

 JAVA METODOS: son programas o scripts realizados en lenguaje Java y representados como objetos dm_method en el repositorio documental. Como el resto de los objetos de la plataforma Documentum, poseen sus propios atributos que definen los argumentos y parámetros de ejecución.

 TBO: (Type Based Object) son desarrollos implementados en java para personalizar funciones sobre un tipo de documento/s, en concreto según la función, naturaleza o necesidades de la aplicación.

 Framework de gestión documental: conjunto de soluciones de integración con Documentum a utilizar por las aplicaciones que requieran dicha integración.

 docu_ws: Solución de integración con Documentum que consiste en una serie de servicios web.

 docu_lib: Solución de integración con Documentum que consiste en un API de acceso a Documentum, este API contiene la misma funcionalidad que los servicios web.

 docu_util_lib: Librería para generar y validar los xml que se le pasan como parámetro a los servicios proporcionados por las soluciones docu_ws y docu_lib

 Esquema XML (XML Schema). Es un lenguaje cuyo objetivo principal es definir la estructura en bloques de un documento XML, al igual que lo hace un DTD, pero de una forma mucho más precisa. El framework de gestión documental incluye una serie de esquemas xml que definen la estructura de los datos de los metodos a invocar.

 wsdl: (Web Services Description Language - Lenguaje de Descripción de Servicios Web). Lenguaje basado en XML para describir servicios web. Permite describir la interfaz pública de los servicios web.

(11)

5. Introducción

Los servicios centrales documentales se encuentran plenamente integrados dentro del entorno general de servicios J2EE existentes en la Comunidad de Madrid, utilizando BEA Weblogic como servidor de aplicaciones, Oracle como motor de base de datos documental, y sistemas SAN para el almacenamiento del sistema de ficheros.

Se ha desarrollado un framework de gestión documental que ofrece una capa de abstracción a las APIS del propio producto Documentum. Este framework aunque incluye diferentes soluciones de integración la recomendada y de uso general es la que está basada en Servicios Web (docu_ws). Por norma general desde las aplicaciones desarrolladas según el framework 2 se accederá a documentum utilizando estos servicios Web.

Alternativamente a esta solución, dentro del framework de gestión documental se ha desarrollado un librería (docu_lib) que ofrece los mismos servicios que la solución de servicios web Esta librería solo debe utilizarse desde aplicaciones con exigencias de rendimiento superiores a las proporcionadas por los servicios web y siempre habiendo sido previamente autorizado su uso por Arquitectura de Aplicaciones.

(12)

Documentum proporciona un conjunto de APIs y librerías (DFC’s) para el desarrollo de aplicaciones que permiten el acceso al repositorio y todas las funciones de gestión documental que ofrece la herramienta. Este api podrá utilizarse previa autorización por parte de ICM, en los casos en los que se requiera alguna funcionalidad no proporcionada por el framework de acceso a Documentum proporcionado por ICM.

En aquellos casos en los que se determine que el cliente estandar de documentum, webtop cumple con los requisitos funcionales de la aplicación se podrá optar por usar esta solución, así como la personalización de la misma, en lugar de un desarrollo propio Java. Este caso debe ser previamente autorizado por parte de ICM.

6. Entornos de ICM

La plataforma tecnológica de Documentum en la Comunidad de Madrid, está constituida por cinco entornos: Desarrollo/Integración, Mantenimiento, Validación, Formación y Producción, cuyas características y funciones se detallarán en los siguientes apartados. Por otra parte el proveedor tiene la responsabilidad de montar en sus intalaciones un entorno con las mismas versiones que las indicadas para su desarrollo.

6.1. Entorno de Desarrollo/Integración

Documentum Content Server Red Hat Ent . 4.0 Upgrade 5

Docbroker 6.0 SP 1 Content Server 6.0 SP 1

(13)

El propósito del entorno de desarrollo es permitir que los diferentes desarrollos realizados puedan probarse en un entorno que dispone de todos los componentes tecnológicos e interfaces que se encontrarán en los entornos de Validación y Producción, de forma que las pruebas no afecten las condiciones o el estado de las aplicaciones documentales en producción.

La instalación en este entorno la realiza la Unidad de Integración de Aplicaciones en base a la correspondiente solicitud por parte del jefe de proyecto. Para lo cual es necesario que el proveedor realice una entrega de todo el software entregado y rellene la correspondiente ficha de entrega que permita la Unidad de Integración de Aplicaciones realizar la instalación de manera autónoma.

6.2. Entorno de Mantenimiento

El entorno de mantenimiento, es el entorno utilizado para desarrollar el mantenimiento correctivo de las aplicaciones. Es un entorno similar en arquitectura al entorno de desarrollo y en él estará instalada la última versión de la aplicación que esté instalada en el entorno de producción.

6.3. Entorno de Validación

El entorno de validación, es un entorno que simula situaciones reales propias al entorno de producción, y es el entorno previo del desarrollo documental antes de entrar en explotación real. Es el entorno en el cual se llevarán a cabo las pruebas de carga o estrés, intentando simular situaciones de explotación y comprobando que los tiempos de respuesta de la aplicación desarrollada son adecuados antes de llevar a cabo la puesta en producción.

En el se suelen llevar a cabo las pruebas de usuario final, por lo que, para evitar la aparición de situaciones o incidencias no previstas, este tipo de entorno es idéntico al de producción, salvo aspectos de balanceo de carga o dimensionamiento de las máquinas.

6.4. Entorno de Formación.

El entorno de formación, es un entorno que simula situaciones reales propias al entorno de producción, y se utilizará para impartir la formación de la aplicación.

6.5. Entorno de Producción

Es el entorno final, y su control y acceso es el más restringido, incluyendo la puesta en producción de los desarrollos, que ha de ser llevada a cabo por personal de sistemas, ajenos a las tareas de

(14)

desarrollo de la aplicación, en base a las instrucciones de implantación entregadas como parte entregable del desarrollo del proyecto.

La arquitectura tecnológica de los distintos entornos de ICM se puede ver en el siguiente esquema:

(15)

(16)

7. Entorno de proveedor

El entorno del proveedor no forma parte de la plataforma perteneciente a ICM. Este entorno debe ser proporcionado por la empresa desarrolladora y servirá como entorno de pruebas previa a la fase de integración. Este entorno deberá cumplir los siguientes requerimientos de versión para evitar problemas de incompatibilidad en la fase de integración.

Entorno de Aplicación

Descripción: El entorno de Aplicación debe establecerse según la normativa establecida por ICM para el FrameWork 2.0

Excepciones: Aquellas aplicaciones que utilicen la librería docu_lib o el api propietario de documentum utilizarán la versión de JDK exigida por Documetum 6.0 sp 1 para sus desarrollos.

Entorno de Documentum

Suite de Documentum Documentum 6 .0 S.P.1

Servidor de Aplicaciones( docu_ws, da) BEA Weblogic. V 9.2

Sistema Operativo: Red Hat Enterprise Linux AS release 4 (Nahant Update 5)

Servidor de Aplicaciones (webtop) Apache Tomcat/5.5.23

Sistema Operativo: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)

Base de Datos Oracle 10g R2

Application Builder EMC Documentum Application

Builder 5.3 S.P. 5.5 Update 1

7.1. Instalación de servicios web

Para poder desarrollar aplicaciones j2ee con acceso a Documentum utilizando la solución docu_ws, es necesario que el proveedor instale estos servicios en sus instalaciones. Para ello se proporciona:

 Manual de instalación en el entorno del proveedor de los servicios Web, publicado en http://desarrollo.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_manual=1341

 docu_ws.war. Fichero .war con los Servicios Web, publicado en

(17)

7.2. Instalación de docapp con tipos documentales básicos de ICM

Previo al desarrollo del modelo documental, debe instalarse en el repositorio la docapp que contiene los tipos documentales básicos de icm. Para ello icm proporciona:

 Docapp con tipos documentales básicos publicada en:

http://desarrollo.madrid.org/soja_int/html/web/EnlaceRecurso.icm?cd_recurso=865

 Documento de instalación y explotación de los tipos documentales básicos corporativos de la Comunidad de Madrid publicado en:

(18)

8. Requerimientos de Desarrollo

A continuación se muestran las diferentes normas de parametrización y desarrollo que deben aplicarse durante la realización del proyecto.

8.1. Framework de gestión documental de ICM

La funcionalidad ofrecida por el Framework de gestión documental de ICM es la siguiente:



VerDocumento

.

Este servicio realiza la visualización del documento que se corresponde con el identificador del documento que se le pasa como parámetro en un xml. El retorno de este servicio es un objeto en el cual en su primera posición está el Datahandler del contenido del documento, que el cliente se encargará de tranformar en un fichero físico para guardar en local y visualizarlo, y en la segunda posición devuelve un xml en el que nos indica el nombre del documento bloqueado.



BorrarDocumento.

Este Servicio realiza el borrado del documento que se corresponde con el identificador del documento que se le pasa como parámetro en un xml.



BuscarDocumento.

Este Servicio permite realizar consultas en documentum, pasándole la consulta dql como parámetro en un xml y devuelve un xml con el resultado de la consulta

.



GestionTablas.

Este Servicio permite realizar modificaciones, inserciones y borrados en tablas

externas, pasándole la operación a realizar como parámetro en un xml.



PedirRendition.

Este Servicio Web permite generar transformaciones de documentos a formatos .pdf y .html. Se le pasará el identificador del documento a transformar y el formato deseado como parámetros en un xml



AdministracionGrupos.

Este Servicio permite crear y modificar grupos, pasándole el identificador del grupo para el caso de modificar ó el nombre del grupo para el caso de crear uno nuevo, como parámetros en un xml.



ImportarModificar.

Este Servicio permite importar y modificar documentos. Permite modificar tanto metadatos como contenido. Se le pasará el identificador del documento (sólo en el caso de una modificación), tipo documental, lista de atributos, localización,… como parámetros en un xml y un DataHandler con el contenido del documento (sólo en el caso de una modificación).

(19)



CheckDocumento

Este Servicio permite bloquear, desbloquear y registrar los cambios en un documento por un usuario previamente bloqueado por el mismo.



GestionCarpetas.

Este Servicio permite añadir, modificar y borrar cabinet y fólder. Se le pasara el identificador del objeto (en el caso de modificación o borrado ) o el nombre del objeto y tipo de objeto (en el caso de alta) como parámetro en un xml. Dentro de este xml también se le pueden pasar opcionalmente otros parámetros como path del padre, acl, indicador de forzado de borrado en caso de tener contenido y valores para los metadatos.



PermisosDocumento.

Este Servicio permite modificar los distintos permisos de los usuarios y grupos asociados a un determinado documento, por lo tanto, lo que realmente se hace es cambiar la Acl asociada de dicho documento. Si cuando se va a modificar los permisos de un documento este contiene una acl estática se cambiará la acl del documento. Si el documento tiene una acl dinámica se cambiarán los permisos de la acl, manteniendo el documento esta acl. Se le pasara el identificador del documento y la lista de permisos a asignar al documento como parámetros en un xml.

Existe una diferencia de la librería docu_lib con respecto a los Servicios Web, en cuanto a la forma de establecer las sesiones con documentum. En los Servicios Web, cada servicio realiza una operación atómica, donde en cada uno de ellos se realiza la conexión y desconexión del repositorio. En el caso de utilizar la librería, la gestión de las sesiones con documentum se realizará desde el aplicativo java, para lo cual la librería proporciona la clase login con sus métodos conectar y desconectar.

Como trabajo en continua evolución de los sistemas de información documentales, ICM ha identificado una tipología documental básica que provea a los proveedores un marco definido para la construcción de los servicios que prestan a ICM en proyectos relacionados con Gestión Documental. Esta tipología con el desarrollo de los proyectos irá alimentándose hasta completar las estructurales básicas de la organización. ICM proporciona al proveedor esta tipología en la docapp ICM_Tipos_Basicos publicada en:

http://desarrollo.madrid.org/soja_int/html/web/EnlaceRecurso.icm?cd_recurso=865

También le proporciona un Documento de instalación de la misma y explotación de los tipos documentales básicos corporativos de la Comunidad de Madrid publicado en:

http://desarrollo.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_manual=1347

8.2. Criterios de Desarrollo bajo la plataforma Documentum

(20)

ICM considera como válidas las diferentes opciones de desarrollo sobre la plataforma Documentum:

 Desarrollo de aplicaciones J2EE con acceso a Documentum basadas en: o Servicios Web de acceso a documentum propietarios de ICM (docu_ws) o Librería java (docu_lib) con la misma funcionalidad que los Servicios Web. o El API del producto, principalmente DFCs.

 Parametrización y desarrollo del cliente estándar de la plataforma Documentum (Webtop).  Procesos planificados o batch.

La Normativa para desarrollar la integración del aplicativo java desarrollado según la normativa del Framework 2 con las distintas soluciones de acceso a Documentum permitidas, se encuentra en el documento Framework 2. Solución de Integración con documentum.

Aplicación J2EE utilizando docu_ws

En general se considerará obligatorio el desarrollo de aplicaciones java J2EE siguiendo la normativa del Framework 2 y con acceso a Documentum usando la solución docu_ws. Sin embargo, si se demuestra que esta opción no nos proporciona el rendimiento o funcionalidad requerida, podrá utilizarse otra de las opciones permitidas previa aprobación por parte de ICM. Aplicación J2EE con Librería docu_lib

Cuando por motivos de eficiencia el uso de docu_ws no nos proporcione el rendimiento necesario, se podrá utilizar la librería java docu_lib. Esta librería accede a Documentum mediante APIs propias del producto y obliga a que las aplicaciones lleven incorporadas las librerías del propio producto.

Los proyectos que utilicen Docu_lib han de incorporar las DFC’s en el .ear de despliegue. En caso de tener que realizar un cambio de versión en las DFC’s, se tendrán que actualizar estos aplicativos. El uso de esta solución deberá ser aprobada por parte de ICM.

Aplicación J2EE con DFC’s Documentum

Esta opción se utilizará cuando el framework de gestión documental, no proporcione la funcionalidad requerida para el desarrollo del proyecto. El uso de esta solución deberá ser aprobada por parte de ICM.

(21)

Consultar la referencia R.10 para más información sobre el uso de las DFC’s del Producto para acceder a Documentum.

Parametrización de Clientes Estándar de Documentum (Webtop)

El uso de clientes estándar de Documentum quedará relegado a situaciones en las que se produzca alguno de los siguientes supuestos:

 El producto (webtop) cumple perfectamente las necesidades de la lógica de negocio de la aplicación.

 La parametrización o desarrollo sobre el producto estándar no alterará el comportamiento interno de la aplicación, para no perder soporte de producto por parte de EMC.

Procesos planificados o batch

Cuando los desarrollos contengan componentes de esta tipología, deberán ser programados mediante las APIs propias del producto ( DFCs).

El desarrollo de estos procesos se realizará mediante un java método que se ejecutará bajo el servidor de métodos propio del producto (Java Method Server), cuando las librerías necesarias para su implementación estén dentro de las permitidas por icm para este tipo de desarrollos. Todas estas librerías se han empaquetado en lib_autorizadas_jmtd.zip y se han publicado en SOJA en:

………

Para el desarrollo de Java Métodos Icm proporciona al proveedor la plantilla fw2_jmtd_plantilla.zip publicada en:

http://desarrollo.madrid.org/soja_int/run/j/EnlaceRecurso.icm?cd_recurso=1542

La Normativa de desarrollo de Java Métodos está documentada en el manual aiaa_fw2_java_metodos_v1_0.doc publicado en:

En el caso de que sea necesario utilizar otras librerías el desarrollo de estos procesos se realizará siguiendo la plantilla de procesos Batchs (fw2_batch_plantilla.zip) del framework 2, publicada en SOJA en:

(22)

El uso de esta plantilla está documentado en el manual Framework_2_-_Arquitectura_de_aplicaciones_batch[1]._Versión_1.1.pdf , publicado en:

http://desarrollo.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_manual=6921 Desde este desarrollo java

Consultar la referencia R.8 para más información sobre la creación de Jobs y Métodos en la plataforma Documentum.

Reutilización de la lógica de negocio

La lógica de negocio de la aplicación puede ser implementada mediante parametrización o desarrollo del propio producto, con lo que las particularidades del sistema se ejecutarán únicamente desde la capa de presentación desarrollada según el FrameWork existente en ICM. En aquellos casos en los que sea posible que distintos clientes accedan a la misma documentación y se desee que la lógica de las operaciones sea la misma independientemente del cliente desde el que el usuario acceda, será obligado el uso de los BOF para garantizar la reutilización de código y facilitar las tareas de mantenimiento.

8.3. Utilización de Repositorios

En ICM para organizar la instalación de las aplicaciones en distintos repositorios, se ha creado un repositorio por cada agrupación funcional de Consejerías en cada uno de los entornos.

La agrupación funcional que se ha tenido en cuenta es la siguiente:

CÓDIGOS DE

REPOSITORIO CONSEJERÍAS

01 Consejería de Economía y Hacienda, Consejería de Transportes e Infraestructuras, Consejería de Medio Ambiente, Vivienda y Ordenación del Territorio

02 Consejería de Presidencia, Consejería de Cultura, Deporte y Turismo, Consejería de Inmigración y Cooperación, Consejería de Familia y Asuntos Sociales, Consejería de Empleo y Mujer

03 Aplicaciones Horizontales 04 Consejería de Educación 05 Consejería de Sanidad

(23)

Todas las aplicaciones que correspondan a la misma agrupación funcional, compartirán el mismo repositorio, almacenando la documentación generada por la nueva aplicación en un nuevo Cabinet o Archivador. Han de tenerse en cuenta las siguientes normas para facilitar la administración de la herramienta y la independencia entre ambas aplicaciones:

 Establecer una codificación adecuada para cada uno de los objetos creados en la aplicación: usuarios, grupos, tipos documentales, etc…mediante el uso de códigos de aplicación como prefijo en el nombre de los objetos, como se indica en posteriores apartados.

 Establecer una seguridad adecuada que impida el acceso a otros archivadores ajenos al de la propia herramienta a la que el usuario tenga acceso.

Una aplicación dispondrá de un repositorio dedicado cuando:

 El volumen de crecimiento de documentos, acls o usuarios esperado es suficientemente grande como para ver reducido el rendimiento de las aplicaciones que convivan en el mismo Repositorio.

 La información almacenada por la aplicación requiera condiciones de seguridad estrictas, o sea requerimiento de alguna de las consejerías o departamentos bajo petición expresa para garantizar un mejor rendimiento de las aplicaciones e independencia ante paradas de servicio o tareas de mantenimiento y configuración de cada repositorio.

8.4. Nomenclatura y ubicación en la docbase de los objetos

Documentum define los objetos propios con la siguiente Convención:

 dm_: Tipos definidos por el sistema (dm_document, dm_user, etc.)  dmr_: Tipos documentales de sólo lectura (dmr_content, etc.).  dmi_: Tipos documentales internos (dmi_type_info, etc.)

Dada esta convención en la nomenclatura de los nombres, es muy importante que los tipos documentales definidos o creados por el usuario no incluyan el prefijo dm_, ya que, al estar reservado para los tipos documentales de Documentum, todos los objetos creados con este sufijo no podrán ser ni borrados ni modificados.

La nomenclatura de todos los objetos debe seguir siempre las siguientes reglas generales: o No comenzar un nombre con el sufijo dm_, ya que Documentum reserva este prefijo

(24)

o Los nombres comenzarán por el acrónimo de la aplicación, de 4 letras, a partir de ahora se hará referencia a él como <codigo_aplicación>

o El nombre de los objetos siempre irá en minúsculas. o El nombre debe contener caracteres ASCII

o El nombre no puede contener palabras reservadas en DQL. Para más información al respecto, puede consultarse el apartado DQL reserved words de la referencia R.9.

A estas reglas, hay que sumar las definidas a modo individual para cada uno de los siguientes objetos:

8.4.1. Nombre de tipos documentales y atributos.  Tipos Documentales:

<codigo_aplicación>_td_<descripción> El nombre final ha de cumplir las siguientes reglas:

 Ha de tener como máximo 27 caracteres.

 El primer carácter ha de ser una letra. El resto pueden ser letras, dígitos o subguiones.  No puede contener espacios o puntuaciones.

 No puede ser una palabra reservada por Oracle. Para más información al respecto, consultar el Libro Normativo de BBDD Oracle.

 El nombre de los tipos documentales no puede acabar en subguión (_).

Todos los tipos documentales de tipo documento heredarán de cm_documento_gral a excepción de aquellos que contengan datos de carácter personal contenidos en ficheros de nivel alto, en cuyo caso heredarán de cm_documento_auditado. Ambos tipos están definidos dentro de la tipología básica de icm.

dm_document

cm_documento_gral

(25)

Todos los tipos documentales que sea necesario crear en una aplicación, vendrán creados inicialmente dentro de la docapp de modelo de datos, nunca podrán crearse nuevos tipos de forma dinámica mediante código.

 Atributos:

Como norma general y siempre que sea posible se seguirá la normativa definida en el apartado 3.2 Nomenclatura de Campos del documento NOMENCLATURA SOBRE OBJETOS ORACLE, MÓDULOS TÉCNICOS Y NOMBRES DE ARCHIVOS DE PROYECTO publicado en:

8.4.2. Nombre de grupos.

<codigo_aplicación>_gr_<descripción> El nombre final ha de cumplir las siguientes reglas:

 Ha de tener como máximo 32 caracteres.

 Si el nombre es acotado con apóstrofes simples (‘) cuando es referenciado, puede contener cualquier carácter contenido en el literal de una cadena simple (espacios, apóstrofes o similar).

 Si el nombre es encerrado dentro de comillas cuando es referenciado, puede ser una palabra DQL reservada.

8.4.3. Nombre de tablas y columnas.



Tablas Externas:

<codigo_aplicación>_ext_<descripción>

Las tablas externas nunca se crearán en la Base de Datos de Documentum. Estas se crearán en la Base de Datos de la aplicación y posteriormente se registrarán en Documentum. Para

dm_document

cm_documento_gral

cm_documento_auditado

(26)

poder acceder a ellas se creará un synónimo privado remoto cuyo nombre debe de coincidir con el nombre utilizado para registrar la tabla, y siguiendo la siguiente nomenclatura.

CREATE SYNONYM <codigo_aplicación>_ext_<descripción> FOR

<<PropietarioTablaEnlazada>>.<<NombreTablaEnlazada>>

@<<NombreEnlaceBaseDatosICM>>;

El nombre final ha de cumplir las siguientes reglas:

 Ha de tener como máximo 64 caracteres, sin embargo puede ser menor en función de las restricciones impuestas en la normativa establecida en la referencia de Oracle correspondiente para ICM.

 El primer carácter ha de ser una letra, el resto pueden ser letras, dígitos o subguiones.  No puede contener espacios o puntuaciones.

 No puede ser una palabra reservada por Oracle.  Columnas:

Como norma general y siempre que sea posible se seguirá la normativa definida en el apartado 3.2 Nomenclatura de Campos del documento NOMENCLATURA SOBRE OBJETOS ORACLE, MÓDULOS TÉCNICOS Y NOMBRES DE ARCHIVOS DE PROYECTO publicado en:

8.4.4. Permission Set Templates (Plantillas de Permisos)

Las plantillas de permisos, son listas de control de acceso a objetos de la docbase, la nomenclatura que tiene que tener el objeto es la siguiente:

<codigo_aplicación>_acl_<descripción>

 Para el cabinet de la aplicación se creará una acl que seguirá la siguiente nomenclatura:

<codigo_aplicación>_acl_cabinet

 Para todas las acl’s el usuario dm_world tendrá asignado el permiso 1 (None), para evitar que el contenido de una aplicación pueda ser consultado por otras.

(27)

8.4.5. Workflows

Los Workflows o circuitos de trabajo deben de seguir en la docapp la siguiente nomenclatura,

<codigo_aplicación>_wf_<descripción>

 Los workflows deben de ubicarse en la la docbase destino en el siguiente directorio, siendo XXXX el acrónimo de 4 letras en mayúsculas que representa a la aplicación.

 Por defecto la ruta está creada en documentum hasta el segundo nivel, el tercer y cuarto nivel deben de crearse en el proceso de desempaquetado de la docapp entregado por el proveedor.

8.4.6. Ciclos de vida

Los ciclos de vida o secuencia de estados por los que pasan los documentos a lo largo de su estancia en el sistema deben de seguir la siguiente nomenclatura:

<codigo de aplicacion>_lf_<descripción>

 Los ciclos de vida deben de ubicarse en la docbase en el siguiente directorio, siendo XXXX el acrónimo de 4 letras en mayúsculas que representa a la aplicación.

 Por defecto la ruta está creada hasta el segundo nivel, el tercer y cuarto nivel deben de crearse en el proceso de desempaquetado de la docapp.

8.4.7. Ejecutables

Los binarios que pueden ejecutarse en documentum son de tres clases: /System/Applications/XXXX (código de aplicación)/Workflow

(28)

 Procedimientos: deben de seguir la siguiente nomenclatura. <código de aplicación>_proc_<descripción>

 Los procedimientos deben de ubicarse en la docbase destino en el siguiente directorio, siendo XXXX el acrónimo de 4 letras en mayúsculas que representa a la aplicación.

 Métodos: deben de cumplir la siguiente nomenclatura. <código de aplicación>_ mtd_<descripción>

 Jobs: deben de cumplir la siguiente nomenclatura. <código de aplicación>_ job_<descripciónl>

 Los jobs deben de ubicarse en la docbase destino en el siguiente directorio, siendo XXXX el acrónimo de 4 letras en mayúsculas que representa a la aplicación.

8.4.8. Relaciones entre tipos de documentos

Las relaciones son constrains, relacionales (padre –hijo o de igual a igual) entre tipos documentos u objetos en documentum y tendrán la siguiente nomenclatura.

<código de aplicación>_ rl_<descripción>

/System/Applications/XXXX (código de aplicación) /Jobs

(29)

8.4.9. Roles

Los roles deben de seguir la siguiente nomenclatura: <código de aplicación>_rol_<descripción> 8.4.10. Alias Sets

Por defecto, en la docapp existe un objeto alias set con su mismo nombre, para poder indicar distintas configuraciones en la docbase destino. Para los supuestos que se creen más alias set, éstos deberán seguir la siguiente nomenclatura.

<código de aplicación>_alias_set_<descripción>

Los Permission set alias definidos dentro de los Alias Set deben seguir la siguiente nomenclatura:

<código de aplicación>_alias_<descripción>

8.4.11. Modulos TBO

Los TBO (Type Based Object) son desarrollos implementados en java para personalizar la funcionalidad por defecto sobre un tipo documental, en concreto según la función, naturaleza o necesidades de la aplicación.

Dentro de la docapp para cada tbo se creará un objeto módulo cuyo nombre debe de coincidir con el nombre del tipo documental para el que está definido, por tanto seguirá la siguiente nomenclatura.

<código de aplicación>_td_<descripción>

El nombre de la librería que contiene el interfaz del TBO debe de seguir la siguiente nomenclatura:

<código de aplicación>_tbo_interfaz_<descripción funcional>.jar

El nombre de la librería que contiene la implementación del TBO debe de seguir la siguiente nomenclatura:

<código de aplicación>_tbo_impl_<descripción funcional>.jar

8.4.12. Librerías Java

Las librerías java que se instalen en la docapp de las que dependan los TBO tendrán la siguiente nomenclatura.

(30)

 Estas librerías deben ubicarse en la docbase destino en el siguiente directorio, siendo XXXX el acrónimo de 4 letras en mayúsculas que representa a la aplicación.

8.4.13. Estructura de Carpetas (Data Objects)

Para el almacenamiento de los documentos que se generen en la aplicación será obligatorio crear un Cabinet cuyo nombre coincida con el acrónimo de 4 letras en mayúsculas, que identifica a la aplicación. Bajo este cabinet se podrá crear la estructura de carpetas necesaria según la lógica de negocio de la aplicación.

8.4.14. Plantillas (Data Objects)

Para las aplicaciones que requieran documentos que funcionen como plantillas como por ejemplo plantillas PDF o etc, tendrán la siguiente nomenclatura.

<código de aplicación>_pla_<descripción>

/System/Applications/XXXX (código de aplicación) /JavaLibs

(31)

 Estas plantillas deben ubicarse en la docbase destino en el siguiente directorio, siendo XXXX el acrónimo de 4 letras en mayúsculas que representa a la aplicación.

 Por defecto la ruta está creada hasta el primer nivel, el segundo debe de crearse en el proceso de desempaquetado de la docapp.

8.4.15. Formatos

Para las aplicaciones que requieran almacenar documentos con formatos que no vengan con la instalación estándar de documentum, el proveedor solicitará a icm la creación de los mismos a través de soja.

8.5. Metodología de control de versiones

Para facilitar las tareas de puesta en marcha de un sistema basado en Documentum y encapsular todos los elementos de aplicación desarrollados durante fases previas a la puesta en producción, Documentum pone a disposición del integrador de la plataforma el concepto de DocApp. Un archivo Docapp es un conjunto de objetos de Documentum, entre los que pueden figurar:

 Tipos Documentales (Object Types) – Hacen referencia a las parametrizaciones específicas realizadas sobre los documentos de la aplicación a implantar.

 Ciclos de Vida – A través de los cuales se definen las diferentes reglas de negocio aplicadas a los documentos cuando pasan por los diferentes estados.

 Workflows – Utilizados para reflejar procesos de negocio relacionados con la documentación.

 Plantillas de permisos – Donde se pueden crear listas de control de acceso a la documentación para los diferentes usuarios y grupos existentes en el repositorio.

 Alias Sets – Consisten en la definición de nombres simbólicos, sustituibles en la nueva ubicación en la que se vaya a implementar la DocApp para poder hacer portable el desarrollo encapsulado. Mediante el sistema de Alias, es posible realizar un desarrollo sin tener que definir nombre de usuarios, rutas, u otros parámetros dependientes del repositorio Documental.

 Métodos y Jobs – Son procedimientos automáticos utilizados para la realización de determinadas tareas. Pueden afectar a objetos específicos, ciclos de vida, workflows, etc…

(32)

 Objetos en general – Puede incluir plantillas de workflow, SmartLists, estructuras de ficheros, o otros objetos del repositorio documental que esté siendo utilizado en el desarrollo actual del sistema.

Documentum guarda la DocApp dentro del repositorio Documental en la siguiente ubicación: System\Applications\<Nombre de la DocApp>.

8.5.1. Control de Versiones Nomenclatura de las Docapps

Para cada proyecto se entregará una Docapp con la siguiente nomenclatura: <codigo_aplicación>_modelo_de_datos_v[n]

donde:

 <codigo_aplicación> identificador de aplicación en ICM:

 modelo_de_datos es un nombre fijo para la Docapp que contiene el modelo de datos de la aplicación en documentum (tipos documentales, plantilla de permisos, workflows, ciclos de vida, métodos, jobs, relaciones entre tipos documentales, documentos y estructura de carpetas) y los desarrollos de los binarios o librerías que gestiona y maneja el content Server, es decir los TBO (type bussines object )

 v[n] siendo n la versión de la Docapp. Todas las entregas iniciales vendrán con v1.  En la entrega inicial, la entrega de esta docapp será obligatoria.

8.6. Desarrollo de Java Métodos

El desarrollo de java métodos se realizará siguiendo la plantilla fw2_jmtd_plantilla.zip, proporciona por ICM y publicada en:

http://desarrollo.madrid.org/soja_int/html/web/EnlaceRecurso.icm?cd_recurso=1542.

El uso de esta plantilla está documentado en el documento de Normativa de desarrollo de Java Métodos de ICM publicada en:

http://desarrollo.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_manual=6101.

Todos los java métodos desarrollados para una aplicación se entregarán en un único fichero .jar cuyo nombre tendrá la siguiente nomenclatura:

<código de aplicación>_jmtd_<descripción>.jar

La entrega de los java métodos se realizará como un módulo a parte, cuyo nombre debe de coincidir con el nombre del jar.

(33)

Desde los java métodos el acceso a documentum se realizará mediante las DFC’s del producto.

Puesto que estos módulos se ejecutan en un servidor de aplicaciones propio del Content Server y las librerías necesarias para su ejecución se comparten entre los distintos java métodos de las diferentes aplicaciones, desde icm se han catalogado una conjunto de librerías autorizadas para la ejecución de estos java métodos.

Todas estas librerías se han empaquetado en docu_jmtd_librerias.zipy se han publicado en SOJA.

Si en el desarrollo del java método se detecta la necesidad de utilizar alguna librería no incluida en el conjunto de librerías autorizadas, previamente a su utilización, deberá solicitarse a Arquitectura de Aplicaciones la autorización de la misma, quien en ese momento decidirá incluir la librería dentro de las autorizadas o solicitar al proveedor que en lugar de un java método desarrolle un módulo siguiendo la plantilla de procesos Batchs del framework2 (fw2_batch_plantilla.zip), publicada en SOJA

8.7. Desarrollo de Programa Java para Carga Inicial en Documentum

Cuando sea necesario realizar una Carga inicial de datos y documentos se desarrollará un programa java de acuerdo a la plantilla de procesos Bath (fw2_batch_plantilla.zip) del framework 2, publicada en SOJA en:

http://desarrollo.madrid.org/soja_int/run/j/EnlacePlantilla.icm?cd_plantilla=1984

Desde este programa se accederá a documentum mediante la librería docu_lib. Cuando la librería no proporcione la funcionalidad requerida, podrán ser utilizadas las DFCs del producto, pero siempre previa autorización por parte de ICM

La entrega del programa de carga inicial de datos se realizará como un módulo a parte, cuyo nombre seguirá la siguiente nomenclatura:

<código de aplicación>_CDATOS

8.8. Desarrollo de TBO’s

El desarrollo Java de los TBO se realizará siguiendo la plantilla de procesos Batch (fw2_batch_plantilla.zip) del framework 2, publicada en SOJA en:

http://desarrollo.madrid.org/soja_int/run/j/EnlacePlantilla.icm?cd_plantilla=1984

(34)

Desde este desarrollo java se accederá a documentum mediante las DFC’s propias del producto.

El desarrollo de cada TBO se entregará en un módulo a parte y el nombre del módulo seguirá la siguiente nomenclatura:

<código de aplicación>_tbo_<descripción>

Dentro de cada módulo se entregarán dos librerías

 Librería que contiene el Interfaz del módulo, cuyo nombre seguirá la siguiente nomenclatura:

<código de aplicación>_tbo_interfaz_<descripción funcional>.jar

 Librería que contiene la implementación del módulo, cuyo nombre seguirá la siguiente nomenclatura:

<código de aplicación>_tbo_impl_<descripción funcional>.jar

Para el desarrollo de TBO’s se deben tener en cuenta las recomendaciones dadas en la referencia R.10

8.9. Desarrollo de SBO

Para las aplicaciones que se identifique el desarrollo de SBO (Services Bussines Object) estos se construirán como un Web Service de acuerdo a las especificaciones del framework 2 de servicios de ICM, además de tener en cuenta las recomendaciones para el desarrollo de SBO dadas en la referencia R.10

8.10. Personalización del Cliente Estándar de Documentum Webtop

La personalización del cliente estándar de documentum se entregará en un módulo a parte y el nombre del módulo seguirá la siguiente nomenclatura:

<código de aplicación>_webtop.

Esta carpeta debe de contener los fuentes java en formato proyecto eclipse del programa de personalización del cliente estandar de documentum (Webtop) según la siguiente estructura de directorios, siendo xxxx el código de la aplicación.

(35)

Descripción Estructura de Carpetas.

 java/ear/desarrollo contiene todos los ficheros entregables del proyecto: o xxxx_webtop.war.

o dfc.properties

o custom_xxxx_webtop.zip . Este fichero contiene el empaquetado de todos los elementos modificados o incluidos en la personalización a partir del directorio web. Ejemplo de contenido de fichero:

xxxx_webtop java

ear

Contiene todos los ficheros entregables del proyecto: xxxx_webtop.war.

dfc.properties (y otros ficheros de configuración que sean necesarios)

custom_xxxx_webtop.zip (fichero que contiene el

empaquetado de todos los elementos modificados o incluidos en la personalización a partir del directorio web)

Este directorio contendrá todos los ficheros necesarios para generar el .war. Será obligatorio que exista el fichero CrearWar.bat y el directorio classes_webtop deploys

Carpeta que contiene todos los .class propios del producto.

fuentes

desarrollo

classes_webtop

lib Directorio con las librerías necesarias de compilación en el proyecto

src

Directorio con los ficheros java fuentes en sus correspondientes paquetes. El nombre del paquete principal debe de coincidir con el nombre del módulo según normativa framework 2.

Paquete principal xxxx_webtop

Contenido del propio Webtop. Por ejemplo, dentro de la carpeta custom se incluirán los nuevos componentes y los componentes modificados en la personalización, siguiendo el mismo empaquetado que en la carpeta src.

(36)

o Otros ficheros de configuración que sean necesarios

 java/fuentes/deploys contiene todos los ficheros necesarios para generar el .war. y el directorio clases_webtop.

o CrearWar.bat. Fichero con las instrucciones necesarias para generar el .war. Ejemplo de fichero CrearWar.bat.

cd ./classes_webtop

ECHO copy of documentum classes to web-inf/classes xcopy ".\com" "..\..\Web\WEB-INF\classes\com\" /e /q cd ../../Web

ECHO generate war

jar -cfvM xxxx_webtop.war *

move xxxx_webtop.war ../../ear/desarrollo

o classes_webtop. Carpeta que contiene todos los .class propios del producto.  java/fuentes/lib contiene las librerías necesarias de compilación en el proyecto.

 java/fuentes/src. Directorio con los ficheros java fuentes en sus correspondientes paquetes. El nombre del paquete principal debe de coincidir con el nombre del módulo (xxxx_webtop) según normativa framework 2. A partir del paquete principal, los componentes modificados deben empaquetarse respetando el empaquetado del producto a partir de com.documentum. Ejempo: Si modificamos NavigationContainer.class, situado en:

(37)

WEB-INF\classes\com\documentum\webcomponent\navigation\navigationcontainer, debería empaquetarse en :

src\xxxx_webtop\webcomponent\navigation\navigationcontainer

 java/fuentes/web. Contiene el propio Webtop.

o Carpeta custom: dentro de esta carpeta se incluirán los nuevos componentes y los

componentes modificados en la personalización, siguiendo el mismo empaquetado que en la carpeta src.

 Dentro de esta carpeta se creará la carpeta xxxx_jsp para ubicar los nuevos jsp’s incluidos en la personalización, siguiendo el mismo empaquetado que en la carpeta src.

 Dentro de las carpetas theme, strings y config debe seguirse el mismo empaquetado que en la carpeta scr.

Nomenclatura para los nuevos componentes incluidos en la personalización  Ficheros jsp’s:

<código de aplicación>_jsp_<descripcion>.jsp

 Ficheros xml

<código de aplicación>_xml_<descripcion>.xml

 Ficheros css

<código de aplicación>_css_<descripcion>.css

 Ficheros tld

<código de aplicación>_tld_<descripcion>.tld

 Ficheros de Properties

<código de aplicación>_pro_<descripcion>.properties

Nota: La nomenclatura de cualquier otro tipo de componente que sea necesario incluir en la personalización de webtop debe acordarse previamente con icm.

8.11. Acceso de usuarios y aplicaciones

Dentro de la plataforma Documentum, hay que diferenciar claramente el acceso a los sistemas documentales en función del tipo de acceso:

 Acceso a través de usuarios nominales, habitual en una aplicación estándar corporativa.  Acceso a través de usuarios genéricos, para consultar, funciones especiales de

administración, funciones de auditoria.

 Acceso a través de aplicaciones, caso habitual para aplicaciones que estén disponibles desde el portal corporativo Madrid.org para cualquier ciudadano.

(38)

Usuario nominales

Este será el caso más habitual cuando sean creadas aplicaciones puramente documentales. Los usuarios deberán siempre conectarse a través de la utilización de su usuario y contraseña, para garantizar la seguridad de la plataforma. En estos casos habrá una integración directa del repositorio con el Directorio Activo, que deberá contener información básica del usuario autentificado, en particular:

 Usuario de Acceso.

 Contraseña de Acceso a los sistemas.  Email.

 DNI

Esta autenticación contra el directorio activo deberá ser llevada a cabo a través de la configuración del objeto LDAP Config del repositorio documental para autentificar los usuarios de entrada al repositorio. Por otro lado, será responsabilidad del área de Gestión de Usuarios el alta de los usuarios en el directorio Activo, que deberán contar con todos los datos identificativos detallados anteriormente.

Estos usuarios como máximo podrán tener permisos de Coordinator en su Client Capability y nunca podrán tener privilegios de Superuser

Usuario genéricos

La aplicación que lo necesite podrá tener usuarios genéricos, para realizar consultas, tareas de administración y para gestionar auditorias. Estos usuarios se crearán en el repositorio de tipo Inline Password en el momento de la instalación de la aplicación, en el caso de ser solicitados por parte del proveedor en la Ficha de Entrega del Modelo Documental.

 Usuario de Consulta : con_<código_aplicación>, con los siguientes permisos o Client Capability: Consumer

o Privilegios: None

o Privilegios Extendidos: None

 Usuario Administración: adm_<código_aplicación>, con los siguientes permisos o Client Capability: Coordinator

o Privilegios: SYSADMIN

o Privilegios Extendidos: Lo que indique el proveedor a excepción del valor Superuser  Usuario de Auditorias: aud_<código_aplicación>, con los siguientes permisos

o Client Capability: Consumer o Privilegios: None

o Privilegios Extendidos: Lo que indique el proveedor Aplicaciones

(39)

La aplicación que lo necesite tendrá un usuario específico creado para el acceso al repositorio documental, y proporcionará a éste mediante algún mecanismo información sobre el usuario que está realizando la petición a la aplicación, de cara a garantizar la trazabilidad de operaciones sobre cada uno de los objetos almacenados en el repositorio documental.

Por lo tanto, será competencia de la aplicación garantizar la seguridad de acceso de usuarios y/o ciudadanos.

8.12. Acceso a base de datos externas

El diseño del modelo de datos oracle de las aplicaciones que utilicen Documentum como Gestor Documental se realiza creando un esquema por aplicación en una base de datos independiente de la Base de Datos de Documentum (Base de Datos de la Aplicación) . Para acceder a las tablas de la aplicación desde documentum, se realizará vía dblink , creando sinónimos privados remotos en la Base de Datos de Documentum para estas tablas y registrándolas como tablas externas en documentum.

8.12.1. Configuración

Con la incorporación de Documentum como herramienta de gestión documental corporativa es necesario detallar a continuación el modelo normalizado de diseño de conexión y explotación entre el modelo de datos de las aplicaciones y el modelo de datos del repositorio documental. Siguiendo el modelo de conexión actual de ICM las aplicaciones que se construyan con documentum como gestor documental accederán a las tablas de base de datos de la aplicación vía dblink. Desde DCTM para el manejo de estas tablas se registrarán como tablas externas. 8.12.2. Administación de la base de datos de la aplicación

En las aplicaciones que utilicen Documentum la administración y mantenimiento de las tablas de la propia aplicación se realizarán a través del pool de conexiones o datasource que provee ICM para el acceso desde aplicaciones java a base de datos. El acceso al repositorio documental se realizará a través de alguna de las opciones permitidas por icm, principalmente mediante el Framework Documentum de Servicios Web propietario de Icm.

(40)

9. Trazabilidad de Accesos a Datos de Alto Nivel de Seguridad.

En este apartado se definen las pautas a seguir por aquellas aplicaciones que necesiten trazar los accesos que realicen los usuarios a datos personales de nivel alto, almacenados en documentum. Dentro de la docapp se entregará:

1. Creación de un tipo documental llamado xxxx_td_traza_lopd que heredará del tipo cm_traza_lopd proporcionado por icm en su tipología básica. En este tipo se almacenarán datos tales como fichero inscrito en el registro de la APD, Código Centro Directivo al que pertenecen los datos y Código Centro Directivo al que pertenece el usuario que accede, todos ellos heredados de cm_traza_lopd

2. Se creará una dm_folder llamada LOPD ubicada dentro del cabinet XXXX (siendo XXXX el código de aplicación), a la que se le asignará el acl xxxx_acl_lodp con los siguientes permisos

a. dm_world tendrá asignado el permiso 1 (None), b. dm_owner tendrá asignado el permiso 7 (Write).

3. Se creará una instancia del tipo documental xxxx_td_traza_lopd llamada xxxx_traza_lopd dentro de la carpeta LOPD con los datos obligatorios de trazabilidad para esa aplicación. (siendo xxxx el código de aplicación)