En esta página vas a encontrar una breve descripción sobre los webjobs que están corriendo actualmente así como el schedule sugerido (para los que corren bajo ese criterio), así como también las colas que hasta el día de hoy se usan.

WebJobs

ActiveUsersBySubscriptionScheduledWJ

Acciones que realiza.

1. Query a la base del campus para obtener la cantidad de usuarios activos de cada suscripción.
2. Luego inserta en la base del dashboard un registro por cada suscripción con el count obtenido.
3. Finalmente genera un json con todos los count y lo guarda en el datalake.

Schedule

0 50 0/8 * * * (cada 8hs en el minuto 50)

Nombre sugerido

PROD-ActiveUsersBySubscription

CalculatePerformanceAndRankingsScheduledWJ

Acciones que realiza.

1. Corre el stored procedure SumarizeUsersActivityRankingData que calcula los minutos pasados en 2. el campus por los usuarios en los últimos 15, 30, 60 y todos los días.
2. Corre el stored procedure SumarizeCompletedLiveEventsData que calcula los cursos completados por los usuarios en los últimos 15, 30, 60 y todos los días.
3. Corre el stored procedure SumarizeAttendancePerformanceByUser que calcula la asistencia a clases virtuales y presenciales de los usuarios en los últimos 15, 30, 60 y todos los días.
4. Corre el stored procedure SummarizeUsersAcademicPerformance que calcula el promedio de exámenes rendidos de los usuarios en los últimos 15, 30, 60 y todos los días.
5. Corre el stored procedure ProcessUsersActivityTimeRankings que calcula los rankings de tiempo de actividad para los últimos 15, 30, 60 y todos los días.
6. Corre el stored procedure ProcessUsersCompletedLiveEventsRankings que calcula los rankings de cursos completados para los últimos 15, 30, 60 y todos los días.
7. Corre el stored procedure ProcessUsersAcademicPerformanceRankings que calcula los rankings de situación académica para los últimos 15, 30, 60 y todos los días.

Schedule

0 40 0/8 * * * (cada 8hs en el minuto 40)

Nombre sugerido

PROD-StdPerformanceAndRankings

SumarizeUsersTimeSpentOnLiveEventScheduledWJ

Acciones que realiza.

1. Corre el stored procedure SummarizeUsersTimeSpentOnLiveEvent que calcula los minutos pasados en el en cada curso por los usuarios en los últimos 15, 30, 60 y todos los días.

Schedule

0 20 0/8 * * * (cada 8hs en el minuto 20)

Nombre sugerido

PROD-TimeSpentOnLiveEvents

SummarizeLiveEventPerformanceScheduledWJ

Acciones que realiza.

1. Crea una tabla temporal igual a LiveEventPerformanceRanking sobre la que luego va a realizar las inserciones.
2. Realiza una query al campus para obtener todos los liveevents de todas las suscripciones que no estén borradas ni vencidas.
3. Inserta el resultado de la query anterior en la tabla temporal.
4. Ejecuta el stored procedure SummarizeAcademicPerformanceData que calcula el promedio de los exámenes de cada liveevent.
5. Ejecuta el stored procedure SummarizeAttendancePerformanceData que calcula el promedio de asistencia a clases de cada liveevent.
6. Ejecuta el stored procedure SummarizeLiveEventPerformanceBySubscription que saca el promedio de exámenes y asistencia de todos los cursos de cada suscripción para insertarlos en LiveEventPerformanceBySubscription (genera un registro por día. Es lo que hace que se vea la variación de los promedios en los últimos 15 días).
7. Borra la tabla vieja y renombra la temporal.

Schedule

0 10 0/8 * * * (cada 8hs en el minuto 10)

Nombre sugerido

PROD-LiveEventPerformance

SummarizeStudentsStatisticsOfExpiredLiveEventsWJ

Acciones que realiza.

1. Ejecuta el stored procedure UpdateUsersEventsInfoCompletedStateOfExpiredLiveEvents que calcula el promedio de los exámenes y la asistencia de cada liveevent y lo guarda en los UsersEventsInfo correspondiente.

