Resolución de problemas

Por dónde empezar siempre#

Como el módulo son dos procesos separados por una tabla, lo primero es averiguar en qué lado está el problema, mirando el estado de la cola.

Sin necesidad de acceso a SQL, eso se ve desde a3ERP en Ficheros > Otros > Adicionales de gestión > Mailings, ordenando por Fecha envío: la tabla es auxiliar y a3ERP la expone directamente. Con acceso a base de datos, la misma información:

SELECT COUNT(*) AS Pendientes
FROM SIT_FED_MAIL_LOG
WHERE SIT_FED_SENT_TIME IS NULL;

• Hay filas pendientes que no bajan: la extensión hace su trabajo y el problema está en el servicio de envío o en el transporte de correo.
• No hay filas pendientes ni recientes enviadas: el problema está en la extensión o en la operativa del usuario, que quizá no llegó a pulsar Procesar con filas seleccionadas.
• Las filas se envían pero el usuario no las recibe: el problema está en el transporte, en el buzón de salida o en el filtrado del destinatario.

Los logs son la segunda parada. Cada componente escribe en la ruta que fije Logging:File:Path en su propio appsettings.json, en un fichero por día con la fecha añadida al nombre. Para diagnosticar, subir el nivel a Trace, reproducir y volver a bajarlo.

Si junto al log del día aparece otro con un nombre de usuario, <nombre>_<usuario>_<fecha>.log, es que esa cuenta no pudo escribir en el del día, y la primera línea de aviso dice por qué. En la extensión es lo normal en un servidor de terminales, porque el fichero del día lo tiene abierto el primer usuario que abrió la pantalla: lo que le pasó a un usuario concreto hay que buscarlo en el suyo. En el servicio, lo habitual es que el fichero del día lo creara otra cuenta, por ejemplo alguien que lanzó el servicio a mano antes que la tarea programada. En ningún caso impide trabajar, pero ese día el log queda repartido entre varios ficheros.

Y para ver el envío en directo, lanzar el ejecutable del servicio a mano y sin -auto en el servidor: con eso escribe el log también por consola y se ve fila a fila qué hace.

No se envía ningún correo#

Con filas pendientes en la tabla y nada saliendo, en orden de probabilidad:

1. La tarea programada no está corriendo. Revisar el historial de la tarea en el Task Scheduler, no solo que exista. Es la causa más habitual después de un reinicio del servidor o un cambio de contraseña de la cuenta de servicio.
2. La tarea corre pero no encuentra su configuración. Si el campo Iniciar en de la tarea está vacío, el servicio no localiza su appsettings.json, porque lo busca en el directorio de trabajo y no en la carpeta del ejecutable. El síntoma es característico: la tarea aparece ejecutada correctamente, no se envía nada y el log no crece ni una línea, porque el propio log se configura en el paso que falla. Se confirma lanzando el ejecutable a mano desde su carpeta: si así funciona, era esto.
3. La licencia no valida. El servicio comprueba licencia antes de enviar y, si falla, no envía nada y lo deja escrito en el log. Suele ir acompañado de un mensaje pidiendo contacto con Esofitec. Revisar la sección de licencias del appsettings.json y la conectividad con el servicio de licencias.
4. La configuración de transporte es incorrecta. Si MailerType es Office365, comprobar que la aplicación registrada sigue teniendo permiso de envío y que el secreto no ha caducado —los secretos de Entra ID expiran, y es un fallo que aparece de un día para otro sin que nadie haya tocado nada—. Con SMTP, comprobar credenciales, puerto y TLS.
5. La conexión a SQL del servicio no funciona. El log lo indica como error general al principio de la pasada.

Un correo concreto no sale y el resto sí#

Es el comportamiento previsto: el envío que falla se descarta para el resto de esa ejecución y se reintenta en la siguiente pasada, porque el fallo no se marca en la tabla. Si el mismo asunto y destinatario aparecen en el correo de resumen una y otra vez, hay algo permanente en esa fila.

Lo más común es una dirección de correo mal formada en la ficha del cliente: un espacio, una coma de más, dos direcciones pegadas sin separador. La columna admite varias direcciones separadas por comas o puntos y comas, pero no perdona una dirección sintácticamente inválida.

Para localizarla, buscar la fila pendiente más antigua y revisar su destinatario:

SELECT TOP 10 SIT_FED_ID_MAIL_LOG, SIT_FED_SUBJECT, SIT_FED_TO
FROM SIT_FED_MAIL_LOG
WHERE SIT_FED_SENT_TIME IS NULL
ORDER BY SIT_FED_ID_MAIL_LOG;

Se corrige en la ficha de a3ERP para los envíos futuros. La fila atascada se arregla escribiendo la dirección correcta en su columna Destinatario(s) desde Adicionales de gestión, o eliminándola y volviendo a procesar el envío desde la pantalla del módulo.

Al procesar se aborta todo y no se genera ningún correo#

