Doc. Integración Appcrue v7.6

DOCUMENTO DE INTEGRACIÓN SERVICIOS
DE LA UNIVERSIDAD
Impulsado por:
05/01/2021 Doc. Integración appCrue Página 1 de 83

Fecha: 22/03/2016FecaF
TABLA DE CONTENIDOS
1 INTRODUCCIÓN ....................................................................................................................... 5
1.1 Propósito ............................................................................................................................... 5
1.2 Alcance .................................................................................................................................. 5
2 COMUNICACIONES ................................................................................................................. 6
3 SEGURIDAD............................................................................................................................... 8
4 ARQUITECTURA....................................................................................................................... 9
5 LISTADO DE SERVICIOS ....................................................................................................... 10
6 Servicios básicos ........................................................................................................................ 11
6.1 Oferta académica ................................................................................................................. 11
6.2 Login de usuario .................................................................................................................. 13
6.2.1 Login interno ................................................................................................................ 13
6.2.2 Login externo ............................................................................................................... 14
6.2.3 Refresco del token ........................................................................................................ 14
6.2.3.1 Caducidad del token ............................................................................................. 15
6.2.3.2 Refresco del token para login interno ................................................................... 15
6.3 Datos de usuario .................................................................................................................. 16
6.3.1 Datos identificativos y personales del usuario. ............................................................ 18
6.3.2 Etiquetas. ...................................................................................................................... 20
6.3.3 Listado de asignaturas. ................................................................................................. 24
6.3.4 JSONs de Ejemplo. ...................................................................................................... 25
6.4 vTUI .................................................................................................................................... 26
6.5 Nota explicativa del proceso de login y actualización de datos: ......................................... 26
6.6 Logout para login externo ................................................................................................... 26
7 EXPEDIENTE ACADÉMICO A NIVEL USUARIO ............................................................... 27
7.1 Consulta de expediente ........................................................................................................ 27
7.2 Consulta de notas ................................................................................................................ 28
8 MIS EXÁMENES A NIVEL USUARIO ................................................................................... 31
9 MI HORARIO A NIVEL USUARIO ........................................................................................ 32
10 MENSAJE DOCENTE-ESTUDIANTE .................................................................................... 34
11 DIRECTORIO ........................................................................................................................... 37
12 CALENDARIO ÚNICO: Servicio calendario personal ............................................................ 43
13 LECTURA CÓDIGOS QR ........................................................................................................ 46
13.1 Creación de códigos QR desde el Gestor ........................................................................ 46
13.2 Widget “Presencia QR” ................................................................................................... 46

13.3 Trazabilidad de la lectura ................................................................................................. 47
13.3.1 Desde el gestor ............................................................................................................. 47
13.3.2 Envío automático de lecturas ....................................................................................... 47
14 SERVICIOS ASOCIADOS A LA vTUI .................................................................................... 49
15 ALTA DE BETATESTERS EN ANDROID/IOS ....................................................................... 51
16.2.4 Deslogado de usuarios por error en respuesta .............................................................. 55
16.3 Apertura de URL en navegador ....................................................................................... 55
17 APIS EXTERNAS ..................................................................................................................... 56
17.1 API de mensajes y notificaciones push ............................................................................ 57
17.1.1 Características de la segmentación de las notificaciones: ............................................ 57
17.1.2 Uso de las propiedades y los segmentos ...................................................................... 60
17.1.3 Creación y envío de mensajes push: ............................................................................ 61
17.1.3.1 Principales diferencias entre API v2 external de Appcrue y API Twinpush: ........ 65
17.1.4 API de reporte push...................................................................................................... 65
17.1.5 Eliminar notificaciones ................................................................................................ 67
17.2 API de noticias ................................................................................................................. 68
17.2.1 Creación de noticias ..................................................................................................... 69
17.2.2 Borrado de noticias ...................................................................................................... 71
17.2.3 Actualizar una noticia .................................................................................................. 71
17.3 API de eventos ................................................................................................................. 73
17.3.1 Creación de eventos ..................................................................................................... 74
17.3.2 Borrado de eventos....................................................................................................... 76
17.4 API de promociones ......................................................................................................... 76
17.4.1 Creación de promociones ............................................................................................. 77
17.4.2 Borrado de promociones .............................................................................................. 79
18 RECOMENDACIONES ............................................................................................................ 80
18.1 Envío de Notificaciones Push .......................................................................................... 80
18.2 Noticias ............................................................................................................................ 80
19 ACCESOS AL GESTOR WEB ................................................................................................. 81
20 MIGRACIÓN A SERVICIO DE DATOS DE USUARIO CON ETIQUETAS......................... 82
20.1 Proceso de migración ....................................................................................................... 82
20.2 Certificación .................................................................................................................... 82
20.3 Publicación ...................................................................................................................... 83

CONTROL DE VERSIONES
Nº de revisión Descripción Autor Fecha
1 Versión inicial Integrador appCrue 18/01/2018

2 Añadidos roles y api de getnewses Integrador appCrue 06/03/2018
3 Explicación adicional balanceador Integrador appCrue 16/03/2018
Añadida información de las notifi-
4 Integrador appCrue 06/09/2018
caciones push
Actualizada la guía de la TUI de la 26/09/2018
5 Integrador appCrue
versión 1.1 a la 1.2
Actualización del documento a la
nueva versión de la App
7 Añadido servicio de Directorio Integrador appCrue 12/10/2019
Actualización servicio de info de
usuario
Actualización de los APIs externos
con etiquetas
Actualización de contenidos sobre
servicio de Datos de usuario
Añadido servicio de Mensaje Do-
cente-estudiante
Añadido servicio calendario perso-
nalizado
13 Revisión del documento Integrador appCrue 05/01/2021
Añadido funcionalidad de lectura
de códigos QR
15 Actualización API Integrador appCrue 25/04/2022

1 INTRODUCCIÓN
La plataforma AppCrue, surge como un proyecto colaborativo, aprobado por el Comité
Permanente de CRUE Universidades Españolas, en septiembre de 2015. Dicho proyecto, consistía en
la creación de una plataforma móvil para todas las universidades españolas que deseen usarla,
orientada a todos los colectivos de la universidad: Alumnos, Personal Docente e Investigador (PDI) y
Personal de Administración y Servicios (PAS). CRUE pone esta plataforma a disposición del sistema
universitario español.
Se ha constituido el Comité de Gobernanza de AppCrue, encargado de coordinar la ejecución
del proyecto y velar por el cumplimiento de los compromisos de todas las partes. Este comité está
formado por representantes de las Sectoriales TIC, comunicación, gerentes, estudiantes, personal
de CRUE Universidades Españolas y del Banco Santander/Universia. Siendo este último la empresa
seleccionada por CRUE para implantar y desarrollar el proyecto en cada una de las universidades
que así lo soliciten. Para más la información del proyecto, desde su génesis, gobernanza y
documentación complementaria en http://tic.crue.org/app-crue
El Banco Santander, en su apuesta por la educación superior desde hace más de 20 años en todo
el mundo, quiere seguir contribuyendo a través de AppCrue a la transformación digital de las
universidades, a la evolución de la tarjeta universitaria inteligente al ámbito virtual y a crear un
innovador canal de comunicación de las universidades con sus colectivos.
1.1 Propósito
El presente documento tiene como propósito principal, definir y explicar todos los
requerimientos técnicos necesarios para que una universidad pueda integrarse correctamente con
los diversos servicios y funcionalidades que brinda la plataforma appCRUE.
1.2 Alcance
La solución definida se encuadra dentro de la plataforma appCRUE. El ámbito de aplicación será
para todas aquellas universidades, que firmen el convenio de participación en el proyecto con la
CRUE.

