Contents

Introdução

Visão geral do recurso

Limitações

Ferramenta HAR Sanitizer

Histórico

Estado atual

Como extrair o HARLog

Gerar um arquivo HAR no navegador

Informações úteis antes de analisar registros HAR

Métodos HTTP

Explicação das Colunas

Anatomia de um registro HAR

Cabeçalhos

Cabeçalhos comuns de solicitação

Cabeçalhos comuns de resposta

Carga útil

Onde a Carga Útil Aparece nos Logs HAR

Visualização

Resposta

Iniciador

Cronometragem

Troubleshooting

Ferramenta interna para Exibir Logs HAR

GeralEtapas de solução de problemas

Exemplo de solução de problemas de tíquetes

Elementos de carregamento lento

Explicação das fases de divisão do tempo

Recurso não disponível

O serviço faz uma solicitação (GET) para conhecer os serviços do usuário

Não é possível ativar um recurso

Mensagens de FAX

Informações de encaminhamento

Introdução

Este documento descreve o entendimento e a solução de problemas de registros HAR.

Visão geral do recurso

Um HAR Log (abreviação de HTTP Archive Logging) é um log de toda a atividade de rede entre seu navegador e um site durante uma sessão específica.

Quando você visita um site, seu navegador envia solicitações ao servidor e recebe respostas. O arquivo HAR captura todas essas solicitações, respostas e informações de tempo.

Eles são essenciais para diagnosticar problemas de desempenho da Web, solucionar problemas de erros de rede e analisar transações de API.

Os registros HAR ajudam a identificar recursos de carregamento lento, solicitações com falha e a rastrear interações do usuário com aplicativos da Web.

Limitações

- Os arquivos HAR podem ser grandes e difíceis de serem analisados manualmente.

- Os dados confidenciais podem ser registrados; garantir a limpeza de dados antes do compartilhamento.

- Algumas políticas de segurança podem bloquear a captura HAR completa.

Caution: O arquivo HAR inclui todo o conteúdo das solicitações e respostas em texto claro (incluindo senhas, ID de sessão, cookies, etc). Portanto, você não deve compartilhar um arquivo HAR capturado em uma sessão com um serviço disponível publicamente. Se a guia Rede foi aberta quando uma senha foi inserida, ela está em texto claro no arquivo HAR. Você deseja remover essas credenciais antes de compartilhar o arquivo HAR. Abra o arquivo HAR salvo em um editor de texto, localize a senha e substitua-a por um texto aleatório como "". Não modifique a formatação JSON do arquivo enquanto estiver fazendo essa alteração, pois ela não será analisada corretamente para revisão.

Ferramenta HAR Sanitizer

Histórico

Em 2023, Okta teve uma violação de segurança em que os arquivos HAR foram roubados de seus sistemas de gerenciamento de casos de suporte. Os invasores usaram o token de acesso e cookies desses arquivos para obter acesso às contas de seus clientes. Em resposta, o Okta implementou uma ferramenta de limpeza.

Estado atual

Atualmente, há uma automação em andamento que tenta remover os materiais confidenciais dos traçados, mas deixa o restante intacto para preservar a capacidade de solucionar problemas e analisar seu problema.

Quando você carrega um arquivo HAR, a ferramenta automaticamente:

1. Detecta que um arquivo HAR foi carregado

2. Limpa o arquivo HAR usando https://har-sanitize.cisco.com

3. Carrega o arquivo limpo no gabinete

4. Criptografa o arquivo HAR original usando o GPG

5. Carrega o arquivo HAR criptografado para o caso

6. Exclui o arquivo HAR original do caso

7. Adiciona uma nota explicando o caso e um link para esta ferramenta

Note: Se você não puder resolver o problema usando a versão saneada do arquivo HAR, poderá arquivar uma exceção, conforme explicado nas próximas seções, e obter uma cópia do arquivo HAR original de volta.

Como extrair o registro HAR

Gerar um arquivo HAR no navegador

Consulte: Gere um arquivo HAR em seu navegador.

Extraia do documento:

- Cromo:

Abra Developer Tools (F12) > Guia Network (Rede) > Preserve Log (Preservar registro) > Start Recording (Iniciar gravação) > Reduce Issue (Reproduzir problema) > Export HAR File (Exportar arquivo HAR).