Si la parrilla trae datos pero al pulsar Procesar sale un único mensaje de error y no se encola nada, lo más probable es que a la consulta le falte la columna de destinatarios, la configurada en EmailColumnName. El módulo la lee por nombre sin comprobar antes si existe, y el error que sale es del tipo La columna 'X' no pertenece a la tabla.

Es un fallo que engaña porque la consulta se refresca y se ve perfectamente: esa columna no la mira nadie hasta el momento de procesar. Pasa sobre todo con consultas nuevas. El nombre tiene que coincidir carácter a carácter con el alias de la consulta, tildes incluidas.

Las otras dos columnas configuradas, la de operación posterior y la de ficheros vinculados, no dan este problema: si la consulta no las trae, los correos se encolan igualmente y el módulo lo avisa al pie de la pantalla, la de ficheros vinculados solo si está marcada la casilla de adjuntar. Lo trata Configuración.

Se esperaba una operación posterior y no se ha realizado#

En las instalaciones que usan operaciones posteriores, si los correos salen bien pero lo que debía actualizarse en a3ERP no se actualiza, lo primero es mirar el pie de la pantalla de generación después de refrescar la vista. Si la consulta no devuelve la columna de operación posterior, ahí aparece un aviso diciéndolo: los correos se envían con normalidad y no se realiza ninguna operación posterior. Muchas veces es lo correcto y no hay nada que arreglar; solo es un problema si esa vista sí debía registrar algo.

Si el aviso no aparece, la columna sí llega y el asunto está aguas abajo: en el proceso externo que consume ese JSON, normalmente un trigger sobre la tabla de la cola. Conviene comprobar entonces que la fila tiene contenido en Operación posterior desde Adicionales de gestión, y que ese proceso existe y está activo en la base de datos del cliente.

El correo llega con marcadores sin sustituir#

El destinatario ve literalmente {{Algo}} en el texto. No es un fallo del módulo: el nombre escrito en la plantilla no coincide con ningún alias de la vista, y el módulo deja intacto lo que no reconoce.

Se comprueba mirando los títulos de las columnas en la parrilla, que son los nombres válidos. Las causas frecuentes son una tilde, una mayúscula o un espacio de diferencia, y que alguien haya renombrado el alias de una columna en la consulta sin avisar: eso rompe en silencio todas las plantillas que lo usaban. Ver el contrato entre la vista y la plantilla.

Error de longitud al procesar#

Un valor que no cabe en su columna aborta la fila al pulsar Procesar, y el mensaje depende de la versión de la App:

• Desde la 2.3.2.0 el aviso y el log dicen el campo y el límite, del estilo AttachmentsDirectory: El campo AttachmentsDirectory debe ser una cadena con una longitud máxima de 150. Con eso ya está localizado, y los límites de cada columna están en Modelo de datos.
• Antes de la 2.3.2.0 el texto era genérico, Validation failed for one or more entities, sin decir qué campo. Ahí el candidato es el directorio de adjuntos, de 150 caracteres, no el asunto: la ruta temporal que se genera por destinatario ya consume más de cien caracteres, así que un nombre de plantilla largo la desborda.

En las versiones anteriores a la 2.3.2.0 fallaban también los envíos sin ningún adjunto, porque la ruta temporal se guardaba siempre. Si el síntoma aparece en una instalación con nombres de plantilla largos y nadie ha marcado la casilla de adjuntar documentos, la salida es actualizar la extensión.

La solución inmediata en cualquier versión es acortar el nombre de la plantilla —renombrando también su carpeta _archivos—, teniendo en cuenta que ese nombre es el asunto del correo que recibe el cliente, así que conviene acordarlo con quien gestione los envíos.

Los adjuntos no llegan#

Distinguir primero de qué adjuntos se habla, porque el origen es distinto:

• Faltan el logotipo y los ficheros de la plantilla. La carpeta <nombre de la plantilla>_archivos no existe, no está junto al .htm o no se llama exactamente igual que la plantilla. Ocurre al renombrar la plantilla y olvidar la carpeta.
• Faltan los documentos propios de cada cliente. Por orden: el usuario no marcó la casilla; falta AttachmentsColumnName en el appsettings.json de la extensión, lo normal tras actualizar desde una versión anterior a la 2.3.3.1, y no hay aviso; la vista no devuelve esa columna, y entonces sí hay aviso al pie de la pantalla; o las rutas que devuelve no existen o no son accesibles desde el puesto que genera el envío. Para esto último, subir MailingViewModel a Warning en el log de la extensión: cada fichero que no encuentra deja una línea con su ruta.
• Llegan algunos documentos del cliente pero no todos. El módulo adjunta todo lo que devuelve la columna, así que o la consulta no los incluye —ejecutarla y mirar esa columna en la fila del cliente—, o esas rutas en concreto no existen en el disco. Lo explica Configuración.
• No llega ningún adjunto de ningún tipo, habiendo marcado la casilla. Es el caso con más causas posibles y tiene su propio apartado justo debajo.

Se marcó la casilla y no ha llegado ningún adjunto#

