feat(api): proxy del Service Layer con registro de recursos

El frontend envía parámetros OData y cuerpo; el backend valida y ejecuta.

- GET lista/por clave, POST y PATCH sobre /api/sl/:recurso, solo para
  recursos registrados (ventas, compras, inventario y maestros estándar);
  EmployeesInfo no se registra nunca (contiene U_WEB_PASS).
- Permisos de menú por recurso (lectura/escritura); catálogos de consulta
  abiertos a cualquier sesión. Evaluador de patrones compartible
  (/inventario/* ya no habilita /inventario-x).
- Parámetros OData validados con lista cerrada, $top máx. 500, $expand solo
  si el recurso lo declara, claves validadas y escapadas por tipo, cabeceras
  B1S-* con lista blanca. $inlinecount y B1S-PageSize automáticos.
- configureApp() compartido entre main.ts y e2e (prefijo y límite de 5 mb).
- Verificado contra SAP real: los 27 recursos existen; listado con total,
  filtro, paginación y claves. InventoryRequests no existe en el SL: se
  registra InventoryTransferRequests.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This commit is contained in:
GeorgeandClaude Sonnet 5.5 committed 2026-10-13 19:04:52 -05:00
1 parent 73fffee2f7
commit c0990ca83e
15 files changed
+683 -6

No files matched your search

+21
View File
@@ -54,3 +54,24 @@ Se guardan en SQLite (`SQLITE_PATH`, por defecto `./data/app.sqlite`, fuera del
- El sistema no deja quitar el acceso total al último administrador (409).
- El esquema se sincroniza automáticamente (`synchronize`); pasar a migraciones cuando se estabilice por cliente.
- Si `better-sqlite3` falla al instalar en una máquina nueva: `npm rebuild better-sqlite3`.
## Proxy del Service Layer (`/api/sl`)
El frontend arma los parámetros OData y el cuerpo; el backend solo valida y ejecuta (sesión SAP, cola, reintento y errores incluidos). El frontend envía el **nombre del recurso**, nunca la URL.
| Llamada | Descripción |
|---|---|
| `GET /api/sl/:recurso?$select&$filter&$orderby&$top&$skip` | Lista. Devuelve `value` y `odata.count`. `$top` por defecto 50, máx. 500. |
| `GET /api/sl/:recurso/:clave?$select` | Un registro. La clave se valida y escapa según su tipo. |
| `POST /api/sl/:recurso` | Crea; devuelve lo que responde SAP (ej. `DocEntry`, `DocNum`). |
| `PATCH /api/sl/:recurso/:clave` | Modifica (204). |
Reglas:
- **Solo recursos registrados** en `src/sl/sl-resources.ts`; el resto es 404. Nunca registrar `EmployeesInfo` (contiene `U_WEB_PASS`).
- Cada recurso declara clave, métodos y la ruta de menú que gobierna lectura/escritura. Los catálogos de consulta (`Items`, `Warehouses`...) se leen con cualquier sesión.
- Parámetros OData fuera de la lista (`$apply`...) → 400. `$expand` solo si el recurso declara qué colecciones admite.
- Cabeceras B1S-* permitidas: `B1S-ReplaceCollectionsOnPatch` (PATCH), `B1S-CaseInsensitive` y `B1S-PageSize` (GET). Se fijan solas: `B1S-PageSize` = `$top` y `B1S-CaseInsensitive` si hay `$filter`.
- No hay DELETE ni acciones (`Cancel`, `Close`); se agregan por recurso cuando haga falta.
- Las escrituras dejan una línea `AUDIT <usuario> <método> <recurso>` en el log.
Agregar un recurso nuevo = una línea en `SL_RESOURCES`. El test en vivo (`SAP_LIVE=1 npm run test:e2e`) comprueba que todos existan en el Service Layer del cliente.