Explore o fluxo
Uma ordem. Quatro momentos.
Selecione uma etapa para acompanhar a troca entre os sistemas e o movimento da carga.
1 / 4 · WMS
Ordem
O WMS informa o que precisa acontecer: qual carga movimentar e qual é o destino solicitado.
Exemplo didático de fluxo lógico. Interfaces e responsabilidades são definidas por projeto.
Separar política de transporte
Uma arquitetura WCS pode organizar cinco responsabilidades: entrada de tarefas, decisão de fluxo, persistência de estados, adaptação aos equipamentos e supervisão. Essa é uma decomposição lógica; não exige cinco serviços ou servidores. Separar processos aumenta isolamento, mas também introduz mensagens, latência e falhas distribuídas. A escolha deve considerar volume, disponibilidade e capacidade da equipe de operação.
O núcleo de fluxo trabalha com tarefas e recursos. Um adaptador traduz esse modelo para o contrato de um equipamento. Manter endereços de tags e códigos específicos no adaptador reduz o impacto de uma substituição de controlador, mas não elimina diferenças físicas ou de semântica entre máquinas.
Persistência nas fronteiras de decisão
Uma decisão que precisa sobreviver a uma reinicialização deve ser registrada antes de ser considerada aceita. Ao atualizar a tarefa e publicar um evento, duas operações independentes criam uma janela de perda. Uma opção de projeto é persistir estado e intenção de publicação na mesma transação, enviando o evento depois e tolerando repetição no consumidor.
O custo é manter fila, retenção e recuperação do publicador. A promessa de entrega não resolve sozinha a execução física: um comando pode ser executado e sua confirmação perdida. Por isso, o protocolo do equipamento precisa permitir identificar a solicitação ou reconciliar seu resultado.
Observabilidade e autoridade
Cada log relevante deve relacionar tarefa, carga, recurso e mensagem. Relógios sincronizados ajudam a investigar, mas a ordem causal deve usar sequências e relações explícitas; timestamps de máquinas diferentes podem divergir. Monitore idade da fila e qualidade da comunicação além de CPU e memória.
Em uma arquitetura redundante, apenas a instância autorizada pode comandar um recurso. A troca de líder precisa invalidar a autoridade anterior. Um painel saudável não demonstra que o sistema consegue assumir essa autoridade de modo seguro.
Exemplo: falha após persistir
A tarefa é registrada, mas o processo cai antes de enviar o comando. Após reiniciar, a intenção pendente é recuperada. Se a queda ocorreu depois do envio, o sistema verifica o estado reconhecido pelo equipamento antes de reenviar. Os dois casos parecem iguais no banco se o contrato não guardar informação suficiente.
Valide cada janela com falhas injetadas. Registre a sequência esperada, o resultado físico observado e o estado final. Essa evidência é mais útil do que afirmar genericamente que a arquitetura é escalável ou resiliente.
Matriz de autoridade: quem pode decidir e quem confirma
A integração começa por uma matriz de autoridade. Para cada decisão, registre o componente que pode alterá-la, a evidência exigida e o comportamento se a informação estiver indisponível. A tabela é uma divisão de referência: um MFC separado pode assumir funções do núcleo WCS, desde que não existam dois proprietários concorrentes.
| Decisão | Autoridade de referência | Evidência e limite |
|---|---|---|
| Destino de negócio e prioridade | WMS / orquestração acordada | Pedido e restrições válidos; não autoriza ultrapassar um intertravamento. |
| Admissão e reserva de capacidade | Coordenação de fluxo WCS/MFC | Ocupação mais cargas reservadas; a mesma vaga não pode ser prometida duas vezes. |
| Movimento local | Controlador do equipamento | Handshake, modo e intertravamentos; segurança permanece na arquitetura da máquina. |
| Conclusão logística | WCS informa; WMS registra o efeito de negócio | Identidade da carga e entrega no ponto acordado, não somente comando enviado. |
| Correção de divergência | Procedimento operacional autorizado | Operador, motivo e evidência; preservar a tarefa e os eventos originais. |
Máquina de estados e invariantes de execução
Estados precisam representar conhecimento, não apenas a última mensagem recebida. No exemplo, ACCEPTED exige registro durável; EXECUTING exige evidência do equipamento; COMPLETED exige a entrega acordada. RECONCILING preserva a incerteza quando não é possível determinar o resultado.
As invariantes a testar são: uma identidade de carga não pode ter duas execuções incompatíveis; uma reserva não pode ser consumida por duas tarefas; um evento antigo não pode regredir um estado concluído; um retry deve preservar a identidade da operação. Uma nova intenção de negócio exige outra versão ou outra tarefa, conforme contrato.
| Estado | Condição de entrada | Próxima decisão |
|---|---|---|
| ACCEPTED | Tarefa validada e persistida | Aguardar capacidade ou rejeitar alteração incompatível. |
| RESERVED | Recurso e destino reservados | Publicar comando com identidade estável. |
| EXECUTING | Equipamento reconhece execução | Aguardar resultado; cancelamento pode precisar de compensação. |
| COMPLETED | Entrega comprovada e registrada | Publicar confirmação pendente; não repetir movimento. |
| RECONCILING | Timeout ou evidência contraditória | Consultar estado e posição; nenhuma conclusão por suposição. |
Sequência nominal com fronteiras de persistência
Este fluxo lógico é ilustrativo; não representa endpoints ou protocolos do produto. As setas mostram relações causais, não a topologia física. O estado da tarefa e a intenção de publicar o próximo evento podem ser gravados na mesma transação local. O envio ocorre depois, com recuperação das intenções pendentes.
WMS → WCS
Enviar T42 / C18 / destino S3 com versão da tarefa.
WCS → persistência
Validar e registrar a tarefa antes de devolver aceite.
WCS → coordenação de capacidade
Reservar S3 considerando ocupação e cargas em trânsito.
WCS → adaptador → equipamento
Enviar comando com identidade estável; registrar o resultado reconhecido.
Equipamento → WCS
Informar progresso e evidência de entrega de C18.
WCS → persistência → WMS
Registrar conclusão e intenção de notificação; reenviar a notificação se necessário.
A confirmação perdida cria incerteza sobre a comunicação, não prova de que o movimento falhou. Recuperar a mensagem e repetir a ação física são operações diferentes.
Quatro janelas de falha que precisam de ensaio
Persistência e troca de mensagens não constituem uma transação única com o mundo físico. Por isso, teste as fronteiras em que software e equipamento podem divergir. A retomada só deve liberar comandos quando a autoridade e o estado forem coerentes.
| Falha injetada | Comportamento esperado | Evidência de aceite |
|---|---|---|
| Após persistir, antes de enviar | Recuperar intenção pendente sem criar outra tarefa | Uma T42, um comando lógico e histórico preservado. |
| Após executar, antes de confirmar | Consultar sequência e posição; conciliar se ambíguo | Nenhum segundo movimento causado pelo timeout. |
| Após concluir, antes de avisar WMS | Reenviar evento com a mesma identidade | Um efeito de negócio, mesmo recebendo o evento duas vezes. |
| Perda de comunicação do líder | Invalidar autoridade antiga antes da retomada | A instância anterior não consegue comandar o recurso. |
Dimensionar filas sem transferir o gargalo
Uma fila absorve diferenças temporárias de ritmo, mas precisa de limite de retenção e controle de entrada. No exemplo de dimensionamento, chegam 120 tarefas/min e a execução sustenta 100 tarefas/min durante dez minutos: acumulam-se 200 tarefas. Quando a chegada cai para 80/min, a capacidade líquida para drenar é 20/min, exigindo mais dez minutos sob essas hipóteses.
O cálculo ignora variação de mix, bloqueios e tarefas inelegíveis; use-o como verificação inicial, não garantia de throughput. Meça idade da tarefa mais antiga, percentis de espera, ocupação física e reservas. Aumentar consumidores de software não aumenta automaticamente a capacidade mecânica.
O aceite deve especificar perfil de carga, duração, indisponibilidades previstas e tempo máximo de recuperação do atraso. Registre também quais funções podem continuar quando WMS, banco ou um adaptador ficam indisponíveis. Assim, disponibilidade passa a ser uma propriedade verificável do fluxo.
Referência: Microsoft — Queue-Based Load Leveling.
Critérios para verificar no projeto
- Desenhar os limites de transação e as janelas de falha.
- Verificar reprocessamento de eventos sem duplicar movimentos.
- Garantir que apenas uma instância tenha autoridade de comando.
Os exemplos descrevem decisões de engenharia e cenários de teste. Interfaces, limites e recursos implantados são definidos no escopo de cada projeto.