Formación para técnicos

Presentación general

1
 Objetivos del curso

• Generales
– Conocer la plataforma Agrega y potenciar su implementación en las
aulas, utilizando entornos de aprendizaje, flexibles y creativos, en los
diferentes niveles de enseñanza y en las distintas áreas curriculares.

• Específicos
– Comprobar la facilidad de uso y accesibilidad de Agrega e identificar
los estándares soportados: catalogación LOM, accesibilidad AA e
integración con otras plataformas SCORM.
– Identificar las características específicas de la plataforma:
uniformidad en estándares, posibilidades de uso de los recursos
educativos dentro y fuera de la plataforma, definición y
características de objetos de aprendizaje, adecuación por las
comunidades autónomas, etc.
– Manejar el buscador como localizador de recursos.
– Usar el catalogador de contenidos con el fin de asociar correctamente
los objetos con la metainformación necesaria, y conseguir una
adecuada caracterización y localización.
– Identificar los pasos necesarios para crear y publicar contenidos.

2
 Contenidos del curso
Módulo 1. Resumen de funcionalidades
1. ¿Qué es?
2. Componentes básicos

Módulo 2. Arquitectura
1. Introducción
2. Arquitectura física
3. Arquitectura lógica

Módulo 3. Instalación (Componentes de la plataforma)

1. Capa de datos
2. Capa de aplicación
3. Capa de servidor web

Módulo 4. Administración
1. Contenidos
2. Plataforma
3. Configuración
3
 Contenidos del curso

Módulo 5. Operación
1. Arranque y parada de los aplicativos
2. Ficheros de Log
3. Backups
4. Modificaciones frente a cambios frecuentes
5. Tareas planificadas
6. Generación automática de ficheros
7. Seguridad
8. Actualización MediaWiki

Módulo 6. Integración
1. Integración
2. WebServices publicados
3. OAI-PMH
4. Gestor de sesiones
5. SQI
6. DRI
4
 Módulo 1. Introducción: portal Agrega

• ¿Qué es Agrega? Plataforma dirigida a toda la comunidad educativa que

permite a sus miembros elaborar y compartir distintos recursos
multimedia orientados al aprendizaje y la enseñanza.

• Características:

– Su interfaz sigue unas pautas y normativas de usabilidad, accesibilidad

y multi-idioma que garantizan su uso.
– Permite la creación de redes de repositorios digitales que se
interaccionen entre sí con el fin de facilitar a los usuarios el acceso a
los contenidos educativos almacenados en estos repositorios.
– Incluye el desarrollo de las herramientas necesarias para la
elaboración, gestión y explotación de objetos digitales educativos
(ODEs) sin limitaciones estructurales para futuras ampliaciones.

5
 Introducción

• ¿Qué es un ODE? Agregación de uno o más elementos digitales, que

incorporan metadatos, y que representa una unidad didáctica con
significación educativa.

• Características:

– Unidades de contenido autónomas.

– Granulares y agregables.
– Reciclables.
– Interoperables.
– Identificados y descritos con metadatos.

6
 Introducción

• ¿Qué es un metadato? Es información complementaria que ayuda a

conocer el contenido y el propósito de un ODE sin necesidad de acceder a
éste.

• Agrega gestiona ODEs con los siguientes estándares:

– Empaquetado SCORM 2004.

– Metadatos LOM-ES.

7
 Estándares

• SCORM: desarrolla contenidos de aprendizaje basados en entornos Web.

• Características de SCORM:

– Agrega contenido en paquetes transportables.

– Realiza la ejecución y el seguimiento del contenido.
– Organiza la estructura del contenido.
– Define la secuenciación adaptativa de las actividades.

• Componentes de SCORM:

– Contenidos (archivos físicos) agrupados en un paquete Zip.

– Archivo maestro en formato XML.
– Archivos de control (esquemas XSDs).

8
 Estándares

• LOM-ES: organiza los datos que especifican y detallan un ODE.

• Categorías de LOM-ES:

– General
– Ciclo de Vida
– Meta-metadatos
– Técnica
– Uso educativo
– Derechos
– Relación
– Anotación
– Clasificación

9
 Menús comunes

• Este apartado es accesible a todo tipo de usuarios: anónimos, registrados

y administradores. Se compone de:

– Acerca de Agrega
– Accesibilidad
– Preguntas frecuentes
– Mapa del portal
– Contacto
– Idiomas
– Acceder/Registrarse
– Ayuda
– Salir

10
 Portal

El portal consta de cuatro apartados principales:

•Portada: permite realizar diferentes búsquedas y acceder a los

apartados del menú: noticias, informes, descargas…
•Búsqueda taxonómica: permite seleccionar el ámbito de búsqueda (en
toda la plataforma o únicamente en CNICE) así como el tipo de búsqueda
(en árbol curricular o en Tesauro ETB).
•Carpeta personal: mediante la cual se accede a la herramienta de
empaquetador básico y avanzado, según el nivel.
•Administración: desde la cual es posible realizar una planificación de
tareas para que se ejecuten en un tiempo determinado (por ejemplo,
una carga masiva de objetos digitales educativos).

11
 Portada

• Consta de los siguientes apartados:

– Noticias: novedades relacionadas acerca de

la plataforma.
– Informes: consultas realizadas de los ODEs.
– Descargas: Agrega off-line.
– Agrega en tu Web: permite añadir a tu
Web información relacionada con Agrega.
– RSS o feeds: canales que recogen
información acerca de páginas Web
sindicadas.
– Nube de Tags: muestra las palabras clave
más repetidas en la plataforma.

12
 Carpeta personal

• Se accede a través de la pantalla principal y en ella se almacenan y

visualizan los ODEs que el usuario tiene en fase de creación.

• Aparte de crear ODEs, a través de esta carpeta el usuario puede consultar

aquellos objetos propuestos para su publicación, así como los publicados
en la plataforma Agrega.

13
 Carpeta personal

• Está compuesta por tres pestañas:

– Personales. Muestra los ODEs creados o rechazados por el usuario.

Permite:
• Modificar
• Crear
• Exportar
• Proponer
• Eliminar
• Importar
• Ver historial

– Propuestos. Muestra los ODEs propuestos a crear por el usuario.

– Publicados. Muestra los ODEs creados y publicados por el usuario.

14
 Buscador

• Permite buscar los objetos digitales educativos (ODEs) publicados en la

plataforma. Éstos se pueden previsualizar y/o descargar.

• Se puede acceder al buscador desde distintos puntos del portal, pudiendo

realizarse dos tipos de búsqueda:

– Básica: la búsqueda se realiza configurando un campo de texto.

– Avanzada: la búsqueda se realiza configurando un formulario de

criterios detallados que permita localizar los ODEs de una forma más
exhaustiva.

15
 Búsqueda básica

• Se introducen una o más palabras en la caja de texto.

• Es posible seleccionar el idioma con el que queremos realizar la búsqueda.

• Se eligen los nodos entre los que se quiere dirigir la búsqueda:

– Todo Agrega: realiza una búsqueda en todos los nodos de la

plataforma disponibles en ese momento y en el nodo local.
– Buscar en CNICE: realiza la búsqueda del término introducido en el
servidor local del bando de datos del CNICE.

16
 Búsqueda básica
Pantalla de resultados

17
 Búsqueda básica

Haz clic en la imagen para ver el vídeo

18
 Búsqueda avanzada

• La búsqueda se realiza configurando un formulario de criterios para

localizar los ODEs de forma más exhaustiva

19
 Búsqueda avanzada

Haz clic en la imagen para ver el vídeo

20
 Búsqueda Taxonómica

• Para realizar una búsqueda taxonómica es necesario estar registrado.

• Una vez que entramos en este apartado, debemos seleccionar:

• El ámbito de búsqueda:

• Todo Agrega
• CNICE

• El tipo de búsqueda:

• Árbol curricular
• Tesauro ETB

21
 Búsqueda Taxonómica

Haz clic en la imagen para ver el vídeo

22
 Empaquetador

• Se trata de una herramienta de empaquetación de objetos digitales

educativos, de acuerdo a un estándar (SCORM 2004), que permite generar
paquetes SCORM a partir de los contenidos y ficheros del usuario.

• Según el perfil del usuario, el empaquetador será:

– Básico
– Avanzado

• Ambos perfiles tienen funcionalidades en común como:

– Catalogar
– Previsualizar
– Validar
– Guardar
– Etc.

23
 Empaquetador básico

• Se trata de la versión sencilla de la herramienta de empaquetación de

contenidos de Agrega. No requiere por parte del usuario ningún
conocimiento acerca de estándares de enseñanza electrónica. Se compone
de dos vistas: Estructura y Archivos, cada una con diferentes
funcionalidades.

