Propiedades de página | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Descripción
El sistema SGI debe poder generar comunicados de manera automática o, lo que es lo mismo, sin intervención manual por parte del usuario, para que los destinatarios que a cada uno apliquen puedan recibirlos por email. Este tipo de comunicados han de estar previamente a su necesidad de envío programados como tareas en el SGI.
Actores
El propio sistema SGI.
Precondiciones
Para el envío/recepción de un comunicado automático, que siempre será por email, deben cumplirse una serie de condiciones:
- El comunicado ha de disponer de una plantilla de asunto y contenido configurada en el SGI.
- El comunicado ha de disponer de una lista de destinatarios configurados, por unidad de gestión, para ese tipo de comunicado.
- La persona o personas destinataria/s de los mismos deben disponer de un email operativo y, en el caso de que el destinatario sea una persona del SGP con el que el SGI se integra, este email debe estar además marcado como "principal". Puede haber destinatarios resueltos desde la configuración o que haya que resolver justo al momento del envío del mismo y no antes, en este caso, deben igualmente cumplir esta condición.
Garantías de éxito (postcondiciones)
Todos los destinatarios configurados o resueltos en diferido asociados al comunicado reciben el comunicado por email en la fecha, con el asunto y con el contenido adecuado.
Escenario principal (flujo básico) -
Comunicado enviado de manera "inmediata"Programación de envío de comunicado
- Dentro de la gestión que corresponda se necesita enviar un comunicado a un destinatario o lista de destinatarios concreta de manera "inmediata" tras el momento en que se produce el evento que lo dispara.
- El módulo que origina la necesidad del del comunicado (CSP, ETI, PII) genera el email a enviar en el módulo de comunicados, enviando además los parámetros necesarios para que se sustituyan dentro de la plantilla de este tipo de comunicado.
- El módulo de comunicados registra los datos del comunicado y lo envía a los destinatarios indicados.
- Si se han indicado destinatarios a resolver en diferido (checks IPs proyecto, IPs convocatoria, ... los responsables económicos, ...), previamente al envío ha de resolverse la lista completa de destinatarios.
Escenario principal (flujo alternativo 1) - Comunicado enviado de manera "programada"
- Dentro de la gestión que corresponda se necesita enviar un comunicado a un destinatario o lista de destinatarios concreta en una fecha futura programada.
- El módulo que origina la necesidad del comunicado (CSP, ETI, PII) registra una tarea programada para la fecha y hora indicada y a la vez un email a enviar en el módulo de comunicados, enviando además los parámetros necesarios para que se sustituyan dentro de la plantilla de este tipo de comunicado.
- El módulo de tareas programadas, llegada la fecha y hora programadas para el envío del comunicado, solicita al módulo de comunicados el envío del email previamente registrado .
- El módulo de comunicados envía el email a los destinatarios indicados.
- Si se han indicado destinatarios a resolver en diferido (checks IPs proyecto, IPs convocatoria, ... los responsables económicos, ...), previamente al envío ha de resolverse la lista completa de destinatarios.
Escenario principal (flujo alternativo
21) -
Comunicado enviado de manera "programada" preconfiguradoEnvío de comunicado previamente programado
- Existe una tarea programada ya preconfigurada en el producto para enviar un comunicado en una fecha y hora indicada y, opcionalmente, que se repita además este envío cada X tiempo.
- El módulo de tareas programadas, llegada la fecha y hora programadas para el envío del comunicado, solicita al módulo que origina la necesidad del comunicado (CSP, ETI, PII) los parámetros necesarios para que se sustituyan en la plantilla y con ellos llama al módulo de comunicados para solicitar el envío del email.
- El módulo de comunicados envía el email a los destinatarios indicados.
- Si se han indicado destinatarios a resolver en diferido (checks IPs proyecto, IPs convocatoria, ... los responsables económicos, ...), previamente al envío ha de resolverse la lista completa de destinatarios.
Escenario principal (flujo alternativo
32) - Fallo en el proceso de
generación de comunicado "inmediato"- Dentro de la gestión que corresponda se necesita enviar un comunicado a un destinatario o lista de destinatarios concreta de manera "inmediata" tras el momento en que se produce el evento que lo dispara.
- El módulo que origina la necesidad del comunicado (CSP, ETI, PII) registra un email a enviar en el módulo de comunicados, enviando además los parámetros necesarios para que se sustituyan dentro de la plantilla de este tipo de comunicado.
- El registro del email falla.
- Se deja registro del error en los log y se hace rollback en el módulo invocante (CSP,ETI,PII) si es que el propio envío del email altera datos en esos módulos, esto es, no se registrará una entrada en la tabla que asocia una entidad de esos módulos con el email, ya que no se ha podido generar. En ningún caso se dejará de realizar el "guardado" o "aplicación" de los posibles cambios que disparan el envío del comunicado en las entidades del módulo invocante (CSP,ETI,PII) porque no se pueda enviar el email. Por ejemplo, no se dejará de guardar un cambio de estado de la solicitud porque no se pueda enviar el email de aviso de que se ha producido este evento.
programación y/o generación de comunicado
- Dentro de la gestión que corresponda se necesita enviar un comunicado a un destinatario o lista de destinatarios concreta en una fecha futura programada.
- El módulo que origina la necesidad del comunicado (CSP, ETI, PII) registra una tarea programada para la fecha y hora indicada y a la vez un email a enviar en el módulo de comunicados, enviando además los parámetros necesarios para que se sustituyan dentro de la plantilla de este tipo de comunicado.
- El registro del email o el de la tarea programada falla.
- Se deja registro del error en los log y se hace rollback en el módulo invocante (CSP,ETI,PII) si es que el propio registro del email o la programación de la tarea altera datos en esos módulos, esto es, no se registrará una entrada en la tabla que asocia una entidad de esos módulos con el email y con la tarea programada, ya que no se ha podido generar uno u otor. En ningún caso se dejará de realizar el "guardado" o "aplicación" de los posibles cambios que disparan el envío del comunicado en las entidades del módulo invocante (CSP,ETI,PII) porque no se pueda registrar el email y/o registrar la tarea programada que dispara su envío. Por ejemplo, no se dejará de guardar un período de pago a un socio colaborador en un proyecto porque no se haya podido generar la tarea que programa el envío del email.
Casos de uso relacionados
Manual
- CU-CSP-1100 -002- Modificar solicitud - Cambio de estado —
- CU-ETI-0010-008 - Envío notificación convocatoria —
- CU-ETI-0020-002 - Evaluar memoria - Guardar sin comentarios —
- CU-ETI-0020-003 - Evaluar memoria - Guardar con comentarios —
- CU-ETI-0060-005 - Enviar a secretaría —
- CU-ETI-0070 - Procesos batch —
- CU-ETI-0090-002 - Evaluar memoria seguimiento - Guardar sin comentarios —
- CU-ETI-0090-003 - Evaluar memoria seguimiento - Guardar con comentarios —
- CU-PII-0010-002 - Solicitudes de protección - Avisos —
Auto
Interfaces relacionados
Manual
- IU-CSP-0204-008 - Modificar convocatoria - Hitos —
- IU-CSP-0302-017 - Añadir-modificar hito —
- CSP Proyectos, contratos, becas y ayudas --
- IU-CSP-0304-005 - Modificar Solicitud - Modificar Hitos - Unidades de gestión —
- IU-CSP-0402-009 - Añadir-modificar fase —
- IU-CSP-0402-010 - Añadir-modificar hito —
- IU-CSP-202-009 - Añadir hito a convocatoria —
- IU-ETI-0030-001 Búsqueda y listado de actas —
Auto