Viafirma Documents

Table of Contents
1. Introduction
i. Control de Cambios
2. Instalación
i. Introducción
ii. Primera Instalación
iii. Actualización
iv. Configuración
i. Configuración mobile services
ii. Configuración viafirma platform
iii. Configuración viafirma manager
iv. Paths de FileSystem
3. Uso del API REST
i. Securización OAuth 1.0
ii. Uso del cliente Postman
iii. Uso del cliente Java
iv. Uso del cliente Swagger
4. Uso de políticas de firma y evidencias
i. Introducción
ii. Firma digitalizada
iii. Evidencias Electrónicas
iv. Políticas de Firma
5. Uso del backend
i. Panel de Control
i. Auditoría de Mensajes
ii. Configuración del Sistema
iii. Gestión de Usuarios
i. Roles
iv. Información del Sistema
i. Check de componentes
ii. Uso en tiempo real
v. Informe de Uso
vi. Sistema de Transferencias
ii. Administración
i. Aplicaciones
ii. Dispositivos
Página2
iii. Grupos
iv. Plantillas
iii. Actividad
i. Buscador de Metadatos
ii. Mensajes
iii. Notificaciones
iv. Desarrollo
i. Códigos de Errores
ii. Ejemplos de mensajes
iii. Servicios Rest
6. Uso de formularios
i. Formulario Base
ii. Formulario Avanzado
iii. Diseñador de Formularios
i. Políticas
7. Uso de plantillas
i. Creación de Plantillas
ii. Uso desde backend
iii. Uso desde móvil
iv. Servicios para Integradores
8. Procedimiento de actualización
i. Histórico de cambios y versiones
ii. Upgrades
i. Actualización 2.5.7 a 2.5.8
ii. Actualización 2.4.0 a 2.5.7
iii. Actualización 2.3.3 a 2.4.0
iv. Actualización 2.3.0 a 2.3.3
v. Actualización 2.2.12 a 2.3.0
vi. Actualización 2.2.11 a 2.2.12
vii. Actualización 2.2.10 a 2.2.11
viii. ANEXO: actualización 2.0 a 2.5
Página3
Documentación de viafirma documents
La solución viafirma documents incluye los siguientes componentes:
Viafirma Platform
Viafirma Manager
Viafirma Mobile Services
Viafirma Document iOS
Viafirma Document Android
Introduction
Página4
Control de Cambios
Esta documentación técnica está sujeta a modificaciones diarias, y alguna información o
configuración avanzada podría no estar reflejada. Consulte en cualquier caso con el
equipo de soporte técnico.
Control de documento
Descripción
Valor
Fecha actualización
25-agosto-2015
Mobile services (backend)
v2.5.8
DB Mobile Services (backend)
modelo 0.0.56
Viafirma platform
v3.8.0
Viafirma manager
v1.8.0
DB viafirma manager
modelo 1.8.0
Últimos cambios
Fecha
Cambio
18-ago-15
Actualización capítulo 1
20-ago-15
Actualización capítulo 2
22-ago-15
Actualización capítulo 4.2
24-ago-15
Actualización capítulos 4 al 7
25-ago-15
Nuevo punto 1.4.4 con explicación paths filesystem.
ControldeCambios
Página5
Instalación
En este capítulo encontrarás las siguientes secciones. Toda la información contenida en
ellas está dirigida a perfiles técnicos y con solvencia en la instalación y despliegues de
aplicaciones JEE.
1.1 Introducción
1.2 Primera Instalación
1.3 Actualización
1.4 Configuración
Instalación
Página6
Introducción
Prerequisitos
¿Qué voy a necesitar para la instalación?
Servidor de aplicaciones JEE (Tomcat o Weblogic), recomendado sobre Linux.
Base de Datos (Oracle o Postgre)
¿Qué dimensionamiento le dedico?
Se tomará como ejemplo una instalación en un mismo servidor de aplicaciones. En caso
de optar por una instalación en varios servidores, o instalación en clúster, consultar con
el soporte técnico de viafirma las opciones recomendadas para cada caso.
RAM: 8GB
Micro: recomendado, 2 micros de 6 núcleos cada uno; a 2Ghz.
Disco: 20 GB (1)
Logs: estimado 1GB por cada millón de operaciones (1)
Custodia: variable según peso y número de documentos firmados. Estimado inicial
20 GB.
Logs de auditoría: estimado 1GB por cada millón de operaciones. Estimado incial
20 GB. (2)
(1): los logs incluyen configuración de rotación, por lo que la optimización de estos logs
podrá definirse por el administrador del sistema en función a las políticas de espacio en
disco deseadas.
(2): manager consumirá la auditoría volcada por viafirma platform y la persiste en su
base de datos.
¿Qué servicios externo voy a necesitar?
Un certificado digital para la firma de documentos
Una clave pública para el cifrado de datos biométricos
Servicio de timestamping RFC3161 (ofrecido por una TSA - Timestamping
Introducción
Página7
Authority)
Servidor SMTP para el envío de correos.
Restricción de Conexiones Externas
Salidas con proxies
Si se va a necesitar salir por un proxy, es necesario informar los datos de conexión
para inlcuirlos en la configuración específica de conexión de cada componente.
Es importante detectar antes de la instalación si existen mecanismos internos que
puedan alterar las cabeceras http en las comunicaciones de red, pues el sistema
implementa varios mecanismos de securización y autenticación, como Oauth y openID,
sensible a este tipo de comportamiento y que haría inviable la instalación del servicio.
Validación de Certificados Digitales
Viafirma platform necesita verificar las fuentes de validación de las Entidades de
Certificación (CA - Certificate Authority) que hayan emitido los certificados con los que
se va a trabajar.
Sólo en el caso de que el servidor donde esté instalado viafirma platform no tenga libre
salida a internet, habrá que autorizar específicamente la lista de fuentes de validación
que se deseen, como mínimo, al servicio OCSP, CRL o endpoint en el que poder
verficar el root ca. Por ejemplo:
http://ocsp.gse.com.co
http://crl.gse.com.co/crl_sub001_ac_gse.crl
http://crl1.gse.com.co/crl_sub001_ac_gse.crl
http://certs.gse.com.co/sub/crt_sub01_ac_gse.crt
Autoridad de Tiempo (TSA)
Viafirma platform necesita conusmir los servicios de tiempo con las TSA contratadas o
autorizadas por el cliente.
Sólo en el caso de que el servidor donde esté instalado viafirma platform no tenga libre
salida a internet, habrá que autorizar específicamente la lista de autoridades de tiempo
que se deseen. Por ejemplo:
Introducción
Página8
http://tsu2.camerfirma.com:8884/tsc
Validación de Licencia
En el arranque del servidor se realiza una comprobación remota de la validez de la
licencia instalada. Para ello es necesaria tener salida a las siguientes URLs:
https://services.viafirma.com/license/
http://services.viafirma.com/licence/
Proveedores de Notificaciones Push
Se consumirán las APIs de los dos proveedores de notificaciones push, Google y
Apple, para lo que hay que autorizar las siguientes salidas:
Google Cloud Messaging (GCM) (1)
https://android.googleapis.com/gcm/send
Apple Push Notificaction (APN) (2)
Producción: gateway.push.apple.com, port 2195
Desarrollo (sandbox): gateway.sandbox.push.apple.com, port 2195
(1) Documentación oficial de google: http://developer.android.com/google/gcm/http.html
(2) Documentación oficial de apple:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/Re
moteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP400
08194-CH101-SW1
Introducción
Página9
Primera Instalación
Entregables
Kit de Instalación
Se hará entrega de un kit de instalación con los siguientes recursos:
war de mobile-services (backend)
war de viafirma platform (firma)
war de viafirma manager (gestión de firma)
Por otro lado, se entregarán los scripts SQL para la instalación, en limpio, de los
modelos de base de datos para Oracle y Postgre.
mobile-services (backend)
viafirma manager (gestión de firma)
Por último, en el kit de instalación se encontrarán otros recursos necesarios para la
instalación y que son referenciados en el proceso de instalación y/o configuración, como
drivers JDBC, ejemplos de configuración, performance de tomcat, etc.
Licencia
Junto a los entregables, se hará entrega de la licencia de uso.
Kit de Desarrollo
De forma adicional se podrá hacer entrega de recursos con utilidades para integradores,
como aplicaciones de ejemplo, snippets de código, o certicados digitales de prueba.
Instalación Base de Datos
A partir de los scripts SQL entregados, se deberán crear los modelos de datos para
mobile-services y para viafirma manager. Viafirma platform NO hace uso de base de
PrimeraInstalación
Página10
datos, por ello no se hace entrega de ningún script SQL asociado a platform.
Los datos de cada modelo de datos creado serán utilizados en la configuración de cada
sistema, según se describe en el capítulo de configuración para cada componente.
Despliegue
Esta documentación de instalación está referida a una instalación típica en un
contenedor Apache Tomcat, por lo que algunos detalles serán muy específicos de este
contenedor, no coincidiendo en otros contenederos soportados, como por ejemplo
Weblogic.
copiar los tres wars proporcionados en la ruta de despliege del tomcat:
<tomcat-home>/webapps/
arrancar servidor
<tomcat-home>/bin/catalina.shstart
Si los wars ya estaban pre-configurados, se podrá acceder al servicio para comprobar
su correcto arranque.
En caso de que los wars no estuvieran pre-configurados, se deberá consultar el capítulo
de configuración para la modificación de los respectivos ficheros de configuración. Tras
el cambio, el servidor deberá ser parado y arrancado nuevamente para que la nueva
configuración tenga efecto.
<tomcat-home>/bin/catalina.shstop
<tomcat-home>/bin/catalina.shstart
Tras el arranque, podremos consultar los frontales web para comprobar el servicio. Por
ejemplo:
http://192.168.10.20:8080/mobile-services
http://192.168.10.20:8080/viafirmaManager
PrimeraInstalación
Página11
http://192.168.10.20:8080/viafirma
nota: la IP 192.168.10.20 es un ejemplo que podría venir configurada en los ficheros de
configuración de ejemplo. Hay que sustituirla por la IP o nombre de dominio finalmente
utilizada en la instalación.
PrimeraInstalación
Página12
Actualización
La instalación de actualizaciones de viafirma documents, o alguno de sus componentes,
está descrita en el capítulo 7 "Procedimiento de Actualización". Consulta tu versión y
elije el procedimiento que corresponda.
Actualización
Página13
1.4 Configuración
Deberá consultarse con el responsable de la instalación en cada caso para confirmar la
configuración de todos los componentes.
En caso de que la instalación forme parte del servicio de soporte técnico contratado a
viafirma, los wars podrían entregarse pre-configurados, o parcialmente preconfigurados.
En caso de que la instalación no forme parte de una gestión de la configuración
contratada con viafirma, los wars entregados vendrán sin configuración personalizada,
por lo que hay que consultar las instrucciones de configuración descritas en este
capítulo.
Configuración de mobile services (backend)
Configuración de viafirma platform (firma)
Configuración de viafirma manager (gestión de firma)
Configuración
Página14
Configuración mobile services
NOTA: documentación optimizada para la v2.5.8. de mobile-services.
El backend de la solución cuenta con dos tipos de configuraciones:
configuración estática (previa al arranque)
configuración dinámica (tras el arranque, desde el panel de control)
Ambas deben llevarse a cabo, y se describen en los siguientes puntos.
Configuración estática
Como parte de la configuración "estática", tenemos:
Configuración del Contexto
El war entregado (mobile-services.war) espera un fichero de configuración mobileservices.xml, el cual se encontrará, tras el despliegue, en el directorio de configuración
del contenedor de aplicaciones.
Ej. para Apache Tomcat:
/<tomcat-home>/conf/Catalina/localhost/mobile-services.xml
En otros contenedores, como WebLogic, la configuración se realiza en un fichero de
propiedades (mobile-services.properties) en lugar del xml del contexto. En Apache
Tomcat también se puede optar por la configuración con fichero .properties. En este
caso, el fichero estaría ubicado en el siguiente path:
/<tomcat-home>/webapps/mobile-services/WEB-INF/classes/config.properties
En el siguiente link se encuentra un fichero de configuración de ejemplo:
config.properties
Configuraciónmobileservices
Página15
NOTA: en la configuración de ejemplo se definen varias propiedades que hacen
referencia a un path de filesystem. Dichos paths deben existir en el momento de la
instalación, y con los permisos de escritura adecuados. Consulta aquí los paths
necesarios para la configuración.
Configuración de la Caché (hazelcast)
De igual forma que para el contexto, el war entregado ya cuenta con una configuración
para hazelcast. En caso de necesitar modificar esta configuración, habrá que modificar
el fichero de configuración siguiente:
/<tomcat-home>/webapps/mobile-services/WEB-INF/classes/hazelcast.xml
En el siguiente link se encuentra un fichero de configuración de ejemplo:
hazelcast.xml
Configuración escritura de logs
El war entregado ya cuenta con una configuración básica para la escritura de logs del
backend. En caso de necesitar modificar esta configuración, habrá que modificar el
fichero de configuración siguiente:
/<tomcat-home>/webapps/mobile-services/WEB-INF/classes/logback.xml
En el siguiente link se encuentra un fichero de configuración de ejemplo:
logback.xml
Configuración Dinámica
A partir de aquí, el resto de parametrización del servicio se podrá hacer en caliente,
desde el Panel de Control del backend, tal y como se detalla en el capítulo 4 "Uso del
Backend > Panel de Control > Configuración del Sistema"
Configuraciónmobileservices
Página16
Configuración viafirma platform
NOTA: documentación optimizada para la v3.8.0 de viafirma platform.
Configuración del Contexto
El war entregado (viafirma.war) espera un fichero de configuración viafirma.xml, el cual
se encontrará, tras el despliegue, en el directorio de configuración del contenedor de
aplicaciones.
Ej. para Apache Tomcat:
/<tomcat-home>/conf/Catalina/localhost/viafirma.xml
En el siguiente link se encuentra un fichero de configuración de ejemplo:
viafirma.xml
En otros contenedores, como WebLogic, la configuración se realiza en un fichero de
propiedades (viafirmaConfig.properties) en lugar del xml del contexto. En Apache
Tomcat también se puede optar por la configuración con fichero .properties. En este
caso, el fichero estaría ubicado en el siguiente path:
/<tomcat-home>/webapps/viafirma/WEB-INF/classes/viafirmaConfig.properties
En el siguiente link se encuentra un fichero de configuración de ejemplo:
viafirmaConfig.properties
NOTA: en la configuración de ejemplo se definen varias propiedades que hacen
referencia a un path de filesystem. Dichos paths deben existir en el momento de la
instalación, y con los permisos de escritura adecuados. Consulta aquí los paths
necesarios para la configuración.
Configuraciónviafirmaplatform
Página17
Configuración de la Caché (ehcache)
De igual forma que para el contexto, el war entregado ya cuenta con una configuración
para ehcache. En caso de necesitar modificar esta configuración, habrá que modificar el
fichero de configuración siguiente:
/<tomcat-home>/webapps/viafirma/WEB-INF/classes/ehcache.xml
En el siguiente link se encuentra un fichero de configuración de ejemplo:
ehcache.xml
IMPORTANTE: esta configuración de ehcache debe hacerse de forma conjunta con la
configuración del ehcache de viafirma manager, o de lo contrario no podrían consumirse
mutuamente. En concreto, prestar especial atención a la configuración
multicastGroupAddress y un multicastGroupPort.
<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=automatic,multicastGroupAddress=230.0.0.1,multicastGroupPort=4446
propertySeparator=","/>
Path de Configuración Externa
De forma opcional, este fichero de configuración de echache podría estar ubicado en un
path externo al de despliegue.
Para que este fichero "externo" pueda ser localizado durante el arranque, será
necesario usar la variable VIAFIRMA_CONFIGURATION_PATH en la configuración del
contexto, e indicar el path donde se encontrará el fichero de configuración para
ehcache, por ejemplo:
/home/viafirma/platform_config/ehcache.xml
Configuración escritura de logs
Configuraciónviafirmaplatform
Página18
El war entregado ya cuenta con una configuración básica para la escritura de logs. En
caso de necesitar modificar esta configuración, habrá que modificar el fichero de
configuración siguiente:
/<tomcat-home>/webapps/viafirma/WEB-INF/classes/log4j.properties
En el siguiente link se encuentra un fichero de configuración de ejemplo:
log4j.properties
Configuraciónviafirmaplatform
Página19
Configuración de viafirma manager
NOTA: documentación optimizada para la v1.8.0 de viafirma manager.
Configuración del Contexto
El war entregado (viafirmaManager.war) espera un fichero de configuración
viafirmaManager.xml, el cual se encontrará, tras el despliegue, en el directorio de
configuración del contenedor de aplicaciones.
Ej. para Apache Tomcat:
/<tomcat-home>/conf/Catalina/localhost/viafirmaManager.xml
En el siguiente link se encuentra un fichero de configuración de ejemplo:
viafirmaManager.xml
En otros contenedores, como WebLogic, la configuración se realiza en un fichero de
propiedades (viafirmaConfig.properties) en lugar del xml del contexto. En Apache
Tomcat también se puede optar por la configuración con fichero .properties. En este
caso, el fichero estaría ubicado en el siguiente path:
/<tomcat-home>/webapps/viafirmaManager/WEB-INF/classes/viafirmaConfig.properties
En el siguiente link se encuentra un fichero de configuración de ejemplo:
viafirmaConfig.properties
NOTA: en la configuración de ejemplo se definen varias propiedades que hacen
referencia a un path de filesystem. Dichos paths deben existir en el momento de la
instalación, y con los permisos de escritura adecuados. Consulta aquí los paths
necesarios para la configuración.
Configuraciónviafirmamanager
Página20
Configuración de la Base de Datos
La configuración de la base de datos será Oracle o Postgre. Una vez elegido el tipo de
base de datos, hay que verificar que el persistence.xml se corresponda con la base de
datos elegida. Este fichero se encuentra en:
/<tomcat-home>/webapps/viafirmaManager/WEB-INF/classes/META-INF/persistence.xml
y habrá que revisar el DIALECTO seleccionado:
<!-<propertyname="hibernate.dialect"value="org.hibernate.dialect.PostgreSQLDialect"/>
-->
<propertyname="hibernate.dialect"value="org.hibernate.dialect.Oracle10gDialect"/>
Si se opta por el fichero de configuración .properties en lugar del contexto .xml, en éste
último sólo habrá que definir el pool de conexión a la base de datos. En el siguiente link
se encuentra un contexto de ejemplo donde sólo se define el pool de conexión a la base
de datos:
viafirmaManager_only_pool_JDBC.xml
Configuración de la Caché (ehcache)
De igual forma que para el contexto, el war entregado ya cuenta con una configuración
para ehcache. En caso de necesitar modificar esta configuración, habrá que modificar el
fichero de configuración siguiente:
/<tomcat-home>/webapps/viafirmaManager/WEB-INF/classes/ehcache.xml
En el siguiente link se encuentra un fichero de configuración de ejemplo:
ehcache.xml
IMPORTANTE: esta configuración de ehcache debe hacerse de forma conjunta con la
Configuraciónviafirmamanager
Página21
configuración del ehcache de viafirma manager, o de lo contrario no podrían consumirse
mutuamente. En concreto, prestar especial atención a la configuración
multicastGroupAddress y un multicastGroupPort.
<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=automatic,multicastGroupAddress=230.0.0.1,multicastGroupPort=4446
propertySeparator=","/>
Path de Configuración Externa
De forma opcional, este fichero de configuración de echache podría estar ubicado en un
path externo al de despliegue.
Para que este fichero "externo" pueda ser localizado durante el arranque, será
necesario usar la variable VIAFIRMA_CONFIGURATION_PATH en la configuración del
contexto, e indicar el path donde se encontrará el fichero de configuración para
ehcache, por ejemplo:
/home/viafirma/manager_config/ehcache.xml
Configuración escritura de logs
El war entregado ya cuenta con una configuración básica para la escritura de logs. En
caso de necesitar modificar esta configuración, habrá que modificar el fichero de
configuración siguiente:
/<tomcat-home>/webapps/viafirmaManager/WEB-INF/classes/log4j.properties
En el siguiente link se encuentra un fichero de configuración de ejemplo:
log4j.properties
Configuraciónviafirmamanager
Página22
Paths de FileSystem
La configuracion del backend puede variar de una instalación a otra, por lo que en esta
sección se dará una referencia de aquella configuración que requiere comprobación en
cada caso.
Configuración de Ejemplo
En los ficheros de configuración entregados se proponen algunas rutas para filesystem,
pero pueden ser variadas en cada instlación.
A continuación todos los paths referenciados en los ficheros de configuración
entregados:
Para mobile services (backend)
La configuración del backend hace referencia a los siguientes PATHS que deberían
existir en el servidor de aplicaciones donde se haya desplegado, o en una unidad NFS o
similar a la que se tenga acceso:
PERSISTENCE_STORAGE=/home/viafirma/config/mobile-services
AUDITORY_PATH=/home/viafirma/storage/auditory/auditory_mobile-services/
VIAFIRMA_CUSTODY_STORAGE=/home/viafirma/storage/custody
Para viafirma platform
La configuración de viafirma platform hace referencia a los siguientes PATHS que
deberían existir en el servidor de aplicaciones donde se haya desplegado, o en una
unidad NFS o similar a la que se tenga acceso:
PATH_CUSTODIA=/home/viafirma/storage/custody
KEYSTORE_PATH=/home/viafirma/config/platform/cacerts
AUDITORY_REGISTER_DIRECTORY_LOG=/home/viafirma/storage/auditory/auditory_platform/
PATH_GROOVY=/home/viafirma/config/platform/groovy
CONFIGURATION_PATH=/home/viafirma/config/platform
PathsdeFileSystem
Página23
Para viafirma manager
La configuración de viafirma manager hace referencia a los siguientes PATHS que
deberían existir en el servidor de aplicaciones donde se haya desplegado, o en una
unidad NFS o similar a la que se tenga acceso:
fileSystem.default.PATH_BASE=/home/viafirma/storage/manager
VIAFIRMA_LOG_DIRECTORIES=/home/viafirma/storage/auditory/auditory_platform/
CONFIGURATION_PATH=/home/viafirma/config/manager
PathsdeFileSystem
Página24
Uso del API REST
En este capítulo encontrarás las siguientes secciones. Toda la información contenida en
ellas está dirigida a perfiles integradores con solvencia en la integración de servicios
REST o aplicaciones Java.
2.1 Securización OAuth 1.0
2.2 Uso del cliente Postman
2.3 Uso del cliente Java
2.4 Uso del cliente Swagger
UsodelAPIREST
Página25
Acceso al API Rest con OAuth 1.0
Los servicios REST expuestos por viafirma documents están securizados con OAuth.
Para más información se puede consultar la Documentación oficial de OAuth 1.0.
Desde la administración de aplicaciones del backend, podremos configurar la seguridad
de acceso al API dos formas:
OAuth a nivel de aplicación
OAuth a nivel de usuario
OAuth 1.0 a nivel de aplicación
Solo es necesario conocer las credenciales de acceso de la aplicación y en las
peticiones solo se registra la información de la aplicación solicitante.
Se deben de informar los parámetros Consumer Key y Consumer Secret de OAuth,
que serán informados en el header de la petición, tal y como se describe a continuación:
OAuthrealm="http://dev.viafirma.com/mobile-services/api/v1/messages",
oauth_consumer_key="com.viafirma.mobile.services.crm",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1422479283",
oauth_nonce="kUBrJA",
oauth_version="1.0",
oauth_signature="zVPxPedplikqrNI0Tmq3GPzMzL0%3D"
En las siguientes capturas podemos ver un ejemplo de acceso al API Rest con el cliente
Postman:
SecurizaciónOAuth1.0
Página26
OAuth 1.0 a nivel de usuario
Sólo es necesario conocer las credenciales de acceso de la aplicación y los datos de
acceso de un usuario válido en el sistema, en las peticiones solo se registra la
información de la aplicación solicitante y del usuario solicitante.
Se deben informar los parámetros Consumer Key, Consumer Secret, Token y Token
Secret de OAuth.
Como resultado, en la cabecera de la petición http debemos informar el parámetro
Authorization en el Header de la petición:
OAuthrealm="http://dev.viafirma.com/mobile-services/api/v1/oauth/accessToken",
oauth_consumer_key="com.viafirma.mobile.services.demo",
oauth_token="48a0bad01f064a69a19d310c5d71c3b6",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1423584275",
oauth_nonce="dN876B",
oauth_version="1.0",
oauth_signature="8pI9Lg7qVuYO0IoEpCV%2BmX5qqJM%3D"
En las siguientes capturas podemos ver un ejemplo de acceso al API REST con el
cliente Postman:
SecurizaciónOAuth1.0
Página27
En primer lugar necesitamos pedir un token de acceso haciendo uso de las credenciales
de acceso a nuestra aplicación:
Tras obtener y aceptar el token, copletamos la petición con los datos del usuario:
SecurizaciónOAuth1.0
Página28
Tras esto, podremos usar el token durante un periodo de tiempo predefinido en el
backend, por ejemplo, 30 min. Transcurrido este tiempo, el token caducará y tendremos
que solicitar uno nuevo.
SecurizaciónOAuth1.0
Página29
Ejemplo de token caducado
SecurizaciónOAuth1.0
Página30
Uso del cliente Postman
Ejemplos de Uso
Recuperar un mensajes procesado
GETahttp://dev.viafirma.com/mobile-services/api/v1/documents/DRAFTED/1422479367884R127/1422479
Construye PDF a partir de datos de mensaje
En la pestaña de OAuth de postman tenemos que indicar los valores correctos en los
campos 'Consumer Key' y 'Consumer Secret' tal cual podemos ver en la siguiente
captura
Realizar una petición:
POSThttp://dev.viafirma.com/mobile-services/api/v1/messages
UsodelclientePostman
Página31
Enviando el siguiente json IMPORTANTE el código del workflow tiene que ser EX005
{
"version":"00001",
"workflow":{
"code":"EX005",
"history":[]
},
"notification":{
"text":"Generarpdf",
"detail":"Ejemploquesologeneraunpdfyejecutaelcallbacksegúnlotengaconfigurado"
},
"document":{
"templateCode":"022_example",
"templateType":"docx",
"items":[{
"key":"KEY_01",
"type":"text",
"label":"KEY_01",
"required":true,
"disabled":false
},{
"key":"KEY_02",
"type":"text",
"label":"KEY_02",
"required":false,
"disabled":false
},{
"key":"KEY_03",
"type":"text",
"label":"KEY_03",
"required":false,
"disabled":false
},{
"key":"KEY_04",
"type":"text",
"label":"KEY_04",
"required":false,
UsodelclientePostman
Página32
"disabled":false
}]
}
}
UsodelclientePostman
Página33
Mobile Services SDK Java
Cliente Java para Mobile Services - Viafirma
Histórico de cambios y versiones
Integración en proyecto maven
Es necesario añadir el siguiente repositorio
<repository>
<id>viavansi-repo</id>
<name>ViavansiMavenRepository</name>
<url>http://repositorio.viavansi.com/repo</url>
</repository>
Añadir la siguiente dependencia
<dependency>
<groupId>com.viafirma</groupId>
<artifactId>ms-sdk-java</artifactId>
<version>2.X.X</version>
</dependency>
Ejemplo de uso:
Recuperar información de un mensaje conocido el código
Ejemplo de Autenticación OAuth a nivel de usuario
V1Apiapi=newV1Api();
//URLdeaccesoalAPIREST
api.setBasePath(urlApi);
//OAuthconsumerkey
api.setConsumerKey(consumerKey);
//OAuthconsumersecret
UsodelclienteJava
Página34
api.setConsumerSecret(consumerSecret);
//Solicitarunnuevotoken
Tokentoken=V1oauthApi.getInstance().requestToken();
api.setToken(token.getOauth_token());
api.setTokenSecret(token.getOauth_token_secret());
//Aceptareltokenrecibido
token=V1oauthApi.getInstance().accessToken(userCode,userPass,"client_auth");
api.setToken(token.getOauth_token());
api.setTokenSecret(token.getOauth_token_secret());
//Ejemplodecomorecuperarunmessageconocidosucódigo
Messagemessage=V1messagesApi.getInstance().getMessageByCode("1400834631788R255");
Ejemplo de envio de mensaje para solo generar
documentos pdf
Ejemplo de autenticación OAuth a nivel de aplicación
V1Apiapi=newV1Api();
//URLdeaccesoalAPIREST
api.setBasePath(urlApi);
//OAuthconsumerkey
api.setConsumerKey(consumerKey);
//OAuthconsumersecret
api.setConsumerSecret(consumerSecret);
//Createmessage
Messagemessage=newMessage();
//Createworkflow
Workflowworkflow=newWorkflow();
workflow.setCode("EX005");
message.setWorkflow(workflow);
//Createnotificationinfo
Notificationnotification=newNotification();
notification.setText("NotificationDemo");
notification.setDetail("Generateaexampledocumentfromtemplate");
message.setNotification(notification);
//Createatemplatedocument
Documentdocument=newDocument();
document.setTemplateCode("022_example");
document.setTemplateType("docx");
UsodelclienteJava
Página35
//Adddatototemplate
List<Item>items=newArrayList<Item>();
Itemitem=newItem();
item.setKey("KEY_01");
item.setLabel("Testkey1");
item.setValue(UUID.randomUUID().toString());
items.add(item);
item=newItem();
item.setKey("KEY_02");
item.setLabel("Testkey2");
item.setValue(UUID.randomUUID().toString());
items.add(item);
item=newItem();
item.setKey("KEY_03");
item.setLabel("Testkey3");
item.setValue(UUID.randomUUID().toString());
items.add(item);
item=newItem();
item.setKey("KEY_04");
item.setLabel("Testkey4");
item.setValue(UUID.randomUUID().toString());
items.add(item);
document.setItems(items);
message.setDocument(document);
//Sendmessage
StringmessageCode=V1messagesApi.getInstance().sendMessage(message);
UsodelclienteJava
Página36
Uso del cliente Swagger
El backend incluye Swagger, una herramienta para el apoyo a la integración de los
servicios REST expuestos por el sistema.
Accediendo a esta sección se podrán revisar y consumir todos los servicios, pues éstos
están securizados con unas credenciales habilitadas para Swagger.
Resulta muy útil para validaciones puntuales del servicio, o conocer la definición exacta
de las entidades del sistema.
UsodelclienteSwagger
Página37
UsodelclienteSwagger
Página38
Uso de políticas de firma y evidencias
Toda la información contenida en ellas está dirigida a perfiles técnicos y con solvencia
en la integración de aplicaciones JEE.
En este capítulo encontrarás las siguientes secciones:
3.1 Introducción
3.2 Firma Digitalizada
3.3 Evidencias Electrónicas
3.4 Políticas de Firma
Usodepolíticasdefirmayevidencias
Página39
Introducción
Estructura de los documentos firmados
Firma del documento PDF
El PDF será firmado electrónicamente, con un certificado digital, y dependiendo de la
política de firma indicada en el JSON se realizará en un formato de firma que incluya un
sello de tiempo (hora oficial).
Dependiendo de las evidencias capturadas durante el proceso de firma, el PDF
mostrará tantas anotaciones como evidencias se hayan capturado, referenciando en
cada caso al XML asociado, el cual estará disponible como anexo al propio PDF, por
tanto, podremos encontrarnos con PDFs que tengan más de un XML asociado.
Introducción
Página40
Además, al PDF se le insertará como anexo el XML que se describe en el siguiente
punto.
Firma de los XML adjuntos al PDF
El XML contendrá datos relativos a la operación de firma digitalizada o cualquier
evidencia capturada durante el proceso. Parte de la información recogida en este XML
irá en claro y otra parte irá cifrada. Esta última se cifrará en función de la política de
cifrado indicada en el JSON.
Además, el XML estará firmado electrónicamente, con un certificado digital, y
dependiendo de la política de firma indicada en el JSON se realizará en un formato de
firma que incluya un sello de tiempo (hora oficial). Entre los datos que se recogen en el
XML también encontraremos datos asociados de forma biunívoca al PDF que el usuario
firmó.
Introducción
Página41
Introducción
Página42
Firma digitalizada
Parámetros de configuración
Ayuda contextual
Para incluir un texto de ayuda en el lienzo de firma que se muestra en el dispositivo
móvil, usaremos el parámetro digitalizedSignHelpText.
{
"key":"digitalizedSignHelpText",
"value":"Firmadeejemplo"
}
Posición de la firma digitalizada
En la política podemos determinar si la firma capturada se puede insertar libremente en
el documento, haciendo doble tap sobre el documento, o bien insertarla en una posición
conocida. Para ello, se usarán los siguientes parámetros:
signPositionEnable: lo usaremos para permitir la posición manual de la firma. Los
valores permitidos son true y false. En caso de indicar false en el parámetro
signPositionEnable, necesitamos los siguientes parámetros:
{
"key":"signPositionEnable",
"value":"false"
}
digitalizedSignRectangle: lo usaremos para definir dónde insertar la firma, en el
formato: Y, X, width, height
{
"key":"digitalizedSignRectangle",
"value":"{\"y\":\"240\",\"x\":\"270\",\"width\":\"160\",\"height\":\"65\"}"
}
Firmadigitalizada
Página43
page: para indicar el número de la página donde se insertará la firma. Para insertarlo en
la última se indica -1.
{
"key":"page",
"value":"1"
}
Tipos de cifrado
Usaremos el parámetro op para indicar qué tipo de operación de cifrado se va a realizar.
Los valores permitidos son dos:
pen = el cifrado se realiza en servidor
biometric = el cifrado se realiza en el propio dispositivo móvil
{
"key":"op",
"value":"pen"
}
Clave pública de un certificado informado
Usaremos la siguiente combinación:
op = pen
biometricAlias y biometricPass existe están informados:
Como resultado tendremos un XML cifrado en servidor con la clave pública del
certificado indicado, el cual previamente fue instalado en el servidor.
Ejemplo:
{
"key":"op",
"value":"pen"
},
{
Firmadigitalizada
Página44
"key":"biometricAlias",
"value":"viafirmadocuments"
},
{
"key":"biometricPass",
"value":"12345"
},
{
"key":"DIGITALIZED_SIGNATURE_FORMAT",
"value":"XADES_EPES_ENVELOPED"
}
En el ejemplo anterior además hemos informado el parámetro
DIGITALIZED_SIGNATURE_FORMAT para que el XML también sea firmado con el
certificado informado, y que también debió ser instalado en el servidor previamente.
Clave pública informada en el propio JSON
Usaremos la siguiente combinación:
op = biometric
biometricCryptoPEM
nota: si nos informan una clave pública en el JSON, usaremos preferentemente el tipo
de operación cifrado en local (dispositivo móvil).
Como resultado tendremos un XML cifrado en el dispositivo móvil, con la clave pública
informada en el parámetro biometricCryptoPEM.
Ejemplo:
{
"key":"op",
"value":"biometric"
},
{
"key":"biometricCryptoPEM",
"value":"MIIFbDCCBFSgAwIBAgIIGtUapa"
},
{
"key":"biometricAlias",
"value":"viafirmadocuments"
},
{
"key":"biometricPass",
"value":"12345"
},
Firmadigitalizada
Página45
{
"key":"DIGITALIZED_SIGNATURE_FORMAT",
"value":"XADES_EPES_ENVELOPED"
}
En el ejemplo anterior además hemos informado los parámetros biometricAlias,
biometricPass y DIGITALIZED_SIGNATURE_FORMAT para que el XML también sea
firmado con el certificado informado, y que también debió ser instalado en el servidor
previamente.
Firmadigitalizada
Página46
Evidencias Electrónicas
Configuración de evidencias
Además de la firma digitalizada, el proceso permite capturar otras evidencias
electrónicas, y además en un orden determinado.
En este capítulo vamos a explicar una política de evidencias basadas en la captura de
huellas dactilares (fingerprint) y en la captura de imágenes desde la cámara del
dispositivo móvil.
Es importante aclarar que el tratamiento de una firma digitalizada (haciendo uso por
ejemplo de stylus bluetooth), NO se incluye dentro de la política de evidencias,
quedando éstas reservadas únicamente para las capturas de fotos y huellas.
Política con Evidencias
Se permiten una o varias evidencias por cada política, es decir, una política de
configuración podrá llevar asociada un array de eviencias, y cada evidencia tendrá su
propia configuración.
Es importante destacar, que al igual que se hace con la firma digitalizada, las evidencias
pueden llevar asociada una política de firma para que los datos queden cifrados y/o
firmados electrónicamente (con certificado digital).
Ejemplo de política con 2 evidencias:
{
"policies":[
{
"evidences":[
{
"evidences_1_config"
},
{
"signature_evidence_1_policy"
}
]
},
EvidenciasElectrónicas
Página47
{
"evidences":[
{
"evidences_2_config"
},
{
"signature_evidence_2_policy"
}
]
}
]
}
Evidencia del tipo Imagen
Usaremos el parámetro type para indicar el tipo de evidencia imagen.
"type":"ANNOTATION"
Los parámetros que podemos usar en esta evidencia para su configuración son los
siguientes:
{
"type":"ANNOTATION",
"helpText":"Fotodelcliente",
"typeFormatSign":"XADES_EPES_ENVELOPED",
"certificateAlias":"viafirmadocuments",
"certificatePassword":"12345",
"positions":
[
{
"page":1,
"rectangle":
{
"width":100,
"height":145,
"x":417,
"y":330
}
}
]
}
Key Descripción
EvidenciasElectrónicas
Página48
type Tipo de evidencia, y debemos indicar “FINGER_PRINT”
helpText Ayuda contextual que aparecerá en modo “alert” en la pantalla del
dispositivo móvil antes de iniciar la captura.
typeFormatSign Formato en el que se firmará el XML que contendrá la evidencia
capturada. Los valores posibles se describen en el capítulo “Firma del XML”.
certificateAlias Alias del certificado que se usará para la firma; este certificado
debe estar instalado previamente en servidor y asociado a las credenciales
gestionadas por viafirma manager.
certificatePassword Password del certificado que se usará para la firma; este
certificado debe estar instalado previamente en servidor y asociado a las
credenciales gestionadas por viafirma manager.
positions Array de posiciones, pudiendo indicar una o varias posiciones en la que
deseamos representar la imagen capturada. Para cada posición, indicaremos el
número de la página, la posción dentro de la página y el tamaño.
positions: page Número de la página en la que se va a insertar la imagen
capturada.
positions: rectangle Usaremos las coordenadas X,Y para determinar el vértice
superior izquierdo del rectángulo imaginario para representar la imagen, e
indicaremos ancho (width) y alto (height) del mismo.
Evidencia del tipo huella (fingerprint)
Usaremos el parámetro type para indicar el tipo de evidencia huella, y el parámetro
deviceType para indicar el vendor del dispositivo que vamos a utilizar para la captura. Al
indicar un vendor relacionado con la captura de huellas, el dispositivo móvil cederá el
control al accesorio para inciar la captura.
"type":"FINGER_PRINT",
"deviceType":"vendorID"
Por ejemplo, para conectar con un lector de huella de Tactivo, Precise Biometric,
usaremos el siguiente identificador: "deviceType": "iFMID"
Los parámetros que podemos usar en esta evidencia para su configuración son los
siguientes:
{
"type":"FINGER_PRINT",
EvidenciasElectrónicas
Página49
"helpText":"Huelladelcliente",
"deviceType":"iFMID",
"typeFormatSign":"XADES_EPES_ENVELOPED",
"certificateAlias":"viafirmadocuments",
"certificatePassword":"12345",
"metadataCipherPublicKey":"MIIFbDCCBFSgAwIBAgIIGtUapa...",
"positions":
[
{
"page":1,
"rectangle":
{
"width":100,
"height":145,
"x":417,
"y":330
}
}
]
}
`
Key Descripción
type Tipo de evidencia, y debemos indicar “FINGER_PRINT”
helpText Ayuda contextual que aparecerá en modo “alert” en la pantalla del
dispositivo móvil antes de iniciar la captura.
deviceType ID del vendor que usaremos para la captura. Por ejemplo, para
Tactivo, usaremos “iFMID”
typeFormatSign Formato en el que se firmará el XML que contendrá la evidencia
capturada. Los valores posibles se describen en el capítulo “Firma del XML”.
certificateAlias Alias del certificado que se usará para la firma; este certificado
debe estar instalado previamente en servidor y asociado a las credenciales
gestionadas por viafirma manager.
certificatePassword Password del certificado que se usará para la firma; este
certificado debe estar instalado previamente en servidor y asociado a las
credenciales gestionadas por viafirma manager.
metadataCipherPublicKey clave pública con la que será cifrado el contenido del
atributo metadata de la evidencia utilizando un cifrado RSA/None/NoPadding en
UTF-8 al cual se le aplicará un base64.
positions Array de posiciones, pudiendo indicar una o varias posiciones en la que
deseamos representar la huella capturada. Para cada posición, indicaremos el
número de la página, la posción dentro de la página y el tamaño.
positions: page Número de la página en la que se va a insertar la representación
de la huella capturada.
EvidenciasElectrónicas
Página50
positions: rectangle Usaremos las coordenadas X,Y para determinar el vértice
superior izquierdo del rectángulo imaginario para representar la huella, e
indicaremos ancho (width) y alto (height) del mismo.
EvidenciasElectrónicas
Página51
Políticas de Firma
Configuración de la firma del PDF
La key DIGITALIZED_SIGN_PDF_SIGNATURE_FORMAT nos indicará el formato de
firma a utilizar, por ejemplo:
{
"key":"DIGITALIZED_SIGN_PDF_SIGNATURE_FORMAT",
"value":"PDF_PKCS7_T"
}
Formatos permitidos para la firma del PDF
PADES_BASIC (no incluye de tiempo)
PADES_BES (sello de tiempo opcional)
PADES_EPES (necesita sello de tiempo)
PDF_PKCS7 (NO incluye sello de tiempo)
PDF_PKCS7_T (necesita sello de tiempo)
nota: para incorporar un sello de tiempo es necesario tener configurada una TSA, bien
en viafirma platform o bien en las credenciales utilizadas en viafirma manager.
Certificado para la firma del PDF
El certificado que se usará para la firma del PDF se define en las keys alias y pass:
{
"key":"alias",
"value":"viafirmadocuments"
},
{
"key":"pass",
"value":"12345"
}
Este par de keys son obligatorias y su uso está ligado a la key
PolíticasdeFirma
Página52
DIGITALIZED_SIGN_PDF_SIGNATURE_FORMAT.
Configuración de firma del XML
La key DIGITALIZED_SIGNATURE_FORMAT nos indicará el formato de firma del XML
que se incluye dentro del PDF y que contiene los datos biométricos y otras evidencias
capturadas durante el proceso de firma, por ejemplo:
{
"key":"DIGITALIZED_SIGNATURE_FORMAT",
"value":"XADES_EPES_ENVELOPED"
}
Formatos permitidos para la firma del XML
XADES_EPES_ENVELOPED (sello de tiempo opcional)
XADES_T_ENVELOPED (necesita sello de tiempo)
XADES_XL_ENVELOPED (necesita sello de tiempo)
XADES_A_ENVELOPED (necesita sello de tiempo)
XMLDSIG (NO incluye sello de tiempo)
XMLSIG_ENVELOPING (NO incluye sello de tiempo)
nota: para incorporar un sello de tiempo es necesario tener configurada una TSA, bien
en viafirma platform o bien en las credenciales utilizadas en viafirma manager.
Certificado para la firma del XML
El certificado que se usará para la firma del XML se define en las keys biometricAlias y
biometricPass:
{
"key":"biometricAlias",
"value":"viafirmadocuments"
},
{
"key":"biometricPass",
"value":"12345"
}
PolíticasdeFirma
Página53
Este par de claves son obligatorias y su uso está ligado a la key
DIGITALIZED_SIGNATURE_FORMAT.
PolíticasdeFirma
Página54
Uso del backend
Las opciones descritas en cada una de las secciones estarán accesible a aquellos roles
autorizados, por lo que si el propósito es el de obtener toda la información posible sobre
el uso del backend, se recomienda acceder con perfil súper admin.
Las secciones se han dividido de la siguiente forma:
Panel de Control
Administración
Actividad
Desarrollo
Usodelbackend
Página55
Panel de Control
El panel de control ofrece las siguientes opciones:
Auditoría de mensajes
Configuración del sistema
Gestión de usuarios
Información del sistema
Informe de uso
Sistema de transferencias
PaneldeControl
Página56
Auditoría de Mensajes
La auditoría de mensajes ofrece una vista histórica de todas las operaciones realizadas,
y cuenta con las siguientes características.
Histórico permanente
A diferencia de la gestión de mensajes, la información auditada no es borrada por el
backend, como sí lo hace con los mensajes. Este borrado se configura en el ciclo de
vida de los mensajes, ver capítulo Administración > Aplicaciones.
Respaldo en disco
Las referencias auditadas quedan respaldadas opcionalmente por ficheros XMLs,
persistidos éstos en un sistema de ficheros.
El path de persistencia del XML es definido en la configuración del sistema, en la
variable AUDITORY_PATH. Si este fichero XML fuese borrado del filesystem, la
inforación seguiría estando disponible en esta vista de auditoría. Lo único que no estaría
disponible sería el fichero XML que reúne toda el detalle de la operación.
El path de persistencia del XML se definirá de la siguiente forma:
AUDITORY_PATH+YYYMMDD+CODMESSAGE+.xml
Por ejemplo:
home/cluster/custodia/auditory/20150810/1439216343810R278.xml
AuditoríadeMensajes
Página57
Configuración del Sistema
A partir de la versión 2.4 del backend se incluye un panel de control que permite
introducir cambios de configuración en caliente, sustituyendo para ello variables de
contexto con parámetros peristidos en la tabla de configuración en base de datos.
Para acceder a esta configuración es necesario rol "súper-admin": Panel de Control >
Configuración de Sistema
Configuración call-back
A partir de la versión 2.4, las respuestas dadas desde el backend hacia las aplicaciones
de terceros que invocan los servicios de viafirma documents permite además enviar un
correo electrónico para cada respuesta.
Para ello, en el objeto MESSAGE debemos incluir la propiedad callbackMails.
Message{
code(string,optional),
userCode(string,optional),
groupCode(string,optional),
appCode(string,optional),
version(string),
workflow(Workflow,optional),
notification(Notification,optional),
document(Document,optional),
metadataList(array[Param],optional),
policies(array[Policy],optional),
callbackURL(string,optional),
callbackMails(string,optional),
callbackMailsFormKeys(array[string],optional),
error(ErrorResponse,optional),
commentReject(string,optional)
}
Una vez configurada la callback vía correo electrónico, desde el backend se podrá
configurar el comportamiento de ese envío de correo, tal y como se describe a
continuación:
ConfiguracióndelSistema
Página58
Adjuntar PDF/XML en el correo: activando estas opciones, el correo remitido al
integrador adjuntará el PDF firmado y el XML del message procesado.
Disclaimer del correo: permitirá personalizar el pie del correo remitido al integrador
tras cada callback.
Valores del formulario en el correo: incluirá en el correo remitido al integrador los
valores informados en el formulario que dio origen al PDF firmado. Esta opción es útil
para revisar en un simple vistazo el contenido de documentos tipo encuestas de
satisfacción o similares, cuyo contenido no es muy extenso y ofrece información sin
necesidad de procesar.
Se permite además incluir más de un destinatario de correo, separados por coma (,).
Además, en el caso de que existan valores sensibles en el formularios, éstos podrán ser
omitidos en el correo electrónico. Para ello, informaremos debidamente en el JSON del
MSESSAGE la lista de "KEYS" que se van a mandar. El resto, no se mandarían.
Para este filtrado de datos usaremos la propiedad callbackMailsFormKeys disponible en
el objeto MESSAGE.
Message{
callbackMailsFormKeys(array[string],optional),
}
Asunto del correo: asunto con el que se remitirá el correo al integrador en cada
callback.
ConfiguracióndelSistema
Página59
Auto-check del sistema
El sistema de monitorización de servicios notificará vía correo electrónico aquellas
indidencias detectadas en alguno de los servicios y comprobaciones que se realizan.
Podremos indicar el destinatario y asunto del correo que se remite.
Además, para prevenir la notificación reiterativa de un servicio que no está disponible de
forma controlada, podremos indicar un número máximo de notificaciones para un mismo
error.
Período de inactividad de cuentas
Se podrá definir un número máximo de días en el que un usuario pueda estar sin
acceder a los servicios.
Es decir, si pasados ese límite el usuario intentara hacer login, se le mostraría un
mensaje indicándole que su cuenta ha sido desactivada.
Reactivación de cuentas
Cuando una cuenta de usuario caduca o ha sido deshabilitada por inactividad, el
usuario podrá solicitar su reactivación.
Esta solicitud enviará un correo electrónico a un responsabl, el cual puede ser indicado
en esta configuración.
ConfiguracióndelSistema
Página60
De igual forma se podrán configurar los contenidos y asuntos de los correos remitidos
para cada uno de los casos previstos: reactivación, rechazo, etc.
Transferencias de documentos firmados
En caso de tener activada la transferencia automática de documentos firmados a un
backend externo, el sistema envía automáticamente un informe con los documentos
transferidos, y lo hace vía correo electrónico.
Con esta configuración podremos definir el destinatario y el contenido de dichos
correos.
ConfiguracióndelSistema
Página61
ConfiguracióndelSistema
Página62
Gestión de Usuarios
El backend distinguirá entre dos tipos de usuarios: súper administrador y usuario.
Un súper administrador tendrá todos los permisos disponibles para configurar y operar
desde el backend.
Un usuario se limitará a las acciones autorizadas al rol al que pertenezca, teniendo en
cuenta que un usuario podrá tener uno o varios roles al mismo tiempo.
Sólo un súper administrador tendrá permisos para la asignación de roles, los cuales
están predefinidos en cinco grupos:
Administrador (ADMIN)
Coordinador (MANAGER)
Asesor (DISPATCHER)
Usuario (USER)
Desarrollador (DEVELOPER)
Permisos de edición
Cualquier usuario podrá editar sus datos personales y su contraseña. El resto de datos
de configuración y operación sólo podrán ser editados por un súper administrador.
GestióndeUsuarios
Página63
Caducidad de Cuentas
La cuenta de usuario podrá ser ilimitada (no caduca) o podrá tener una fecha de
caducidad.
La fecha de caducidad se gestiona de dos formas distintas:
Caducidad asociada a una fecha conocida
Una cuenta de usuario podrá tener una fecha de caducidad, la cual puede ser elegida
desde un calendario, o bien, indicar un número de días de validez. Por ejemplo, 60 días
de validez, tomándose en cuenta la fecha actual como el primer día de validez.
Caducidad asociada a una inactividad del usuario
Si el usuario supera un número de días sin usar su cuenta, el sistema la caducará
automáticamente.
Este número de días es definido en la configuración del sistema, en Panel de Control,
sólo administrable por un súper administrador.
GestióndeUsuarios
Página64
Ciclo de vida de las cuentas de usuario
Desde el backend se podrán podrán gestionar las cuentas activas, inactivas y aquellas
cuentas que están en proceso de reactivación.
Cuenta bloqueada
¿Cuándo se bloquea una cuenta?
Como ya se ha explicado anteriormente, una cuenta puede tener asociada una
caducidad, determinada en base a una fecha conocida o por un período de inactividad.
Y como tercer motivo, una cuenta podría ser bloqueada por un súper administrador, a
través de la opción disponible en el listado de cuentas activas.
Reactivación de Cuentas
¿Cómo se vuelve a habilitar una cuenta bloqueada?
Aquel usuario que intente acceder con su cuenta bloqueada o caducada, verá un
mensaje en la pantalla del login indicándole el estado de su cuenta. Al mismo tiempo, se
le ofrecerá la posibilidad de solicitar la reactivación de su cuenta.
GestióndeUsuarios
Página65
Para ello, el sistema seguirá los siguientes pasos:
solicitará user y password
si las credenciales introducidas son correctas, comprobará si el usuario tiene
informado una cuenta de correo:
si no la tuviera, se le solicita que informe una cuenta
el sistema envía una notificación al responsable del backend encargado de la
reactivación de cuentas.
La cuenta de correo a la que se informa de una nueva solicitud se define en la
configuración del sistema, ver capítulo del Panel de Control > Configuración del
Sistema.
Del mismo modo, en la gestión de usuarios se podrá acceder a la pestaña "Cuentas
Pendientes", en las que un súper administrador podrá autorizar o denegar la
reactivación.
Cualquiera de las acciones realizadas generará una notificación vía email al usuario
afectado.
En caso de que la reactivación haya sido autorizada, dicho correo electrónico incluirá la
nueva contraseña autogenerada por el backend, contraseña que podrá ser cambiada
por el usuario accediendo a los datos de su cuenta.
Importación de Usuarios
Se podrán importar usuarios en bloque a partir de la carga de una plantilla excel (.xlsx)
que se puede descargar desde la propia pantalla de importación de usuarios.
El proceso de importación mostrará el resumen de la operación, indicando el número de
usuarios importados correctamentes y, en su caso, indicando el error y motivo de
aquellos usuarios que no pudieron ser importados.
GestióndeUsuarios
Página66
GestióndeUsuarios
Página67
Roles
Las acciones permitidas para cada role son las siguientes:
Las acciones permitidas para cada rol son las enumeradas a continuación:
Administrador (ADMIN)
Aplicaciones
Editar
Acceso al listado
Eliminar
Dispositivos
Acceso al listado
Crear
Eliminar
Acceder al detalle
Grupos
Editar
Acceso al listado
Eliminar
Auditoría de mensajes
Acceso al listado
Mensajes
Acceso al listado de mis mensajes
Notificaciones
Acceso al listado de mis notificaciones
Plantillas
Asignar
Editar
Acceso al listado
Eliminar
Generar documentos
Edición Básica
Usuarios
Edición Básica
Acceso al listado
GestióndeUsuarios
Página68
Coordinador (MANAGER)
Grupos
Editar
Acceso al listado
Eliminar
Plantillas
Acceso al listado
Asesor (DISPATCHER)
Mensajes
Acceso al listado de mis mensajes
Plantillas
Acceso al listado
Generar documentos
Usuario (USER)
Mensajes
Acceso al listado de mis mensajes
Plantillas
Acceso al listado
Generar documentos
Desarrollador (DEVELOPER)
Servicios Rest
Acceder (UI swagger, con el detalle de todos las entidades expuestas por
servicios rest)
Códigos de Errores
Acceso al listado (listado a la codificación de errores)
GestióndeUsuarios
Página69
GestióndeUsuarios
Página70
Información del Sistema
Esta sección del panel de control analiza el estado del sistema en dos líneas: por un
lado el estado de los componentes críticos de integración y servicio, y por otro lado,
muestra una "foto actual" del uso del sistema.
Check de Componentes
Uso en Tiempo Real
InformacióndelSistema
Página71
Check de componentes
En este panel se mostrará el estado de seis componentes necesarios para un correcto
funcionamiento.
La comprobación se realizada cada cinco minutos, y si se desea conocer el estado
actual, se debe hacer click en el botón "Actualizar ahora".
Reporte automático de fallos
Si uno de estos componentes monitorizados falla, el sistema envía un correo electrónico
informando del problema.
El correo se repetirá hasta que el problema pesista, o tantas veces como se haya
definido en las opciones de configuración, ver parámetro "Número máximo de
notificaciones en caso de error de un sistema externo" (ver capítulo "Configuración del
Sistema").
InformacióndelSistema
Página72
Configuración necesaria
Para permitir este reporte automático, se definen las siguientes variables de
configuración:
variable
descripción
MAIL_HOST_NAME
smtp server, por ej. 10.40.23.1
MAIL_SMTP_USER
user smtp, por ej. "[email protected]"
MAIL_SMTP_PASS
password smtp, opcional.
MAIL_FROM
nombre remitente, por ej. "Viafirma documents"
variable
descripción
SYSTEM_STATUS_ERROR_THREAD_TIMER_DELAY
Delay general para
el inicio de los hilos
para el auto-check
del sistema
expresado en
milisegundos
SYSTEM_STATUS_ERROR_THREAD_TIMER_PERIOD
Temporizador
general para el
inicio de los hilos
para el auto-check
del sistema
expresado en
milisegundos
SYSTEM_STATUS_ERROR_SUBJECT
Asunto para el
correo de envio de
error
SYSTEM_STATUS_ERROR_THREAD_TIMER_PERIOD
Destinatarios para el
correo de envio de
error, separados por
coma
InformacióndelSistema
Página73
Uso en tiempo real
Esta vista ofrecerá el número de documentos procesados en el día en curso, y lo
presentará en una gráfica comparativa con los últimos siete días.
Para conocer el número de documentos procesados de un día en concreto, se debe
consultar en la opción Panel de Control > Informe de Uso.
InformacióndelSistema
Página74
Informe de Uso
Esta sección generará gráficas de uso del día seleccionado. La información ofrecida
distingue operaciones por su estado y por el origen de la petición.
Si además se tuviera activado un repositorio externo para la persistencia de
documentos, se mostrará una gráfica con el resumen de las transferencias realizadas,
agrupadas por estado.
Esta última gráfica, la de transferencias, se corresponde a un informe diario de
transferencias, y que se remite de forma automática a los responsables autorizados.
Para más información consultar la sección Panel de Control > Configuración del
Sistema.
InformedeUso
Página75
Sistema de Transferencias
En caso de haber configurado un sistema externo para la persistencia de documentos,
esta vista mostrará el detalle de las transferencias realizadas.
Para cada caso, se indicará:
fecha y hora de la transferencia
mensaje asociado a la transferencia
sistema externo configurado (ej. computec, ftp, etc.)
estado de la transferencia (pendiente, asignada, finalizada o error)
número de intentos en caso de fallo en la primera transferencia
la respuesta del sistema externo tras la transferencia, por ej. 200 (si es un servicio
REST), y el número asignado por el sistema externo en la petición.
El número de intentos de los documentos a transferir se define en las propiedad del
sistema external_signed.MAX_RETRY_COUNT. Para más info consulta la
Configuración del Sistema.
En caso de error, en esta vista se podrá acceder al detalle del error para que pueda ser
analizado y escalado según proceda.
SistemadeTransferencias
Página76
Administración
Desde esta sección se podrán administrar las siguientes entidades del sistema:
Aplicaciones
Dispositivos
Grupos
Plantillas
Administración
Página77
Aplicaciones
Esta administración de aplicaciones permitirá definir las reglas de comunicación entre el
backend y los usuarios que hagan uso, bien de aplicaciones móviles, o bien de
aplicaciones servidor que estén integradas con viafirma documents.
Nos permitirá autorizar el uso a estas aplicaciones, y nos permitirá identificar el origen y
destino de los documentos procesados.
Tipo de Aplicaciones
Se tendrán en cuenta tres tipos de aplicaciones:
iOS
Android
API
Las aplicaciones iOS y Android se refieren a las apps oficiales de viafirma documents.
Cada una cuenta con su propia configuración, nombre, y securización.
Aplicaciones
Página78
El tercer tipo de apliaciones, API, se refiere a aquellas aplicaciones que integren con los
servicios de viafirma documents, por ejemplo, un CRM, que al igual que para el caso de
iOS y Android, podrá tener su propia configuración y securización.
A continuación se describe cómo gestionar las aplicaciones en el backend.
Datos Generales
Entre los datos generales a la hora configurar una aplicación, empezaremos a describir
los datos bloqueantes y funcionales:
Tipo de aplicación (plataforma)
Tipo de autenticación
Como ya se ha explicado, nuestra aplicación deberá crearse como una de las tres
opciones permitidas: iOS, Android y API.
El tipo de autenticación se explica de forma detallada más abajo, en la sección
"seguridad".
Y por otro lado, tenemos la siguiente configuración opcional:
Título
Versión
Fecha de creación
Fecha de actualización
URL icono de aplicación (actualmente no es funcional)
URL de instalación de la app (sólo a título informativo, no se realiza ningún tipo de
validación sobre esta URL).
Aplicaciones
Página79
JSON de configuración externa
Esta opción sólo está disponible para aplicaciones del tipo iOS y Android, y permite
inyectar configuración distinta a la configuración con la que fue compilada la versión.
Es importante aclarar que la configuración "inyectable" sólo afecta a aquellas
funcionalidades que en origen (compilación original) se hayan marcado como
"editables".
¿Para qué necesito inyectar configuración externa?
Esta opción es útil para ambientes de desarrollo o preproducción, en los que se pueden
probar aplicaciones inicialmente compiladas para un ambiente de producción, y que
podremos cambiar configuraciones como por ejemplo el endpoint del backend.
También podrá ser últil para cambiar datos de credenciales de servicios externos, como
por ejemplo, el servicio de mensajería SENDGRID. Si la cuenta de este servicio
(user/pass) cambiara, sólo habría que hacer el cambio en el backend, en el fichero de
configuración, y de forma automática, todas las apps distribuidas aplicarían el cambio
en el siguiente inicio de sesión.
¿Qué tipo de configuración puedo editar desde aquí?
propiedad
descripción
viafirmaURL
endpoint del servicio de firma, por ejemplo,
"http://testservices.viafirma.com/viafirma"
editableURL
true o false; se usa para poder apuntar a un
backend distinto con el que la app fue compilado,
por ejemplo,
"http://testservices.viafirma.com/mobile-services" .
Para ambientes de producción se recomienda
false.
frontCamera
true para permitir el uso de la cámara frontal en la
captura de evidencias del tipo foto, y false para
deshabilitarla.
true o false; si vale true, la aplicación hará logout
cuando la sesión cuando finaliza; el tiempo de
Aplicaciones
Página80
autoLogout
sesión se define en la configuración general del
sistema, por ejemplo, 30 min. Si esta propiedad
vale false, la aplicación permanece en sesión.
Para ambientes de producción se recomienda
true.
showCSV
true o false; se usa para mostrar un QR-Code que
apunta a la página de verificación de firma. Si vale
false, la última pantalla del proceso sólo indica que
la operación fue procesada correctamente.
personMask
true o false; se usa para activar o desactivar la
validación de "personas" cuando se captura una
evidencia del tipo foto.
registerHide
true oculta la pantalla de registro de dispositivo
cuando éste ya está registrado. false para mostrar
pantalla de registro de dispositivo en cada inicio
de sesión.
allowsInvalidSSLCertificate
true para omitir la validación del certificado SSL
en comunicaciones cifradas, útil para pruebas de
integración en ambientes de desarrollo cuyo SSL
no es de confianza. Se recomienda false para
ambientes de producción, y sólo en caso de que el
sistema esté configurado bajo SSL.
SSLPinningEnabled
sólo aplicable para iOS, y se usa para la
validación del certificado del SSL. Se recomienda
true para ambientes de producción, y sólo en caso
de que el sistema esté configurado bajo SSL.
evidenceBase64
true para convertir a Base64 las evidencias
capturadas. false para remitir las evidencias en
crudo.
finalize_menu_options
conjunto de configuraciones opcionales que
componen el diseño de la última página del
proceso. Por ejemplo, muestra iconos de
herramientas externas, mail, etc. Para más info,
consultar el anexo de opciones de menú.
JSON de ejemplo
{
"viafirmaURL":"http://viafirma.tigo.com.co/viafirma",
"editableURL":false,
"frontCamera":false,
"autoLogout":true,
"showCSV":false,
"personMask":true,
"registerHide":true,
"allowsInvalidSSLCertificate":true,
"SSLPinningEnabled":false,
"evidenceBase64":true,
"finalize_menu_options":[]
}
Aplicaciones
Página81
Ejemplo de configuración para finalize_menu_options: EMAIL
La configuración externa "EMAIL" sólo aplica para los documentos que son procesados
mediante formularios, y en los que se ha definido una KEY con nombre "email". Si se
encuentra dicha KEY, se usará automáticamente para remitir el documento a la cuenta
de correo que se haya informado en dicha KEY.
Si dicha KEY no se encontrara en el formulario, se mandaría a la cuenta de correo
informada en la configuración "to", tal y como se describe en el json de configuración
siguiente:
{
"email":
{
"from":{
"required":true,
"visible":true,
"default_value":"[email protected]"
},
"fromName":{
"required":false,
"visible":false,
"default_value":"Viafirmadocuments"
},
"to":{
"required":true,
"visible":true,
"default_value":"[email protected]"
},
"subject":{
"required":true,
"visible":true,
"default_value":""
},
"replyTo":{
"required":false,
"visible":true,
"default_value":""
},
"cc":{
"required":false,
"visible":true,
"default_value":""
},
"bcc":{
"required":false,
"visible":false,
"default_value":""
},
Aplicaciones
Página82
"text":{
"required":false,
"visible":false,
"default_value":"Textoaenviarporcorreo.<br/>Disclaimer...<br/>"
}
}
}
Ejemplo de configuración para finalize_menu_options: SENDGRID
{
"className":"com.viafirma.viafirmaDocuments.thirdparty.SendGridPlugin",
"automatic":true,
"name":"Envioautomáticodecorreo",
"icon":"ic_sendgrid.png",
"username":"username",
"password":"password"
}
Ejemplo de configuración para finalize_menu_options: completo
"finalize_menu_options":[
{
"className":"com.viafirma.viafirmaDocuments.thirdparty.SendGridPlugin",
"automatic":true,
"name":"Envioautomáticodecorreo",
"icon":"ic_sendgrid.png",
"username":"username",
"password":"password",
"email":{
"from":{
"required":true,
"visible":true,
"default_value":"[email protected]"
},
"fromName":{
"required":false,
"visible":false,
"default_value":"Viafirmadocuments"
},
"to":{
"required":true,
"visible":true,
"default_value":"[email protected]"
},
"subject":{
"required":true,
"visible":true,
"default_value":"Contratofirmadoconviafirmadocuments"
Aplicaciones
Página83
},
"replyTo":{
"required":false,
"visible":true,
"default_value":""
},
"cc":{
"required":false,
"visible":true,
"default_value":""
},
"bcc":{
"required":false,
"visible":false,
"default_value":""
},
"text":{
"required":false,
"visible":false,
"default_value":"Contenidodelcorreoremitido.<br/>Diclaimerejemplo..."
}
}
}
]
Seguridad
La comunicación entre las aplicaciones y el backend se realiza mediante servicios
REST, securizados con OAuth.
Cada aplicación tendrá sus propias credenciales, esto es, consumer-key y consumersecret, cuya equivalencia en la configuración de la aplicación sería la siguiente:
plataforma
consumer-key
consumersecret
iOS
com.viafirma.mobile.ios.documents
[9999999999]
Android
com.viafirma.viafirmaDocuments.Documents
[9999999999]
Swagger
com.viafirma.mobile.services
[9999999999]
Aplicaciones
Página84
Otra...
com.viafirma.mobile.crm
[9999999999]
nota: swagger es la utilidad para desarrolladores que permite el consumo de los
servicios RESTS directamente desde el backend para pruebas de integración. Esta
funcionalidad consume el servicio con las credenciales definidas aquí. Para más
información ver el capítulo Desarrollo > Servicios Rest
¿Qué tipo de autenticación debo elegir?
En cuanto al tipo de autenticación, puede usarse indistintamente una u otra, aunque se
podrá tomar en cuenta la siguiente recomendación:
Aplicaciones del tipo iOS y Android = OAuth (usuarios)
Aplicaciones del tipo API = OAuth (aplicación)
Una autenticación del tipo usuario requiere que el TOKEN intercambiado por OAuth
vaya siendo renovado. Si el usuario (o la aplicación móvil) no tiene actividad, este
TOKEN caduca, y por tanto la sesión queda invalidada.
Una autenticación del tipo aplicación gestiona la renovación del TOKEN de forma
automática, es decir, la aplicación que consuma el API REST de viafirma documents
sólo tendrá que inicializar sus credenciales una única vez, y no tendrá que gestionar la
renovación del TOKEN intercambiado por OAuth.
Más información en el capítulo "2. Uso del API REST > Securización OAuth 1.0".
Ciclo de Vida de mensajes y notificaciones
Con esta configuración podemos controlar el ciclo de vida de los mensajes y
notificaciones generados por el sistema.
Mensajes y sus Metadatos
Aplicaciones
Página85
Un mensaje, y todos sus metadatos, serán persistidos en la base de datos del sistema
durante el tiempo especificado (en días) en la configuración Borrado Mensajes.
Por ejemplo, si el tiempo indicado es de 30 días, transcurrido ese tiempo, se procede al
borrado del mensaje en la tabla "VD_MESSAGE", así como todos los metadatos
asociados a este mensaje en la tabla "VD_METADATA".
¿Dónde puedo revisar un mensaje que ya se borró de la tabla VD_MESSAGE?
Si ya se borró el mensaje, el único sitio donde se podría consultar es en la Auditoría.
Para más información ver el capítulo Panel de Control > Auditoría de Mensajes.
Notificaciones
Las notificaciones, serán persistidos en la base de datos del sistema durante el tiempo
especificado (en días) en la configuración Borrado Notificaciones.
Por ejemplo, si el tiempo indicado es de 30 días, transcurrido ese tiempo, se procede al
borrado de la notificación en la tabla "VD_NOTIFICATION".
Configuración de notificaciones push
Esta configuración sólo aplica a las plataformas iOS y Android, y para cada una de ellas
se cuenta con una configuración específica.
Configuración PUSH para iOS
Aplicaciones
Página86
Una aplicación iOS podrá tener asociados dos certificados digitales para la firma de las
push (.p12), uno para producción, y otro para los ambientes de prueba (sandbox).
Cuando se marca la casilla "Usar certificado de producción" entonces se usará el p12
para tal efecto.
Las pruebas de carga y estrés deberían realizarse con la configuración "sandbox", para
evitar que Apple pudiera interpretar ese consumo como spam y bloquee la cuenta.
Configuración PUSH para Android
Para el caso de Android no se usarán certificados .p12 sino tokens previamente
generados desde el developers center de Google.
Aplicaciones
Página87
Dispositivos
Desde el backend se tiene el control de todos los dispositivos registrados en el sistema.
La información de cada uno de ellos será usada para permitir su identificación en cada
aplicación y para cada usuario.
Campo
Descripción
Código
Es elegido por el usuario durante el proceso de registro.
Token
Es autogenerado por el sistema.
Identificador
Único
Dato ofrecido por el sistema operativo del dispositivo. En
ocasiones este dato está bloqueado o no accesible a
desarrolladores, por ejemplo, en configuraciones anti-publicidad
de Google o no rastreo del dispositivo. Estas situaciones podrían
afectar a la recepción de notificaciones push.
Descripción
Es opcional, y se le solicita al usuario durante el proceso de
registro de su dispositivo.
Tipo
Es informado automáticamente, y puede obtener los valores
ANDROID y IOS. Es un campo útil en caso de querer enviar
notificaciones push de forma masiva a todos los usuarios de un
sistema operativo en concreto, por ejemplo, ANDROID, para
informarles de una nueva actualización disponible.
Dispositivos
Página88
Idioma
Es informado automáticamente a partir de la configuración
detectada en el dispositivo móvil. Puede ser útil para saber en
qué idioma debemos mandarle una notificación a este usuario.
Estado
ACTIVE para los dispositivos que tengan una sesión iniciada, e
INACTIVE para los que no tengan sesión iniciada.
Usuario
Se informa automáticamente cuando el usuario hace login en el
sistema.
Aplicación
Identificativo de la aplicación que está usando y que previamente
ha debido ser registrada en el backend.
Notas:
todos los campos, excepto descripción, son obligatorios.
código y descripción son los únicos campos que el usuario debe rellenar
manualmente, el resto son calculados automáticamente durante el proceso de
registro del dispositivo.
Servicios para Integradores
Entre los servicios REST expuestos por el sistema se encuentran los asociados a la
entidad DEVICES.
Por ejemplo:
Obtener dispositivos del código de usuario:
GET/v1/devices/user/{userCode}
Obtener el dispositivo a partir del código de dispositivo:
(se pueden poner varios identificadores separados por coma)
GET/v1/devices/{identifier}
El objeto device:
Device{
Dispositivos
Página89
appCode(string),
code(string),
description(string),
locale(string),
status(string)=['ACTIVE'or'INACTIVE'],
token(string,optional),
uniqueIdentifier(string),
type(string)=['ANDROID'or'IOS'or'WP'],
userEmail(string),
userCode(string),
userNationalId(string,optional)
}
Para más información se pueden consultar los capítulos "2. Uso del API REST" y "4.4
Desarrollo > Servicios Rest".
Dispositivos
Página90
Grupos
La figura de grupos nos permitirá una agrupación lógica de usuarios y plantillas.
Un usuario podrá hacer uso de todas las plantillas asignadas al grupo al que pertenece.
Usuarios sin grupos asignados
Si el usuario no perteneciera a ningún grupo, o éste no tuviera asignado ninguna
plantilla, se tomará en cuenta la asignación individual de plantillas para el usuario, es
decir, las plantillas asignadas directamente en su cuenta de usuario.
Grupos
Página91
Como se puede ver en la imagen anterior, el usuario NO pertenece a ningún grupo, sin
embargo, tiene asignadas 9 plantillas.
Esta asignación de plantillas de forma individual la podrá hacer un usuario con rol
Administrador.
Grupos
Página92
Plantillas
Todo la información relativa al uso y gestión de plantillas se encuentra se describe en el
"Capítulo 6. Uso de Plantillas".
Plantillas
Página93
Actividad
Desde esta sección se podrá acceder a distintas vistas que ofrecen información útil y
actualizada de la actividad registrada.
Buscador de Metadatos
Mensajes
Notificaciones
Actividad
Página94
Buscador de Metadatos
El sistema persiste todos los datos recuperados del fomulario (key/value), pudiendo
localizar una operación a partir de algunos de los datos que fueron enviados en el
formulario, por ejemplo, en número de identificación del cliente o su correo electrónico.
La tabla en la que se persiste esta información es la siguiente:
CREATETABLEVD_METADATA
(
ID_METADATANUMBERNOTNULL,
KEYVARCHAR2(255BYTE),
VALUEVARCHAR2(1024BYTE),
ID_MESSAGENUMBER
);
y podrá ser consultada desde esta sección del backend.
BuscadordeMetadatos
Página95
Mensajes
En esta vista se encuentran todos los mensajes procesados por el sistema
independientemente de su estado.
Ofrece un punto de información vital para conocer todo el detalle de cualquier
operación.
Vista detalle
Accediendo al detalle de cada mensaje podremos consultar en detalle todo el mapa de
información asociado a él.
datos generales, como fecha, hora, usuario, etc.
worklow, mostrando fecha y hora de cada una de las tareas por las que pasó el
proceso.
Notificaciones asociadas al proceo.
Plantilla asociada al mensaje.
Datos consignados en el fomulario.
Documentos y Evidencias firmadas durante el proceso.
Mensajes
Página96
Cancelar Mensajes Enviados
Desde backend se podrá rectificar un mensaje ya enviado y recibido al dispositivo móvil.
El proceso consiste en hacer una copia del mensaje cancelado, y marcarlo con estado
standby, permitiendo ser editado y enviado nuevamente con los datos rectificados.
Mensajes
Página97
Esta funcionalidad está pensada para la rectificación de datos de documentos que ya
han llegado al dispositivo móvil de un vendedor, por ejemplo, y solicita la rectificación de
datos para poder completar la operación.
Filtro de Búsqueda
Para facilitar la explotación de esta información, se ofrecen distintas opciones de filtros
que nos permitirán acotar los resultados.
Hay que tener en cuenta que los mensajes procesados tienen asociado un ciclo de
vida, por el cual, éstos pueden ser borrados de este registro. Para más información
sobre el ciclo de vida de los mensajes y su borrado, consultar el capítulo "4.2
Administración > Aplicaciones".
Servicios para Integradores
Mensajes
Página98
Entre los servicios REST expuestos por el sistema se encuentran los asociados a la
entidad MESSAGE.
Por ejemplo:
Crear nuevo mensaje:
POST/v1/messages
Recuperar un mensaje a partir de su código:
GET/v1/messages/{messageCode}
Rechazar un mensaje:
PUT/v1/messages/reject/{messageCode}
Actualizar un documento asociado al mensaje:
PUT/v1/messages/updateDocument/{messageCode}
Para más información se pueden consultar los capítulos "2. Uso del API REST" y "4.4
Desarrollo > Servicios Rest".
Mensajes
Página99
Notificaciones
Vista que ofrece las notificaciones push emitidas desde el backend a los dispositivos
móviles registrados.
Notificaciones
Página100
Desarrollo
Sección dedicada a utilidades y apoyo para desarrolladores e integradores de los
servicios de viafirma.
Códigos de Errores
Ejemplos de Mensajes
Servicios Rest
Desarrollo
Página101
Códigos de Errores
Los errores asociados a los servicios ofrecidos por el backend están codificados y
descritos en esta sección.
Al estar internacionalizados (i18n), éstos podrán ser personalizados a la conveniencia
de cada instalación.
Los properties de definición de mensajes de error se encuentran en:
<directorio-despliegue>/WEB-INF/classes/i18n.properties
Código
Descripción
1
Debe indicar una aplicación
2
Aplicación no encontrada con el código especificado
3
Configuración de la aplicación no disponible
4
Error al procesar la configuración de la aplicación
11
Debe indicar un usuario
12
Usuario no encontrado con el identificador especificado
13
Usuario no encontrado con el email especificado
14
Usuario no encontrado con el código especificado
15
Error al guardar el usuario
16
Los datos facilitados para el acceso son incorrectos
17
No se ha podido asociar la plantilla al usuario
18
No se ha podido solicitar la reactivación de la cuenta de usuario
19
Esta cuenta de usuario ya tiene solicitada la reactivación
20
Cuenta ya activa
29
Usuario no activo
21
Debe indicar un tipo de dispositivo
22
Tipo de dispositivos no encontrado
CódigosdeErrores
Página102
23
No existen dispositivos con el token especificado
24
No existen dispositivos con el identificador único especificado
25
Se he producido un error al obtener el dispositivo
26
No se encontró ningún dispositivo según lo indicado en el mensaje
27
Se encontraron dispositivos de distintos usuarios según lo indicado en
el mensaje
28
Se ha producido un error al registrar el dispositivo
29
La notificación solo puede ser enviada a un dispositivo
31
Tipo de documento no reconocido
32
Se he producido un error al obtener el documento
33
Se ha producido un error al guardar el documento
34
Se ha producirdo un error al añadir la evidencia al documento
35
No se puede añadir una evidencia ya existente en el documento
40
Se ha producido un error al crear la plantilla solicitada
41
No se ha encontrado la plantilla para el código especificado
42
No se ha podido localizar el documento en cache
43
El usuario indicado no tiene ninguna planatilla solicitada
44
Error al recuperar la información del formulario de la plantilla
solicitada
80
No se ha podido localizar un token para usar esta app. Contacte con
el administrador del sistema
81
El token utilizado por esta app no es válido. Contacte con el
administrador del sistema
82
El token utilizado por esta app no es válido. Contacte con el
administrador del sistema
83
Ha caducado la sesión. Vuelva a hacer login en la app
84
Error en la verificación de la marca de tiempo de la petición
85
Tu sesión ha sido cerrada por inactividad. Por favor ingresa
nuevamente tus credenciales
86
Problemas al identificar esta app el servidor. Contacte con el
administrador del sistema
87
Error en el proveedor de autenticación
88
Error al firmar el contenido de la respuesta
CódigosdeErrores
Página103
89
Protocolo no soportado, solo se permiten peticiones https
51
Se ha producido un error al obtener las notificaciones
52
Se ha producido un error al enviar la notificación
53
Se ha producido un error al actualizar la notificación
61
Se ha producido un error al obtener la configuración de los workflows.
101
Se ha producido un error al preparar la firma del documento
102
Se ha producido un error al utilizar la política de firma indicada
103
Se ha producido un error en la firma de las evidencias
201
Se ha producido un error al validar el mensaje
202
Se ha producido un error al validar el mensaje
203
Se ha producido un error al validar el mensaje
204
Se ha producido un error al validar el mensaje
205
Se ha producido un error al validar el mensaje
206
Se ha producido un error al validar el mensaje
207
Se ha producido un error al validar el mensaje
208
Se ha producido un error al validar el mensaje
209
Se ha producido un error al validar el mensaje
210
Se ha producido un error al validar la notificación
211
Se ha producido un error al validar la notificación
212
Se ha producido un error al validar la notificación
212
Se ha producido un error al validar la notificación
230
Se ha producido un error guardar el mensaje en base de datos
231
Error al repostar el error a la url de callback
232
No es posible rechazar un mensaje finalizado
233
No ha sido posible realizar la operación porque el mensaje ha
expirado
234
Se ha producido un error al intentar modificar un mensaje ya
finalizado anteriormente
235
El documento ya ha sido generado previamente
401
Las credenciales utilizadas no son válidas
403
No es posible aceptar la petición
CódigosdeErrores
Página104
501
Se ha producido un error al enviar el mensaje al servicio informado
601
No existen dispositivos para el usuario indicado
701
Error al recuperar la información de estado del sistema
999
Vaya, algo no va bien y la app no puede continuar. Ciérrela y vuelva a
hacer login por favor
CódigosdeErrores
Página105
Ejemplos de mensajes
En esta sección se ofrecen formularios (.json) listos para usar con una plantilla ya
regisrada en el backend.
La idea de estos recursos es poder probar todas las funcionalidades disponibles y
reducir el tiempo de implantación de nuevas plantillas.
Por ejemplo:
Propiedad
Código
Valor
013_example
Ejemplosdemensajes
Página106
Título
2 Firmas con foto y 1 firma digitalizada con firma pdf
Descripción
3 Firmas, las dos primeras con solicitud de foto y sin firma pdf y la
tercera sin solicitud de foto y con firma del pdf con sello de
tiempo.
Este formulario (JSON) se corresponderá con la plantilla de ejemplo con mismo título,
en este caso, 013_example.
Activar recursos de prueba
Para poder optar a estos mensajes de prueba será necesario indicarlo en la
configuración durante el proceso de instalación del backend.
En concreto, la variable de configuración que activa estos recursos es la siguiente:
CREATE_TEMPLATE_EXAMPLES=true
Si se define esta variable a true, se instalarán en la base de datos todos los mensajes
de prueba disponibles. Para más información consultar el capítulo "1.4.1 Configuración
mobile services".
Ejemplosdemensajes
Página107
Servicios Rest
Esta sección es explicada en el capítulo "2.4 Uso del cliente Swagger".
ServiciosRest
Página108
Uso de formularios
El sistema permite crear formularios para ser usados como entrada de datos desde el
backend, una aplicación de terceros o el propio dispositivo móvil.
El formulario se define en formato JSON, y en esencia, contendrá tantas variables de
datos como se hayan definido en su plantilla asociada.
Podremos contar con dos clases de formularios:
1. Formulario Base
2. Formulario Avanzado
Se explican en los siguientes capítulos.
Usodeformularios
Página109
Formulario Base
Para construir un Formulario Base asociado a una plantilla seguiremos los siguientes
pasos:
1. Partimos de una plantilla registrada en el sistema.
2. Generamos desde el backend el formulario asociado a la plantilla.
Con esto, ya tendremos un FORMULARIO BASE en formato JSON asociado a nuestra
plantilla, lista para ser usada.
Un formulario base mostrará cada variable como tipo de elemento texto, sin ningún tipo
de validaciones o diseños.
FormularioBase
Página110
Para dotar al formulario de validaciones, formato enriquecido con distintos elementos
html y obtener un Formulario Avanzado, tendremos dos opciones:
usar el diseñador de formularios
editar manualmente del JSON
Ambas opciones se explican en los siguientes capítulos.
FormularioBase
Página111
Formulario Avanzado
Un formulario avanzado podrá contener formato de datos, validación de datos, listas
relacionadas, etc. Todas estas propiedades se describen a continuación.
Tipo de Datos
Validación de Datos
Tipo de Datos
Email
Caja de texto que valida si el texto introducido es un email con formato correcto.
{
"key":"email",
"type":"text",
"label":"Email",
"placeHolder":"insertemail",
"size":"33",
"validation":"email"
}
FormularioAvanzado
Página112
Como se muestra en la imagen, el teclado muestra la @ para facilitar la introducción del
correo.
Teléfono
Caja de texto que habilita el teclado númerico para facilitar al usuario la introducción de
un número de telefóno.
{
"key":"number",
"type":"tel",
"label":"Teléfono",
"placeHolder":"insertphone",
"size":"33"
}
FormularioAvanzado
Página113
Como se muestra en la imagen, se habilita el teclado de teléfono.
Fecha
Muestra elemento calendario.
{
"key":"date",
"type":"date",
"label":"Date",
"placeHolder":"date",
"size":"33"
}
FormularioAvanzado
Página114
Fecha/Hora
Muestra elemento del tipo fecha/hora.
{
"key":"datetime",
"type":"datetime",
"label":"Datetime",
"placeHolder":"datetime",
"size":"33"
}
FormularioAvanzado
Página115
Hora
Muestra elemento del tipo hora.
{
"key":"time",
"type":"time",
"label":"Time",
"placeHolder":"time",
"size":"33"
}
FormularioAvanzado
Página116
Fecha Actual
Muestra la fecha actual del dispositivo, y no permite su edición.
{
"key":"today",
"type":"todayText",
"format":"%w-%d%n%y",
"monthNames":["January","February","March","April","May","June","July","August"
"dayNames":["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"
}
Formato por defecto: "%d/%m/%y"
FormularioAvanzado
Página117
Posibles Valores:
d: Day
m: Month number
n: Month name
w: Day name
y: Full year
H: Hours
M: Minutes
S: Seconds
i: ISO date
Este elemento además permite los atributos update e increment.
{
"key":"today",
"type":"todayText",
"increment":"30",
"update":"expire_date"
}
Según el ejemplo anterior, el formulario se cargaría con la fecha actual + "30 días", y
además actualizaría el valor del campo "expire_date", con la fecha de expiración del
contrato, contando 30 días a partir de su formalización.
Número
Habilita el teclado númerico y sólo permite valores númericos.
{
"key":"number",
"type":"number",
"label":"Number",
"placeHolder":"insertnumber",
"size":"33"
}
FormularioAvanzado
Página118
Textarea
Habilita caja de texto para un mayor contenido que las cajas de texto del tipo input text.
La longitud permitida se define con el atributo height, y éste se mide en píxeles. Su
valor por defecto será de 100, el cual no hay que confundir con el atributo size, al igual
que para otros elementos, se usa para definir el tamaño del elemento en relación al
formulario, y se mide en %. Por ejemplo, si se define un valor de "50%", el elemento
ocupará la mitad de la pantalla disponible.
{
"key":"textarea",
"type":"textarea",
"label":"Textarea",
"size":"100",
FormularioAvanzado
Página119
"height":"120",
"placeHolder":"Thisisatextarea"
}
Select (lista)
Muestra el conjunto de valores contenidos en la lista informada dentro del JSON.
{
"key":"select1",
"type":"select",
"label":"SelectSample",
"list":"combos"
}
Lista precargada para el Select
La lista que alimentará al select del ejemplo 1 deberá definirse al principio del JSON tal
y como se muestra en el siguiente ejemplo:
"lists":{
"combos":["Value1","Value2","Value3"]
}
Checkbox
Muestra el conjunto de valores contenidos en la lista informada dentro del JSON.
{
"key":"checkbox1",
"type":"checkbox",
"label":"Checkboxes",
"list":"checkboxes"
}
Devolvemos string de lista de los valores seleccionados separados por el separador "|"
Lista precargada para el Checbox
La lista que alimentará al checkbox anterior deberá definirse al principio del JSON tal y
FormularioAvanzado
Página120
como se muestra en el siguiente ejemplo:
"lists":{
"checkboxes":["Value1","Value2","Value3"]
}
Radio
Muestra el conjunto de valores contenidos en la lista informada dentro del JSON.
{
"key":"radios1",
"type":"radio",
"label":"Radios",
"list":"radios"
}
Lista precargada para el Radio
La lista que alimentará la lista de valores del radio del ejemplo anterior deberá definirse
al principio del JSON tal y como se muestra en el siguiente ejemplo:
"lists":{
"radios":["Value1","Value2","Value3"]
}
¿Cómo definir varias listas precargadas?
Para alimentar varias listas que serán usadas en distintos elementos del formularios, y
siguiendo los ejemplos anteriores, se podrán informar de la siguiente forma:
"lists":{
"combos":["Value1","Value2","Value3"],
"checkboxes":["Value1","Value2","Value3"],
"radios":["Value1","Value2","Value3"]
}
Listas Vinculadas
FormularioAvanzado
Página121
Los selects pueden estar vinculados de forma que los valores mostrados en cada uno
dependan de los seleccionados en un select anterior, como la típica selección de
provincia y con ella se recarga el select de municipios que pertenecen a esa provincia.
Para su uso nos ayudaremos del siguiente ejemplo:
En 1er lugar definimos la lista padre:
"lists":{
"listaPaises":["España","Colombia"]
}
En segundo lugar definimos la listas hijas, y para ello usaremos el elemento
nestedLists.
"nestedLists":{
"listaComunidades":{
"España":["Andalucía","Galicia","Aragón"],
"Colombia":["Atlántico","Antioquia","Cundinamarca"]
}
}
Y por último definimos las listas:
"items":[
{
"key":"comboPaises",
"type":"select",
"label":"Países",
"update":"comunidades",
"list":"listaPaises"
},
{
"key":"comboComunidades",
"type":"select",
"label":"Comunidades",
"nestedList":"listaComunidades"
}]
Observar que en el segundo combo no es necesario el atributo update porque este
combo no actualiza a ningún otro combo hijo. Observar también que este segundo
combo se usa el atributo nestedList en lugar de list, como sí se usa en su combo padre.
FormularioAvanzado
Página122
Tipo Link
Este tipo de elemento se podrá usar para incluir enlaces html para llevar al usuario a
contenidos externos de la app.
{
"key":"help",
"type":"link",
"text":"help",
"href":"http://www.viafirma.com"
}
Elemento de solo lectura (disabled)
Todos los elementos permiten el atributo "disabled" para que el valor introducido sólo
sea de lectura y no permita su edición.
{
"key":"name",
"type":"text",
"label":"Name",
"placeHolder":"insertname",
"size":"33",
"disabled":true
}
Elemento de repetición (match)
Para los items del tipo "text" se permiten el atributo "match" para indicar en la validación
del formulario que el valor aquí indicado debe ser igual que el introducido en el item
referenciados, usado por ejemplo en los casos "Repita su contraseña", y "Repita su
email".
{
"key":"email",
"type":"text",
"label":"Email",
"placeHolder":"insertemail",
"required":true,
}
FormularioAvanzado
Página123
{
"key":"emailRepeat",
"type":"text",
"label":"RepeatEmail",
"placeHolder":"repeatemail",
"required":true,
"match":email
}
Validación de Datos
Todos los elementos descritos arriba, pueden incorporar la mayoría de atributos de
validación descritos a continuación:
Campo Requerido
{
"key":"name",
"type":"text",
"required":true
}
Validación: email
Aunque se cuenta con un elemento del tipo email, sería posible usar una validación de
email para cualquier elemento de texto, por ejemplo, definir un elemento tipo text, y
sobre éste aplicarle una validación de email.
{
"key":"email",
"type":"text",
"validation":"email"
}
Aunque está permitido este caso de uso, se recomienda usar el tipo de elemento
pensado para este propósito, es decir, type:email.
Validación con Expresión Regular
FormularioAvanzado
Página124
Para cualquier otro tipo de dato que se desee validar se podrá usar, de forma explícita,
una expresión regular a la hora de definir el componente.
Para incluir una expresión regular como validación en cualquier componente que
queramos montar en nuestro formulario lo podremos hacer tal y como se muestra en el
siguiente ejemplo haciendo uso del atributo validationRegex:
{
"key":"age",
"type":"text",
"validationRegex":"[0-9]+"
}
En el código anterior montamos un tipo texto para solicitar la Edad del Usuario, y en la
validación usamos una expresión regular para que sólo admita valores del 0 al 9.
Validación Longitud de Campos
Se podrá validar la longitud máxima y mínima elementos del tipo text. Para ello, se
usaremos maxlength y minlength en cada caso.
{
"key":"usercode",
"type":"text",
"maxlength":"10",
"minlength":"5"
}
Otros Atributos
De forma común, y con algunas excepciones descritas a continuación, todos los
elementos descritos anteriormente podrán hacer uso de los siguientes atributos.
Atributo
Uso
size
define el % de espacio que ocupará en una fila del formulario. Por
ejemplo, si maquetamos cuatro cajas de texto en una misma fila,
el size para cada uno sería 25.
label
nombre de la etiqueta para el elemento.
texto de ayuda que se mostrará como valor predefinido en el
FormularioAvanzado
Página125
placeholder
elemento.
FormularioAvanzado
Página126
Diseñador de Formularios
Para hacer uso de todas las posibilidades descritas para los formularios avanzados, se
recomienda el uso de la herramienta JForm Designer, de viafirma.
En el siguiente link se podrá hacer uso de la herramienta.
http://jform-designer.viafirma.com/pro/
Se podrá partir de cero, con la opción New Form, o bien partir de un formulario ya
existente, con la opción Import JSON.
Maquetación del Formulario
Se ofrecen tres elemento del tipo contenedor que nos ayudarán a maquetar nuestro
formulario:
Contenedores
Filas
El primero equivale a un contenedor html "Fieldset", y el segundo a una fila. Con ellos
podremos agrupar todos los elementos de nuestro formulario con la apariencia
deseada, teniendo en cuenta que el target principal de nuestros formularios podrá ser
un dispositivo móvil, hecho por el cual el diseño realizado con JForm Designer es
líquido, y podrá adaptarse de manera distinta a la maquetada según el dispositivo móvil
en el que se esté visualizando.
Contenedor
Lo usaremos para agrupar de manera lógica un conjunto de elementos. El contenedor
permite incluir título, y podrá tener tantas filas como se desee.
DiseñadordeFormularios
Página127
Fila
Estarán dentro de un contenedor, y en ellas insertaremos los elementos de formulario
que deseemos.
Habrá que tener en cuenta el tamaño de los mismos, haciendo uso del atributo size. Por
ejemplo, si deseeo incluir dos elementos en la fila, podré asignarle un tamaño de 50-50,
90-10, 10-90 o cualquier combinación que sume el 100% del ancho de la fila.
Las filas podrán ser desplazadas hacia arriba o hacia abajo hasta ajustarla en el lugar
deseado, siempre dentro de un contenedor. Para ello seleccionamos la fila y usaremos
los botones "Up" y "Down" habilitados en la parte superior del container.
Elementos de Formulario
DiseñadordeFormularios
Página128
Una vez tengamos definida la estructura contenedora, ya podremos insertar tantos
elementos de formularios como deseemos. Para ello seleccionaremos la fila en la que
deseemos insertar el elemento, y usamos el botón Add item o Remove.
Una vez añadido a la fila, podremos desplazarlo a derecha o izquierda, con los botones
Right y Left, y editar sus propiedades, con el botón Edit.
DiseñadordeFormularios
Página129
Listas y Listas Anidadas
Para los elementos del tipo listas tenemos una gestión específica. Para ello, usaremos
los accesos directos Edit lists y E dit nested lists.
DiseñadordeFormularios
Página130
DiseñadordeFormularios
Página131
Políticas de Firma y Evidencias
El diseñador de formularios también permite modelar las políticas de firma y evidencias
electrónicas. Para ello, haremos click en el botón Add policy.
Podremos agregar tantas políticas como queramos. Una política estará compuesta por
dos partes:
Política de firma.
Política de evidencia.
Política de Firma
Al hacer click sobre el botón edit del contenedor de política, accederemos a un panel en
la parte derecha donde se mostrarán todas las propiedades configurables para la
política de firma.
Identificación
Políticas
Página132
Propiedad
Valor
Type
Pen o Biometric; determina el punto en el que se realiza el cifrado
de la infomración biométrica. Pen = cifrado en servidor, y
Biometric para cifrar en el propio dispositivo móvil, a partir de la
clave informada para tal efecto.
Help Text
Ayuda contextual que se le mostrará al usuario final. Resultará útil
cuando un documento cuenta con varias políticas de firma y
queremos guiar al firmante. Por ejemplo, "Firma del aval del
contrato", "Firma del titular del contrato", etc.
Biometric Cypher
Políticas
Página133
Propiedad
Valor
Public key
Si queremos que los datos biométricos capturados vayan cifrados
con una clave pública específica, usaremos esta propiedad para
pegar su valor, en formato PEM.
Propiedades firma XML
Políticas
Página134
Propiedad
Valor
Alias
del certificado con el que se firmará el documento en servidor.
Password
del certificado con el que se firmará el documento en servidor.
Propiedades firma PDF
Políticas
Página135
Propiedad
Valor
Alias
del certificado con el que se firmará el documento en servidor.
Password
del certificado con el que se firmará el documento en servidor.
Posición de la firma
La posición de la firma se puede definir de dos formas:
Posición predefinida por coordenadas.
Posición libre, elegida en última instancia por el usuario.
Posición predefinida por coordenadas
Políticas
Página136
Propiedad
Valor
Page
Número de la página en la que se insertará la firma. Podemos usar
distintos valores separados por coma. Para colocar la firma en
todas la firmas usaremos el valor cero (0).
Width
Ancho de la imagen.
Height
Alto de la imagen.
X position
Indica la posición en píxeles del vértice superior izquierdo de la
imagen.
Y position
Indica la posición en píxeles del vértice inferior derecho de la
imagen.
Políticas
Página137
Posición de libre elección
Si marcamos la opción "Choosen by the user" la posición se fijara en el proceso de la
firma, haciendo doble tap sobre la posición deseada en el documento.
Política de Evidencia
Las evidencias podrán ser de dos tipos:
Evidencia del tipo foot
Evidencia del tipo huella (fingerprint)
Evidencia tipo foto
Políticas
Página138
Propiedad
Valor
Type
Annotation es el equivalente a captura de fotos.
Type
Format
Sign
Formato de firma, a elegir entre los formatos: DIGITALIZED_SIGN,
DIGITALIZED_SIGN, PAdES_BASIC, PAdES_BES,
PAdES_EPES, PAdES_LTV o PDF_PKCS7
Helptext
Ayuda contextual que se le mostrará al usuario final. Resultará útil
cuando un documento cuenta con varias políticas de firma y
queremos guiar al firmante. Por ejemplo,
Algorithm
Se refiere al algoritmo de cifrado. Si se deja en blanco se usará
SHA1. Se puede optar por SHA256.
Alias
del certificado con el que se firmará la evidencia en servidor.
Password
el certificado con el que se firmará la evidencia en servidor.
Políticas
Página139
Contenedor de la Evidencia
Podremos definir las características del contenedor en el que se representará la
evidencia del tipo foto.
Para ello, haremos click en "Add rectangle" y definiremos el tamaño y posición del
contenedor.
Propiedad
Valor
Width
Ancho del contenedor.
Height
Alto del contenedor.
X position
Indica la posición en píxeles del vértice superior izquierdo del
contenedor de la foto.
Y position
Indica la posición en píxeles del vértice inferior derecho del
contenedor de la foto.
Eviencia tipo huella (fingerprint)
Políticas
Página140
Políticas
Página141
Propiedad
Valor
Type
Annotation es el equivalente a captura de fotos.
Type
Format
Sign
Formato de firma, a elegir entre los formatos: DIGITALIZED_SIGN,
DIGITALIZED_SIGN, PAdES_BASIC, PAdES_BES,
PAdES_EPES, PAdES_LTV o PDF_PKCS7
Helptext
Ayuda contextual que se le mostrará al usuario final. Resultará útil
cuando un documento cuenta con varias políticas de firma y
queremos guiar al firmante. Por ejemplo,
Algorithm
Se refiere al algoritmo de cifrado. Si se deja en blanco se usará
SHA1. Se puede optar por SHA256.
Finger ID
Indica el dedo al que pertenece la huella capturada. Podrán
tomarse hasta un máximo de 10, una por cada dedo de las dos
manos.
Alias
del certificado con el que se firmará la evidencia en servidor.
Password
el certificado con el que se firmará la evidencia en servidor.
Contenedor de la Evidencia
Podremos definir las características del contenedor en el que se representará la
representación gráfica de la huella.
Para ello, haremos click en "Add rectangle" y definiremos el tamaño y posición del
contenedor.
Propiedad
Valor
Width
Ancho del contenedor.
Height
Alto del contenedor.
X position
Indica la posición en píxeles del vértice superior izquierdo del
contenedor de la huella.
Y position
Indica la posición en píxeles del vértice inferior derecho del
contenedor de la huella.
Políticas
Página142
Uso de Plantillas
En este capítulo se explicará todo lo necesario para el máximo aprovechamiento del uso
de plantillas.
Creación de plantillas
Uso desde backend
Uso desde móvil
Servicios para integrdores
Usodeplantillas
Página143
Creación de Plantillas
El sistema de plantillas implementado en mobile services soporta formato Word .docx y
formato openOffice .odt, y está basado en la inclusión de variables de forma cómoda e
intuitiva.
A continuación se explican dos formas de uso, ambas desde Microsoft Word.
Con prefijo "$"
Con campo "merge field"
Uso del prefijo "$"
Para insertar en nuestro documento una variable sólo será neceario insertar en el lugar
deseado el nombre de la variable precedida de $, por ejemplo $client_surname .
Nombredecliente:$client_name
Apellidosdelcliente:$client_surname
Importedelacompra:$purchase_amount
CreacióndePlantillas
Página144
Uso merge field
Otro mecanismo de insertar variables en nuestra plantilla será haciendo uso del merge
field. Y a diferencia del mecanismo anterior, para insertar una nueva variable debemos
posicionarnos en el lugar deseado y seleccionar la opción insertar campo del tipo Merg
Field, que en cualquier caso dependeraá de la versión del Editor de Texto con el que se
trabaje.
CreacióndePlantillas
Página145
La ilustración anterior muestra explica el acceso a la opción merge field sobre una
versión de Microsoft Word 2007 para Mac.
CreacióndePlantillas
Página146
Uso desde backend
Una vez tengamos creada nuestra plantilla, ya podremos darla de alta en el backend.
Registrar plantillas
Para registrar una nueva plantilla necesitaremos:
datos identificativos
plantilla (.docx .odt)
formulario asociado
Datos Identificativos
Dato
Descripción
Código
Se trata de un campo obligatorio, será el identificador único de
cada plantilla. No es necesario que sea descriptivo, para eso se
podrán usar los campos títulos y descripción.
Título
Nombre corto de la plantilla a modo de título. Este dato se
mostrará en la "tarjeta" de la aplicación móvil.
Descripción
Nombre largo de la plantilla a modo descripción. Este dato se
mostrará en la "tarjeta" de la aplicación móvil.
Plantilla
Se subirá la plantilla en formato .docx o .odt, tal y como se explicó anteriormente, y una
vez agregada finalizaremos el registro de la nueva plantilla, haciendo click en "Guardar".
Formulario
Una vez que la plantilla ha sido registrada en el sistema, podremos asociarle un
formulario.
¿Para qué se usa el formulario?
El formulario será la fuente de entrada a los datos esperados en la plantilla. Por
ejemplo, si en la plantilla se insertaron 3 campos (keys), $client_name, $client_surname
Usodesdebackend
Página147
y $purchase_amount, nuestro formulario mostrará, como mínimo, tres cajas de texto
para que el usuario pueda completar el dato requerido.
¿Cómo creo el formulario?
El formulario esperado es en formato .json, y podremos generarlo automáticamente de
la siguiente forma.
1. editamos la plantilla anteriormente creada
2. hacemos click sobre "Generar formulario desde esta plantilla".
3. se descargará un formulario en formato .json
4. adjuntamos el .json descargado a "Formulario".
En el capítulo "5. Uso de formularios" se describe en detalle todo lo relativo a la
creación y optimización de formularios, así como el uso de elementos avanzados de
formularios.
Usar una plantilla
Para usar una plantilla desde el backend sólo tenemos que hacer click sobre el botón
"+" situado a la derecha de cada plantilla.
Usodesdebackend
Página148
Esto nos llevará a un página que contiene dos bloques de información:
configuración de la petición
campos del formulario asociado a la plantilla
Configuración de la Petición
En este primer bloque debemos seleccionar a qué usuario vamos a enviar el mensaje,
para lo que el sistema nos ofrecerá ayuda "predictiva" en el momento de localizar al
usuario.
nota: para que el sistema muestre la ayuda predictiva es necesario digitar al menos tres
caracteres.
A: podemos buscar al usuario de forma indistinta con o sin grupo; si elegimos un
grupo, el sistema filtrará sólo los usuarios que pertenezcan a dicho grupo.
Usodesdebackend
Página149
B: una vez elegido el usuario, se mostrarán todos los dispositivos registrados a
nombre del usuario seleccionado, así como las aplicaciones disponibles. Deberá
elegirse por tanto el dispositivo y la aplicación deseada.
C: cofiguración opcional que se refiere al uso de las peticiones del tipo "Origen
Mixto". Si marcamos este check, el usuario recibirá en su dispositivo móvil un
formulario con los datos informados previamente en esta pantalla, pudiendo
completar los que falten o incluso modificar los que ya existen.
D: también de forma adicional, y sólo en caso de haber marcado el check descrito
anteriormente para "Origen Mixto", si marcamos este check, el formulario que verá
el usuario en su dispositivo móvil tendrá deshabilitados los campos que ya fueron
informados en esta pantalla, pudiendo completar sólo los campos vacíos.
E: título y descripción de la notificación push que le llegará al usuario en su
dispositivo móvil.
Guardar como Borrador
Usodesdebackend
Página150
El formulario podrá ser enviado al dispositivo móvil seleccionado, pulsando en
continuar, o bien guardar como borrador para enviarlo más adelante.
Plantillas con Localización
Dependiendo de la configuración del formulario, en la plantilla se mostrarán los
elementos de datos asociados, fecha, listas, etc., incluso si se incluyen campos del tipo
LOCATION, para indicar una geolocalización.
Usodesdebackend
Página151
Al indicar localización, el mensaje no se podrá leer a más de 100 metros de la
ubicación exacta.
El dispositivo necesita autorizar el uso del GPS.
El mensaje podrá ser editado desde backend para eliminar la restricción del GPS.
Existen plantillas de ejemplo que hacen uso de este tipo de dato (LOCATION).
Consultar en el "Capítulo 4.4.2 Ejemplos de mensajes" para más información.
Plantillas con Código de Bloqueo
Al indicar un código de bloqueo, el mensaje no podrá ser visualizado sin la validación
correcta.
Usodesdebackend
Página152
Existen plantillas de ejemplo que hacen uso de este tipo de dato (VALIDATION
CODE). Consultar en el "Capítulo 4.4.2 Ejemplos de mensajes" para más información.
Importar desde JSON
Se permite importar un JSON ya listo para ser enviado, ofreciendo utilidad cuando un
mismo mensaje pueda repetirse para un mismo destinatario, ahorrando tiempo de
proceso.
Usodesdebackend
Página153
Sobre usuarios y grupos
Usuarios sin plantillas asignados
Si el usuario no tuviera asignada ninguna plantilla, se tendrán en cuenta las plantillas
asignadas a su grupo.
Como se puede ver en la imagen anterior, el usuario NO tiene asignada ninguna
plantilla, sin embargo, pertenece a un grupo, por lo que en principio podrá hacer uso de
todas las plantillas autorizadas a su grupo.
Usuarios y Grupos
En estos casos, el usuario no podrá hacer uso de plantillas, bien desde el backend, o
bien desde su propio dispositivo móvil.
Esto no significa que el usuario no pueda hacer uso del sistema. Por ejemplo, podrá
recibir documentos listos para firmar en su dispositivo móvil.
Es decir, puede ser perfectamente normal contar con usuarios sin grupos ni plantillas.
Estos usuarios serán aprovisionados vía integración sin mayores problemas.
Usodesdebackend
Página154
Uso desde móvil
De igual forma a como lo haríamos desde un backend, el formulario asociado a una
plantilla podrá rellenarse desde la app móvil (iOS y Android). Para ello se accederá al
menú de formularios asociados a cada plantilla.
También se respetarán los tipos de datos según la configuración realizada para el
formulario.
Usodesdemóvil
Página155
Usodesdemóvil
Página156
Servicios para Integradores
Entre los servicios REST expuestos por el sistema se encuentran los asociados a la
entidad TEMPLATE.
Por ejemplo:
Obtener todas las plantillas de un usuario:
GET/v1/template/list/{userCode}
Obtener una plantilla a partir del código de plantilla:
GET/v1/template/{code}
El objeto template:
TemplateList{
code(string),
title(string),
description(string),
creationDate(string,optional),
version(integer)
}
Para más información se pueden consultar los capítulos "2. Uso del API REST" y "4.4
Desarrollo > Servicios Rest".
ServiciosparaIntegradores
Página157
Manual de actualización el sistema
En las siguientes secciones se explicará con detalle, las acciones necesarias para
actualizar viafirma documents a la última versión disponible.
Debe ejecutar los procedimientos de actualización de forma secuencial hasta llegar a la
versión que desea instalar.
Procedimientodeactualización
Página158
Próxima release / 2015-09
Nueva alerta que controla un número elevado de items por cola (hazelcast).
Nuevas estadísticas de usuarios y dispositivos, disponibles en el panel de control.
Optimización de registros de auditoría (tabla VD_MESSAGE_AUDITORY).
Soluciona problemas con la transferencia de mensajes procesados (sólo afecta a
repositorios externos).
Optimización de la persistencia de metadatos. Ahora sólo se persisten datos del
formulario (pattern document.items.*).
Optimización de la búsqueda de metadatos.
Se añade configuración en panel de control para la nueva funcionalidad de
geolocalización de documentos firmados a través de las APIs de Google Maps.
Mejora del panel de configuración.
Se desactiva el control de descarga de documentos firmados incluido en la revisión
anterior.
2.5.8 / 2015-08-14
Se añaden mecanismos de control para la descarga de documentos firmados en
entornos con repositorios de filesystem sincronizados.
Corrije problema en la persistencia de mensajes cuando el dispositivo ha sido
borrado.
Mejora en el control de mensajes caducados.
2.5.7 / 2015-07-14
decouple node queue
change permissions to edit user data
update json form builder v1.0.13
change param class to className in json config
optional expired date to import users
2.5.6 / 2015-06-30
Históricodecambiosyversiones
Página159
changes in hazelcast.xml to allow manager-center monitoring
viafirma preference value of json application if exist
new option in control panel to manage the maximum notifications for system alerts
2.5.5 / 2015-06-02
Fix encoding at get template by code.
Avoid NullPointerException at transform old policies when form template has no
policy.
fix double url encode in path params in oauth request filter
fix double url encode in path params in oauth request filter
Add refresh filter button for messages view
2.5.4 / 2015-06-01
fix error in search device
fix old policies in template form settings
inactive devices in register new device
Update hazelcast.xml
2.5.3 / 2015-05-27
fix form policy params
Update Readme.md
Readme jMeter.
Adding images to jMeter Readme.
New version jMeter configuration.
Configuration JMeter.
Fix Piecharts view
Log PRO tigo - Avoid error 404.
JMeter configuration.
Update upgrade_0.0.55_to_0.0.56.sql
Configuration Viafirma JMeter.
Configuration jMeter.
Históricodecambiosyversiones
Página160
2.5.2 / 2015-05-20
fix default template version on create new
2.5.1 / 2015-05-19
update to 2.5.1
Update application context.xml
fix error in java code
Now the document preview download the signed document
Update DownloadServlet.java
Control access token with jMeter tests.
Check code template at importing new message.
Add network parameters to get hazelcast cluster. - Order (desc) notification list
view by create date
Increased runtime system testing
2.5.0 / 2015-05-18
fix template version error
update 0.0.56 sql scripts
remove 028_example
update 0.0.56 sql scripts
fix html forms style
JMeter new test new document loop.
fix computec excepciones
Several conflicts have been merged.
JMeter Test complete flow at created document.
Test de integración con Manager modificado. - Se ha tenido en cuenta para las
estadísticas que no haya mensaje.
Update 01_services_tablas.sql
Update upgrade_0.0.55_to_0.0.56.sql
Add Viavansi cluster dev profile
add templateVersion info
Históricodecambiosyversiones
Página161
fix compile error
Add user expired date at template to import users.
Improve log.
Add Junit computec
Fix insert auditory message when it expires.
Testing create message with pdf generation.
update expite message proccess
configure task from getCanonicalName
fix error in reject and clone messages
refactor workflows in xml and task manager
refactor workflows manager
remove downloaded documents
add demo 002
backend now update notification completed
Example for waiting_form states.
New status to allow form edit from mobile apps. Rest service to update form in a
message.
Desarrollo de test de funcionamiento de sistemas externos
Set default workflow configuration.
Workflow at xml file.
Estadísticas de uso RC1
More charts changes
Inicial code
fix isRejectable method
update json form and 024_example
Change application version to 2.4.0-RC1
Fix create/edit user with expired date
Add user expired date at template to import users.
Add new system_status
Fix insert auditory message when it expires.
Testing create message with pdf generation.
update expite message proccess
configure task from getCanonicalName
fix error in reject and clone messages
refactor workflows in xml and task manager
refactor workflows manager
update to 2.5.0
remove downloaded documents
add demo 002
Históricodecambiosyversiones
Página162
update USER_CREDENTIALS_ERROR i18n
add notification rejected control
backend now update notification completed
Example for waiting_form states.
New status to allow form edit from mobile apps. Rest service to update form in a
message.
Modificado fichero de configuración de hazelcast para nodos en PRO
Add profiles and conf for new nodes in PRO
Desarrollo de test de funcionamiento de sistemas externos
Set template version.
Set default workflow configuration.
Workflow at xml file.
Estadísticas de uso RC1
More charts changes
Inicial code
2.4.2 / 2015-05-04
Solve literal errors
2.4.0 / 2015-04-28
update USER_CREDENTIALS_ERROR i18n
Merge pull request #129 from viavansi/notification_completed
update USER_CREDENTIALS_ERROR i18n
Merge pull request #129 from viavansi/notification_completed
add notification rejected control
backend now update notification completed
Merge pull request #127 from viavansi/encodingJSON
Merge pull request #128 from viavansi/report
Improve labels in report page. Locale calendar primefaces.
Check encoding UTF-8 at JSON files.
Merging version 2.3 to master (2.4)
Merge pull request #126 from viavansi/fixErrorsConstraint
Merge branch 'activeAccount_#20324'
Merging to master [ refs #20324 ]
Fix errors due to unique code constraint at auditory messages.
Históricodecambiosyversiones
Página163
Report page for messages and transfer jobs.
Merge pull request #125 from viavansi/logbackTigo
Mark error level at pro tigo log.
Add ScheduledTask entity
Add email param to reactivateUserByCode in IndexPage
Config logback ms-transfer tigo dev/pre/pro
Merging reactivate user account messages.
Reactive user account [ refs #20324 ].
Add fgomez account to param "REPORT_TRANSFER_JOB_RECIPIENTS"
Merge branch 'master' of https://github.com/viavansi/mobile-services
Add email to reactivate service
update hazelcast config
Set value OAUTH_EXPIRE_TOKEN_MINUTES to 60 minutes
Set value OAUTH_EXPIRE_TOKEN_MINUTES to 60 minutes
Merge branch 'fix_2.4.0'
add computec_key in settings
Update upgrade_0.0.53_to_0.0.54.sql
Add "fr.opensagres.xdocreport" to INFO level
Update upgrade_0.0.53_to_0.0.54.sql
Update 06_services_views.sql
Update 06_services_views.sql
Update upgrade_0.0.53_to_0.0.54.sql
Update upgrade_0.0.53_to_0.0.54.sql
Update upgrade_0.0.53_to_0.0.54.sql
Merge branch 'releases_2.3.X' into fix_2.4.0
Add status<>'REJECTED' to conditions
Add status<>'REJECTED' to conditions
Merge pull request #123 from viavansi/fix_version_2.4.0
change login error message
fix 2.4.0 errors
working in selenium test
Update upgrade_0.0.51_to_0.0.52.sql
Update database connection
Merge pull request #122 from viavansi/migrationPage
Not assign templates to groups at migration from role to group.
Merge pull request #121 from viavansi/fix_api_dto
add missing atributes
Merge pull request #120 from viavansi/errorsComputec
Merged
Históricodecambiosyversiones
Página164
Check not controlled errors at transfer job list (computec). Created transfer job log.
Update upgrade_0.0.53_to_0.0.54.sql
Add control for expired users
Merge pull request #119 from viavansi/fix_version_2.4.X
update config page
Merge pull request #118 from viavansi/userexpired#20324
prepare viafirma dev context
add userCode in mail body (reactivate account)
restore findNotificationsByCode in swagger doc
Merge branch 'releases2.3.X' into user_expired#20324
Merge branch 'master' into userexpired#20324
Merge branch 'refactorsystem_status' into user_expired#20324
update reactive account
refactor configuration vars and expired sessions
Merge pull request #117 from viavansi/fixSonarIssues
Update i18n.properties
Fix some Sonar issues.
Fix empty string as value in message items.
Merge branch 'master' into userexpired#20324
show localized text
delete tasks test
fix error in notification expires time
Servicio para petición de reactivación de cuenta
fix error in delete duplicate rows in message auditory
fix error in hazelcast shutdown
Merge branch 'releases_2.3.X'
Merge pull request #115 from viavansi/refactor_rest_services
disable auto update
update pom version to 2.4.0
fix encoding errors in applicaction web pages
add device unique identifier in backend
add update mobile app info
disable jpa cache
Local commit;
add install version info to configuration rest service
refactor edit application page
get config app without login
refactor viafirma config param
set pom version in swagger api
Históricodecambiosyversiones
Página165
Merge branch 'master' into refactor_rest_services
update hazelcast config
Temporal commit
fix SwaggerBootstrap weblogic
fix hazelcast 3.4 instance
update serialVersionUID in JSMessage
Temporal data (not working)
update hazelcast config weblogic
exclude jmeter class in weblogic profile
Merge branch 'refactor_rest_services' into test_weblogic_2.3.0
Temporal commit.
Merge branch 'test-service-generator' into refactor_rest_services
organize imports
Merge branch 'master' into refactor_rest_services
test service generator
Merge branch 'master' of https://github.com/viavansi/mobile-services
Merge branch 'master' of https://github.com/viavansi/mobile-services
Temporal commit
refactor rest services
add JUnit test for evidence error
2.3.3 / 2015-04-15
branch release_2.4.x -> FETCH_HEAD
Deny updating messages at rejected status.
Update upgrade_0.0.53_to_0.0.54.sql
Update 06_services_views.sql
Update 06_services_views.sql
Update upgrade_0.0.53_to_0.0.54.sql
Update upgrade_0.0.53_to_0.0.54.sql
Update upgrade_0.0.53_to_0.0.54.sql
Merge branch 'releases_2.3.X' of https://github.com/viavansi/mobile-services into
releases_2.3.X
update OAUTH_SIGNATURE_ERROR message
Update logback.xml
Add status<>'REJECTED' to conditions
Add status<>'REJECTED' to conditions
update logback config pro
Históricodecambiosyversiones
Página166
Fix ALTER TABLE vd_message
Save i18n in ISO
Update database connection
Update i18n.properties
Fix update errors in queries
Add OAUTH_EXPIRE_TOKEN_MINUTES param.
Update param "expire tokens time in minutes" to 30 minutes
Update i18n.properties
Add OAUTH_EXPIRE_TOKEN_MINUTES param.
Update app version to 2.3.3
Fix empty string as value in message items.
Update app version to 2.3.2
Fix param OAUTH_EXPIRE_TOKEN_MINUTES twice time!
Comment export message until check file size.
Fix current status to save auditory data.
Apply delete constraints on cascade.
Add constraint unique token and index at table vd_token.
Merge branch 'releases_2.3.X' of https://github.com/viavansi/mobile-services into
releases_2.3.X
Fix import users in case of number cells as string cells.
Update Persistence.java
Update pom.xml
Update context.xml
Utilización de tabla ScheduleTask para persistencia de acciones de hilos. Solución al envío por duplicado del informe de transferencias.
Make to push button at filtering metadata.
Merge branch 'releases_2.3.X' of https://github.com/viavansi/mobile-services into
releases_2.3.X
Merge pull request #113 from viavansi/expiredMessages
Local commit
Merge pull request #112 from viavansi/fixTemplateEdit
update changelog
update changelog
Fix edit template with admin role.
Get message from auditory path when it was deleted. Set consistent data in order to
apply constraints at unique codes on several tables. It requires checking previously
(scripts are commented in upgrading files to avoid run them automatically).
Merge pull request #111 from viavansi/messageReport_#19466
Históricodecambiosyversiones
Página167
Merge pull request #110 from viavansi/assignGroupsFromUser
Merge pull request #109 from viavansi/searchMetadatas
Remove filter metadata at message search page.
Assign groups to user from user edit page.
Search by metadatas message.
New page for filtering metadata messages.
Merge pull request #108 from viavansi/fixCreateGroups
Visibility at assignation of users and templates to groups.
Not allow assign users or templates to a group until it is created.
Report filtered messages sending email to user in case of too much items. [ refs
#19466 ]
fix weblogic config
Merge pull request #107 from viavansi/fixTemporalData
Fix saving temporal data of messages with evidences.
2.3.0 / 2015-03-17
Merge pull request #106 from viavansi/fix_2.3.0_tigo_errors
update hazelcast config tigo dev
add old storage params for migrations system
fix error in cache test
fix oracle scripts template_view
fix error in rejected message
Merge pull request #105 from viavansi/fixRejectMessage
Fix reject message params.
Merge pull request #102 from viavansi/migrateRole
Merge pull request #104 from viavansi/decodeURL
Decode url at notification service.
Merge pull request #103 from viavansi/filterNotifications
Fix filter at notifications list.
Migrate previous roles to actual default roles.
Merge pull request #101 from viavansi/menuAdmin
Admin role menu visibility.
Merge pull request #100 from viavansi/add_reject_message_comment
add reject message in message view
update v1/template/list/{code} to v1/template/list/{userCode}
fix error in swagger css
Merge pull request #99 from viavansi/editMessage
Históricodecambiosyversiones
Página168
Select default device at creation message.
Merge branch 'editMessage' of https://github.com/viavansi/mobile-services into
editMessage
Fix required fields at stand by option.
Merge pull request #98 from viavansi/fix_error_2.3.0
Fix required fields at stand by option.
fix error in message view without location info
add KEY_VALIDATE_CODE key in form for add validateCode in Notification
Fix script for oracle
Merge pull request #97 from viavansi/editMessage
Include map at edition message page.
Avoid return pressing enter at forms.
Delete deprecated params.
Update with param "expire tokens time in minutes"
Merge pull request #96 from viavansi/issuesNewMessage
USER role only can create messages to himself.
Group required if not admin user.
Filter mobile applications and set required fields at message creation.
New template with geolocation and validation code.
fix label in validate code
Merge branch 'master' of https://github.com/viavansi/mobile-services
Fix validate code.
fix validate code example
Merge pull request #95 from viavansi/validateCode
Validate code at message.
Merge pull request #94 from viavansi/menuDeveloper
Api messages view for developer role.
Merge pull request #93 from viavansi/templateView
Control templates view by roles.
Merge pull request #92 from viavansi/manage_permissions_2
admin list all devices
Merge pull request #91 from viavansi/adminViewMessage
Admin role can view all messages.
Merge pull request #90 from viavansi/roleActionList
fix notifications expired view
localize role name
Security filter if not Authenticated
0.0.51 data base version
check roles in user in session
Históricodecambiosyversiones
Página169
Merge pull request #89 from viavansi/geoupgrade#19464
Ref. #19465
temporal commit
Merge pull request #88 from viavansi/importUsersExcel
Check groups and role before assignment.
Merge branch 'master' into importUsers
Fix user import by excel file.
Merge branch 'roleActionList' of https://github.com/viavansi/mobile-services into
roleActionList
Read only role actions at edition role.
Restrict edition of role actions.
Merge pull request #87 from viavansi/push_optional
fix error in notifications query
Read only role actions at edition role.
notification order by creation date desc
change config mail server dev
Merge pull request #85 from viavansi/geoupgrade#19464
Merge pull request #86 from viavansi/deletete_old_swagger_servirces
upgrade pom version to 2.3.0
refactor notifications services
fix duplicate error code
add expire date in message view
add missing locale text
Restrict edition of role actions.
delete old swagger services doc
Se añade condición de ocultación según disponga de geolocation el form.
Integración con google maps utilizando javascript y no librería externa con miras a
utilizar el API de Google Maps for Business.
Merge pull request #84 from viavansi/pagNotifications
Change label of application select at creation message.
Change list implementations.
Update 01_services_tablas.sql
Update 05_services_indexes.sql
Update 02_services_constraints.sql
Update 01_services_tablas.sql
Pagination at notification services.
fix hazelcast config dev
fix hazelcast config dev
prepare config dev.viafirma.com
Históricodecambiosyversiones
Página170
Merge pull request #83 from viavansi/hazelcast_data_base
fix error in api messages examples
add 026 example (standby)
fix error in log message
update template list
0.0.50 data base scripts
change 0.0.48 to 0.0.50
change to last_update
update jmeter config
move code to TemporalPersistenceHelper
move code to JSMessagePersistenceHelper
update MSOAuthProvider
Add default value for OAUTH_EXPIRE_TOKEN_MINUTES Add install.bat file for
jmeter in Windows
Temporal commit
delete messages and temporal documents cache
remove duplicate oauth filter
update jmeter test
remove hazelcast_bootstrap
Add indentificator group_code to view messages.
Cambio en el nombre de la columna DATE a LAST_UPDATE en
VD_TEMPORAL_DATA
token in AES
add metadata in oauth tokens
fix error in store JSMessage
remove expired oauth tokens
implements serializable
update jmeter test
add spire time in store JSMessage
update view
fix error in template examples import
delete log message
fix errors in hazelcast data base
store messages always in data base
remove oauth response filter
Hazelcast test
new data base version postgresql
store temporal pdfs and images in data base
store OAuth token ins data base
Históricodecambiosyversiones
Página171
add changes in template view
Update 05_services_indexes.sql
Update 02_services_constraints.sql
Update 01_services_tablas.sql
Update 01_services_tablas.sql
Merge pull request #82 from viavansi/notificationServices
Rest services for list notifications.
Merge pull request #81 from viavansi/importJSON_#19444
Merged with previous changes.
Update web.xml
Update ApiExamplesHelper.java
Merge pull request #75 from viavansi/importUsers_#18214
Import message data from JSON. [ refs #19444 ]
Update MessagesService.java
Update MessagesService.java
Merge pull request #80 from viavansi/geo_#19464
Update Persistence.java
Geolocation_Ref. #19464 ○ Posibilidad de añadir geolocalización a través de
google maps en un mensaje. ○ Persistencia de la geolocalización si procede en
notificaciones. ○ Envío de geolocalización a las notificaciones. ○ En el detalle de la
notificación se muestra la geolocalización si existe. ○ Cambios en BBDD: - Añadido
campo geolocation en la tabla notificaciones.
Merge pull request #79 from viavansi/actionsRoleGROUP
Menu visibility with role GROUP.
Actions for role GROUP.
Merge pull request #78 from viavansi/constraints
Update inconsistent data to apply constraints at the db.
Update context.xml
Update context.xml
Update context.xml
Update context.xml
Update context.xml
Update context.xml
Merge pull request #77 from viavansi/constraints
Merge pull request #76 from viavansi/selectApp_#19463
Applying unique constraints at group and role.
Filter devices by application at new message page. [ refs #19463 ]
Fix and improve code referred in comments.
Massive user import.
Históricodecambiosyversiones
Página172
update hazelcast config
Merge pull request #74 from viavansi/hazelcast_cluster
try fix hazelcast start
Eliminación del punto final de la opción de menú "Gestión de roles"
Removed unused code.
Merge branch 'master' of https://github.com/viavansi/mobile-services
Ref. #20464
Merge pull request #73 from viavansi/hazelcast_cluster
try fix hazelcast shutdown
add jobs system
Merge pull request #71 from viavansi/evidences_error
Merge pull request #72 from viavansi/forms_by_user_group
protect insert null in hazelcast map
add oracle scripts changes
Update Persistence.java
Merge pull request #70 from viavansi/fixNewMessage
Fix adding user at new message page.
Create constants and shutdown hazelcast instance method
add flush in store method
add JUnit test for evidence error
add new rest template service
add new rest template service
Merge pull request #69 from viavansi/update_#20081
Uncomment mail sender.
Restore period of report schedule timer.
Ref. #20081 Charts
Ref. #20081 - Charts in excel
Merge pull request #68 from viavansi/userGroupMessage_#19463
Changing logo size.
Changing logo.
Filtering by group and user at new message page.
Some improved details and filter templates by user in session.
Merge pull request #66 from viavansi/fixMigrateRole
Merge pull request #67 from viavansi/listMessages_#19453
Change order at create message view into scripts of upgrading.
Merging with previous changes.
Improving code at role migration.
Fix behaviour at roles migration.
List message filtering by group. [refs #19453 ]
Históricodecambiosyversiones
Página173
Temporal Commit.
Merge pull request #65 from viavansi/restService_#19519
Merging previous changes
Add user into notification. [ refs #20329 ]
List notifications by user, status and device (optional). [ refs #19519 ]
Fix behaviour at roles migration.
Merge pull request #64 from viavansi/test_hazelcast
fix hazelcast config
format source code
update config viavansi dev hazelcast and logback
fix error in template update
fix error 3.4 hazelcast migration
fix error in notification view
configure hazelcast log to info
fix log error in json parser
Store token in disk
fix sonar pull request comments
TimeStamp with System.currentTimeMillis()
fix null cache queue name
Set 2 seconds in mail sender connection time out
remove poll in System Status
fix error in DataTable
fix rebase master error
temporal commit
temporal commit
fix postgres 0.0.45 scripts
Merge pull request #63 from viavansi/userGroups_#19438
Close streams at templates migration.
List notifications by user, status and device (optional). [ refs #19519 ]
Reset workflow after stand by status.
Revert commented code at workflow status to continue stand by messages.
Merging branch userGroups_#19438.
Update BBDD version script. Review a info message and delete some commented
code. [ refs #19438 ]
New BBDD version (0.0.45) and migration roles to groups. [ refs #19438 ]
CRUD user groups. It requires bbdd changes and sql folder is not included. DO
NOT MERGE TO MASTER YET [ refs #19438 refs #19439 refs #19440 ]
Merge pull request #62 from viavansi/fix_sonar_2.2.14
log to LOG
Históricodecambiosyversiones
Página174
change all System.out.println
Modifiers should be declared in the correct order
remove tab spaces
remove throws runtime exception.
remove throws runtime exception.
remove throws CoreException
format all java code
preserve the original exception
remove activity events V6
delete comment code
private static final Logger
delete comment code
fix sonar errors
fix sonar errors
fix pmd errors
fix sonar errors
fix sonar errors
fix sonar errors
fix sonar errors
fix sonar errors
delete old code
delete code
Merge pull request #61 from viavansi/fix_error_2.2.14
fix errors in standby messages
update message in message services api
fix error in iterate expired messages
remove JS prefix in JSInfoSystemStatus.java
fix error in workflows in REJECTED status
Merge master into userGroups_#19438
New BBDD version (0.0.45) and migration roles to groups. [ refs #19438 ]
update version to 2.2.15
update chaneglog
Merge pull request #57 from viavansi/weblogic_version
fix error in template cache in weblogic
add metadataCipherPublicKey example 025
add changelog version 2.2.14
Merge branch 'master' into weblogic_version
Merge pull request #60 from viavansi/prepare_2.2.13
prepare 2.2.13 changelog and pom version
Históricodecambiosyversiones
Página175
Merge branch 'master' into userGroups_#19438
CRUD user groups. It requires bbdd changes and sql folder is not included. DO
NOT MERGE TO MASTER YET [ refs #19438 refs #19439 refs #19440 ]
Merge pull request #59 from viavansi/fix01_#20052
Solución al cacheo del form desde cambio de custodia a la BBDD en
ComputecFileRepositoryImpl
Solución problema al cacheo de form desde ComputecFileRepositoryImpl
Modified email message body reporting messages transfers
update to 0.0.44 Persistence.java
Merge pull request #58 from viavansi/fix01_#19815
Fix Oracle view for expired messages and notifications.
fix oracle update 0.0.43
Merge branch 'master' into weblogic_version
fix error in pagination search
fix error in message search in weblogic
Merge pull request #56 from viavansi/p12_#20052
fix error in ConfigurationService.java
update weblogic viavansi config
Close inputstream
Files p12 to BBDD
Change DateTime to Calendar (Weblogic error)
fix error in notification query
fix error in JSON app config parser
fix error in ConfigurationService.java
Merge branch 'master' into weblogic_version
Critical fix for template list
Update BBDD version.
Merge branch 'cloneDocument_#19460'
Manually merge [ refs #19460 ]
Update context for testservices
Update AdminMessageEditPage.java
Merge pull request #55 from viavansi/#20052
Close inputstreams
Ref #20052 Cambio de custodia de plantillas, formularios y logos a BBDD.
Merge branch 'master' of https://github.com/viavansi/mobile-services
Review setting type template and version message. [ refs #19460 ]
Change name workflow because of merging master. [ refs #19460 ]
Merge branch 'master' into cloneDocument_#19460
Create a document from another and from template list view. [ refs #19460 ]
Históricodecambiosyversiones
Página176
fix error in NotificationPersistenceService
create index in last update message
refs #2099 fix error in transactions in weblogic and refactor xxxPersistenceServices
refs #20159 create JUnit test and fix SSLPinningEnabled attribute mapper
Merge branch 'master' into weblogic_version
update version to 2.2.12
update version to 2.2.12
fix error in Api Exampples
fix error in rebase version
delete old src/main/resources/examples/templates/ info.json
refs #20098 fix error in example template install
refs #20098 fix error in example template install
refs #20098 fix error in example template install
refs #19395 add METADATA_CIPHER_PUBLIC_KEY in weblogic viavansi
config.properties
refs #19395 encrypt metadata evidences with public key
add examples form types 024_example
try fix weblogic resources
try fix weblogic resources
refs #20024 update weblogic viavansi config
refs #20024 change metadata save in BBDD
refs #20024 change log info
refs #20024 fix error in metadata update
refs #20024 add executeUpdateNamedQuery transaction
refs #20024 fix error in encoding example text
refs #20024 fix error in configuration services
prepare 2.2.11 weblogin version
set workflow code EX002 to default workflow and EX005 to generate pdf workflow
Up to 2.2.11
Update History.dm to v. 2.2.10
2.2.14 / 2015-02-20
fix error in template cache in weblogic
add metadataCipherPublicKey example 025
fix oracle update 0.0.43
fix error in pagination search
fix error in message search in weblogic
Históricodecambiosyversiones
Página177
fix error in ConfigurationService.java
update weblogic viavansi config
Change DateTime to Calendar (Weblogic error)
fix error in notification query
fix error in JSON app config parser
fix error in ConfigurationService.java
fix error in NotificationPersistenceService
create index in last update message
refs #2099 fix error in transactions in weblogic and refactor PersistenceServices
refs #20159 create JUnit test and fix SSLPinningEnabled attribute mapper
fix error in Api Exampples
delete old src/main/resources/examples/templates/ info.json
refs #20098 fix error in example template install
refs #19395 add METADATA_CIPHER_PUBLIC_KEY in weblogic viavansi
config.properties
refs #19395 encrypt metadata evidences with public key
add examples form types 024_example
refs #20024 update weblogic viavansi config
refs #20024 change metadata save in BBDD
refs #20024 change log info
refs #20024 fix error in metadata update
refs #20024 add executeUpdateNamedQuery transaction
refs #20024 fix error in encoding example text
refs #20024 fix error in configuration services
set workflow code EX002 to default workflow and EX005 to generate pdf workflow
2.2.13 / 2015-02-20
Merge pull request #59 from viavansi/fix01_#20052
Solución al cacheo del form desde cambio de custodia a la BBDD en
ComputecFileRepositoryImpl
Solución problema al cacheo de form desde ComputecFileRepositoryImpl
Modified email message body reporting messages transfers
update to 0.0.44 Persistence.java
Merge pull request #58 from viavansi/fix01_#19815
Fix Oracle view for expired messages and notifications.
Merge pull request #56 from viavansi/p12_#20052
Close inputstream
Históricodecambiosyversiones
Página178
Files p12 to BBDD
Critical fix for template list
Update BBDD version.
Merge branch 'cloneDocument_#19460'
Manually merge [ refs #19460 ]
Update context for testservices
Update AdminMessageEditPage.java
Merge pull request #55 from viavansi/#20052
Close inputstreams
Ref #20052 Cambio de custodia de plantillas, formularios y logos a BBDD.
Merge branch 'master' of https://github.com/viavansi/mobile-services
Review setting type template and version message. [ refs #19460 ]
Change name workflow because of merging master. [ refs #19460 ]
Merge branch 'master' into cloneDocument_#19460
Create a document from another and from template list view. [ refs #19460 ]
2.2.12 / 2015-02-12
Add last update message index
Merge pull request #52 from viavansi/fix_workflows_code_error
Set code EX002 to default workflow and EX005 to generate pdf workflow
Update workflow on standBy messages. [refs #19516]
Updated workflow EX_STAND_BY. [refs #19516]
2.2.11 / 2015-02-10
*Allowrejectmessageindicatingthereason
*TransferJobReport
*Fromnowarenotmandatorypushnotifications
*Addedserviceforautomaticcheckinstatussystem
*addtemplatecodeintemplatelist
*addtemplatetitleinform
*fixerrorintemplateupdate
*addtemplatetitleinsearch
*deletepicklistdevicesinusereditandtemplatepicklistisnowordered
*Updatehazelcast.xml
*Updatelogback.xml
*Fixminorerrors
Históricodecambiosyversiones
Página179
2.2.12 / 2015-02-12
Add last update message index
Merge pull request #52 from viavansi/fix_workflows_code_error
Set code EX002 to default workflow and EX005 to generate pdf workflow
Update workflow on standBy messages. [ refs #19516 ]
Updated workflow EX_STAND_BY. [ refs #19516 ]
2.2.11 / 2015-02-10
Update pom.xml
Merge pull request #51 from viavansi/fix_error_random_codes
Merge pull request #50 from viavansi/fix_error_reject_notification
fix error in generate random codes in policies and evidences
fix error in throw error code 232
Form to edit messages at STAND_BY status. [ refs #19457 ]
Merge last commit on master to standByMessages_#19457.
Merge manually master to standByMessages_#19457.
Add thread sample config to context for Tigo.
Fix error log instead of debug while saving the message. [ refs #19457 ]
Merge pull request #44 from viavansi/rejectMessage_#19537
Autocomplete to search user at message edition. [ refs #19457 ]
Update Constants.java
Merge pull request #46 from viavansi/#20081
Ref. #20081
Primera implementación
Merge pull request #47 from viavansi/#20171_error_ORA-19011
refs #20171 Error ORA-19011 in VD_MESSAGE_VIEW
Merge pull request #45 from viavansi/push_notifications
Mejora de código
Form to edit messages at STAND_BY status. [ refs #19457 ]
Solve comments [ refs #19537 ]
Edit a message at STAND_BY status [ refs #19457 ]
Ref. #20078
Reject message. [ refs #19537 ]
Update 04_services_insert.sql
Update 02_services_constraints.sql
Históricodecambiosyversiones
Página180
Update 01_services_tablas.sql
Update 01_services_tablas.sql
Merge pull request #43 from viavansi/fix_template_edit
Merge pull request #42 from viavansi/change_picklist
add template code in template list
add template title in form
fix error in template update
add template title in search
Merge pull request #41 from viavansi/#19960
Optimización de código
Añadido servicio para consulta del estado del sistema
Ref. #19960
delete picklist devices in user edit and template picklist is now ordered
Update hazelcast.xml
Update logback.xml
2.2.10 / 2015-01-29
add install certificate in cacert util test
Update context.xml
fix error in oauth (application)
refs #19983 prepare jmeter test more info in Readme.md
update version to 2.2.10
add exception in throw new ApiException(...
fix api_key param for swagger-codegen
put constants in uppercase
fix computec url in config example
2.2.9 / 2015-01-27
fix erros in oracle expired views
update tigo profiles
Revisión configuración hazelcast par TIGO PRE
Revisión de configuración para TIGO PRE
update logback Tigo profiles
Merge pull request #35 from viavansi/#19986_list_transferJob
create 0.0.39 BBDD full script
Históricodecambiosyversiones
Página181
Merge branch 'master' into #19986_list_transferJob
Merge pull request #34 from viavansi/#19863
Merge pull request #33 from viavansi/#19978_api_security_type
refs #19986 add transfer job list, update messageView and add messageCode in
TranferJob entity
fix error in postgre script
Referencia a http://redmine.viavansi.com/issues/19863
fix 0.0.37 and 0.0.39 oracle scripts
refs #19978 add API security type in application type in DDBB
return all devices by user in application type API
Merge pull request #32 from viavansi/#19977_workflow_only_create_pdf
refs #19977 fix pull request create constants
refs #19977 fix pull request add IOUtils.closeQuietly
refs #19977 fix pull request
refs #19977 workflow to just create a pdf document
fix error in template view callback mail example @jcabrera
Fix alter table script
Fix alter table
Merge branch 'master' of https://github.com/viavansi/mobile-services
fix error in oracle scripts 0.0.34
Up version app to 2.2.9
Merge pull request #31 from viavansi/#18196
Ref #18196 Nuevos campos "teléfono móvil" y "canal" para la entidad usuario.
2.2.8 / 2015-01-22
fix error in expired query in RESPONSED status
fix data base version in 0.0.36 scripts
fix error in date String search
create xml path converter
Move simple date format to a constant
add message auditory list in control pannel
add xml auditory path info in message view
delete unused log events code
add filter for not super admin user
new message view is now ready
refactor create method for get idSign in json message
remove temporal search page
Históricodecambiosyversiones
Página182
Create converter for date with seconds
sort filters in message search
Fix NPE when idDevice in database is null when checking notifications expired.
update dev.viafirma node 1 context
prepare data base scripts
fix errors in new message detail view
Merge pull request #27 from viavansi/#19901
new message detail view
refs #18224 prepare new message view detail
refs #18224 prepare 0.0.36 data base version and reorganize code
preparing message view
Recuperación de mensajes para auditar mediante la vista vd_message_auditory
http://redmine.viavansi.com/issues/19901
message view in progress
add new workflows EX002:only generate pdf and EX003:only register form data
remove old code
Cambios en la select para la caducidad de mensajes. Cambios en el método de
eliminación de notificaciones.
change system status test mail to [email protected]
fix error in send message from template add userCode in device info
refs #18224 message view with and filters ready
fix error in send message from template
refs #18224 update message view
Merge pull request #26 from viavansi/#19815
Delete TODO comment.
Timer schedule fix
Eliminación de objetos message en caché, así como su paso a xml y custodiado en
auditoría.
update signature code in message save
Merge pull request #25 from viavansi/prepare_version_2.2.8
fix errors in 0.0.34 data base version
Merge pull request #24 from viavansi/search_messages
Merge branch 'master' into search_messages
add default app for api rest
stored messages in database on each state change
delete user picklist in template edit
remove application table cache
working in MessageViewEntity
Merge branch 'master' into search_messages
Históricodecambiosyversiones
Página183
prepare for pagination in message view
remove user pick list in template edit
fix critical sonar errors
CloseQuietly
Clean streams
Merge branch 'refactor-sonar'
fix sonar errors
restore old message list
remove old code
fix sonar error: close ObjectInputStream
deleted TODO's comments
Merge branch 'test_fileUpload'
temporal working in list filter message view
changes in the message entity
Create generic class for extends in jersey rest services
update template list view
Create Text100Converte for xhtml list
remove unused tools tables
2.2.7 / 2015-01-14
change version to 2.2.7
refs #19797 add param callbackMailsFormKeys
2.2.6 / 2015-01-13
Merge branch '#19797_sent_callback_mail'
Merge pull request #17 from viavansi/ipsen
Removes references to StadisticsUtil
refs #19797 add callbackMails in auto create example messages
refs #19797 update viavansi dev profiles
refs #19797 update amgen profile
refs #19797 fix errors in template mail
Merge pull request #20 from viavansi/#18093
Solved issue http://redmine.viavansi.com/issues/18093. Add alphabetical order of
devices in templates view.
refs # 19797 update config.properties
Históricodecambiosyversiones
Página184
refs # 19797 upgrade to 2.2.6
refs #19797 add retrieveMessageByteArray method
refs #19797 add callbackMails
refs #19797 enable MailUtilImpl
refs #19797 refactor callback and add sent email if callbackMails present
fix sendgrip example @jgarrido
refs #19797 add sent mail example
Merge pull request #19 from viavansi/#19681
Solved last comment in request pull (https://github.com/viavansi/mobileservices/pull/19)
Fixed all reviews from drmillan at the last pull:
Merge pull request #18 from viavansi/#19681
Solución al problema de subida de los p12 para las notificaciones push de
aplicaciones.
Ipsen profile Template API
Fix null property
Merge pull request #16 from viavansi/test_fileUpload
fix error in 017_example
send image in base 64
Merge pull request #15 from viavansi/#19619_fix_application_config
2.2.5 / 2014-12-15
refs #19619 add URLDecoder and fix response error
Merge pull request #14 from viavansi/add_Examples
2.2.4 / 2014-12-09
update to 2.2.4
update list form rest service, now add title and discription info
add new examples for test movil app
Merge pull request #13 from viavansi/#19557_signedCode
refs #19557 add signedCode before generate the xml
Merge pull request #12 from viavansi/fixPreviewPdf
refs #19547 fix error in pdf preview with several signature
Fix incorrect application message
Fix oracle update
Históricodecambiosyversiones
Página185
Use computec-key as document object type id on computec transfers
Merge pull request #11 from viavansi/errorRole
refs #19419 fix error in edit ROLE
add workflow EX001 in examples with evidences
Merge pull request #10 from viavansi/prepare_examples
close InputStream
fix error when templateType is null
add title field in table vd_template
refs #19342 add examples of messages and templates
Merge pull request #9 from viavansi/document_generated
fix bugs comments in pull request
add message aplication.mobile.configuration.error
refs #19322 throw exception in prepare signature error
refs #19322 Allow use as a drafted document in url
Merge pull request #8 from viavansi/fix_pdfPreview
fixes bugs comments
Merge branch 'sendgrid' add 0.0.31 in sql
fix error in pdf preview second attempt
fix error in pdf preview
2.2.3 / 2014-11-19
Merge pull request #7 from viavansi/computec_info
add TransferJob info in infoSystemStatus
add trandferJob info in message view
fix error in Rol edit, add RoleAction class in persistence.xml
App configuration with json configuration
fix error in preview pdf in remove adobe AcroForm
Add json config
2.2.2 / 2014-11-14
upgrade data base to 0.0.30 on delete set null in id_message in vd_transfer_job
now completed state records of the table vd_transfer_job are stored
fix substring in TransferJobService
fix .gitignore hazelcast.xml in profiles
add tigo-dev profile
Históricodecambiosyversiones
Página186
fix ComputecFileRepositoryImpl.java
2.2.1 / 2014-11-12
fix error in multievidences workflow
update register device service
set response exception mapper to application/json
refs #18222 add response info in TranferJobEntity
fix oracle 0.29 scripts
update History.md
2.2.0 / 2014-11-10
update logback config en dev nodo 2
prepare JMeter test cluster
update dev.viafirma.com node 1 profile
Merge branch 'test_computec'
update info status page
refactor computec integration, add message refs
remove old code
refactor tasks and hazelcast config
Sonar cleaning
Merge branch 'storagemanager'
update to version 2.2.0
Merge branch '2.1.X'
fix error in registerUser in user rest services
add .metadata/ to .gitignore
fix error in evidences workflow
add compatibility with older mobile applications
restore login method in user rest service
Changes testservices hazelcast configuration to avoid port conflict
Change timer to ExecutorService
Added computec / transferJob
Sonar bugfixes
2.1.0 / 2014-10-07
Históricodecambiosyversiones
Página187
update viavansi dev profile
fix error in TestPreviewPdf.java
Merge branch 'fix-digitalized-preview'
configure logback in debug
add JUnit Digitalied Preview
Merge pull request #4 from viavansi/pickList
Set Amazon IP´s
Se eliminan los pickList
update viavansi dev profile
fix error in TestPreviewPdf.java
Merge branch 'fix-digitalized-preview'
configure logback in debug
add JUnit Digitalied Preview
Merge pull request #4 from viavansi/pickList
Set Amazon IP´s
Se eliminan los pickList
refs #17761 Change in way to store metadata
Merge branch '#17411'
refs #17719 fix error in reject message
refs #17719 fix error in notification status rejected
refs #16397 remove amgen and rovi in version info
refs #17719 fix error in notification status rejected
Merge branch '#17411'
refs #17677 fix error updating user
refs #17676 fix error in validation user form
Se inicia en caliente la conexión con ViafirmaManager
refs #17659 Signature response error
refs #17659 fix java.lang.NullPointerException
Mejora en la pantalla de aplicaciones
Se inicia en caliente la conexión con ViafirmaManager
Merge pull request #3 from viavansi/17154
Se actualiza el pom a la versión 2.1.0
Merge branch 'master' of github.com:viavansi/mobile-services into 17154
Se hace el update de metadatos
Optimizar tablas metadata y message
update History
Merge branch '#17411'
Merge branch 'master' of https://github.com/viavansi/mobile-services
Históricodecambiosyversiones
Página188
add bin/ to .gitignore
update viafirma-client to 2.10.4
Merge branch '17370'
ref #17370 Se elimina el autocomplete de los campos sensibles de usuario
Remove Hazlecast config file and create example one
Merge branch 'master' of https://github.com/viavansi/mobile-services
add config.properties-example
Merge pull request #2 from viavansi/17337
ref #17337 Se mejora el validador de Emails para permitir email vacios
update .gitignore
Merge pull request #1 from viavansi/17154
ref #17154 Se permite el borrado de mensajes con metadatas asociados
refs #15705 Corregir configuración del contexto en TEST
fix History.md
update Readme with History
add History.md
error in JAVA 6
change r${env.SVN_REVISION} to r${env.GIT_COMMIT}
add Readme in Tomcat7 folder
update .gitignore
delete unnecessary files
update .gitignore
2.0.1.1 / 2014-08-18
refs #17411 Error de seguridad Fijar sesión
2.0.1 / 2014-08-09
Delete Readme
refs #17051 Comento todos los test estan dando un problema en Sura se queda en
bucle infinito
fix #17337 Resuelto problema de seguridad ataques XSS
config para version 2.0.1
Comento el filter y cambio la politica de caducidad de token en el archivo
hazelcast.xml para dev y segdillo
Cambios para que funcione el plugin de maven
Históricodecambiosyversiones
Página189
refs #17334 Error peticiones POST no validan la firma del payload (Contenido de la
petición)
refs #17304 Error en la firma del contenido de la respuesta cuando caduca el token
refs #17304 Error en la firma del contenido de la respuesta cuando caduca el token
Initial commit GitHub
refs #17302 Controlar la traza del error cuando se produce un error interno de la
app
refs #17301 Cambiar el mensaje al estado de error cuando se produce un error a la
hora de añadir una evidencia
ref #17097, #17051 Se permite código de dispositivo duplicado (se filtra por tupla
code - userCode). La pantalla info Sistema está implementada hasta donde ha sido
posible.
Security Fix: CacheControl
Force Signature-Body header even if its empty.
fix #17110 Se corrigen las dependencias de slf4j
Faltaba una clase por subir
ref #17052 Se implementa mecanismo para guardar los metadatos de los
JSMessage como pares key - value en la tabla vd_metadata
ref #16966 cambio menor que quedaba por subir
ref #16935 No se cachea la información sensible en los navegadores
close #16966 La pantalla de administración de aplicaciones se ha modificado por
completo para hacerla más usable.
Error bypass weblogic
Error in tomcat
Error response signature
update #16989 Actualizada configuración de tigo pre
16989 Se actualiza el profile de tigopre a su última versión
Faltaba el fichero de textos
close #16834 Primera versión del importador de usuarios, se adjunta en la propia
petición una plantilla de ejemplo.
close #16615 Alternativa con Java6 para el mimeType.
weblogic config
Update #16612 se mejora el urlParamsFilter
Token oauth expired
Históricodecambiosyversiones
Página190
Actualizado #16368 para ejecutarse correctamente en Jenkins
Merge with oauth
Mejora en #16368 similar a la aplicada en manager para #16369, los test se han
estandarizado para cualquier despliegue.
close #16630 No se permiten añadir dispositivos manualmente
Cambio profile para usar viafirma de pro
close #16748 Se cambia texto digitalizedHelp en los JSON
close #16368 Tests JUnit de Postgres y Oracle
Updated POM and remove some illegal references for a JPA project from
persistence.xml
close #16488 Se oculta el password de Viafirma en la gestión de usuarios
Simplificación al método resuelto en 16689
close #16689 Se controlan los caracteres inválidos en el código de plantilla
comento UrlParamsFilter por problemas con oauth
close #16715 Se elimina la zona de mensajes de la gestión de usuarios
close #14329 Los usuarios ya se ordenan por Code en la gestión de plantillas
close #16612 Se impide robar la sessión
close #16616 Se controla la inserción de scripts en los formularios.
close #16615 Se controla la subida de .exe en la gestión de plantillas. Se hace por
mime type.
close #16613 Evitar que recuerde contraseñas, cuidado que en Firefox se comporta
diferente
Subo config.properties estándar.
close #15850 Faltaban 2 ficheros
close #15850 Se añade empaquetado básico mediante el assembly de maven
config presura testservices
refs #16270
refs #16269 Profile para Amgen
refs #16269 Profile para Amgen
closes #15742
profile pre para tigo
refs #16181 se corrigen los scripts para la instalación limpia en Oracle
Avoid saving password fields contents on browser - Avoid saving HTML content
refs #16105 Error en SDK Java cuando el message genera un error
refs #16105 Error en SDK Java cuando el message genera un error
refs #16093 Información duplicada en JSON de Message
configure dev node 1
refs #62225 permitir camel case en código de usuario
Históricodecambiosyversiones
Página191
1.0.8-RC1 / 2014-06-12
refs #14570 Nuevos atributos para la entidad usuario
refs #16031 Error de seguridad: acceso al servicio sin autenticar weblogic
refs #16031 Error de seguridad: acceso al servicio sin autenticar weblogic
refs #16031 Error de seguridad: acceso al servicio sin autenticar weblogic
refs #15587 Ejemplo de plan de pruebas para JMeter
closes #15939
Se aplican los cambios de custom.sql
add profile.finalName
closes #14570 Atributos Región y POS en la entidad de usuario
closes #14628
closes #14741 Validar que no exista un punto en el código de la plantilla
config in http
1.0.7-RC1 / 2014-05-28
closes #15270
fix error :80 in https
Fix error in FacesUtil weblogic
Delete duplicate @URLMapping in controller, produce error in https
filter for https and fix in idform
filter for https
fix error in workflows
profile para testservices
change error message
merge with weblogic12
closes #15270
fix error in signatures services
Test comentados
1.0.6 / 2014-05-13
fix error if policy.getEvidences() is null
Históricodecambiosyversiones
Página192
add menu in mobile style
Multi evidences
Update bean 404 in xsd
Multi evidences
refs #15128
1.0.5 /
update swagger version
cambio de hora del log
Generate default policy in settings
he dejado comentado los bloques donde tendríamos que construir el settings, que a
su vez contiene el policy, con sus formatos de firma y params, y el title y description
añado envio de callback, petición http
añador a todos los profiles la nueva cola en hazelcast
quitar palabra menu del header
Añadir callback para estado rejected
fix error al cambiar la contraseña desde la página del perfil del usuario
downloadSources a false
css para móvil
Permito que desde móvil se pueda navegar por la app
Cambio comentario de tipos de documentos en swagger a mayúsculas
scripts de creación en limpio del model-0.0.25. No hace falta hacer ningún alter
después de lanzar estos scripts.
Quito cifrado de clave en login
Better CSS responsive behaviour
1.0.4 /
remove force encoding from Template engine add -Dsun.jnu.encoding=ISO-885915 in tomcat arguments
change template encoding to windows-1258
change version xdocsreport
Históricodecambiosyversiones
Página193
1.0.3 / 2014-01-02
change version xdocreport to 1.0.3 and force encoding to UTF-8 in docx to pdf
converter
captura de errores al copiar por FTP
change querys for support oracle and postgresql
0.3.0 / 2013-09-27
fix error with encoding in templates
version 1.0.1 fix error search device in oracle and fix update scripts oracle
incluyo nueva descripcion de error durante instalacion relacionada con DB
actualizo configuracion para tigo pro para cuando se automaticen los despliegues
por profile
actualizacion de la documentacion de ayuda
refs #13867 permisos para eliminar plantillas
suprimo un create table y una secuencia que sobraban y rompia la ejecucion.
return forms order by description
incluyo los alters necesarios para el upgrade a la 0.24; inicialmente estos mismos
alters estaban en custom.sql
la tabla form ya no se usa; se elimina de este sql
remove ResourceServlet
fix version DDBB
fix
Migrate Page
Listado de tablas y export a excel
Paginador modificable. primera version Exportador XLS de Devices
se incluye ejemplo de instalacion de fonts en el servidor close #13713
refs #13918
correccion errata
actualización del contenido de ayuda Close #13742
Pruebas JMeter
Conf cache de JPA y mock de firma para workflow con codigo test12345
Parche para la 0.3.0.b3.r14262 en pretigo para que liste los form cuando la plantilla
no tiene idform
Históricodecambiosyversiones
Página194
actualización del contenido de ayuda Close #13742
actualizacion graficos
correccion erratas menores
Se actualiza ayuda del uso de FORMS: nuevos atributos disabled, match y
nestWith y nuevo tipo de item link. close #13734 close #13730 close #13714 close
#13715
Descarga de apps android
Multi app primer intento
Multi app primer intento
error version 2.3.20 de fremarker en repo jboss
Filtro de form y solución a la vista de mensajes y notificaciones
Históricodecambiosyversiones
Página195
Upgrades
En esta sección se describirán los procesos de actualización de versión del backend y
sus componentes.
Algunos recursos referenciados en los procesos podrían no estar disponibles en esta
documentación online, por lo que deberán ser solicitados al soporte técnico de viafirma.
Upgrades
Página196
Actualización 2.5.7 a 2.5.8
La revisión 2.5.8 NO requiere cambios en DB ni en configuración.
Actualización2.5.7a2.5.8
Página197
Actualización 2.4.0 a 2.5.7
La versión 2.5.7 requiere cambios en DB respecto a la 2.4.0, en concreto:
se crea nueva constraint para la tabla VD_TRANSFER_JOB
se modifica la tabla VD_TEMPLATE
se crea nueva vista VD_TEMPLATE_VIEW (se elimina previamente)
se eliminan las vistas VD_MESSAGE_EXPIRED_VIEW y
VD_NOTIFICATION_EXPIRED_VIEW
Los cambios a realizar se distribuyen en el fichero upgrade_0.0.55_to_0.0.56.sql,
cuyos pasos serían los siguientes:
1 - Constraint en VD_TRANSFER_JOB
La nueva constraint evita registros de mensajes duplicados para un mismo repositorio.
Para aplicarla, lanzaremos primero el ALTER:
ALTERTABLEvd_transfer_jobaddconstraintvd_transfer_job_unique_codeunique(message_code,rep
En caso de error, descomentaremos el select que comprueba si existen registros
repetidos:
--checkduplicatemessage_codeandrepository_configatvd_transfer_job
selectcount(*),n1.message_code,n1.repository_configfromvd_transfer_jobn1,vd_transfer_
wheren1.message_code=n2.message_codeandn1.repository_config=n2.repository_config
andn1.id_transfer_job<n2.id_transfer_job
groupbyn1.message_code,n1.repository_config;
Si encontramos registros duplicados, ejecutamos la siguiente sentencia para
eliminarlos:
DELETEFROMvd_transfer_jobwhereID_TRANSFER_JOBin
(selectn2.id_transfer_jobfromvd_transfer_jobn1,vd_transfer_jobn2
WHEREn1.message_code=n2.message_code
andn1.repository_config=n2.repository_config
Actualización2.4.0a2.5.7
Página198
ANDn1.id_transfer_job<n2.id_transfer_job);
Y a continuación, volveremos a ejecutar el ALTER:
ALTERTABLEvd_transfer_jobaddconstraintvd_transfer_job_unique_codeunique(message_code,rep
2 - Modificar VD_TEMPLATE
Se añade nueva columna para el número de versión de las plantillas.
ALTERTABLEVD_TEMPLATEADDVERSIONNUMBERDEFAULT1NOTNULL;
3 - Modificar VD_TEMPLATE_VIEW
Se elimina la vista y se crea de nuevo modificada.
dropviewVD_TEMPLATE_VIEW;
CREATEORREPLACEVIEWVD_TEMPLATE_VIEWAS(
selectTRUNC(DBMS_RANDOM.VALUE(0,100000000))asid,template_code,user_code,wm_concat(grou
(selecttemplate_code,user_code,nullgroup_codefromVD_TEMPLATE_USER_VIEW
unionall
selecttemplate_code,user_code,group_codefromVD_TEMPLATE_USER_GROUP_VIEW)t,VD_TEMPLATEtt
groupbytemplate_code,user_code,title,description,version
);
4 - Eliminar vistas
DROPVIEWvd_message_expired_view;
DROPVIEWvd_notification_expired_view;
5 - Actualizar versión
UPDATECONFIGURATIONSETVALUE='0.0.56'WHERENAME='APP_VERSION'andPROFILE='commons'
Actualización2.4.0a2.5.7
Página199
Actualización2.4.0a2.5.7
Página200
Actualización 2.3.3 a 2.4.0
La versión 2.4.0 requiere cambios en DB respecto a la 2.3.3, en concreto, se actualiza
la tabla VD_USER_APP.
El cambio a realizar se distribuye en el fichero upgrade_0.0.54_to_0.0.55.sql.
UPDATECONFIGURATIONSETVALUE='0.0.55'WHERENAME='APP_VERSION'andPROFILE='commons'
ALTERTABLEVD_USER_APPADDEXPIRED_DATEDATE;
ALTERTABLEVD_USER_APPADDEXPIRED_PERIODNUMBER;
ALTERTABLEVD_USER_APPADDLAST_LOGINDATE;
ALTERTABLEVD_USER_APPADDSTATUSVARCHAR2(25BYTE);
UPDATEVD_USER_APPSETstatus='ACTIVE'WHEREstatusisnull;
Actualización2.3.3a2.4.0
Página201
Actualización desde la versión 2.3.0 a la
versión 2.3.3
La versión 2.3.3 requiere cambios en DB, debiendo ejecutar los siguientes scripts:
○upgrade_0.0.51_to_0.0.52.sql
○upgrade_0.0.52_to_0.0.53.sql
○upgrade_0.0.53_to_0.0.54.sql
Actualización2.3.0a2.3.3
Página202
Actualización desde la versión 2.2.12 a la
versión 2.3.0
Ejecución de scripts de base de datos
Para este upgrade debe ejecutarse los siguientes scripts:
○upgrade_0.0.41_to_0.0.42.sql
○upgrade_0.0.42_to_0.0.43.sql
○upgrade_0.0.43_to_0.0.44.sql
○upgrade_0.0.44_to_0.0.45.sql
○upgrade_0.0.45_to_0.0.46.sql
○upgrade_0.0.46_to_0.0.47.sql
○upgrade_0.0.47_to_0.0.48.sql
○upgrade_0.0.48_to_0.0.49.sql
○upgrade_0.0.49_to_0.0.50.sql
○upgrade_0.0.50_to_0.0.51.sql
Migración de plantillas, certificados push y
roles de grupos:
Para el correcto funcionamiento de esta nueva versión es necesario migrar los ficheros
físicos alojados en el sistema de fichero que corresponde a plantillas y los p12 de
certificados a la base de datos, así como todos los roles a grupos y migración de
usuarios con los anteriores roles a los roles establecidos. Para ello accederemos la
página destinada para dicha función:
http://[servidor]:[puerto]/mobile-services/admin/migrate
A continuación pulsaremos uno a uno, y esperando que cada proceso termine, los
botones "Migrar". Para cada uno de ellos se notificará del estado en su conclusión en la
misma página.
Configuración asociada
En esta nueva versión hay que añadir un nuevo parámetro al contexto de la aplicación;
éste servirá para establecer el tiempo (en minutos) máximo de vida del token sin que el
Actualización2.2.12a2.3.0
Página203
usuario haga acción alguno sobre la aplicación. Una vez que se cumpla dicho tiempo la
aplicación requerirá al usuario sus credenciales para poder acceder. Esta nueva
funcionalidad únicamente estará disponible para aplicaciones que contenga en su
configuración el valor del parámetro autoLogout a true.
<!--Caducidaddetokens-->
<Environmentdescription="Expiretokenstimeinminutes"
name="OAUTH_EXPIRE_TOKEN_MINUTES"override="false"
type="java.lang.String"value="30"/>
Con la nueva funcionalidad de custodia de plantillas y p12 en base de datos, ya no se
persisten en disco los recursos mencionados, por lo que la siguiente configuración
quedará deprecated, por lo que se eliminarán del fichero de configuración.
name="fileSystem.application.PATH_BASE" = deprecated
name="fileSystem.application.VERSIONAR" = deprecated
name="fileSystem.template.PATH_BASE" = deprecated
name="fileSystem.template.VERSIONAR" = deprecated
En resumen, el uso de disco se optimiza con esta mejora.
Importación Masiva de Usuarios
Desde la v2.3 se mejora la importación de usuarios a partir de plantillas excel.
import_user_00_newscreen.png
import_user_01_errors.png
Esta importación permitirá:
Asignar uno o varios grupos.
Asignar un rol (rol asociado a niveles de seguridad según nueva versión v2.3).
Si no se informan credenciales para viafirma platform/manager, éstas se crean
automáticamente.
Resumen tras la importación con el número de importados y con el número de no
importados debido a errores, incluyendo el detalle de los registros enumerados.
Actualización2.2.12a2.3.0
Página204
Actualización desde la versión 2.2.11 a la
versión 2.2.12
Actualizar DB
Ejecutar los siguientes scripts de base de datos:
upgrade_0.0.41_to_0.0.42.sql
upgrade_0.0.42_to_0.0.43.sql
Migración de ficheros de plantillas y certificados de
notificaciones (p12) a base de datos:
Posteriormente entrar en la aplicación y ejecutar el proceso en las siguientes páginas:
Certificados Push: http://[servidor]/mobile-services/admin/aplication/migrate
Plantillas: http://[servidor]/mobile-services/admin/template/migrate
Actualización2.2.11a2.2.12
Página205
Actualización desde la versión 2.2.10 a la
versión 2.2.11
Parámetros en contexto
Eliminar los siguientes parámetros:
fileSystem.template.PATH_BASE
fileSystem.template.VERSIONAR
fileSystem.application.PATH_BASE
fileSystem.application.VERSIONAR
A partir de la 2.2.11 estos params ya no son necesarios porque los recursos (templates
y applications resources) se guardan en badse de datos.
Añadir los siguientes parámetros explicados en el fichero properties.md:
SYSTEM_STATUS_ERROR_SUBJECT
SYSTEM_STATUS_ERROR_RECIPIENTS
SYSTEM_STATUS_ERROR_THREAD_TIMER_DELAY
SYSTEM_STATUS_ERROR_THREAD_TIMER_PERIOD
REPORT_TRANSFER_JOB_SUBJECT
REPORT_TRANSFER_JOB_RECIPIENTS
REPORT_TRANSFER_JOB_BODY
Ejemplo:
<Environmentdescription="Delaygeneralparaeliniciodeloshilos"
name="SYSTEM_STATUS_ERROR_THREAD_TIMER_DELAY"override="false"
type="java.lang.String"value="60000"/>
<Environmentdescription="Delaygeneralparaeliniciodeloshilos"
name="SYSTEM_STATUS_ERROR_THREAD_TIMER_PERIOD"override="false"
type="java.lang.String"value="300000"/>
<Environmentdescription="Asuntoparaelcorreodeenviodeerror"
name="SYSTEM_STATUS_ERROR_SUBJECT"override="false"type="java.lang.String"
value="[Urgente]ErrorMobileServices"/>
<Environmentdescription="Destinatariosparaelcorreodeenviodeerror"
name="SYSTEM_STATUS_ERROR_RECIPIENTS"override="false"type="java.lang.String"
value="[email protected],[email protected]"/>
Actualización2.2.10a2.2.11
Página206
<Environmentdescription="Asuntoparaelcorreodeenviodeerror"
name="REPORT_TRANSFER_JOB_SUBJECT"override="false"type="java.lang.String"
value="Informetransferenciascomputec[reportDate]"/>
<Environmentdescription="Destinatariosparaelcorreodeenviodeerror"
name="REPORT_TRANSFER_JOB_RECIPIENTS"override="false"type="java.lang.String"
value="[email protected],[email protected],[email protected]"/>
<Environmentdescription="Destinatariosparaelcorreodeenviodeerror"
name="REPORT_TRANSFER_JOB_BODY"override="false"type="java.lang.String"
value="InformedetransferenciasrealizadasaComputeceldía[reportDate].Esteinforme
Base de datos
Se debe lanzar los siguientes ficheros sql en el servidor de base de datos:
upgrade_0.0.39_to_0.0.40.sql
upgrade_0.0.40_to_0.0.41.sql
Actualización2.2.10a2.2.11
Página207
Actualización 2.0.1 a 2.5.7
1. Introducción
En esta sección se describe el procedimiento para hacer un uprade completo desde una
v2.0.1 hasta una v2.5.7.
Se contarán con recursos específicos para evitar el upgrade de versiones intermedias y
simplicar el proceso.
Para ello, se contará con:
SQL de actualización de la DB.
Reestructuración del filesystem.
Configuración:
Contexto de aplicación
Configuración de hazelcast
1.1 Actualización DB
La versión 2.0.1 usaba un modelo v0.0.27, y la última versión v2.5.7 usa el modelo
v0.0.56, por lo que se ha compilado en un único fichero SQL la actualización del modelo
de datos.
Descargar upgrade_0.0.27_to_0.0.56.zip
1.2 Reestructuración del filesystem
En las versiones v2.3 y superior se optimiza el uso de disco, migrando la mayoría de
recursos a base de datos y simplificando la estructura del filesystem a la hora de crear
las carpetas de instalacón.
Con ello, habrá que tener en cuenta que en la configuración para v2.5 desaparecen
algunas variables de contexto que hacían referencias paths físicos en disco.
Estos cambios se podrán contrastar con el contexto optimizado para v2.5 que se
entrega junto al resto de recursos para el upgrade:
ANEXO:actualización2.0a2.5
Página208
ver property sample
Descripción del fichero de configuración:
1.3 Configuración
La configuración de mobile-services sufre cambios en la nueva versión. Se prescinde de
algunas variables que ya no son utilizadas, o se agregan nuevas.
Como novedad, destacar que parte de la configuración que se persistía en el fichero de
configuración (mobile-services.xml) ahora se persiste en base de datos, facilitando su
gestión y permitiendo incluso cambios en caliente.
2. Prerrequisitos
Antes de comenzar con la migración hay que realizar una comprobación del encoding
utilizado a la hora de editar los JSONs asociados a los formularios.
En concreto, hay que confirmar que los JSON de formularios estén editados en UTF8, y
en caso de que no lo esté, hay que editarlos con este encoding y sustituir las actuales.
3. Nueva Configuración
3.1 Cambios en el contexto de mobile-services
3.1.1 Variables deprecated en v2.5.5
variable
descripción
fileSystem.template.PATH_BASE
ahora se persiste en DB
fileSystem.template.VERSIONAR
ahora se persiste en DB
fileSystem.drafted.PATH_BASE
ahora se persiste en DB
fileSystem.drafted.VERSIONAR
ahora se persiste en DB
fileSystem.application.PATH_BASE
ahora se persiste en DB
fileSystem.application.VERSIONAR
ahora se persiste en DB
3.1.2 Nuevas variables en v2.5.5
ANEXO:actualización2.0a2.5
Página209
Envío automático de correos:
variable
descripción
MAIL_HOST_NAME
config SMTP
MAIL_SMTP_USER
config SMTP
MAIL_SMTP_PASS
config SMTP
MAIL_FROM
config SMTP
Config para la call-back realizada desde el backend
variable
descripción
MAIL_CALLBACK_SUBJECT
asunto del correo
MAIL_CALLBACK_ATTACHMENT_XML
true o false para adjuntar el XML
MAIL_CALLBACK_ATTACHMENT_PDF
true o false para adjuntar el PDF
MAIL_CALLBACK_PRINT_FORM_PARAMS
true o false para mostrar datos
del formulario en el correo
MAIL_CALLBACK_PRINT_DISCLAIMER
disclaimer del correo
Esta configuración se usará para enviar los correos electrónicos en caso de haber
definido una callback del tipo "callBackMails" en la configuración del Message.
Message{
code(string,optional),
userCode(string,optional),
groupCode(string,optional),
appCode(string,optional),
version(string),
workflow(Workflow,optional),
notification(Notification,optional),
document(Document,optional),
metadataList(array[Param],optional),
policies(array[Policy],optional),
callbackURL(string,optional),
callbackMails(string,optional),
callbackMailsFormKeys(array[string],optional),
error(ErrorResponse,optional),
pid(string,optional),
server(string,optional),
processTimeExpired(Calendar,optional),
commentReject(string,optional)
}
ANEXO:actualización2.0a2.5
Página210
AUTO-CHECK: configuración hilos chequeo del sistema
variable
descripción
SYSTEM_STATUS_ERROR_THREAD_TIMER_DELAY
Delay general para
el inicio de los hilos
para el auto-check
del sistema
expresado en
milisegundos
SYSTEM_STATUS_ERROR_THREAD_TIMER_PERIOD
Temporizador
general para el
inicio de los hilos
para el auto-check
del sistema
expresado en
milisegundos
SYSTEM_STATUS_ERROR_SUBJECT
Asunto para el
correo de envio de
error
SYSTEM_STATUS_ERROR_THREAD_TIMER_PERIOD
Destinatarios para el
correo de envio de
error, separados por
coma
Seguridad
variable
descripción
OAUTH_EXPIRE_TOKEN_MINUTES
ciclo de vida del token intercambiado
con los dispositivos móviles, expresado
en minutos
OPCIONAL: utilidades
variable
CREATE_TEMPLATE_EXAMPLES
descripción
Instala automaticamente plantillas de
ejemplo para planes de prueba
3.2 Cambios en la configuración de hazelcast
Ejemplo de hazelcast para nueva versión 2.5: hazelcast.xml
A destacar:
3.2.1 ManCenter
ANEXO:actualización2.0a2.5
Página211
La versión de hazelcast incluida en el backend 2.5 permite la monitorización de la caché
desde un panel de control facilitado por Hazelcast.
Su instalación es opcional, y en caso de hacerlo, en la configuración de nuestro
hazelcast sólo habrá que especificar el host en el que se ha instalado:
Por ejemplo:
<management-centerenabled="true">http://192.168.10.160:9081/mancenter</management-center
ANEXO:actualización2.0a2.5
Página212
3.2.2 Mapas
A nivel de configuración se crean tres mapas:
<mapname="MESSAGES_TEMPORAL_DOCUMENT_MAP"/>
<mapname="DOWNLOAD_MAP"/>
y por código (java) se crea un mapa adicional:
MAP_MESSAGES_IN_PROGRESS
Ya no se usan los siguientes mapas:
<mapname="MESSAGES_REAL_TIME"/>
<mapname="NOTIFICATION_REAL_TIME"/>
<mapname="MESSAGES_MAP"/>
3.2.3 Queues
Ahora las colas NO se definen en el fichero de configuración de hazelcast, se definen
programáticamente.
Por tanto, desaparecen de la configuración de hazelcast todas las colas:
<queuename="QUEUE_MESSAGES_DISPATCHED"/>
<queuename="QUEUE_MESSAGES_RECEIVED"/>
<queuename="QUEUE_MESSAGES_COMMITTED"/>
<queuename="QUEUE_MESSAGES_DRAFTED"/>
<queuename="QUEUE_MESSAGES_SIGNED"/>
<queuename="QUEUE_MESSAGES_SAVED"/>
<queuename="QUEUE_MESSAGES_RESPONSED"/>
<queuename="QUEUE_MESSAGES_ERROR"/>
<queuename="QUEUE_MESSAGES_MOCK_MOBILE"/>
4. Upgrade paso a paso
4.1. Parada y Backup
ANEXO:actualización2.0a2.5
Página213
Antes de iniciar el proceso de migración se debe contar con la confirmación por
parte de los DBA´s de Oracle que han realizado una copia de seguridad del
esquema.
Se debe contar con copia de seguridad del directorio de despliegue (tomcat,
weblogic), así como de los ficheros de configuración: mobile-services.xml y
hazelcast.xml
El proceso de migración debe comenzar con el servidor de aplicaciones parado
(tomcat, weblogic).
4.2. Base de Datos
El fichero upgrade_0.0.27_to_0.0.56.zip contiene la secuencia de los tres scripts SQL
que se encargarán de hacer el upgrade:
1_upgrade_0.0.27_to_0.0.51.sql
2_upgrade_0.0.51_to_0.0.52.sql
3_upgrade_0.0.52_to_0.0.56.sql
nota oracle: en el nuevo modelo de usan vistas y bloques PL/SQL, por lo que se
requiere que el usuario propietario del esquema tenga los permisos adecuados.
nota scripts SQL: el segundo fichero se debe revisar con detalle durante su ejecución,
puese contiene instrucciones y toma de decisión que requieren intervención manual.
4.3. Despliegue y puesta en marcha
A partir de la nueva versión distribuida y de los nuevos ficheros de configuración,
proceder con el despliegue en el serviddor de aplicaciones (tomcat, weblogic).
Comprobar en el log de arranque que no ha habido ningún problema.
4.4. Proceso de Migración de Recursos
Procedemos a realizar la migración de los p12, plantillas y roles
http://[host]/mobile-services/admin/migrate
En esta pantalla encontraremos varias secciones:
4.4.1 Migración de Certificados (push)
ANEXO:actualización2.0a2.5
Página214
El proceso recuperará los .p12 que encuentre en la configuración del sistema,
persistidos éstos en filesystem, y los importará en base de datos.
A partir de este momento, ya no será necesario informar en el contexto de la aplicación
ningún path de filesystem en la que persistir los recursos de las apps móviles iOS.
4.4.2 Migración de Plantillas
Este proceso migrará todas las plantillas, junto con su formulario (JSON) y logotipo,
desde el sistema de fichero actual a la base de datos.
Es importante que el formulario (JSON) haya sido editado en formato UTF8, tal y como
se explica en el capítulo 2 "Prerequisitos".
4.4.3 Migración de roles a grupos
Este proceso migrará todos los roles a grupos (con relación 1-1).
Se creará un grupo por cada rol encontrado, manteniendo la misma configuración.
A los grupos creados se les asociarán los usuarios encontrados a partir del rol al que
pertenecían.
A partir de este momento, la entidad "Rol" sólo será utilizada para propósitos de
restricción de permisos sobre el backend, y ya no se podrán editar.
Los grupos serán las entidades lógicas para definir las asociaciones de plantillas y
usuarios.
4.4.4 Migración de Usuarios y Roles
En este proceso se podrá establecer el nuevo rol de los usuarios, teniendo en cuenta el
rol que tenían antes de la migración.
4.5. Actualización de Roles y Plantillas
Una vez importadas las plantillas debemos lanzar un script SQL que harán ajustará el
título de plantillas, disponible en versiones superiores a la 2.0.1, y que por defecto, se
insertará igual a la descripción.
ANEXO:actualización2.0a2.5
Página215
4_template_titles.sql (incluido en el upgrade_0.0.27_to_0.0.56.zip)
ANEXO:actualización2.0a2.5
Página216