24
 ¿Cómo se crea un ODE?

Haz clic en la imagen para ver el vídeo

25
 Empaquetador avanzado

• Se trata de la versión más compleja de la herramienta de empaquetación

de Agrega destinada a usuarios con conocimientos sobre estándares
SCORM para la creación de cursos electrónicos. Incluye una gestión
completa de: Archivos, Recursos, Organizaciones y Sub-manifiestos.

26
 Catalogador

• Su función principal es añadir datos de catalogación (metadatos) al objeto

digital educativo que se está creando.

• Dependiendo del perfil elegido habrá dos tipos de catalogador:

– Básico
– Avanzado

• Las opciones de la cabecera Importar, Exportar y Ayuda son comunes

para ambos perfiles.

27
 Catalogador básico

• Asocia al ODE editado la metainformación necesaria para una adecuada

catalogación (mediante el empaquetador básico) y localización del objeto
en la plataforma.

• Componentes:
– Formulario: consiste en cumplimentar los diferentes campos.
– Inserción curricular: sirve para asociar el ODE a un objetivo
curricular.
– Validación: confirma que el ODE está listo para su publicación.
– Guardar validación.

28
Formulario del catalogador básico

29
 Catalogador avanzado

• Asocia al ODE editado la metainformación necesaria para una adecuada

catalogación (mediante el empaquetador avanzado) y localización del
objeto en la plataforma.

• Componentes:
– Formulario.
– Modificar.
– Validación.
– Guardar validación.

30
 Formulario del catalogador avanzado

• Se compone de las siguientes categorías. Cada categoría consta de una

serie de campos que hay que rellenar para la futura publicación del ODE:

– General: información genérica del ODE.

– Ciclo de Vida: describe el estado actual e histórico del ODE.
– Metadatos: describe el propio registro de los metadatos.
– Técnica: requisitos y características técnicas del ODE.
– Uso educativo: describe las características educativas y pedagógicas
del ODE.
– Derechos: derechos de propiedad intelectual y condiciones de uso.
– Relación: describe las relaciones, en caso de que las haya, con otros
ODEs.
– Anotación: comentarios sobre la utilización pedagógica del ODE.
– Clasificación: describe la situación del ODE dentro de un sistema de
clasificación concreto.

31
 Administración

• Desde este apartado se lleva a cabo la planificación de una serie de tareas

con el fin de ejecutarlas o administrarlas posteriormente en la
plataforma.

• Este módulo es exclusivo del administrador. Se compone de:

– Contenidos
– Plataforma
– Configuración

32
 Módulo 2. Arquitectura

Durante este módulo describiremos la arquitectura física y lógica de un nodo de

la plataforma. Un nodo responde a la arquitectura de 3 capas o niveles:

Apache
Capa servidor Web PHP (MediaWiki)
Squid (caché opcional)
JBoss Application Server
Capa de aplicación JDK 1.6
Galería de Imágenes
NFS
Capa de datos Base de datos (MySQL)
LDAP

33
Arquitectura física

34
 Componentes principales

1. Apache

2. JBoss Application Server

3. Base de datos: MySQL

4. LDAP

5. Servidor de ficheros: NFS

35
 Conexiones establecidas

Host Origen Puerto Origen Host Destino Puerto Destino

* (ANY) * (ANY) Apache 80
* (ANY) * (ANY) Apache 443

Apache * (ANY) JBoss 8009

Apache * (ANY) MySQL 3306

* (ANY) * (ANY) JBoss 8080

JBoss * (ANY) LDAP 389

JBoss * (ANY) MySQL 3306

36
Conexiones establecidas

37
 Arquitectura lógica

La plataforma se desarrolla con

la tecnología Java (J2EE v1.4) y
tiene una Arquitectura
Orientada a Servicios (SOA)
donde el papel del proveedor
de servicios lo interpretará el
Nodo de Objetos Educativos
Digitales y el papel consumidor
lo interpretarán las
Aplicaciones Clientes.

38
 Sistema de almacenamiento

Se propone utilizar al menos tres sistemas:

1.Directorio LDAP: se almacenará la información utilizada en los

módulos de autenticación.

2.Sistema de ficheros en disco: se utilizará para aquella información

que se suele almacenar en archivos, por ejemplo: contenidos,
metainformación LOM, trazas del sistema de auditoria, logs, etc.

3.Base de datos: la mayor parte de la información manejada por la

Plataforma será almacenada en el sistema de ficheros.

39
 Capa de acceso a datos

Este elemento de la arquitectura tiene como objetivo proporcionar a los

módulos funcionales un elevado nivel de abstracción sobre los detalles
referentes a cómo los objetos persisten en el sistema de
almacenamiento. De esta forma la implementación de los módulos
funcionales se centrará en la lógica de negocio.

40
 Módulos funcionales
Componente Descripción

Componente encargado de la orquestación de los diferentes servicios lógicos que componen el

nodo de forma que permita ofrecer al exterior una capa de webservices, denominada Interfaz de
DRI
interoperabilidad con las funcionalidades de Presentar/Almacenar, Buscar/Mostrar y
Solicitar/Entregar.

Componente encargado de la coreografía de los diferentes servicios lógicos que compondrán el

nodo de forma que se permita a buscadores tipo Google, tener información acerca de los
OAI-PMH
contenidos digitales almacenados en el repositorio que expone el nodo cumpliendo el protocolo.

Componente encargado de ofrecer servicios de búsqueda y transformar las diferentes búsquedas

Buscar
en el lenguaje entendible por el servicio de Buscador / Indexador.

Componente encargado de ofrecer servicios principalmente al Empaquetador de forma que

Empaquetación gestiona la funcionalidad de empaquetado de un usuario en su propio lugar de trabajo dentro
del repositorio.

Componente encargado de ofrecer servicios al Gestor de Flujo de forma que gestiona el flujo de
Publicación
publicación seguido por un contenido digital.

Componente encargado de ofrecer los servicios para poder consumir los objetos digitales
Entregar
existentes en el repositorio.

41
 Módulos funcionales

Componente Descripción

Componente encargado de ofrecer los servicios para poder catalogar, según el estándar LOM-
Catalogación
ES, los distintos contenidos generados y / o almacenados en el repositorio.

Componente encargado de ofrecer los servicios para poder realizar operaciones sobre los
Contenidos Portales contenidos que se publicarán en el portal, entendiendo como contenidos, las noticias, los feeds
y las descargas.

Componente que implementa los servicios de la herramienta de modificación introducida en el

Modificador
cambio C14.

Componente que se encargará de la gestión de la valoración que se dé por parte de los usuarios
Valoración
a los contenidos.

Componente que conforma un recubrimiento lógico del interfaz propuesto por la librería de
Indexador y Buscador
indexación y búsqueda de Apache Lucene.

Componente que engloba la gestión y explotación de las fuentes taxonómicas, los tesauros,
Fuentes Taxonómicas
árboles curriculares y los vocabularios controlados.

42
Módulos funcionales

43
 Módulo 3. Instalación

Capas de datos

El portal Agrega, en función de la naturaleza de los datos a consultar o

almacenar, hace uso de 3 recursos diferentes a la hora de almacenar la
información:

•Sistema de ficheros
•Base de datos
•Directorio LDAP

44
 Sistema de ficheros

Los contenidos que se albergarán en el sistema de ficheros son:

•Repositorio de ODEs: cada ODE estará formado por una estructura de meta
información, ficheros XML… y los recursos propios del objeto digital
educativo, como pueden ser imágenes, animaciones flash, videos, sonidos
mp3, ogg…
•Esquemas XML.
•Plantillas.
•Informes: reportes generados por la aplicación BIRT.
•Miniaturas (previsualizaciones) de los objetos capturadas por la galería de
imágenes.
•Descargas disponibles desde la plataforma (herramienta off-line…)
•Logs.

45
Sistema de ficheros

46
 Servidor NFS

El servidor de archivos NFS será un servidor con uno o varios discos de gran
capacidad conectados (usando LVM o no) con la capacidad de exportarlos vía
NFS. Es aconsejable que el sistema de ficheros de la unidad exportada sea
ReiserFS o XFS debido a las menores restricciones que se imponen en cuanto
a máximo tamaño de ficheros, máximo número de subdirectorios por
directorio, etc.

Los archivos de configuración a tener en cuenta son:

•/etc/exports
•/etc/hosts.allow
•/etc/hosts.deny

47
 Cliente NFS

Como prerrequisito el kernel del sistema operativo del cliente NFS debe tener
soporte para el sistema de ficheros NFS. En caso de no tenerlo es necesario
actualizar el kernel a uno que si lo tenga.

Para configurar que se monten las unidades de red NFS automáticamente

