Cómo ejecutar el optimizador de una ocurrencia
Calcula disposiciones propuestas para una ocurrencia de servicio y permite revisar soluciones con métricas, desdobles y asignaciones sugeridas antes de tocar las mesas guardadas.
En este artículo
El optimizador trabaja sobre una ocurrencia completa de servicio. Antylogic usa el plano, las mesas, las combinaciones, las reservas activas y las asignaciones existentes para proponer distribuciones alternativas.
En Marea Gran Via, el responsable abre el Servicio de comidas Gran Via, entra en Configuraciones y lanza Disposiciones propuestas. La acción calcula o recupera un `OptimizationRunSummary`; no aplica cambios definitivos por sí sola.
Antes de empezar
- Trabajar con sesión iniciada en Grupo Marea Demo y Marea Gran Via, o en un contexto operativo equivalente con `orgId` y `locationId` activos.
- Abrir una ocurrencia existente de un evento de tipo `service` dentro de la ubicación activa.
- La ocurrencia debe tener `layout_id` y `optimization_config_id` resolubles.
- La ubicación debe tener habilitado `reservation-automatic:use`.
- Para ver el botón Configuraciones en la pantalla actual, el usuario necesita `reservation:manage` en la ubicación.
- El entorno debe tener configurado el optimizador externo mediante `optimization.BaseURL`, salvo que vaya a reutilizar una caché fresh válida.
Instrucciones
- 1.
Abre el detalle del servicio
Desde el calendario de reservas o desde `/:orgId/:locationId/reservations/:occurrenceId`, abre la ocurrencia de servicio que quieres optimizar. En el demo ES, el caso preparado usa Marea Gran Via y `BOOKING_SOLUTIONS_OCCURRENCE_ID`.
- 2.
Comprueba Configuraciones
Localiza el botón Configuraciones en el detalle. La pantalla puede cargar con permisos de vista, pero este menú solo queda disponible para lanzar la acción cuando el usuario tiene `reservation:manage`.
- 3.
Selecciona Disposiciones propuestas
Pulsa Configuraciones y elige Disposiciones propuestas. La app comprueba que exista `occurrenceId` y que la ocurrencia tenga `optimization_config_id` antes de llamar al optimizador.
- 4.
Espera el cálculo o la caché
Si el modo es manual, la caché no está fresh o falta `optimization_last_run_id`, la app envía `{ force: true }`. Si hay caché fresh, envía `{ force: false }` y el backend puede devolver el run persistido sin llamar otra vez al motor externo.
- 5.
Revisa las soluciones
Cuando la respuesta incluye soluciones, se abre el modal Disposiciones propuestas. Revisa score, objetivo, desdobles y asignaciones sugeridas por reserva antes de decidir si quieres previsualizar alguna alternativa.
- 6.
No lo trates como guardado definitivo
Ejecutar el optimizador no crea, edita ni cancela reservas, y tampoco persiste asignaciones de mesas. Precargar en cronograma solo lleva una propuesta al trabajo temporal; guardar mesas pertenece al flujo posterior de asignaciones.
Validaciones y límites
- `POST /api/app/{orgId}/{locationId}/service-occurrences/{occurrenceId}/optimization/runs` acepta body vacío o `{ force: boolean }`; no hay más campos implementados en `OptimizationRunRequest`.
- Un JSON inválido responde `400 payload invalido`; un método distinto de `POST` responde `405 metodo no permitido`.
- La ocurrencia debe pertenecer a la ubicación activa y a un evento de tipo `service`; una ocurrencia de otra ubicación se trata como no encontrada.
- El backend acepta cualquiera de `optimization:view`, `reservation:manage` u `optimization:manage`, y además exige `reservation-automatic:use`. La UI actual, sin embargo, solo expone el menú con `reservation:manage`.
- El plano debe existir en la misma ubicación, la configuración de optimización debe existir y sus settings deben poder parsearse.
- Con caché fresh, `OptimizationLastRunID` válido y `force=false`, el backend devuelve el resumen existente. Con `force=true` o caché inválida, crea un nuevo `service_occurrence_optimization_run` con trigger `manual_request`.
- Si no hay soluciones, la UI muestra `No se han encontrado soluciones aplicables para este servicio` y no abre el modal.
- Si `optimization.BaseURL` no está configurado, la acción falla con estado inválido. Si `Optimize` o `Completed` falla, el run queda `failed` y la caché, `failed`; la ocurrencia solo pasa a modo manual (`optimize_failed`) si el fallo es determinista (400, 401 o una respuesta que el backend no puede interpretar). Con 422 `infeasible` o con un fallo transitorio (503, 500, red o plazo agotado) el modo no cambia.
- No documentar `POST /optimization/runs/{runId}/apply` como parte visible de esta pantalla; el flujo observado precarga en cronograma y guarda por asignaciones en otro paso.
Resultado esperado
El responsable ve propuestas de distribución para el servicio, con métricas y asignaciones revisables, mientras las reservas y mesas persistidas permanecen intactas hasta que se use un flujo posterior de asignación.