Download normativa para el desarrollo de aplicaciones con el

NORMATIVA PARA EL DESARROLLO DE APLICACIONES CON EL
SISTEMA DE GESTIÓN DOCUMENTAL DOCUMENTUM
Versión 2.3
Fecha: 05-2010
Guía Normativa de Desarrollo de Documentum
Í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
8.4.10. Alias Sets ...........................................................................................29
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 2 de 50
Guía Normativa de Desarrollo de Documentum
8.4.11.
8.4.12.
8.4.13.
8.4.14.
8.4.15.
Modulos TBO .....................................................................................29
Librerías Java.....................................................................................29
Estructura de Carpetas (Data Objects) ............................................30
Plantillas (Data Objects)....................................................................30
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
10. Entregables ................................................................................................................48
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 3 de 50
Guía Normativa de Desarrollo de Documentum
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
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
entorno
de
validación
y
Página 4 de 50
Guía Normativa de Desarrollo de Documentum
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
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
(Se
ha
incluido
referencia
a
Página 5 de 50
Guía Normativa de Desarrollo de Documentum
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.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 6 de 50
Guía Normativa de Desarrollo de Documentum
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
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 7 de 50
Guía Normativa de Desarrollo de Documentum
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.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 8 de 50
Guía Normativa de Desarrollo de Documentum
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.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 9 de 50
Guía Normativa de Desarrollo de Documentum

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.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 10 de 50
Guía Normativa de Desarrollo de Documentum
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.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 11 de 50
Guía Normativa de Desarrollo de Documentum
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.
Documentum
Content Server
Red Hat Ent
. 4 . 0 Upgrade 5
Docbroker
6 . 0 SP 1
Content Server
6 . 0 SP 1
1 – N Docbases
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
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 12 de 50
Guía Normativa de Desarrollo de Documentum
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
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 13 de 50
Guía Normativa de Desarrollo de Documentum
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:
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 14 de 50
Guía Normativa de Desarrollo de Documentum
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 15 de 50
Guía Normativa de Desarrollo de Documentum
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:
Enterprise Linux AS
(Nahant Update 5)
Red
Hat
release 4
Apache Tomcat/5.5.23
Sistema
Operativo:
Enterprise Linux AS
(Nahant Update 3)
Red
Hat
release 4
Servidor de Aplicaciones (webtop)
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
http://desarrollo.madrid.org/soja_int/html/web/EnlaceRecurso.icm?cd_recurso=1082
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 16 de 50
Guía Normativa de Desarrollo de Documentum
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:
http://desarrollo.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_manual=1347
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 17 de 50
Guía Normativa de Desarrollo de Documentum
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).
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 18 de 50
Guía Normativa de Desarrollo de Documentum

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
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 19 de 50
Guía Normativa de Desarrollo de Documentum
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.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 20 de 50
Guía Normativa de Desarrollo de Documentum
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
el
manual
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
aiaa_fw2_java_metodos_v1_0.doc publicado en:
http://desarrollo.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_manual=6101
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:
http://desarrollo.madrid.org/soja_int/run/j/EnlacePlantilla.icm?cd_plantilla=1984
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 21 de 50
Guía Normativa de Desarrollo de Documentum
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
CONSEJERÍAS
REPOSITORIO
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
06
Consejería de Presidencia, Justicia e Interior SOLO JUSTICIA
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 22 de 50
Guía Normativa de Desarrollo de Documentum
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
para su propio uso.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 23 de 50
Guía Normativa de Desarrollo de Documentum
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
xxxx_td_descripcion
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 24 de 50
Guía Normativa de Desarrollo de Documentum
dm_document
cm_documento_gral
cm_documento_auditado
xxxx_td_descripcion
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:
http://desarrollo.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_manual=7001
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
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 25 de 50
Guía Normativa de Desarrollo de Documentum
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:
http://desarrollo.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_manual=7001
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.