durante el arranque es necesario configurar el fichero /etc/fstab del
siguiente modo:

• En device especificamos la dirección ip seguida del directorio

compartido del servidor NFS a montar.
• En mountpoint especificamos el punto de anclaje local, es decir, en que
directorio del cliente se va a montar el directorio de la unidad de red
remota.
• El fs-type ha de ser nfs.
• En opciones especificamos que usaremos las opciones por defecto.

48
 Base de datos

El portal almacenará cierta información de naturaleza relacional en la base

de datos, como:

•Histórico de búsquedas realizadas (para su posterior explotación mediante

informes)
•Comentarios
•Información relacionada con las descargas
•Noticias
•Datos de los nodos de la federación
•Tareas planificadas
•Información sobre los Usuarios, Grupos y Roles
•Etc.

49
 MySQL

Con el fin de ilustrar una base de datos en el manual, se escoge MySQL por su
carácter de software libre y su amplia instalación en la mayor parte de las
comunidades.

Las conexiones a la base de datos se realizarán desde el servidor Apache

(ayuda MediaWiki) y desde el servidor del JBoss (portal Agrega).

50
 Servidor MySQL

Una vez instalado el servidor MySQL procedemos de la siguiente manera:

•Revisamos la configuración del fichero /etc/my.cnf .

•Arrancamos el demonio.
•Agregamos una contraseña para el usuario root.
•Nos conectamos con el usuario root al servidor MySQL.
•Creamos la base de datos para Agrega.
•Creamos el usuario agrega_user con permisos de inserción, modificación,
eliminación de registros y consulta de las tablas de la base de datos Agrega.
•Creamos la base de datos para la ayuda (Mediawiki).
•Creamos el usuario wiki_user con acceso de escritura, modificación,
borrado y consulta de las tablas de la base de datos wikidb.

51
 Base de datos: Agrega

Una vez esté creada la base de datos y el usuario agrega_user, durante la

instalación del nodo se ejecutaron los siguientes scripts SQL:

•CrearTablas.sql
El cometido del script consiste en crear toda la estructura de
tablas necesarias para el correcto funcionamiento del portal Agrega,
además de crear los índices y las contraints necesarias.

•CargarDatos.sql
Una vez creadas todas las tablas, índices y restricciones, se
procede a hacer una carga inicial de datos necesarios (idiomas, localización
de los índices, FAQs iniciales, etc).

52
 Base de datos: Ayuda

Una vez creados tanto la base de datos wikidb como el usuario wiki_user,
procedemos a insertar tanto las tablas como los contenidos de las mismas
a partir de un dump generado:

1.De nuevo, debemos ejecutar la inserción del dump con el usuario root
puesto que wiki_user no tiene permisos de creación / borrado de tablas.

2.Para comprobar que la creación del usuario y las inserciones han sido
correctas, podemos ejecutar (desde la máquina que se autorizó al crear al
usuario si tiene instalado el cliente mysql) los siguientes comandos:

mysql –u wiki_user –p –h <ip_mysql_server>

use wikidb;
show tables;

53
 Autenticación LDAP

El modo de acceso a la aplicación y a los distintos módulos funcionales se

realizará a través del navegador web utilizando los protocolos HTTP y HTTPS
para la autenticación del usuario en el portal.

El sistema pedirá un login y una clave al usuario que validará mediante la

operación Bind contra un directorio LDAP, que puede ser propio de la CCAA
o interno del nodo, en donde residirá por cada usuario un identificador
único y una clave cifradas con la función SHA-1.

Si la autenticación es correcta, el portal continuará con la carga

adquiriendo los roles de la base de datos. En caso contrario, se deniega el
login y se notifica al usuario el error.

54
Autenticación LDAP

55
 Capa de aplicación

En la capa de aplicación encontramos 3 componentes fundamentales:

•JDK 1.6: Es necesario disponer de la versión JDK 1.6 o superior para poder
ejecutar tanto el servidor de aplicaciones como la galería de imágenes.

•JBossAS: el portal Agrega se puede desplegar sobre el servidor de

aplicaciones JBoss. Modificando manualmente configuraciones y agregando
un servidor de colas JMS como Apache ActiveMQ también se podría
desplegar sobre Tomcat.

•Galería de imágenes: cada vez que se carga un ODE en la plataforma, se

genera una captura de pantalla del recurso, para ello, se hace uso de
diversas herramientas de software libre tales como ffmpeg, convert,
firefox…

56
 JDK 1.6

La versión mínima para ejecutar la plataforma es de Java 1.5, pero por

razones de rendimiento y actualizaciones se aconseja la utilización de la JDK
1.6u6 o superior. Una vez instalada es importante modificar el perfil del
usuario que arrancará el jboss configurando las siguientes variables de
entorno:

1.Se recomienda crear el enlace simbólico /opt/jdk que apunte al directorio

real donde se ha instalado la JDK con el fin de independizar las variables de
entorno de la versión de JDK instalada.

2.Editamos el /etc/profile añadiendo las dos exportaciones siguientes:

export JAVA_HOME=/opt/jdk
export PATH=$PATH:$JAVA_HOME/bin

57
 Servidor de Aplicaciones JBossAS

El portal Agrega es un desarrollo J2EE que puede ser desplegado en

cualquier contenedor de aplicaciones J2EE compatible.

Se ha seleccionado JBoss como servidor de aplicaciones por:

•Las características técnicas.

•La comunidad open source que hay en torno a JBoss.
•La estabilidad mostrada en entornos de producción.
•Las continuas mejoras y evoluciones que ha experimentado.

58
 Comprobaciones previas del sistema

• Apertura de ficheros. Se comprueba que no existe límite de apertura de

ficheros con el comando unlimit –a.

• Máximo número de sockets de red. Para comprobar el valor actual

empleamos el siguiente comando: sysctl -a |grep -i somaxconn

• Usuario y grupo JBoss. Se recomienda que el proceso de JBossAS sea

lanzado por un usuario con permisos adecuados, así se garantiza que el
usuario pueda escribir en los diferentes directorios necesarios para el
correcto funcionamiento del portal.

59
 Scripts de arranque

1. run.conf
Existe un fichero denominado run.conf que contiene los parámetros a
pasar a la máquina virtual de Java (JVM) para el arranque del JBoss.

2. /etc/init.d/jboss y run.sh
Al realizar la instalación, en los sistemas Linux, en el directorio bin se
encuentra el fichero “jboss_init_redhat.sh”, fichero que se suele copiar
al directorio /etc/init.d/ para el arranque y parada del servidor.

60
 Ficheros de configuración de JBoss

Los ficheros más relevantes para la correcta configuración de la plataforma

Agrega se establecen del siguiente modo:

1.Configuración de los conectores de JBoss: HTTP y AJP.

2.Datasources.
3.Colas JMS.
4.Alias en directorios.
5.Redirección tráfico 8080.

61
 Librerías del JBoss

JBoss tiene dos directorios de librerías:

1.$JBOSS_HOME\lib
En el directorio lib contiene los JARs necesario para el set up del
arranque del JBoss.

2. $JBOSS_HOME\server\default\delpoy\lib
Todos los ficheros JAR del directorio se cargarán por JBoss en el
classpath compartido por todos los módulos (WARs).

62
 Directorio de informes

El directorio de informes almacena en su interior los siguientes directorios:

1.birt-runtime-2_2_1_1
Para la generación de informes online la plataforma hace uso de Birt.
Los binarios del sistema de reportes Birt se almacenan ahí.

2. destinoInformesDir
Los informes planificados desde el planificador se almacenarán en esta
carpeta.

3. plantillasInformes
Las plantillas a partir de las cuales Birt genera los informes se
encuentran en esta carpeta.

63
 Directorio de índices

En el directorio se almacenan los índices generados por Lucene para los

diferentes idiomas, existiendo un índice por cada idioma en los que se
encuentra disponible la plataforma.

Al encontrarse la aplicación disponible en 6 idiomas aparecen 6 índices

(subdirectorios dentro de $JBOSS_HOME/indices):

Idioma Subdirectorio índices

Catalán ca_CA_simple.id

Inglés en_EN_simple.id

Español es_ES_simple.id

Euskera eu_EU_simple.id

Gallego gl_GL_simple.id

Valenciano va_VA_simple.id

64
 Directorio de uploads

El directorio de uploads es el directorio donde se almacenarán los ficheros

necesarios para la plataforma y los ficheros que se irán generando a medida
que se use la plataforma.

El tamaño de este directorio será elevado y variará en función de:

1.Los ODEs creados en el taller.

2.Los ODEs publicados (tamaño y número) en el repositorio.
3.Las descargas disponibles desde la plataforma.

