Categoría: Contratación

Introducción

El sistema de notificaciones permite enviar un mensaje al empleado de la aplicación BOLD para informarle de algún evento significativo que se ha producido. Por ejemplo, cuando un gestor inserta a un empleado una incidencia se avisaría con un mensaje. El mensaje puede llegar de tres formas: un mensaje simple a la aplicación web, una notificación push en la aplicación móvil o un mensaje por correo electrónico.

Cómo configurar las notificaciones

Se hace en el fichero WPServerCfg.ini. Con la variable NotificationMode en la entrada General. Esta variable puede tomar tres valores: el valor 0 desactiva el sistema de notificaciones, el valor 1 lo activa en modo prueba y el valor 2 lo activa en modo producción.

Por defecto el valor es 1, modo prueba. En este modo el sistema de notificaciones está en marcha pero no le envía ningún mensaje al empleado final. Sirve para comprobar que las notificaciones se generan correctamente pero para hacer pruebas. Sin molestar al empleado.

Configuración de las notificaciones desde el punto de vista del empleado

El empleado que recibe las notificaciones puede configurar dos cosas: el idioma en que quiere que le lleguen los mensajes y si quiere que le lleguen por correo electrónico. Hay que comentar que siempre le llegarán como mensaje simple a la aplicación web. En la aplicación móvil puede desactivar los mensajes quitando las notificaciones push a nivel de aplicación.

Configuración de las notificaciones desde el punto de vista del gestor

En primer lugar para que un usuario gestor genere notificaciones es necesario que tenga activado el check en su ficha de usuario:

Para configurar las notificaciones lo puede hacer desde el Gestor de notificaciones que aparece accediendo al menú CONFIGURACIÓN -> Configuración general:

Al apretar el botón Configurar notificaciones aparecerá una ventana como esta:

En esta ventana se ve un listado de las 19 posibles notificaciones que se pueden enviar de momento a los empleados. En la parte de abajo de la ventana aparece el botón Editar notificación que nos permite configurar una a una las características de cada notificación. Seleccionamos una y apretamos el botón. Aparecerá el siguiente cuadro de diálogo:

En el ejemplo, debajo del nombre de la notificación, aparece Título, Idioma y Mensaje:

• Título es el texto que aparecerá en la cabecera del mensaje.
• Idioma es el idioma en el que están Título y Mensaje.
• Mensaje es el cuerpo del mensaje. Como se puede ver Mensaje es una plantilla en la que se pueden personalizar campos que después serán sustituidos al generar el texto definitivo. Esto lo veremos más adelante.

A continuación aparece el bloque de idioma alternativo donde podemos configurar Título, Idioma y Mensaje alternativos.

Más adelante tenemos Ventana de aplicación de la notificación. Esta ventana decide si la notificación se envía o no en función de la fecha en la que se genera la notificación. Todas las notificaciones tiene asociadas una fecha. Si esta fecha entra dentro de esta ventana la notificación se envía. Por ejemplo, supongamos que en Días previos tenemos 10 días y en Días posteriores tenemos 30 días. Ahora insertamos una incidencia dentro de 15 días. Como 15 días es inferior a 30 días y por lo tanto está dentro de la ventana la notificación de inserción de incidencia se enviará.

Luego tenemos otras características de las notificaciones:

• Enviar push: indica si se envia una notificación push al móvil.
• Enviar mail: indica si se envia un mail.

El mensaje simple a la web se envía siempre. Esto no se puede desactivar. Por lo tanto vemos los tres tipos de noticiación que se pueden enviar: mensaje simple, siempre, notificación push al móvil, desactivable, y mensaje a correo electrónico, desactivable.

Visor de notificaciones de cada empleado por parte del gestor

El usuario gestor tiene la posibilidad de ver, buscar y filtrar los diferentes tipos de notificaciones que le van llegando a los empleados. Para ver este visor hay que ir a la ficha del empleado y seleccionar la pestaña Notificaciones:

Como se puede ver se puede buscar las notificaciones por texto y filtrar según los tipos. Se mantienen sólo las notificaciones enviadas durante los últimos 60 días.

Campos personalizables dentro de la plantilla del Mensaje