La plantilla se registra en el objeto dm_acl, no aplica indicar una ruta en la docbase.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 26 de 50
Guía Normativa de Desarrollo de Documentum
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.
/System/Applications/XXXX (código de aplicación)/Workflow

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.
/System/Applications /XXXX (código de aplicación) /LifeCycles

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:
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 27 de 50
Guía Normativa de Desarrollo de Documentum

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.
/System/Applications/XXXX (código de aplicación)/Procedures

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.

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.
/System/Applications/XXXX (código de aplicación) /Jobs

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.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>
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 28 de 50
Guía Normativa de Desarrollo de Documentum
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.
<código de aplicación>_tbo_lib_<descripción>.jar
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 29 de 50
Guía Normativa de Desarrollo de Documentum

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.
/System/Applications/XXXX (código de aplicación) /JavaLibs

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.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.
/XXXX (código de 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>
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 30 de 50
Guía Normativa de Desarrollo de Documentum

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.
/Templates/XXXX (código de 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…
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 31 de 50
Guía Normativa de Desarrollo de Documentum

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.
<código de aplicación>_jmtd_<descripción>
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 32 de 50
Guía Normativa de Desarrollo de Documentum
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.zip y 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
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 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
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
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 33 de 50
Guía Normativa de Desarrollo de Documentum
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.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 34 de 50
Guía Normativa de Desarrollo de Documentum
xxxx_webtop
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)
java
ear
desarrollo
fuentes
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
classes_webtop
Carpeta que contiene todos los .class propios del
producto.
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.
xxxx_webtop
web
Paquete principal
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.
Descripción Estructura de Carpetas.

java/ear/desarrollo contiene todos los ficheros entregables del proyecto:
o
o
o
xxxx_webtop.war.
dfc.properties
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:
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 35 de 50
Guía Normativa de Desarrollo de Documentum
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:
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 36 de 50
Guía Normativa de Desarrollo de Documentum
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.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 37 de 50
Guía Normativa de Desarrollo de Documentum
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
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 38 de 50
Guía Normativa de Desarrollo de Documentum
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.
Se muestra en la siguiente figura.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 39 de 50
Guía Normativa de Desarrollo de Documentum
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
dm_document
cm_traza_lopd
xxxx_td_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)
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 40 de 50
Guía Normativa de Desarrollo de Documentum
4. Todos los tipos documentales que contengan datos de carácter personal de nivel alto
deben de heredar del tipo cm_documento_auditado, proporcionado por icm en su
tipología básica. De este tipo heredará el campo cd_clave que debe de utilizarse como
clave del tipo documental.
dm_document
cm_documento_gral
cm_documento_auditado
xxxx_td_descripcion
La forma de generar la traza dependerá de que el acceso al gestor documental, se realice con
usuarios nominales o con usuario genérico.
Usuario Generico:
Cuando el acceso a documentum desde la aplicación se realice con usuario genérico, la
trazabilidad se delegará a la aplicación. La aplicación será la responsable de que antes de
invocar a operaciones de alta, baja, consulta y modificación de datos almacenados en
documentum, llame manualmente al paquete xxxx_pack_log (siendo xxxx el código de
aplicación), según la normativa de trazabilidad estándar de ICM.
Para este tipo de aplicaciones java, que adicionalmente tengan otros desarrollos java
(java_metodos, tbo’s) ejecutados en el content Server y sobre los que se quiera auditar sus
operaciones, icm ha instalado en la base de datos de documentum el paquete docu_pack_log,
al que debe de llamarse manualmente, previamente a invocar operaciones de alta, baja, consulta
y modificación de datos personales de nivel alto. Este paquete será común para todas las
aplicaciones y es igual al paquete estándar de envío y almacenamiento de trazas.
En soja se encuentra publicado un ejemplo de java método (fw2_jmtd_plantilla) que invoca al
paquete docu_pack_log en: xxxx
Para consultar la normativa de trazabilidad estándar de ICM, ver documento de Trazabididad de
accesos a ficheros de alto nivel de Seguridad, publicado en soja en:
https://gestiona.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_elemento=621
Usuarios Nominales:
Cuando el acceso a documentum se realice con usuarios nominales, la trazabilidad se delegará a
documentum. El proveedor solicitará a icm la configuración de las auditorias necesarias sobre los
tipos documentales a auditar, mediante la ficha de entrega del mólulo de documentum.
Peridodicamente icm ejecutará un proceso batch para migrar los datos almacenados en las tablas
de auditoria de documentum al sistemas de trazas disponible para el framework2, para que
posteriormente puedan ser explotadas por la aplicación SGUR_WEB
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 41 de 50
Guía Normativa de Desarrollo de Documentum
10. Procedimiento de entrega de aplicaciones DCTM
10.1. Formato de entrega de las aplicaciones DCTM en ICM.
Como se especifica en la normativa de ICM los proveedores entregaran las docapps, desarrollos y
scripts de preinstalación y postinstalación por los procedimientos que se encuentren en vigor en el
momento de la entrega (actualmente vía ftp ).
No obstante es preciso estructurar el formato de las entregas para identificar con facilidad por
parte de ICM el contenido de la parte de documentum y para acoger nuevos componentes futuros
como por ejemplo modelos de datos y tipos de desarrollo de futuras versiones del producto sin
que impacte en la estabilidad de los entornos.
El primer paso es indicar la nomenclatura que se va a seguir en la descripción de la estructura de
carpetas en las que se van a alojar los distintos módulos que componen la entrega de
documentum.
Tipo
PREFIJO
IDENTIFICADOR MODULO DOCUMENTUM
IDENTIFICADOR MODULO JAVA METODOS
IDENTIFICADOR MODULO TBO’s
IDENT. MODULO CARGA INICIAL DE DATOS
IDENT. MODULO PERSONALIZACION WEBTOP
Descriptor
CÓDIGO DE PROYECTO XXXX
docu
jmtd
tbo
batch_cdatos
webtop
Todas las entregas realizadas en el entorno de Integración, se consideran Entregas
Iniciales.
A continuación se especifica en el siguiente esquema la estructura de carpetas definidas
para las entregas iniciales de software para los módulos de documentum:
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 42 de 50
Guía Normativa de Desarrollo de Documentum
XXXX_AAAAMMDD
Contiene un fichero erwin con una subarea llamada
Documentum en la que se crean los objetos oracle
necesarios (sinónimos,secuencia y trigger)
XXXX-ERW-vv.rr-aaaammdd.er1
BASE DATOS
ERWIN
xxxx_docu
Carpeta que contiene:
Docapp modelo de datos. xxxx_modelo_de_datos_v[n]
Scripts: xxxx_preinstalación_v[n].api
xxxx_postinstalación_v[n].dql
xxxx_marcha_atras_v[n].ebs
Carpeta que contiene los fuentes java en formato proyecto
eclipse de java métodos según plantilla
fw2_jmtd_plantilla.zip
DOCAPP
xxxx_jmtd_<nombre>
Carpeta que contiene los fuentes java en formato proyecto
eclipse de los tbo’s según plantilla fw2_batch_plantilla.zip
xxxx_tbo_<nombre>
xxxx_batch_cdatos
Carpeta que contiene los fuentes java en formato proyecto
eclipse del programa de carga inicial de datos según plantilla
fw2_batch_plantilla.zip
xxxx_webtop
Carpeta que contiene los fuentes java en formato proyecto
eclipse del cliente webtop personalizado
Una vez pasada la aplicación a producción, el resto de entregas se considerarán Entregas
Incrementales. A continuación se especifica en el siguiente esquema la estructura de carpetas
definidas para las entregas incrementales de software para los módulos documentum.
XXXX_AAAAMMDD
Contiene un fichero erwin con una subarea llamada
Documentum en la que se crean los objetos oracle
necesarios (sinónimos,secuencia y trigger)
XXXX-ERW-vv.rr-aaaammdd.er1
BASE DATOS
ERWIN
Docapp modelo de datos. xxxx_modelo_de_datos_v[n]
Scripts: xxxx_preinstalación_v[n].api
xxxx_postinstalación_v[n].dql
xxxx_marcha_atras_v[n].ebs
xxxx_docu
DOCAPP
Docapp modelo de datos. xxxx_modelo_de_datos_inc_v[n]
Scripts: xxxx_preinstalación_inc_v[n].api
xxxx_postinstalación_inc_v[n].dql
xxxx_borrado_objetos_inc_v[n].ebs
Carpeta que contiene los fuentes java en formato proyecto
eclipse de java métodos según plantilla fw2_jmtd_plantilla.zip
Carpeta que contiene los fuentes java en formato proyecto
eclipse de los tbo’s según plantilla fw2_batch_plantilla.zip
Carpeta que contiene los fuentes java en formato proyecto
eclipse del programa de carga inicial de datos según plantilla
fw2_batch_plantilla.zip
DOCAPP_INC_V[n]
xxxx_jmtd_<nombre>
xxxx_tbo_<nombre>
xxxx_batch_cdatos
xxxx_webtop
Carpeta que contiene los fuentes java en formato proyecto
eclipse del cliente webtop personalizado
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 43 de 50
Guía Normativa de Desarrollo de Documentum
Descripción de la Entrega.
En la colección de software que ICM recoge del proveedor en la estructura del apartado
anterior se distinguen los siguientes contenidos.