65
 Ejemplo de la estructura de subdirectorios

descargas
galeriaimg/common (contiene los iconos de las imágenes por defecto)
galeriaimg/<sitio> (se generarán las previsualizaciones de los ODEs)
html (con contenido inicial)
imagenesInformes
informesPortada
modificador
noticias
repositorio
rss
schemas (con contenido inicial)
schemasImscp (con contenido inicial)
schemasScorm12 (con contenido inicial)
schemasVdex (con contenido inicial)
searchPlugin (con contenido inicial)
sitemaps/backup
sitemaps/estatico (con contenido inicial)
taller
utilidades (con contenido inicial)
xmls (con contenido inicial)
xslt (con contenido inicial)

66
 Ficheros de configuración de Agrega

En el directorio $JBOSS_HOME/server/default/conf encontramos los archivos

de configuración del JBoss y del portal Agrega. En concreto, los ficheros de
configuración de Agrega son:

agrega.properties
authbackend.properties
cas.properties
dependentServer_EN.properties
dependentServer.properties
generacionContenidos.properties
i18n_ca.properties
i18n_en.properties
i18n_es.properties
i18n_eu.properties
i18n_gl.properties
i18n.properties
i18n_va.properties
importedServices.properties
log4j.xml
springldap.xml
67
 Despliegue del aplicativo: WARs

Tanto los servicios como los módulos web se deben desplegar en el directorio
$JBOSS_HOME/server/default/deploy/agrega/

Para desplegar un módulo, sobreescribiendo uno actual, podemos realizar la

tarea de dos maneras:

1.Copiamos el WAR en caliente (hot deploy): sin parar el servidor de

aplicaciones JBoss, después de haber realizado un backup del war, copiamos
el nuevo sobre el viejo, produciéndose las tareas de undeploy y dedeploy del
módulo.

2.Copiamos el WAR habiendo parado el JBoss: una vez detenido el servicio

del JBoss, procedemos a sobrescribir el WAR, borrar los directorios
temporales citados anteriormente y arrancamos de nuevo el servicio.

68
 Galería de imágenes

La galería de imágenes se invoca desde el módulo publicador a través del

protocolo RMI tal y como se muestra en la siguiente figura:

69
 Scripts ejecutados

Existen dos scripts que pueden ser ejecutados:

1.resizeimg.sh
Si la aplicación de antemano conoce que el recurso es una imagen,
invocará directamente al script resizeimg.sh.

2. generateimg.sh
Si se da el caso contrario, se ejecuta el script generateimg.sh.

70
 Software requerido

El software necesario para que funcionen los scripts anteriores es:

•awk
•Xvfb
•ImageMagick
•FFmpeg
•Xfonts-100dpi
•Xfonts-75dpi
•Xfonts-base
•Plugin de flash para el mozilla-firefox

71
 Capa de servidor web

En la capa del servicio web podemos distinguir al menos 3 componentes

fundamentales:

•Servidor web: con el fin de atender todas las peticiones y los componentes
estáticos tales como imágenes, CSS, JS, disponemos de un servidor web
Apache 2.X instalado.

•Ayuda Mediawiki: la ayuda se basa en el popular software libre Mediawiki. Se

trata de una aplicación PHP disjunta del portal instalada directamente sobre
Apache.

•Proxy cache: para aquellos contenidos que sean susceptibles de ser

almacenados en caché tales como imágenes, CSS, JS, e incluso algunos
contenidos (ODEs) solicitados muy a menudo, se propone el uso de un Proxy
cache como Squid.

72
 Apache 2

Dada la naturaleza de software libre y el presente uso en la mayoría de las

CCAA, se ha escogido Apache 2.x como servidor web.

Podemos ver gráficamente las conexiones al Apache en la siguiente figura:

73
 Ficheros de configuración

httpd.conf

•Se habilitan las conexiones persistentes.

•Se indica el número de clientes soportados por CPU.
•Se cargan los módulos mod_deflate, mod_alias.so, mod_rewrite.so y
mod_jk.so.

74
 Ficheros de configuración

worker.properties

Define las conexiones entre el Apache y el servidor de aplicaciones JBoss.

worker.list=<nodo>
worker.<nodo>.host=<ip_jboss>
worker.<nodo>.type=ajp13
worker.<nodo>.port=8009
worker.<nodo>.connect_timeout=10000
worker.<nodo>.prepost_timeout=10000
worker.<nodo>.socket_timeout=10
#This value must equal server.xml's connectionTimeout of 10 minutes
worker.<nodo>.connection_pool_timeout=600

75
 Ficheros de configuración

vhost

•Se crea un virtual host diferente en cada CCAA.

•Se indica el puerto 80 para recibir todas las direcciones IP. Se
especifica el DocumentRoot, el ServerName y el ServerAlias.
•Se definen los alias para el contenido estático del portal, los ficheros
de logs, las wikis internacionalizadas y para los subdirectorios del
directorio “uploads”.
•Se definen los directorios de contenidos estáticos, uploads y wikis.
•Se definen un conjunto de RewriteRules para facilitar las URLs y su
almacenamiento en favoritos en sistemas externos.
•Se definen los módulos que se conectan al JBoss.
•Se define un virtual host asociado al módulo de autenticación y otro
mediante protocolo seguro.

76
 Ayuda MediaWiki

La ayuda de la plataforma Agrega hace uso de la aplicación basada en

software libre MediaWiki. La aplicación MediaWiki 1.12.0 se ejecuta durante
el proceso de instalación del nodo. Para el correcto funcionamiento,
requiere PHP 5 o superior y la conexión a una base de datos.

Se trata de una aplicación disjunta del portal con una base de datos
diferente a la del portal, en la que no se comparte directamente la
información entre ambas aplicaciones.

77
 Proceso de instalación

• Descomprimir binarios en directorio /export/wiki.

• Crear una nueva entrada para la wiki y volcar la información desde

wikidb.sql.

• Crear usuario con todos los permisos excepto el de modificación de

esquemas.

78
 Ficheros de configuración

1. /export/wiki/LocalSettings.php: almacena la configuración de la wiki.

2. vhost especificado en Apache: se debe definir tanto el Alias como el

Directorio donde se encuentre instalada la MediaWiki con permisos de
ejecución php.

79
 Proxy cache. Squid

En algunas ocasiones, puede ser conveniente instalar un Proxy caché

intermedio para almacenar aquellas peticiones que se repitan muchas veces
a lo largo del tiempo. Las respuestas del portal HTTP se encuentran bien
formadas y permiten su almacenamiento tanto en la caché del navegador
como en las caches intermedias existentes.

Un usuario posee una cache de navegación habilitada para no volver a pedir

aquellos ficheros que no se han modificado desde la última vez que se
solicitaron, se conecta a través de un proveedor de servicios de Internet
(ISP), que suele disponer de pooles de cache bastante extensos con el fin de
limitar el tráfico saliente de su red hacia Internet.

80
Proxy cache. Squid

81
 Configuración Squid

En función de número de conexiones simultáneas y descargas que tengamos en

la CCAA, podría ser necesario habilitar SQUID como Proxy transparente
cacheando los contenidos devueltos por el portal para evitar que las peticiones
lleguen hasta Apache o incluso al propio JBossAS. Para ello, si se ha instalado
Squid 3 el fichero de configuración es el siguiente:

•/etc/squid3/squid.conf: se especifican los puertos para recibir peticiones http

y enviar consultas a la caché, los servidores DNS, donde situar la caché de
Squid y sus logs, los controles de acceso a equipo, etc.

82
 Módulo 4. Administración

• Desde este apartado se lleva a cabo la planificación de una serie de tareas

con el fin de ejecutarlas o administrarlas posteriormente en la
plataforma.

• Este módulo se compone de:

– Contenidos
– Plataforma
– Configuración

83
 Contenidos

• Consta de:

– Noticias: permite crear nuevas noticias o modificar las ya existentes.

– Descargas: permite crear, modificar o eliminar las descargas. Éstas
pueden estar:
• Activadas
• Desactivadas
– Preguntas frecuentes: permite crear, modificar o eliminar preguntas
frecuentes o FAQ´s.

84
 Agrega off line

• Aplicación de escritorio que facilita las funciones básicas de creación,

previsualización y validación de contenidos SCORM 2004,
implementadas en los nodos de Agrega, sin necesidad de contar con una
conexión a Internet.

85
 Agrega off line

• Requisitos de la herramienta off-line:

1. Requisitos hardware:
– 200 MB de espacio libre en disco duro.
– 1 GB de memoria RAM.

2. Requisitos software:
– Máquina virtual de Java (JRE) 1.5 o superior.
– Navegador Web (recomendados Internet Explorer 5+ y Firefox 2+).

