Existente diversas situaciones ante las cuales nos vemos en la necesidad de volcar una cantidad importante contenido a una instancia de Opencms. El caso más común, la migración de contenido XML/HTML desde un sistema existente al sistema de archivos virtual de Opencms.

A continuación, vamos a explicar un procedimiento sencillo y efectivo para incorporar contenido masivamente a Opencms.

1. El primer paso de este procedimiento es la generación de un archivo ZIP con la estructura de directorio y archivos a incorporar a Opencms. Es muy importante tener en cuenta que esta misma estructura va a ser generada dentro del VFS.  
2. Una vez creado el archivo con el contenido a incorporar, ir al Workplace, vista de Explorador y hacer click sobre el botón UPLOAD. Seleccionar el archivo a subir y marcar la casilla que indica que el archivo a importar es un ZIP.

Una vez aceptada la acción, el sistema creará de forma automática las carpetas e importará los archivos contenidos dentro del .ZIP determinando el content-type de acuerdo a la extensión de los archivos a procesar. Por ejemplo, cuando el .ZIP contiene archivos con extensión .JPG, los mismos serán incorporados a Opencms con el tipo “image”.

El mapeo de extensiones y tipos de archivos puede ser configurado en opencms-vfs.xml. Para esto, debemos ubicar el nodo <resourcetype> y estabecer las relaciones dentro de la sección <mapping>.

Para aquellos casos donde los archivos fueron subidos y no son reconocidos por Opencms como un tipo de contenido declarado, puede modificarse el content-type de forma programática mediante una JSP que utilice el siguiente método de CmsObject propio de la API de Opencms:

public void chtype(String resourcename, int type) throws CmsException

Éxitos en la importación de contenido!

A continuación, compartimos las 11 razones que nos llevaron a elegir OpenCMS para la construcción de portales de alto tráfico como www.perfil.com, www.lacapital.com.ar y www.diariouno.net.ar.

1. Comunidad / Soporte

Opencms cuenta con una importante comunidad de desarrollo, más de 120 proveedores de soluciones a nivel mundial y más de 5.000 casos de implementación en el mundo entre los cuales se encuentran: FOX Australia, Dreamworks Animation, 3M, Renault y Bayer.

Posee módulos libres y comerciales provistos por terceras partes y por el desarrollador del producto (Alkacon Software GmbH).

El soporte comercial de OpenCMS se brinda tanto por la empresa desarrolladora de la solución (Alkacon Software) como a través de su red de proveedores de soluciones.

2. Gestión de Contenido

La solución permite la utilización de múltiples tipos de contenido o definir tipos propios a través de un modelo de propiedades y atributos extensible. Los contenidos son persistidos en un sistema de archivos virtual (VFS) y pueden ser entregados a los navegantes de forma estática o dinámica. Nuestra firma ha extendido OpenCMS para incorporar soporte a tipos de contenido como: Video Flash, Audio Flash, PDF, Noticias, Carteleras, etc.

El modelo de carga es muy sencillo, pudiendo optar por múltiples editores, tipos de contenido estructurados o carga programática. La opción por defecto es un editor avanzado (FCKEditor). El editor de contenido puede ser actualizado de forma independiente al resto de la plataforma permitiendo un correcto desempeño con navegadores modernos.

OpenCMS posee soporte nativo de versionado automático, permitiendo ver un historial completo de lo ocurrido con un elemento dentro del sistema. Esto es sumamente importante en un entorno de redacción donde debe llevarse cierto nivel de control sobre la evolución de una nota. Además, posee soporte de “bloqueo” de contenido para permitir la colaboración entre diferentes usuarios (símil check-in / check-out).

3. Templates

La construcción de templates dentro de la herramienta de CMS es una de las barreras de entrada más fuertes que presentan muchas soluciones existentes en el mercado actual.

La generación de templates a medida en OpenCMS puede realizarse utilizando cualquier herramienta de diseño web HTML para su posterior integración en páginas java (JSP), las cuales pueden ser construidas tomando como base el templates nativo TEMPLATEONE.

La construcción de estos templates requiere conocimientos básicos de Java, HTML / CSS y sólidos conocimientos de JSP, XML / XSD para interactuar con funcionalidad dinámica construida por el usuario alrededor de OpenCMS.

4. Gestión de Imágenes

La solución cuenta con un módulo nativo de gestión de imágenes que permite subir archivos individuales, archivos ZIP para la carga de múltiples elementos, ajuste de tamaño automático, y estatificación configurable a nivel de elemento o carpetas. De esta forma puede servir el contenido visual haciendo uso del cache nativo del servidor Web.
Los usuarios pueden organizar sus imágenes a nivel de Galerías temáticas o por fecha.