BASE DATOS/ERWIN
o
Contiene un fichero erwin con una subárea llamada Documentum en la que se crean
los objetos oracle necesarios en la Base de Datos de Documentum. Los objetos que se
permiten crear en este subárea són: sinónimos, secuencia y trigger. Cualquier otro
tipo de objeto que se necesite crear, será necesaría autorización previa por parte de
ICM.
El diseño de esta subárea se realizará según la Guía de Diseño Erwin publicada en:
http://desarrollo.madrid.org/soja_int/html/web/EnlaceManual.icm?cd_manual=6981.
o
Los nombres de los objetos de oracle seguirán la normativa definida en el apartado 3
Normativa de Objetos Oracle del documento NOMENCLATURA SOBRE OBJETOS
ORACLE, MÓDULOS TÉCNICOS Y NOMBRES DE ARCHIVOS DE PROYECTO,
publicado
en:
http://desarrollo.madrid.org/soja_int/html/web/EnlaceManual.icm?cd_manual=7001
o
La entrega de este fichero es opcional.


Nomenclatura: XXXX-ERW-vv.rr-aaaammdd.er1

XXXX: Nombre del proyecto

vv.rr: Versión y revisión del proyecto (por ejemplo 1.0)

aaaammdd: Fecha (por ejemplo 20092506).
xxxx_docu/DOCAPP contiene:
o
Script de preinstalación del sistema. Este script debe de contener la creación de los
objetos documentales que forman parte del modelo de datos documentum y que por su
naturaleza no se pueden desplegar dentro de la docapp. Por lo general suelen ser las
listas de control de acceso (ACL) definidas para la aplicación. En cualquier caso el
proveedor debe documentar en la ficha de entrega del modulo de documentum los
objetos y propiedades que se crean al ejecutar el procedimiento. Este script debe
codificarse en iapi La entrega de este fichero es obligatoria