2 COMUNICACIONES
Para realizar la integración con la universidad, es necesario que esta habilite las IPs
correspondientes a los entornos de desarrollo, preproducción y producción en el caso de que se
disponga de firewall/proxy de entrada a los servicios. Estas IPs son:
Entorno IP pública
Producción 1 34.248.235.252
Preproducción 52.212.141.67
Desarrollo (banco) 193.127.221.5
Desarrollo 2 (banco) 88.12.28.89
Producción 2 52.208.70.223
Producción 3 52.50.43.57
Tabla 1 IPS de entornos
Nota: Al hacer ping sobre la DNS de producción, devolverá la IP del balanceador, pero no es
necesario darla de alta puesto que no es la máquina que luego gestiona las peticiones.
Por parte de la universidad, será necesario que está disponga de dos entornos. Un entorno
de preproducción (utilizado para la realización de pruebas) y otro de producción. En ambos entornos
deben de estar habilitadas las IPs anteriormente mencionadas.
Es importante indicar, que el entorno de producción tiene que tener habilitados los accesos
al exterior, sobre todo en el caso de que el servicio de login utilice autenticación SSO (Single Sing-
On) como puede ser CAS, SAML o OAuth2. Ya que será el dispositivo móvil el que realice
directamente la invocación, sin pasar por los servidores de backend.
El cifrado o comunicaciones con la universidad se establece en función de las peculiaridades de
cada universidad, siendo recomendable cifrar o autenticar el usuario o la información en función de
si esta información es sensible (datos personales de usuario, notas…) o bien, es información de
carácter público (oferta académica, información relativa a la universidad,…).
Una vez dadas de alta las comunicaciones, es necesario especificar los métodos de petición
correspondiente para obtener la información de los distintos servicios de la universidad. Para ello,
se propone como aplicación de pruebas de llamadas a los servicios Postman
(https://www.postman.com/), que emula las llamadas que realizará el backend. Estas invocaciones se
realizarán a través de llamadas GET, POST o Bearer con las cabeceras correspondientes.
• GET: Si simplemente se quiere cargar el contenido con información de carácter público que no
necesita ningún tipo de autenticación. Se le pueden pasar parámetros en la propia cabecera.
• POST: Permite en envío de parámetros en el body de la petición.
• BEARER: Haciendo uso del esquema de autenticación HTTP que involucra tokens de seguridad
llamados bearer tokens. Este token es el generado por la universidad. Si por bearer se invoca
algún servicio, este tendrá que ser de tipo GET, para que sea reconocido por la App.

Por seguridad todas las llamadas en las que se intercambie información irán por POST o Bearer.
Las respuestas de los servicios deben de ser:
OK 200 Respuesta correcta
OK 204 No hay error, pero la respuesta está vacía, no hay datos
Acceso denegado porque el token no es válido. Por seguridad no se informa

ERROR 401
al usuario de que las credenciales son incorrectos.
Problema de conexión con los servicios académicos. Los servicios no están

ERROR 403
disponibles en éste momento (por ejemplo, caída de servicio).
Usuario no encontrado en los servicios académicos. Se ha podido realizar

ERROR 404 correctamente el login del usuario, pero no se encuentra en la plataforma
de servicios académicos.
Respuesta Los parámetros de entrada son incorrectos. El token y/o el idioma están va-
ERROR 406 cíos, son nulos, o bien tienen un formato inadecuado. Este error es difícil
que se produzca con un servicio en producción.
Timeout de conexión con los servicios académicos. El servicio no responde

ERROR 408 pasado un tiempo. Puede suceder por exceso de carga en el servicio acadé-
mico, puertos bloqueados en la conexión, etc.
Error no especificado de los servicios académicos.

El usuario ha sido identificado, es válido, y la conexión con el servicio acadé-
ERROR 409 mico funciona. Pero el servicio responde con algún error. A veces el usuario
requiere de una activación o de algún trámite adicional. El mensaje de error
en la app sugerirá contactar con la universidad.
ERROR 500 Error inesperado, no controlado.

3 SEGURIDAD
En este apartado se enumeran los principales requisitos de seguridad aplicados:
o Como primera capa a nivel de sistemas, se propone autenticar los equipos origen y destino
por filtrado de las IP públicas indicadas en el apartado anterior. Con esto se logra que solo
los servidores de nuestro backend y los equipos conectados desde la IP de la oficina sean
los únicos que puedan acceder a los servicios expuestos por la universidad.
o Para la capa de transporte, se hace uso de TLS 1.2 (Transport Layer Security) para cifrar el
tráfico que entra y sale del backend.
o Uso de token propio AppCrue. Utilizamos un token propio que se va actualizando cada hora,
de manera que si se intercepta en alguna comunicación entre la app y el backend no podrá
usarse y los datos del usuario estarán a salvo.
o Restricción de uso del token de universidad exclusivo de backend. El token proporcionado
por la universidad para cada usuario es de uso exclusivo del backend. Sólo se le pasa a la
app en casos puntuales (uso de webviews, ciertos protocolos de single sign-on o integración
con terceros) pero jamás se almacena ni en la app ni en el dispositivo.
El token se usa para consultar los datos privados de los usuarios. Si se ha caducado, es el
backend el que avisa a la app. Esta puede pedir un refresco de token si dispone de este
servicio o lanzar la página de login, pero nunca tendrá almacenado el token.
o Limitación de las operaciones que se pueden realizar en nombre del usuario. Solo se
permiten acciones consultivas, aunque el token expuesto por la universidad permitiese
acciones de modificación o representación del usuario.
o La infraestructura de la AppCRUE, disponemos de redes separadas para PREPRODUCCIÓN
y para PRODUCCIÓN, cada una está en una VPC (Virtual Private Cloud) y sólo es accesible
por el equipo de AppCRUE a través de una VPN. El acceso a las máquinas se realiza me-
diante SSH y requiere una clave privada.
o El contenido que se visualiza en la app sólo es accesible (salvo que sea público) si el usua-
rio ha iniciado la sesión.
o Los datos que viajan desde los servicios expuestos por la universidad hasta la app, no se
guardan en ningún momento en la aplicación.

4 ARQUITECTURA
Diagrama representativo tanto de la arquitectura actual, cómo de la infraestructura de

comunicaciones.
Ilustración 1Diagrama de Arquitectura

5 LISTADO DE SERVICIOS
Tipo Servicios Definición

Servicio encargado de realizar la autenticación. Devuelve un token de universidad y que será el identifi-
Login*
cador único asociado al usuario.
Servicio que devuelve un JSON con datos que son necesarios para identificar al usuario en todos los ser-
Datos de usuario*
vicios y son utilizado también, para poder segmentar los contenidos de la App.
TUI* Servicio que devuelve un JSON con los datos que son necesarios para generar la TUI
Expediente Servicio que devuelve los años académicos con notas
Notas Servicio que devuelve las notas
Funcionalidades cuya integración re-
quiere un servcio de la universidad Exámenes Servicio que muestra los exámenes que tiene el estudiante en la sección de exámenes.
Horario Servicio que muestra el horario que tiene el estudiante en la sección de horarios.
Mensaje docente-estu-
Servicio que informa de las etiquetas a las que un docente puede enviar notificaciones.
diante
Directorio Servicio que devuelve un listado con los contactos y sus datos que coincidan con la búsqueda del usuario
Calendario único Servicio que devuelve el horario, exámenes y revisión de exámenes y los muestra en el calendario.
Oferta académica Servicio que devuelve un json con la oferta académica que la universidad quiere publicitar
Notificaciones push Servicio para la publicación de notificaciones
Noticias Servicio para la publicación de noticias
API Externa de Appcrue Eventos Servicio para la publicación de eventos en el calendario del usuario y en la sección de eventos.
Retos Servicio para la publicación de retos
Ventajas Servicio para la publicación de ventajas
Identificación con código
Sistema de validación de la vTUI y de su propietario mediante códigos QR de un solo uso.
QR dinámico
API de identificación
Validation Servicio al que llamando con el token de appcrue que devuelve los datos identificativos del usuario
*Servicios básicos requeridos para el funcionamiento de la app

6 Servicios básicos
Se consideran servicios básicos a aquellos servicios que debe brindar la aplicación para poder
ser publicada en los Stores. Estos son:
o Oferta académica: Servicio que muestra la oferta académica existente por la universidad.
Se mostrará información similar a la mostrada en la página web de la universidad.
o Login: Servicio que autenticación del usuario.
o Datos de usuario: Servicio que retorna datos personales del usuario, etiquetas y
asignaturas. Información imprescindible para el correcto funcionamiento de otros
servicios y poder segmentar contenidos del gestor a los usuarios.
o TUI: Servicio necesario para mostrar la Tarjeta Universitaria Interactiva.
Aparte de estos servicios, se recomienda incluir el servicio de Notas. Ya que es el más utilizado
por los estudiantes, pero no es obligatorio para publicar la App. En los próximos apartados se
detallarán estos servicios y el formato de la respuesta esperado por AppCRUE.
Nota: Importante destacar que es necesario proporcionar usuarios de prueba, con todos los
roles disponibles (estudiante, PAS, PDI y usuarios mixtos), y que posean datos para mostrar la TUI.
Tanto para el entorno de Preproducción como el de Producción.
Estos servicios básicos (y el servicio de Notas), pueden ser implementados por la empresa
colaboradora Datio Software sin coste alguno para la universidad.
6.1 Oferta académica

Mostrará la oferta académica que disponga la universidad. Generalmente se ubica en la parte
publica de la App. Existen tres formas de mostrar esta información:
1º Por servicio: Forma más recomendable, ya que la información mostrada siempre estará
actualizada. Este servicio debe de estar expuesto desde un servidor accesible. Se invocará por GET,
y el único parámetro necesario será el idioma en caso de disponer de una oferta multiIdioma.
2º Por JSON estático: Consiste en la creación de un JSON estático que o bien es alojado por la
universidad en una url pública accesible o bien se puede proporcionar a AppCrue para que sea
alojado en sus servidores. El JSON estático resulta una opción menos aconsejable, ya que, ante
cualquier cambio en la oferta, hay que actualizar el archivo JSON.
3º Por webview: Si se desea enlazar con una URL ya existente por la universidad, se puede
enlazar directamente vía Webview. Visualmente es la opción menos atractiva, ya que las dos
anteriores se muestran de forma nativa en la app.
Las tres opciones son configurables desde el gestor de contenido (hablaremos de él
posteriormente en el documento). En los dos primeros casos se configurará como “Lista navegable”,
se mostrarán diferentes niveles de navegación en la app, agrupados según el criterio considerado
por la universidad (puede ser por áreas de conocimiento, por tipo de formación…). En el tercer caso,
será configurado desde el gestor como de tipo “webview”.
Ejemplo de JSON:

ofertaAcademica.js
on

6.2 Login de usuario
El login completo del usuario en la App, se compone de dos partes: el servicio de login o
autenticación (que es muy dependiente de la universidad), y el servicio de información de usuario,
donde recuperamos la información necesaria para el funcionamiento de la aplicación.
El servicio de login será el encargado de realizar la autenticación. Esta autenticación puede ser
nativa, que es lo que llamamos login interno. O podría ser login externo, esto quiere decir que desde
la aplicación se levanta un navegador con la web de la universidad para autenticar, como puede ser
CAS, SAML o OAuth2.
En los dos casos se recupera un token, el cual denominamos token de universidad, y que será
el identificador único asociado al usuario. Será utilizado para recuperar la información de los
servicios nativos de la universidad, entre ellos el servicio que se comentará en el punto 5.3 “datos
de usuario”.
Este token está controlado por la universidad, que definirá su duración de validez y en todo
momento, y podrá revocarlos si lo estima oportuno.
6.2.1 Login interno
Para incorporar el login interno se necesita un servicio REST al que llamando con el username
del usuario y la contraseña del usuario devuelve el token del usuario,
Request: AppCrue envía un username y password como parámetros de entrada en el body de la
llamada.
Parámetros entrada (POST):
Campo Tipo Descripción
username String Username del usuario
password String Password del usuario
Response: La universidad devuelve un Token, fecha de caducidad del mismo y un token de refresco.
token String Token del usuario
refresh_token String Token que será utilizado para hacer la llamada al

servicio de refresco del token
expires_at String Fecha de caducidad del token en formato UNIX.

6.2.2 Login externo
Para logins externos, se especifica desde la pantalla de login propia de la universidad las
credenciales del usuario, teniendo que seguir el siguiente esquema de comunicación (en el diagrama
como ejemplo para OAuth2), incluyendo una redirección para devolver el control a las apps:
NOTA: El portal de autenticación tiene que estar abierto a tráfico, sin filtro ip, para que desde
cualquier sitio las aplicaciones nativas puedan acceder al login.
Callback URL
PREPRODUCCIÓN: https://pre.appuniversitaria.idsant.com/api/v7/external_login
PRODUCCIÓN: https://appuniversitaria.universia.net/api/v7/external_login
El parámetro donde tiene que venir el token que facilita la universidad como identificador del
usuario y la sesión se debe de llamar token.
6.2.3 Refresco del token
Se recomienda que la Universidad exponga un servicio del refresco del token. Si el backend
AppCRUE detecta que ha caducado el token del usuario, invocaría a este servicio para renovar el
token y no deslogarle.
Aporta seguridad a los servicios sensibles de la universidad al estar rotando frecuentemente.
Se puede aplicar tanto a login interno como login externo.

6.2.3.1 Caducidad del token
Este periodo de tiempo lo establece la universidad y afecta a la validez de un token para realizar
peticiones a la universidad. Una vez el token esté “caducado” el usuario podrá seguir navegando por
la app, pero en el momento en el que intente utilizar una funcionalidad que dependa de un servicio
de la universidad (Ej: notas, horario, exámenes..) dicho servicio devolverá un error y se deslogará al
usuario de la app.
Para evitar deslogar al usuario la universidad debe facilitar el servicio de refresco del token. Si el
backend AppCRUE detecta que ha caducado el token del usuario, invocará a este servicio para
renovar el token y no deslogarle.
6.2.3.2 Refresco del token para login interno
refresh_token String Token de refresco del usuario
Devuelve:
token String Token del usuario
refresh_token String Token que será utilizado para hacer la llamada al

servicio de refresco del token
expires_at String Fecha de caducidad del token en formato UNIX en

segundos

6.3 Datos de usuario
La plataforma AppCRUE invoca a un servicio REST de la universidad para recuperar los datos del
usuario que se acaba de logar en la aplicación.
El modelo esperado para la obtención de datos del usuario sería:
URL de ejemplo https://universidad.es/APIRestServices/api/AppCRUE/GetDatosUsuario
Método POST
Tipo MIME www-form-urlencoded
Token con la sesión del usuario en vigor. Es el

Petición token mismo token que anteriormente fue creado Texto
por la universidad en el login.
Parámetros
Idioma configurado por el usuario en la app.
lan El cual se utiliza para mostrar el nombre de ES,CA,GA,EN
las asignaturas en el idioma del usuario.
Tipo MIME application/json
OK 200 Ver sección estructura de la respuesta

Respuesta
Este código se utiliza cuando la respuesta es incompleta. Es decir,
OK 204 alguno de los datos no está disponible en la estructura. Este código
es monitorizado por la plataforma AppCRUE.
Posibles códigos de error en la respuesta:
Acceso denegado porque el token no es válido.

El mensaje de error que se incluya se mostrará al usuario en la app. El men-
saje de error debe incluirse bajo el campo “detail”, cumpliendo el siguiente
formato:
ERROR 401 {
"errors" : {
"detail": "........"
}
}
Problema de conexión con los servicios académicos. Los servicios no están

ERROR 403
disponibles en este momento (por ejemplo, caída de servicio).
Respuesta Usuario no encontrado en los servicios académicos. Se ha podido realizar

ERROR 404 correctamente el login del usuario, pero no se encuentra en la plataforma
de servicios académicos.
Los parámetros de entrada son incorrectos. El token y/o el idioma están va-
ERROR 406 cíos, son nulos, o bien tienen un formato inadecuado. Este error es difícil
que se produzca con un servicio en producción.
Timeout de conexión con los servicios académicos. El servicio no responde

ERROR 408 pasado un tiempo. Puede suceder por exceso de carga en el servicio acadé-
mico, puertos bloqueados en la conexión, etc.
ERROR 409 Error no especificado de los servicios académicos.

El usuario ha sido identificado, es válido, y la conexión con el servicio acadé-
mico funciona. Pero el servicio responde con algún error. A veces el usuario
requiere de una activación o de algún trámite adicional. El mensaje de error
en la app sugerirá contactar con la universidad.
ERROR 500 Error inesperado, no controlado.
El servicio de datos de usuario retorna una estructura de tipo JSON. La información que
contiene este JSON se divide en tres bloques. A continuación, se describen brevemente estos
bloques, posteriormente se pasará a explicar en detalle cada uno de ellos.
1. Datos identificativos y personales del usuario: Como pueden ser el nombre, apellidos,
rol, foto…. Estos datos son necesarios para identificar al usuario en todos los servicios y
son utilizado también, para poder personalizar contenidos de la App.
2. Etiquetas: Se utilizan para indicar los canales a los que está suscrito el usuario. Se utiliza
también para poder segmentar los contenidos de la aplicación (noticias, mensajes,
eventos, etc.), así como para el envío de notificaciones Push. Estas etiquetas pueden ser
vacías y no tienen por qué estar asociadas con la estructura académica, sino con aquellos
contenidos que realmente interesen al usuario.
3. Asignaturas: Para los usuarios con rol alumno, se le mostrarán las asignaturas a las cuales
está matriculado en el momento de la consulta. En el caso de usuario con rol profesor, se
mostrarán las asignaturas que actualmente está impartiendo. Para otros colectivos como
Alumni o PAS, seguramente no existan asignaturas asociadas.
EJEMPLO DE JSON:
Ejemplo de JSON de respuesta para un alumno (Ver: JSONrespuestaparaalumno.json)
VALIDADOR DE JSON:
La respuesta a la consulta de datos de usuario es un objeto con estructura JSON. A
continuación, adjuntamos un JSON Schema que puede utilizarse para comprobar la validez de
cualquier respuesta de datos de usuario.
JSON datos
esquema.txt

6.3.1 Datos identificativos y personales del usuario.
Esta parte del JSON de respuesta corresponde con datos que son necesarios para identificar
al usuario en todos los servicios y son utilizado también, para poder personalizar contenidos de la
App.
Todos los campos pertenecientes a esta parte son de carácter obligatorio. No disponer de
alguno de estos datos de usuario podría suponer el incorrecto funcionamiento de los servicios de
AppCRUE.
A continuación, se listan y explican estos campos:
Email
Correo electrónico del usuario en la universidad. Se utiliza como identificador del usuario y
Descripción
para contacto en la resolución de algunas incidencias.
Etiqueta email Tipo Email
Longitud Máximo de 100 caracteres Obligatorio SI
Restricción Formato email Ejemplo isabel.morgan@alumnos.uned.es
Nombre
Descripción Nombre del usuario.
Etiqueta firstname Tipo String
Restricción Ninguna Ejemplo Isabel
Apellidos
Apellidos del usuario. El campo puede tener un solo apellido, que es habitual en alumnos ex-
Descripción
tranjeros donde sólo se utiliza uno de los apellidos de los progenitores.
Etiqueta lastname Tipo String
Restricción Ninguna Ejemplo Morgan
Avatar
El “avatar” es la fotografía del usuario que se muestra en la App. La imagen debe retornarse en
formato JPG y a su vez codificada en Base64 (texto).
Descripción
La fotografía debe ser lo más actual posible y hay que evitar el uso de iconos o imágenes gené-
ricas. Esto mejora la sensación de personalización de AppCRUE para el usuario final.
Etiqueta avatar Tipo String
Longitud Imagen menor de 300k Obligatorio SI
Restricción Base 64 Ejemplo -

Teléfono
Descripción Teléfono de contacto del usuario. Se puede añadir el prefijo internacional.
Etiqueta telephone Tipo String
Restricción Ninguna Ejemplo +44-7963192333
Perfil
Perfil del usuario, que debe tener uno de los siguientes valores (ESTUDIANTE, PAS, PROFESOR,
ALUMNI, PREUNIVERSITARIO, EXTERNO). El perfil puede contener varios de estos valores sepa-
rados por comas, cuando se trate de un multiperfil.
La plataforma soporta los siguientes tipos de perfiles:

• ESTUDIANTE: Alumnos que actualmente están matriculados en la universidad.
• PROFESOR: Personal de la universidad dedicado a la docencia.
Descripción • PAS: Personal de la universidad dedicados a administración y servicios.

• ALUMNI: Colectivo de antiguos alumnos de la universidad.
• PREUNIVERSITARIO: Futuros estudiantes de la universidad, que no están matriculados,
pero ya se encuentran pre-inscritos.
• EXTERNO: Usuarios de carácter externo a la universidad, como, por ejemplo, proveedo-
res.
En el caso de querer utilizar usuarios multiperfil, hay que ordenar alfabéticamente los roles se-
parados por comas, y evitar que se repitan.
Etiqueta role Tipo String
Restricción Lista Ejemplo ESTUDIANTE,PROFESOR
NIA
Descripción Número de identificación académico unívoco del usuario en la universidad.
Etiqueta nia Tipo String
Restricción Ninguna Ejemplo ES46276
Tipo de Documento de identidad

Descripción Tipo de documento de identidad (DNI, NIF, NIE, PASAPORTE)
Etiqueta document_type Tipo String
Restricción Valores: NIF, PAS, NIE, OTROS Ejemplo NIF, PAS, NIE, OTROS

Documento de identidad
Descripción Documento de identidad (DNI, NIF, NIE, Pasaporte) que identifica al usuario en la universidad.
Etiqueta doc Tipo String
Restricción Ninguna Ejemplo 12345678S
Cuenta de usuario
Descripción Nombre de la cuenta de usuario en la universidad.
Etiqueta username Tipo String
Restricción Ninguna Ejemplo isabel.morgan
6.3.2 Etiquetas.
Dentro de la información de usuario se puede rellenar un listado de “etiquetas”. Estas etiquetas

nos permiten describir al usuario dentro de la comunidad universitaria. Y son utilizadas por
AppCRUE para suscribir al usuario a un conjunto de canales de comunicación. El uso de etiquetas no
es obligatorio, pero sí muy recomendable.
Con este mecanismo, la universidad puede enviar comunicados (mensajes, eventos, noticias,
etc.) directamente a los canales. Y los comunicados llegarán a todos los usuarios suscritos a dicho
canal.
En las etiquetas que describen a un usuario, podemos rellenar la siguiente información:
✓ Campus al que pertenece el usuario.
✓ Planes de estudio relacionados con el usuario (como alumno o cómo profesor).
✓ Asignaturas relacionadas con el usuario (como alumno o cómo profesor).
✓ Grupos de clase relacionadas con el usuario (como alumno o cómo profesor).
✓ AppCRUE permite otro tipo de etiquetas que la universidad considere oportuno: estudiantes
de Erasmus, deportes, etc.
✓ Todos los usuarios tienen la etiqueta Universidad, la cual es incluida por defecto, sin
necesidad de ser informada.
Por tanto, las etiquetas permiten enviar comunicados a diversos niveles. Por ejemplo, a algo tan
amplio como un campus completo. O algo más concreto, como el grupo B de estudiantes de Filología
Inglesa.
La etiqueta de un usuario tiene el siguiente formato:
CODIGO::NOMBRE

El código es una identificación unívoca dentro de la propia universidad para la etiqueta, y el
nombre es una descripción que nos permite saber de qué trata. Por ejemplo:
100887::Historia del arte de la baja Edad Media
Esta etiqueta hace referencia a una asignatura llamada “Historia del arte de la baja Edad Media”
cuyo identificador único dentro de la universidad es ID = 100887.
Otros ejemplos de etiquetas:
✓ 12::Campus de Miguel Delibes
✓ 217::Graduado en Medicina
✓ 564A156::Derecho Romano I
✓ 011208V2C::Farmacología Grupo C (Tardes)
El sistema de etiquetas es muy flexible y permite llegar hasta el nivel de segmentación deseado
de cada universidad. A continuación, vemos un ejemplo de etiquetas para un usuario con un doble
grado en la UNED, llegando hasta el nivel de grupo:
✓ C100885::Campus 1 UNED
✓ D100047::Doble Grado en Dirección de Empresas y Marketing
✓ S100885::Estadística empresarial y financiera
✓ S100886::Microeconomía
✓ S100887::Macroeconomía
✓ S100888::Optimización Matemática
✓ G100885::Grupo 1 Mañana Estadística empresarial y financiera
✓ G100886::Grupo 2 Mañana Microeconomía
✓ G100887::Grupo 3 Tarde Macroeconomía
Las etiquetas se agrupan dentro de una estructura JSON . Todas las etiquetas están definidas
dentro de una propiedad (que pueden tener cualquier nombre), las propiedades están definidas
dentro del nodo “segments”. Ejemplo de JSON:
"segments": {
"degrees": [
"217::Graduado en Medicina"
],
"campus": [
"12::Campus de Miguel Delibes"
],
"subjects": [
"564A156::Derecho Romano I"
],
"groups": [
"011208V2C::Farmacología Grupo C (Tardes)"
]
"deportes": [
"psc::Piscina",
“01233::Futbol”,
“ten::Tenis”
],

"deportes_api": [
"psc",
“01233::Fultbol”,
“ten”
]
}
Se permite definir propiedades que se podrán mostrarán tanto en el gestor de contenidos

como en el API. También se permite definir propiedades que solo serán accesibles desde el API.
Estas últimas, para poder ser identificadas, tendrán que finalizar en “_api” (ejemplo deportes_api).
Las etiquetas contenidas dentro de una propiedad visible en el gestor, tiene que estar construidas
por el conjunto CODIGO::NOMBRE indicado anteriormente, para poder ser fácilmente identificadas
y poder construir los desplegables en el gestor. En cambio, las que únicamente se quiera que sean
usadas desde el API, pueden tener la estructura CODIGO::NOMBRE o simplemente tener CODIGO.
Esta diferenciación se ha hecho, ya que, desde el API, tiene que escribirse la etiqueta
exactamente igual que la definida para el usuario. Para facilitar la invocación es más sencillo escribir
solo un código. Aunque si así se desea, se puede hacer uso de la etiqueta estándar codigo:nombre.
Por otro lado, se permite crear etiquetas restringiendo su uso solo al API. Puede ser de utilidad si se
desea ocultar determinadas etiquetas a los usuarios del gestor.
Es importante mencionar, que solo se puede hacer uso de las etiquetas de los usuarios que se
hayan logado en la aplicación. A medida que los usuarios se van logando en la aplicación, la
información obtenida por el servicio de datos de usuario se va integrando (almacenando en base de
datos). El sistema solo puede hacer uso de las etiquetas que estén almacenadas en base de datos
(tanto el gestor de contenidos, como el API). Por ejemplo, si se incluye una etiqueta
“alumno1::alumno de primer curso”, para los usuarios de primer año, hasta que alguno de los
usuarios que posee esa etiqueta no se loge en la app, no se podrá segmentar contenido, ni enviar
notificaciones asociadas a esta etiqueta.
En la estructura JSON de etiquetas debemos tener en cuenta las siguientes consideraciones:

✓ El grupo de etiquetas degrees es obligatorio, siempre y cuando el usuario tenga relación
académica con la universidad.
✓ En las etiquetas no se tiene en cuenta el perfil de usuario. No importa si el usuario acude a
una asignatura como alumno o como profesor, lo importante es etiquetarlo en la asignatura
si está relacionado con ella.
✓ Los textos con el nombre o descripción de la etiqueta se especifican siempre en el idioma
que la universidad tenga por defecto
✓ Ordenar las etiquetas por tipo de etiqueta y por código. Es recomendable que los grupos de
etiqueta conserven siempre el mismo orden. Y que dentro de cada grupo de etiquetas los
códigos estén ordenados alfabéticamente. Esto permite optimizar el tratamiento de las
etiquetas y mejorar la detección de cambios en las suscripciones de un usuario.
La estructura de grupo de etiquetas es abierta y extensible. Podemos añadir cualquier otro grupo
según las necesidades de cada universidad (deportes, asociaciones, grupos, etc.).

"segments": {
"degrees": [
"217M::Máster en Profesor de Educación Secundaria Obligatoria"
],
"deportes": [
"D3482::Curso de Gimnasia para la espalda"
],
"asociaciones": [
"ASOC28::Asociación de Radioaficionados Universitarios",
"ASOC12::Asociación Cultural Universitaria"
],
"otros": [
"473793-X::Sindicato de estudiantes"
]
}
Para facilitar una mayor y mejor segmentación de los servicios de comunicaciones, también se
recomienda que los datos de usuario incluyan todas las etiquetas posibles. Es decir, todos los
elementos académicos relacionados con el usuario: asignaturas y planes de estudio que cursa,
grupos en los que se encuentra, facultades y campus con los que está relacionado, etc.
A continuación, mostramos una captura de ejemplo para el envío de un mensaje push al canal
[C100885::Campus 1 UNED]. Este mensaje push llegará a todos los usuarios con AppCRUE instalada
y suscritos a dicho canal.
Figura: Ejemplo de envío de mensajes push segmentados con Twin Push.
Las etiquetas también pueden agruparse, para administrarlas fácilmente dentro de los gestores.
Puede utilizarse cualquier sistema de nombrado para la agrupación, pero recomendamos incluir los
siguientes grupos académicos:
✓ campus: Grupo de etiquetas con los campus con los cuales tiene relación el usuario.

✓ degrees: Grupo obligatorio con los planes de estudio relacionados con el usuario.
✓ subjects: Asignaturas también relacionadas con el usuario.
✓ groups: Grupos de clase a los que pertenece el usuario.
Figura: Ejemplo de cómo usar la etiqueta y el grupo de etiqueta con Twin Push.
6.3.3 Listado de asignaturas.

La última parte de los datos del usuario es el listado de asignaturas. Esta información se utiliza
dentro de AppCRUE para la sección “Mis Asignaturas”. En el caso de los usuarios con rol estudiante,
se compone del listado de asignaturas donde está matriculado el usuario en el momento de la
consulta. Para los usuarios de tipo PDI, se mostrarán las asignaturas que actualmente esté
impartiendo. Para el caso de tratarse de un usuario de tipo multiRol (Estudiante y profesor), se le
mostrarán ambas informaciones, bien diferenciadas en la App.
Es importante mencionar que no es necesario que esta información aparezca como
etiquetas, si no se va a segmentar por ellas.
Finalmente es necesario incluir información y metadatos sobre las asignaturas relacionadas
con el usuario. A continuación, se muestra un ejemplo en JSON de usuario con doble perfil:
{
"subjects": [
{
"import_code": "A45942",
"name": "OPERACIONES BÁSICAS DE LABORATORIO II",
"url": "https://universidad.es/asignaturas/45942.html",
"group": "GRUPO 1 OPERACIONES BÁSICAS DE LABORATORIO II"
},
{
"name": "QUÍMICA EXPERIMENTAL II",
"group": "GRUPO 2 QUÍMICA EXPERIMENTAL II"
}
],
"subjects_teacher": [
{
"name": "OPERACIONES BÁSICAS DE LABORATORIO II",

"group": "GRUPO 1 OPERACIONES BÁSICAS DE LABORATORIO II"
}
]
}
En la estructura JSON de asignaturas hay que tener en cuenta las siguientes consideraciones:
✓ Las asignaturas deben separarse en dos arrays distintos y obligatorios: asignaturas que son
impartidas por un profesor (subjects_teacher), o bien asignaturas en las que actualmente
está matriculado un alumno (subjects). Sino es necesario indicar asignaturas de un rol, por
ejemplo subjects_teacher, por tratarse de un estudiantes, esté se enviará vacío.
✓ Ordenar las asignaturas por tipo y por código. Es recomendable que los tipos de asignatura
tengan siempre el mismo orden: subjects, subjects_teacher. Y que, dentro de cada tipo, las
asignaturas estén ordenadas alfabéticamente por código (import_code). Esto permite
optimizar el tratamiento de las asignaturas.
El import_code ha de ser único.
✓ Los textos, direcciones URL y metadatos en general se retornarán siempre en el idioma
solicitado por el usuario (parámetro idioma de la solicitud). Por ejemplo, podemos utilizar
URL distintas para el castellano y para el inglés, si la universidad dispone de ellas. En el caso
de tratarse de la primera vez que se integra el usuario, al no tener un idioma seleccionado,
se invocarán en el idioma que tenga por defecto la universidad.
Las Urls indicadas, han de ser de tipo https, en caso contrario no se mostrarán en la app. Si
se indica este campo, en la app se podrá pulsar sobre la asignatura indicada y este abrirá la
Url definida.
✓ Se puede incluir opcionalmente el nombre del grupo asociado con la asignatura.
6.3.4 JSONs de Ejemplo.

Estos ejemplos se encuentran en la carpeta “json_ej_datos_usuario”:
• Ejemplo de respuesta para un doble perfil de usuario Alumno y Profesor (Ver:
doblerolejemplo.json)
• Ejemplo de respuesta para un profesor, con el nivel de etiquetas mínimo (Ver:
mínimoejemplo.json)
• Ejemplo de respuesta para un profesor, con múltiples etiquetas (Ver:
profesormultiplestags.json)
• Ejemplo de respuesta para un alumni, sin relación académica con ningún plan de estudios,
ni etiquetas (estructura mínima sin datos académicos) (Ver: ejemploalumni.json)
• Ejemplo de respuesta para un PAS, sin relación académica con ningún plan de estudios
(estructura mínima sin datos académicos) (Ver: ejemploPAS.json)
• Ejemplo de respuesta para un alumno con diversas etiquetas (Ver: aluvariasetiquetas.json)

6.4 vTUI
Actualmente, se integra la TUI virtual con la empresa colaboradora Datio Software. Se adjunta
documento de integración de Datio v1.2 con las especificaciones de integración:
6.5 Nota explicativa del proceso de login y actualización de datos:

Cuando un usuario introduce sus credenciales desde la app, se invoca al servicio de login
(explicado en el punto 5.1), y se obtiene el token de universidad para este usuario.
Con este token y el idioma del usuario, se invoca al servicio de datos de usuario, y se obtiene
toda la información del usuario (datos personales, etiquetas y asignaturas), se comprueba si el
usuario existe en Base de Datos. Si no existe, se integra por completo en la aplicación,
almacenándose sus datos en la Base de Datos como un usuario nuevo
Este proceso de integración es costo y puede repercutir en el rendimiento de la Base de Datos,
sobre todo en el caso de la existencia de muchos usuarios concurrentes usando la aplicación. Por
este motivo, se cuenta con un campo denominado “tiempo de integración”. Durante el periodo de
tiempo especificado en este campo, no se actualizarán los datos del usuario en Base de datos (este
tiempo por defecto es de 7 días, pero puede ser modificado). Esto quiere decir que si durante este
tiempo hay cualquier modificación en el usuario, como puede ser un cambio de foto, una nueva
etiqueta… no quedará reflejado en el sistema hasta que no pase el tiempo de integración.
6.6 Logout para login externo

Debido a que una vez hecho login, los navegadores cachean datos del usuario y cookies, es necesario
implementar un servicio de logout. Cuya finalidad es la de descachear información de usuarios,
eliminando cookies y limpiar datos de sesión.

7 EXPEDIENTE ACADÉMICO A NIVEL USUARIO
Este servicio nativo se ofrece para mostrar el expediente académico del alumno, o bien sólo las notas
del año en curso.
Si se desea incorporar el expediente completo serán necesario exponer dos servicios: consulta de
expediente y consulta de notas por año.
Si se desea sólo incorporar las notas del año académico en curso, con el servicio de consulta de notas
por año sería suficiente.
A continuación, se detallan.
7.1 Consulta de expediente

La universidad debe de exponer un servicio REST que a través del token identificativo del usuario
debe de devolver los años académicos con notas, y posteriormente hacer consultas individuales
por año, en el segundo servicio de consulta de notas por año.
El año con el campo sel: ’S’ es el que carga por defecto la primera vez y la ordenación a la hora de
seleccionar el año va a ser tal cual venga especificada en el JSON.
Request por POST: token de autorización e idioma
Ejemplos:
https://serviciosparaappcrue/AppCRUE/getExpediente
Param1 → token=A5HfVTE77eYaFLS4 /nSJ2Khw==
Param2 → lan=es
Response: Años académicos para hacer consulta posterior

{
"cursos":
[
{
"id": "2016-17", /*String type*/
"descripcion": "Año 2016-17", /*String type*/
"sel": "S" /*String type*/
},
{
"id": "2015-16", /*String type*/
"descripcion": "Año 2015-16", /*String type*/
"sel": "N" /*String type*/
}
],
"total": 2, /*String type*/
"lang": "es" /*String type*/
}

7.1.1 Consulta de notas
La universidad debe de exponer un servicio REST para consultar las notas por años.
Request: AppCrue envía el TOKEN del usuario e idioma (opcional: Año académico)
Ejemplos:
https://serviciosparaappcrue/AppCRUE/getNotas
Param2 → lan=es
Param3 → year=2016-17
Response: Devolver las notas en el formato JSON especificado a continuación.
En el caso de que para la asignatura sea “NO PRESENTADO” el campo nota tiene que ser null
invalidando el resto de los campos a la hora de presentarlo.
En el caso de que para la asignatura sea “APROBADO” el campo nota tiene que tener notación
numérica y el campo info especificado en el JSON: true.
En el caso de que para la asignatura sea “SUSPENSO” el campo nota tiene que tener notación
numérica y el campo info especificado en el JSON: false.
El resto de los campos son de texto variable, pudiendo configurarlo la propia universidad (para
calificación se recomienda abreviaturas de SUSPENSO (SP), APROBADO (AP), NOTABLE (NT),
SOBRESALIENTE (SB), MATRICULA DE HONOR (MH).

{
"grados":
[
{
"codigo": "1", /*String (opcional)*/
"nombre": "Grado en Ingenieria Industrial", /*String (opcional)*/
"creditos_conseguidos": "40", /*String (opcional)*/
"creditos_pendientes": "60", /*String (opcional)*/
"asignaturas":
[
{
"nombre": "Calculo tecnico 1", /*String (opcional)*/
"convocatoria": "Febrero", /*String (opcional)*/
"creditos": "6", /*String (opcional)*/
"tipo": "Troncal", /*String (opcional)*/
"calificacion": "NOTABLE", /*String (opcional)*/
"nota": "7,7", /*String (opcional)*/
"info": "true" /*boolean (aprobado)*/
},
{
"nombre": "Calculo tecnico 2", /*String (opcional)*/
"convocatoria": "Junio", /*String (opcional)*/
"creditos": "4",/*String (opcional)*/
"tipo": "Obligatorio", /*String (opcional)*/
"calificacion": "SUSPENSO", /*String (opcional)*/
"nota": "4,1", /*String (opcional)*/
"info": "false" /*boolean (suspenso)*/
}
]
}
]
}
}
NOTA: Los años académicos, las titulaciones y las notas se mostrarán en el orden que se
reciben del servicio de la universidad.

Appcrue también admite que se muestren las notas de diferentes cursos de enseñanza. Se
deberá devolver la información como en el siguiente ejemplo:
{
"grados": [
{
"codigo": "27",
"nombre": "Grado en Administración y dirección de empresas",
"creditos_conseguidos": "240,00",
"creditos_pendientes": "90,00",
"asignaturas": [
{
"codigo": "273002",
"nombre": "Matemáticas financieras",
"convocatoria": "Primera",
"creditos": "6,00",
"tipo": "OBLIGATORIA",
"calificacion": "APROBADO",
"nota": "6,10",
"info": true
}
]
},
{
"codigo": "50",
"nombre": "Máster en marketing",
"creditos_conseguidos": "50,00",
"creditos_pendientes": "250,00",
"asignaturas": [
{
"codigo": "255002",
"nombre": "Marketing 1",
"convocatoria": "Primera",
"creditos": "6,00",
"tipo": "OBLIGATORIA",
"calificacion": "APROBADO ",
"nota": "7,00",
"info": true
}
]
}
]
}

8 MIS EXÁMENES A NIVEL USUARIO
El servicio nativo de Mis exámenes muestra los exámenes que tiene el estudiante. El funcionamiento
sería como el que se detalla a continuación.
Request: AppCrue envía el TOKEN del usuario e idioma.

Response: Devolver mis exámenes en el formato JSON especificado a continuación (se mostrará en
las apps tal cual venga los valores para cada uno de los campos y en el orden devuelto).
{
"alumnoExamen": [
{
"CURSO_ACADEMICO": "2017-18", /*String type */
"COD_PLAN": "2036", /*String type */
"PLAN": "GRADO EN FISIOTERAPIA (ALCORCON)", /*String type */
"COD_ASIGNATURA": "2036024", /*String type */
"ASIGNATURA": "FISIOTERAPIA EN ESPECIALIDADES CLINICAS: NEUROLOGICA, CARDIO-
RRESPIRATORIA Y VASCULAR", /*String type */
"CUATRIMESTRE": "Segundo semestre", /*String type */
"CURSO": "4", /*String type */
"COD_GRUPO": "4AT", /*String type */
"DESC_TURNO": "TURNO DE TARDE", /*String type */
"CAMPUS": "ALCORCÓN", /*String type */
"CONVOCATORIA": "S", /*String type */
"TIPO_EXAMEN": "Teórico", /*String type */
"FECHA": "21-09-2017", /*String type */
"HORA": "16:00-19:00", /*String type */
"AULAS": "107 Aulario II", /*String type */
"OBSERVACIONES": null /*String type */
},
{
"CURSO_ACADEMICO": "2017-18", /*String type */
"COD_PLAN": "2036", /*String type */
"PLAN": "GRADO EN FISIOTERAPIA (ALCORCON)", /*String type */
"COD_ASIGNATURA": "2036024", /*String type */
"ASIGNATURA": "FISIOTERAPIA EN ESPECIALIDADES TEORICAS", /*String type */
"CUATRIMESTRE": "Segundo semestre", /*String type */
"CURSO": "4", /*String type */
"COD_GRUPO": "4AT", /*String type */
"DESC_TURNO": "TURNO DE TARDE", /*String type */
"CAMPUS": "ALCORCÓN", /*String type */
"CONVOCATORIA": "S", /*String type */
"TIPO_EXAMEN": "Teórico", /*String type */
"FECHA": "24-01-2018", /*String type */
"HORA": "16:00-19:00", /*String type */
"AULAS": "107 Aulario II", /*String type */
"OBSERVACIONES": null /*String type */
}
]
}

9 MI HORARIO A NIVEL USUARIO

El servicio nativo de Mi horario muestra el horario que tiene el estudiante. El funcionamiento sería
como el que se detalla a continuación.
Request: AppCrue envía el TOKEN del usuario, junto con el idioma y el día actual (formato
mm/dd/aaaa)
Param2 → lan=es
Param3 → fecha=01/30/2022
Response: Devolver mi horario en el formato JSON especificado a continuación (se mostrará en las
apps tal cual venga los valores para cada uno de los campos y en el orden devuelto). Se deberán
devolver las clases que el usuario tenga a partir del día actual (sin incluir clases de días anteriores).
Ejemplo:
{
"day": "20220112",
"schedule": []
},
{
"day": "20220113",
"schedule": [
{
"starts": "19:00",
"ends": "21:00",
"location": " (0016P2004) L22 - AULA DE INFORMÁTICA",
"subjectname": "FUNDAMENTOS DE LAS BASES DE DATOS",
"degreename": "GRADO EN INGENIERÍA INFORMÁTICA",
"groupname":"GRUPO 4 (PRÁCTICAS DE LABORATORIO)"
},
{
"starts": "15:00",
"ends": "16:00",
"location": " (0016P2004) L22 - AULA DE INFORMÁTICA",
"subjectname": "ASIGNATURA DE EJEMPLO",
"degreename": "GRADO EN INGENIERÍA INFORMÁTICA",
"groupname":"GRUPO 4 (PRÁCTICAS DE LABORATORIO)"
}
]


10 MENSAJE DOCENTE-ESTUDIANTE
Esta funcionalidad es para disponer que los usuarios con rol PROFESOR puedan enviar
notificaciones a sus alumnos, para ello es necesario que la universidad que lo desee exponga un
servicio REST informando de las etiquetas que un profesor puede enviar estas notificaciones.
Funcionalidad destinada a las universidades con sistemas de etiquetas en el login, y se activará
bajo demanda.
Url:
https://<base_url>/notification_targets
token String Token que identifica al usuario
Devuelve:
Campo Tipo Obligatorio Descripción
notification_targets Array X Array de objetos de etiquetas notificables
Notification_targets:
subjects Array of Lista de etiquetas relacionadas con las asignaturas

Strings que el profesor imparte para enviar los push.
degrees Array of Lista de carreras relacionadas con las asignaturas

Strings que el profesor imparte para enviar los push.
groups Array of Lista de etiquetas relacionadas con los grupos de

Strings asignaturas que el profesor imparte para enviar los
push.
campus Array of Lista de etiquetas relacionadas con los campus que

Strings el profesor imparte para enviar los push.

Ejemplo:
{
"notification_targets": {
"subjects": ["S100885::Estadística", "S100886::Microeconomía", "S100887::Ma-
croEconomía", "S100888::Optimización Matemática"],
"degrees": ["D100885::Doble Grado en Dirección de Empresas y Marketing"],
"groups": ["G100885::Grupo 1 Mañana Estadística Empresarial y Financiera"],
"campus": ["C100885::Campus 1"]
}
}
Códigos de respuesta:
Código Descripción
200 Respuesta correcta.
401 Usuario no autorizado
403 Acceso denegado/prohibido
500 Error en el servicio

DISEÑO EN LA APLICACIÓN:

11 DIRECTORIO
El usuario podrá realizar búsquedas en el directorio corporativo de la universidad según los

siguientes criterios: Nombre y/o apellidos, correo electrónico o teléfono.
El resultado mostrará los contactos que coincidan con la búsqueda.
Por cada contacto de la universidad se podrá mostrar:
• Nombre y apellidos
• Lista de filiaciones asociadas al usuario. Por cada filiación se podrá mostrar:
o Nombre de la filiación
o Unidad organizativa
o Puesto o cargo
o Correo electrónico
o Teléfono
o Dirección postal
o Otra información asociada a la filiación
• Otra información:
o Lista de teléfonos, que no aparezcan en las filiaciones.
o Lista de correos, que no aparezcan en las filiaciones.
o Otra información asociada al usuario
En el listado de resultados de búsqueda se mostrará el nombre del contacto y su rol, teniendo que
pulsar el usuario sobre el contacto para acceder al detalle de la información.
Los detalles de correo electrónico y teléfono del contacto permitirán la apertura automática de las
aplicaciones gestor de correo y teléfono.
La información sobre el directorio se obtendrá mediante una petición POST recogiendo los datos en
formato JSON.
A continuación, se incluye el formato necesario JSON del servicio REST que debe de tener la
Universidad que devolverá la información necesaria.
Url:
https://<base_url>/directory_search

Parámetros (POST):
filter String Cadena de búsqueda. Los criterios de búsqueda pueden

ser por nombre y/o apellidos, correo electrónico y telé-
fono.
pageNumber Integer Número de página, iniciada en 0.
pageItemsNumber Integer Número de elementos por página.
locale String Código de idioma para la respuesta. Posibles valores:

− es: Castellano (valor por defecto)
− en: Inglés
− ca: Catalán, Valenciano
− gl: Gallego
Devuelve:
contacts Array X Lista de contactos que coinciden con los parámetros de bús-
queda. Array de objetos de tipo Contact.
totalItems Integer X Número total de contactos. Este número no es el número de ele-

mentos de la lista de contactos contenida en contacts, sino el to-
tal de registros que se van paginando.
totalPages Integer X Número total de páginas.
Cada objeto Contact contiene:
uid String X Identificador único del contacto en la universidad.
cn String X Nombre y apellidos del contacto.
emails Array Lista de correos electrónicos que no estén asociados en las filia-
ciones. Array de objetos de tipo cadena. Por ejemplo: ["pa-
fli@uni.es", "pafli@gmail.com"]

phones Array Lista de teléfonos que no estén asociados en las filiaciones. Array
de objetos de tipo cadena. Por ejemplo: ["3425", "678123456"]
filiations Array Lista de filiaciones del contacto. Array de objetos de tipo Filia-
tion.
others String Otra información asociada al contacto. Para mostrar la informa-

ción en distintas líneas, se pueden concatenar las cadenas con el
separador . Por ejemplo, "Esto es un ejemplo de in-
formación del contacto", se mostrará como:
Esto es un ejemplo
de información del contacto
Cada objeto Filiation contiene:
Atributo Tipo Obligatorio Descripción
descrip- String X Nombre o descripción corta de la filiación. Ejemplo: ALU, PDI,

tion PAS, AAAA, EXT, etc.
ou String X Unidad organizativa.
business- String Puesto o cargo.

Category
email String Correo electrónico
phone String Teléfono.
postalAd- String Dirección postal. Para mostrar la información en distintas líneas,

dress se pueden concatenar las cadenas con el separador . Por
ejemplo, "Edificio Correos y Almacén Campus de Espi-
nardo", se mostrará como:
Edificio Correos y Almacén
Campus de Espinardo
others String Otra información asociada a la filiación. Para mostrar la informa-

ción en distintas líneas, se pueden concatenar las cadenas con el
separador . Por ejemplo, "Tutorías: Lunes y Martes
de 9:00-10:30", se mostrará como:
Tutorías:
Lunes y Martes de 9:00-10:30

Ejemplo lista vacía:

{
"contacts": [],
"totalItems": 0,
"totalPages": 0
}
Ejemplo lista 5 contactos:

{
"contacts": [
{
"uid": "294501",
"cn": "ALEJANDRO FRANCO RUIZ",
"emails": [
"afranco1@gmail.com"
],
"phones": null,
"others": "Otra información relacionada con el contacto",
"filiations": [
{
"description": "ALU",
"ou": "Grado en Ciencia Política y Gestión Pública",
"businessCategory": null,
"email": " afranco1@univ.es",
"phone": null,
"postalAddress": null,
"others": "Otra información relacionada con la filiación del contacto"
}
]
},
{
"uid": "536452",
"cn": "ANA ROSA RUIZ LAZ",
"emails": [],
"phones": [],
"filiations": [
{
"description": "ALU",
"ou": "Grado en Administración y Dirección de Empresas",
"email": "anarosaruiz@univ.es",
"phone": null,
"others": null
}
]
},
{
"uid": "565712",
"cn": "ANTONIO FRANCISCO PEREZ MARIN",
"emails": null,
"phones": [
"612345678"
],
"filiations": [
{
"description": "PAS1",
"ou": "Servicio de Correos",
"businessCategory": "J.NEG. N.20 CORREOS",
"email": "afpm@univ.es",
"phone": "3107",

"postalAddress": "Edificio Correos y Almacén $ Campus de Espinardo",
"others": null
}
]
},
{
"uid": "419874",
"cn": "CARLOS NAVARRO FRANCO",
"emails": [
"cnavfranc@gmail.com"
],
"phones": [],
"filiations": [
{
"description": "PDI",
"ou": "Métodos de Investigación y Diagnóstico en Educación",
"businessCategory": "ASOCIADO T.PARCIAL",
"email": " cnavfranc@univ.es",
"phone": "8000",
"postalAddress": "Facultad de Educación $ Campus de Espinardo",
"others": null
},
{
"description": "PAS1",
"ou": "Sección de Proyectos y Aplicaciones",
"businessCategory": "P. BASE SISTEMAS Y T.I.: ADM. ELECTRONICA",
"email": " cnavfranc@univ.es",
"phone": "7345",
"postalAddress": "Edificio ÁTICA $ Campus de Espinardo",
"others": "Otra información relacionada con la filiación del contacto"
},
{
"description": "TIC",
"ou": "ATICA",
"email": null,
"phone": null,
"others": null
}
]
},
{
"uid": "647895",
"cn": "DANIEL FRANCIS SANCHEZ MARTINEZ",
"emails": [
"danielfsm@univ.es"
],
"phones": [],
"filiations": [
{
"description": "AAAA",
"ou": "Asociado de Antiguos Alumnos y Amigos de la Universidad de Murcia",
"email": "danielfsm@gmail.com",
"phone": null,
"others": null
}
]
}
],
"totalItems": 5,
"totalPages": 1
}


12 CALENDARIO ÚNICO: Servicio calendario personal
Esta funcionalidad es para disponer que los usuarios con puedan tener un calendario unificado en
la aplicación. Actualmente en el calendario se muestran los eventos de la universidad. Con este
servicio, se fusionará el calendario personal del usuario logado que disponga en la universidad con
el calendario de eventos. Y así de un vistazo poder ver lo que tiene en un día, los eventos de la
universidad y lo que tenga programado para ese día (Horario, exámenes, tutorías...).
Url:
https://<base_url>/user_calendar
token String Si Token que identifica al usuario

Formato 20201010, es decir AÑO(4digitos)MES(2
fromDate String No
digitos)DIA(2 digitos), sin espacios ni separadores.
Formato 20201010, es decir AÑO(4digitos)MES(2
toDate String No digitos)DIA(2 digitos), sin espacios ni separado-
res.
No (si no se especifica se
Posibles valores “EXAMEN”, “HORARIO”, “REVI-
category String devuelve todos los eventos
SION_DE_EXAMEN”, “TUTORIA”
para ese usuario)
lang String Si Idioma
Devuelve:
calendar Array X Lista de eventos del usuario de tipo calendar.

Calendar:
date String SI Fecha del evento personal: formato yyyy-mm-dd.
events Array of SI Lista de eventos para ese día para ese usuario de
Strings tipo Event.
Event:
id Number NO Identificador del evento. Si no se envía se genera

internamente
title String SI Nombre del evento
description String SI Descripción del evento
url String NO Url del evento
nameAuthor String SI Nombre del autor
imgDetail String NO Imagen de detalle
type String SI Posibles valores “EXAMEN”, “HORARIO”, “REVI-

SION_DE_EXAMEN”, “TUTORIA”
startsAt String SI Timestamp con la hora de inicio del evento
endsAt String SI Timestamp con la hora de inicio del evento
Ejemplo:
{
"calendar": [
{ // day item
"date": "2020-04-21"
"events": [
{ // event item
"id": 1033992237,
"title": "Tutoria",
"description": "Tutoria asignatura Matemáticas",
"url": "http://universidad.es/tuperfil/tutorias",
"nameAuthor": "Autor",
"imgDetail": "http://test.host/uploads/event/logo/1033992237/example.png",
"type": "TUTORIA",
“startsAt”: “1575990139”,

“endsAt”: “1575990139”
},
{ "id": 1033992247,
"title": "Clase",
"description": "Clase asignatura Inglés",
"type": "HORARIO",
“startsAt”: “1575990139”,
“endsAt”: “1575990139”
}
]
},
{ // day item
"date": "2020-04-22"
"events": [
{ "id": 1033945237,
"title": "Tutoria",
"description": "Tutoria asignatura Matemáticas”,
"type": "TUTORIA,
“startsAt”: “157593453”,
“endsAt”: “157593453”,
},
{ // event item
"id": 1033992449,
"title": "Clase",
"description": "Clase asignatura Inglés",
"type": "HORARIO,
“startsAt”: “157593453”,
“endsAt”: “157593453”,
}
]
}
]
}

13 LECTURA CÓDIGOS QR
Esta funcionalidad incluye:
13.1 Creación de códigos QR desde el Gestor

Desde el apartado “Códigos QR” del menú lateral del gestor la universidad puede crear códigos QR
y descargarlos para su posterior uso. La creación requiere que se le añada un título (para poder
localizarlo fácilmente en el listado de QRs del gestor) y un Texto que será el que contenga el QR. Se
puede crear de forma individual o cargado un fichero csv con un listado de QR.
13.2 Widget “Presencia QR”

Este widget permite la lectura de códigos QR desde la app (generado desde el gestor de Appcrue o
no). La universidad puede añadirlo en cualquier apartado de la sección privada de la app.

13.3 Trazabilidad de la lectura
13.3.1 Desde el gestor

Accediendo a “Códigos QR” del menú lateral del gestor, se puede descargar un fichero con todas las lecturas
que se han realizado de un código QR. El fichero incluye el día y hora de la lectura, así como el nombre,
apellidos y DNI del usuario que lo realizó.
13.3.2 Envío automático de lecturas

Si la universidad lo prefiere se puede enviar un json automáticamente con la información del
momento y el usuario que ha realizado la lectura del un código QR (válido para QR generados o no
desde el gestor).
El json que se envía contiene la siguiente información:
{
"qr ":"SALON DE ACTOS"
"email": "D001@universia.es",
"firstname": "PABLO",
"lastname": "GARCIA SANCHEZ",
"role": "ESTUDIANTE",
"username": "D001",
"fecha":"1620730112" ,
“token”:”tyufq”
}
El endpoint de destino se configura se incluye en la configuración del widget. La URL debe ser https
y la invocación se realiza por POST.
Se pueden enviar respuestas personalizadas que se mostrarán en la pantalla del móvil una vez el
usuario realice la lectura del código QR. Los mensajes se podrán personalizar para los códigos de

respuesta 200 en caso de lectura correcta y 406 en caso de error. La respuesta debe tener el siguiente
formato:
{
"message": "Mensaje que desee mostrar en la pantalla "
}

14 SERVICIOS ASOCIADOS A LA vTUI
La plataforma vTUI tiene algunos módulos adicionales (plugins o addons) que pueden activarse
para proporcionar la siguiente funcionalidad:
• Emulación NFC/HCE: Módulo que permite emular una TUI mediante NFC y que almacena los datos
de la tarjeta en el sistema HCE.
VTUI - AppCRUE -
Compatibilidad NFC-HCE.docx
• Identificación segura con código QR dinámico: Sistema de validación de la vTUI y de su propietario

mediante códigos QR de un solo uso.
VTUI - AppCRUE -
Servicio de códigos dinámicos v1.2.docx
• Activación de servicios con código QR: Permite escanear un QR de la universidad y activar un ser-
vicio JSON con la información del QR escaneado y del usuario que lo hizo.
VTUI - AppCRUE -
Activación de servicios con QR para universidades v1.0.docx
• Activación de servicios con lectores Elatec mediante BLE: Este módulo es capaz de comunicarse
de forma segura con un lector Elatec por BLE, usando un protocolo propietario de Elatec. La comu-
nicación consiste en el envío de un dato identificativo del titular de la vTUI. Y se usa para que el
lector Elatec pueda activar máquinas multifuncionales de impresión.
VTUI Servicios REST

para obtencion de configuracion lector Elatec BLE v1.0.docx

• Apertura de cerraduras SALTO con NFC: Permite comunicarse con los sistemas de Salto para inter-
cambiar y mantener las “llaves“ del usuario e instalarlas en su app. El sistema funciona solamente
con NFC (librería de Salto) en teléfonos Android.

15 ALTA DE BETATESTERS EN ANDROID/IOS

Para poder probar las apps en las fases de pruebas es necesario darse de alta como testers tal y
como se explica a continuación.
Testers AppCrue -
Manual.docx

16 MODELOS DE INTEGRACIÓN EXISTENTES EN LA PLATAFORMA
APPCRUE
Se permite integrar los contenidos propios de la Universidad a través de los siguientes modelos.
16.1 Apertura de app nativa
AppCrue permite poder abrir cualquier aplicación nativa tanto propia de la universidad como de
terceros y para ambas plataformas: IOS y Android.
Para el caso de Android solo será necesario indicar el paquete de la App. En el caso de IOS será
necesario indicar tanto el esquema como el paquete de la app.
Ambas plataformas tienen el mismo funcionamiento. En caso de no tener la app instalada en el
dispositivo móvil, se abre la página del store. En el caso de estar ya instalada en el dispositivo, abre
la aplicación correspondiente a ese paquete.
También se puede añadir el paso de parámetros, los valores contemplados son:
• Token de Appcrue
• Token de la universidad
• Import code

16.2 Webview
Se puede incluir en la app cualquier contenido https haciendo uso de los siguientes métodos.
La gestión de cookies depende en su totalidad de la universidad, aunque AppCrue traslade las

cookies de navegaciones anteriores al abrir un webview no tenemos conocimiento del estado de
estas.
16.2.1 Método GET
Permite pasar parámetros en la propia cabecera.

Mantiene las cookies de las navegaciones anteriores del usuario por los webviews de la app. Se
borrarán las cookies al hacer logout o al volver a hacer login tras expirar el token de la sesión.
Los valores de parámetros contemplados son:
• <token>: token para acceder a los servicios de Universidad.

• <user_id>: Id del usuario en la base de datos de AppCrue.
• <app_identifier>: Acrónimo de la universidad en minúsculas.
• <import_code>: ID o código del usuario en la universidad.
• <appcrue_token>: token para acceder a los servicios de AppCrue.
16.2.2 Método POST
Se recomienda utilizar este método si se quiere autenticar automáticamente al usuario en la web

de destino. Permite el envío de parámetros en el body de la petición.
Los valores de parámetros contemplados son:

Códigos de error para el deslogado de usuarios

Para los métodos Get y Post con envío de parámetro token, en el caso en el que la web devuelva
los códigos de error 407 o 498 se deslogará al usuario.
16.2.3 Método bearer
Haciendo uso del esquema de autenticación HTTP que involucra tokens de seguridad llamados
bearer tokens. Este token es el generado por la universidad. En el destino es donde se debe
identificar al usuario a partir del token. Los parámetros de identificación se deben añadir en la
URL.
El valor de parámetro contemplados es:

Comportamiento iOS:
Los webviews que sean por bearer se inician siempre sobre un webview limpio de cookies. La
gestión de la navegación entre páginas web con el token, así como de las cookies que necesiten los
enlaces o redirecciones entre éstas, recaen en el desarrollo web, por tanto, la app no mantendrá
estados ni sesiones que no hayan sido gestionadas por la propia web. Se recomienda, por tanto, el
uso del método bearer exclusivamente a páginas que autentiquen mediante bearer token en el
header de la petición y no dependan de cookies para evitar que el usuario esté continuamente
introduciendo sus credenciales.
Comportamiento Android:
Para los tres métodos el uso de los parámetros se debe hacer de la siguiente forma:
nombreParametro=<valorParametro>

16.2.4 Deslogado de usuarios por error en respuesta
En los casos en los que se reciba un error 407 o un error 498 se deslogará al usuario de la aplicación.
16.3 Apertura de URL en navegador
Además de la integración por Webview se puede incluir la apertura de una URL en navegador
externo. En este caso la app no gestionará cookies.
Permite incluir en la cabecera el parámetro del token de la aplicación.
Esta funcionalidad sólo se debe de usar en caso de que el webview no soporte algo de la página web
destino. Ya que es menos deseable, porque te provoca sacarte de la aplicación y no fomenta su uso
16.4 API Externa

Este modelo se contempla en el siguiente punto de este documento

17 APIS EXTERNAS
Se dispone de APIs externas para gestionar las noticias, eventos, retos y promociones de la
aplicación, y poder automatizarlo desde las universidades. Está documentado en el APIDOC en
las urls que se muestran a continuación:
URL_prod: https://appuniversitaria.universia.net/apidocs/ext-3.2.html
URL_pre: https://pre.appuniversitaria.idsant.com/apidocs/ext-3.2.html
User: appcrue_ext
Pass: ujg754tj9$
Para automatizar el envío de notificaciones push se dispone del API de Twinpush:

https://developers.twinpush.com/developers/api?class=sidebar-header#api-concepts
Se deberá informar al equipo de integración de Appcrue
(integracionappcrue@universia.es)de las IPs desde las que se vayan a realizar las llamadas
al API para autorizarlas.
Para poder hacer pruebas de llamada a la API de forma ágil se recomienda utilizar Postman o
SoapUI.

17.1 API de mensajes y notificaciones push
Actualmente utilizamos TwinPush (https://twinpush.com/) para el envío de mensajes push a

los dispositivos, esto permite que la gestión de mensajes push se pueda realizar a través de
3 medios: Gestor de contenidos de la App, Plataforma TwinPush y Api externa de TwinPush.
Las notificaciones llegarán como una “notificación push” al dispositivo. En la aplicación el
mensaje aparecerá en el menú mi perfil, en el apartado notificaciones.
La llamada a la API correspondiente con el servicio de POST se encuentra en la
documentación del siguiente enlace:
https://developers.twinpush.com/developers/api?class=sidebar-header#api-concepts
En este documento se detallan los siguientes métodos:

Recurso Descripción
POST /apps/${app_id}/notifications Creación y envío de

notificaciones
GET /apps/${app_id}/notifications/${notif_id}/report Detalle y estadísticas del envío
DELETE Eliminar del buzón del usuario

/apps/${app_id}/devices/${device_id}/notifications/${notification_id} un mensaje
17.1.1 Características de la segmentación de las notificaciones:
Los mensajes push se podrán enviar a usuarios individuales, a toda la universidad o a grupos
segmentados de usuarios.
La segmentación se puede hacer por una propiedad o por un segmento.
a) Propiedad
Las propiedades son pueden ser las siguientes:
-Las etiquetas que describen al usuario enviadas en el servicio de datos de usuario
(asignaturas, facultades, etiquetas personalizadas…)
-Roles de usuario: información que se envía en el servicio de datos de usuario.
-Alias del usuario (“user_name” enviado en el servicio de datos de usuario)
Las propiedades que provienen de etiquetas enviadas por la universidad estarán
disponibles a partir del momento en el que un usuario con esa etiqueta logue en la app.
Si no hay ningún usuario logado con una determinada propiedad/etiqueta, esta no estará
disponible ni en la plataforma de notificaciones ni en el Gestor de contenidos y si se
intenta hacer uso de ella vía API dará error de envío.

b) Segmentos
Conjuntos de propiedades creados desde la plataforma de notificaciones. La creación de
segmentos se realiza desde la plataforma de TwinPush de la siguiente manera:
1) Acceder al apartado de “Segmentos”, “Crear nuevo segmento”:
2) Escoger las propiedades que incluirá el segmento:

3) Escoger el tipo de discriminación
4) Asignar un nombre al segmento
Una vez creado el segmento se mostrará el número de usuarios que cumplen con las
especificaciones del segmento:
Además de la creación de segmentos por las propiedades ya descritas, también se pueden crear

