¿Qué son las notificaciones centralizadas?
  • 09 Feb 2024
  • 11 Minutos para leer

¿Qué son las notificaciones centralizadas?


Article Summary

Desarrollo de notificaciones centralizadas

En Totara 14 presentamos un nuevo sistema para generar notificaciones. Cambiamos la forma en que los desarrolladores escriben la funcionalidad de notificaciones en funciones y cómo los usuarios configuran e interactúan con las notificaciones. En nuestra documentación nos referimos a esta característica como “notificaciones centralizadas”. Históricamente, los desarrolladores debían tomar muchas decisiones sobre cómo funcionarían las notificaciones, lo que dio como resultado una experiencia inconsistente para los usuarios cuando se trataba de configurar e interactuar con las notificaciones. El sistema de notificaciones centralizadas proporciona una forma consistente para que los desarrolladores implementen notificaciones y para que los usuarios las utilicen.

El lanzamiento inicial de notificaciones centralizadas incluyó la migración de notificaciones de programa y certificación al nuevo sistema. En las versiones posteriores, se han agregado más notificaciones de funciones a las notificaciones centralizadas, mientras que otras aún se administran fuera del sistema de notificaciones centralizadas y ahora se denominan “notificaciones heredadas”. A medida que Totara avance, seguiremos migrando las notificaciones existentes y agregando nuevas notificaciones al sistema de notificaciones centralizado. Por ejemplo, Totara 16 vio la introducción de notificaciones de cursos, que se administran a través de notificaciones centralizadas.

Notificaciones centralizadas explicadas

'Notificaciones centralizadas' es el término utilizado para el nuevo sistema de notificaciones. Los desarrolladores agregan funcionalidad a las características, lo que permite a los usuarios configurar las notificaciones que se enviarán en relación con los eventos que ocurren. Hay dos tipos diferentes de eventos para los que puedes configurar notificaciones:

  • Los eventos pueden ser acciones que realiza un usuario, como cuando un usuario completa un curso
  • Los eventos pueden representarse por fechas registradas en la base de datos, como la fecha límite del programa

Los desarrolladores deben implementar un activador de notificación para cada tipo de evento que necesite dar lugar a una notificación. Por ejemplo, un desarrollador puede implementar un activador de notificación basado en la fecha límite del curso. Los usuarios pueden configurar cualquier número de notificaciones para cada activador de notificación. Por ejemplo, un administrador del curso podría crear una notificación de 'Vencimiento en siete días', así como una notificación de 'Dos días vencidos', ambas basadas en el mismo activador de notificación.

Cuando ocurre un evento, el sistema de notificación centralizado verifica si alguna notificación está configurada para ser enviada. Existen varios pasos para decidir qué notificaciones se enviarán, quién las recibirá, cuál será el contenido y cómo se entregarán.


Beneficios de las notificaciones centralizadas

El sistema centralizado de notificaciones proporciona una forma estándar para que los desarrolladores y usuarios finales interactúen con las notificaciones. Aquí hemos descrito varios de los beneficios clave de usar notificaciones centralizadas:

  • Las notificaciones para una variedad de características diferentes comparten una interfaz común. En el pasado, diferentes características proporcionaban diferentes interfaces para configurar notificaciones, con diferentes funcionalidades y configuraciones.
  • Las notificaciones se pueden reutilizar en más de una instancia (p. ej., la misma notificación en más de un curso). En el pasado, diferentes características implementaban diferentes formas de compartir entre instancias, como el uso de plantillas.
  • Los usuarios tienen una única forma de configurar todas sus preferencias de notificación en el sistema de notificaciones centralizado. En el pasado, algunas notificaciones podían configurarse en las preferencias del usuario, mientras que otras estaban codificadas para ser entregadas por correo electrónico o tenían algún otro medio de configuración.
  • El comportamiento de cómo se envían las notificaciones es coherente. En el pasado, se utilizaban diferentes sistemas para determinar qué notificaciones se enviaron y cuándo. Hubo varias formas de tratar con las notificaciones que deberían haber sido enviadas en el pasado, como cuando se creó una nueva notificación para ser enviada cuando ocurrió un evento, cuando ese evento ya había ocurrido para algunos usuarios.
  • Al configurar notificaciones, los usuarios tienen una forma consistente de seleccionar a quién se enviará cada notificación. En el pasado, si era necesario enviar una notificación al administrador de un usuario, un desarrollador debía implementar el código para que eso sucediera, y elementos de interfaz personalizados para permitir a los usuarios controlar cuándo se utilizaría.
  • Un sistema de programación compartido, que permite programar casi cualquier notificación, con el mínimo trabajo requerido por el desarrollador. En el pasado, los desarrolladores tenían que implementar soluciones personalizadas para añadir programación, incluida la interfaz que permitía a los usuarios configurar las programaciones.
  • Un sistema unificado de marcadores de posición , que permite la reutilización de marcadores de posición entre diferentes activadores de notificación y una sintaxis común para que los usuarios utilicen marcadores de posición en su contenido de notificación. En el pasado, los desarrolladores tenían que implementar una solución personalizada en cada característica en la que se requerían marcadores de posición, y los usuarios tenían que aprender la sintaxis de marcadores de posición correcta para esa característica específica.
  • Implementación consistente de funcionalidad en varios idiomas. En el pasado, los desarrolladores tenían que implementar el uso de la funcionalidad multilingüe en cada característica utilizando notificaciones.
  • Una nueva fuente única para auditar todas las notificaciones y todos los tipos de salida. En el pasado, los usuarios tenían que confiar en los registros hechos específicamente para una característica, cuando estaba disponible, o intentar usar los datos de notificación de alertas y tareas internas como fuente para la generación de informes.
  • Un sistema central para que los desarrolladores implementen activadores de notificación de manera coherente y fácil. Gran parte del trabajo de desarrollar activadores de notificación se ha realizado para el desarrollador. En el pasado, los desarrolladores a menudo tenían que implementar sus propias soluciones a problemas como la programación y los marcadores de posición, pero todos se encargaban de esto en notificaciones centralizadas.

