Nesta seção, é apresentada uma visão geral dos componentes do StoreX, dividido em duas partes. A primeira aborda definições gerais de cada um dos módulos principais (StoreX EP, StoreX SP, StoreX POS e Integrador de transações). A segunda aborda um overview dos componentes do ecossistema que interagem com esses módulos principais (Portal Big Retail, Tomcat, Servidor de Configurações entre outros).  A apresentação mais aprofundada, trazendo conceitos funcionais, integrações e detalhes práticos é apresentada na seção Visão Funcional dos Componentes.

Visão Geral dos Componentes

O StoreX, de maneira geral, possui quatro componentes principais: StoreX EP, StoreX SP, Integrador de Transações (ou IntTrans), e StoreX POS (os PDV’s) distribuídos como recursos de frente de loja e recursos de retaguarda. Esses não são todos os componentes de todo ecossistema do StoreX, mas são os que se tornam base para customização. A Figura 1 mostra a arquitetura dos módulos principais do StoreX: O StoreX EP, StoreX SP, StoreX POS e StoreX Int Trans, distribuídos entre a retaguarda corporativa e a frente de loja. 

Figura 1 — Módulos principais do StoreX.

StoreX EP

O StoreX EP, ou Enterprise Processor, é o componente responsável por fazer a conexão entre o usuário que interage na retaguarda, com a loja. É ele que garante que todas as transações realizadas pelo usuário cheguem até a loja, sejam elas alterações de cadastro, consultas e solicitações diversas endereçadas a uma loja, cheguem de fato a loja. Ele também é responsável pela distribuição dos dados para os componentes StoreX SP.

O StoreX EP recebe as requisições, processa e distribui os dados solicitados às devidas lojas. O EP, tem como função se conectar com cada servidor de loja, ou seja, cada StoreX SP, agindo como um HUB para as lojas, notificando cada SP sobre diversas informações como, por exemplo, alterações de produto e alterações de preço, e ele faz isso para todas as lojas. A Figura 2 mostra um esquemático dessa relação, usando o Portal Big Retail como exemplo de interação do usuário. 

Figura 2 — Relação de distribuição de informações entre portal, StoreX EP e StoreX SP.

Storex SP

O StoreX SP, ou Store Processor, é o componente responsável por receber os dados do StoreX EP, e distribuí-las aos PDV’s, para manter todos os componentes da loja atualizados, atuando como um HUB para os mesmos. Ele também é um HUB concentrador de notificações, semelhante ao EP. A Figura 3 mostra o esquemático dessa relação.

Figura 3 — Relação esquematizada entre StoreX SP e POS(PDV’s).

Storex POS

O StoreX POS é o responsável pelas vendas e frente de loja dentro de cada loja. Recebe as bases, alterações de preço e de usuário do SP, para permitir que os usuários possam operar a partir dos dados cadastrados e alterados na retaguarda corporativa. Ele é o nosso PDV, componente da frente de loja que mais sofre solicitações para customização. A Figura 4 mostra o layout padrão do StoreX, ou seja, a forma como ele é concebido hoje.

Figura 4 — Layout padrão do StoreX POS(PDV).

StoreX Int Trans (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. Era Antigamente chamado Proc Trans era extremamente dependente do StoreX EP. Ou seja, ele só existia se o EP existisse. Com a mudança para StoreX Custom, isso não é mais necessário. Ele foi Rebatizado para Integrador de Transações, e também foi produzido um instalador dele para ele ser instalado em qualquer pasta para ele ser independente do StoreX EP. Para instalação, são necessárias as URLs de acesso a banco, IP, porta e usuário do banco de dados. Com isso o instalador garante a instalação do Integrador de Transações.

Componentes do Ecossistema

Uma vez tendo um overview dos componentes principais que podem ser customizados no StoreX, temos todo o ecossistema de aplicações, mostrada na Figura 5. Percebemos que apareceram mais componentes que são relacionados aos módulos principais. Seguimos então com um overview deles para melhor entendimento de suas integrações.

 Figura 5 — Ecossistema de relações do StoreX.

Portal Big Retail e Tomcat

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.). Visto 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.). Contudo, o Portal Big Retail surgiu da necessidade que acabar com as telas applet. 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.

Servidor de Configurações

O Servidor de Configurações é o componente responsável pelo gerenciamento e atualização de parâmetros de configuração. Informações como IP’s e portas de comunicação de lojas, por exemplo, são dados que são centralizados no Servidor de Configurações para que em uma situação como uma alteração realizada no Portal Big Retail seja direcionada a uma ou mais lojas se for o caso. Todos os módulos do StoreX Custom precisam de conexão com o servidor de configurações no momento de sua concepção para poder pegar as informações básicas.

Application Uppdater

O Application Updater é o componente responsável pela atualização de versão dos componentes. O Application Updater é inicializado pelo StoreX EP, e escuta as solicitações na mesma porta do EP, esperando uma notificação de que o pacote de atualização está disponível para o download. Quando o pacote de atualização é baixado, é realizada uma notificação por parte da retaguarda do Application Updater de que a atualização está pronta para ser realizada.

Servidor de Pedidos

O StoreX Custom tem a possibilidade de resgatar pedidos que foram processador em outros sistemas para otimizar o processo do caixa. O POS tem essa integração direta com o servidor de pedidos. Ele é corporativo (ambiente de retaguarda) para ele poder buscar os pedidos e fazer o processamento na loja.

LWS Corporativo

Ele agora se chama StoreX Cloud, e a ideia é que ele passe a ser um HUB de comunicação não só interna com outros sistemas como externa. Atualmente ele é um monobloco, porém futuramente ele será um conjunto de microsserviços para centralizar essa responsabilidade de comunicação.

Autorizador Financeiro

É responsável hoje por cartão presente, por fazer trocas, gerar e utilizar vale-troca, gerar e utilizar cartão presente. E é responsável também para determinados seguimentos a parte de convênio(usado em Farma) para poder viabilizar consumo de descontos diferenciados com empresas conveniadas com o cliente. Também tem o modulo de garantia que ele também efetua o gerenciamento.

Sistemas Externos

Também existem outros produtos externos que tem algum tipo de interação com o StoreX Custom:

1. QRLINX —  Interação direta do POS com o Linx Pay. A ideia é que no futuro essa interação seja feita via StoreX Cloud.
2. Linx Promo — A interação foi feita do POS para o Linx Promo e segue a mesma ideia de ser via StoreX Cloud.