Nomenclatura: xxxx_preinstalacion_v[n].api . (Todo en minúsculas).

Ejemplo: xxxx_preinstalacion_v1.api
create,c,dm_acl
set,c,l,owner_name
dm_dbo
set,c,l,object_name
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 44 de 50
Guía Normativa de Desarrollo de Documentum
xxxx_acl_acl1
set,c,l,description
acl1
grant,c,l,dm_world,1
grant,c,l,dm_owner,7,change_state,change_permit,change_owner,execute_p
roc,change_location
save,c,l
o
NOTA: Para entregas incrementales, este scrip contendrá la creación de todas las
acl’s del proyecto.
Docapp con el modelo de datos de la aplicación en documentum. Esta docapp debe
contener los Tipos de objeto (tipos documentales), plantilla de permisos, workflows,
ciclos de vida, job, java_métodos, relaciones entre tipos documentales, documentos,
estructura de carpetas y desarrollos de los binarios o librerías que gestiona y maneja
el content Server, es decir los TBO’s (type bussines object ). Dentro de esta docapp
también
se
entregará
un
procedimiento
de
postinstalación
llamado
xxxx_proc_postinstall donde se deben realizar las asignaciones de permisos a los
grupos (creado en la docapp) dentro de las acl’s (creadas previamente a la instalación
de la docapp). En las opciones de instalción de la docapp este procedimiento se
seleccionará
como
procedimiento
de
postinstalación.
Un
ejemplo
de
este
procedimiento se encuentra en la docapp con los tipos básicos + script
postintalación publicada en:
http://desarrollo.madrid.org/soja_int/html/web/EnlaceRecurso.icm?cd_recurso=1002