86
 Agrega off line

• Proceso de instalación

– Para instalar las herramientas Agrega, simplemente debes ejecutar el

instalador y seguir las instrucciones que aparecen en la pantalla.

– Recuerda que debes instalar las herramientas en una carpeta cuyo

nombre no tenga espacios, por ejemplo:

• C:\Aplicaciones\Agrega -> Correcto

• C:\Archivos de Programa\Agr -> Error

87
Proceso de instalación

88
 Herramientas Agrega off line

• Para utilizar las herramientas Agrega en tu PC, ve al menú Inicio ->

Programas -> Agrega, y ejecuta Iniciar Servidor. Este enlace iniciará la
aplicación que contiene las herramientas. El proceso puede ser lento.

• El servidor estará listo para funcionar cuando aparezcan estos mensajes:

– 17:24:37,567 INFO [Catalina] Initialization processed in 1078 ms

– 17:24:55,143 INFO [Catalina] Server start-up in 17576 ms

89
 Herramientas Agrega off line

• Una vez se ha iniciado el servidor, ve a Inicio -> Programas -> Agrega, y

ejecuta Herramientas–Agrega. Se abrirá entonces el navegador Web por
defecto con la pantalla principal de las herramientas Agrega:

90
 Herramientas Agrega off line

• Las opciones disponibles son:

– Crear ODE
– Abrir ODE
– Visualizar ODE
– Validar ODE
– Herramienta de modificación
– Configurar datos de usuario:
• Datos personales
• Tipo de empaquetador/catalogador (básico o avanzado)
• Idioma

91
 Crear un ODE en off line

Haz clic en la imagen para ver el vídeo

92
Validar y publicar un ODE en off line avanzado

Haz clic en la imagen para ver el vídeo

93
 Plataforma

• Este módulo se compone de los siguientes elementos:

– Nodo
– Usuarios
– Logs
– Informes
– Planificador
– Modificador
– Monitorizador
– Grupos de usuarios
– Taxonomías y Tesauros

94
 Nodos

• Se encarga de administrar los nodos que cada comunidad tiene para

conectarse a la aplicación.

• Para crear un nodo deben rellenarse los siguientes campos:

– Nodo: nombre explicativo para reconocer el nodo.

– Url Nodo: url donde se encuentra el nodo.
– Url Web Service: url donde se encuentran los servicios del nodo.
– Puerto: puerto por el que se comunica el nodo.
– Comunidad Autónoma: nombre de la Comunidad Autónoma a la que
corresponde el nodo.

• Además, los nodos pueden modificarse o eliminarse.

95
 Usuarios

• Permite la gestión y el mantenimiento de los usuarios en la plataforma.

Esta aplicación tiene las siguientes funcionalidades:

– Listar usuarios.
– Crear usuarios.
– Modificar usuarios.
– Describir usuarios.
– Eliminar usuarios.
– Listar usuarios inactivos.

96
 Informes

• Muestra una lista con los informes creados desde el planificador. Desde
esta pantalla se puede:

– Crear informes. Éstos se dividen en:

• Informe de Fechas.
• Informe de rango.
• Informe de usuario.

– Eliminar informes.

97
 Informes

Haz clic en la imagen para ver el vídeo

98
 Planificador

• Se encarga de las tareas utilizadas para el mantenimiento del portal, tales

como la carga de ODEs, reindexado, eliminar ODEs, generar tareas de
informes, etc.

• Se compone de tres pantallas:

– Pendientes
– Ejecutándose
– Ejecutadas

99
 Pendientes

• Muestra un listado con todas las tareas pendientes de ser ejecutadas.

Desde esta pantalla se puede:

– Crear tarea. Tipos:

• Carga de ODEs
• Reindexado
• Eliminar ODEs
• Informe de fechas
• Informe de rango
• Informe de usuario

– Eliminar tarea.
– Ejecutar tarea.

100
 Modificador

• Permite configurar tareas para la modificación en bloque de ODEs

múltiples.

• Los cambios que la herramienta permite realizar en la catalogación de

los ODEs serán de los siguientes tipos:

– Añadir Término LOM-ES

– Eliminar Término LOM-ES
– Comprobar Término LOM-ES
– Modificar término LOM-ES
– Validación

• Además, la herramienta proporciona un código HTML para la

configuración de tareas.

101
 Taxonomías y Tesauros

• Esta opción permite administrar las diferentes estructuras de la

plataforma: árboles curriculares, taxonomías y tesauros.

• Para añadir a la aplicación cualquiera de estas estructuras, deben

cumplirse los siguientes requisitos:

– Ser un archivo un XML con formato VDEX.

– Debe validar contra el VDEX de la estructura.
– El nombre del fichero debe acabar en _idioma, donde el idioma
debe ser un código ISO, por ejemplo: _en (inglés); _es (español);
_ca (catalán); _eu (euskera), etc.

102
 Configuración

• Se compone de los siguientes apartados:

– Publicador: se encarga de administrar los ODEs publicados y los

despublicados. Los publicados se pueden rechazar o publicar;
mientras que los despublicados se pueden eliminar o volver a
publicar. Para publicar un ODE es necesario ser un usuario con rol
de publicador.

103
 Configuración

– Catalogador: se encarga de administrar los ODES pendientes de

catalogación. Los ODEs se pueden proponer para su publicación o
modificación. Para publicar un ODE, hay que tener el rol de
publicador; y para modificarlo (Modificar), el de empaquetador.

104
 Proponer y publicar

Haz clic en la imagen para ver el vídeo

105
 Módulo 5. Operación

Asumiendo la instalación de la plataforma Agrega en sistemas operativos

Linux, vamos a ver los comandos, ficheros, logs… necesarios para la
operación y mantenimiento de la plataforma.

•Arranque y parada de los aplicativos.

•Ficheros de Log.
•Backups.
•Modificaciones frente a cambios frecuentes.
•Tareas planificadas.
•Generación automática de ficheros.
•Seguridad.
•Actualización MediaWiki.

106
 Arranque y parada de los aplicativos

JBoss. Arranque y parada

Arranque:
/etc/init.d/jboss start

Parada:
/etc/init.d/jboss stop

Para comprobar si se encuentra el JBoss arrancado podemos ejecutar el

comando:
ps auxww | grep –i java

107
 Arranque y parada de los aplicativos

JBoss. Eliminación despliegues anteriores

Si vamos a actualizar la versión de Agrega, es conveniente limpiar

previamente todos los despliegues anteriores (tanto clases como JSPs)
mediante los siguientes pasos:

1.Paramos el servidor de aplicaciones JBoss.

2.Borramos el contenido del directorio:
$JBOSS_HOME/server/default/tmp/deploy/
3. Borramos el contenido del directorio:
$JBOSS_HOME/server/default/work/jboss.web/localhost/
4. Desplegamos los nuevos WARS, properties, etc.
5. Arrancamos el servidor de aplicaciones JBoss.

108
 Arranque y parada de los aplicativos
Servidor Web Apache

Arranque:
/etc/init.d/httpd start

Parada:
/etc/init.d/httpd stop

Recarga en caliente de la configuración sin pérdida de servicio:

/etc/init.d/httpd graceful

Para comprobar si se encuentra Apache arrancado podemos ejecutar el

comando:
ps auxww | grep –i httpd

Obteniéndose una salida similar a la siguiente:

apache 28745 0.0 0.9 28780 9368 ? S 09:54 0:00
/usr/sbin/httpd
apache 849 0.0 1.7 36688 18288 ? S 10:54 0:00
/usr/sbin/httpd
109
 Arranque y parada de los aplicativos

MySQL

Arranque:
/etc/init.d/mysql start

Parada:
/etc/init.d/mysql stop

Para comprobar si se encuentra el servicio de base de datos MySQL arrancado

podemos ejecutar el comando:
ps auxww | grep –i mysqld

Obteniéndose una salida similar a la siguiente:

mysql 2754 2.5 11.9 2412144 311028 ? Sl Sep29 24:31
/usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql
--pid-file=/var/lib/mysql/database.agrega.indra.es.pid --skip-
external-locking --port=3306 --socket=/var/lib/mysql/mysql.sock

110
 Arranque y parada de los aplicativos

LDAP

Arranque:
/etc/init.d/ldap start

Parada:
/etc/init.d/ldap stop

Para comprobar si se encuentra el servicio de directorio LDAP arrancado

podemos ejecutar el comando:
ps auxww | grep –i slapd

Obteniéndose una salida similar a la siguiente:

ldap 29512 0.0 0.3 27660 3736 ? Ssl Sep28 0:00
/usr/sbin/slapd -u ldap -h ldap:/// -s 9

111
 Arranque y parada de los aplicativos