No todos los posibles campos tienen sentido en todas las notificaciones. Por ejemplo, el campo %Notification.End.Incidence.Description% tiene sentido cuando se genera una notificación asociada a la inserción de una incidencia. Pero no tendría sentido en una cobertura. Los posibles campos son:

•     %Notification.Worker.Name%
•     %Notification.Worker.FullName%
•     %Notification.Worker.Description%
•     %Notification.Alt.Worker.Name%
•     %Notification.Alt.Worker.FullName%
•     %Notification.Alt.Worker.Description%
•     %Notification.ContractWorker.Name%
•     %Notification.ContractWorker.Description%
•     %Notification.Alt.ContractWorker.Name%
•     %Notification.Alt.ContractWorker.Description%
•     %Notification.BOLDForm.Name%
•     %Notification.Ini.Need.Name%
•     %Notification.Ini.Need.Description%
•     %Notification.End.Need.Name%
•     %Notification.End.Need.Description%
•     %Notification.Ini.Schedule.Name%
•     %Notification.Ini.Schedule.Description%
•     %Notification.End.Schedule.Name%
•     %Notification.End.Schedule.Description%
•     %Notification.Ini.SequenceSchedule.Name%
•     %Notification.Ini.SequenceSchedule.Description%
•     %Notification.End.SequenceSchedule.Name%
•     %Notification.End.SequenceSchedule.Description%
•     %Notification.Ini.Incidence.Name%
•     %Notification.Ini.Incidence.Description%
•     %Notification.End.Incidence.Name%  
•     %Notification.End.Incidence.Description%  
•     %Notification.Case.ID%  
•     %Notification.Ini.Case.Version%  
•     %Notification.End.Case.Version%  
•     %Notification.Date%  
•     %Notification.Worker.ID%  
•     %Notification.Alt.Worker.ID%  
•     %Notification.ContractWorker.ID%  
•     %Notification.Alt.ContractWorker.ID%  
•     %Notification.BOLDForm.ID%  
•     %Notification.Ini.Need.ID%  
•     %Notification.End.Need.ID%  
•     %Notification.Ini.Schedule.ID%  
•     %Notification.End.Schedule.ID%  
•     %Notification.Ini.SequenceSchedule.ID%  
•     %Notification.End.SequenceSchedule.ID%  
•     %Notification.Ini.Incidence.ID%  
•     %Notification.End.Incidence.ID%  
•     %Notification.Ini.Dates%  
•     %Notification.End.Dates%  
•     %Notification.Dates%  

Aparte de todos estos también se pueden utilizar expresiones dinámicas asociadas a los objetos que generar la notificación. Por ejemplo, el texto del Permiso aceptado es el siguiente:

El permiso del día %Notification.Date% con ID %Notification.BOLDForm.ID% y incidencia %CustomProps.M32DatosPermiso.IncidenceJustifiedID.Name% ha sido aceptado. Revise la aplicación para tener más detalles.

El campo %CustomProps.M32DatosPermiso.IncidenceJustifiedID.Name% es propio del formulario que se crea y que produce la notificación.

Los anticipos son un tipo más de formulario que permite indicar una cantidad económica que el empleado quiere que se le adelante. El flujo de aprobación y denegación es algo diferente del típico de todos los formularios ya que solo es necesario que lo apruebe o deniegue RR.HH.. Para que aparezca la pestaña de anticipos en el menú solo tiene que existir la Feature PaymentForms en el fichero BOLDWebCfg.xml.

Este es el aspecto que tiene el formulario en el portal:

• Instalar Chrome, Notepad++ y 7z.
• Ejecutar installIIS.cmd en un PowerShell. Este script añade todas las features necesarias del IIS.
• Para SQL instalar: VC_redist.x64.exe, msodbcsql_17.4.2.1_x64.msi y MsSqlCmdLnUtils.msi.
• Para los pools de aplicación web instalar: rewrite_x64_es-ES.msi, node-v20.15.1-x64.msi y iisnode-full-v0.2.16-x64.msi.
• Crear la carpeta C:\Program Files (x86)\Global Planning Solutions\data y copiar el fichero data.properties. Se puede obtener del FRE-01, por ejemplo.
• Crear la carpeta C:\Program Files (x86)\Global Planning Solutions\binaries y descomprimir el último node_modules.7z. Se puede obtener del FTP de la última release de la aplicación web.
• Añadir a las variables de entorno de sistema NODE_PATH con el valor C:\Program Files (x86)\Global Planning Solutions\binaries\node_modules.
• Reiniciar la máquina.
• Crear el pool gpsnode_adm apuntando a //core-pro-fs-01/cfg/Install/gpsnode_adm. El usuario es el de dominio wke\gpsadmin.
• Añadir la máquina a la lista de la BD CaseAdminData: INSERT INTO WPMACHINES_TB (ISMASTER, HOSTNAME, IP, FQDN) VALUES (0,’a3gt-pro-bck-01′,’a3gt-pro-bck-01.wke.pro’,’a3gt-pro-bck-01.wke.pro’)
• Reiniciar el pool gpsnode_adm.
• Parar el pool gpsnode_clockings en el FRE-01.
• Añadir en BCK-01 el pool gpsnode_clockings apuntando a //core-pro-fs-01/cfg/Install/production/gpsnode_clockings. El usuario es el de dominio wke\gpsadmin.
• Reiniciar el pool gpsnode_clockings.
• Eliminar en FRE-01 el pool gpsnode_clockings.
• En el proxy en el fichero /etc/nginx/sites-availables/default añadir upstream bck1 { server 172.16.0.11; keepalive 64; }
• En el proxy en el fichero /etc/nginx/sites-availables/common/locationsGeneric.conf cambiar fe1 por bck1:

location /gpsnode_clockings {
    error_log /etc/nginx/logs/error_gpsnode_clockings.log warn;
    client_max_body_size 100m;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $http_host;
    proxy_pass http://bck1/gpsnode_clockings;
}

• Comprobar que todo es correcto con sudo nginx -t.
• Recargar el nginx con sudo systemctl reload nginx.service.
• Ir a la URL: https://a3gt.wolterskluwer.es/gpsnode_clockings.

El acceso con MFA se debe activar a nivel general en la aplicación web en la pantalla de Configuración General.

El acceso con MFA en la aplicación web funciona de dos maneras. Esto se configura en gpsnode.js con la variable de entorno MFA_BY_USER.

Si MFA_BY_USER vale ‘0’ significa que accederán con MFA sólo los usuarios de tipo no empleado. Es decir, los usuarios administradores, planificadores, etc. Este el modo en que lo tienen configurado en WKE.

Si MFA_BY_USER vale ‘1’ significa que podrán acceder con MFA todos los usuarios, independientemente del tipo, con la condición de que el empleado asociado al usuario tenga activa la opción Acceso MFA en sus propiedades. Cada empleado se puede activar esta opción desde el diálogo de cambio de contraseña.

Para configurar el servidor de MFA son necesarias tres variables de entorno en gpsnode.js.

API_AUTHORIZATION_MFA_BEARER es la autorización de acceso al servidor de MFA.

CREATE_MFA_PROMPT_URL es la URL que muestra el diálogo de envío del código de acceso MFA.

VALIDATE_MFA_COMPLETION_URL es la URL que valida que el código de acceso MFA es correcto y da acceso a la aplicación.

En la configuración de WKE el servidor de MFA es ajeno e independiente de nuestra aplicación web. Pero GPS tiene la posibilidad de ofrecer también este servicio configurando adecuadamente las tres variables de entorno anteriores.

En un entorno Cloud, cuando es GPS el que ofrece el servidor de MFA, se debe recordar que las URL proporcionadas en CREATE_MFA_PROMPT_URL y VALIDATE_MFA_COMPLETION_URL requieren mantener el estado en la memoria. Esto implica que el reverse proxy de acceso a la aplicación web debe redirigir siempre estas dos URL al mismo frontal que además debe estar configurado como monoproceso.

Las siguientes pruebas nos servirán para hacer una previa verificación del funcionamiento correcto de las Push Notifications.

Validación de configuración del servidor