grupos de usuarios que cumplan las siguientes características:
- “Log” permite discriminar los envíos entre los usuarios que están logados en la app y
los que la tienen descargada, pero no están logados
Disponible en “segmentos”, “otras propiedades”,”login”
17.1.2 Uso de las propiedades y los segmentos
Como se mencionaba antes se puede realizar la segmentación por una propiedad o un segmento.
La segmentación por propiedad permite un valor de esta o una cadena de valores. La cadena de
valores no discrimina por el cumplimiento de todos los valores, sino que suma los destinatarios que
cumplan cada valor individualmente.
En el siguiente ejemplo se segmenta por la propiedad “subjects” y la cadena de valores Historia de
la filosofía y matemáticas.
POST / https://appcrue.twinpush.com/api/v2/apps/:application_id/notifications
{
"broadcast": false,
"devices_ids": [],
"devices_aliases": [],
"segments": [],
"target_property": {
"name": "subjects",
"values": ["29001-362::(2019-20) HISTORIA DE LA FILOSOFÍA","23301-400::(2019-20) MATEMÁTICAS
” ]
},
Esta notificación la recibirán todos los estudiantes de “29001-362::(2019-20) HISTORIA DE LA

FILOSOFÍA" y todos los estudiantes de ","23301-400::(2019-20) MATEMÁTICAS”
En este otro ejemplo se segmenta por la propiedad “Devices_aliases” y la cadena de usuarios

elegidos:
{
"broadcast": false,
"devices_ids": [],
"devices_aliases": [user1@universia.es, user2@universia.es, user3@universia.es],
"segments": [],
"name": "subjects",
"values": []
},
La segmentación por segmentos permite el uso de una cadena de estos, incluyendo como destinatari
os a todos aquellos usuarios que cumplen por lo menos uno de los segmentos:
{
"broadcast": false,
"devices_ids": [],
"segments": [“Target Estudiantes Arquitectura Campus Madrid”, “Target profesores”],
"name": "",
"values": []
},
17.1.3 Creación y envío de mensajes push:
A continuación, se muestra cómo se tiene que hacer la llamada al API de TwinPush de una
notificación push
URL destino https://appcrue.twinpush.com/api/v2/apps/:app_id/notifications
Application. Identifica-
:app_id dor único de la universi-
dad
Método POST
Content-
application/json
Type
Petición
“True” para enviar a todos los disposi-
broadcast Booleano
tivos registrados en la app.
devices_ids Listado con device_id específicos String

Listado con alias específicos. La infor-
mación de este campo corresponde al
“username” que se envía en el servicio
devices_aliases String
de datos de usuario.
A cada device_id se le asigna un de-
vice_aliase
Dispositivos que cumplen las condicio-

nes de cualquiera de los segmentos se-
leccionados previamente creados
Los segmentos se crean desde la plata-
forma de Twinpush, combinando eti-
segments String
quetas (property)
.
La notificación se envía a todos los
usuarios que cumplan uno de los seg-
mentos de la cadena.
Dispositivos que tienen cualquiera de

los valores seleccionados para una pro-
piedad dada.
Este parámetro es un objeto JSON for-
mado por dos atributos adicionales:
target_property nombre: identificador de propiedad de Object y String
cadena
valores: conjunto de valores de cadena
que los dispositivos tendrán que coin-
cidir para ser seleccionados como des-
tino de la notificación
Hora a la que se enviará la notificación

push, en formato aaaa-MM-dd HH:
Send_since mm: ss Z. Si no se establece o si el va-
lor es null, la notificación se enviará in-
mediatamente.
Paráme-
tros del
title Dato necesario Texto
conte-
nido
alert Dato necesario (Cuerpo de mensaje) Texto
Apy Key Creator. Disponible en el apar-

X-TwinPush-REST-
Headers tasdo de ajustes, ver clave de autenti-
API-Key-Creator
cación de la cuenta de twinpush.
Devuelve un array con un solo objeto que representa la

Respuesta OK 200 notificación creada. La primera línea de la respuesta con-
tiene el id de la notificación.

401 El objeto no existe
402 No autorizado
KO 406 No aceptable (Formato inválido).
Entidad no procesable. Algunos de los parámetros dados

422
son incorrectos.
500 Error de servidor
Este es un ejemplo de envío de JSON con el formato correspondiente devolviendo el valor de ID

unívoco de la notificación.
{
"broadcast": true,
"title": "Este espacio para el título",
"alert": "Este espacio para el cuerpo del mensaje. Te lleva a google.prueba",
"url": "https://www.google.es/"
}
Respuesta:
200
{
"id": 912388313
}
Ejemplo con envío a dos segmentos. En este caso se enviará la notificación a todos los usuarios que
cumplan al menos uno de los segmentos.
{
"broadcast": false,
"devices_ids": [],
"segments": ["LOGIN TRUE", "ESTUDIANTE"],
"name": "",
"values": []
},
"title": "Push API TwinPush dos segmentos",
"alert": "Push via API LOGIN TRUE + ESTUDIANTE",
"url": ""
}
Estos ejemplos se encuentran en la carpeta “json_ej_push”:
• Envío a un alias determinado (Ver: alias.json)