- Firefox

Abra Developer Tools (F12) > Guia Rede > Ícone Mecanismo > Marque "Persist Logs" > Iniciar Gravação > Salvar HAR.

Informações úteis antes de analisar registros HAR

Métodos HTTP

Os métodos HTTP (também conhecidos como verbos HTTP) definem o tipo de operação que um cliente deseja executar em um determinado recurso (como dados ou uma página da Web).

Cada método tem um propósito e uma semântica específicos.

Os métodos HTTP mais comuns são: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS e TRACE.

Método

Solicitações

Idempotente

Uso Típico

Corpo da solicitação

Corpo da resposta

GET

Yes

Yes

Recuperar dados

No

Yes

POST

No

No

Criar recurso/enviar dados

Yes

Yes

PUT

No

Yes

Substituir recurso

Yes

Yes

PATCH

No

Sim*

Atualizar parcialmente o recurso

Yes

Yes

DELETE

No

Yes

Remover recurso

No

Opcional

TÍTULO

Yes

Yes

Recuperar cabeçalhos

No

No

OPÇÕES

Yes

Yes

Descobrir métodos/recursos

No

Opcional

RASTREAR

Yes

Yes

Teste de diagnóstico

No

Yes

* O PATCH é geralmente idempotente, mas depende da implementação.

Explicação das Colunas

- Seguro: Indica se o método HTTP é considerado seguro, o que significa que ele não modifica recursos ou o estado do servidor. Os métodos seguros destinam-se apenas à recuperação, não à realização de alterações. Eles são geralmente usados para operações somente leitura.

- Idempotent: Especifica se repetir a mesma solicitação HTTP várias vezes tem o mesmo efeito que fazê-la uma vez. Um método idempotent significa que, não importa quantas vezes a solicitação seja repetida, o resultado permanecerá inalterado (após a primeira solicitação bem-sucedida)

- Uso Típico: Descreve o objetivo ou cenário comum para o qual o método HTTP é usado. Isso fornece contexto para quando e por que você usaria cada método no desenvolvimento da Web ou no design de API.

- Corpo da Solicitação: Indica se a solicitação HTTP normalmente inclui um corpo (dados enviados ao servidor). O corpo da solicitação é frequentemente usado para enviar dados (como JSON, XML, dados de formulário) para o servidor, como ao criar ou atualizar recursos.

- Corpo da resposta: Especifica se a resposta HTTP geralmente contém um corpo (dados retornados pelo servidor). O corpo da resposta são os dados enviados de volta do servidor para o cliente, como o recurso solicitado, as mensagens de status ou a confirmação de uma ação.

Anatomia de um registro HAR

Note: Todas as imagens de exemplo nesta seção foram obtidas ao tentar carregar os locais no HUB de Controle para uma organização

Cabeçalhos

Captura metadados trocados entre o cliente (navegador) e o servidor durante solicitações e respostas HTTP.

Os cabeçalhos fornecem contexto sobre os dados que estão sendo enviados ou recebidos, como o tipo de conteúdo, informações de autenticação, políticas de cache e muito mais.

Os cabeçalhos estão incluídos nestas seções de um log HAR:

1. Cabeçalhos de solicitação: Eles são enviados do navegador (cliente) para o servidor como parte da solicitação HTTP.

2. Cabeçalhos de resposta: Eles são retornados pelo servidor para o navegador em resposta à solicitação.

Os cabeçalhos são armazenados como matrizes de pares chave-valor, onde:

- Chave: O nome do cabeçalho.

- Valor: O valor associado ao cabeçalho.

Cabeçalhos comuns de solicitação

1. Host: Especifica o nome de domínio do servidor (por exemplo, as example.com) e o número da porta.

- Exemplo: Host: www.example.com

2. Usuário-Agente: Identifica o navegador ou cliente que está fazendo a solicitação, juntamente com sua versão e sistema operacional.

- Exemplo: Usuário-agente: Mozilla/5.0 \(Windows NT 10.0; Win64; x64\)

3. Aceitar: Indica os tipos de conteúdo que o cliente pode manipular (como HTML, JSON, imagens).

- Exemplo: Aceitar: texto/html,aplicativo/xhtml+xml