La clave para entender este síntoma es dónde están los ficheros. La extensión los copia a una carpeta temporal del puesto y del usuario que genera el envío, guarda esa ruta en la cola, y el servicio de envío la lee después, desde el servidor y con la cuenta de la tarea programada. Todo lo que rompa esa cadena deja el correo sin adjuntos, y el correo sale igual: no hay error ni línea en el log.

Comprobar en este orden:

1. El envío se generó en un terminal distinto del servidor. La ruta guardada es local del puesto, del estilo C:\Users\...\AppData\Local\Temp\..., y en el servidor esa ruta no existe. En las instalaciones de a3ERP en red con servidor y terminales físicos separados, este caso afecta a todos los envíos con adjuntos. Se ve al instante comparando el valor de Directorio de adjuntos de la fila con lo que existe en el servidor.
2. Misma máquina, pero cuentas distintas. El temporal de un usuario no es accesible para otro: la cuenta de la tarea programada no puede leer C:\Users\<otro usuario>\AppData\Local\Temp. Cae en lo mismo aunque la ruta sí exista.
3. El usuario cerró sesión, o se limpió el temporal, antes de que el servicio hiciera su pasada. Entre generar el envío y enviarlo pasa el tiempo que marque la tarea programada, y en ese hueco los ficheros pueden desaparecer: perfiles temporales o de dominio que se borran al cerrar sesión, Sensor de almacenamiento, o cualquier limpieza programada del equipo. La carpeta ya no está y la ruta de la cola apunta a la nada.
4. La ruta pasaba de 150 caracteres. Aquí el síntoma es distinto y conviene no confundirlo: la fila no se llega a encolar, así que no es que el correo salga sin adjuntos, es que no sale ningún correo. Lo trata Error de longitud al procesar.

Los tres primeros casos no se arreglan con la configuración del módulo: para que funcionen, la carpeta temporal del usuario que genera el envío tiene que seguir existiendo, y ser legible por la cuenta del servicio, en el momento de la pasada. Eso solo se cumple cuando la extensión y el servicio corren en la misma máquina y con acceso a la misma carpeta, como en un servidor de escritorio remoto. Ver Instalación.

Las imágenes llegan como adjunto en vez de dentro del texto#

El módulo incrusta en el cuerpo las imágenes de la plantilla reescribiendo sus referencias, pero solo reconoce el marcado que genera Word al guardar como página web. Una plantilla montada a mano, con rutas absolutas o con imágenes referenciadas de otra forma, no se reescribe y las imágenes viajan como ficheros sueltos. La vía rápida es rehacer la plantilla guardándola desde Word.

Caracteres extraños o espaciado raro en el cuerpo#

Revisar EsPlantillaWord en el appsettings.json de la extensión: con plantillas hechas en Word tiene que estar a true para que el módulo limpie el marcado que añade Word en la versión de texto plano del correo.

Si lo que se ve mal son las tildes, el origen suele ser la codificación con la que Word guardó el fichero. Volver a guardar la plantilla desde Word resuelve la mayoría de los casos. Y si los caracteres extraños están en el asunto, tener en cuenta que las columnas de la tabla no son Unicode.

El usuario no ve la opción de menú#

Comprobar en este orden: que el menú del módulo está importado en a3ERP, que el diccionario DSIT_FEDMAILING está activado en la empresa, y que el ejecutable está donde el menú lo busca, dentro de la carpeta de binarios de la extensión.

La extensión no abre y dice que debe iniciarse desde a3ERP#

La extensión exige recibir todos los parámetros de apertura y solo los que conoce: si llegan de menos, o aparece uno que no reconoce, se niega a arrancar con ese mensaje.

Pasa cuando alguien ha editado la entrada de menú y ha tocado los parámetros, o cuando se intenta lanzar el ejecutable a mano desde una carpeta. La cadena que espera es la que trae el menú del módulo:

:E :Empresa :U :Usuario :P :Password :T :Tipo :O :MailingView

De todo eso el módulo solo utiliza la opción final; el resto se descarta en cuanto se valida. La validación es estricta, así que hay que pasarlos igualmente. Si el menú se ha modificado, lo más rápido es volver a instalarlo.

La pantalla se abre y da un error de configuración#

El módulo lee todas sus claves al abrirse y falla de inmediato si falta alguna, indicando cuál. Las dos confusiones habituales:

• Falta el appsettings.xml, que es donde viven las vistas. Los dos ficheros de configuración de la extensión son obligatorios.
• Se ha copiado el appsettings.json del servicio de envío sobre el de la extensión, o al revés. Se llaman igual pero tienen claves distintas.

El desplegable de plantillas está vacío#

PlantillasPath apunta a una carpeta que no existe, está vacía o no es accesible para el usuario que abre a3ERP. Si es una ruta de red, comprobar que el usuario del puesto —no el del servidor— tiene acceso.

El envío se ha vuelto lento#

Con muchos envíos históricos, revisar el tamaño de SIT_FED_MAIL_LOG. La tabla no se purga y no tiene índice sobre la fecha de envío, así que la búsqueda de pendientes se degrada a medida que crece el histórico. Lo trata Modelo de datos.