Para aquellos casos donde la gestión de activos visuales es un requerimiento es posible realizar la integración con sistema de imágenes como CUMULUS. OpenCMS posee uno de los casos más importantes de referencia: THE ROYAL LIBRARY.

5. Rendimiento, Disponibilidad y Escalabilidad

La problemática de los sitios de alto tráfico suele estar íntimamente vinculada con la reducción del impacto en múltiples servidores Web consultando el motor de base de datos. En este punto es importante definir una estrategia para servir el contenido a los usuarios: dinámica o estático. Afortunadamente OpenCMS puede trabajar con ambas y expone mecanismos de cache diferenciados para cada caso.

OpenCMS presenta diferentes niveles de cache orientados a solucionar ese problema en forma eficiente:
1. FlexCache: realiza el cache de las diferentes JSP y sus variantes
2. OCEE Accelerator (DB): es un sistema de cache que tiene por objetivo reducir la cantidad de consultas a la base de datos (VFS).
3. Static Export (servir estáticamente) + Modproxy: realiza el cacheo del contenido que fue definido como estático a nivel del servidor Web Apache.

La FlexCache posee directivas avanzadas para la gestión de diferentes tipos de contenido. En la versión 6.x se recrea en cada publicación mientras que en versión 7.x la limpieza del cache se realiza a nivel de ítem. Por su parte el OCEE Cache de base de datos persiste a través de las múltiples publicaciones y sólo es renovado cuando el sistema se reinicia o los elementos expiran.

A diferencia de otras soluciones de CMS, la escalabilidad en OpenCMS es provista a nivel de la aplicación OpenCMS Alkacon OCEE Cluster que permite tener un servidor designado como Workplace (Intranet) y múltiples servidores de frontera encargados de servir el contenido a los navegantes. Este modelo posibilita una escalabilidad ilimitada y alta disponibilidad a través de diferentes esquemas de implementación que detallaremos en otro artículo.
A nivel de base de datos OpenCMS ofrece las opciones de mercado más reconocidas: MySQL, Microsoft SQL Server, PostgreSQL y Oracle.

6. Seguridad

Los aspectos centrales de la seguridad son:
1. Proteger el acceso a los contenidos en preparación (externo)
2. Administrar eficientemente el acceso de usuarios (interno)

A nivel externo, el servidor de Workplace (también llamado Intranet de publicación) puede existir sin necesidad de estar publicado en Internet. Es recomendable además que este equipo disponga de conectividad independiente (entre el servidor y los usuarios que acceden a él) para no competir por ancho de banda con los servidores públicos retrasando la publicación de nuevo contenido en situaciones de picos de alto tráfico.

A nivel interno, la seguridad se basa en modelo por listas de acceso (ACL) en el Virtual File System a nivel de elemento. Asimismo se brinda soporte para la gestión de soporte para grupos, roles y usuarios. OpenCMS posee una extensión comercial OCEE LDAP para la integración con Servicios de Directorio.

OpenCMS permite además tener un alto nivel de auditoría sobre las acciones de los usuarios en el sistema mediante un “historial de proyecto’”a nivel de recurso.

7. Localización

OpenCMS tiene soporte multi-idioma. Ofrece de forma nativa las localizaciones para inglés y alemán. La comunidad ha desarrollado localizaciones para español e italiano.

8. Motor de Búsquedas

La solución integra el producto Lucene Search Engine. A partir de una extensión de OpenCMS, nuestra firma brinda soporte de búsquedas avanzadas. Permite también la construcción de múltiples fuentes de indexación permitiendo tener un modelo de búsqueda especializado por cada índice.

Los índices de búsqueda pueden asociarse con tipos de contenido, recursos y proyectos. La indexación se realiza por atributos de los elementos como por ejemplo título, palabra clave, meta tag, categorías, fecha de creación, fecha de publicación, edición, tipo de publicación, etc.

9. Funcionalidad Interactiva

La funcionalidad interactiva puede ser construida fácilmente como contenido estructurado o como módulo que extienden a OpenCMS. Actualmente, se encuentran disponibles módulos para:

• Registración y Autenticación de Usuarios Web
• Valoración de Contenido
• Comentarios y Reporte de Abuso
• Suscripción y Administración de Newsletter
• Opiniones (símil Foro)
• Recomendación de contenido
• Múltiples tipos de Rankings para los navegantes
• RSS para sindicar contenido
• Gestor de Encuestas
• Etc (http://www.tfsla.com/productos_opencms_modulos.php)

10. API de Integración y Extensión

OpenCMS expone abiertamente todo su código (excluyendo las extensiones comerciales) permitiendo a los usuarios tener una versión personalizada del CMS y extender el mismo. El acceso a la funcionalidad básica puede realizarse a través de la Core Build API.

El conocimiento disponible sobre el desarrollo se encuentra muy bien documentado y disponible en www.opencms.org, Online Javadoc y el repositorio CVS.

11. Separación de Entornos

La separación tradicional de entornos incluye desarrollo, pruebas y producción. En OpenCMS es posible alcanzar esta separación de diferentes formas:

La primera, consiste en tener un servidor de desarrollo con las extensiones OCEE instaladas en modo desarrollo lo cual nos permite trabajar en un entorno prácticamente idéntico al productivo. Una vez terminado el desarrollo, el módulo completo puede ser exportado e importado en el nuevo servidor.

La segunda forma implica la utilización del OCEE Replicator para enviar la información del servidor de desarrollo al servidor de producción de forma automática.

La tercera forma, aunque la menos recomendada pero apta para situaciones particulares, considera el despliegue de OpenCMS en diferentes servidores (N) y el consumo de 2 o más bases de datos. A idéntico sistema de archivos de los servidores, la única diferencia posible es el contenido del sistema de archivos virtual (VFS). El VFS vive dentro de una base de datos que puede replicarse de forma manual o automática y lograr que otro servidor, consumiendo esta base “esclava”, obtenga la misma funcionalidad que la primera.

Introducción y Objetivos

Básicamente la tarea comprenderá dos conjuntos de acciones diferenciadas:

1. Aquellas que tengan que ver con la administración llevada a cabo desde el Workplace de OpenCms, lo que puede realizarse desde cualquier Web Browser, a través de la dirección en que se encuentre nuestro sistema.
2. La modificación de los archivos de configuración de OpenCms, para lo cual deberá accederse a la ubicación del servidor que soporte la instancia del sistema que estamos utilizando.

Debido a que muy probablemente nos encontremos accediendo remotamente al servicio, deberemos valernos de algún método que nos permita tener acceso a los archivos necesarios desde donde nos encontremos. Puede optarse por una herramienta como PuTTY, o cualquier otra que nos permita conectarnos al servidor destino y acceder a sus archivos.

Nuestro objetivo sera entonces el de crear un tipo de contenido estructurado y facilitar su manipulación desde el Workplace. Podremos crear un nuevo tipo definido por el usuario, seleccionándolo desde la interfaz de creación, y editar su contenido, a partir del formulario que generará OpenCms con los parámetros que le indiquemos.

Nuestro interés se centra en ciertos archivos de configuración ubicados en el path <rutaTomcat>/webapps/opencms/WEB-INF/config (por ejemplo, para sistemas Linux suele ser por defecto: /usr/share/tomcat5/webapps/opencms/WEB-INF/config).

Opencms posee dos formas de realizar la definición de un tipo de contenido estructurado:

• La primera opción implica la modificación de los archivos opencms-vfs.xml y opencms-workplace.xml. Esta opción no es recomendada debido a su complejidad.
• La segunda opción implica colocar los archivos que definirán la nueva estructura dentro de un modulo separado, y editar la definición de dicho módulo dentro del archivo opencms-modules.xml, que se encuentra en la misma ruta que los dos anteriores, y se encarga de albergar el “esqueleto” de los módulos definidos en nuestro sistema. Esta es la opción recomendada que utilizaremos.

En resumen, esta última opción implica agregar información a opencms-modules.xml sobre el nuevo contenido en dos niveles:

• Una referencia al archivo xsd que definirá nuestro contenido, lo que puede lograrse a través del elemento <type> de <resourcetypes>, más precisamente en su item <param>.

      Ejemplo: <param name=”schema”>”Path xsd”</param>

• Detalles sobre el tipo de contenido en la vista de Explorador del Workspace (nombre, descripción, icono, etc), usando el elemento <explorertype> de <explorertypes>.

Ejemplo: <explorertype name=”nombreContenido“    key=”claveNuevoContenido” icon=”imagen.gif” reference=”xmlcontent“>

A continuación, describiremos paso a paso las tareas a realizar para implementar la opción 2.

Paso 1: Creación del Módulo
 
Desde la vista de Administración, estando en Offline procedemos a la creación de un nuevo módulo. Como nombre de package usaremos com.tfsla.contenidos.prueba, y para el nombre del módulo utilizaremos, por ejemplo, Definicion de contenido estructurado. Es importante tildar los campos Create Modulefolder y Create classes subfolder entre las opciones que ofrece el recuadro Module folders. De lo contrario deberemos dirigirnos al mencionado opencms-modules.xml para definirlo manualmente, o realizarlo luego desde el Workplace.

Una vez creado el módulo, debe corroborarse que se haya generado automáticamente un Export Point para el subdirectorio classes que se eligió crear anteriormente. Para esto seleccionamos el nombre del módulo creado dentro de la vista de administración, con lo cual accederemos a un conjunto de opciones, entre las que se encuentra Module exportpoints. Una vez allí, podremos observar que la carpeta classes del módulo creado (/system/modules/com.tfsla.contenidos.prueba/classes/) se mapea en WEB-INF/classes, lo que nos indica que fue correctamente creado. De lo contrario deberá elegirse New exportpoint y completarse los campos de forma manual.

Luego de esto nos encargaremos de los recursos. Volvemos a la vista de administración con las opciones de nuestro flamante módulo y seleccionamos esta vez, Module Resources. Seguramente se encontrará el path de nuestro módulo (/system/modules/com.tfsla.contenidos.prueba/).

Nuestra lista de recursos debería incluir rutas a archivos utilizados en la configuración de contenido estructurado, localizados en distintas partes del VFS. En particular el camino hacia la carpeta que contiene iconos para listar el contenido estructurado en la interfaz del Workplace. Éste es por defecto: /system/workplace/resources/filetypes/, que procedemos a añadir a nuestra lista de recursos.

Paso 2: Creación del esquema XSD

Así como optamos anteriormente por crear un módulo separado que contenga los elementos de nuestro nuevo tipo de contenido, haremos lo propio con los archivos xsd que definirán la estructura del mismo. Para esto nos colocamos dentro del módulo creado (/system/modules/com.tfsla.contenidos.prueba/) y vamos a New->Folder, en la vista de Explorador. Le pondremos el nombre schemas a la carpeta, que es el que se utiliza comúnmente para estos fines. Nos limitaremos sólo a nombrarlo, sin añadir cualquier otra propiedad.

Dentro de schemas, procederemos a generar un nuevo recurso, esta vez, un archivo del tipo Text File, al que nombraremos como contenidos.xsd.

A continuación, procederemos a editarlo, para dar lugar a un nuevo tipo de contenido con una estructura similar a la de una noticia.

Nos basaremos en el ejemplo que proporciona Alkacon, con algunas modificaciones. Podemos encontrarlo dentro del tutorial llamado “OpenCms XML content documentation”, que viene con la versión que utilizamos de OpenCms.

Nuestro contenido llevará un título, una cantidad de hasta tres subtítulos y un cuadro de texto.

A continuación se transcribe el xsd del que haremos uso:

Como se puede observar, este archivo contiene el nombre del elemento raíz (TfsTypes, que debe terminar siempre con una “s”) y el tipo del contenido XML (que debe llevar el mismo nombre precedido del prefijo OpenCms).

Debajo de estas definiciones podemos ver la del elemento hijo con nombre TfsType (igual a su padre pero sin la “s”), y a continuación una segunda definición de tipo complejo, que contiene la secuencia de elementos con sus correspondientes tipos de datos. Aquí usamos OpenCmsString para cadenas cortas sin contenido HTML, y OpenCmsHtml que permite almacenar texto con contenido HTML.

Debe editarse el contenidos.xsd creado con esta información, y guardarse para finalizar la etapa de definición.

Paso 3: Modificación de archivos de configuración

Como mencionamos anteriormente, el archivo de configuración que modificaremos se llama opencms-modules.xml y se encuentra por defecto en el path

/usr/share/tomcat5/webapps/opencms/WEB-INF/config en sistemas Linux.

Hay que tener en cuenta que para modificar este tipo de archivos es necesario tener ciertos permisos, que, por lo general, no son frecuentes en usuarios normales del sistema. El root siempre puede llevar a cabo estas actualizaciones, por lo que es recomendable, o bien ingresar como éste, o adquirir sus permisos (por ejemplo, en Linux el comando sudo su nos permite que nuestro uid y gid reales y efectivos se seteen a los del superusuario, y podamos ejecutar comandos como él sin necesidad de estar logueados a root).

En primer lugar debemos identificar la parte del archivo opencms-module.xml que editaremos a continuación. Dicha sección del fichero será la que contenga las definiciones sobre el módulo que creamos. En nuestro caso se trata de la siguiente:

Para localizar este fragmento podemos valernos de varios recursos si contamos con un editor sofisticado, sin embargo este no es siempre el caso, ya que, por lo general, nos valemos de versiones del sistema operativo concebidas con el único fin de soportar la instancia del OpenCms del que nos servimos. Si utilizamos vi para la edición (nos basaremos en dicho editor por encontrarse en la mayoría de los casos disponible), podremos localizar esta porción facilmente a través del comando de búsqueda :/ , seguido del nombre de nuestro módulo (com.tfsla.contenidos.prueba). El cursor se posicionará entonces en el sector deseado dentro del xml.

Para proceder a la edición de esta parte, nos basaremos en un módulo ya existente en el sistema, a fin de copiar la estructura necesaria, modificando las secciones que merezcan un tratamiento especial. Esto nos permitirá reutilizar un código ya probado y evitar cualquier error debido a restricciones inherentes.

Nos dirigimos, dentro del mismo opencms-modules.xml, a la sección que define el módulo org.opencms.frontend.templateone.xmlcontentdemo.

Nuestro interés se encuentra en los elementos etiquetados como <resourcetypes> y <explorertypes>.

Dentro de <resourcetypes> nos interesa el siguiente fragmento:

Marcamos en rojo lo que debe cambiarse. En name colocaremos el nombre de lo que deseamos crear. En nuestro caso lo bautizamos TfsType. En id deberemos optar por un identificador que sólo pertenezca al tipo que definiremos, es decir, debe ser único en el sistema OpenCms que estamos usando. Una buena opción sería comenzar a partir de 100, ya que hay escasas posibilidades de que en la declaración de contenidos se haya alcanzado este valor. Es importante aclarar que si se utiliza un id previamente definido, nuestra definición se corresponderá a la de aquella que lo haya usado, basándose nuestro tipo en la estructura creada para la misma.

Finalmente, en la etiqueta <param> correspondiente (marcada en rojo también), colocamos el path donde se halla nuestro xsd:

system/modules/com.tfsla.contenidos.prueba/schemas/contenidos.xsd.

Con respecto a los elementos de <explorertypes>, el fragmento que extraeremos desde xmlcontentdemo será éste: 

Cambiaremos el atributo name a TfsType, key a fileicon.TfsType, y icon a xmlcontent.gif. En la uri, la palabra article coloreada debe ser reemplazada por TfsType y order al número elegido anteriormente, por ejemplo, 101. La parte restante puede dejarse sin cambios, al menos para los fines del presente artículo.

Resumiendo, el archivo opencms-modules.xml, en la porción de nuestro módulo deberá tener la siguiente apariencia:

Una vez editada esta sección del archivo abandonamos el editor y nos preparamos a la próxima etapa, nuevamente desde el Workplace. Nuestra incursión en los archivos de configuración se da por finalizada de esta manera.

Paso 4: Creación del archivo properties

Nos colocamos entonces en la vista del Explorador, en el Workplace de nuestro OpenCms y accedemos al path

/system/modules/com.tfsla.contenidos.prueba/classes/com/tfsla/contenidos/prueba/

para la creación de un archivo que nos permitirá definir cómo este tipo de contenido es llamado cuando es listado en la interfaz del Workplace.

Todo esto se logra a través de un archivo .properties (tabla hash), que bautizaremos como workplace.properties.

Damos New, para crear un nuevo Text File, con el nombre que mencionamos, y lo llenamos con lo siguiente: 

fileicon.TfsType = TfsType

title.TfsType = Create new TfsType 

Guardamos esta información y ya tenemos nuestro archivo properties listo para nuestra nueva definición.

 Paso 5: Creación de un recurso del tipo definido

Antes de proceder, reiniciaremos Tomcat, a fin de dar lugar a las modificaciones llevadas a cabo. 

Finalmente resta crear un nuevo elemento para probar nuestra definición. Vamos a New->Structured content, y veremos que entre las opciones que nos presenta el sistema, se encuentra la de nuestro flamante TfsType. Seleccionamos el tipo mencionado y luego lo editamos para ver que el formulario se creó de acuerdo a los parámetros colocados en el archivo contenidos.xsd.

De esta manera finaliza el proceso de definición de contenido XML estructurado. 

Información adicional y enlaces útiles:

• Tutorial Oficial de Alkacon Software sobre contenidos estructurados llamado “OpenCms XML content Documentation”. Interesante para la definición de esquemas XSD. Carece de contenido sobre la utilización del tipo creado desde la interfaz del Workplace:

http://195.14.236.181/opencms/opencms/alkacon-documentation/documentation-xmlcontent/

• Tutorial Flash para la creación de contenido estructurado:

http://www.wdogsystems.com/opencms/opencms/demos/structured_content_editing.html

• Herramienta PuTTY, útil para el acceso remoto al servidor que contenga la instancia de OpenCms que usamos:

http://www.tartarus.org/~simon/putty-snapshots/x86/putty.exe