4. Aceitar-Codificação: Especifica os tipos de codificação (como gzip, deflate) que o cliente pode decodificar.

- Exemplo: Aceitar-Codificação: gzip, deflate

5. Autorização: Contém credenciais para autenticação, como tokens ou credenciais de autenticação básica.

- Exemplo: Autorização: Portador <token>

6. Cookies: Inclui cookies enviados pelo cliente ao servidor.

- Exemplo: Cookie: sessionId=12345; userPref=darkMode

7. Tipo de conteúdo: Indica o tipo de dados que está sendo enviado no corpo da solicitação (para solicitações POST/PUT).

- Exemplo: Tipo de conteúdo: aplicativo/json

8. Referência: Identifica a URL da página que fez referência ao cliente para o recurso atual.

- Exemplo: Referência: https://www.example.com/

Cabeçalhos comuns de resposta

1.Tipo de conteúdo: Especifica o tipo MIME do recurso (como text/html, application/json).

- Exemplo: Tipo de conteúdo: aplicativo/json

2. Conteúdo-Comprimento: Indica o tamanho do corpo da resposta em bytes.

- Exemplo: Comprimento do conteúdo: 1234

3. Controle de Cache: Especifica as políticas de cache para o recurso (por exemplo, se ele pode ser armazenado em cache e por quanto tempo).

- Exemplo: Cache-Control: no-cache, no-store, must-revalidate

4. Servidor: Identifica o software/versão do servidor.

- Exemplo: Servidor: Apache/2.4.29

5. Set-Cookie: Contém cookies que o servidor deseja que o cliente armazene.

- Exemplo: Set-Cookie: sessionId=67890; Caminho=/; Seguro

6. Data: A data e a hora em que o servidor gerou a resposta.

- Exemplo: Data: Ter, 10 de outubro de 2023 12:00:00 GMT

7. Local: Usado em redirecionamentos, indicando a URL para a qual o cliente deve navegar.

- Exemplo: Local: https://www.example.com/new-page

8. ETag: Um identificador exclusivo do recurso, frequentemente usado para armazenamento em cache e controle de versão.

- Exemplo: ETag: 12345abcd

9. Codificação de conteúdo: Indica como o corpo da resposta é codificado (como gzip, deflate).

- Exemplo: Codificação de conteúdo: gzip

10. Controle de Acesso - Permitir-Origem: Especifica quais origens têm permissão para acessar recursos (usado no CORS).

- Exemplo: Access-Control-Allow-Origin: *

Note: O mais relevante para a chamada do Webex é o cabeçalho Trackingid, pois esse é o ID que você pode procurar na ferramenta LMA.

Carga útil

Dados enviados ou recebidos no corpo de uma solicitação ou resposta HTTP.

É mais comumente associado com solicitações POST, PUT ou PATCH, em que o cliente envia dados ao servidor, como envios de formulários, uploads de arquivos ou dados JSON para APIs.

O payload também pode existir em respostas HTTP, que contêm dados retornados pelo servidor, como HTML, JSON ou conteúdo binário (como imagens, arquivos).

Onde a Carga Útil Aparece nos Logs HAR

O Payload é normalmente encontrado em duas seções principais do registro HAR:

1. Carga de solicitação: Dados enviados do cliente (navegador) para o servidor no corpo de uma solicitação HTTP.

2. Carga de resposta: Dados retornados pelo servidor ao cliente no corpo de uma resposta HTTP.

Visualização

Faz parte do objeto response.content e fornece uma representação dos dados retornados pelo servidor em um formato estruturado e legível por humanos, se disponível.

A Visualização é normalmente usada para exibir dados analisados ou estruturados do corpo da resposta de uma forma amigável, como JSON, XML ou outros formatos.

Esta seção é particularmente útil para depurar APIs, inspecionar dados retornados ou entender a estrutura da resposta do servidor.

Resposta

A Resposta fornece informações detalhadas sobre a resposta HTTP enviada pelo servidor ao cliente (browser) para uma solicitação específica. Esta seção contém metadados, cabeçalhos, detalhes de conteúdo e outros dados críticos que podem ajudá-lo a entender o comportamento do servidor durante o ciclo de solicitação-resposta. Fornece um snapshot detalhado da resposta do servidor a uma solicitação HTTP.