• Envío segmentado por una asignatura (Ver: segmentación_asignatura.json)

• Envío Broadcast (Ver: broadcast_con_url.json)
• Envío a los usuarios no logados (Ver: login_false.json)

17.1.3.1 Principales diferencias entre API v2 external de Appcrue y API
Twinpush:
Api V2 Notificaciones Api twinpush
Import code asignado al Application. Identificador único de la

usuario univadmin de la universidad. Disponible en el menú de
import_code App_id
universidad. Se facilita ajustes de twinush, ver claves de au-
desde Universia. tentificación
Token asignado al usuario

X-TwinPush- Apy Key Creator. Disponible en el
univadmin de la universi-
token REST-API-Key- apartado de ajustes, ver clave de au-
dad. Se facilita desde Uni-
versia. Creator tenticación de la cuenta de twinpush.
La información de este campo corres-

ponde al “username” que se envía en
Target User' username or
app_username devices_aliases el servicio de datos de usuario.
import_code
Alias A cada device_id se le asigna un
device_aliase
17.1.4 API de reporte push
https://appcrue.twinpush.com/api/v2/apps/:application_id/notifications//${notif_id}/report
URL destino Id de la notificación. En la respuesta del servicio de crea-
:notif_id
ción de notificación se muestra este id.
Método GET
Content-
application/json
Petición Type
X-TwinPush-REST- Apy Key. Disponible en el apartasdo de ajustes, ver clave