• Hay que ubicarnos donde querramos hacer las pruebas, sea en local, dev, etc (si es local debemos asociar nuestro localhost a ngrok por ejemplo y así poder hacer pruebas).
• Una vez dentro, nos dirigimos al archivo de configuración de servidor, que normalmente se encuentra en la siguiente ruta.
  \Clients\Custom_Files\Integration\configuration\production\boldserver\WPServerConfig.ini
• Una vez dentro comprobamos que las URLs de FullWeb apuntan al servidor.

LOCAL:

DEV:

Validación de funcionamiento Firebase a App

• Acceder al messaging de la cuenta firebase haciendo login con la cuenta de soportegpsplan (https://console.firebase.google.com/project/boldapp-prueba2/messaging?hl=es)
• Hacemos click en Experimento nuevo -> Notificaciones.
• Ahora rellenamos los datos siendo conscientes de que depende lo que configuremos, podría llegarle a todos los usuarios que estén usando la versión que indiquemos
  (En este ejemplo usamos la versión TestFlight de IOS para tener una prueba encapsulada).

• En la opción de Variables, bastaría con darle a siguiente.
• En Objetivo elegimos el que queremos analizar, pero si no tenemos ninguno en concreto elegimos la opción «Usuarios que no experimentan fallas».
• Por último programamos nuestra prueba.

Validación desde Apple cloudKit

• Nos conectamos a anyDesk y abrimos un navegador (de preferencia Safari, ya que recuerda las credenciales)
• Nos dirigimos a la herramienta apple para enviar push notifications (https://icloud.developer.apple.com/dashboard/notifications/teams/VK6PRMTH9)
• Elegimos en qué app haremos la prueba, por ejemplo com.gps-plan.BOLD-APP y clickamos la opción send.
• Nombramos el título con algo que nos ayude a identificar la prueba fácilmente.
• Si estamos en local nos será fácil encontrar nuestro deviceToken, sólo bastará con ejecutar la app en xCode y este al iniciar la app nos lo mostrará:

El formulario se vería algo así:

• También podemos modificar el payload:

• Por último enviamos con el botón ubicado en la parte superior derecha:

• La respuesta sería lo siguiente:

Para activar esto hay que hacer lo siguiente:

1. Instalar la última versión del cliente Windows.
2. Copiar la última dll LZ4_32.dll en Prebuild.
3. Añadir en el WPServerCfg.ini en General: DisableLZ4=0.

Atención: La ejecución de lo explicado en este artículo puede generar efectos catastróficos en el servidor LDAP si no se sabe exactamente qué se está haciendo. Ve con sumo cuidado.

$csvPath = "ldap_import.csv"

$csvData = Import-Csv $csvPath

foreach ($entry in $csvData) {
    Set-ADUser -Identity $entry.sAMAccountName -Replace @{employeeID=$entry.DNI;employeeNumber=$entry.Matricula}
    Write-Host $entry.sAMAccountName " " $entry.DNI "  " $entry.Matricula
}

powershell -executionpolicy bypass -File .\ImportCSVData.ps1

Por motivos de seguridad, es necesario modificar las páginas de inicio por defecto de IIS y Tomcat, aplicando redirecciones hacia nuestras aplicaciones.

A continuación, se explica paso a paso el proceso

Aplicando una redirección en el IIS (página de inicio por defecto: gpsnode)

Lo primero que necesitarás saber es en qué ruta está instalado el gpsnode. En entornos de productivo, suele ser en /gpsnode mientras que en entornos de desarrollo, suele ser /gpsnode_dev. Una vez lo tengas claro, sólo debes hacer lo siguiente:

En el IIS, clica sobre el cliente y luego sobre «Redirección HTTP«

Se te abrirá un nuevo panel, en el que deberás activar todos los checkbox y poner la ruta de la instalación de gpsnode, en este ejemplo, pondremos /gpsnode

Si todo ha ido bien, al colocar en el navegador localhost, el nombre de la máquina o la URL base configurada con certificado, ya no debería salirte la página por defecto del IIS, sino la de gpsnode.

Aplicando una redirección en Tomcat (página de inicio por defecto: portal)

Para Tomcat, se recomienda utilizar el método sugerido en la guía de instalación del mismo, sin embargo, es posible que se quiera aplicar una redirección en lugar de simplemente mostrar error.