Componentes principais do StoreX Custom
Esta seção mostra uma visão funcional dos 4 módulos principais: Integrador de Transações, StoreX EP, StoreX SP e StoreX POS. Quando praticável, também é mostradas algumas práticas desses módulos além de integrações com outros componentes.
Integrador de Transações
O Integrador de Transações foi criado para processar as transações enviadas pela frente de loja (StoreX POS) e os seus logs. O Integrador de Transações ao ser iniciado, fica escutando as mensagens enviadas pelo PDV’s, essas mensagens são chamadas de mensagens assíncronas, que são mensagens que precisam ser persistidas no banco de dados, para garantir a suas entregas. Todas as operações que o PDV faz hoje ele gera uma transação, e essas transações são direcionadas ao Integrador de Transações.
Cada operação (abertura de caixa, entrada de operador, suprimento de caixa, venda, cancelamento, pagamento de contas, trocas, devoluções, encerramento de caixa, etc.) que faz parte da rotina do PDV gera uma transação (log do caixa) e o StoreX ele, ao finalizar a operação, envia essa operação via “online” para ela ser processada e gravada no banco corporativo (banco de dados Oracle). Então isso é feito através desse canal de comunicação, ou seja, os PDV possuem uma comunicação direta com o Integrador de transações. PDV’s enviam mensagens para o integrador transações a cada vez que termina a sua operação.
Figura 1 – Integrador de Transações.
Storex EP
O StoreX EP é uma aplicação que faz com que as demandas e ações feitas pelo usuário diretamente na retaguarda (Portal Big Retail/Tomcat; alterações de cadastros, consultas e solicitações diversas) para serem feitas na loja cheguem até a loja. Ou seja, ele trabalha integrado com o servidor de configuração e ele é responsável pela integração com o Portal Big Retail e distribuição dos dados para os componentes StoreX SP através de lotes e cargas de dados de base. Também, quando é necessário consultar informações de uma determinada loja, tudo se dá pelo StoreX EP.
Tendo como interface de entrada do usuário o Portal Big Retail, caso seja feita alguma alteração de algum valor em um determinado usuário ou então, seja criado um usuário totalmente novo. Essas modificações só vão chegar ao ecossistema da loja através das requisições feitas pelo StoreX EP, visto que este receba as requisições feitas pelo usuário da retaguarda. Então, precisamos falar de Tomcat e Portal Big Retail.
Figura 2 – Tomcat e Portal Big Retail.
Junto do StoreX EP, precisamos ter o Tomcat. A versão do Tomcat é uma versão antiga, não podendo ser utilizada uma versão mais atual por incompatibilidade de bibliotecas, impossibilitando a exibição de determinadas telas (telas do portal, telas da tesouraria, etc.). Uma vez que toda migração do Tomcat for concluída, ele poderá ser excluído. Enquanto isso não acontece, o Tomcat continua. Hoje, o Tomcat se comunica com o portal recebendo requisição do portal, e também se comunica com o EP. Todas as classes que o Tomcat usa hoje, estão dentro do StoreX EP, ou seja, o classpath do Tomcat é todo apontando para o StoreX EP.
O Portal Big Retail uma aplicação que fica na retaguarda da corporação, feita em Angular, e é responsável pelo input e pela atualização de dados nossas pelo usuário na retaguarda. Anteriormente, a aplicação web do StoreX era um Monobloco, e dentro dela existiram diversas tecnologias (Atlas,JSP, Flex HTML, etc). Porém, o Portal Big Retail surgiu da necessidade que acabar com as telas applet, pois até elas exigiam não só uma configuração de segurança baixíssima em cada máquina que abre o portal do StoreX como também exigia uma série de configurações manuais para ser possível exibir a boa parte de uma boa parte das telas.
O portal Big Retail hoje exibe toda a aba de menus disponível. As telas migradas, como, por exemplo, “formas de recebimento” é uma tela applet(em Angular). Então, tudo que é feito nessa tela é uma interação entre o portal Big Retail e o banco de dados, diretamente (Não afetando nada no StoreX EP, nem com Tomcat). Uma tela não migrada (por exemplo, a tela “tipos de desconto”), se utiliza da integração com o Tomcat (uma requisição, vinda do portal, solicitando para abrir a tela “tipos de desconto”). O portal Big Retail consegue enxergar o que ainda não foi migrado e o que foi migrado. O portal sabe onde tá o Tomcat através do servidor de configuração.
Então, como saber se, por exemplo, uma loja está atualizada? A tela em Angular da Figura 3 permite fazer essa consulta.
Figura 3 – Tela de Suporte
É enviada para a loja uma mensagem, solicitado a mesma a situação de número de lote (ULG). Ao selecionar o código da loja, o portal manda uma mensagem diretamente para o StoreX EP para resgatar as informações listadas. A Figura 4 mostra as informações retornadas.
Figura 4 – Tela de suporte mostrando detalhamento da loja.
Nessa situação, o portal Big Retail aciona o Tomcat para acessar os dados? NÃO! Telas migradas em Angular não precisam acionar o Tomcat.
Em todas as mensagens que são enviadas do portal para o StoreX EP são criados os tratadores (ou listeners), classes que usam o engenho de comunicação que fazem o recebimento dessas mensagens. Desse modo, o portal solicita ao EP pedindo a informação de uma determinada a loja, no exemplo, da loja 45. O EP sabe que a loja tem essas informações então ele envia uma mensagem para o StoreX SP que é o servidor da loja, funcionando apenas como um HUB nesse processo. Com isso, o portal não precisa saber IP e porta da loja em específico. Só precisa mandar a requisição pro StoreX EP que ele precisa daquela loja.
O que é e como fazer uma liberação de lote através do portal Big Retail?
A liberação de lote é fazer a distribuição dos dados que estão na retaguarda que foram alterados para chegar nas lojas. E por onde esse processo passa? Pelo StoreX EP. A Figura 5 mostra como iniciar uma liberação de lote.
Figura 5 – Liberação de Lote
Ao clicar em “Liberar Lote”, ele vai mostrar a quantidade de alterações que foram feitas nos bancos. O banco comercial são cadastros comerciais, ou seja, de uso na frente da loja. E o banco de parametrização são informações sobre os componentes da loja (em desuso, porém o engenho está mantido). A Figura 6 mostra os bancos que são mostrados no StoreX.
Figura 6 – Bancos comercial e de parametrização na liberação de lote
Ao selecionar o banco e clicar em “Ok”, o portal vai notificar o EP para que ele faça a distribuição daquela atualização para todas as lojas cadastradas no StoreX, seguindo o mesmo padrão da consulta mostrada no exemplo anterior. Com isso a Liberação é executada com sucesso.
Hoje, o StoreX EP fica na pasta p2k. Ele é um diretório que possui muitas pastas, por que ele veio do StoreX antigo. Ele basicamente se concentra na pasta bin (que é a pasta de execução dele), a pasta do diretório da retaguarda (hoje, ainda com muitos htmls e outros tipos de arquivos herdados do StoreX antigo).
Para ele operar, ele necessita do IP do servidor de configuração. Em todas as aplicações, foi criada uma pasta chamada ‘config’ onde é informado o IP e a porta do servidor de configuração.
Para o StoreX EP foi criado um instalador, diferentemente dos outros StoreX, o StoreX EP conseguimos instalá-lo(ele possui uma limitação que ele PRECISA estar na pasta p2k). Ele parte de uma matriz controlada que instala o StoreX EP e o Tomcat puxando os parâmetros do servidor de configuração. Quando ele for instalado e conseguir subir, a primeira coisa que ele faz é pegar todas as suas parametrizações. O StoreX EP precisa do seu IP e sua porta especificados quando ele subir para ele poder ficar escutando as mensagens de quem é integrado com ele.
Hoje o EP ainda possui (assim como todos os componentes) o arquivo chamado “MessagingConstants.properties” que é um arquivo padrão da biblioteca de comunicação. O Comunication precisa saber em que porta ele vai escutar. Caso a porta que ele esteja configurado der conflito com alguma outra aplicação o serviço não vai subir. Essas parametrizações desse arquivo são parametrizações básicas, porém são bem importantes para o funcionamento do EP. Caso algum desses serviços não estejam no ar e seja solicitada uma consulta via Portal Big Retail é mostrada a mensagem Erro COM028, como mostra a Figura 7.
Figura 7 – Erro COM028.
Os processos de alteração de dados podem acontecer de duas formas hoje: ou via portal, ou via processos automáticos, que são processos que ficam rodando em batch na aplicação e que fazem esse processo de atualização de dados, mas já dentro do banco de dados. A partir dessa atualização no banco de dados, ele gera o que são chamadas entradas de lote, para que o EP distribua.
Os processos automáticos são uma lista de processos onde se é configurado um horário e a periodicidade. Eles disparam procedures e pacotes de importação no banco de dados Oracle. Tanto o Portal Big Retail quando o Banco de dados Oracle produzem as entradas de lote. Nos arquivos de lote, podemos ver a estrutura dessas entradas.
Exemplo de entrada dentro do lote.
Os processos automáticos podem ser de dois tipos distintos: Processos automáticos e Processos automáticos periódicos. Os processos automáticos são processos que rodam uma vez por dia de forma automática, e os processos periódicos que são processos que rodam mais de uma vez por dia de forma cadenciada. Esses processos são mantidos hoje de forma sobrescrita, pois o arquivo responsável (ProcessosAutomaticos.properties) não é de fácil manutenção, requerendo uma atenção manual.
Figura 8 – Exemplificando tipos de processos automáticos.
O EP também é responsável por distribuir a base de dados num processo chamado geração de carga de base, um dos processos mais monitorados pelos times de suporte hoje, pois é o reset do status. Por exemplo, se houve alguma oscilação de preço na loja que por algum motivo não chegou ao PDV, essa carga de base recria a base e garante que você esteja com os mesmos preços da retaguarda corporativa. Porém, é um processo bem oneroso, pela questão do volume de dados no tráfego.
Figura 9 – Tipos de Carga de Base
Existem duas opções: a carga comercial e a carga parcial. A carga parcial ela ainda não está validada por completo no StoreX. Sendo assim, é recomendado o uso da carga comercial completa. Então ao selecionar o tipo de carga, são selecionadas as lojas e feita a solicitação. Ao fazer isso, o Portal notifica o EP, que aciona o processo de carga de base.
Figura 10 - Seleção de lojas da carga de base
Como o processo de carga de base é um processo que precisa ser monitorado ele possui os logs em um diretório específico, o diretório chamado Carga_Base. Quando esse processo é iniciado, primeiro é verificado se não existem lotes pendentes. Se houverem esses lotes vão ser liberados.
Storex SP
O StoreX SP (Store Processor) é o servidor de loja. Ele é um concentrador de informações e um HUB de notificações para todos os componentes da loja. Quando são feitas alterações em um preço de produto, criação de usuário ou outras operações pelo portal Big Retail, o StoreX EP vai conseguir notificar cada servidor de loja sobre essa determinada ação esse servidor StoreX SP vai, uma vez recebendo essa notificação, processar essa solicitação (ele possui uma base local, então ele vai atualizar a base local) e ele por ser o servidor da loja ele distribui essa notificação para cada componente da loja.
Por exemplo, suponhamos que um cliente possua 500 lojas e, cada loja possua 3 PDVs totalizando 1500 PDVs. Quando é feita, por exemplo, a criação de um usuário que possa estar em qualquer uma dessas lojas, o StoreX EP recebe a notificação de criação deste usuário e ele que vai notificar as 500 lojas sobre a criação desde novo usuário, informando que este precisa ser cadastrado nas bases locais das lojas e de seus componentes.
Figura 11 – Exemplificando StoreX SP.
O StoreX EP vai conhecer 500 notificações (uma para cada loja). Todos os StoreX SPs vão receber essas notificações (Cada SP receberá uma notificação) e ficará responsável por processar essa requisição (no caso do exemplo a criação de usuário) e vai enviar uma notificação para cada componente dele (ou seja, ele vai enviar uma notificação para os três PDVs da loja). Ou seja, ao invés de termos um StoreX EP notificando 1500 componentes de loja, ele notifica apenas 500 (StoreX SP) que por sua vez atualizam os componentes da loja (PDVs).
Essa arquitetura é baseada na necessidade de as lojas terem autonomia de operação, refletindo um dos pilares que o StoreX possui: dar o poder para uma loja operar de maneira “offline”. Existe uma distribuição de bases locais entre os componentes da loja para evitar que a loja pare de operar por problemas de rede. Não é admitido o StoreX parar toda uma loja por problemas de link. Ele tem autonomia de funcionar “offline” e fará as devidas operações quando as conexões normalizarem.
Hoje, os SP’s são instalados tanto em Windows quanto em Linux. Contudo, existe apenas o instalador para Linux atualmente. A nível de instalação, o SP ainda precisa ser instalado em uma pasta chamada p2ksp (herança do StoreX Standard). Ao contrário do que acontecia anteriormente, no StoreX Custom o SP não tem mais a pasta por loja: existe apenas um diretório e esse diretório já é o diretório da loja. Isso foi importante para manter o SP, EP, e POS com a mesma estrutura de diretórios. A unificação desse diretório nas soluções passou a facilitar diversas operações (Scripts, instalação, etc).
Como todos os módulos StoreX, o SP também possui a pasta config com as informações de IP e porta para o servidor de configurações. Contudo, no SP é criado um arquivo adicional chamado “store-number” (ele é criado quando as instalações são feitas, no caso do Linux é criado automaticamente pelo instalador, no Windows ele precisa ser criado manualmente porque o Windows não possui instalador).
Esse arquivo é necessário, pois o SP precisa saber para qual loja ele trabalha e a gente precisa saber em que loja ele ta no momento de sua concepção.
Como foi visto antes, o SP é responsável por dois grandes processos: distribuição de dados e consulta de informações. Todas as consultas de informação, quando o SP recebe eles possuem também os tratadores de mensagem. Então o SP quando sobe ele cadastra esses tratadores para que ele possa escutar naquela porta configurada as notificações. Podemos analisar as informações que são exibidas em uma requisição feita pelo portal para o SP. O SP também é responsável por monitorar esses componentes (Se está “online” ou “offline”, status, etc.).
Figura 12 – Detalhamento de informações oriundas do SP.
Ele abre um thread onde ele fica pingando os componentes, e esses componentes respondem para ele o status (numa periodicidade de 1 minuto, não parametrizável). Com isso o SP consegue atualizar localmente os dados dele, para que quando alguém consulte a loja ele possa ter essa informação o mais atualizada possível. Ele não busca o status dos componentes no momento da consulta, pois aí o processo seria onerado demais.
Acessando o portal Big Retail, podemos solicitar a uma ou N lojas se um usuário (por exemplo, 2172) existe. Acessando a Tela de Tira Teima - Código de usuário e preenchendo as credenciais necessárias a tela de requisição fica como na Figura 13.
Figura 13 – Tela Tira-teima
O Portal envia uma requisição pela camada de comunicação para o StoreX EP, esse que no que lhe concerne roteia essa requisição apenas para a loja selecionada. A loja selecionada responde (através do StoreX SP) as informações solicitadas. Como não são informados no exemplo nenhum número de PDV, essa solicitação é feita apenas para o servidor da loja. Caso seja preenchido o número do PDV também, o mesmo caminho é feito até o StoreX SP e ao chegar nele, ele irá perguntar ao PDV selecionado sobre a informação.
A outra função do SP é a distribuição de dados, que pode ser por lote ou por carga. Esses lotes são todos recebidos em formato XML e o SP distribui esses lotes para todos os componentes. O SP notifica os componentes de maneira assíncrona, ou seja, mensagens que precisam garantir a persistência e a ordem em que elas chegam.
Existe um tipo de mensagem, chamada mensagem assíncrona com prioridade, sendo uma mensagem que passa na frente de todas as outras mensagens assíncronas na fila de prioridades. Hoje, só existe uma mensagem com essa classe que é a mensagem de carga de base, o segundo motivo pelo qual o SP existe. Essa mensagem tem um arquivo.zip que contém todo o retrato da base de dados daquela loja que hoje está armazenado no banco de dados Oracle (retaguarda) para poder o SP processar.
Storex POS
StoreX POS é o PDV, a aplicação da loja e ele é responsável hoje pelas vendas e pelos pagamentos na frente de loja. Ele recebe as bases, as alterações de preços de usuário para ele poder efetuar venda atualizada com os preços atualizados e permitindo que os usuários possam operar a partir das informações cadastradas e alteradas lá na retaguarda Corporativa. É o módulo hoje que mais sofre alterações e modificações. Assim como os outros módulos, ele também necessita de conectividade com o servidor de configuração no momento de sua concepção para poder carregar sua primeira base de parâmetros. E assim como os outros módulos também ele se atualiza pelo Application Updater. Hoje, é o PDV quem interage com todos os outros sistemas externos (outros produtos Linx). O PDV hoje possui a mesma estrutura de pastas que possui o SP, tirando a parte de lotes.
Figura 14 – Integrações do StoreX POS com produtos externos.
Visualizamos o POS com integrações externas com os vários produtos Linx existentes. Futuramente, ele concentrará todas essas integrações no LWS corporativo, que unificará a comunicação do PDF e ele ficará responsável por se comunicar com os produtos.
O PDV é baseado em uma máquina de estado, ou seja, são componentes que tem estados e esses estados variam. Entre um estado e outro ele faz diversas operações. A Figura 15 temos o estado “Disponível”. Esse é o principal estado do PDV, porque é dele que o operador pode fazer todas as suas operações.
Figura 15 – Layout do POS com o estado “Disponível”.
Podemos sair do estado disponível para o estado de “Venda”, onde é feito o registro de um produto.
Figura 16 – Layout do POS com o estado “Venda”
A tecla subtotal leva ao estado de Recebimento.
Figura 17 – Layout do POS com o estado “Recebimento”.
E ao finalizar, voltamos ao estado inicial que é o estado “Disponível”. Para sair de um estado para outro sempre tem o acionamento de uma tecla. Tanto pode ser acionado via tecla física, ou o próprio sistema pode acionar via tecla lógica, para emular o acionamento de um teclado.
Quando o PDV faz uma operação que muda de estado, ele manda uma notificação pro SP independente se o SP solicitou ou não. Isso é necessário para deixar os componentes o mais atualizado possível.
Figura 18 – Esquema de subida de transações do POS para o Int Trans.
O PDV tem o que chamamos controle de movimento, ou seja, ele opera na data de movimento dele. Ele herdou algumas regras do uso do SEF (Impressora Fiscal/ Emissor de cupom fiscal). Existem várias regras dentro do PDV que são antigas. Sendo assim, o PDV tem o conceito de data de movimento (das 2:00 da manhã do dia atual até as 1:59 do próximo dia), tendo os conceitos de abertura de caixa e fechamento Z (que são requerimentos fiscais originais). Esses conceitos vêm das impressoras fiscais e o PDV se utiliza das mesmas regras para operar.
O PDV possui um estado chamado estado parcial, exemplificado na Figura 19. O PDV só pode entrar em funcionamento com a entrada de um operador. Operador é a pessoa responsável pelas operações em um determinado momento.
Figura 19 – Estado parcial.
O conceito de fundo de troco existe no PDV. É o fundo monetário que o operador vai ter ao começar o turno de trabalho que será colocado no caixa. Esse dinheiro é registrado no PDV como mostra a tela abaixo.
Figura 20 – Fundo de troco na entrada de operador.
Existe uma solução de impressora virtual que simula uma impressora não fiscal, para ajudar os desenvolvedores a fazerem testes e checar comportamentos. O Layout dela é mostrado na Figura 21.
Figura 21 – Impressora virtual usada pra desenvolvimento e testes.
Em cada transação, no rodapé do PDV é impresso o NSU que é o número da transação. Isso ajuda a achar transação no log, no banco caso tenha algum problema. No caso da operação de fundo de troco, o PDV gera comprovante para ela com as informações, como mostra a Figura 22.
Figura 22 – Comprovante de transação
O PDV no StoreX Custom tem o conceito de bandeiras. No StoreX Standard a bandeira default é “linx”. Na estrutura dos diretórios das bandeiras seguem o padrão p2k/bin/dominios/”nomedabandeira”. Onde nome da bandeira é uma string toda minuscula, pois como existem os ambientes Linux e Windows, o Linux é case sensitive e o Windows não é. Os arquivos dentro dessas pastas são as imagens que são direcionadas para a bandeira a qual ela se referência, como mostram as Figuras 26 e 27.
Figura 23 – Ícones presentes no POS Standard.
Figura 24 – Ícones customizados para uma bandeira de um cliente.
Atualmente não é recomendado que as imagens sejam modificadas além da mudança de cores. Futuramente, é um objetivo permitir que, caso seja necessário, sejam feitas mudanças também nas imagens. Essas imagens norteiam os ícones de todas as operações na tela do PDV.
Além das imagens, esse mesmo folder possui o arquivo “estiloPDVTouch.css” que determina a fonte, tamanho, cores, sombreamento, de cada elemento visual. Quando é dito que o botão é de determinada cor, ele tem certamente um .css definido para esse botão.