Headers
API-Token de autenticación de la cuenta de twinpush.
La respuesta contiene lo siguientes campos:

Notification (objeto) información básica de la notificación
Respuesta OK 200
Status:
"draft": no se ha enviado aún la notificación

"sending": la notificación se está enviando
"sent": sending process has been completed
"scheduled": la notificación está programada para enviar
en el futuro
"campaign_active": campaña actualmente activa
"campaign_inactive": campaña actualmente inactiva
"campaign_expired": campaña finalizada
Delivery_count: número de envíos
Opening_count: número de dispositivos que han abierto la

notificación
Errors Listado con los errores reportado para la notifica-

ción
401 El objeto no existe
NOK 403 No autorizado
406 No aceptable (Formato inválido).
422 Error de servidor
GET / https://appcrue.twinpush.com/api/v2/apps/:application_id/notifications//${notif_id}/report
{
"notification": {
"id": "bb1b31f5f206e7ca",
"sound": null,
"alert": "This is the message displayed in Notifications Center",
"title": "Welcome to TwinPush",
"badge": "+1",
"custom_properties": {},
"tp_rich_url": null,
"delivery_speed": "normal",
"name": null,
"group_name": null,
"protected_content": false,
"send_since": "2020-02-05 11:59:05 UTC",
"type": "Notification"
},
"status": "sent",
"delivery_count": 12,
"opening_count": 0,
"errors": [
{
"level": "error",
"platform": "ios",
"key": "send-error",
"message": "BadDeviceToken",
"created_at": "2020-02-05 11:59:06 UTC"
},
{
"level": "error",
"platform": "ios",
"created_at": "2020-02-05 11:59:06 UTC"
},
{

"level": "error",
"platform": "ios",
"created_at": "2020-02-05 11:59:06 UTC"
}
]
}
17.1.5 Eliminar notificaciones
Permite eliminar el mensaje del buzón de un determinado alias.
https://appcrue.twinpush.com/api/v2/apps/:application_id /devices/${device_id}/notifica-
tions/${notification_id}
:app_id
Application. Identifivador único de la universidad
: application_id
URL destino
:device_id Identificador único del dispositivo
Id de la notificación. En la respuesta del servicio de crea-

