Explore el flujo
Una orden. Cuatro etapas.
Seleccione una etapa para seguir el intercambio entre sistemas y el movimiento de la carga.
1 / 4 · WMS
Orden
El WMS indica qué debe suceder: qué carga mover y cuál es el destino solicitado.
Ejemplo didáctico de flujo lógico. Las interfaces y responsabilidades se definen por proyecto.
Separar política y transporte
Una arquitectura puede distinguir entrada de tareas, decisiones de flujo, persistencia, adaptación a equipos y supervisión. Son responsabilidades lógicas, no cinco servicios obligatorios. Separar procesos mejora aislamiento, pero añade mensajería y fallos distribuidos. Elija fronteras según carga y capacidad operativa.
Los adaptadores traducen tareas y recursos al contrato del equipo. Aislar direcciones de tags y códigos reduce impacto de cambios, pero no elimina diferencias físicas o semánticas entre máquinas.
Persistir decisiones recuperables
Registre una tarea antes de considerarla aceptada. Actualizar estado y publicar un evento por separado crea una ventana de pérdida. Una opción registra estado e intención de publicación en la misma transacción y después envía el evento a consumidores tolerantes a duplicados.
Esto requiere retención y recuperación de la cola. Las garantías de entrega no resuelven la incertidumbre física: un comando puede ejecutarse y perderse su respuesta. El contrato del equipo necesita identificación o conciliación.
Observabilidad y autoridad
Vincule registros con tarea, carga, recurso y mensaje. Sincronizar relojes ayuda, pero la causalidad también necesita secuencias explícitas. Mida antigüedad de colas y calidad de comunicación, además de CPU.
Solo una instancia autorizada debe comandar cada recurso. El cambio de líder debe invalidar la autoridad anterior en la frontera efectiva del comando. Un panel saludable no demuestra failover correcto.
Ejemplo de fallo
La tarea se persiste y el proceso cae antes de enviar. La recuperación encuentra la intención pendiente. Si cayó después del envío, debe consultar el estado del equipo antes de repetir. Sin evidencia suficiente, ambos casos pueden parecer iguales en la base.
Inyecte fallos en cada frontera. Registre secuencia esperada, resultado físico y estado final. Esa evidencia vale más que afirmar genéricamente que la arquitectura es resiliente.
Matriz de autoridad: decisión y evidencia
Comience por una matriz de autoridad. Para cada decisión, indique quién puede cambiarla, qué evidencia necesita y qué ocurre si falta información. Es una división de referencia: un MFC separado puede asumir funciones de flujo, siempre que no haya propietarios competidores.
| Decisión | Autoridad de referencia | Evidencia y límite |
|---|---|---|
| Destino de negocio y prioridad | WMS / orquestación acordada | Demanda y restricciones válidas; no permite superar interbloqueos. |
| Admisión y reserva | Coordinación WCS/MFC | Ocupación más reservas en tránsito; una plaza no se promete dos veces. |
| Movimiento local | Controlador del equipo | Handshake, modo e interbloqueos; seguridad en arquitectura de máquina. |
| Conclusión logística | WCS informa; WMS registra efecto | Identidad y entrega en el punto acordado, no solo comando enviado. |
| Corrección de divergencia | Procedimiento operativo autorizado | Operador, motivo y evidencia; conservar tarea y eventos originales. |
Máquina de estados e invariantes
Los estados representan conocimiento, no solo el último mensaje. En este ejemplo ACCEPTED exige registro duradero; EXECUTING, evidencia del equipo; COMPLETED, entrega acordada. RECONCILING conserva la incertidumbre cuando no puede establecerse el resultado.
Compruebe estas invariantes: una carga no admite ejecuciones concurrentes incompatibles; dos tareas no consumen la misma reserva; un evento antiguo no hace retroceder un estado concluido; un retry conserva identidad. Una nueva intención de negocio necesita otra tarea o versión autorizada según contrato.
| Estado | Condición de entrada | Siguiente decisión |
|---|---|---|
| ACCEPTED | Tarea validada y persistida | Esperar capacidad o rechazar cambio incompatible. |
| RESERVED | Recurso y destino reservados | Publicar comando con identidad estable. |
| EXECUTING | Equipo reconoce ejecución | Esperar resultado; cancelar puede exigir compensación. |
| COMPLETED | Entrega demostrada y registrada | Publicar confirmación pendiente; no repetir movimiento. |
| RECONCILING | Timeout o evidencia contradictoria | Consultar estado y posición; no suponer conclusión. |
Secuencia nominal y persistencia
Este flujo lógico ilustrativo no especifica endpoints ni protocolos del producto. Las flechas representan causalidad, no topología de red. Estado e intención de publicar el siguiente evento pueden registrarse en una transacción local. El envío sucede después, recuperando intenciones pendientes si es necesario.
WMS → WCS
Enviar T42 / C18 / destino S3 y versión.
WCS → persistencia
Validar y registrar antes de aceptar.
WCS → capacidad
Reservar S3 considerando ocupación y tránsito.
WCS → adaptador → equipo
Enviar identidad estable y registrar resultado reconocido.
Equipo → WCS
Informar progreso y evidencia de entrega C18.
WCS → persistencia → WMS
Registrar conclusión e intención de notificar; reenviar notificación si procede.
Perder confirmación crea incertidumbre de comunicación, no demuestra fallo físico. Recuperar mensaje y repetir movimiento son operaciones diferentes.
Cuatro ventanas de fallo para ensayar
Persistencia y mensajería no forman una transacción única con el mundo físico. Pruebe fronteras donde software y equipo pueden divergir. Reanude comandos solo con autoridad y estado coherentes.
| Fallo inyectado | Comportamiento esperado | Evidencia de aceptación |
|---|---|---|
| Después de persistir, antes de enviar | Recuperar intención sin otra tarea | Una T42, un comando lógico e historial conservado. |
| Después de ejecutar, antes de confirmar | Consultar secuencia y posición; conciliar ambigüedad | Ningún segundo movimiento por timeout. |
| Después de concluir, antes de avisar WMS | Reenviar evento con la misma identidad | Un efecto de negocio aunque llegue dos veces. |
| Pérdida de comunicación del líder | Invalidar autoridad anterior antes de continuar | La instancia antigua no comanda el recurso. |
Dimensionar colas sin trasladar el cuello de botella
Una cola absorbe diferencias temporales de ritmo, pero necesita retención limitada y control de admisión. Ejemplo: llegan 120 tareas/min y se ejecutan 100/min durante diez minutos; se acumulan 200. Si luego llegan 80/min, quedan 20/min para drenar: otros diez minutos bajo esas hipótesis.
El cálculo ignora mix, bloqueos y tareas inelegibles. Úselo como comprobación inicial, no garantía. Mida edad de la tarea más antigua, percentiles de espera, ocupación física y reservas. Más consumidores de software no aumentan automáticamente capacidad mecánica.
La aceptación define perfil, duración, indisponibilidades y tiempo máximo de recuperación. Registre qué funciones continúan sin WMS, base o adaptador. Así, disponibilidad se convierte en propiedad verificable del flujo.
Referencia: Microsoft — Queue-Based Load Leveling.
Criterios de verificación del proyecto
- Dibujar transacciones y ventanas de fallo.
- Reprocesar eventos sin duplicar movimientos.
- Demostrar una única autoridad de comando por recurso.
Los ejemplos describen decisiones de ingeniería y escenarios de prueba. Interfaces, límites y funciones implantadas se definen en el alcance de cada proyecto.