Iniciador

O Iniciador fornece informações sobre o que disparou uma solicitação HTTP específica durante o carregamento de uma página da web. Ele identifica a origem ou a causa de uma solicitação de rede, ajudando os desenvolvedores a entenderem a cadeia de eventos que levou à solicitação. O iniciador também ajuda a rastrear a origem de uma solicitação e pode apontar para a linha exata de código ou recurso responsável por fazê-la.

Cronometragem

O tempo fornece um detalhamento dos vários estágios envolvidos no processamento de uma solicitação e resposta HTTP. Ele ajuda os desenvolvedores a entenderem quanto tempo leva cada etapa do ciclo de solicitação-resposta, desde o início da conexão até o recebimento da resposta final. O tempo também rastreia a sequência e a duração de eventos que ocorrem quando um navegador faz uma solicitação a um servidor e recebe uma resposta. Ele inclui métricas detalhadas para resolução DNS, estabelecimento da conexão, envio da solicitação, espera pela resposta do servidor e download dos dados de resposta.

Troubleshooting

Ferramenta interna para Exibir Logs HAR

Navegue para EasyLmaSearch > Importar arquivo HAR/Saz.

Etapas gerais de solução de problemas

1. Abra o arquivo HAR em um .

2. Identifique as solicitações com falha (como erros HTTP 4xx/5xx).

3. Verifique os tempos de resposta e os elementos de carregamento lento.

4. Analisar cabeçalhos de solicitação/resposta para problemas de autenticação e CORS.

5. Procure por IDs de rastreamento em solicitações de rede e .

6. Se possível, verifique as falhas em relação às respostas.

Exemplo de solução de problemas de tíquetes

Elementos de carregamento lento

Exemplo:

- O Control Hub está demorando muito para carregar os números de um local

Troubleshooting:

- Solicite um vídeo do problema (tentando carregar a página de números de um local)

- Solicitar um log HAR ao tentar carregar os números de um local

1. Abra o arquivo HAR no Visualizador HAR ou no navegador Ferramentas de Desenvolvimento.

2. Identificar a solicitação na Cachoeira exibir

3. Clique na Solicitação que está demorando a carregar.

4. Revise a guia Timing do registro:

5. Verifique os tempos de resposta e os elementos de carregamento lento.

6. Reúna o Trackingid para esse Cabeçalho.

7. Abra o EasyLMA e pesquise com o trackingid.

Explicação das fases de divisão do tempo

Aqui estão mais informações sobre cada uma das fases que você pode ver na guia Tempo:

- Enfileiramento. O navegador enfileira as solicitações antes do início da conexão e quando:

- Há solicitações de prioridade mais alta. A prioridade da solicitação é determinada por fatores como o tipo de um recurso, bem como sua localização no documento. Para obter mais informações, leia a seção de prioridade de recursos do guia de busca de prioridades.

- Já existem seis conexões TCP abertas para esta origem, que é o limite. (Aplicável somente a HTTP/1.0 e HTTP/1.1.)

- O navegador está alocando espaço brevemente no cache de disco.

- Parado. A solicitação pode ser interrompida após o início da conexão por qualquer um dos motivos descritos em Enfileiramento.

- Pesquisa DNS. O navegador está resolvendo o endereço IP da solicitação.

- Conexão inicial. O navegador está estabelecendo uma conexão, incluindo handshakes ou repetições de TCP e negociando um SSL.

- Negociação de proxy. O navegador está negociando a solicitação com um servidor proxy.

- Solicitação enviada. A solicitação está sendo enviada.

- Preparação do ServiceWorker. O navegador está inicializando o Service Worker.

- Solicitação ao ServiceWorker. A solicitação está sendo enviada ao trabalhador do serviço.

- Aguardando (TTFB). O navegador está aguardando o primeiro byte de uma resposta. TTFB significa Time To First Byte (Tempo até o primeiro byte). Esse tempo inclui 1 percurso de ida e volta de latência e o tempo que o servidor levou para preparar a resposta.

- Download de conteúdo. O navegador está recebendo a resposta, diretamente da rede ou de um operador de serviços. Esse valor é o tempo total gasto lendo o corpo da resposta. Valores maiores do que o esperado podem indicar uma rede lenta ou que o navegador está ocupado executando outro trabalho que atrasa a leitura da resposta.

