Workers y dispatchers / API estándar para a3ERP
Puesta en marcha
El despliegue de este worker sigue el procedimiento general de todos los workers (carpeta propia, tarea programada con el campo «Iniciar en», usuario de a3ERP con licencia NAX…), detallado en Cómo funcionan los workers. Aquí solo se recogen las particularidades de la API estándar para a3ERP.
Dónde se instala#
En su propia subcarpeta dentro de la instalación de la API:
C:\SIT\Services\Sit_a3ERP_Api\Dispatchers\Sit.a3ERP.Dispatcher\
Fichero de configuración#
El worker lee su configuración de un fichero appsettings.json en su propia carpeta. El valor que hay que ajustar en la puesta en marcha es:
UsuarioAPI— el identificador del usuario de API con el que el worker se autentica. Es la pieza clave: determina qué peticiones recoge de la cola y, a través de ese usuario, la empresa de a3ERP y las credenciales con las que entra. Se da de alta en la pantalla de Configuración de la API (ver Usuarios y permisos) y se copia aquí.
La conexión a SQL Server no está en este fichero: el worker la toma del Configuracion.json compartido con la API, en la raíz de la instalación (C:\SIT\Services\Sit_a3ERP_Api\Configuracion.json). Por eso el worker debe vivir dentro de la instalación de la API (y por eso importa el campo «Iniciar en» de la tarea, ver Cómo funcionan los workers).
Un UsuarioAPI por worker
Cada worker procesa solo las peticiones del UsuarioAPI que tenga configurado. Si dos workers comparten el mismo UsuarioAPI, se pelearían por las mismas tareas. Para exponer otra empresa, otro worker con otro UsuarioAPI (ver el aviso sobre la licencia NAX más abajo).
Argumentos de arranque#
En la acción de la tarea programada, en «Agregar argumentos (opcional)», lo habitual para este worker es:
-auto— sin ventana de consola (lo normal en producción).-fifo— procesa las peticiones en estricto orden de llegada.
Familias que atiende#
Este worker responde a los dispatchers Clientes, Proveedores, Personas, Articulos, Pedidos, Albaranes, Facturas y Auxiliares. Cualquier extremo custom que quieras exponer debe usar uno de esos nombres de dispatcher y una de las operaciones del Catálogo de operaciones.
Alta de los endpoints#
En la primera instalación hay que cargar los extremos de la API (la tabla Endpoints): tanto los de consulta como los de escritura. El procedimiento y el script semilla están en Instalación de endpoints.
Diccionario de extensibilidad#
Las consultas (endpoints GET) no las resuelve el worker: las resuelve la API a partir de las vistas y procedimientos que el módulo instala en el diccionario de extensibilidad de a3ERP. Por eso, para que las consultas funcionen, hay que instalar el diccionario en cada empresa de a3ERP cuyos datos se expongan (con el instalador del diccionario; ver el proyecto Sit.API.a3ERP). Si una empresa no tiene el diccionario instalado, sus consultas fallarán aunque el worker esté perfectamente configurado.
Además, el diccionario está acoplado a una versión concreta: hay que tener instalada la versión que indique la entrega del módulo. Si no coincide, algunas consultas pueden fallar. Verifica la versión compatible en las notas de la entrega antes de actualizar el módulo o el diccionario.
Una sesión de a3ERP por worker
Como cualquier worker, esta API estándar abre una sesión de a3ERP con su usuario y consume una licencia NAX mientras está en marcha. Si necesitas atender dos empresas (bases de datos) distintas a la vez, hace falta un segundo worker con su propia tarea y su propio usuario de a3ERP con licencia. El detalle está en Cómo funcionan los workers.