Cómo se procesan las notificaciones centralizadas

Los eventos de notificación basados en acciones y aquellos basados en fechas registradas se procesan de maneras ligeramente diferentes:

  • Si el evento fue una acción que realizó un usuario, el evento se registra en una cola de eventos de notificación. La tarea Procesar notificaciones activadas por eventos (\totara_notification\tarea\process_event_queue_task) está configurada de forma predeterminada para ejecutarse en segundo plano cada minuto, y observa todos los eventos registrados en la cola y verifica si existen notificaciones correspondientes que estén configuradas para ser enviadas el evento . La disminución de la frecuencia de esta tarea programada hace que los usuarios esperen más tiempo antes de recibir estas notificaciones y no tiene ningún beneficio de rendimiento, por lo que debe dejarse que se ejecute cada minuto.
  • Las notificaciones que están programadas para ser enviadas antes o después de las fechas registradas, o que están programadas para ser enviadas en el evento y se basan en las fechas registradas, son procesadas por la tarea Procesar notificaciones activadas por fechas (\totara_notification\task\process_scheduled_event_task), que está configurada por defecto para ejecutarse en segundo plano una vez al día. Este proceso encuentra todas las notificaciones programadas para ser enviadas desde la última vez que se ejecutó la tarea. Si bien es posible ejecutar esta tarea con más frecuencia, considera el impacto en el rendimiento de esta decisión, ya que esta tarea debe evaluar muchos datos para determinar si alguna fecha registrada coincide con los programas configurados en las notificaciones.

Una vez que se encuentra un evento de notificación, se produce el siguiente proceso:

  1. Si el activador de notificación está desactivado, la notificación se descarta (esto puede ocurrir antes, pero no es relevante desde el punto de vista del usuario).
  2. Si la notificación está deshabilitada, se descarta.
  3. El activador de la notificación puede implementar condiciones adicionales que deben cumplirse antes de enviar la notificación. Los datos del evento se evalúan y la notificación se descartará si no cumple con estos criterios.
  4. La lista de destinatarios se calcula en función de los datos del evento.
  5. El contenido de la notificación se genera para cada usuario. Los marcadores de posición en el asunto y el cuerpo se reemplazan con valores calculados utilizando los datos del evento.
  6. Se calculan las salidas habilitadas de cada destinatario.
  7. El contenido de la notificación se envía a través de cada salida para cada usuario.

Nota especial sobre cuándo se envían las notificaciones

En el pasado, se implementaban diferentes notificaciones de diferentes maneras. Un problema significativo fue cómo el sistema sabía si se había enviado una notificación, lo que ayudó a determinar si era necesario enviar una notificación. En muchos casos, si un administrador configuró una nueva notificación, el sistema determinaría que la notificación no se había enviado a una cantidad de usuarios que ya cumplían con los criterios para recibir esa notificación, y luego enviaría esa notificación a esos usuarios. En la mayoría de los casos, este no fue el resultado previsto. En el sistema de notificaciones centralizadas, las notificaciones solo se envían cuando deben enviarse. Las notificaciones no se colocan en una cola de espera para ser entregadas en algún momento posterior. El sistema no verifica las notificaciones que se han omitido o que deberían haber sido enviadas previamente. El sistema se basa en el tiempo para determinar qué se debe enviar en un momento determinado. Pregunta “¿Qué notificaciones deberían haberse enviado entre ahora y la última vez que se enviaron las notificaciones?”, y solo se envían estas notificaciones.