Servidor NFS

Arranque:
/etc/init.d/nfs start

Parada:
/etc/init.d/nfs stop

Para comprobar si se encuentra el servicio de exportación NFS arrancado

podemos ejecutar el comando:
ps auxww | grep –i nfsd

Obteniéndose una salida similar a la siguiente:

root 2925 0.1 0.0 0 0 ? S Mar04 350:01
[nfsd]
root 2926 0.1 0.0 0 0 ? S Mar04 349:45
[nfsd]

112
 Ficheros de Log

JBoss

Por defecto los logs se almacenan en $JBOSS_HOME/server/default/log.

En el fichero $JBOSS_HOME/server/default/conf/log4j.xml definimos los
appenders con la ubicación y la política de rotado.

<appender name="FILE"
class="org.jboss.logging.appender.DailyRollingFileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="File" value="${jboss.server.log.dir}/server.log"/>
<param name="Append" value="true"/>

<!-- Rollover at midnight each day -->

<param name="DatePattern" value="'.'yyyy-MM-dd"/>

113
 Ficheros de Log

Apache

Una vez confirmado que se encuentra presente el módulo en la

configuración de Apache (httpd.conf) LoadModule log_config_module
modules/mod_log_config.so, en cada fichero de configuración del virtual
host especificamos tanto el formato de log a emplear como el fichero
donde almacenarlo.

LogFormat "%h %l %u %t \"%r\" %>s %b" extendedlog

CustomLog logs/<sitio>_access.log extendedlog
ErrorLog logs/<sitio>_error.log

114
 Ficheros de Log

MySQL

Si en el fichero de configuración my.cnf se ha habilitado la opción “log-bin”

se podrán auditar posteriormente los logs en /var/lib/mysql/.

Por defecto, existirá un log de error asociado a la base de datos Agrega, y si

se ha habilitado la opción de los logs binarios, existirán diversos ficheros
/var/lib/mysql/mysql-bin.000XYZ.

Para poder visualizar el contenido de los ficheros, es necesario hacer uso de

la aplicación mysqlbinlog proporcionada junto a la BD. La sintaxis es:

mysqlbinlog log_file

115
 Ficheros de Log

LDAP

En el archivo slapd.conf se especifica el nivel de registro de los logs

mediante el parámetro loglevel. Para especificar el fichero donde almacenar
los logs es necesario saber que OpenLDAP por defecto envía su información
de registro al demonio del sistema syslog (syslogd) bajo el canal LOCAL4.
Para poder almacenar la información en un fichero que nosotros
especifiquemos es necesario modificar el archivo /etc/syslog.conf,
agregando una línea como la siguiente:

local4.* /var/log/openldap

116
 Backups

Bases de datos

Tanto en el caso de actualizaciones de Agrega que afecten a base de datos

como cada cierto período de tiempo es conveniente realizar una backup de
la base de datos.

Los backups podrían ser deltas o completos. En función de la base de datos

existirán unos u otros procedimientos aconsejados.

En el caso de la instalación de Agrega sobre una base de datos MySQL, para

realizar un backup completo de la BD se aconseja el siguiente
procedimiento:

mysqldump --opt -c -e -Q –h $HOST --hex-blob -u usuario -

ppassword $DBNAME > $BACKUP_DIR/$DATABASE-dump-$FECHA.sql

117
 Backups

OpenLDAP

En el caso de haber instalado OpenLDAP, existen varias alternativas para

hacer el backup del contenido del mismo. Para asegurar la consistencia del
ldif generado, es necesario parar el servicio de LDAP previamente.

Si se está empleando bdb, el comando sería:

/usr/sbin/slapcat -v -l $BACKUP_DIR/ldap.ldif

Si se esta usando lbdm:

/usr/sbin/ldbmcat -n /var/lib/ldap/id2entry.gdbm >
BACKUP$DIR/ldap.ldif

118
 Backups

Módulos WAR

La mayor parte de las actualizaciones de Agrega llevarán asociadas la

modificación de uno o más módulos WAR de la plataforma. Por ello, se
recomienda hacer un backup del directorio
$JBOSS_HOME/server/default/deploy/agrega.

Es conveniente destacar que los módulos WAR se encuentran en formato ZIP,

por lo que intentar aplicar cualquier algoritmo de compresión apenas reducirá
el espacio.

119
 Backups

Índices

Un componente fundamental de la plataforma son los índices. Las políticas

de backup sugeridas son:

•Es altamente recomendable hacer un backup de los índices todos los días, a
una hora en la que no existan operaciones pendientes en disco tales como
carga de ODEs, generación de informes, etc.
•Cada vez que se haga una parada y arranque de la aplicación para efectuar
alguna migración o actualización, es obligatorio salvaguardar la información
de los índices una vez que el servidor de aplicaciones se encuentra parado.

120
 Backups

Informes

El directorio $JBOSS_HOME/informes es susceptible de ser salvaguardado. En

algunas ocasiones, las actualizaciones de Agrega conllevarán la modificación de
algunas plantillas que se emplean en la elaboración de los informes y cuya
ubicación es $JBOSS_HOME/informes/plantillasInformes.

121
 Backups

Ficheros de configuración del portal

Debido a que los ficheros de configuración del portal contienen información

tal como la dirección IP del servidor de LDAP, la IP del servidor de base de
datos, periodicidad de la generación de informes, etc., no sólo en cada
actualización de Agrega se modificarán los ficheros de configuración del
portal, sino también en cada modificación que la comunidad realice sobre los
elementos de la infraestructura.

Por todo ello, es conveniente hacer backups antes de realizar cualquier

modificación en los ficheros del portal.

122
 Backups

Estáticos

En los procesos de actualización de la plataforma se actualizarán los ficheros

estáticos (CSS, JS, JPG…) siendo necesario la realización de un backup previo
a la actualización.

El directorio a salvaguardar será aquel especificado en el alias del virtual

host de Apache.

123
 Backups

Programación de backups en CRON

Una vez completados los “scripts” de backups, editamos el fichero crontab

para añadir nuestras tareas. Ejecutamos el comando crontab –e

# Ejecuta un script que realiza un backup de la base de datos el primer día de cada
mes a las 22:00
0 22 1 * * /home/backup/script_bd.sh
# Más ejemplos
0 2 * * 1-6 sh /raid/Backups_Data/pruebas/MyBackup.sh Diario
0 2 * * 0 sh /raid/Backups_Data/pruebas/MyBackup.sh Semanal
0 2 1 * * sh /raid/Backups_Data/pruebas/MyBackup.sh Mensual

124
 Modificaciones frente a cambios frecuentes

Modificación de la base de datos del portal Agrega

1.Modificación de la dirección IP. Aunque normalmente la dirección

especificada de la BD suele ser un alias, en caso de haberse especificado
manualmente implicaría cambiar el fichero donde se definen los
datasources: $JBOSS_HOME/server/default/deploy/<nodo>-ds.xml

2.Modificación de usuario/contraseña. Por cada datasource definido en el

fichero $JBOSS_HOME/server/default/deploy/<nodo>-ds.xml deberá ser
revisada la configuración de acceso.

125
 Modificaciones frente a cambios frecuentes

Modificación de la base de datos de MediaWiki

En caso de modificarse alguno de los parámetros de acceso a la base de

datos que contiene la ayuda MediaWiki, será necesario revisar el fichero
LocalSettings.php y modificar los parámetros que correspondan:

$wgDBserver = "localhost";
$wgDBname = "db";
$wgDBuser = "user";
$wgDBpassword = "pass";

126
 Modificaciones frente a cambios frecuentes

Cambio de datos de conexión al LDAP

Los datos de la conexión a LDAP se especifican en dos ficheros de

configuración:

$JBOSS_HOME/server/default/conf/authbackend.properties
$JBOSS_HOME/server/default/conf/springldap.xml

127
 Modificaciones frente a cambios frecuentes

Cambio de IP del JBoss

En el caso de cambiar la IP del servidor JBoss, si siempre se ha hecho

referencia al alias definido en el /etc/hosts no será necesario realizar
ninguna modificación (salvo la actualización en el hosts). En caso contrario,
será necesario revisar el fichero:
/etc/httpd/conf/workers.properties

Cambio de IP de Apache

En caso de haber cambiado la IP del servidor web Apache, será necesario

tenerlo en cuenta en el fichero /etc/hosts del servidor JBoss.

128
 Tareas planificadas

La plataforma dispone de un planificador de tareas basado en Quartz. El

planificador permite programar tareas de mantenimiento como:

1.Carga de ODEs: Permite cargar al repositorio nuevos objetos educativos.