La entrega de este fichero es obligatoria.

Nomenclatura: xxxx_modelo_de_datos_v[n] (Todo en minúsculas).
NOTA: Para entregas incrementales, este docapp contendrá la creación de todos
los objetos documentales del proyecto.
o
Script de postinstalación del sistema. Este script debe codificarse en dql y debe de
contener el Registro de tablas externas en dctm, además de asignarles los permisos
que corresponda. Cada sentencia register debe precederse de su correspondiente
sentencia unregister. La entrega de este fichero es opcional

Nomenclatura: xxxx_postinstalacion_v[n].dql .

Ejemplo: xxxx_postinstalacion_v1.dql
unregister table dm_dbo.xxxx_ext_suca_municipio
go
register table dm_dbo. xxxx_ext_suca_municipio (
"cdpais"
char(3),
"cdprov"
char(3),
"cdmuni"
char(3),
"dsmuni"
char(50)
)
go
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 45 de 50
Guía Normativa de Desarrollo de Documentum
update dm_registered object
set owner_table_permit = 15,
set group_table_permit = 15,
set world_table_permit = 15
where object_name = 'xxxx_ext_suca_municipio'
go
NOTA: Para entregas incrementales, este scrip retistrará las tablas externas de
todo el proyecto
o
Script de marcha atrás. Este script debe borrar todos los objetos que se han creado
en el repositorio tanto en los scripts de pre y post instalación como en la docapp, se
utilizará en caso de que la instalación acabe con código de error para dejar el
repositorio en su estado inicial. Este script debe codificarse en dmbasic. El
procedimiento principal debe llamarse MarchaAtras y su cabecera debe de ser la
siguiente:
Sub MarchaAtras(repositorio As String, usuario As String, password As
String)

La entrega de este fichero es obligatoria

Nomenclatura: xxxx_marcha_atras_v[n].ebs
NOTA: Para entregas incrementales, este scrip borrará todos los objetos e
instancias del proyecto.
Un ejemplo de este procedimiento se encuentra publicado en soja en:
http://desarrollo.madrid.org/soja_int/html/web/EnlaceRecurso.icm?cd_recurso=1822

xxxx_docu/DOCAPP_INC_V[1] contiene:
o
Script de preinstalación incremental. Este script debe de contener la creación de las
nuevas listas de control de acceso (ACL) de esta entrega incremental. Este script debe
codificarse en iapi La entrega de este fichero es opcional

Nomenclatura: xxxx_preinstalacion_inc_v[n].api , siendo n mayor que 1 (Todo
en minúsculas).

Ejemplo: xxxx_preinstalacion_inc_v2.api
create,c,dm_acl
set,c,l,owner_name
dm_dbo
set,c,l,object_name
xxxx_acl_acl1
set,c,l,description
acl1
grant,c,l,dm_world,1
grant,c,l,dm_owner,7,change_state,change_permit,change_owner,execute_p
roc,change_location
save,c,l
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 46 de 50
Guía Normativa de Desarrollo de Documentum
o
Docapp incremental con el modelo de datos de la aplicación en documentum. Esta
docapp debe contener los nuevos objetos y objetos modificados en la entrega. Dentro
de esta docapp también se entregará un procedimiento de postinstalación llamado
xxxx_proc_postinstall_inc_v[n] donde se deben realizar las asignaciones de
permisos a los grupos (creado en la docapp) dentro de las nuevas acl’s (creadas
previamente a la instalación de la docapp), tambíen se podrán realizar las
modificaciones de permisos de las acl’s existentes. En las opciones de instalción de la
docapp este procedimiento se seleccionará como procedimiento de postinstalación. Un
ejemplo de este procedimiento se encuentra en la docapp con los tipos básicos +
script postintalación publicada en:
http://desarrollo.madrid.org/soja_int/html/web/EnlaceRecurso.icm?cd_recurso=1002