:notif_id
ción de notificación se muestra este id.
Petición Método DELETE
OK 200
Respuesta
NOK 404 No se encuentra la notificación

17.2 API de noticias
Disponemos de los siguientes métodos para gestionar las noticias
POST /api/external/v3_2/newses Crea una noticia y añade destinatarios a través de

etiquetas
PATCH /api/external/v3_2/newses/{news_id} Actualiza una noticia. Si se quiere añadir más

destinatarios se deberá de realizar esta acción a través
del gestor.
DELETE/api/external/v1/newses/{news_id} Borra una noticia

17.2.1 Creación de noticias
A continuación, se muestra cómo se tiene que hacer la llamada al API externa de creación de una
noticia.
https://pre.appuniversitaria.idsant.com/api/external/v3_2/newses
URL destino
https://appuniversitaria.universia.net/api/external/v3_2/newses
Método POST
Tipo
application/json
MIME
Token asignado al usuario univadmin

token de la universidad. Se facilita desde Uni- Texto
versia.
Import code asignado al usuario uni-

import_code vadmin de la universidad. Se facilita Texto
desde Universia.
Si necesitas especificar idioma pasar

news[title] Texto
como tittle_<cod_idioma>.

news[description] Texto
como description_<cod_idioma>.

news[body] Texto
como body_<cod_idioma>.
Petición
Universidad (Valor
Paráme-
por defecto sino
tros
Categoría de suscripción a la que per- se incluye nada)
news[subscription]
tenece la noticia sport, science, art,
entertainment,
weather.
news[starts_at] Fecha que comienza la noticia Texto
news[ends_at] Fecha que finaliza la noticia Texto
news[foto] Foto de la noticia Base64
news[video_url] Url de un video de la noticia String
news[category] Categoría de la noticia text, video, image
0 para noticias, 1
news[section] Sección de la app donde aparecerá. actualidad, 2 am-
bas secciones.

