Cómo funcionan los workers

Un worker es el programa que ejecuta las operaciones personalizadas (custom) contra a3ERP. La API solo encola la petición; quien hace el trabajo de verdad es el worker. Esta página explica el modelo y cómo se opera; cada worker concreto tiene su propia página bajo esta misma sección.

Qué hace un worker#

• Vigila la cola de tareas de la API.
• Cuando aparece una tarea que le corresponde, la ejecuta en a3ERP y deja el resultado.
• La aplicación recupera ese resultado consultando la tarea (/api/task/{nº}).

Por qué es un programa aparte#

a3ERP solo permite operar a través de su componente a3ERP ActiveX (NAX) (el módulo con el que a3ERP deja que otros programas actúen sobre él), y obliga a usar programas de 32 bits que trabajan en monohilo (solo puede gestionar una tarea detrás de otra, no hay multitasking). Esa lógica no puede vivir dentro de la API, así que se saca a estos procesos externos, que atienden las tareas de una en una. De ahí que las operaciones custom sean asíncronas (encolar → procesar → consultar).

Estándar y a medida#

• Estándar — workers reutilizables. El de referencia es la API estándar para a3ERP (Sit.a3ERP.Dispatcher), con las operaciones habituales de gestión (pedidos, albaranes, facturas, clientes, artículos…).
• A medida — workers hechos para un cliente concreto.

Cada worker se documenta en su propia subsección dentro de Workers y dispatchers.

Dónde vive y cómo se ejecuta#

Cada worker va en su propia subcarpeta dentro de C:\SIT\Services\Sit_a3ERP_Api\Dispatchers\ (por ejemplo, Dispatchers\Sit.a3ERP.Dispatcher).

No es un servicio de Windows: se arranca con una tarea programada que lanza el .exe del worker. Al crear la tarea, en su acción hay dos campos que importan:

• Programa o script — la ruta del ejecutable del worker, dentro de su subcarpeta.
• «Iniciar en (opcional)» — la carpeta del worker. Es el campo que más se olvida y el que más problemas da.

Además:

• El usuario con el que corre la tarea necesita permisos sobre la carpeta de instalación y C:\Logs (que es donde normalmente loguean nuestras aplicaciones).
• Parámetros de arranque (en «Agregar argumentos (opcional)»): ver documentación de cada worker. Normalmente, aunque no siempre, -auto (sin ventana de consola; lo normal en producción) y -fifo (procesa en estricto orden de llegada).

Desencadenadores#

En Desencadenadores, crea dos para que el worker esté siempre arriba:

• Al iniciar el sistema.
• Diariamente, a las 7:00 (o a una hora que se sepa que el servidor está levantado).

Configuración#

En la pestaña Configuración de la tarea:

• Desmarca «Detener la tarea si se ejecuta durante más de:».
• Marca «Permitir que la tarea se ejecute a petición».
• Marca «Ejecutar tarea lo antes posible si no hubo inicio programado».
• Marca «Si la tarea no se ejecuta, reiniciarla cada 1 minuto» e «Intentar el reinicio un máximo de 3 veces».
• Marca «Detener la tarea en ejecución si no finaliza cuando se solicite».
• En «Aplicar la siguiente regla si la tarea ya está en ejecución», elige «No iniciar una instancia nueva».

La identidad del worker: el UserId#

Cada worker se autentica ante la API con el UserId de un usuario y solo procesa las tareas de los usuarios que tiene asignados. Ese UserId se da de alta en la pantalla de Configuración de la API (ver Usuarios y permisos) y se le facilita a quien configura el worker.

Esto tiene una consecuencia importante: cada worker (cada tarea programada) abre una única sesión en a3ERP, con las credenciales de su usuario. Por eso, si necesitas exponer dos usuarios de API que se conectan a bases de datos (empresas) distintas, un solo worker no basta. Hace falta:

• una subcarpeta de worker adicional (por ejemplo, Sit.a3ERP.Dispatcher2),
• una tarea programada adicional que la ejecute, y
• un usuario de a3ERP distinto, con su propia licencia NAX.

Si una operación custom no responde#

Comprobaciones rápidas (más detalle en Solución de problemas):

• ¿Está el worker en marcha? (revisa la tarea programada)
• ¿Tiene el UserId correcto, el del usuario que encoló la petición?
• ¿Coincide el dispatcher del extremo con el del worker?