2.Reindexado: Borra los índices del nodo para rehacerlos.
3.Eliminar ODEs: Lanza un borrado de objetos del repositorio.
4.Generación de informes: Genera de forma programada un informe del
tipo especificado.

129
 Tareas planificadas

Parámetros de configuración del planificador

Las tareas de informes del planificador usan una serie de parámetros de

configuración contenidos en el fichero
$JBOSS_HOME/server/default/conf/agrega.properties. Estas propiedades
permiten definir los directorios donde se almacenan los informes y los
nombres de los ficheros asociados a cada tipo de informe.

130
 Tareas planificadas

Tareas

A continuación se describen los tipos de tareas disponibles en la versión

1.0.3 de Agrega y lo recursos utilizados por dichas tareas en el servidor.

1.Carga de ODEs.
2.Reindexado.
3.Eliminación de ODEs.
4.Informes.

131
 Generación automática de ficheros

Informes de portada

Tarea automática de generación de los informes de la portada pública de

Agrega.

Los informes generados recogen información de los contenidos digitales

educativos que más veces se ha mostrado su ficha de búsqueda, los que
más veces han sido previsualizados, descargados, los ODEs más valorados o
los términos más buscados.

Este proceso es lanzado por la plataforma todos los días a las cuatro de la
mañana y por defecto genera unos ficheros con la información del día
anterior y otros con la información de los siete días anteriores.

132
 Generación automática de ficheros

Ficheros sitemap

Tarea de generación de los ficheros de sitemaps que serán utilizados por

Google para indexar los contenidos de la plataforma Agrega.

Por defecto se lanza todos los días a la una de la mañana. Estos dos valores
junto con el número de entradas que tendrá cada fichero sitemap y el
nombre de los ficheros se pueden modificar en el fichero
generacionContenidos.properties.

133
 Generación automática de ficheros

Captura de ODE aleatorio

Esta tarea programada genera el contenido dinámico de la plataforma, es

decir, realiza la selección de una captura de un ODE aleatoriamente.

Por defecto se lanza todos los días cada hora. Tanto la periodicidad como la
hora en la que se lanza son valores configurables dentro del fichero
generacionContenidos.properties.

134
 Generación automática de ficheros

Generación de catálogo

Tarea de generación automática del catálogo de contenidos de Agrega

con todos los contenidos digitales educativos con nivel de agregación
mayor o igual que tres.

Por defecto esta tarea se lanza una vez al mes a las cinco de la mañana.
El fichero resultante con el catálogo se almacena en el directorio
referenciado por el atributo destinoInformesDir del fichero
agrega.properties.

135
 Generación automática de ficheros

Generación de RSS

Esta tarea genera los ficheros rss con las últimas diez noticias, los últimos
diez ODEs publicados y los contenidos digitales educativos más descargados,
más previsualizados y más mostrados en la última semana, en el último mes
y el último año.

Por defecto se lanza todos los días a las dos de la mañana. Los ficheros
generados se almacenan en el directorio referenciado por el atributo
rss.path del fichero agrega.properties.

136
 Módulo 6. Integración

Para añadir valor a los objetos almacenados en la plataforma Agrega,

potenciar su distribución y facilitar su acceso, se definen dentro de la
comunidad educativa una serie de estándares, normas y protocolos que se
orientan a la facilitación de los contenidos.

•WebServices publicados
•OAI-PMH
•Gestor de sesiones
•SQI
•DRI

137
 Webservices publicados

Buscar

Buscar es el módulo de Agrega que ejecuta las búsquedas en el repositorio y

se encarga de aunar y cachear los resultados en el caso de realizar búsquedas
federadas. Depende del buscador, que es el módulo que trabaja con el
índice.

Desde esta funcionalidad se permite buscar conociendo el identificador del

ODE y el idioma en el que esta catalogado:

•solicitarMetadato: busca en el repositorio por el idioma de catalogación la

ficha del ODE.
•buscarAvanzado: permite la realización de búsquedas.

138
 Webservices publicados

Entregar

La plataforma AGREGA cumple con la especificación SCORM 2004, gracias a

la que se hace posible la creación de contenidos que puedan importarse
dentro de sistemas de gestión de aprendizaje diferentes.

Los principales requerimientos que el modelo SCORM trata de satisfacer son:

•Accesibilidad.
•Adaptabilidad.
•Durabilidad.
•Interoperabilidad.
•Reusabilidad.

De acuerdo con estos requerimientos, el módulo Entregar permite el

intercambio de ODEs del repositorio de la plataforma y la reutilización por
plataformas que soportan modelos anteriores, como SCORM 1.2 o IMS-CP.

139
 OAI-PMH

OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) se

define como un protocolo para la transmisión de metadatos a través de
Internet. En este protocolo participan dos tipos de agentes:

•Proveedores de datos: exponen públicamente sus metadatos codificados en

Dublín Core en un fichero xml.

•Proveedores de servicios: realizan servicios de búsqueda para recopilar

(harvesting) los metadatos de un proveedor.

Desde la plataforma Agrega se ofrece la posibilidad de integración con su

repositorio a través del protocolo OAI-PMH actuando como proveedora de
datos.

140
 OAI-PMH

Identify

Argumentos:
verb: Obligatorio. Se pasará la operación que se quiere realizar en este caso
Identify.

Formato de llamada:
La manera de obtener información sobre el repositorio es mediante una
llamada HTTP al método Identify del repositorio:

http://urlRepositorioAgrega?verb=Identify

Formato de salida:
Como respuesta el Agrega devolverá un XML codificado en UTF-8 con toda la
información del repositorio.

141
 OAI-PMH

ListMetadataFormats

Argumentos:

verb: Obligatorio. Operación que se quiere realizar en este caso

ListMetadataFormats.
Identifier: Optativo. En el caso de añadir este parámetro se devolverían
únicamente los tipos de metadatos en los que esta disponible el objeto del
repositorio cuyo identificador se pasa.

Formato de llamada:

http://urlRepositorioAgrega?verb=ListMetadataFormats

Formato de salida:

Como resultado se obtendrá un xml con los tipos de metadatos.

142
 OAI-PMH

ListSets

Argumentos:

verb: Obligatorio. Operación que se quiere realizar en este caso ListSets.

resumptionToken: Optativo. Token necesario para el control de flujo. Este
atributo será utilizado por más métodos del protocolo para permitir el
paginado de la respuesta.

Formato de llamada:

http://urlRepositorioAgrega?verb=ListSets

Formato de salida:

Como resultado se obtendrá un xml con los conjuntos.

143
 OAI-PMH

ListIdentifiers

Argumentos:

verb: Obligatorio. Operación que se quiere realizar en este caso ListIdentifiers.

from: Opcional. Fecha a partir de la cual se quiere obtener la lista selectiva de
identificadores.
until: Opcional. Fecha hasta la cual se quiere obtener la lista selectiva de identificadores.
metadataPrefix: Obligatorio. Tipo de metadato que deben soportar los identificadores. En el
caso de la plataforma Agrega será oai_dc (Dublín Core) ya que es el único tipo de metadato
soportado.
Set: Opcional. Identificador del conjunto.
resumptionToken: Opcional. Token necesario para el control de flujo.

Formato de llamada:
http://urlRepositorioAgrega?verb=ListIdentifiers&metadataPrefix=oai_d

Formato de salida:

Como resultado se obtendrá un xml con la lista de los identificadores.

144
 OAI-PMH

GetRecord

Argumentos:

verb: Obligatorio. Se pasará la operación que se quiere realizar en este caso

GetRecord.
identifier: Obligatorio. Identificador del registro del que se quiere obtener
la información.
metadataPrefix: Obligatorio. Tipo de metadato. Como se ha comentado
anteriormente la plataforma Agrega únicamente soporta oai_dc.

Formato de llamada:

http://urlRepositorioAgrega?verb=GetRecord&metadataPrefix=oai_dc
&identifier=identificadorRegistro

Formato de salida:

Como resultado se obtendrá un xml con la información del registro.

145
 OAI-PMH

ListRecords

Argumentos:

verb: Obligatorio. Operación que se quiere realizar en este caso ListRecords.

from: Opcional. Fecha a partir de la cual se quiere obtener la lista selectiva de
registros.
until: Opcional. Fecha hasta la cual se quiere obtener la lista selectiva de registros.
metadataPrefix: Obligatorio. Tipo de metadato que deben soportar los registros. En el
caso de la plataforma agrega será oai_dc (Dublín Core).
Set: Opcional. Identificador del conjunto.
resumptionToken: Opcional. Token necesario para el control de flujo.

Formato de llamada:

http://urlRepositorioAgrega?verb=ListRecords&metadataPrefix=oai_dc

Formato de salida:

Devuelve un xml con los registros del repositorio.

146
 OAI-PMH

