Ficha técnica

Sit.Mailer es un addon estándar de a3ERP para el envío masivo de correos personalizados a partir de consultas SQL y plantillas HTML. Este documento está dirigido a implantación y soporte: cubre la arquitectura, los componentes, la instalación y el diagnóstico. La operativa de usuario —la pantalla, las plantillas y el paso a paso— está en la Visión general del portal de usuario.

Identificación del addon#

Arquitectura#

El módulo son dos ejecutables independientes que se comunican a través de una tabla, no entre ellos:

  Usuario en a3ERP                                        Tarea programada
        │                                                        │
        ▼                                                        ▼
  Sit.Mailer.App  ──escribe──►  SIT_FED_MAIL_LOG  ──lee──►  Sit.Mailer.Sender  ──►  Office 365 / SMTP
   (extensión)                   (cola de envíos)             (desatendido)

Sit.Mailer.App ejecuta la consulta de la vista elegida, compone el cuerpo de cada correo sustituyendo los marcadores de la plantilla e inserta una fila por destinatario en SIT_FED_MAIL_LOG con la fecha de envío a NULL. Ahí acaba su trabajo: no envía nada.

Sit.Mailer.Sender se ejecuta desde una tarea programada, recoge las filas pendientes, envía cada correo y les estampa la fecha de envío. Al terminar, si ha habido errores, manda un resumen a la dirección de notificaciones.

Por qué está partido en dos#

Tiene tres consecuencias prácticas para soporte, y las tres explican decisiones de diagnóstico:

• La pantalla de a3ERP nunca falla por culpa del correo. Si el buzón está mal configurado o el servidor SMTP rechaza los envíos, el usuario no ve nada raro: encola correctamente y el problema aparece en el log del Sender y en el correo de resumen. Cuando un usuario dice "no llegan los correos", el punto de partida es el Sender, no la App.
• Los reintentos son gratis. Un envío que falla no se marca en la tabla, así que la siguiente pasada de la tarea programada lo vuelve a intentar sin que nadie haga nada. Dentro de una misma ejecución, en cambio, un envío que ha fallado se descarta para no reprocesarlo en bucle.
• Las credenciales del buzón viven solo en el servidor, en la configuración del Sender. Los puestos de usuario no las tienen.

No usa NAX ni ActiveX#

Tanto la App como el Sender acceden a SQL Server directamente, con las credenciales de sus respectivos ficheros de configuración. Ni consultan a3ERP a través del enlace NAX ni requieren el componente ActiveX.

De todo lo que a3ERP le pasa a la extensión al abrirla —empresa, usuario, contraseña, tipo contable y opciones— el módulo solo usa las opciones, para decidir qué ventana abrir. El resto se ignora por completo, así que el usuario y la contraseña de la sesión de a3ERP no intervienen en la conexión a la base de datos.

Esto simplifica la instalación —no hay que dar de alta usuarios de ActiveX— pero tiene dos implicaciones que conviene tener claras:

• Hace falta un usuario de SQL Server propio, con permisos de lectura sobre las tablas que consulten las vistas y de escritura sobre SIT_FED_MAIL_LOG. Los permisos del usuario de a3ERP no pintan nada aquí. El detalle de qué credenciales usa cada componente y con qué privilegios está en con qué credenciales se accede a la base de datos.
• El módulo trabaja siempre contra la base de datos indicada en su configuración, con independencia de la empresa que el usuario tenga abierta en a3ERP, porque la empresa recibida también se ignora. En una instalación multiempresa eso significa que un usuario situado en otra empresa vería y enviaría los datos de la empresa configurada. Es el primer sitio donde mirar si un cliente multiempresa reporta datos que no le cuadran.

Componentes#

Lo que se configura y lo que no#

Casi todo el comportamiento del módulo sale de configuración, no de código, y eso define el reparto de trabajo con el cliente:

• Las vistas son consultas SQL en un fichero de configuración. Añadir una lista de destinatarios nueva, o un dato nuevo para personalizar los correos, es editar ese fichero. No requiere versión nueva ni reinstalar.
• Las plantillas son ficheros del sistema. El usuario las crea y las cambia por su cuenta, sin intervención de implantación.
• El asunto no se configura: es el nombre del fichero de la plantilla.
• La periodicidad de los envíos es la de la tarea programada del servidor, no un parámetro del módulo.

El contrato entre la consulta y la plantilla es la parte que hay que entender bien para dar soporte, y está detallado en Configuración.

Por dónde seguir#

• Instalación: requisitos, despliegue de los dos ejecutables y verificación.
• Configuración: claves de los appsettings, definición de vistas y transporte de correo.
• Modelo de datos: la tabla de la cola, sus límites y consultas útiles para soporte.

• Resolución de problemas: síntomas habituales y por dónde empezar.

• Registro de cambios: qué cambió en cada versión y qué hay que desplegar para llevarla a una instalación.

Ese último es el que hay que leer antes de actualizar un cliente: cada entrada dice si basta con sustituir un ejecutable, si hacen falta los dos, o si hay que actualizar antes el diccionario en a3ERP. Saltarse ese orden es la causa más habitual de que una actualización deje el módulo a medias.