La entrega de este fichero es opcional

Nomenclatura: xxxx_modelo_de_datos_inc_v[n] , siendo n mayor que 1
(Todo en minúsculas).
o
Script de postinstalación incremental. Este script debe codificarse en dql y debe de
contener el Registro de nuevas tablas externas en dctm, además de asignarles los
permisos que corresponda. Cada sentencia register debe precederse de su
correspondiente sentencia unregister. En este script también se desregistrarán las
tablas externas que ya no sean necesarias. La entrega de este fichero es opcional

Nomenclatura: xxxx_postinstalacion_inc_v[n].dql . siendo n mayor que 1
(Todo en minúsculas).

Ejemplo: xxxx_postinstalacion_inc_v2.dql
unregister table dm_dbo.xxxx_ext_suca_municipio
go
register table dm_dbo. xxxx_ext_suca_municipio (
"cdpais"
char(3),
"cdprov"
char(3),
"cdmuni"
char(3),
"dsmuni"
char(50)
)
go
update dm_registered object
set owner_table_permit = 15,
set group_table_permit = 15,
set world_table_permit = 15
where object_name = 'xxxx_ext_suca_municipio'
go
o
Script de borrado de objetos incremental. Este script debe borrar todos los objetos
que se han creado nuevos en el repositorio, con esta entrega, tanto en los scripts de
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 47 de 50
Guía Normativa de Desarrollo de Documentum
pre y post instalación como en la docapp, se utilizará en caso de que la instalación
acabe con código de error para dejar el repositorio en su estado inicial. Este script
debe
codificarse
en
dmbasic.
El
procedimiento
principal
debe
llamarse
BorradoObjetos y su cabecera debe de ser la siguiente:
Sub BorradoObjetos(repositorio As String, usuario As String, password As
String)

La entrega de este fichero es obligatoria

Nomenclatura: xxxx_borrado_objetos_inc_v[n].ebs. siendo n mayor que 1 (Todo
en minúsculas).

xxxx_jmtd_<nombre>: Carpeta que contiene los fuentes java en formato proyecto eclipse de
los desarrollos de los distintos
java métodos según plantilla fw2_jmtd_plantilla.zip. Ver
apartado Desarrollo de Java Métodos . Módulo Opcional

xxxx_tbo_<nombre>: Carpeta que contiene los fuentes java en formato proyecto eclipse del
desarrollo de un tbo según plantilla fw2_batch_plantilla.zip. Habrá una carpeta de esta para
cada tbo desarrollado. Ver apartado Desarrollo de TBO's . Módulo Opcional

xxxx_batch_cdatos: Carpeta que contiene los fuentes java en formato proyecto eclipse del
programa de carga inicial de datos según plantilla fw2_batch_plantilla.zip. Ver apartado
Desarrollo de Programa Java para Carga Inicial en Documentum. Módulo Opcional

xxxx_webtop: Carpeta que contiene los fuentes java en formato proyecto eclipse del
programa de personalización del cliente estandar de documentum (Webtop).Módulo Opcional
NOTA: Los ficheros ó módulos marcados como opcionales, tan sólo lo serán cuando carezcan de
contenido.
11. Entregables
La documentación mínima exigible (con control de versiones) que entregará el equipo de
desarrollo a ICM a la finalización de los desarrollos del proyecto estará formada por:

Diseño funcional, Para aplicaciones que trabajen con Documentum se debe añadir a la
plantilla estándar de Diseño funcional para aplicaciones J2EE establecida por ICM un
apartado en el que se describa funcionalmente el módulo de Documenum. En este se
definirá: Análisis Orgánico, perfiles, grupos, usuarios, tipos documentales, jerarquía
documental, organización de la documentación, proceso de aprobación de la
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 48 de 50
Guía Normativa de Desarrollo de Documentum
documentación (ciclos de vida), procesos documentales (Workflow), políticas de seguridad,
alimentación del sistema, políticas de retención y borrado, volumetría de la documentación
y escalabilidad y rendimiento. Ver documento DDF_Documentum.doc publicado en la
WEB de SOJA.

Diseño técnico, Para aplicaciones que trabajen con Documentum se debe añadir a la
plantilla estándar de Diseño Técnico para aplicaciones J2EE establecida por ICM un
apartado en el que se reflejará al detalle toda la información relativa al módulo de
Documentum como, detalle de los tipos documentales propios de la aplicación, tablas de
Oracle externas utilizadas, o en general toda la información técnica de que pueda ser de
importancia de cara a garantizar una no dependencia del equipo de desarrollo en el
mantenimiento futuro de la aplicación. Del mismo modo se detallarán la interacción con
componentes
o
servicios
externos
de
la
aplicación.
Ver
documento
DDT_Docucmentum.doc publicado en la WEB de SOJA.

Documento de requerimientos en la estación cliente, entregado en la fase Inicial del
proyecto, en el que quedarán reflejadas las necesidades de hardware y software que ha de
reunir la estación cliente para el correcto funcionamiento de la aplicación.

Documento de pruebas, que servirá para la realización de pruebas en los entornos de
Desarrollo, Validación
y de proveedor (en este último mediante simulación de la
interacción con componentes o servicios externos).

Documento de pruebas de Carga, que definirá toda la información necesaria para la
correcta realización de las pruebas en la fase de validación.

Ficha de Entrega Aplicación Java, necesaria para la integración de la aplicación en el
entorno de ICM, para los casos en los que se haya desarrollado una aplicación cliente java
con acceso a documentum según el Framework 2. Ver documento
DESARROLLO SOFTWARE - v.1.6
FICHA ENTREGA
publicado en:
http://desarrollo.madrid.org/soja_int/run/j/EnlacePlantilla.icm?cd_elemento=1664

Ficha de Entrega Personalización Webtop, necesaria para la integración de la aplicación
en el entorno de ICM, para los casos en los que se haya personalizado la aplicación cliente
estardar de documentum (Webtop) Ver documento
Ficha_de_Entrega_Modulo_Personalización_Webtop publicado en la Web de Soja

Ficha de Entrega Modelo Documental, necesario para la integración de la aplicación en
el entorno de ICM. En esta ficha se identificarán las docapp, script de instalación, tipos
documentales, plantillas de permisos, Workflows, Ciclos de Vida, jobs, Métodos invocados
desde job, procedimientos, relaciones entre documentos, roles, alias set de aplicación,
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 49 de 50
Guía Normativa de Desarrollo de Documentum
módulos java TBO, java métodos invocados desde workflows, estructura de carpetas,
sinónimos remotos, definición de auditorias y políticas de retención y borrado .
En el caso de entregas incrementales, vendrán los objetos nuevos, modificados y dados
de baja en dicha entrega, las modificaciones realizadas deben comentarse en el apartado
de observaciones. Ver documento
Ficha_de_Entrega_de_Modulos_de_Tecnología_Documentum publicado en la WEB de
SOJA.

Documento de alta de usuarios, Para realizar las pruebas funcionales de la aplicación el
proveedor deberá de entregar la ficha de alta de usuarios, indicando los distintos perfiles
de usuarios que se tienen que dar de alta en la aplicación. Ver documento FICHA ALTA
DE USUARIOS DESARROLLO publicado en:
http://desarrollo.madrid.org/soja_int/run/j/EnlaceManual.icm?cd_manual=2461.
Normativa_de_desarrollo_ICM_con_Documentum_v2.3.doc
Página 50 de 50