Mensajes de error

A continuación, se detallan algunos de los mensajes de error que puede

devolver el repositorio Agrega. Al igual que ocurre con las respuestas
correctas éstos serán xml codificados en UTF-8.

•BadVerb.
•BadArgument.
•CannotDisseminateFormat.
•idDoesNotExist.

147
 Gestor de sesiones

El gestor de sesiones es un módulo de Agrega que permite a los servicios

externos interaccionar con los módulos ofrecidos a través del interfaz Web
Service donde se requiere un identificador de sesión.

Desde la funcionalidad del gestor de sesiones se implementan funcionalidades

básicas como son:

•crear sesión: crear una sesión válida dentro del sistema.

•crear sesión anónima: crear una sesión anónima dentro de sistema.
•eliminar sesión: eliminar una sesión válida dentro del sistema.

148
 Gestor de sesiones

Integración a través de WebServices

Se describen los métodos implementados en el API del gestor de sesiones así

como la descripción de los parámetros necesarios para su correcta invocación,
los tipos de información devuelta y los errores posibles.

•createSession.
•createAnonymousSession.
•destroySession.

149
 Gestor de sesiones

createSession

El método tiene el siguiente aspecto:

CreateSession (String userId, String password) throws Exception

Este método requiere como parámetros un identificador de usuario y la clave

asociada al mismo. Tanto el usuario como la clave deben estar dados de alta
en la plataforma para tener acceso a un identificador válido. En el caso de
que esto sea así, el método devuelve un identificador de sesión válido con el
que poder interaccionar con la plataforma.

150
 Gestor de sesiones

createAnonymousSession

El método tiene el siguiente aspecto:

CreateAnonymousSession () throws Exception

Este método no requiere parámetros y devuelve un identificador de sesión

válido con el que poder interaccionar con la plataforma.

151
 Gestor de sesiones

destroySession

El método tiene el siguiente aspecto:

DestroySession (String sessionID) throws Exception

Este método toma como parámetro el identificador de la sesión que se quiere

eliminar. El resultado de esta operación es la eliminación del sistema de
gestión de sesiones de la sesión a la que corresponde el identificador.

152
 SQI

Se trata de una especificación que define una capa para facilitar las búsquedas.
Especifica un estándar para resolver la problemática de las búsquedas de
contenidos digitales en entornos heterogéneos.

Define un API con las siguientes funcionalidades:

• set query language.

• set results format.
• set max query results.
• set max duration.
• set results set size.
• sychronous query.
• get total results count.
• asynchronous query.
• set source location.
• query results listener.

153
 SQI

Integración a través de WebServices

Se describen los métodos implementados en el API del servicio de SQI así

como la descripción de los parámetros necesarios para su correcta invocación,
los tipos de información devuelta y los errores posibles.

•getTotalResultsCount
•setMaxDuration
•setResultsFormat
•setResultSetSize
•setQueryLanguage
•setMaxQueryResults
•synchronousQuery

154
 SQI

getTotalResultsCount

El método tiene el siguiente aspecto:

GetTotalResultsCount (String targetSessionID, String queryStatement) throws

Exception

Este método requiere como parámetros un identificador de sesión y un texto

con una consulta.

155
 SQI

setMaxDuration

El método tiene el siguiente aspecto:

SetMaxDuration (String targetSessionID, Integer maxDuration) throws

Exception

Este método requiere como parámetros un identificador de sesión y un

número de entero positivo. El identificador de sesión debe pertenecer a una
sesión válida y la cifra se interpreta como milisegundos.

156
 SQI

setResultsFormat

El método tiene el siguiente aspecto:

SetResultsFormat (String targetSessionID, String resultsFormat) throws

Exception

Este método requiere como parámetros un identificador de sesión y el

identificador de un lenguaje de respuesta de resultados de búsqueda. El
identificador de sesión debe pertenecer a una sesión válida y el lenguaje, a
un lenguaje admitido por la plataforma.

157
 SQI

setResultSetSize

El método tiene el siguiente aspecto:

SetResultSetSize (String targetSessionID, Integer resultSetSize) throws

Exception

Este método requiere como parámetros un identificador de sesión y una cifra

con el tamaño del conjunto de elementos devueltos. El identificador de
sesión debe pertenecer a una sesión válida y el tamaño del conjunto de
resultados ser válido.

158
 SQI

setQueryLanguage

El método tiene el siguiente aspecto:

SetQueryLamguage (String targetSessionID, String queryLanguajeID) throws

Exception

Este método requiere como parámetros un identificador de sesión y un

identificador de lenguaje de consulta. El identificador de sesión debe
pertenecer a una sesión válida y el identificador de lenguaje deberá estar
entre los identificadores de lenguajes de consulta aceptados por Agrega (VSQI,
LQS).

159
 SQI

setMaxQueryResults

El método tiene el siguiente aspecto:

SetMaxQueryResults (String targetSessionID, Integer maxQueryResults) throws

Exception

Este método requiere como parámetros un identificador de sesión y un entero

con el máximo número de resultados que una búsqueda puede producir. El
identificador de sesión debe pertenecer a una sesión válida y el entero
deberá ser una cifra válida de resultados de una búsqueda.

160
 SQI

synchronousQuery

El método tiene el siguiente aspecto:

SynchronousQuery (String targetSessionID, String queryStatement, Integer

startResult) throws Exception

Este método requiere como parámetros un identificador de sesión, una

sentencia con el texto de la consulta y un valor entero que indica el índice del
primer resultado sobre el total posible a partir del cual se quieren elementos
devueltos. El identificador de sesión debe pertenecer a una sesión válida, la
sentencia debe estar escrita en un lenguaje admitido por la plataforma Agrega
y el valor del índice sobre el total de resultados.

161
 DRI

Se trata de una especificación que se define dentro del contexto de los

repositorios de contenidos digitales para facilitar su interoperabilidad.
Según la especificación DRI, la interacción de los repositorios se consigue
mediante la implementación de una serie de funcionalidades consideradas
básicas en cualquier repositorio:

•Búsqueda.
•Exposición.
•Almacenamiento.
•Entrega.

162
 DRI

Integración a través de WebServices

A continuación, se describen en detalle todos los métodos implementados en

el API de DRI así como la descripción de los parámetros necesarios para su
correcta invocación, los tipos de información devuelta y los errores posibles.

•presentarAlmacenarSesion
•presentarAlmacenar
•solicitarEntregarSesion
•solicitarEntregar
•presentarCatalogarSesion
•presentarCatalogar

163
 DRI

presentarAlmacenarSesion

El método tiene el siguiente aspecto:

PresentarAlmacenarSesion (String sesionId, DataHandler pif) throws Exception

Este método necesita como parámetro un identificador de sesión válido y el

fichero que contiene el ODE que se pretende almacenar en formato Pif.

El resultado de la operación es la publicación dentro de la plataforma del ODE

suministrado.

164
 DRI

presentarAlmacenar

El método tiene el siguiente aspecto:

PresentarAlmacenar (String usuario, String clave, DataHandler pif) throws

Exception

Este método necesita como parámetro un usuario válido, su clave dentro del
sistema y el fichero que contiene el ODE que se pretende almacenar en formato
Pif.

El resultado de la operación es la publicación dentro de la plataforma del ODE

suministrado.

165
 DRI

solicitarEntregarSesion

El método tiene el siguiente aspecto:

SolicitarEntregarSesion (String sesionId, String mec) throws Exception

Este método necesita un identificador de sesión válida y un identificador de

objeto digital que resida publicado en el repositorio. Se devuelve un ODE en
formato Pif.

166
 DRI

solicitarEntregar

El método tiene el siguiente aspecto:

SolicitarEntregar (String usuario, String clave, String mec) throws Exception

Este método necesita un identificador de usuario válido en la plataforma, su

clave dentro del sistema y un identificador de objeto digital que resida
publicado en el repositorio. Se devuelve un ODE en formato Pif.

167
 DRI

presentarCatalogarSesion

El método tiene el siguiente aspecto:

PresentarCatalogarSesion (String sesionId, DataHandler pif) throws Exception

Este método necesita un identificador de sesión válida y un fichero con un

ODE válido en formato pif. El resultado de esta operación es la introducción
del recurso digital dentro de la plataforma en estado pendiente de
catalogación.

168
 DRI

presentarCatalogar

El método tiene el siguiente aspecto:

PresentarCatalogar (String usuario, String clave, DataHandler pif) throws

Exception

Este método necesita un identificador de usuario válido en la plataforma, su

clave dentro del sistema y un fichero con un ODE válido en formato pif. El
resultado de esta operación es la introducción del recurso digital dentro de la
plataforma en estado pendiente de catalogación.

169