6.3 KiB
Operação da reposição periódica do SGC
Estado desta entrega
O comando, a recuperação durável, o diagnóstico e a exclusão de execuções locais estão implementados. Este documento não instala uma tarefa Windows nem comprova arranque após reinício. A configuração do cliente e o ensaio de reinício continuam a fazer parte da instalação.
Preparação da instalação
Confirmar a composição SGC, a ligação à base da instalação, as migrações e a parametrização aprovada de artigos/armazéns. A conta técnica do sistema operativo precisa de ler a aplicação e de escrever em storage e bootstrap/cache; isso não lhe concede perfil funcional no SGC. Não transportar credenciais do auxiliar de avaliação para um cliente.
No Agendador de Tarefas Windows, preparar uma tarefa recorrente a cada minuto, com execução mesmo sem uma sessão interactiva. Usar o executável PHP aprovado para a instalação, o argumento artisan sgc:replenishment-tick e a pasta da aplicação como directório inicial. Configurar a tarefa para não iniciar outra instância enquanto a anterior estiver em execução. Seleccionar a conta técnica e as suas credenciais no momento da instalação; não as gravar no repositório. Ainda não foi criada essa tarefa neste desenvolvimento.
O comando específico evita iniciar tarefas não relacionadas com reposição. O limite de lote vem da configuração existente ou de --limit=1..500; não altera a quantidade de compra. Cada trabalho conserva na base a próxima data de avaliação, tentativas e sinal pendente. A frequência técnica não é prazo de aprovação nem autorização de compra.
Concorrência e recuperação
O comando usa storage/framework/replenishment-command.lock, partilhado por chamadas manuais, auxiliar de avaliação e agendador nesta instalação local. A posse é mantida pelo sistema operativo até terminar o comando; não tem uma validade que possa expirar durante uma avaliação demorada. Uma segunda chamada não descobre nem processa trabalhos, não altera o último acompanhamento e devolve código de insucesso com mensagem de execução em curso.
O bloqueio é libertado no final, em excepção ou quando o sistema operativo termina o processo. O ficheiro pode permanecer no disco: a sua existência não significa que esteja bloqueado. Não o apagar durante uma execução. Numa instalação com vários servidores e armazenamento não partilhado, este bloqueio local não constitui exclusão distribuída; esse cenário exige validação própria. As transacções e o controlo durável por empresa/trabalho continuam a proteger as compras independentemente deste controlo de processo.
Depois de uma interrupção, a próxima execução recupera os sinais duráveis e reavalia as origens existentes. Uma transacção interrompida não deve deixar um rascunho parcial; uma compra já ligada à necessidade é reutilizada. Não apagar sinais ou repetir aprovações para forçar recuperação. Consultar as pendências e as mensagens técnicas quando existirem falhas sucessivas.
Conferência pelo responsável
Verificação técnica sem processar reposições
Na pasta e ambiente já validados da instalação, php artisan sgc:replenishment-health consulta o estado; php artisan sgc:replenishment-health --json devolve dados estruturados. Código de saída 0 significa passagem recente confirmada para esta instalação, composição/esquema disponíveis e ausência de sinais pendentes/trabalhos falhados observados; 1 requer atenção. Não descobre origens, não drena trabalhos, não cria rascunhos e não actualiza a passagem observada. Usa a ligação configurada do operador técnico e não inicia sessão em nome de uma pessoa.
JSON inclui momento da consulta, resultado, motivos, última passagem e contagens técnicas agregadas. Não inclui empresas, pessoas, artigos, mensagens privadas de trabalhos ou credenciais. Motivos possíveis: not_installed, not_recent, last_run_not_successful, unbound_observation, pending_signals, failed_work ou unavailable. Sinais pendentes podem ser transitórios entre passagens; o comando não atribui prioridade nem prazo de aprovação. A existência de regras válidas, responsáveis e configuração empresarial é conferida no diagnóstico funcional próprio, não certificada por este resultado técnico.
Passagens nativas novas guardam uma associação por hash da pasta/composição/ligação à base, sem nomes de bases, caminhos ou credenciais no ficheiro. A leitura recusa uma associação diferente. Registos antigos sem associação continuam legíveis na interface para compatibilidade, mas não permitem sucesso na nova verificação de saúde. Apenas uma passagem real do comando de reposição grava a associação; consultar a saúde não a fabrica. Este hash evita confusão de contextos, não é assinatura ou certificado contra um administrador do servidor.
As mesmas fontes de observação e contagem são reutilizadas no ecrã. A interface continua limitada à empresa do utilizador, incluindo utilizadores sem empresa; a agregação técnica global só é permitida em consola sem identidade interactiva ou sessão HTTP. Não foi instalado um monitor recorrente, tarefa de arranque ou serviço Windows. Continuam necessários os ensaios de instalação/reinício e a validação operacional do cliente.
Em Reposição e no diagnóstico do piloto, verificar a passagem recente, o resultado e os trabalhos ainda a recuperar. replenishment-command-status.json é observação técnica, não documento de compra. Um estado antigo, danificado ou ausente não prova que o serviço esteja activo; uma passagem bem sucedida também não garante execução futura. Uma terminação abrupta pode deixar a última observação até esta perder actualidade.
No ensaio de instalação, comprovar passagem sem utilizador ligado, reinício do serviço/máquina, recuperação da pendência e ausência de duplicações, usando dados sintéticos autorizados. Conservar os resultados e os registos protegidos segundo a política do cliente. Não confundir a passagem do auxiliar local com aceitação comercial ou instalação concluída.
O serviço prepara e recupera necessidades/rascunhos segundo a configuração existente. Não submete decisões humanas, selecciona fornecedores, emite encomendas ou movimenta stock em substituição dos percursos aprovados.