Un ejemplo ayudará a explicar esto. Digamos que has creado una notificación para dar la bienvenida a nuevos usuarios cuando están inscritos en un curso. Si la notificación está programada para enviar el evento On (es decir, tan pronto como el usuario esté inscrito), solo se enviará a los usuarios que se inscriban después de que usted cree la notificación. La notificación no se enviará retroactivamente a los usuarios que se inscribieron antes de que usted creara la notificación. Si configuras la misma notificación para enviar 1 mes después de la inscripción, entonces cada día el sistema verificará si hay usuarios con una fecha de inscripción de un mes atrás y los enviará a esos usuarios, incluso si la notificación no existía en el momento en que se inscribieron. En este caso, todos los usuarios que se inscribieron en el último mes y aquellos que se inscribieron en el futuro recibirán la notificación en la fecha adecuada. Aquellos que se inscribieron hace más de un mes nunca lo recibirán, porque debían recibir la notificación antes de que se creara.

Los usuarios suspendidos no recibirán notificaciones. Cuando un usuario suspendido es restituido, no recibirá ninguna notificación activada durante su suspensión. Las notificaciones que deberían haber sido enviadas mientras un usuario estaba suspendido no están en cola.

Herencia de notificación

Las notificaciones del sistema de notificaciones centralizadas se heredan de contextos más altos a contextos más bajos. La funcionalidad proporcionada por herencia es similar a la idea de las plantillas, ya que las notificaciones se pueden crear y administrar en un solo lugar y luego se reutilizan en muchos otros lugares.

Las notificaciones se pueden crear en diversos contextos, como dentro de cursos, programas, seminarios o en el contexto del sistema (también denominado “nivel de sitio”). Las notificaciones se pueden configurar en contextos superiores al contexto donde ocurre el evento y heredar a niveles de contexto inferiores. Por ejemplo, los eventos de finalización de cursos ocurren en un contexto de curso, pero las notificaciones de curso completado se pueden crear en el contexto del sistema, así como dentro de cursos individuales. Las notificaciones en cualquier contexto están determinadas por aquellas creadas en ese contexto, así como por aquellas heredadas de contextos superiores. Las notificaciones en contextos más altos se heredan en todos los contextos descendentes donde ocurre el evento.

Las notificaciones heredadas de contextos superiores pueden tener varias propiedades anuladas en un contexto inferior. Por ejemplo, un usuario asignado en la notificación del programa podría crearse en el contexto del sistema, con contenido genérico del asunto y del cuerpo adecuado para la mayoría de los programas. Luego, en un programa específico, el asunto y el cuerpo podrían personalizarse para ser más adecuados para ese programa, o la notificación podría deshabilitarse completamente en ese programa.

Por ejemplo, es posible que desees que todos los cursos de tu sitio envíen un mensaje de bienvenida al curso cuando se inscriba un usuario por primera vez. Este mensaje debe tener el mismo contenido en todos los cursos, excepto por el nombre del curso y el nombre del usuario. En la interfaz de notificaciones a nivel del sitio, el administrador del sitio puede configurar una notificación e incluir el nombre completo del curso y los marcadores de posición del nombre del usuario en el asunto y/o el cuerpo (1). Esta notificación será heredada en todos los cursos, lo que significa que todos los cursos nuevos y existentes tendrán esta nueva notificación configurada automáticamente (2). En un curso en particular, el administrador del curso puede decidir que el cuerpo de la notificación debe ser cambiado para proporcionar información adicional a los nuevos usuarios. Pueden cambiar la notificación en este nivel de contexto específico editando la notificación heredada dentro de la interfaz de notificaciones del curso, habilitando la opción Anular para el cuerpo y haciendo los cambios necesarios (3). En otro curso, el administrador del curso puede decidir deshabilitar la notificación heredada y crear una nueva notificación personalizada basada en el mismo activador de notificación (4). 

Notificaciones heredadas

Actualmente, una serie de características diferentes utilizan notificaciones heredadas, que funcionan de manera diferente al sistema de notificaciones centralizadas. Si la funcionalidad que estás usando no está cubierta por notificaciones centralizadas, verifica la documentación de esa característica. Continuaremos agregando nuevas notificaciones y migrando las notificaciones existentes al sistema de notificaciones centralizado .

C065 - Notifications in Totara

The Totara Academy has a whole course dedicated to Notifications in Totara. Here you can learn more about how to set up and use centralised notifications, see best practice, and give it a go yourself.

© Copyright 2024 Totara Learning Solutions. All rights reserved.


¿Te ha sido útil este artículo?

Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.