Recurso não disponível

Exemplo:

"Habilitei o SNR para meu usuário no hub de controle de administração, mas não vejo a opção de configurar o número SNR quando faço login no portal user.webex.com.

Você poderia verificar minha organização e usuário para ver por que não consigo vê-los no hub do usuário?"

Troubleshooting:

1. Confirme o que o usuário está vendo solicitando uma captura de tela de um usuário em funcionamento versus um usuário que não está em funcionamento.

2. Solicite um registro HAR ao carregar as opções para o usuário.

Próximas etapas:

1. Abra o arquivo HAR no Visualizador HAR ou no navegador Ferramentas de Desenvolvimento.

2. Identificar solicitações:

O serviço faz uma solicitação (GET) para conhecer os serviços do usuário

Chamando a solicitação de Modelo de acesso a recursos do usuário final (GET) o modelo dos serviços que são mostrados ao usuário:

1. Analisar cabeçalhos de solicitação/resposta.

O "Sem acesso" significa que o modelo está ocultando essas opções para o usuário.

2. Você precisa revisar o modelo para a ORG e ativar o Alcance de número único para que o usuário possa vê-lo no Hub de usuário.

Exemplo:

Não é possível ativar um recurso

Exemplo com gravação de chamada:

Ao tentar ativar a gravação de chamada para um usuário, você recebe uma mensagem de erro: "Falha na alteração da gravação de chamada".

Para solucionar problemas:

1. Confirme o erro solicitando o texto completo da mensagem de erro.

2. Peça uma captura de tela do erro.

3. Solicite um registro HAR ao tentar habilitar a "Gravação de Chamada" no usuário afetado .

4. Abra o arquivo HAR no Visualizador HAR ou no navegador Ferramentas de Desenvolvimento.

5. Identifique as solicitações com falha (como erros HTTP 4xx/5xx).

6. Procure os IDs de rastreamento no EasyLMA.

7. Com a exceção de cpapi, você pode abrir um BEMS:

8. Abrir um BEMS com as informações recolhidas:

- Capturas de tela

- Mensagem de erro completa

- ID deAcompanhamento

- Exceção de cpapi

9. Peça ao espaço Dubber ou à equipe BU para revisar com a equipe Dubber o erro:

"Resumo da resposta de erro: 400 : Produto inválido: Falha na criação do ponto de duplicação em Dubber. Status HTTP: 502"

Mensagens de FAX

Aqui está o diagrama que ilustra o fluxo de provisionamento à medida que ele passa pelos microsserviços:

Ao solucionar problemas de provisionamento de mensagens de fax no Control Hub, é essencial coletar um rastreamento HAR para coletar informações detalhadas sobre a natureza do problema e entender os motivos por trás das falhas de provisionamento.

Ao habilitar o recurso de mensagem de fax, o rastreamento HAR captura e exibe a solicitação relevante de CH para CPAPI. Esta solicitação capturada segue um formato específico.

No CH → CPAPI:

PATCH

URL de solicitação:https://cpapi-r.wbx2.com/api/v1/customers/[OrgID]/users/[CHUserID]/voicemail

