Dinaup DocsAutomatizaciones del servidor
El trabajo que el servidor de tu empresa ejecuta en segundo plano: peticiones programadas, webhooks, control horario, propagaciones, proyectos, reparaciones y archivado del histórico.
El servidor de tu empresa ejecuta trabajo en segundo plano sin que nadie lo lance: llama a las URL programadas, envía los webhooks, mantiene los turnos y repara datos. Una parte la configuras tú; el resto corre sin configuración.
Cómo se ejecuta
El planificador reparte los componentes en grupos y arranca un hilo por grupo. Cada hilo recorre sus componentes en orden y vuelve a empezar tras una pausa de al menos 150 milisegundos. Cada componente guarda su propia fecha de próxima ejecución y sale sin hacer nada en el resto de vueltas.
| Situación | Qué ocurre |
|---|---|
| Un componente falla | El error queda en el log como tick.failed y el hilo sigue con el siguiente componente. |
| Un componente tarda más de 100 milisegundos | La ejecución queda registrada en la actividad de componentes del servidor. |
| La base de datos está en solo lectura | Solo corren la comprobación de PostgreSQL, el mantenimiento de conexiones y el envío a Redis. |
| El servidor está en pausa | Solo corre el envío a Redis. |
| Varias instancias del servidor | Los componentes que salen hacia fuera o escriben datos derivados están marcados como exclusivos de la instancia activa. |
Dinaup puede apagar un componente concreto de una licencia con la marca [disable-cmp-<componente>- en la configuración del servidor.
Lo que configuras tú
Peticiones HTTP programadas
Componente HTTPCron. Cada 10 segundos lee los registros activos de la sección HTTP CRON y lanza los que corresponden según su intervalo y su horario. Campos, intervalos, resultado y avisos por correo: Programar peticiones HTTP.
Webhooks salientes
Componente OutgoingWebhooks. Vacía la cola de avisos pendientes hacia las URL que configuraste. Condiciones de disparo, cuerpo, cadencia y reintentos: Webhooks salientes. El ajuste disablewebhookssalientes del servidor apaga el encolado y el envío de toda la licencia; Dinaup lo usa en copias de desarrollo para no disparar webhooks de producción.
En la misma vuelta salen los correos de tu empresa: la cola de correo, el resumen diario de errores de la API y el Recap semanal.
Control horario
Componente EmployeeWorkingHoursUpdate. Pasa una vez por minuto y hace, en este orden:
| Paso | Qué hace |
|---|---|
| Cierre de fichajes abiertos | Cada 10 minutos busca fichajes en curso sin hora de salida de los últimos 90 días, hasta 500. Si el día tenía turnos, cierra pasado el margen de cierre del empleado (240 minutos por defecto) y pone como salida el fin del plan. Sin turnos ese día, cierra 12 horas después de la entrada. |
| Descansos vencidos | Cierra los descansos que han agotado su duración. |
| Horarios y turnos | Asigna a cada empleado el horario que le corresponde y genera los turnos del día en la primera pasada tras la medianoche local del empleado. Si borras los turnos del día, los vuelve a generar en la siguiente pasada. |
| Ausencias | Propaga las ausencias laborales a los turnos afectados, con un barrido de respaldo por si la cola se perdió en un reinicio. |
| Cobertura | Deriva el estado de cada turno a partir de los fichajes: Programada, EsperandoInicio, EnCurso, Presente o Ausencia. |
Dónde ficha el equipo: Kiosco. Qué guarda cada jornada y cómo se descarga: El registro de jornada.
Lo que corre sin configuración
| Componente | Cada | Qué hace |
|---|---|---|
RetainedMonitoringPropagator | 2 segundos | Reparte los lotes de cambios a los servicios que los escuchan: webhooks, Redis, PG Sync y las derivaciones. |
RelatedDataPropagationCalculate y RelatedDataPropagationFlush | 60 segundos | Propaga un cambio en un dato maestro a los registros que copian su valor. |
SalesSchedule | 2 a 20 minutos | Repara el estado de las ventas de los últimos 30 días sustituidas por una rectificativa y genera los movimientos de inventario de venta que falten. |
PurchasesSchedule | 5 a 20 minutos | Repara el estado de las compras sustituidas por una rectificativa. |
AccountingMaintenance | 15 minutos | Revisa el estado de los ejercicios contables a partir de los asientos y repara los eliminados repercutidos en las secciones incrustadas. |
FixData | 10 minutos | Reparaciones de datos: cumplimiento de tipos de venta, campo sin factura, stock por almacén, sección del documento en firmas, tokens de URL de aplicaciones, cuentas contables de entidades y fecha de operación desde contabilidad. |
HistoricalArchive | Una vez al día, entre las 02:00 y las 05:59 UTC | Mueve el histórico de cambios de más de 3 días de _historicos_h a _historicos_archivado_h. No se borra nada: las filas cambian de tabla. |
ProjectsMaintance | Cuando hay cambios en cola | Recalcula los proyectos de la app Tareas y las dependencias entre sus tareas. Ver Proyectos. |
FilesSetLastVersion | 10 minutos | Repara la última versión de los archivos cuando cambió la tabla de imágenes. |
PGSyncSync | Cada vuelta | Actualización rápida de PG Sync. Ver PG Sync. |
RedisSendData | Cada vuelta | Publica los cambios y el estado en tu Redis. Ver Eventos Redis. |
FlushLogAPI | 15 segundos | Vuelca a la sección Uso API el consumo de la API por minuto: peticiones, errores, duraciones y bytes por clave API, función y app. El uso desde Play no cuenta. Ver Plataforma y sistema. |
El resto de componentes (PostgreHealthCheck, PGConnectionsMaintance, SessionMaintenance, DiskCleanup, MemoryCompaction, RemoteConfigSync, APIHealthCheck, SharedMetrics, PublicFileMaintance y PublicTableSummarySave) cuidan la salud de la propia instancia: conexiones, sesiones, disco, memoria, configuración remota y métricas.
Relacionado
- Programar peticiones HTTP: la tarea programada que sí configuras.
- Webhooks salientes: el aviso por evento.
- Eventos Redis: el mismo aviso en tu Redis.