ESTUDIANTE,
PROFESOR, PAS,
news[target_roles] Filtrado de rol para la noticia ALUMNI, PRE-
UNIVERSITARIO,
EXTERNO, TODOS.
news[target_segme Etiquetas académicas.

String
nts]
news[highlighted_el
ement_attributes][s Fecha comienzo destacado String
tarts_at]
ews[highlighted_ele
ment_attributes][e Fecha fin destacado String
nds_at]
Tipo
application/json
MIME
OK 200 Devuelve el id de la noticia creada.
Error en usuario. Usuario incorrecto o no tiene los permi-

401
sos necesarios para esta acción
Respuesta Error en los destinatarios. Universidad no se corresponde a
403
NOK la universidad del usuario
Error en los destinatarios. Tipo de destinatario no permi-

406
tido para noticias
Error en los parámetros para el servicio. Revisar documen-

422
tación
Este es un ejemplo de envío de JSON con el formato correspondiente (en este caso se tienen que
proporcionar las credenciales de token e importcode emisor para cada universidad), devolviendo el
valor de ID unívoco de la noticia, necesario para poder borrar/actualizarla a posteriori.
POST /api/external/v3_2/newses
{
"news": {
"starts_at": "2020-02-06",
"category": "image",
"section": "2",
"title_es": "Noticia creada por API tag univertity.PRUEBA3.CON ROL ESTUDIANTE",
"title_en": "Some title in en",
"body": "Noticia creada por API",
"foto_url": "https://img.blogs.es/anexom/wp-content/uploads/2018/12/42707058715_61bbdc578f_k.jpg
",
"target_segments": ["degrees::DG01S::GRADO EN CIENCIAS DE LA ACTIVIDAD FÍSICA Y DEL DEPORTE (PLA
N 2015)"
],
"target_roles": [ "ESTUDIANTE" ]
},
"import_code": " univadmin_code_001",
"token": " univadmin_code_001"
}

Respuesta:
200
{
"id": 912388313
}
NOTA: En la descripción de la noticia hace reconocimiento de etiquetas html para darle un diseño
exclusivo. Las etiquetas que aceptamos son: p ul li div span strong b em cite dfn i big small font tt a
u del s strike sup sub h1 h2 h3 h4 h5 h6 br
17.2.2 Borrado de noticias
Para el borrado de la noticia vía API, es necesario recuperar el id que se devuelve al dar de alta la
noticia y a continuación realizar la llamada al servicio de borrado “/api/external/v1/newses” con
método DELETE indicando:
- id: id de la noticia devuelto al dar de alta la noticia.
- import_code: asociado al usuario que va a borrar la noticia.
- token: token de autorización del usuario que va a borrar la noticia.
https://pre.appuniversitaria.idsant.com/api/external/v1/newses
URL destino
Método DELETE
Paráme-
Petición id News id
tro
OK 200
Respuesta
NOK 404 No se encuentra la noticia
17.2.3 Actualizar una noticia
https://pre.appuniversitaria.idsant.com/api/external/v3_2/newses/{news_id}
URL destino
https://appuniversitaria.universia.net/api/external/v3_2/newses/{news_id}
Método PATCH
Petición Tipo
application/json
MIME

token de la universidad. Se facilita desde Uni- Texto
Paráme- versia.
tros Import code asignado al usuario uni-
desde Universia.

news[title] Texto

news[description] Texto

news[body] Texto
como body_<cod_idioma>.
news[starts_at] Fecha que comienza la noticia Texto
news[ends_at] Fecha que termina la noticia Texto
news[foto] Foto de la noticia Base64

news[url] String
como url_<cod_idioma>.
news[video_url] Url de un video String
news[category] Categoría de la noticia text, video, image
0 para noticias, 1
news[section] Sección de la app donde aparecerá. actualidad, 2 am-
bas secciones.
ESTUDIANTE,
PROFESOR, PAS,
news[target_roles] Filtrado de rol para la noticia ALUMNI, PRE-
UNIVERSITARIO,
EXTERNO, TODOS.
news[target_segme
Etiquetas académicas. String
nts]
news[highlighted_el
ement_attributes][s Fecha comienzo destacado String
tarts_at]
ews[highlighted_ele
ment_attributes][e Fecha fin destacado String
nds_at]
Tipo
application/json
Respuesta MIME
OK 200 Updated. Noticia actualizada.

NOK
404
Ejemplo de envío y respuesta
PUT /api/external/v3_2/newses/news_id
{
"news": {
"starts_at": "2019-12-17",
"category": "text",
"section": "0",
"title_es": "Titulo en es",
"title_en": "Some title in en",
"description": "Descripcion en es",
"target_segments": [
"tag1",
"tag2"
],
"target_roles": [
"TODOS"
]
},
"import_code": "univadmin_code_001",
"token": "token_univadmin_001"
}
Respuesta:
200
{
Updated
17.3 API de eventos
Disponemos de los siguientes métodos para gestionar los eventos:
POST /api/external/v3_2/events Crea un evento y añade destinatarios a través de

etiquetas
PATCH /api/external/v3_2events/{event_id} Actualiza un evento. Si se quiere añadir más destinatarios

se deberá de realizar esta acción a través del gestor.

DELETE /api/external/v1/events/{event_id} Borra un evento
17.3.1 Creación de eventos
A continuación, se muestra cómo se tiene que hacer la llamada al API externa de creación de un
evento.
Los eventos sólo aceptan la codificación UTF-8.
https://pre.appuniversitaria.idsant.com/api/external/v3_3/events
URL destino
https://appuniversitaria.universia.net/api/external/v3_3/events
Método POST
Tipo
application/json
MIME

Petición token de la universidad. Se facilita desde Uni- Texto
Paráme- versia.
desde Universia.

event[title] String
título del evento que se ver en la sec-
ción de eventos en la app.
Si necesitas especificar idioma pasar String

event[description]
Descripción del evento que se ver al en-
trar en el detalle del evento.
Fecha del evento String

event[starts_at]
Fecha en la que se despublica el String

event[ends_at] evento
base64 image Pú-

event[logo]
blica

base64 image Pú-

event[detail_image] blica
event[attached_file
]
event[url] Enlace externo al evento
Festivo , Seminario , Curso , Mas-

event[event_catego
terclass , Congreso , Otros .
ry]
“ESTUDIANTE”, “PROFESOR”, “PAS “,

event[target_roles] “ALUMNI”,”PRE-UNIVERSITARIO”, “EX- String
TERNO” Y“TODOS” ,
event[target_segme
nts]
Tipo
application/json
Respuesta MIME
OK 200 Id
proporcionar las credenciales de token e importcode emisor para cada universidad), devolviendo el
valor de ID unívoco deL evento, necesario para poder borrar/actualizarla a posteriori.
POST /api/external/v3_3/events
"event": {
"starts_at": "2020-01-01",
"ends_at": "2020-06-01",
"title_es": "Título del evento via API",
"title_en": "Event title via API",
"description": "Description via API",
"logo": "https://img.blogs.es/img.jpg",
"event_category": "Festivo",
"University::UCJCNEW"
],
"target_roles": [
"TODOS"
]
},
"import_code": "univadmin_code_001",
"token": "token_univadmin_001"
}
Respuesta
200

