- Criado por Edmo Sergio Ribeiro Bezerra em fev 18, 2022
Você está vendo a versão antiga da página. Ver a versão atual.
Comparar com o atual Ver Histórico da Página
Versão 1 Próxima »
Introdução
Este documento tem o intuito de detalhar a integração entre StorEx Custom e Storex Mobile com o serviço de telemetria da Azure.
Entre os serviços Cloud disponibilizados pelo Azure, o serviço de Telemetria é o responsável por receber as notificações das aplicações Storex acima citadas para prover manipulação dos dados em formato de relatórios (dashboards Azure) para fins de métrica de utilização.
Até esta versão, as aplicações Storex notificarão o serviço de Telemetria nos processos de Abertura de Movimento (abertura fiscal do PDV, no caso do Storex PDV e processo de Login, no Storex Mobile). Dessa forma, serão criados dashboards de controle para indicar o quantitativo de componentes linx que estão em uso nos ambientes produtivos dos nossos clientes.
Arquitetura
Configurando acesso ao serviço de telemetria
Conforme mostrado na seção 'Introdução e Arquitetura', o acesso ao ambiente Cloud Azure estará disponível por meio do Storex Cloud. Logo, faz-se necessário prover a parametrização no Storex Cloud, através do Servidor de Configuração, preenchendo o parâmetro "Chave de instrumentação do Linx Metrics", conforme imagem abaixo.
A seguir está detalhado passo a passo necessário para acesso e configuração do parâmetro:
Acessar servidor de configuração que contém as parametrizações do Storex Cloud | |
Acessar grupo de parâmetros e pesquisar por 'GRP-LWS-CORP-GLOBAL' | |
Filtrar pelo parâmetro "Chave de instrumentação do Linx Metrics" e informar o valor da chave correspondente ao serviço de telemetria. Atenção O valor a ser colocado no parâmetro é 678fd6f2-7f4b-4c4f-b09a-66fd69ad4f47 |
Requisitos
Para acessar o ambiente produtivo da Telemetria Azure será necessário ter as credenciais de acesso devidamente liberadas.
Visão Inicial - Dashboard principal
As operações de abertura do caixa (Storex PPV) e login do usuário (Storex Mobile) são os ativadores para envio das requisições dos componentes Storex para notificar que os mesmo estão ativos e em uso. Logo, a consolidação e organização destas informações é realizada em tempo real no dash principal do Azure através de três paineis de monitoramento, conforme imagens abaixo:
Detalhamento | Exemplo |
---|---|
Componentes em uso por cliente Exibe a quantidade de componentes em uso, agrupados por cliente. | |
Componentes em uso por cliente/ loja Exibe a quantidade de componentes em uso, agrupados por cliente e loja. | |
Componentes em uso por loja/ tipo de componente Exibe a quantidade de componentes em uso por cliente, loja e tipo de componente, sendo a visão mais analítica do painel. |
Visão Inicial - Manipulando dados coletados
Os dados em tela são exibidos conforme os filtros, que podem ser modificados conforme a necessidade do usuário.
Detalhamento | Exemplo |
---|---|
O principal deles é o tempo de UTC, que diz respeito ao período em que os dados foram coletados. Ele está localizado no canto superior esquerdo da tela, conforme imagem ao lado: | |
O valor observado no filtro pode ser alterado de acordo com a necessidade do usuário. Nesse caso, além de outras faixas padronizadas de tempo, temos a possibilidade de informar um período próprio, como mostram as imagens ao lado: | |
Ao aplicar o filtro, as três visões são refletidas automaticamente. Além do Tempo de UTC, é possível adicionar filtros próprios, de forma que seja permitido visualizar apenas um cliente, loja ou tipo de componente, por exemplo. Para estes filtros, estão disponíveis operações simples de comparação (igual, diferente, maior e menor que, etc.). | |
Vale salientar que, diferente do Tempo de UTC, o filtro personalizado é refletido apenas nas visões que possuem a coluna escolhida. No exemplo abaixo, ao filtrar o tipo de componente, apenas a terceira visão é modificada, uma vez ela é a única que possui a coluna tipo de componente. Veja a imagem ao lado: | |
Já ao filtrar a coluna “cliente”, as três visões são impactadas, pois o campo está presente nos três blocos. No exemplo abaixo, ao selecionar a coluna "cliente", observe que os três painéis seguiram destacados. Desse modo, o filtro foi refletido em todas as três visões: |
Atenção
Outro ponto importante a ser destacado é que a redundância dos dados é tratada diretamente na query de pesquisa. Sendo assim, ao filtrar os dados de 1 mês, mesmo que dado componente registre operações de abertura de caixa ou login do usuário repetidas vezes, cada operação será contabilizada apenas uma vez.
Mudança nos blocos do painel
Cada bloco é exibido no painel de forma independente. Isto é, o seu título, tamanho, quantidade de colunas e inclusive o seu próprio conteúdo podem ser modificados livremente, conforme a necessidade do usuário.
Detalhamento | Exemplo |
---|---|
No exemplo ao lado, o usuário clica em "editar título" e consegue alterar o texto do título e subtítulo, sem grandes dificuldades. | |
Além do título e subtítulo, é possível modificar também o conteúdo das consultas. Ao clicar na opção “editar”, será possível modificar o nome das colunas, adicionar novas colunas e modificar o engenho de busca, entre outras coisas. Vale ressaltar que as consultas são construídas em KQL (Kusto Query Language), uma linguagem muito próxima do SQL e com várias funções que dão suporte a operações de agregação, ordenação e tratamento de redundância. |
Edição do painel e criação de novos blocos
Além da edição de blocos, é possível criar outros blocos. O processo é simples. Basta editar o painel e clicar em adicionar bloco. Nessa opção já aparece uma galeria de novos blocos disponíveis, com modelos pré-moldados.
Cada bloco deve ser construído sobre consultas construídas em KQL. A documentação oficial da Microsoft é bem extensa e está disponível em https://docs.microsoft.com/en-us/azure/data-explorer/kusto/query/.
- Sem rótulos