En un entorno empresarial real, los ordenadores del almacén o de administración se apagan al terminar la jornada (19:00 PM), los fines de semana se interrumpe el suministro eléctrico en el polígono industrial y las líneas de fibra sufren microcortes transitorios. La arquitectura Store-and-Forward (Almacenar y Reenviar) de Bentian ERP Bridge es el patrón de ingeniería distribuida diseñado para garantizar que ningún pedido web se pierda jamás, independientemente del estado físico del hardware local.
1. La Realidad Operativa: El PC del Almacén se Apaga
Los conectores síncronos tradicionales cometen el error crítico de intentar escribir directamente en el ERP en el mismo milisegundo en que el cliente pulsa "Finalizar compra" en el checkout web. Si en ese instante:
- El ordenador del almacén está apagado por ser domingo por la tarde o festivo,
- Un operario ha reiniciado el switch o router de la red de área local (LAN), o
- La línea de Internet del almacén sufre un microcorte transitorio de DNS o fibra óptica,
el webhook síncrono del conector tradicional arroja un error 504 Gateway Timeout o Connection Refused. Como resultado, el pedido queda huérfano en la tienda online sin registrarse en Factusol, obligando a los administrativos a revisar albarán por albarán cada lunes por la mañana.
2. Delimitación Rigurosa del Ciclo de Vida en 4 Fases
Para solucionar este problema de raíz, Bentian divide el ciclo de vida del pedido en cuatro fases estrictamente delimitadas e independientes:
| Fase | Ubicación del Dato | Estado del Pedido | Garantía Operativa |
|---|---|---|---|
| Fase 1: Tienda Online | Base de Datos Web (Cloud / Hosting) | PENDING (En espera) | Retención inmutable en servidor web. Seguro aunque el PC esté apagado. |
| Fase 2: Descarga Agente | Canal Seguro HTTPS (TLS 1.3) | DOWNLOADING | Descarga automática al encender el PC o en ciclo programado de polling. |
| Fase 3: Custodia SQLite | %APPDATA%\Bentian Agent\queue.db | QUEUED (Custodiado) | Persistencia local con WAL mode. Cero pérdida ante caídas de red o bloqueos. |
| Fase 4: Inyección ERP | Factusol OLEDB (F_PCL / F_LPC) | SYNCED (Confirmado) | Transacción relacional atómica y confirmación ACK bidireccional a la web. |
3. Fase 1: Retención Inmutable en la Tienda Online (PC Apagado)
Durante la noche o durante el fin de semana, los clientes realizan compras en WooCommerce, PrestaShop o tu tienda personalizada. La tienda web procesa los pagos con tarjeta o transferencia y registra el pedido en su propia base de datos (tablas wp_posts / HPOS _wc_orders en WordPress, ps_orders en PrestaShop, o eb_orders en el Endpoint Universal) marcando su estado como PENDING o processing.
En este punto, la tienda web actúa como el primer buffer de retención. No requiere que el ordenador del almacén esté encendido ni que la base de datos de Factusol esté accesible. La información del pedido, las direcciones de envío y los totales fiscales están perfectamente seguros en el servidor web.
4. Fase 2: Recuperación Automática por el Agente (Arranque y Polling)
Cuando el personal del almacén enciende el ordenador o el servidor local, el agente de Bentian se inicia automáticamente como servicio o proceso en segundo plano con Windows. Inmediatamente ejecuta su ciclo de sondeo (*polling*) saliente mediante peticiones HTTPS autenticadas:
- Detección secuencial: Consulta la API de la tienda solicitando todos los pedidos con estado
PENDING. - Descarga en bloques seguros: Recupera los pedidos en lotes controlados (de 50 en 50, máx. 200) para no sobrecargar el servidor web ni la memoria local.
- Validación sintáctica: Verifica la integridad del JSON entrante (cabecera, cliente, NIF/CIF y líneas con precios sin IVA y tipos impositivos).
5. Fase 3: Custodia en Cola Local SQLite (Modo WAL)
En cuanto los pedidos se descargan por HTTPS, el agente NO intenta grabarlos directamente en Factusol. Los inserta de inmediato en su motor local transaccional SQLite:
Este almacenamiento se configura en modo Write-Ahead Logging (WAL) (PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL), garantizando:
- Inmunidad ante caídas de Internet: Si la fibra óptica se corta un segundo después de descargar el pedido, el dato ya reside en el disco NVMe/SSD local. No se perderá aunque el almacén quede incomunicado.
- Inmunidad ante caídas de la tienda web: Si el servidor de la tienda online sufre un reinicio o mantenimiento en la nube, el agente puede seguir trabajando con los pedidos ya custodiados.
- Concurrencia libre de bloqueos: El modo WAL permite lecturas continuas desde la interfaz gráfica del agente mientras el motor de sincronización escribe pedidos en disco sin cuellos de botella.
6. Fase 4: Inyección Atómica en Factusol y Confirmación ACK
Con el pedido custodiado en SQLite, el motor LocalSyncEngine procede a su inyección en la base de datos de Factusol (.accdb):
- Apertura de Transacción OLEDB: Se inicia una transacción atómica agrupada (
BeginTrans) en el motor OLEDB de 32 bits de Microsoft ACE. - Resolución de Cliente: Se busca la ficha del cliente por CIF/NIF en
F_CLI. Si no existe, se crea automáticamente una nueva ficha con su código de provincia, tarifa y datos de contacto. - Inserción de Cabecera (F_PCL): Se obtiene el siguiente número correlativo disponible para la serie seleccionada (ej. serie "1" o "W") y se inserta el registro del pedido con sus totales netos, brutos y fecha.
- Inserción de Líneas (F_LPC): Se insertan secuencialmente todas las líneas de productos con sus códigos de artículo (
ARTLPC), descripción, cantidad, precio unitario sin IVA y porcentaje de recargo si procede. - Commit Transaccional: Si todas las líneas se escriben correctamente, se ejecuta
CommitTrans. Si ocurriera cualquier error, se ejecutaRollbackTrans, dejando Factusol intacto. - Confirmación ACK a la Tienda Online: Tras el commit exitoso, el agente envía una llamada de confirmación (flujo ACK) a la tienda web, informando del número de pedido asignado por Factusol y marcando el pedido web como SYNCED.
7. Tolerancia a Bloqueos (.laccdb) y Reintentos Exponenciales
¿Qué ocurre si un operario del almacén está realizando un balance contable, una regeneración de stock o una copia de seguridad en Factusol y bloquea la tabla en modo exclusivo (error 3045 / Could not use; file already in use)?
Un conector síncrono colapsaría. Bentian, en cambio, mantiene el pedido en estado PENDING_INJECTION en su cola SQLite y aplica un algoritmo de retroceso exponencial (*exponential backoff*) con jitter aleatorio:
En cuanto el operario termina su tarea en Factusol y el archivo .laccdb se desbloquea, el agente inserta los pedidos de la cola de forma ordenada y cronológica en cuestión de milisegundos.
8. Garantía de Entrega e Idempotencia Extremo a Extremo
La cola SQLite local incorpora una restricción de unicidad primaria sobre el identificador original del pedido web (web_order_id). Esta salvaguarda garantiza la propiedad de idempotencia estricta:
- Fallo de red durante el ACK: Si el agente inyecta el pedido en Factusol pero la llamada de confirmación ACK a la tienda online falla por un timeout de red, la tienda web mantendrá el pedido como
PENDING. En el siguiente ciclo de polling, la tienda volverá a enviar el mismo pedido al agente. - Detección de duplicado en SQLite: El agente detecta que el
web_order_idya existe en su cola local en estadoSYNCEDcon su número de Factusol asignado. El agente jamás reinserta el pedido en Factusol, evitando duplicaciones de albarán o descuadres de inventario. En su lugar, reenvía inmediatamente la confirmación ACK a la tienda web para sincronizar su estado.