Schedule

0 0 0/8 * * * (cada 8hs en el minuto 0)

Nombre sugerido

PROD-ExpiredLiveEventStatsWJ

Notas

• Por config está buscando liveevents vencidos en el último día.
• Esta info es la que se usa para mostrar en el listado de inscriptos a curso del admin y en el listado de cursos en curso del participante.

WIT.LMS.AsyncBulkActionsWebJob

Acciones que realiza.

1. Envio Masivo de Emails
   • Master worker (mail).
     • Recibe el mensaje de nuevo envío de mail masivo que se generó desde el campus en la cola async-master-queue.
     • Levanta los templates y los guarda en mandrill.
     • Según el tamaño del envío, genera N batches para repartir las tareas y encola N mensajes para el slave.
   • Slave worker (mail).
     • Recibe el mensaje de nuevo envío de mail masivo que se generó desde el master worker en la cola async-slave-send-email-queue.
     • Pide los usuarios correspondientes a ese batch a la base del campus.
     • Trae el attachment del storage si es necesario.
     • Envía el mail a los usuarios correspondientes.
   • Cleaner worker (mail).
     • Recibe el mensaje de nuevo envío de mail masivo que se generó desde el master worker en la cola async-slave-cleaner-email-queue.
     • Descuenta el contador de estado en redis.
     • Si el contador llega a 0, borra los templates, el attachment y las keys en redis.
2. Ajuste de puntos de LiveEvent
   • Master Worker - async-master-queue
     • Recibe el mensaje de ajuste de puntos del liveevent desde el campus luego de haber creado/modificado/eliminado un contenido en la cola async-master-queue.
     • Se ejecuta la clase Batcher ProgressPointsAdjustement dividiendo el trabajo de ajuste de puntos y enviando mensajes para que procese por lotes el slave worker.
   • Slave Worker - async-slave-progress-pts-adj-queue
     • Obtiene los usuarios que están inscriptos o que alguna vez lo estuvieron (desinscriptos).
     • Por cada usuario ejecuta un método que:
       • Obtiene los users_event_information de los programas asociadas al curso.
       • Ejecuta un stored procedure que:
         • Actualiza los puntos en el users_events_info.
         • Actualiza los users_content_info para los usuarios que vieron el contenido.
         • Completa el curso en caso de tratarse de una eliminación de contenido.
       • Para los usuarios que completaron el curso/programa envía los mensajes que deben de ser procesados por el webjob-bigdata.
       • Para lo usuarios en donde hubo una actualizacion de puntos se envia el mensaje correspondiente para que sea procesado por el webjob-bigdata.
     • En caso de error mientras se obtienen los usuarios se vuelve a encolar el mensaje completo.
     • En caso de error mientras se procesa un usuario particular se captura la excepción y se encola un mensaje para realizar el mismo procesamiento anteriormente explicitado a ese usuario específico.

Schedule

Contínuo.

Nombre sugerido

PROD-AsyncBulkActionsWebJob

WIT.LMS.WebJobBigData

Acciones que realiza.

1. Desencola mensajes de las distintas colas de dashboard.
2. Según la cola de la que tomó y el método definido en el mensaje tiene mapeado qué clase debe resolver dicho mensaje.
3. Se ejecuta la clase definida que suele hacer alguna inserción o update sobre la base de dashboard.
4. Finalmente se guarda el mensaje original en el datalake

Schedule

Contínuo.

Nombre sugerido

PROD-WebJobBigData

WIT.LMS.ExpiredSubscriptionMailerWebJob

Objetivo

Enviar mails de notificación de próximo vencimiento a los resellers y/o administradores de cuentas que estén por vencer.

Acciones que realiza.

1. Verifica que suscripciones estén por vencer desde el momento en el que corre el jobs hasta 1 y 5 días en el futuro.
2. Verifica que ya no le haya mandado notificación, si no es así, busca al reseller y a los admins de esa cuenta.
   Para cada uno de esos resellers o admins les envía un mail notificando.

Schedule

0 0 0 * * *

