Identificar producto e instalación
Manhattan incluye distintas soluciones. Registre edición, versión, extensiones, interfaces disponibles y funciones asumidas por WMS/WES. La documentación Active describe orquestación de automatización, pero no demuestra que toda instalación exponga un endpoint determinado.
Mapee recepción, almacenaje, picking y expedición por separado. Defina creación, modificación y evidencia de conclusión de tareas. La integración ABNET WCS debe respetar ese contrato sin duplicar reglas de inventario.
Referencia técnica: Manhattan — Integrated Automation & Robotics.
Identidad estable
Especifique identificadores de tarea, carga, mensaje y correlación, campos obligatorios, unidades y compatibilidad de versiones. Cambiar prioridad no crea otra tarea; retransmitir no debe generar otro movimiento.
Acknowledgement de transporte, aceptación de negocio y conclusión física son hechos diferentes. Conserve eventos pendientes para recuperar confirmaciones después de una caída.
Retry y excepciones operativas
Reintente fallos transitorios con límites, espaciado y control de volumen. Un destino inválido exige corrección. La cola de excepciones necesita responsable, diagnóstico y reenvío que preserve identidad.
Compare tareas abiertas en ambos sistemas con posición física conocida. Igualar contadores de mensajes no detecta una confirmación asociada a la carga incorrecta. Distinga progreso parcial de conclusión.
Ejemplo de timeout
El WCS entrega C31 y envía E91. El WMS lo procesa, pero se pierde su respuesta. Repetir E91 no debe generar otro movimiento de inventario. Una actualización tardía tras la conclusión debe rechazarse o compensarse según contrato, sin reabrir silenciosamente la ejecución.
La aceptación incluye indisponibilidad prolongada, eventos desordenados y recuperación de colas. Derive latencia y caudal del flujo contratado; cifras de demostración no dimensionan producción.
Antes de la API: acordar autoridad funcional
Registre producto Manhattan, versión, extensiones, autenticación, límites y entornos. Por flujo, identifique qué crea la tarea, quién decide destino y qué punto físico permite concluir. WMS, WES, WCS y control local no corresponden necesariamente a servidores separados.
El documento de interfaz cubre ejecución nominal, cancelación, prioridad, progreso parcial y recuperación. Asigne responsables en ambos extremos y validación de cambios. Una conexión activa puede transportar una interpretación incorrecta de carga o destino.
Contrato ilustrativo: mensaje no es tarea
Este JSON es un ejemplo didáctico. No es una API oficial Manhattan ni un formato publicado de ABNET WCS. Sus conceptos deben mapearse a la interfaz disponible en el proyecto.
messageId identifica entrega lógica; taskId, operación física; taskVersion, cambio autorizado. correlationId relaciona comandos y eventos. La clave de deduplicación necesita ámbito suficiente, como emisor e instalación, para evitar colisiones.
{
"schemaVersion": "example-1",
"messageId": "MSG-0091",
"taskId": "T42",
"taskVersion": 1,
"correlationId": "FLOW-018",
"loadId": "C18",
"source": "IN-01",
"destination": "S3",
"intent": "MOVE"
}| Elemento | Regla que definir | Fallo evitado |
|---|---|---|
| Identidad y ámbito | Unicidad, retención y reinicio | Reejecutar trabajo antiguo al perder historial. |
| Versión de tarea | Cambiar solo en versión y fase permitidas | Prioridad antigua sobrescribe decisión reciente. |
| Carga y direcciones | Validar existencia, formato y mapeo | Mover carga correcta al destino incorrecto. |
| Resultado | Separar recibido, aceptado, ejecutando y completado | Registrar inventario antes de entrega física. |
Tres confirmaciones diferentes
Recepción de transporte, aceptación de negocio y conclusión física deben distinguirse en registros e interfaz. El transporte puede confirmar antes de validar destino. Una tarea aceptada puede esperar capacidad sin fallo de comunicación.
Manhattan → WCS
Solicitar T42 con carga, destino y versión.
Canal → emisor
Confirmar recepción del protocolo sin inferir ejecución.
WCS → Manhattan
Aceptar tras validar y registrar, o rechazar con motivo.
WCS ↔ equipo
Reservar, enviar comando y seguir carga.
WCS → Manhattan
Publicar entrega demostrada con identidad estable.
Manhattan → integración
Confirmar procesamiento o permitir conciliación.
Si se pierde la respuesta final, repetir evento no debe repetir inventario. La retención de deduplicación cubre la ventana de replay acordada.
Orden, timeout y excepciones operativas
Ordene operaciones dependientes, como cambios de una tarea. Evite una cola global si tareas independientes pueden avanzar en paralelo. Una versión futura antes de su predecesora requiere espera, consulta o rechazo diagnosticable acordado. Un timestamp no establece causalidad por sí solo.
Limite reintentos transitorios y aplique espaciado progresivo con variación para evitar oleadas sincronizadas. El rechazo de contenido exige corrección, no retry infinito. La cola de excepciones necesita responsable, contexto y reenvío auditado. Corregir contenido con la misma identidad puede interpretarse como duplicado; defina identidad válida para versiones corregidas.
| Incidencia | Acción de referencia | Evitar |
|---|---|---|
| Respuesta perdida tras aceptar | Consultar T42 o repetir idempotentemente | Crear T43 solo porque hubo timeout. |
| Destino inválido | Rechazar con código y contexto; corregir autorizadamente | Repetir contenido inválido indefinidamente. |
| Cancelar tras movimiento | Evaluar compromiso físico y compensación | Borrar tarea mientras la carga sigue en tránsito. |
| Conclusión repetida | Devolver resultado ya aplicado | Registrar otro movimiento de inventario. |
Matriz mínima de aceptación
El ensayo demuestra integridad de negocio y ejecución, no solo conectividad. Use tareas identificables, estado inicial conocido y registros correlacionados. Carga y recuperación se derivan de requisitos operativos acordados.
Al terminar, concilie tareas aceptadas, cargas entregadas y resultados WMS. Toda diferencia se explica por rechazo, cancelación o excepción abierta. Un panel sin alarmas no sustituye conciliación.
| Escenario | Resultado esperado | Evidencia |
|---|---|---|
| Duplicar solicitud | Una tarea física y respuestas coherentes | taskId, deduplicación y trayectoria. |
| Perder confirmación final | Recuperar notificación sin nueva ejecución | Evento original y un resultado WMS. |
| Invertir actualizaciones | Versión antigua no sobrescribe nueva | Versiones, decisión y estado final. |
| Reiniciar ejecutando | Recuperar o bloquear para conciliación | Estado persistido, observación y decisión. |
| Interrumpir y restaurar canal | Drenar dentro del límite acordado | Edad de colas, caudal útil y pendientes. |
Criterios de verificación del proyecto
- Confirmar edición, interfaz disponible y autoridad.
- Perder la respuesta después de procesar y comprobar deduplicación.
- Conciliar tareas abiertas tras una caída prolongada.
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.