APRENDER. PRATICAR. EVOLUIR.Quatro perguntas sobre a mesma mudança
Uma investigação de encaminhamento começa por separar quatro perguntas: o que foi aprovado, o que foi copiado, o que o processo carregou e o que aconteceu ao pedido. Cada pergunta precisa de evidência própria. Na oficina, dois frontends recebem um ficheiro com a nova URI de relatórios. A cópia do norte coincide com o artefacto aprovado; a do sul diverge. Isso orienta a investigação, mas não prova que o norte carregou o ficheiro. Regista a identidade do frontend, o caminho configurado, a hora, a versão e o pedido de teste. Evita escrever apenas “plugin atualizado”, porque essa frase esconde etapas que podem ter resultados diferentes.
Inspeção local de artefactos
O laboratório incluído cria ficheiros temporários originais e lê-os com ElementTree. O parser rejeita XML malformado, mas aceita sintaxe que pode conter referências sem destino. Por isso, um segundo passo inventaria nomes e verifica as referências do subconjunto definido. Um Route que refere missing-uri sem grupo correspondente aparece no relatório. A verificação também deteta nomes duplicados antes de os converter num dicionário, evitando que uma entrada esconda outra. Este script não conhece todo o schema IBM, não executa matching de wildcards e não carrega um plugin. Usa-o para praticar inspeção e limites da evidência, não como autorização de deployment.
Digest, conteúdo e caminho efetivo
Um digest responde a uma pergunta sobre bytes. Se duas cópias têm SHA-256 diferente, investiga a diferença; se têm o mesmo valor, ainda precisas de confirmar a origem esperada e o uso pelo processo. No exercício, acrescentar quebras de linha muda o digest sem mudar os campos selecionados pelo inventário. Isso não demonstra equivalência completa, porque o inventário ignora outros atributos. A comparação útil liga o ficheiro ao caminho realmente configurado e à identidade que o lê. A documentação do plugin explica que condições de reload dependem do mecanismo em uso. Não deduzas adoção apenas da hora da cópia nem uses um restart geral como substituto da identificação do caminho.
Experiência controlada pelo percurso afetado
Num portal fictício de fundos, compara o mesmo relatório através dos dois frontends, com parâmetros, identidade e momento suficientemente semelhantes. Se só o sul falha e lhe falta uma URI presente na configuração aprovada, a propagação é uma hipótese concreta. Confirma também o host e a porta observados, porque testar 8443 não é automaticamente equivalente a testar 443. O laboratório compara apenas literais e identifica essa diferença; a interpretação real exige a configuração completa. Se uma cache responder antes do plugin, o conteúdo antigo pode persistir sem nova execução na JVM. Localiza quem respondeu antes de repetir deployments ou alterar pools de ligações.
Interpretar tempos sem inventar uma causa
Os access logs WAS podem distinguir o tempo total HTTP e o tempo de serviço até ao primeiro byte. Na fixture, %D vale 900000 e %{R}W vale 120000 microssegundos: são 900 ms e 120 ms. O segundo valor está incluído no primeiro, pelo que não os somas. A diferença de 780 ms orienta investigação do restante envio, incluindo cliente e intermediários, mas não mede diretamente SQL. A heurística tem limites quando há streaming ou flush intermédio. Regista formato, unidades e comportamento da resposta antes de comparar. Usa identificadores controlados e uma janela temporal útil, evitando anexar cookies ou credenciais a tickets de acesso amplo.
Guião de diagnóstico e passagem à equipa
Executa o laboratório local, identifica a cópia divergente e explica por que motivo um XML legível pode continuar incoerente. Depois prepara um registo com hipótese, evidência que a suporta, evidência em falta e próximo passo reversível. Na situação fictícia, a ação é corrigir a propagação no âmbito aprovado e confirmar adoção e resposta pelo sul. Desviar tudo para o norte só é uma mitigação aceitável depois de avaliar capacidade e continuidade. No handover, inclui critérios de sucesso, monitorização, responsáveis e forma de regressar ao estado anterior. Resume separadamente o que o laboratório demonstrou e os testes que ainda exigem um ambiente WebSphere autorizado.
# LOCAL ARTIFACT LAB: original fixtures; no WebSphere process
python3 content/labs/was-routing/run.py
# front-b.xml differs; /reports/* absent from selected inventory
# XML parsing != IBM schema validation != runtime adoption
# Synthetic timing: 900000 us total; 120000 us service; difference 780 msO norte tem a cópia aprovada e o sul não inclui /reports/*. A comparação local identifica a divergência; a resolução exige confirmar carregamento e um pedido pelo sul.
Armadilhas comuns
Confundir parsing com validação IBM; ignorar duplicados; tratar digest como prova de carregamento; somar tempos incluídos; divulgar cookies no ticket.
Tópicos relacionados: Topologia e configuração · Deployment e encaminhamento · JVM e diagnóstico
Liga artefacto, cópia, processo e pedido. Indica sempre o âmbito do teste e a observação que falta antes de declarar o percurso recuperado.
Referência: WAS Webserver Plug-in FAQ · DR WebSphere traditional ND 9.0.5; maintenance baseline 9.0.5.29 (2026-09-08); documentation reviewed 2026-09-30