Nombre sugerido

PROD-ExpiredSubscriptionMailer

WIT.LMS.Services.Workers.LiveEventRemindersMailer

Objetivo

Envía los recordatorios de las clases virtuales y presenciales a los inscriptos.

Acciones que realiza.

1. Busca clases que tengan recordatorios configurados que entren dentro de los últimos X minutos (parámetro de configuración).
2. Deja un mensaje en la cola del envío masivo de mails para que lo procese el webjob correspondiente.

Schedule

0 0/5 * * * *

Nombre sugerido

PROD-LiveEventRemindersMailer

WIT.LMS.Services.Workers.TakeVirtualRoomUsersAttendance

Objetivo

En base a la información de ingresos a la sala virtual, determina si los usuarios estuvieron presentes, llegaron tarde o estuvieron ausentes de las clases de sala virtual

Acciones que realiza.

1. Toma los registros de ingresos a la sala de clases que hayan finalizado en la última hora (usando un stored procedure). Éste incluye el tiempo que pasó cada uno de los usuarios que ingreso.
2. Guarda los datos de asistencia en la base del campus.
3. Genera mensajes para ser enviados a la cola para que éstos también se reflejen en la base del dashboard.

Schedule

0 0 * * * *

Nombre sugerido

PROD-TakeVirtualRoomAttendance

WIT.LMS.Services.Workers.AddUsersByEmail

Objetivo

Inscribe usuarios a cursos para WesternUnion

Acciones que realiza.

1. Busca nuevos correos en wuapi@wormholeit.com
2. De esa casilla baja CSVs con listados de usuarios a inscribir (según las reglas puestas en el código).
3. Los crea (si hace falta) y los inscribe a los cursos.

Schedule

0 0 * * * *

Nombre sugerido

PROD-AddUsersByEmail

WIT.LMS.Workers.BadgesProcessor

Objetivo
Determina si debe generar o no una nueva medalla en base al mensaje recibido. Conoce a cada categoría de medallas, y estas mismas saben los criterios de otorgamiento.

Acciones que realiza.

1. Desencola mensajes de las distintas colas de dashboard.
2. Según la cola de la que tomó y el método definido en el mensaje tiene mapeado qué clase debe resolver dicho mensaje.
3. Se ejecuta la clase definida que define si debe o no generar una nueva medalla para el usuario y suscripción correspondientes.

Schedule

Contínuo.

Nombre sugerido

PROD-BadgesProcessor

WORKER.WIT.LMS.UpdateSubscriptionStatusWorker

Objetivo

Setea el estado “inactive” a las suscripciones que vencieron en las últimas 24 hs

Acciones que realiza.

1. Busca suscripciones que hayan vencido en las últimas 24hs.
2. Para cada una de ellas llama a un strategy para:
   • Setearles el estado “inactive”.
   • Si el customer de la cuenta solo tenía una cuenta activa, también lo pone como “inactive”.

Schedule

0 0 0 * * *

Nombre sugerido

PROD-UpdateSubscriptionStatus

WIT.LMS.Services.Workers.WebhookWJ

Objetivo

Notificar a una URL sobre las actualizaciones o la actividad de los usuarios en el Campus. Gracias a esto se podrán programar integraciones basadas en las novedades que van surgiendo sin tener que pedir toda la información nuevamente y compararla con un registro anterior de la misma.
Un ejemplo sería poder actualizar una base de datos con personas que completaron un curso solo cuando se llame automáticamente a una url del sistema externo cuando un usuario completa un curso.

Configuraciones implicadas

• Webhook_Callback_Url: La url del sistema externo a la que llamaremos cuando un usuario completa un curso. Por ejemplo: https://www.sistema.net/api/sync 
• Webhook_Callback_Token: Un token que enviaremos en todos los llamados a esa url. Por ejemplo: Tcl08eGhbkZJHU7n1XV1QDJhox3xrk9klRrP

Acciones que realiza.