Identificação de rastreamento ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Dados da postagem {

"habilitado": verdadeiro,

"notificações": {

"habilitado": verdadeiro,

"Destino": "lazoclaudiafi+faxmessaging@gmail.com"

},

"enviar todas as chamadas": {

"habilitado": falso

},

"enviarChamadasOcupadas": {

"habilitado": verdadeiro,

"saudação": "PADRÃO"

},

"enviarChamadasNãoAtendidas": {

"habilitado": verdadeiro,

"saudação": "PADRÃO",

"maxRings": 3

},

"NúmeroParaTransferência": {

"habilitado": falso

},

"EmailCopyOfMessage": {

"habilitado": verdadeiro,

"ID de e-mail": "lazoclaudiafi+faxmessaging@gmail.com"

},

"Mensagem defax": {

"habilitado": falso,

"Número de telefone": "+12099193323",

"extensão": nulo

},

"armazenamento de mensagens": {

"mwiEnabled": verdadeiro,

"Tipo de armazenamento": "INTERNO",

"e-mail externo": "lazoclaudiafi+faxmessaging@gmail.com"

}

Para rastrear efetivamente essas informações no EasyLMA, consulte as orientações detalhadas fornecidas aqui:

Categoria: TrackingID

Subcategoria: Global

ID de rastreamento do Webex: ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

Você pode encontrar os logs fornecidos aqui:

A partir do roteador CPAPI → OCI:

ENVIANDO POST https://ocirouter-rialto.broadcloudpbx.com:443/ocirouter/ocip HTTP/1.1

Destino X-BroadWorks: id=10f0e34e-7a42-46e7-9bb6-993bcd638f7d;tipo=empresarial

X-BroadWorks-Protocol-Versão: 1.0

Tipo de conteúdo: aplicativo/xml

ID deAcompanhamento: CPAPI_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12_0

OCIROUTER_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12_0] Rx [http] 10.71.101.37:80 -> ch3-bwks-v-ocir01-bc StatusCode=200

Do roteador OCI → WXCAS:

10.71.128.200:37514

<?xml version="1.0" encoding="UTF-8"?>

<BroadsoftDocument xmlns="C" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" protocol="OCI">

<externalUserIdentity xmlns="">

<id>159128f9-0758-46ac-85ff-120fae29c9ed</id>

<organizationId>10f0e34e-7a42-46e7-9bb6-993bcd638f7d</organizationId>

<role>Administrador</role>

</externalUserIdentity>

<trackingId xmlns="">CPAPI_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12_1</trackingId>

<command xmlns="" xsi:type="UserVoiceMessagingUserModifyVoiceManagementRequest">

<userId>5849cbde-8ac7-43d6-8726-b5e0678a7904</userId>

<isActive>true</isActive>

<processing>Sistema unificado de mensagens de voz e e-mail</processing>

<voiceMessageDeliveryEmailAddress>lazoclaudiafi+faxmessaging@gmail.com</voiceMessageDeliveryEmailAddress>

<usePhoneMessageWaitingIndicator>true</usePhoneMessageWaitingIndicator>

<sendVoiceMessageNotifyEmail>true</sendVoiceMessageNotifyEmail>

<voiceMessageNotifyEmailAddress>lazoclaudiafi+faxmessaging@gmail.com</voiceMessageNotifyEmailAddress>

<sendCarbonCopyVoiceMessage>true</sendCarbonCopyVoiceMessage>

<voiceMessageCarbonCopyEmailAddress>lazoclaudiafi+faxmessaging@gmail.com</voiceMessageCarbonCopyEmailAddress>

<transferOnZeroToPhoneNumber>falso</transferOnZeroToPhoneNumber>

<alwaysRedirectToVoiceMail>false</alwaysRedirectToVoiceMail>

<busyRedirectToVoiceMail>true</busyRedirectToVoiceMail>

<noAnswerRedirectToVoiceMail>true</noAnswerRedirectToVoiceMail>

</command>

<command xmlns="" xsi:type="UserVoiceMessagingUserModifyGreetingRequest20">

<userId>5849cbde-8ac7-43d6-8726-b5e0678a7904</userId>

<busyAnnouncementSelection>Padrão</busyAnnouncementSelection>

<noAnswerAnnouncementSelection>Padrão</noAnswerAnnouncementSelection>

<noAnswerNumberOfRings>3</noAnswerNumberOfRings>

</command>

<command xmlns="" xsi:type="UserFaxMessagingModifyRequest">

<userId>5849cbde-8ac7-43d6-8726-b5e0678a7904</userId>

<isActive>false</isActive>

<phoneNumber>+12099193323</phoneNumber>

<extension xsi:nil="true"/>

</command>

</BroadsoftDocument>

Informações de encaminhamento

- Arquivo de log HAR

- Capturas de tela de erros

- Etapas para reproduzir o problema

- Carimbo de data/hora do incidente

- Logs de LMA

Responda a essas perguntas antes de abrir o escalonamento BEMS, pois isso ajuda na solução de problemas:

- Que erro você vê?

- Que IDs de rastreamento você vê?

- Você revisou a ID de rastreamento no LMA?

- O que você vê no LMA?

- Esta BEMS é realmente necessária?