{
"id": 1033992032
}
17.3.2 Borrado de eventos
Para el borrado del evento vía API, es necesario recuperar el id que se devuelve al dar de alta el
evento y realizar la llamada al siguiente servicio “/api/external/v1/events/{event_id}” con método
DELETE indicando:
https://pre.appuniversitaria.idsant.com/api/external/v1/events/{event_id}
URL destino
https://appuniversitaria.universia.net/api/external/v1/events/{event_id}
id id del evento devuelto al dar de alta el evento.
import_code asociado al usuario que va a borrar el evento.

Petición token de autorización del usuario que va a borrar el
token
evento.
Método DELETE
OK 200
Respuesta
NOK 404 No se encuentra la notificación
17.4 API de promociones
Disponemos de los siguientes métodos para gestionar las promociones:
POST /api/external/v3/promotions Crea una promoción y añade destinatarios a través de

etiquetas
PATCH /api/external/v3/ promotions Actualiza una promoción. Si se quiere añadir más

/{promotion_id} destinatarios se deberá de realizar esta acción a través
del gestor.
DELETE Borra un evento

/api/external/v2/promotions/{promotion_id}

17.4.1 Creación de promociones
A continuación, se muestra cómo se tiene que hacer la llamada al API externa de creación de una
promoción.
https://pre.appuniversitaria.idsant.com/api/external/v3/promotions
URL destino
https://appuniversitaria.universia.net/api/external/v3/ promotions
Método POST
Tipo
application/json
MIME

Petición token de la universidad. Se facilita desde Uni- Texto
Paráme- versia.
desde Universia.

promotion[title] String
Título de la promocion que se verá en la
sección de promociones en la app.
Si necesitas especificar idioma pasar String

promotion
[description] Descripción de la promoción que se
verá al entrar en el detalle.
promotion Fecha de inicio de la promoción. String

[starts_at]
promotion Fecha en la que finaliza la promoción. String

[ends_at]
promotion [foto] base64 image
promotion
[foto_url]
promotion[url] Url destino. String

Promotion[discount
Descuento de la promoción Numérico
]
promotion[price_be
Precio antes de la promoción Numérico
fore]
promotion[price_af
Precio después de la promoción Numérico
ter]
“ESTUDIANTE”, “PROFESOR”, “PAS “,

promotion
“ALUMNI”,”PRE-UNIVERSITARIO”, “EX- String
[target_roles]
TERNO” Y“TODOS” ,
promotion
[target_segments]
Tipo
application/json
Respuesta MIME
OK 200 Id
proporcionar las credenciales de token e import_code emisor para cada universidad), devolviendo
el valor de ID unívoco de la promoción, necesario para poder borrar/actualizarla a posteriori.
POST /external/v3/promotions
body:
{
"promotion": {
"starts_at": "2020-05-27",
"ends_at": "2021-05-20",
"url": "https://google.com",
"discount": "20",
"price_before": "50",
"price_after": "20",
"title_es": "Promoción por API tag regresiva 27/03/2020",
"title_en": "Promotion title in en for API",
"description": "Descripcion de Promoción en es",
"foto_url": "https://www.cleverfiles.com/howto/wp-content/2018/03/minion.jpg",
],
"target_roles": [
"ESTUDIANTE"
]
},
"import_code": "unizar_import_code",
"token": "unizar_token"
}

RESPONSE:
{
"id": 623
}
17.4.2 Borrado de promociones
Para el borrado de una promoción vía API, es necesario recuperar el id que se devuelve al dar de alta
la promoción y realizar la llamada al siguiente servicio
“/api/external/v2/promotions/{promotion_id}” con método DELETE indicando:
https://pre.appuniversitaria.idsant.com/api/external/v2/promotions/{promotion_id}
URL destino
https://appuniversitaria.universia.net/api/external/ v2/promotions/{promotion_id}
id id de la promoción devuelto al dar de alta el evento.
import_code asociado al usuario que va a borrar la promoción.

Petición token de autorización del usuario que va a borrar la pro-
token
moción
Método DELETE
OK 200
Respuesta
NOK 404 No se encuentra la promoción

18 RECOMENDACIONES
18.1 Envío de Notificaciones Push
Las notificaciones push son una herramienta muy útil de comunicación de la universidad. Deben de
ser mensajes concretos y cortos que inciten a entrar en la aplicación para ver el contenido que se
quiere.
Cuando se automatice el envío de notificaciones push a través del API o bien si se envían
individualmente a través del gestor, se exponen las recomendaciones para su correcto uso.
Recomendaciones:
Título: No exceder de 45 caracteres, procurando que sea algo concreto y que llame la atención, ya
que será lo que primero que se vea en el dispositivo móvil. Si es más largo no se verá
adecuadamente.
Mensaje: El mensaje debe de ser entre 150 a 350 caracteres (contando los espacios).
Recomendable un máximo de 2 párrafos de texto. Si se desea completar con más texto se puede
crear una noticia para exponer todo el contenido que se desea.
18.2 Noticias
Las noticias también tienen que ser ajustadas para leerse en un dispositivo móvil, no deben de
considerarse como noticias en una web.
Recomendaciones:
Título: No exceder de 75 caracteres para que se vea adecuadamente.
Contenido: El contenido debe de ser entre 300 y 400 caracteres para que no sea demasiado largo y
no haya que hacer mucho scroll en un móvil.

19 ACCESOS AL GESTOR WEB
Los dos enlaces disponibles para el gestor son:
PREPRODUCCION: https://pre.appuniversitaria.idsant.com
PRODUCCION: https://appuniversitaria.universia.net
Las credenciales de acceso para cada entorno se proporcionan según se vaya avanzando en las fases
de lanzamiento.
Nota: EL ENTORNO DE PREPRODUCCIÓN SOLO SIRVE PARA INTRODUCIR DATOS DE

PRUEBA, NO SE TRASPASAN CONTENIDOS DE PREPRODUCCIÓN A PRODUCCIÓN.

20 MIGRACIÓN A SERVICIO DE DATOS DE USUARIO CON ETIQUETAS
Este apartado del documento va dirigido a aquellas universidades que actualmente trabajan con el
Servicio de Datos de usuario y el Servicio de Estructura y van a migrar al nuevo Servicio de datos de
usuario con etiquetas.
20.1 Proceso de migración
Actualmente la segmentación y asignación de grupos de pertenencia de usuarios se realiza a través

de la información académica que devuelve el servicio de datos de usuario, así como la estructura
académica estática de la universidad. Al publicar un contenido segmentado se cruzan estas dos
fuentes de información mostrando dicho contenido únicamente a los usuarios con los niveles
académicos escogidos.
Con el nuevo servicio de datos de usuario con etiquetas se asociarán directamente los niveles
académicos a los usuarios, evitando el cruce de dos fuentes de información y permitiendo también
la actualización automática de la información de grupos de segmentación.
La migración consistirá en:

• Transformar la respuesta del servicio de datos de usuario, devolviendo los niveles
académicos en forma de etiquetas. Además, se podrá incluir cualquier tipo de etiqueta que
la universidad desee y no únicamente las académicas. (Véase pg. 18 del documento)
La información personal del usuario deberá permanecer igual (exceptuando el campo dni
que se deberá sustituir por los campos “doc” y “document_type”)
El apartado “subjects” deberá permanecer igual.
• También se migrará a un nuevo sistema de notificaciones, permitiendo a la universidad

enviar notificaciones desde el propio gestor de AppCrue, como la plataforma específica de
envío de notificaciones (Twinpush)
• Si la universidad utiliza el API externo se tendrá que actualizar también a la nueva versión de
este. Para noticias y eventos versión 3.1 del API de Appcrue y para notificaciones, el API de
Twinpush. (Véase pg. 38 del documento). En el caso de la universidad lo solicite facilitaremos
un paquete Postman con llamadas de ejemplo al API.
• En el caso de que la Oferta Académica use como fuente la Estructura Académica. Se deberá
optar por una de las 3 opciones detallas en este documento. (Véase pg. 10).
20.2 Certificación
El servicio de datos de usuario con etiquetas se integrará en la versión 7 de la app, permitiendo

mantener de manera paralela tanto para el entorno de preproducción como el de producción ambos
entornos.

El paquete de certificación incluirá:
• Credenciales de acceso al gestor v7 para preproducción y producción

• Invitación de descarga de la versión v7 de la app
• Credenciales de acceso a la plataforma de notificaciones
El contenido que se publique desde el gestor v7 únicamente será visible en la app v7 y en el gestor
v7.
Se añadirá la etiqueta “Universidad” a todo el contenido publicado en la v6 de la app, permitiendo

su visibilidad tanto en el gestor como en la aplicación v7, se diferencia uno de otro por el nombre
del autor, siendo el de la v7 “uniadmin-siglasdelauniversidad-tag”
20.3 Publicación
En el momento de la publicación los usuarios del gestor de contenidos que utilizase la universidad
antes de la migración pasarán a funcionar para la v7 (no es necesario crear nuevos usuarios)
El proceso de publicación será el siguiente:
1. Bloqueamos la versión 6 de la aplicación con el siguiente mensaje informativo “La APP se

encuentra en proceso de migración tecnológica, durante el día dispondrás de una nueva
versión que deberás actualizar. Disculpa las molestias.”(El texto es configurable)
2. Cerramos la sesión de todos los usuarios que estén logados en la app.
3. Subimos la versión 7 a las stores.
4. Cuando la versión 7 aparezca publicada tanto en la App Store como en la Play Store (el
número de horas puede variar) se sustituye el mensaje de bloqueo por el de actualización
obligatoria de la versión de la app.

Doc. Integración Appcrue v7.6

Cargado por

Copyright:

Formatos disponibles

Doc. Integración Appcrue v7.6

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Doc. Integración Appcrue v7.6

Cargado por

Copyright:

Formatos disponibles

DOCUMENTO DE INTEGRACIÓN SERVICIOS

05/01/2021 Doc. Integración appCrue Página 1 de 83

05/01/2021 Doc. Integración appCrue Página 2 de 83

05/01/2021 Doc. Integración appCrue Página 3 de 83

Nº de revisión Descripción Autor Fecha

1 Versión inicial Integrador appCrue 18/01/2018

05/01/2021 Doc. Integración appCrue Página 4 de 83

05/01/2021 Doc. Integración appCrue Página 5 de 83

• POST: Permite en envío de parámetros en el body de la petición.

05/01/2021 Doc. Integración appCrue Página 6 de 83

Las respuestas de los servicios deben de ser:

OK 200 Respuesta correcta

OK 204 No hay error, pero la respuesta está vacía, no hay datos

Acceso denegado porque el token no es válido. Por seguridad no se informa

Problema de conexión con los servicios académicos. Los servicios no están

Usuario no encontrado en los servicios académicos. Se ha podido realizar

Timeout de conexión con los servicios académicos. El servicio no responde

Error no especificado de los servicios académicos.

ERROR 500 Error inesperado, no controlado.

05/01/2021 Doc. Integración appCrue Página 7 de 83

En este apartado se enumeran los principales requisitos de seguridad aplicados:

05/01/2021 Doc. Integración appCrue Página 8 de 83

Diagrama representativo tanto de la arquitectura actual, cómo de la infraestructura de

Ilustración 1Diagrama de Arquitectura

05/01/2021 Doc. Integración appCrue Página 9 de 83

Tipo Servicios Definición

*Servicios básicos requeridos para el funcionamiento de la app

05/01/2021 Doc. Integración appCrue Página 10 de 83

6.1 Oferta académica

05/01/2021 Doc. Integración appCrue Página 11 de 83

05/01/2021 Doc. Integración appCrue Página 12 de 83

6.2.1 Login interno

Campo Tipo Descripción

username String Username del usuario

password String Password del usuario

Campo Tipo Descripción

token String Token del usuario

refresh_token String Token que será utilizado para hacer la llamada al

expires_at String Fecha de caducidad del token en formato UNIX.

05/01/2021 Doc. Integración appCrue Página 13 de 83

6.2.3 Refresco del token

05/01/2021 Doc. Integración appCrue Página 14 de 83

6.2.3.2 Refresco del token para login interno

Parámetros entrada (POST):

Campo Tipo Descripción

refresh_token String Token de refresco del usuario

Campo Tipo Descripción

token String Token del usuario

refresh_token String Token que será utilizado para hacer la llamada al

expires_at String Fecha de caducidad del token en formato UNIX en

05/01/2021 Doc. Integración appCrue Página 15 de 83

Tipo MIME www-form-urlencoded

Token con la sesión del usuario en vigor. Es el

Tipo MIME application/json

OK 200 Ver sección estructura de la respuesta

Posibles códigos de error en la respuesta:

Acceso denegado porque el token no es válido.

Problema de conexión con los servicios académicos. Los servicios no están