Uma resposta de integração pode reunir muitos campos em uma única linha do log, com o horário e o marcador na frente e os caracteres especiais escapados. A estrutura está ali, mas o resultado, os itens e o motivo de uma recusa ficam difíceis de achar, e a leitura depende de extrair a mensagem inteira, formatá-la em uma cópia e manter o original para a conferência.
A extração da mensagem
O conteúdo da mensagem é separado do prefixo do log, como o horário, o componente e o marcador Enviado ou Recebido. Uma linha como esta traz o prefixo e o JSON juntos:
2026-10-01 14:32:05.611 -03:00 [caixa 01] operacao=OP-0031 tentativa=1 Recebido: HTTP=200 {"autorizado":false,"motivo":"Produto nao coberto"}
Só o trecho que vai da primeira chave até a última segue para o formatador, porque uma linha com o prefixo não é um documento JSON válido. A formatação acontece em uma cópia ou em uma visualização em árvore, e, nas mensagens com dados de clientes ou credenciais, as ferramentas locais evitam colar o conteúdo em sites de terceiros.
No JSON, os espaços e as quebras entre os elementos da estrutura mudam só a apresentação, e os espaços dentro de um texto entre aspas fazem parte do valor. No XML, os recuos acrescentados podem criar espaços que contam no conteúdo e invalidar uma assinatura digital. A cópia formatada serve para a leitura, e a mensagem original continua sendo a evidência, principalmente no XML assinado.
Os caracteres escapados
Dentro de um texto JSON, algumas sequências representam caracteres especiais:
\": as aspas;\n: a quebra de linha;ç: o caractere ç.
Alguns programas gravam a mensagem inteira como um texto dentro de outro registro, e o JSON aparece com todas as aspas escapadas, como em "conteudo":"{\"id\":1}". A leitura interpreta primeiro o JSON externo e, se o contrato indicar um JSON nesse campo, interpreta e formata o texto interno à parte. A remoção manual de todas as barras pode alterar o valor.
Os conteúdos codificados e as mensagens incompletas
Um texto longo pode estar em Base64, a forma de representar bytes como texto, como os de um PDF, de um XML ou de uma imagem. A aparência e um sinal de igual no fim são pistas, e não uma identificação, e o campo e o contrato confirmam o formato.
Quando a formatação falha, a primeira suspeita é a extração: o trecho pode ter ficado sem uma parte da mensagem, com o prefixo do log ou com o conteúdo escapado dentro de outro campo. O registro também pode ter sido cortado por um limite de tamanho do log ou conter uma mensagem malformada. A presença da última chave ou da última tag de fechamento não basta para validar a estrutura inteira.
A estrutura legível e o resultado
Três verificações diferentes se aplicam à mensagem:
- se o conteúdo pode ser interpretado como JSON ou como XML;
- se ele segue o layout ou o schema exigido;
- se ele informa o resultado esperado da operação.
Um JSON com {"autorizado":"false"} é bem formado, mas traz um texto, enquanto {"autorizado":false} traz um valor lógico, e a integração pode aceitar só um desses tipos. Uma lista vazia, um valor nulo e um campo ausente também são situações diferentes, e o contrato define o significado de cada uma.
Os nomes repetidos dentro do mesmo objeto JSON merecem atenção. Os programas que leem a mensagem podem recusá-la ou ficar com um só dos valores. Se o log tem dois campos status no mesmo objeto e a árvore mostra um só, o texto preservado mostra o que chegou, e o comportamento do programa que leu a mensagem define o estado considerado. A formatação ajuda a enxergar, mas não resolve uma ambiguidade do conteúdo.
No suporte
Diante de uma mensagem em uma linha só, convém extrair o conteúdo completo, sem o prefixo, e formatar uma cópia. O resultado técnico, o resultado de negócio e os campos da operação são localizados na mensagem inteira, e o original continua preservado para a conferência.
Para guardar
- O prefixo do log fica fora do trecho que vai para o formatador.
- A cópia formatada serve para a leitura, e o original continua sendo a evidência.
- Os caracteres escapados e o JSON guardado como texto pedem uma interpretação em etapas.
- Uma falha de formatação pode vir da extração, de um corte no log ou de uma mensagem malformada.
- A estrutura legível não confirma o tipo dos valores, o schema nem o resultado da operação.
O formatador recusa o trecho copiado do log. A mensagem do fornecedor está malformada?
Não necessariamente. O trecho pode conter o prefixo do log, pode ter perdido o fim da mensagem por um limite de tamanho ou pode trazer o JSON escapado dentro de outro campo. A extração é conferida primeiro, e só depois a falha pode ser atribuída ao conteúdo recebido.
A árvore do formatador mostra um único campo status, mas o texto da linha tem dois campos status no mesmo objeto. Qual valor o programa recebeu?
O formatador não responde a essa pergunta. Com nomes repetidos, cada leitor pode recusar a mensagem ou ficar com um dos valores, e o texto preservado mostra os dois. O comportamento do programa que leu a mensagem, e não o do formatador, define o estado considerado.