Alfresco Manual w6ag
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report r6l17
Overview 4q3b3c
& View Alfresco Manual as PDF for free.
More details 26j3b
- Words: 7,110
- Pages: 46
Alfresco
El modelo de metadatos
Alfresco: El modelo de gestión documental y la utilización de metadatos Andrés Aznar [email protected]
Andrés Aznar Royo
Página 1
Alfresco
El modelo de metadatos
INDICE 1.- Introducción a la gestión documental de Alfresco ......................3 1.1.- Alfresco gestor documental .................................................3 1.2.- Sobre el autor ........................................................................3 2.- Los documentos en Alfresco ......................................................4 2.1.- Un contenedor de documentos y algo más ........................4 2.2.- Búsquedas por metadatos y por contenido........................4 3.- Metadatos ...................................................................................6 3.1.- Etiquetas, Categorías, Aspectos y Tipos ............................6 4.- La definición del modelo ...........................................................14 4.1.- Estructura jerárquica ..........................................................14 4.2.- Definición a partir de un ejemplo real ...............................15 5.- Implementación del modelo......................................................18 5.1.- Fichero de declaración del modelo ...................................18 5.2.- Fichero de definición del modelo ......................................19 5.3.- El fichero de publicación en Alfresco Explorer ................26 5.4.- El fichero de propiedades ...................................................33 5.5.- El fichero de declaración en Alfresco Share ....................34 5.6.- El fichero de publicación en Alfresco Share.....................35 5.7.- Los ficheros del menú de carga de Share.........................42 6.- Conclusiones ............................................................................46
Andrés Aznar Royo
Página 2
Alfresco
El modelo de metadatos
1.- Introducción a la gestión documental de Alfresco 1.1.- Alfresco gestor documental Alfresco es un gestor documental open source nacido a raíz de una escisión de personas desde EMC (empresa propietaria del software de gestión documental Documentum) y la participación del actual CEO y presidente John Powell que venía de Business Objects (compañía actualmente adquirida por SAP). Alfresco presenta una arquitectura web, basada en una base de datos (acepta tanto open source como Mysql o PostgreSQL como Oracle y otras de carácter comercial), un servidor de aplicaciones Java (también en este caso puede ser open source como Tomcat o JBoss o comercial como Websphere o Weblogic) y la propia aplicación Alfresco que se despliega en el servidor y que tiene formato modular (Explorer, Share, Web Content Manager…).
1.2.- Sobre el autor Andrés Aznar soy yo. Mi formación es de ingeniería industrial aunque llevo más de quince años dedicado a los proyectos IT en diferentes empresas y sectores. Mis inicios en la gestión documental provienen del uso de Autodesk WorkCenter (hoy día un producto obsoleto y no existente) que era un incipiente embrión de la parte de la gestión documental relacionada con el ciclo de vida de producto (PLM o Product Lifecycle Management). Más tarde he sido implantador de sistemas de gestión documental puros como FileNet o PoseiDoc Gestor documental, sistemas PLM (Teamcenter), sistemas BPM (Business Process Management) como Fujitsu Teamware o Staffware y más recientemente los denominados ECM (Enterprise Content Management) como puede ser Alfresco (sistema más orientado a la documentación) o Liferay (orientado a portales y gestión de contenidos). Cuando un profesional se queda sin trabajo es el momento de recapitular y dar un pequeño vistazo a todo eso que hemos aprendido y, cuyas pruebas en forma de proyectos, desarrollos, implantaciones, se han quedado en las empresas o clientes en los que hemos trabajado. Con motivo de dar un orden a todo ese conocimiento y acercarlo a la comunidad, surge el proyecto de realizar una serie de documentos (llamémoslos manuales o pequeños libros de producto) a fin de poner negro sobre blanco sobre todo ese conocimiento almacenado en la materia gris. Este es un primer manual que espero pueda ser de utilidad a la comunidad. Si la situación de desempleo se alarga, quizás pueda obsequiarles con alguna cosa adicional, aunque sin mala intención les digo que ojalá no sea así.
Andrés Aznar Royo
Página 3
Alfresco
El modelo de metadatos
2.- Los documentos en Alfresco 2.1.- Un contenedor de documentos y algo más Cuando introducimos un documento en Alfresco, ya sea directamente a través de alguno de sus portales (Explorer o Share) o mediante el por caminos integrados en el entorno de trabajo (WebDav, Sharepoint Protocol, Plug-ins de MS Office) éste quedará almacenado en aquel contenedor donde le asignemos (una carpeta, la librería documental de un portal del Share…).
Alfresco Explorer: vista de un documento dentro del directorio de
Pero es obvio que lo que buscamos cuando nos planteamos el uso de un gestor documental no es tan sólo replicar la funcionalidad que nos puede dar la estructura de directorios de un sistema operativo, sino que se busca disponer de unas herramientas de indexación que nos permita luego realizar, entre otras cosas, unas búsquedas selectivas de esos documentos almacenados independientemente de donde se hallen o el formato en que estén generados.
2.2.- Búsquedas por metadatos y por contenido Los documentos introducidos en Alfresco deberán, con posterioridad, ser recuperados por los s. Y para ello la misión del integrador que realiza la implementación del proyecto de implantación será el ofrecer las herramientas más intuitivas y eficaces para que el sea capaz de buscar y acceder a esos documentos de manera ágil.
Andrés Aznar Royo
Página 4
Alfresco
El modelo de metadatos
La gestión documental clásica y los primeros sistemas construidos para este menester basaban la indexación de los documentos en los denominados metadatos (o también llamadas propiedades). Los metadatos son campos que se añaden a un archivo documental y que nos permitirá con posterioridad utilizar sus posibles valores para realizar búsquedas. En Alfresco veremos que nos podemos encontrar con cuatro tipos de organización para los metadatos a añadir: las etiquetas, las categorías, los aspectos (que en realidad son conjuntos de metadatos) y los tipos. Con posterioridad a esta visión más clásica de la indexación documental han surgido herramientas que permiten añadir la búsqueda por contenidos, es decir, se trata de funciones que permiten penetrar en el interior del documento (un html, un archivo ofimático o un PDF) y realizar la búsqueda de un contenido concreto (una cadena de caracteres) dentro de dicho documento. En el caso de Alfresco, esta posibilidad está desarrollada a través de SOLR. SOLR es un motor de búsqueda de código abierto basado en la biblioteca Java del proyecto Lucene, con APIs en XML/HTTP y JSON, resaltado de resultados, búsqueda facetada, caché, y una interfaz para su istración. Al tratarse de una herramienta bajo licencia Apache Software Foundation, Alfresco sólo la tiene disponible si el servidor de aplicaciones sobre el que desplegamos el programa es Apache Tomcat. La misión de este manual es explicar en detalla la construcción del modelo de metadatos, así que la gestión y despliegue del SOLR la dejaremos para otro volumen.
Andrés Aznar Royo
Página 5
Alfresco
El modelo de metadatos
3.- Metadatos 3.1.- Etiquetas, Categorías, Aspectos y Tipos Como hemos mencionado anteriormente disponemos de cuatro herramientas para gestionar la indexación de un documento por sus metadatos. Estas herramientas son las etiquetas, las categorías, los aspectos y los tipos.
3.1.1.- Etiquetas Una etiqueta es un nombre clave, una palabra, o cualquier cadena alfanumérica que podemos asociar al documento. Las etiquetas no son exclusivas de los documentos, podemos etiquetar una entrada en un blog del Share, una entrada en el wiki etcétera. Asimismo no existen unos valores predeterminados sino que el puede añadir esas palabras clave que crea oportunas para identificar el documento al que se está refiriendo.
Alfresco Share: Visión de las propiedades de un documento y sus etiquetas
Una vez generadas las etiquetas podremos utilizarlas para realizar búsquedas. En el caso de Share, la propia interfaz del portal ya incluye la enumeración de las etiquetas en el menú de la parte izquierda de la pantalla. Así, marcando la etiqueta para la que queremos encontrar ítems, nos aparecerán todos aquellos elementos (no sólo documentos, sino también entradas wiki, blog…) que contengan la mencionada etiqueta. Para el caso de Explorer no existe en la interfaz base una metodología para la búsqueda por etiquetas.
Andrés Aznar Royo
Página 6
Alfresco
El modelo de metadatos
Interfaz de Alfresco Share y listado de objetos por etiquetas
Para que un documento pueda tener etiquetas dicho documento debe tener activado el aspecto “Etiquetable” (en inglés “Taggable”). En caso contrario no aparecerá la opción de poder asignarle estos campos al documento.
3.1.2.- Categorías Las categorías son otro tipo de metadato existente en Alfresco. Al contrario de lo que pasa con las etiquetas, las categorías sí son campos preconfigurados, y al categorizar un documento le asignamos un valor o valores (un documento puede tener varías categorías) predeterminados.
Alfresco Explorer: Gestión de las categorías desde la consola de istración
Andrés Aznar Royo
Página 7
Alfresco
El modelo de metadatos
Además las categorías pueden definirse en un árbol de jerarquías, pudiendo así una categoría tener subcategorías. De esta manera también la istración de las mismas se realiza de una forma más sencilla y permite su con mayor facilidad y rapidez.
Alfresco Share: Propiedad “Departamento”
Alfreso share: Subpropiedades de la propiedad “Departamento”
Como observábamos que ocurre en el caso de las etiquetas, las categorías, inicialmente, no están accesibles para los documentos a no ser que indiquemos específicamente que sea así. En las propiedades de los documentos (dentro del Explorer) existe un apartado para la categorización donde se permite activar ésta y poder gestionar las categorías a las que haremos pertenecer a ese documento. Desde Share la categorización (aunque el término utilizado en Share es clasificación) se debe hacer añadiendo el aspecto “Clasificable” al documento, en la gestión de aspectos.
Andrés Aznar Royo
Página 8
Alfresco
El modelo de metadatos
Alfresco Explorer: Gestión de la categorización de un documento
Alfresco Share: Gestión de los aspectos y adición de la posibilidad de uso de las categorías
Las categorías también presentan una ventaja importante con respecto a las etiquetas: el buscador avanzado de Explorer dispone, por defecto, de la posibilidad de realizar búsquedas por categoría.
Andrés Aznar Royo
Página 9
Alfresco
El modelo de metadatos
Visión de la búsqueda avanzada en Explorer. En la parte inferior izquierda existe la búsqueda por categorías
3.1.3.- Aspectos Los aspectos aportan características a un documento. Por defecto, en Alfresco ya existen una serie de aspectos predefinidos. Dos de ellos ya los vimos con anterioridad: el aspecto de etiquetable y el de clasificable. Además de estos dos existen algunos más, como puede ser el de ser un documento versionable, editable en línea… En el apartado anterior veíamos una pantalla de Share donde se realizaba la asignación de aspectos a un documento. Pero además de los aspecto predefinidos del sistema, cuando implantemos Alfresco una de las tareas principales será definir el árbol documental, donde generaremos nuevos aspectos definidos por el proyecto que nos ocupe y destinado a determinados tipos de documentos. Estos aspectos definidos por el serán conjuntos de propiedades o metadatos que podremos asignar a un documento o tipo de documentos. En apartados posteriores se explicará la generación de estos aspectos y del modelo de árbol documental en su globalidad. Veremos entonces que los pasos a seguir para la generación y uso de un aspecto son: 1. Creación del aspecto en el fichero xml de modelo de contenido. 2. Adición del aspecto al fichero de renderización de explorer para los diferentes entornos donde se debe acceder (acciones, creación de un nuevo documento, reglas, búsqueda avanzada). 3. Adición del aspecto al fichero de renderización del share (con igual extensión a todos los s).
Andrés Aznar Royo
Página 10
Alfresco
El modelo de metadatos
Vista del fichero de contenido personalizado y del código de creación de un aspecto
Las propiedades de los aspectos definidos por el se deben renderizar en la interfaz tanto de Explorer como de Share.
Pantalla de búsquedas avanzadas de Explorer. Las propiedades de los aspectos se programan para ser visualizados en el apartado de Opciones adicionales.
Andrés Aznar Royo
Página 11
Alfresco
El modelo de metadatos
Pantalla de búsquedas avanzadas de Share con las propiedades de los aspectos personalizados.
3.1.4.- Los tipos Los tipos de documentos permiten generar una infraestructura jerarquizada para la documentación que se almacena en Alfresco. De base el sistema presenta un tipo denominado “content” que será la base para la construcción de otros tipos, siempre como subtipos del content. Estos subtipos, al igual que las categorías, son jerárquicos y pueden extenderse varios rivales. Cuando asignemos un tipo a un documento recogerá todas las características del mismo así como de los tipos ancestros al que estamos usando. Al igual que ocurre con los aspectos, tendremos tres pasos para generar y utilizar un tipo: 1. Creación del tipo en el fichero xml de modelo de contenido. 2. Adición del tipo al fichero de renderización de explorer para los diferentes entornos donde se debe acceder (acciones, creación de un nuevo documento, reglas, búsqueda avanzada).
Andrés Aznar Royo
Página 12
Alfresco
El modelo de metadatos
3. Adición del tipo al fichero de renderización del share (con igual extensión a todos los s).
Vista del fichero de contenido personalizado y del código de creación de tipos en base al “content”
En la definición de los tipos podremos incluir aspectos, tanto predefinidos del sistema como generados dentro del propio modelo personalizado.
Andrés Aznar Royo
Página 13
Alfresco
El modelo de metadatos
4.- La definición del modelo 4.1.- Estructura jerárquica Cuando iniciemos la construcción de nuestro modelo documental deberemos identificar qué tipos de documentos vamos a integrar en nuestro sistema, cuales son variantes de un tipo común (con metadatos que seguramente serán los mismos) etcétera. A partir de ello realizaremos un árbol documental de tipos que marcará nuestra estrategia de implantación. Una primera distinción entre los documentos, que nos puede generar la introducción de dos ramas principales en nuestro árbol documental es el origen de los documentos. Por lo general, de aquellos documentos generados dentro de la compañía nos interesarán una serie de características (qué departamento lo hizo, quien ha sido el autor…) mientras que para los documentos externos será necesario disponer de información de la compañía que nos envía el documento (puede ser una factura, un albarán) tal como nombre de la empresa, su NIF etcétera. Por tanto es muy posible que nuestro árbol documental se inicie generando dos subtipos del modelo base “content”.
<custom:DocExterno>
<custom:DocInterno>
Árbol documental: tipos para documentos internos y externos
Los tipos interno y externo tendrán una serie de metadatos comunes para todos los documentos que clasifiquemos como tales. Estos metadatos los podemos añadir de dos posibles maneras: 1. Agregando los metadatos como propiedades dentro de la definición del propio tipo. 2. Generando aspectos que agrupen estas propiedades y asignando dicho aspecto a la definición del tipo. Ambas son formas válidas aunque (y aquí entramos en la visión personal de cada consultor) parece más elegante la definición por aspectos, agregando luego ese aspecto con la etiqueta <mandatory-aspect> al tipo.
Andrés Aznar Royo
Página 14
Alfresco
El modelo de metadatos
<custom:AspectDocEx>
<custom:TypeDocExt>
<custom:TypeDocInt>
<custom:AspectDocIn>
Definición de la base del modelo documental con tipos y aspectos
Una vez definido el primer nivel del modelo de árbol documental deberemos seguir definiendo la subsiguiente escala jerárquica. Dentro de los documentos externos es posible que la siguiente definición ya sea el tipo de documento (factura, albarán, hoja de pedido…) y no queramos tener una clasificación con más niveles. Seguramente en el caso de los documentos internos sí habrá un despliegue mayor, pues es posible que cada departamento emita unos tipos de documentos y los quieran agrupar bajo una categoría departamental.
<custom:AspectDocEx>
<custom:TypeDocExt>
<custom:TypeDocInt>
<custom:AspectDocIn>
<custom:AspectFactur>
<custom:TypeFactur>
<custom:TypeMktg>
<custom:AspectMktg>
<custom:AspectAlbara>
<custom:TypeAlbara>
<custom:TypeVentas>
<custom:AspectVenta>
<custom:AspectPedid>
<custom:TypePedido>
<custom:TypeCalidad>
<custom:AspectCalida>
<custom:AspectPG>
<custom:TypePG>
Ejemplo ilustrativo de un árbol de documentación
4.2.- Definición a partir de un ejemplo real Se puede plantear un ejemplo ilustrativo que nos ayude a entender cómo debemos plantear la construcción del árbol documental. Nuestro ejemplo se basará en las siguientes premisas: 1. Se requiere la implementación de Alfresco para gestionar los documentos del departamento de calidad de un laboratorio. 2. Existen cinco documentos base que se generan desde ese departamento: Procedimientos Generales, Documentos PRAE, Documentos PNT, Documentos RCAE de química y Documentos RCAE de microbiología.
Andrés Aznar Royo
Página 15
Alfresco
El modelo de metadatos
3. Además se quieren almacenar copias de las facturas recibidas por el departamento y publicaciones que se reciben y se quieren guardar. A partir de las premisas anteriores plantearemos un modelo documental de árbol. Sería suficiente el generar los tipos que nos pide el cliente, pero siempre debemos tener en cuenta la extensión del modelo a otras partes de la compañía y sería un error plantear una solución focalizada a un solo área y limitada en su capacidad de extensión posterior. A partir del modelo base “content” generaremos tres subtipos (subtypes): 1. Tipo para documentos externos. 2. Tipo para publicaciones. 3. Tipo para documentos internos. Las facturas las incluiremos como un subtipo cuyo tipo padre será el de documentos externos. Generaremos un subtipo “documentos de calidad” cuyo padre será el tipo de documentos internos y que, a su vez, tendrá cinco subtipos que serán los que el cliente quiere istrar como documentos de calidad. Finalmente, el tipo de publicaciones lo mantendremos como un tipo especial sin subtipos.
<custom:AspectDocEx>
<custom:TypeDocExt>
<custom:TypeDocInt>
<custom:AspectDocIn>
<custom:TypePubli>
<custom:AspectFactur>
<custom:TypeFactur>
<custom:TypeCalidad>
<custom:AspectCalida>
<custom:AspectPubli>
<custom:AspectPG>
<custom:TypePG>
<custom:AspectPRAE>
<custom:TypePRAE>
<custom:AspectPNT>
<custom:TypePNT>
<custom:AspectRCQ>
<custom:TypeRCQ>
<custom:AspectRCM>
<custom:TypeRCM>
Modelo de contenido propuesto para el ejemplo
Andrés Aznar Royo
Página 16
Alfresco
El modelo de metadatos
Con este modelo se garantiza solucionar la problemática planteada y, a la vez, se permite seguir en el futuro desarrollando el modelo creando nuevos tipos dependientes del documento interno para el resto de departamentos de la compañía.
Andrés Aznar Royo
Página 17
Alfresco
El modelo de metadatos
5.- Implementación del modelo 5.1.- Fichero de declaración del modelo El inicio de la construcción del modelo se realiza mediante la generación de un fichero con el modelo y otro declarando el mismo. Estos ficheros se hallan en el directorio: {directorio servidor de aplicaciones}\shared\classes\alfresco\extension Si realizamos la instalación del bundle de Alfresco en un directorio que podría ser D:\alfresco en este caso deberemos situar nuestros ficheros en: D:\Alfresco\tomcat\shared\classes\alfresco\extension El fichero de declaración de modelo será un fichero XML que debe denominarse según el patrón xxx-model-context.xml. El modelo que generemos deberá tener un nombre y le asignaremos una abreviatura que utilizaremos como prefijo para definir después aspectos, tipos o propiedades. Para la construcción del modelo anterior utilizaremos: • •
Como nombre del modelo de contenidos usaremos “company”. Como prefijo del modelo usaremos “co”
De esta manera generaremos un fichero co-model-context.xml para declarar el modelo.
Fichero co-model-context.xml
En este fichero generaremos dos dependencias: •
•
Indicaremos en la primera parte la dependencia con el fichero co-model.xml que es el fichero donde se definirá el modelo de contenido (con los tipos, los aspectos y las propiedades o metadatos). La segunda hará referencia a un fichero con las etiquetas i18n para configurar los nombres a utilizar en la interfaz cuando se desee implementar la
Andrés Aznar Royo
Página 18
Alfresco
El modelo de metadatos
renderización de las mismas. Este fichero será el company.properties y lo tendremos en otro directorio.
5.2.- Fichero de definición del modelo El fichero de definición del modelo (para nosotros el co-model.xml) es el que almacenará nuestra definición que hemos diseñado anteriormente. Este fichero se almacenará en el mismo directorio que el co-context-model.xml que anteriormente hemos creado.
5.2.1.- La cabecera del fichero La cabecera del fichero nos sirve para definir el nombre del modelo y algunas propiedades (no obligatorias) como la descripción y el autor del modelo. También se importará el diccionario (veremos que usaremos “d” para importar las clases de propiedades) y el content model original (“cm”) que usaremos como base del árbol del modelo. Finalmente definiremos entre las etiquetas
el prefijo y nombre del modelo.
Cabecera del fichero co-model.xml
Una vez creada la cabecera el siguiente paso será la generación de las constraints (valores para propiedades que se definan como campos de selección, por ejemplo, los de un deplegable), los types (tipos) y los aspects (aspectos).
Andrés Aznar Royo
Página 19
Alfresco
El modelo de metadatos
5.2.2.- Las constraints Bajo una primera etiqueta
incluiremos las diferentes que necesitemos para nuestro modelo. Si tomamos por ejemplo los departamentos de la empresa (recordemos que, sin ir más lejos, hablábamos cuando nos referíamos al tipo de documento “publicación” de que una propiedad podría ser el departamento que había adquirido el libro o publicación), definiremos una constraint con el nombre co:ListaDepartamentos que será de tipo lista. La definición de las constraints se halla guardada dentro de Alfresco en el paquete org.alfresco.repo.dictionary.constraint y pueden ser de los siguientes tipos: • • •
•
REGEX (org.alfresco.repo.dictionary.constraint.RegexConstraint): se utiliza para que la propiedad esté condicionada al resultado de una expresión. LENGTH (org.alfresco.repo.dictionary.constraint.StringLengthConstraint): nos permite gestionar una longitud maxima y una minima para un campo de texto. MINMAX (org.alfresco.repo.dictionary.constraint.NumericRangeConstraint): se utiliza para marcar una propiedad numérica con unos valores limítrofes superior e inferior. LIST (org.alfresco.repo.dictionary.constraint.ListOfValuesConstraint): se utiliza para restringir el valor de una propiedad a una lista predeterminada de posibles opciones.
Nuestra constraint para los departamentos de nuestra compañía quedaría de la siguiente manera:
Definición de la constraint de lista de departamentos en co-model.xml
Andrés Aznar Royo
Página 20
Alfresco
El modelo de metadatos
Un ejemplo de los diferentes tipos de constraints (extraído de la wiki de Alfresco) se muestra en el siguiente código:
Ejemplo de definición de constraints
5.2.3.- Los tipos En base al context model original generaremos los subtipos que necesitamos para construir nuestro árbol documental. Dentro de un apartado marcado por la etiqueta
se definirán los tipos. Los primeros se definen con la referencia del context original. Después generaremos los hijos de estos hasta completar la estructura.
Andrés Aznar Royo
Página 21
Alfresco
El modelo de metadatos
Definición del tipo de documento interno
Como se puede observar en el código, generamos un tipo denominado co:TipoCompany (recordemos que el prefijo co es el que definimos al inicio), que titulamos como Documento interno. El origen de este tipo (parent) es el content inicial (todo el modelo de contenido por defecto se define con el prefijo cm, de ahí cm:content declarado en el parent. A este tipo le asignamos una serie de aspectos que llevarán intrínsecos todos los documentos que definamos como documentos internos. Algunos de estos aspectos son de base (prefijo cm) como el que sea auditable, titulable y etiquetable. Adicionalmente le añadimos un aspecto de nuestro propio modelo (prefijo co) que luego definiremos y que llevará las propiedades o metadatos comunes para todos los documentos de este tipo. En nuestro caso el tipo no contiene por si mismo propiedades, ya que hemos decidido que dichas propiedades se integren como un aspecto (co:AspectoCompanyData). No obstante podríamos definir las propiedades directamente en el tipo. Un ejemplo podría ser el siguiente:
Ejemplo de tipo con propiedades insertadas
Una vez tengamos los tipos que llamaríamos de primer nivel, es decir, los tipos que hemos decidido que su parent type sea el content original, seguiremos definiendo los siguientes niveles de nuestro árbol. Para ello utilizaremos el mismo modelo sustituyendo el parent por el que pertoque.
Andrés Aznar Royo
Página 22
Alfresco
El modelo de metadatos
Definición del tipo factura, hijo del tipo documento externo (TipoNoCompany)
El código precedente nos muestra la definición del tipo “Factura externa”. Se puede observar que en este caso el tipo base o parent no es el content original, sino un tipo propio de nuestro modelo, el de documentos externos. Como en el caso previo de la definición que veíamos para los documentos internos, asociamos un aspecto (bajo el paraguas de obligatorio <mandatory-aspects>) de nuestro propio modelo (prefijo co) co:AspectoFacturaExt que será el que aporte al tipo las propiedades requeridas.
5.2.4.- Los aspectos Un aspecto personalizado no será sino un conjunto de propiedades o metadatos agrupados que pueden asignarse directamente a un documento o, mediante la definición del modelo de contenidos documentales, a uno o varios tipos de documentos. En función de nuestra definición del modelo, deberemos generar un aspecto para cada tipo definido. Lo veíamos en el apartado anterior: para el tipo co:TipoFacturaExterna le hemos asignado un aspecto de carácter obligatorio (mandatory-aspect) denominado co:AspectoFacturaExt. Este aspecto no tendrá sino aquellas propiedades que queremos definir para este tipo. Recordemos que como el tipo co:TipoFacturaExterna es hijo del tipo co:TipoNoCompany además también tendrá aquellas propiedades y aspectos heredados de su tipo padre.
Definición del aspecto co:AspectoFacturaExt en el fichero de definición del modelo
Andrés Aznar Royo
Página 23
Alfresco
El modelo de metadatos
Como podemos observar en el ejemplo anterior, el aspecto se compone de un nombre, un título y un conjunto de propiedades. Estas propiedades o metadatos pueden ser de diferentes tipos (fecha, texto, dígitos enteros o en coma flotante…). Se pueden definir que dichas propiedades sean obligatorias, etcétera. No olvidemos, asimismo, que adicionalmente a los aspectos que podamos definir para nuestro modelo de contenido documental, existen algunos como el de etiquetable, versionable, categorizable etcétera que ya están definidos en el model content original que viene por defecto. Estos aspectos los podremos asociar directamente a un documento o tipo sin necesidad de definirlos específicamente.
5.2.5.- Las propiedades o metadatos Las propiedades o metadatos son la unidad básica de la definición del modelo. Nuestra meta cuando iniciamos la construcción del mismo es poder acabar teniendo unos documentos que pertenecen a un tipo y que en base a ese tipo están definidos por unas propiedades que nos permitirán indexarlos, categorizarlos y, posteriormente, realizar buscas selectivas y localizarlos con mayor facilidad. Estas propiedades pueden ser de diferente naturaleza: • • • • • • • • • •
TEXT (d:text) que introduce un campo de tipo cadena de texto (un nombre etc..). CONTENT (d:content) que permite la introducción de un documento binario. INT (d:int) que permite asociar un dígito entero. LONG (d:long) se utiliza para añadir un entero grande. FLOAT (d:float) que se usa para introducir un número decimal (coma flotante). DATE (d:date) que se utiliza para añadir la fecha (año, mes, día). DATETIME (d:datetime) que permite añadir fecha y hora (denominado en inglés timestamp). BOOLEAN (d:boolean) que introduce un valor binario TRUE o FALSE CATEGORY (d:category) que hace referencia a una categoría con una clasificación. PATH (d:path) que permite la introducción de una URL.
Es importante recordar que los valores de estas variables pueden ser restringidos mediante el uso de las denominadas constraints que vimos al inicio de este capítulo. También podemos definir que unas propiedades puedan convertirse en propiedades de tipo índice, de manera que optimicen a posteriori el trabajo de realizar búsquedas por estos mismos metadatos.
Andrés Aznar Royo
Página 24
Alfresco
El modelo de metadatos
Ejemplo de definición de las propiedades en un aspecto
En una propiedad, podemos observar que se define su nombre, un título, su tipo en base a los vistos con anterioridad y si la misma es obligatorio que tenga un valor. Mediante el index enabled podemos asignar a dicha propiedad el carácter de ser un índice (se definirá como tal cuando almacenemos el metadato en la base de datos del modelo).
Ejemplo de propiedad definida como índice
También, como veíamos al principio de este capítulo, podremos restringir mediante las constraints el tipo de valor que asignamos a una propiedad.
Andrés Aznar Royo
Página 25
Alfresco
El modelo de metadatos
Ejemplo de propiedad restringida con una constraint
En el caso del ejemplo anterior, nuestra propiedad co:coUbi tomará un valor marcado por la constraint co:ListaUbicaciones que habremos definido anteriormente.
Constraint definida y utilizada en la propiedad anterior
5.3.- El fichero de publicación en Alfresco Explorer Una vez hayamos definido nuestro modelo con su jerarquía de tipos, sus aspectos, sus propiedades, constraints etcétera debemos conseguir que dicho modelo se refleje dentro de la interfaz de Alfresco, en términos propios de la aplicación, hemos de transferirlo a los ficheros de renderización. Dado que Alfresco presenta dos interfaces diferentes, la clásica del Explorer y la del Share, será necesario aplicar los cambios por duplicado en ficheros diferentes. El fichero de renderización para Alfresco Explorer es el web-client-config-custom.xml y se halla ubicado en el mismo directorio donde teníamos los ficheros que hemos tratado anteriormente: {directorio servidor de aplicaciones}\shared\classes\alfresco\extension El fichero web-client.config-custom.xml se inicia con la etiqueta
y dentro tendremos diferentes config conditions para definir la visualización de nuestros tipos en las diferentes partes del Explorer.
Andrés Aznar Royo
Página 26
Alfresco
El modelo de metadatos
Vista inicial del fichero de renderización en Explorer
Las diferentes partes del Explorer donde hemos de añadir nuestros tipos personalizados son: • • • •
El asistente para la asignación de tipos de contenido (wizard) La interfaz de la búsqueda avanzada El motor de ejecución de acciones (action wizard) La pantalla de visualización de propiedades de los propios documentos
Para visualizar los tipos en nuestro asistente de asignación de tipos de contenidos deberemos generar una condición de configuración para el Content Wizards y asignar los nombres de nuestros tipos personalizados.
Sección para dar visibilidad a nuestros tipos personalizados en el wizard de tipos de documentos
Lo que permite esta configuración es que en la carga de un nuevo documento podamos incluir nuestros tipos personalizados durante el asistente de definición del mismo.
Andrés Aznar Royo
Página 27
Alfresco
El modelo de metadatos
Vista del asistente de inserción de un nuevo documento con nuestros tipos personalizados.
Para generar la vista de la búsqueda avanzada deberemos definir los tipos que participarán y deberemos, asimismo, indicar cuáles serán los campos de estos tipos que queremos utilizar (propiedades, que definiremos indicando el aspecto al que pertenecen). Como veíamos cuando hablábamos anteriormente de propiedades, es recomendable que los campos o metadatos que utilicemos en la búsqueda avanzada hayan sido definidos como índices al crear esa propiedad en el tipo o aspecto pertinente.
Definición de tipos y propiedades a mostrar en la búsqueda avanzada
Esta configuración se reflejará en nuestra interface de Alfresco mostrando tipos y propiedades en la búsqueda avanzada.
Andrés Aznar Royo
Página 28
Alfresco
El modelo de metadatos
Muestra de la búsqueda avanzada con los tipos predefinidos
Las propiedades predefinidas se mostrarán bajo el apartado de opciones adicionales.
Vista de las opciones adicionales con las propiedades personalizadas
Andrés Aznar Royo
Página 29
Alfresco
El modelo de metadatos
El siguiente punto donde hemos de añadir nuestro modelo es en los asistentes (wizards) de ejecución de acciones. Este asistente se utiliza tanto cuando usamos “Ejecutar acción” como cuando creamos reglas de contenido sobre un contenedor o carpeta de Alfresco. Dado que tenemos la posibilidad de generar una acción para asignar un tipo pero también para asignar un aspecto, deberemos incluir ambos términos en nuestro fichero de renderizado a fin de que podamos usar ambos. Esto es lo que haremos con el código siguiente.
Sección del fichero de renderizado para la definición de los asistentes de acciones y reglas
Recordemos que cuando hemos generado nuestro modelo hemos usados los aspectos como conjuntos de datos obligatorios para determinados tipos. Sería lógico pensar que, como nos guiaremos por un modelo de tipos de documentos, no sería necesario asignar aspectos de forma individual ya que éstos serán asignados en función del tipo definido. Si lo hiciéramos de dicha manera, eliminando los aspectos de esta sección, nos aseguraríamos que el no puede asignar individualmente aspectos a un determinado documento. No obstante, como ejemplo ilustrativo, quizás es mejor mostrar cómo podemos añadir ambas clases de elementos a nuestra interface.
Andrés Aznar Royo
Página 30
Alfresco
El modelo de metadatos
Ejemplo de la secuencia de aplicación de regla de contenido a una carpeta, con los tipos personalizados
Finalmente debemos aplicar nuestros tipos y aspectos a los formularios de visualización y edición de las propiedades cuando entramos en las pantallas de visión de los documentos. Para ello generaremos nuestra “property-sheet” con los metadatos que vayamos a mostrar en la pantalla.
Definición de la visualización del aspecto co:AspectoFichaBibliografica
Mediante el código anterior conseguiremos que este aspecto (asociado al tipo de publicación externa) nos permita visualizar y editar las propiedades de aquellos documentos que definamos con este tipo.
Andrés Aznar Royo
Página 31
Alfresco
El modelo de metadatos
Vista de la pantalla de propiedades de un documento con los metadatos personalizados del aspecto ficha bibliográfica
Vista de la pantalla de edición y modificación de propiedades de un documento
Andrés Aznar Royo
Página 32
Alfresco
El modelo de metadatos
5.4.- El fichero de propiedades En el fichero de declaración del modelo en Explorer veíamos que se aludían a dos definiciones: la definición del modelo de contenido (ya comentada) y el fichero de etiquetas i18n donde traduciremos los nombres de los contenidos y las variables a la cadena de texto pertinente. Este fichero lo llamaremos company.properties y lo generaremos en el directorio: {directorio servidor de aplicaciones}\shared\classes\alfresco\messages Las secciones de este fichero serán: • • •
Sección de etiquetas para las propiedades de los aspectos. Sección de etiquetas para los aspectos. Sección de etiquetas para los tipos.
En la sección de propiedades definiremos las etiquetas para las mismas que veremos cuando se nos presenten en pantalla. La sintaxis será: prefijo_nombredelmodelo.property.prefijo_nombredelapropiedad.tittle=etiqueta En nuestro caso, por ejemplo: co_company.property.co_coAutor.title=Autor del documento Recordemos que nuestro modelo se llama company y tiene el prefijo co (co:company).
Ejemplo de las secciones de propiedades para documentos internos y externos en el fichero company.properties
Una vez definidas las etiquetas para las propiedades realizaremos el proceso para tipos y aspectos. En este caso tendremos dos bloques para cada uno de estos elementos. Los bloques de los aspectos tendrán una sintaxis del tipo:
Andrés Aznar Royo
Página 33
Alfresco
El modelo de metadatos
Bloque 1: prefijo_nombredelmodelo.aspect.prefijo_nombredelaspecto= etiqueta Bloque 2: aspect.prefijo_nombredelaspecto= etiqueta Para el caso de los tipos será similar: Bloque 1: prefijo_nombredelmodelo.type.prefijo_nombredeltipo= etiqueta Bloque 1: type.prefijo_nombredeltipo= etiqueta
Definición de aspectos y tipos en el fichero de propiedades i18n
5.5.- El fichero de declaración en Alfresco Share El hecho de realizar la publicación de las propiedades en la interface de Explorer no implica que esa misma visualización se extienda a Share. Share tiene sus propios ficheros de renderizado y tipos, aspectos, propiedades, etcétera tendrán que darse de
Andrés Aznar Royo
Página 34
Alfresco
El modelo de metadatos
alta en estos ficheros para poder mostrarse en cuando utilicemos esa parte de Alfresco. El primer fichero es el que declarará nuestras propiedades para ser renderizadas referenciando a las etiquetas del fichero company.properties que hemos visto en el apartado anterior. Este fichero se llama custom-slingshot-application-context.xml y se hallará ubicado en el directorio: {directorio servidor de aplicaciones}\shared\classes\alfresco\web-extension
Fichero custom-slingshot-application-context.xml
5.6.- El fichero de publicación en Alfresco Share El fichero que gestiona la interface de Share es el share-config-custom.xml. Este fichero se halla en la misma ubicación que el que hemos tratado con anterioridad: {directorio servidor de aplicaciones}\shared\classes\alfresco\web-extension En este fichero gestionaremos: • • • •
La accesibilidad a los aspectos personalizados cuando se utiliza la opción de añadir aspecto a un documento en sus propiedades. La jerarquía de asignación de tipos. La inserción en la búsqueda avanzada del Share Todos los formularios vinculados a tipos, aspectos y propiedades de un documento, y que se gestionan en conjunto para cada tipo.
Fichero de configuración del share: cabecera inicial
Andrés Aznar Royo
Página 35
Alfresco
El modelo de metadatos
La sección de document library del fichero nos permitirá insertar todos los aspectos que deseemos en la opción de añadir aspectos del share.
Inserción de los aspectos personalizados a la gestión de aspectos del share
El resultado se mostrará en el cuadro de diálogo de adición de aspectos para los documentos.
Cuadro de diálogo de inserción de aspectos para los documentos en Share
Otra sección dentro del mismo fichero nos permitirá gestionar como jerarquizamos la asignación de tipos a los documentos. Recordemos que nuestro modelo de tipos tiene una jerarquía. Se parte de la base del modelo de contenido estándar (content) y se
Andrés Aznar Royo
Página 36
Alfresco
El modelo de metadatos
generan tipos (documento interno, documento externo…) que a su vez tienen subtipos etcétera. En definitiva, tenemos una estructura de árbol. Tenemos que conocer, asimismo, que cuando a un documento le asignamos que es de un determinado tipo esta asignación es irreversible. No podremos devolverlo al estado anterior. Sí que podremos, por otra parte, volver a asignarle un tipo de los niveles siguientes al tipo anterior (dentro del árbol) pero nunca devolverlo a un tipo previo padre, al content model original o a un subtipo de otra naturaleza. La permisividad de saltar des de un tipo a un nivel o más niveles inferiores, dentro de share, se puede definir en este fichero.
Vista de la gestión de las jerarquías en la asignación de tipo de contenido
En el ejemplo anterior vemos los tipos y los subtipos que nos permitirá asignar. Un documento de tipo content lo podremos convertir en sus hijos (TipoCompany, TipoNoCompany o TipoPublicacion), también en los hijos de sus hijos (TipoFacturaExterna, que es hijo de TipoNoCompany en nuestro modelo, TipoQualProcDoc que es hijo de TipoCompany) e incluso en los hijos de estos últimos (TipoQualPR, que es hijo de TipoQualProcDoc, que lo es de TipoCompany). A su vez, el TipoCompany vemos que tiene como subtypes (es decir, como documentos que podremos asignar partiendo del tipo inicial TipoCompany) tanto su hijo TipoQualPorcDoc como los derivados de éste (TipoQualPR, TipoQualPRAE…). Vemos también que el TipoQualProc se puede derivar en sus cinco hijos y que el TipoNoCompany lo podemos convertir en TipoFacturaExterna (único hijo definido inicialmente en nuestro modelo de ejemplo). Recordemos que, una vez asignado un tipo sólo podremos seguir descendiendo en el árbol a un tipo hijo o inferior pero nunca volver hacia arriba. La definición de este fichero es la forma en que se nos permite realizar esta asignación por la interface del Share. Si, por ejemplo, no quisiéramos que se pudieran saltar dos niveles de asignación de golpe, el fichero debería sólo tener como subtypes para cada type aquellos tipos que en el modelo original definimos como hijos. De esta manera no podríamos saltar varios niveles aunque haciéndolo nivel a nivel podríamos alcanzar el mismo resultado.
Andrés Aznar Royo
Página 37
Alfresco
El modelo de metadatos
Vista de la asignación de un documento a un tipo. Partiendo del content y según el ejemplo definido en el fichero anterior.
La definición de los campos a utilizar en la búsqueda avanzada se gestionan a partir del código que define que formularios vamos a utilizar y de la asignación de los metadatos al formulario concreto. Así la adición al Advanced Search de la instrucción:
nos va a indicar que tendremos propiedades del tipo mencionado en nuestra búsqueda avanzada. Posteriormente definiremos el formulario de búsqueda para este tipo
El modelo de metadatos
Alfresco: El modelo de gestión documental y la utilización de metadatos Andrés Aznar [email protected]
Andrés Aznar Royo
Página 1
Alfresco
El modelo de metadatos
INDICE 1.- Introducción a la gestión documental de Alfresco ......................3 1.1.- Alfresco gestor documental .................................................3 1.2.- Sobre el autor ........................................................................3 2.- Los documentos en Alfresco ......................................................4 2.1.- Un contenedor de documentos y algo más ........................4 2.2.- Búsquedas por metadatos y por contenido........................4 3.- Metadatos ...................................................................................6 3.1.- Etiquetas, Categorías, Aspectos y Tipos ............................6 4.- La definición del modelo ...........................................................14 4.1.- Estructura jerárquica ..........................................................14 4.2.- Definición a partir de un ejemplo real ...............................15 5.- Implementación del modelo......................................................18 5.1.- Fichero de declaración del modelo ...................................18 5.2.- Fichero de definición del modelo ......................................19 5.3.- El fichero de publicación en Alfresco Explorer ................26 5.4.- El fichero de propiedades ...................................................33 5.5.- El fichero de declaración en Alfresco Share ....................34 5.6.- El fichero de publicación en Alfresco Share.....................35 5.7.- Los ficheros del menú de carga de Share.........................42 6.- Conclusiones ............................................................................46
Andrés Aznar Royo
Página 2
Alfresco
El modelo de metadatos
1.- Introducción a la gestión documental de Alfresco 1.1.- Alfresco gestor documental Alfresco es un gestor documental open source nacido a raíz de una escisión de personas desde EMC (empresa propietaria del software de gestión documental Documentum) y la participación del actual CEO y presidente John Powell que venía de Business Objects (compañía actualmente adquirida por SAP). Alfresco presenta una arquitectura web, basada en una base de datos (acepta tanto open source como Mysql o PostgreSQL como Oracle y otras de carácter comercial), un servidor de aplicaciones Java (también en este caso puede ser open source como Tomcat o JBoss o comercial como Websphere o Weblogic) y la propia aplicación Alfresco que se despliega en el servidor y que tiene formato modular (Explorer, Share, Web Content Manager…).
1.2.- Sobre el autor Andrés Aznar soy yo. Mi formación es de ingeniería industrial aunque llevo más de quince años dedicado a los proyectos IT en diferentes empresas y sectores. Mis inicios en la gestión documental provienen del uso de Autodesk WorkCenter (hoy día un producto obsoleto y no existente) que era un incipiente embrión de la parte de la gestión documental relacionada con el ciclo de vida de producto (PLM o Product Lifecycle Management). Más tarde he sido implantador de sistemas de gestión documental puros como FileNet o PoseiDoc Gestor documental, sistemas PLM (Teamcenter), sistemas BPM (Business Process Management) como Fujitsu Teamware o Staffware y más recientemente los denominados ECM (Enterprise Content Management) como puede ser Alfresco (sistema más orientado a la documentación) o Liferay (orientado a portales y gestión de contenidos). Cuando un profesional se queda sin trabajo es el momento de recapitular y dar un pequeño vistazo a todo eso que hemos aprendido y, cuyas pruebas en forma de proyectos, desarrollos, implantaciones, se han quedado en las empresas o clientes en los que hemos trabajado. Con motivo de dar un orden a todo ese conocimiento y acercarlo a la comunidad, surge el proyecto de realizar una serie de documentos (llamémoslos manuales o pequeños libros de producto) a fin de poner negro sobre blanco sobre todo ese conocimiento almacenado en la materia gris. Este es un primer manual que espero pueda ser de utilidad a la comunidad. Si la situación de desempleo se alarga, quizás pueda obsequiarles con alguna cosa adicional, aunque sin mala intención les digo que ojalá no sea así.
Andrés Aznar Royo
Página 3
Alfresco
El modelo de metadatos
2.- Los documentos en Alfresco 2.1.- Un contenedor de documentos y algo más Cuando introducimos un documento en Alfresco, ya sea directamente a través de alguno de sus portales (Explorer o Share) o mediante el por caminos integrados en el entorno de trabajo (WebDav, Sharepoint Protocol, Plug-ins de MS Office) éste quedará almacenado en aquel contenedor donde le asignemos (una carpeta, la librería documental de un portal del Share…).
Alfresco Explorer: vista de un documento dentro del directorio de
Pero es obvio que lo que buscamos cuando nos planteamos el uso de un gestor documental no es tan sólo replicar la funcionalidad que nos puede dar la estructura de directorios de un sistema operativo, sino que se busca disponer de unas herramientas de indexación que nos permita luego realizar, entre otras cosas, unas búsquedas selectivas de esos documentos almacenados independientemente de donde se hallen o el formato en que estén generados.
2.2.- Búsquedas por metadatos y por contenido Los documentos introducidos en Alfresco deberán, con posterioridad, ser recuperados por los s. Y para ello la misión del integrador que realiza la implementación del proyecto de implantación será el ofrecer las herramientas más intuitivas y eficaces para que el sea capaz de buscar y acceder a esos documentos de manera ágil.
Andrés Aznar Royo
Página 4
Alfresco
El modelo de metadatos
La gestión documental clásica y los primeros sistemas construidos para este menester basaban la indexación de los documentos en los denominados metadatos (o también llamadas propiedades). Los metadatos son campos que se añaden a un archivo documental y que nos permitirá con posterioridad utilizar sus posibles valores para realizar búsquedas. En Alfresco veremos que nos podemos encontrar con cuatro tipos de organización para los metadatos a añadir: las etiquetas, las categorías, los aspectos (que en realidad son conjuntos de metadatos) y los tipos. Con posterioridad a esta visión más clásica de la indexación documental han surgido herramientas que permiten añadir la búsqueda por contenidos, es decir, se trata de funciones que permiten penetrar en el interior del documento (un html, un archivo ofimático o un PDF) y realizar la búsqueda de un contenido concreto (una cadena de caracteres) dentro de dicho documento. En el caso de Alfresco, esta posibilidad está desarrollada a través de SOLR. SOLR es un motor de búsqueda de código abierto basado en la biblioteca Java del proyecto Lucene, con APIs en XML/HTTP y JSON, resaltado de resultados, búsqueda facetada, caché, y una interfaz para su istración. Al tratarse de una herramienta bajo licencia Apache Software Foundation, Alfresco sólo la tiene disponible si el servidor de aplicaciones sobre el que desplegamos el programa es Apache Tomcat. La misión de este manual es explicar en detalla la construcción del modelo de metadatos, así que la gestión y despliegue del SOLR la dejaremos para otro volumen.
Andrés Aznar Royo
Página 5
Alfresco
El modelo de metadatos
3.- Metadatos 3.1.- Etiquetas, Categorías, Aspectos y Tipos Como hemos mencionado anteriormente disponemos de cuatro herramientas para gestionar la indexación de un documento por sus metadatos. Estas herramientas son las etiquetas, las categorías, los aspectos y los tipos.
3.1.1.- Etiquetas Una etiqueta es un nombre clave, una palabra, o cualquier cadena alfanumérica que podemos asociar al documento. Las etiquetas no son exclusivas de los documentos, podemos etiquetar una entrada en un blog del Share, una entrada en el wiki etcétera. Asimismo no existen unos valores predeterminados sino que el puede añadir esas palabras clave que crea oportunas para identificar el documento al que se está refiriendo.
Alfresco Share: Visión de las propiedades de un documento y sus etiquetas
Una vez generadas las etiquetas podremos utilizarlas para realizar búsquedas. En el caso de Share, la propia interfaz del portal ya incluye la enumeración de las etiquetas en el menú de la parte izquierda de la pantalla. Así, marcando la etiqueta para la que queremos encontrar ítems, nos aparecerán todos aquellos elementos (no sólo documentos, sino también entradas wiki, blog…) que contengan la mencionada etiqueta. Para el caso de Explorer no existe en la interfaz base una metodología para la búsqueda por etiquetas.
Andrés Aznar Royo
Página 6
Alfresco
El modelo de metadatos
Interfaz de Alfresco Share y listado de objetos por etiquetas
Para que un documento pueda tener etiquetas dicho documento debe tener activado el aspecto “Etiquetable” (en inglés “Taggable”). En caso contrario no aparecerá la opción de poder asignarle estos campos al documento.
3.1.2.- Categorías Las categorías son otro tipo de metadato existente en Alfresco. Al contrario de lo que pasa con las etiquetas, las categorías sí son campos preconfigurados, y al categorizar un documento le asignamos un valor o valores (un documento puede tener varías categorías) predeterminados.
Alfresco Explorer: Gestión de las categorías desde la consola de istración
Andrés Aznar Royo
Página 7
Alfresco
El modelo de metadatos
Además las categorías pueden definirse en un árbol de jerarquías, pudiendo así una categoría tener subcategorías. De esta manera también la istración de las mismas se realiza de una forma más sencilla y permite su con mayor facilidad y rapidez.
Alfresco Share: Propiedad “Departamento”
Alfreso share: Subpropiedades de la propiedad “Departamento”
Como observábamos que ocurre en el caso de las etiquetas, las categorías, inicialmente, no están accesibles para los documentos a no ser que indiquemos específicamente que sea así. En las propiedades de los documentos (dentro del Explorer) existe un apartado para la categorización donde se permite activar ésta y poder gestionar las categorías a las que haremos pertenecer a ese documento. Desde Share la categorización (aunque el término utilizado en Share es clasificación) se debe hacer añadiendo el aspecto “Clasificable” al documento, en la gestión de aspectos.
Andrés Aznar Royo
Página 8
Alfresco
El modelo de metadatos
Alfresco Explorer: Gestión de la categorización de un documento
Alfresco Share: Gestión de los aspectos y adición de la posibilidad de uso de las categorías
Las categorías también presentan una ventaja importante con respecto a las etiquetas: el buscador avanzado de Explorer dispone, por defecto, de la posibilidad de realizar búsquedas por categoría.
Andrés Aznar Royo
Página 9
Alfresco
El modelo de metadatos
Visión de la búsqueda avanzada en Explorer. En la parte inferior izquierda existe la búsqueda por categorías
3.1.3.- Aspectos Los aspectos aportan características a un documento. Por defecto, en Alfresco ya existen una serie de aspectos predefinidos. Dos de ellos ya los vimos con anterioridad: el aspecto de etiquetable y el de clasificable. Además de estos dos existen algunos más, como puede ser el de ser un documento versionable, editable en línea… En el apartado anterior veíamos una pantalla de Share donde se realizaba la asignación de aspectos a un documento. Pero además de los aspecto predefinidos del sistema, cuando implantemos Alfresco una de las tareas principales será definir el árbol documental, donde generaremos nuevos aspectos definidos por el proyecto que nos ocupe y destinado a determinados tipos de documentos. Estos aspectos definidos por el serán conjuntos de propiedades o metadatos que podremos asignar a un documento o tipo de documentos. En apartados posteriores se explicará la generación de estos aspectos y del modelo de árbol documental en su globalidad. Veremos entonces que los pasos a seguir para la generación y uso de un aspecto son: 1. Creación del aspecto en el fichero xml de modelo de contenido. 2. Adición del aspecto al fichero de renderización de explorer para los diferentes entornos donde se debe acceder (acciones, creación de un nuevo documento, reglas, búsqueda avanzada). 3. Adición del aspecto al fichero de renderización del share (con igual extensión a todos los s).
Andrés Aznar Royo
Página 10
Alfresco
El modelo de metadatos
Vista del fichero de contenido personalizado y del código de creación de un aspecto
Las propiedades de los aspectos definidos por el se deben renderizar en la interfaz tanto de Explorer como de Share.
Pantalla de búsquedas avanzadas de Explorer. Las propiedades de los aspectos se programan para ser visualizados en el apartado de Opciones adicionales.
Andrés Aznar Royo
Página 11
Alfresco
El modelo de metadatos
Pantalla de búsquedas avanzadas de Share con las propiedades de los aspectos personalizados.
3.1.4.- Los tipos Los tipos de documentos permiten generar una infraestructura jerarquizada para la documentación que se almacena en Alfresco. De base el sistema presenta un tipo denominado “content” que será la base para la construcción de otros tipos, siempre como subtipos del content. Estos subtipos, al igual que las categorías, son jerárquicos y pueden extenderse varios rivales. Cuando asignemos un tipo a un documento recogerá todas las características del mismo así como de los tipos ancestros al que estamos usando. Al igual que ocurre con los aspectos, tendremos tres pasos para generar y utilizar un tipo: 1. Creación del tipo en el fichero xml de modelo de contenido. 2. Adición del tipo al fichero de renderización de explorer para los diferentes entornos donde se debe acceder (acciones, creación de un nuevo documento, reglas, búsqueda avanzada).
Andrés Aznar Royo
Página 12
Alfresco
El modelo de metadatos
3. Adición del tipo al fichero de renderización del share (con igual extensión a todos los s).
Vista del fichero de contenido personalizado y del código de creación de tipos en base al “content”
En la definición de los tipos podremos incluir aspectos, tanto predefinidos del sistema como generados dentro del propio modelo personalizado.
Andrés Aznar Royo
Página 13
Alfresco
El modelo de metadatos
4.- La definición del modelo 4.1.- Estructura jerárquica Cuando iniciemos la construcción de nuestro modelo documental deberemos identificar qué tipos de documentos vamos a integrar en nuestro sistema, cuales son variantes de un tipo común (con metadatos que seguramente serán los mismos) etcétera. A partir de ello realizaremos un árbol documental de tipos que marcará nuestra estrategia de implantación. Una primera distinción entre los documentos, que nos puede generar la introducción de dos ramas principales en nuestro árbol documental es el origen de los documentos. Por lo general, de aquellos documentos generados dentro de la compañía nos interesarán una serie de características (qué departamento lo hizo, quien ha sido el autor…) mientras que para los documentos externos será necesario disponer de información de la compañía que nos envía el documento (puede ser una factura, un albarán) tal como nombre de la empresa, su NIF etcétera. Por tanto es muy posible que nuestro árbol documental se inicie generando dos subtipos del modelo base “content”.
<custom:DocExterno>
<custom:DocInterno>
Árbol documental: tipos para documentos internos y externos
Los tipos interno y externo tendrán una serie de metadatos comunes para todos los documentos que clasifiquemos como tales. Estos metadatos los podemos añadir de dos posibles maneras: 1. Agregando los metadatos como propiedades dentro de la definición del propio tipo. 2. Generando aspectos que agrupen estas propiedades y asignando dicho aspecto a la definición del tipo. Ambas son formas válidas aunque (y aquí entramos en la visión personal de cada consultor) parece más elegante la definición por aspectos, agregando luego ese aspecto con la etiqueta <mandatory-aspect> al tipo.
Andrés Aznar Royo
Página 14
Alfresco
El modelo de metadatos
<custom:AspectDocEx>
<custom:TypeDocExt>
<custom:TypeDocInt>
<custom:AspectDocIn>
Definición de la base del modelo documental con tipos y aspectos
Una vez definido el primer nivel del modelo de árbol documental deberemos seguir definiendo la subsiguiente escala jerárquica. Dentro de los documentos externos es posible que la siguiente definición ya sea el tipo de documento (factura, albarán, hoja de pedido…) y no queramos tener una clasificación con más niveles. Seguramente en el caso de los documentos internos sí habrá un despliegue mayor, pues es posible que cada departamento emita unos tipos de documentos y los quieran agrupar bajo una categoría departamental.
<custom:AspectDocEx>
<custom:TypeDocExt>
<custom:TypeDocInt>
<custom:AspectDocIn>
<custom:AspectFactur>
<custom:TypeFactur>
<custom:TypeMktg>
<custom:AspectMktg>
<custom:AspectAlbara>
<custom:TypeAlbara>
<custom:TypeVentas>
<custom:AspectVenta>
<custom:AspectPedid>
<custom:TypePedido>
<custom:TypeCalidad>
<custom:AspectCalida>
<custom:AspectPG>
<custom:TypePG>
Ejemplo ilustrativo de un árbol de documentación
4.2.- Definición a partir de un ejemplo real Se puede plantear un ejemplo ilustrativo que nos ayude a entender cómo debemos plantear la construcción del árbol documental. Nuestro ejemplo se basará en las siguientes premisas: 1. Se requiere la implementación de Alfresco para gestionar los documentos del departamento de calidad de un laboratorio. 2. Existen cinco documentos base que se generan desde ese departamento: Procedimientos Generales, Documentos PRAE, Documentos PNT, Documentos RCAE de química y Documentos RCAE de microbiología.
Andrés Aznar Royo
Página 15
Alfresco
El modelo de metadatos
3. Además se quieren almacenar copias de las facturas recibidas por el departamento y publicaciones que se reciben y se quieren guardar. A partir de las premisas anteriores plantearemos un modelo documental de árbol. Sería suficiente el generar los tipos que nos pide el cliente, pero siempre debemos tener en cuenta la extensión del modelo a otras partes de la compañía y sería un error plantear una solución focalizada a un solo área y limitada en su capacidad de extensión posterior. A partir del modelo base “content” generaremos tres subtipos (subtypes): 1. Tipo para documentos externos. 2. Tipo para publicaciones. 3. Tipo para documentos internos. Las facturas las incluiremos como un subtipo cuyo tipo padre será el de documentos externos. Generaremos un subtipo “documentos de calidad” cuyo padre será el tipo de documentos internos y que, a su vez, tendrá cinco subtipos que serán los que el cliente quiere istrar como documentos de calidad. Finalmente, el tipo de publicaciones lo mantendremos como un tipo especial sin subtipos.
<custom:AspectDocEx>
<custom:TypeDocExt>
<custom:TypeDocInt>
<custom:AspectDocIn>
<custom:TypePubli>
<custom:AspectFactur>
<custom:TypeFactur>
<custom:TypeCalidad>
<custom:AspectCalida>
<custom:AspectPubli>
<custom:AspectPG>
<custom:TypePG>
<custom:AspectPRAE>
<custom:TypePRAE>
<custom:AspectPNT>
<custom:TypePNT>
<custom:AspectRCQ>
<custom:TypeRCQ>
<custom:AspectRCM>
<custom:TypeRCM>
Modelo de contenido propuesto para el ejemplo
Andrés Aznar Royo
Página 16
Alfresco
El modelo de metadatos
Con este modelo se garantiza solucionar la problemática planteada y, a la vez, se permite seguir en el futuro desarrollando el modelo creando nuevos tipos dependientes del documento interno para el resto de departamentos de la compañía.
Andrés Aznar Royo
Página 17
Alfresco
El modelo de metadatos
5.- Implementación del modelo 5.1.- Fichero de declaración del modelo El inicio de la construcción del modelo se realiza mediante la generación de un fichero con el modelo y otro declarando el mismo. Estos ficheros se hallan en el directorio: {directorio servidor de aplicaciones}\shared\classes\alfresco\extension Si realizamos la instalación del bundle de Alfresco en un directorio que podría ser D:\alfresco en este caso deberemos situar nuestros ficheros en: D:\Alfresco\tomcat\shared\classes\alfresco\extension El fichero de declaración de modelo será un fichero XML que debe denominarse según el patrón xxx-model-context.xml. El modelo que generemos deberá tener un nombre y le asignaremos una abreviatura que utilizaremos como prefijo para definir después aspectos, tipos o propiedades. Para la construcción del modelo anterior utilizaremos: • •
Como nombre del modelo de contenidos usaremos “company”. Como prefijo del modelo usaremos “co”
De esta manera generaremos un fichero co-model-context.xml para declarar el modelo.
Fichero co-model-context.xml
En este fichero generaremos dos dependencias: •
•
Indicaremos en la primera parte la dependencia con el fichero co-model.xml que es el fichero donde se definirá el modelo de contenido (con los tipos, los aspectos y las propiedades o metadatos). La segunda hará referencia a un fichero con las etiquetas i18n para configurar los nombres a utilizar en la interfaz cuando se desee implementar la
Andrés Aznar Royo
Página 18
Alfresco
El modelo de metadatos
renderización de las mismas. Este fichero será el company.properties y lo tendremos en otro directorio.
5.2.- Fichero de definición del modelo El fichero de definición del modelo (para nosotros el co-model.xml) es el que almacenará nuestra definición que hemos diseñado anteriormente. Este fichero se almacenará en el mismo directorio que el co-context-model.xml que anteriormente hemos creado.
5.2.1.- La cabecera del fichero La cabecera del fichero nos sirve para definir el nombre del modelo y algunas propiedades (no obligatorias) como la descripción y el autor del modelo. También se importará el diccionario (veremos que usaremos “d” para importar las clases de propiedades) y el content model original (“cm”) que usaremos como base del árbol del modelo. Finalmente definiremos entre las etiquetas
Cabecera del fichero co-model.xml
Una vez creada la cabecera el siguiente paso será la generación de las constraints (valores para propiedades que se definan como campos de selección, por ejemplo, los de un deplegable), los types (tipos) y los aspects (aspectos).
Andrés Aznar Royo
Página 19
Alfresco
El modelo de metadatos
5.2.2.- Las constraints Bajo una primera etiqueta
•
REGEX (org.alfresco.repo.dictionary.constraint.RegexConstraint): se utiliza para que la propiedad esté condicionada al resultado de una expresión. LENGTH (org.alfresco.repo.dictionary.constraint.StringLengthConstraint): nos permite gestionar una longitud maxima y una minima para un campo de texto. MINMAX (org.alfresco.repo.dictionary.constraint.NumericRangeConstraint): se utiliza para marcar una propiedad numérica con unos valores limítrofes superior e inferior. LIST (org.alfresco.repo.dictionary.constraint.ListOfValuesConstraint): se utiliza para restringir el valor de una propiedad a una lista predeterminada de posibles opciones.
Nuestra constraint para los departamentos de nuestra compañía quedaría de la siguiente manera:
Definición de la constraint de lista de departamentos en co-model.xml
Andrés Aznar Royo
Página 20
Alfresco
El modelo de metadatos
Un ejemplo de los diferentes tipos de constraints (extraído de la wiki de Alfresco) se muestra en el siguiente código:
Ejemplo de definición de constraints
5.2.3.- Los tipos En base al context model original generaremos los subtipos que necesitamos para construir nuestro árbol documental. Dentro de un apartado marcado por la etiqueta
Andrés Aznar Royo
Página 21
Alfresco
El modelo de metadatos
Definición del tipo de documento interno
Como se puede observar en el código, generamos un tipo denominado co:TipoCompany (recordemos que el prefijo co es el que definimos al inicio), que titulamos como Documento interno. El origen de este tipo (parent) es el content inicial (todo el modelo de contenido por defecto se define con el prefijo cm, de ahí cm:content declarado en el parent. A este tipo le asignamos una serie de aspectos que llevarán intrínsecos todos los documentos que definamos como documentos internos. Algunos de estos aspectos son de base (prefijo cm) como el que sea auditable, titulable y etiquetable. Adicionalmente le añadimos un aspecto de nuestro propio modelo (prefijo co) que luego definiremos y que llevará las propiedades o metadatos comunes para todos los documentos de este tipo. En nuestro caso el tipo no contiene por si mismo propiedades, ya que hemos decidido que dichas propiedades se integren como un aspecto (co:AspectoCompanyData). No obstante podríamos definir las propiedades directamente en el tipo. Un ejemplo podría ser el siguiente:
Ejemplo de tipo con propiedades insertadas
Una vez tengamos los tipos que llamaríamos de primer nivel, es decir, los tipos que hemos decidido que su parent type sea el content original, seguiremos definiendo los siguientes niveles de nuestro árbol. Para ello utilizaremos el mismo modelo sustituyendo el parent por el que pertoque.
Andrés Aznar Royo
Página 22
Alfresco
El modelo de metadatos
Definición del tipo factura, hijo del tipo documento externo (TipoNoCompany)
El código precedente nos muestra la definición del tipo “Factura externa”. Se puede observar que en este caso el tipo base o parent no es el content original, sino un tipo propio de nuestro modelo, el de documentos externos. Como en el caso previo de la definición que veíamos para los documentos internos, asociamos un aspecto (bajo el paraguas de obligatorio <mandatory-aspects>) de nuestro propio modelo (prefijo co) co:AspectoFacturaExt que será el que aporte al tipo las propiedades requeridas.
5.2.4.- Los aspectos Un aspecto personalizado no será sino un conjunto de propiedades o metadatos agrupados que pueden asignarse directamente a un documento o, mediante la definición del modelo de contenidos documentales, a uno o varios tipos de documentos. En función de nuestra definición del modelo, deberemos generar un aspecto para cada tipo definido. Lo veíamos en el apartado anterior: para el tipo co:TipoFacturaExterna le hemos asignado un aspecto de carácter obligatorio (mandatory-aspect) denominado co:AspectoFacturaExt. Este aspecto no tendrá sino aquellas propiedades que queremos definir para este tipo. Recordemos que como el tipo co:TipoFacturaExterna es hijo del tipo co:TipoNoCompany además también tendrá aquellas propiedades y aspectos heredados de su tipo padre.
Definición del aspecto co:AspectoFacturaExt en el fichero de definición del modelo
Andrés Aznar Royo
Página 23
Alfresco
El modelo de metadatos
Como podemos observar en el ejemplo anterior, el aspecto se compone de un nombre, un título y un conjunto de propiedades. Estas propiedades o metadatos pueden ser de diferentes tipos (fecha, texto, dígitos enteros o en coma flotante…). Se pueden definir que dichas propiedades sean obligatorias, etcétera. No olvidemos, asimismo, que adicionalmente a los aspectos que podamos definir para nuestro modelo de contenido documental, existen algunos como el de etiquetable, versionable, categorizable etcétera que ya están definidos en el model content original que viene por defecto. Estos aspectos los podremos asociar directamente a un documento o tipo sin necesidad de definirlos específicamente.
5.2.5.- Las propiedades o metadatos Las propiedades o metadatos son la unidad básica de la definición del modelo. Nuestra meta cuando iniciamos la construcción del mismo es poder acabar teniendo unos documentos que pertenecen a un tipo y que en base a ese tipo están definidos por unas propiedades que nos permitirán indexarlos, categorizarlos y, posteriormente, realizar buscas selectivas y localizarlos con mayor facilidad. Estas propiedades pueden ser de diferente naturaleza: • • • • • • • • • •
TEXT (d:text) que introduce un campo de tipo cadena de texto (un nombre etc..). CONTENT (d:content) que permite la introducción de un documento binario. INT (d:int) que permite asociar un dígito entero. LONG (d:long) se utiliza para añadir un entero grande. FLOAT (d:float) que se usa para introducir un número decimal (coma flotante). DATE (d:date) que se utiliza para añadir la fecha (año, mes, día). DATETIME (d:datetime) que permite añadir fecha y hora (denominado en inglés timestamp). BOOLEAN (d:boolean) que introduce un valor binario TRUE o FALSE CATEGORY (d:category) que hace referencia a una categoría con una clasificación. PATH (d:path) que permite la introducción de una URL.
Es importante recordar que los valores de estas variables pueden ser restringidos mediante el uso de las denominadas constraints que vimos al inicio de este capítulo. También podemos definir que unas propiedades puedan convertirse en propiedades de tipo índice, de manera que optimicen a posteriori el trabajo de realizar búsquedas por estos mismos metadatos.
Andrés Aznar Royo
Página 24
Alfresco
El modelo de metadatos
Ejemplo de definición de las propiedades en un aspecto
En una propiedad, podemos observar que se define su nombre, un título, su tipo en base a los vistos con anterioridad y si la misma es obligatorio que tenga un valor. Mediante el index enabled podemos asignar a dicha propiedad el carácter de ser un índice (se definirá como tal cuando almacenemos el metadato en la base de datos del modelo).
Ejemplo de propiedad definida como índice
También, como veíamos al principio de este capítulo, podremos restringir mediante las constraints el tipo de valor que asignamos a una propiedad.
Andrés Aznar Royo
Página 25
Alfresco
El modelo de metadatos
Ejemplo de propiedad restringida con una constraint
En el caso del ejemplo anterior, nuestra propiedad co:coUbi tomará un valor marcado por la constraint co:ListaUbicaciones que habremos definido anteriormente.
Constraint definida y utilizada en la propiedad anterior
5.3.- El fichero de publicación en Alfresco Explorer Una vez hayamos definido nuestro modelo con su jerarquía de tipos, sus aspectos, sus propiedades, constraints etcétera debemos conseguir que dicho modelo se refleje dentro de la interfaz de Alfresco, en términos propios de la aplicación, hemos de transferirlo a los ficheros de renderización. Dado que Alfresco presenta dos interfaces diferentes, la clásica del Explorer y la del Share, será necesario aplicar los cambios por duplicado en ficheros diferentes. El fichero de renderización para Alfresco Explorer es el web-client-config-custom.xml y se halla ubicado en el mismo directorio donde teníamos los ficheros que hemos tratado anteriormente: {directorio servidor de aplicaciones}\shared\classes\alfresco\extension El fichero web-client.config-custom.xml se inicia con la etiqueta
Andrés Aznar Royo
Página 26
Alfresco
El modelo de metadatos
Vista inicial del fichero de renderización en Explorer
Las diferentes partes del Explorer donde hemos de añadir nuestros tipos personalizados son: • • • •
El asistente para la asignación de tipos de contenido (wizard) La interfaz de la búsqueda avanzada El motor de ejecución de acciones (action wizard) La pantalla de visualización de propiedades de los propios documentos
Para visualizar los tipos en nuestro asistente de asignación de tipos de contenidos deberemos generar una condición de configuración para el Content Wizards y asignar los nombres de nuestros tipos personalizados.
Sección para dar visibilidad a nuestros tipos personalizados en el wizard de tipos de documentos
Lo que permite esta configuración es que en la carga de un nuevo documento podamos incluir nuestros tipos personalizados durante el asistente de definición del mismo.
Andrés Aznar Royo
Página 27
Alfresco
El modelo de metadatos
Vista del asistente de inserción de un nuevo documento con nuestros tipos personalizados.
Para generar la vista de la búsqueda avanzada deberemos definir los tipos que participarán y deberemos, asimismo, indicar cuáles serán los campos de estos tipos que queremos utilizar (propiedades, que definiremos indicando el aspecto al que pertenecen). Como veíamos cuando hablábamos anteriormente de propiedades, es recomendable que los campos o metadatos que utilicemos en la búsqueda avanzada hayan sido definidos como índices al crear esa propiedad en el tipo o aspecto pertinente.
Definición de tipos y propiedades a mostrar en la búsqueda avanzada
Esta configuración se reflejará en nuestra interface de Alfresco mostrando tipos y propiedades en la búsqueda avanzada.
Andrés Aznar Royo
Página 28
Alfresco
El modelo de metadatos
Muestra de la búsqueda avanzada con los tipos predefinidos
Las propiedades predefinidas se mostrarán bajo el apartado de opciones adicionales.
Vista de las opciones adicionales con las propiedades personalizadas
Andrés Aznar Royo
Página 29
Alfresco
El modelo de metadatos
El siguiente punto donde hemos de añadir nuestro modelo es en los asistentes (wizards) de ejecución de acciones. Este asistente se utiliza tanto cuando usamos “Ejecutar acción” como cuando creamos reglas de contenido sobre un contenedor o carpeta de Alfresco. Dado que tenemos la posibilidad de generar una acción para asignar un tipo pero también para asignar un aspecto, deberemos incluir ambos términos en nuestro fichero de renderizado a fin de que podamos usar ambos. Esto es lo que haremos con el código siguiente.
Sección del fichero de renderizado para la definición de los asistentes de acciones y reglas
Recordemos que cuando hemos generado nuestro modelo hemos usados los aspectos como conjuntos de datos obligatorios para determinados tipos. Sería lógico pensar que, como nos guiaremos por un modelo de tipos de documentos, no sería necesario asignar aspectos de forma individual ya que éstos serán asignados en función del tipo definido. Si lo hiciéramos de dicha manera, eliminando los aspectos de esta sección, nos aseguraríamos que el no puede asignar individualmente aspectos a un determinado documento. No obstante, como ejemplo ilustrativo, quizás es mejor mostrar cómo podemos añadir ambas clases de elementos a nuestra interface.
Andrés Aznar Royo
Página 30
Alfresco
El modelo de metadatos
Ejemplo de la secuencia de aplicación de regla de contenido a una carpeta, con los tipos personalizados
Finalmente debemos aplicar nuestros tipos y aspectos a los formularios de visualización y edición de las propiedades cuando entramos en las pantallas de visión de los documentos. Para ello generaremos nuestra “property-sheet” con los metadatos que vayamos a mostrar en la pantalla.
Definición de la visualización del aspecto co:AspectoFichaBibliografica
Mediante el código anterior conseguiremos que este aspecto (asociado al tipo de publicación externa) nos permita visualizar y editar las propiedades de aquellos documentos que definamos con este tipo.
Andrés Aznar Royo
Página 31
Alfresco
El modelo de metadatos
Vista de la pantalla de propiedades de un documento con los metadatos personalizados del aspecto ficha bibliográfica
Vista de la pantalla de edición y modificación de propiedades de un documento
Andrés Aznar Royo
Página 32
Alfresco
El modelo de metadatos
5.4.- El fichero de propiedades En el fichero de declaración del modelo en Explorer veíamos que se aludían a dos definiciones: la definición del modelo de contenido (ya comentada) y el fichero de etiquetas i18n donde traduciremos los nombres de los contenidos y las variables a la cadena de texto pertinente. Este fichero lo llamaremos company.properties y lo generaremos en el directorio: {directorio servidor de aplicaciones}\shared\classes\alfresco\messages Las secciones de este fichero serán: • • •
Sección de etiquetas para las propiedades de los aspectos. Sección de etiquetas para los aspectos. Sección de etiquetas para los tipos.
En la sección de propiedades definiremos las etiquetas para las mismas que veremos cuando se nos presenten en pantalla. La sintaxis será: prefijo_nombredelmodelo.property.prefijo_nombredelapropiedad.tittle=etiqueta En nuestro caso, por ejemplo: co_company.property.co_coAutor.title=Autor del documento Recordemos que nuestro modelo se llama company y tiene el prefijo co (co:company).
Ejemplo de las secciones de propiedades para documentos internos y externos en el fichero company.properties
Una vez definidas las etiquetas para las propiedades realizaremos el proceso para tipos y aspectos. En este caso tendremos dos bloques para cada uno de estos elementos. Los bloques de los aspectos tendrán una sintaxis del tipo:
Andrés Aznar Royo
Página 33
Alfresco
El modelo de metadatos
Bloque 1: prefijo_nombredelmodelo.aspect.prefijo_nombredelaspecto= etiqueta Bloque 2: aspect.prefijo_nombredelaspecto= etiqueta Para el caso de los tipos será similar: Bloque 1: prefijo_nombredelmodelo.type.prefijo_nombredeltipo= etiqueta Bloque 1: type.prefijo_nombredeltipo= etiqueta
Definición de aspectos y tipos en el fichero de propiedades i18n
5.5.- El fichero de declaración en Alfresco Share El hecho de realizar la publicación de las propiedades en la interface de Explorer no implica que esa misma visualización se extienda a Share. Share tiene sus propios ficheros de renderizado y tipos, aspectos, propiedades, etcétera tendrán que darse de
Andrés Aznar Royo
Página 34
Alfresco
El modelo de metadatos
alta en estos ficheros para poder mostrarse en cuando utilicemos esa parte de Alfresco. El primer fichero es el que declarará nuestras propiedades para ser renderizadas referenciando a las etiquetas del fichero company.properties que hemos visto en el apartado anterior. Este fichero se llama custom-slingshot-application-context.xml y se hallará ubicado en el directorio: {directorio servidor de aplicaciones}\shared\classes\alfresco\web-extension
Fichero custom-slingshot-application-context.xml
5.6.- El fichero de publicación en Alfresco Share El fichero que gestiona la interface de Share es el share-config-custom.xml. Este fichero se halla en la misma ubicación que el que hemos tratado con anterioridad: {directorio servidor de aplicaciones}\shared\classes\alfresco\web-extension En este fichero gestionaremos: • • • •
La accesibilidad a los aspectos personalizados cuando se utiliza la opción de añadir aspecto a un documento en sus propiedades. La jerarquía de asignación de tipos. La inserción en la búsqueda avanzada del Share Todos los formularios vinculados a tipos, aspectos y propiedades de un documento, y que se gestionan en conjunto para cada tipo.
Fichero de configuración del share: cabecera inicial
Andrés Aznar Royo
Página 35
Alfresco
El modelo de metadatos
La sección de document library del fichero nos permitirá insertar todos los aspectos que deseemos en la opción de añadir aspectos del share.
Inserción de los aspectos personalizados a la gestión de aspectos del share
El resultado se mostrará en el cuadro de diálogo de adición de aspectos para los documentos.
Cuadro de diálogo de inserción de aspectos para los documentos en Share
Otra sección dentro del mismo fichero nos permitirá gestionar como jerarquizamos la asignación de tipos a los documentos. Recordemos que nuestro modelo de tipos tiene una jerarquía. Se parte de la base del modelo de contenido estándar (content) y se
Andrés Aznar Royo
Página 36
Alfresco
El modelo de metadatos
generan tipos (documento interno, documento externo…) que a su vez tienen subtipos etcétera. En definitiva, tenemos una estructura de árbol. Tenemos que conocer, asimismo, que cuando a un documento le asignamos que es de un determinado tipo esta asignación es irreversible. No podremos devolverlo al estado anterior. Sí que podremos, por otra parte, volver a asignarle un tipo de los niveles siguientes al tipo anterior (dentro del árbol) pero nunca devolverlo a un tipo previo padre, al content model original o a un subtipo de otra naturaleza. La permisividad de saltar des de un tipo a un nivel o más niveles inferiores, dentro de share, se puede definir en este fichero.
Vista de la gestión de las jerarquías en la asignación de tipo de contenido
En el ejemplo anterior vemos los tipos y los subtipos que nos permitirá asignar. Un documento de tipo content lo podremos convertir en sus hijos (TipoCompany, TipoNoCompany o TipoPublicacion), también en los hijos de sus hijos (TipoFacturaExterna, que es hijo de TipoNoCompany en nuestro modelo, TipoQualProcDoc que es hijo de TipoCompany) e incluso en los hijos de estos últimos (TipoQualPR, que es hijo de TipoQualProcDoc, que lo es de TipoCompany). A su vez, el TipoCompany vemos que tiene como subtypes (es decir, como documentos que podremos asignar partiendo del tipo inicial TipoCompany) tanto su hijo TipoQualPorcDoc como los derivados de éste (TipoQualPR, TipoQualPRAE…). Vemos también que el TipoQualProc se puede derivar en sus cinco hijos y que el TipoNoCompany lo podemos convertir en TipoFacturaExterna (único hijo definido inicialmente en nuestro modelo de ejemplo). Recordemos que, una vez asignado un tipo sólo podremos seguir descendiendo en el árbol a un tipo hijo o inferior pero nunca volver hacia arriba. La definición de este fichero es la forma en que se nos permite realizar esta asignación por la interface del Share. Si, por ejemplo, no quisiéramos que se pudieran saltar dos niveles de asignación de golpe, el fichero debería sólo tener como subtypes para cada type aquellos tipos que en el modelo original definimos como hijos. De esta manera no podríamos saltar varios niveles aunque haciéndolo nivel a nivel podríamos alcanzar el mismo resultado.
Andrés Aznar Royo
Página 37
Alfresco
El modelo de metadatos
Vista de la asignación de un documento a un tipo. Partiendo del content y según el ejemplo definido en el fichero anterior.
La definición de los campos a utilizar en la búsqueda avanzada se gestionan a partir del código que define que formularios vamos a utilizar y de la asignación de los metadatos al formulario concreto. Así la adición al Advanced Search de la instrucción:
nos va a indicar que tendremos propiedades del tipo mencionado en nuestra búsqueda avanzada. Posteriormente definiremos el formulario de búsqueda para este tipo
Related Documents 171j1w
Alfresco Manual w6ag
April 2023 0
Alfresco 13s3r
April 2023 0
Manual Alfresco 604j3l
November 2019 46
Manual Alfresco 604j3l
November 2019 44
Alfresco Manual s586m
October 2019 116
Alfresco Architecture 6i3644
April 2021 0More Documents from "Andrew Divemaster" 6t6v4f
Alfresco Manual w6ag
April 2023 0
Liferay Jasper 38a73
April 2023 0
Eurotherm 6100e Manual Pdf 64st
October 2019 201
Eu Robo Livro Pdf 2i2v50
October 2019 491
Ib Hl Chemistry Assessment Statements Topics 9 And 19 i5354
November 2019 190