1. Desencola mensajes de la queue liveevent-webhook-queue, que previamente son encolados por el WebJobBigData.
2. Valida que la suscripción esté activa, no borrada y tenga habilitado el webhook. Para esto último revisa si hay algún valor en la customization value Webhook_Callback_Url.
3. Hace un POST del mensaje en formato JSON a la url configurada en la customization Webhook_Callback_Url. El request siempre se hace con un header con el nombre Authorization y el valor que obtiene de la customization Webhook_Callback_Token.
4. Si el servidor que recibe el mensaje devuelve un Status Code 2xx, de Success, no realiza ninguna acción adicional. Caso contrario, el mensaje es encolado en la queue liveevent-webhook-queue-poison.

Schedule

Continuo

Nombre sugerido

PROD-WebhookWJ

Notas

• Hoy el WebJobBigData solo encola mensajes al completar un live event que luego son desencoladas por este webjob.
• Un ejemplo de json que envía el webhook: {"courseEditionId":null,"liveEventId":191863,"liveEventType":1,"subscriptionId":2169,"userId":1210691,"method":"Complete","active":true,"timestamp":"2020-09-08 17:37:49"}
• El atributo active indica si el live event está activo.
• Se envían también otros atributos en el json pero siempre están en null, desestimarlos.
• Para el caso de cursos con ediciones se envía un solo mensaje, en el mensaje va la property liveEventId con el id del maestro, la property liveEventType con el tipo maestro y la property courseEditionId con el id de la edición que se completó.

Queues

Dashboard

• liveevent-queue

  • En esta cola se van a guardar y consumir todos los mensajes de actividad relacionados con los liveevents. Actualmente incluye:
    • Create
    • Delete
    • Complete
    • ForumMessageCreate
    • EnrollUser
    • DisenrollUser
    • Access

• profile-queue

  • En esta cola se van a guardar y consumir todos los mensajes de actividad relacionados con los usuarios. Actualmente incluye:
    • LiveEventStatusChange
    • CreateLiveEvent
    • ViewAsTrainee
    • ViewLiveEvent
    • Login
    • Signup
    • ActivityTime
    • ViewProfile
    • UserStatusChange
    • NewUser

• content-queue

  • En esta cola se van a guardar y consumir todos los mensajes de actividad relacionados con los contenidos. Actualmente incluye:
    • ExamTaken
    • RollCall
    • ExamDeleted
    • ContentCompleted

• usersupdates-queue

  • En esta cola se van a guardar y consumir todos los mensajes de actividad relacionados con modificaciones sobre los datos personales del usuario. Actualmente incluye:
    • SignUp
    • Delete
    • Update

• newbadges-queue

  • En esta cola se van a guardar y consumir todos los mensajes relacionados con la generación de nuevas medallas.

• content-library-queue

  • En esta cola se van a guardar las visualizaciones y descargas de los documentos de la biblioteca para los students y teachers

Acciones masivas

• async-master-queue
  En esta cola se guardan los mensajes con los que se inicia la acción masiva. La conocen el campus (que es el productor) y el master worker (que es el consumidor).
• async-slave-send-email-queue
  En esta cola se guardan los mensajes para el envío por lotes de los mensajes. La conocen el master worker (que es el productor) y el slave worker (que es el consumidor).
• async-slave-cleaner-email-queue
  En esta cola se guardan los mensajes que informan cuántos mails fueron procesados por mandrill. La conocen el webhook que consume mandrill (que es el productor) y el cleaner worker (que es el consumidor).
• async-slave-progress-pts-adj-queue
  En esta cola se guardan los mensajes para el ajuste de puntos por lotes de los mensajes. La conocen el master worker (que es el productor) y el slave worker (que es el consumidor).

WebHooks

/webhooks/public/mandrill

Este webhook recibe requests de mandrill con información sobre los mails que procesó. Según la información que trae el body (metadata) sabe qué ambiente lo generó (DEVX, CampusTest o PROD) y según eso sabe si le corresponde o no encolar el mensaje en async-slave-cleaner-email-queue. Dicho mensaje básicamente contiene la misma metadata generada en el slave worker y además el número de mensajes que mandrill procesó.