Introdução

Um hub de periféricos é um componente que permite a conexão e gerenciamento de diversos dispositivos periféricos a um sistema central abstraindo os diversos protocolos que são necessários para a comunicação com os periféricos. Ele desempenha o papel de intermediário entre o sistema principal e os periféricos, facilitando a comunicação e o controle dos dispositivos. No contexto de impressoras térmicas e fiscais, pinpad's, balanças, SAT FISCAL e outros hardwares, um hub de periféricos pode ser projetado para suportar a integração desses dispositivos.

Principais características e funcionalidades:

1. mComunicação e Integração:

   • O hub deve suportar diferentes protocolos de comunicação utilizados pelos dispositivos periféricos, como interfaces de rede, USB, Bluetooth, RS-232, entre outros.
   • Ele deve implementar drivers e bibliotecas que permitam a comunicação eficiente com os dispositivos periféricos, fornecendo uma interface unificada para o sistema central.
   • Não depender de DLL´s de Fabricantes, ou seja, comunicação direta.

2. Tratamento de Exceções:

   • O hub deve ser capaz de lidar com exceções e erros de comunicação, fornecendo mecanismos para registrar e tratar problemas de forma adequada.
   • Ele pode implementar recursos de reenvio de dados, recuperação automática de erros e mecanismos de notificação para alertar os usuários sobre problemas de conectividade ou funcionamento dos periféricos.

3. Monitoramento de Status:

   • O hub de periféricos pode fornecer recursos de monitoramento de status dos dispositivos, como níveis de papel de impressoras, status da conexão com o pinpad, informações sobre o estado das balanças, etc.

4. Suporte a Múltiplas Plataformas:

   • O hub de periféricos pode ser projetado para ser compatível com diferentes plataformas e sistemas operacionais, permitindo a integração em ambientes heterogêneos.

Objetivo estudo

Desenho de arquitetura para solução de Hub de periféricos para agilizar o processo de integrações de novos periféricos em múltiplas interfaces, criando uma camada única de comunicação das interfaces com os fabricantes de periféricos, entre um desenvolvimento próprio e/ou considerando o Hub de Mercado ACBR.

Escopo

O hub de periféricos é responsável por orquestrar a comunicação das diversas interfaces (PDV, ERP ou qual quer sistema que precise se comunicar com periféricos) com os principais fabricantes de periféricos, desta forma as interfaces não precisaram conhecer os protocolos de comunicação com os periféricos, e sim apenas com o Hub se periféricos.

Modelo 1: Desenvolvimento Próprio sem utilização do ACBR

Detalhamento

O Desenho contempla duas aplicações, uma em nuvem e outra local, abaixo detalhamento:

• Objetivos da aplicação em nuvem
  • Gerenciar o licenciamento e uso da aplicação
  • Gerenciar atualizações dos clientes
  • Bilhetagem
• Objetivo da aplicação local
  • Receber e organizar as requisições das múltiplas interfaces 
  • Se comunicar com os periféricos independente dos contratos ou protocolos de comunicação (DLL´s de Fabricantes)

As diversas interfaces irão se comunicar com o Hub de periféricos client através de API's Rest full, que por sua vez fará o papel de tradução e camada anticorrupção com os diversos protocolos de comunicação com o periféricos, o Hub de periféricos client precisará de um banco local relacional para armazenar as informações de liberação de uso, logs, uso e configurações básicas, de tempos em tempo precisará se comunicar com o Hub de periféricos server a fim de verificar possíveis atualizações, contabilização de uso e a continuidade da liberação de uso. 

Sugestão tecnológica

Sugestão de Linguagem de Programação: C#

Justificativa:

A linguagem de programação C# é uma escolha sólida para o desenvolvimento do sistema proposto devido a várias razões:

1 - Ecossistema de Suporte:

•  C# possui um ecossistema maduro, com uma ampla gama de bibliotecas e frameworks disponíveis. Isso facilita o desenvolvimento eficiente de funcionalidades e a integração com componentes de terceiros.

2 - Desempenho e Escalabilidade:

• C# é uma linguagem compilada que oferece bom desempenho e eficiência, tornando-a adequada para sistemas que precisam lidar com cargas de trabalho exigentes.
• A linguagem suporta programação assíncrona e paralela, permitindo a criação de sistemas que podem aproveitar ao máximo os recursos de hardware e lidar com operações concorrentes de maneira eficiente.

3- Suporte da Comunidade:

• C# possui uma comunidade de desenvolvedores ativa e engajada, que contribui com bibliotecas, frameworks, fóruns de discussão e recursos educacionais. Isso facilita a resolução de problemas, compartilhamento de conhecimento e atualização contínua da equipe de desenvolvimento.

4 - Experiência da Equipe:

• Nossa equipe de desenvolvimento possui experiência significativa no desenvolvimento com C#. Isso nos permite tirar proveito do conhecimento existente, reduzindo a curva de aprendizado e acelerando o processo de desenvolvimento.

5 - Integração com o Ecossistema Microsoft:

• Se nossa organização já utiliza outras tecnologias Microsoft, como servidores Windows, SQL Server e Azure, o uso de C# se alinha bem com essas tecnologias, facilitando a integração, o gerenciamento e a manutenção do sistema.

É importante ressaltar que a escolha da linguagem de programação deve ser avaliada em conjunto com outros fatores específicos do projeto, como requisitos funcionais, não funcionais e restrições tecnológicas. No entanto, com base nos benefícios mencionados acima, a linguagem de programação C# é uma opção recomendada para o desenvolvimento do sistema proposto.

Sugestão de Banco de Dados Relacional: PostgreSQL

Justificativa:

O banco de dados relacional PostgreSQL é uma escolha recomendada, considerando os seguintes aspectos:

1 - Confiabilidade e Robustez:

• O PostgreSQL é conhecido por sua alta confiabilidade e robustez. Ele possui um mecanismo de recuperação de falhas sólido e é capaz de lidar com grandes volumes de dados e cargas de trabalho exigentes. Isso é essencial para garantir a disponibilidade e a integridade dos dados do sistema.

2 - Suporte a Recursos Avançados:

• O PostgreSQL oferece suporte a uma ampla gama de recursos avançados, como transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade), chaves estrangeiras, gatilhos, visões e procedimentos armazenados. Esses recursos permitem modelar e manter a consistência dos dados de maneira eficiente.

3 - Desempenho e Otimização:

• O PostgreSQL é altamente otimizado e possui recursos avançados de otimização de consultas. Ele suporta índices eficientes, planos de execução personalizados e ferramentas para análise e ajuste de desempenho. Isso contribui para um melhor desempenho do sistema, especialmente ao lidar com consultas complexas e volumes de dados significativos.

4 - Escalabilidade e Concorrência:

• O PostgreSQL é capaz de lidar com grandes quantidades de dados e oferece suporte a recursos de escalabilidade, como replicação e balanceamento de carga. Além disso, ele possui um sistema de controle de concorrência eficiente, permitindo que várias transações acessem e modifiquem os dados de forma segura e eficaz.

5 - Comunidade Ativa e Suporte:

• O PostgreSQL possui uma comunidade de desenvolvedores e usuários ativa, o que resulta em um suporte amplo e contínuo. Há uma abundância de recursos, como documentação detalhada, fóruns de discussão e atualizações regulares de versões, que garantem a estabilidade e a evolução do banco de dados.

6 - Integração com Outras Tecnologias:

• O PostgreSQL tem suporte para várias linguagens de programação e é amplamente utilizado em diversas plataformas e sistemas operacionais. Além disso, ele oferece integração com outras tecnologias, como frameworks de desenvolvimento web e ferramentas de análise de dados. Isso facilita a integração e o desenvolvimento do sistema proposto.

Com base nos benefícios mencionados acima, a sugestão do uso do banco de dados relacional PostgreSQL é recomendada para atender às necessidades de armazenamento de dados.

Vantagens

• solução proprietária, seria desenhado com foco para atender soluções TOTVS
• possibilidade de gerenciamento em nuvem para controle de licença e monitoramento
• gerenciamento de fila
• desacoplado da solução

Desvantagens

• modelo apenas em API (não é uma classe ou biblioteca que pode ser importada na aplicação), queda de performance na comunicação direta com os periféricos
• investimento para utilização em demais soluções que já possuem o Hub ACBR: Winthor, Virtual Age (Moda) e CONSINCO
• investimento/horas inicial para estrutura base do hub
• investimento/horas para integração de cada periférico (aproximadamente 100 horas por periférico)
• time dedicado para implementação de novos periféricos
• irá concorrer com solução de mercado com alto nível de maturidade e com código aberto
• necessidade de time focado para evoluir e manter a solução

Modelo 2: Utilização do ACBR como classe, biblioteca, AcbrMonitor  e/ou desenvolver camada intermediaria TOTVS Monitor

Detalhamento

O Desenho contempla 4 formas de utilização da camada ACBR, sendo as 3 primeiras já existentes no projeto:

• Classe
  • Aplicações baseadas em Object Pascal podem utilizar diretamente as classes sem precisar de Bibliotecas/Dlls ou camadas intermediarias como AcbrMonitor.
  • Esse modelo já é utilizado nas soluções Winthor, Moda e Consinco.

• Biblioteca/Dlls
  • Demais aplicações como as baseadas em C# e ADVPL, podem utilizar as bibliotecas que são derivadas das mesmas classes utilizadas pela linguagem Object Pascal para a comunicação.
•  AcbrMonitor
  • Aplicação tipo serviço, que permite a comunicação por meio de troca de arquivos ou comunicação TCP/IP. Também são derivadas das mesmas classes utilizadas pela linguagem Object Pascal.
• TOTVSMonitor (Desenvolvimento novo)
  • Desenvolvimento de monitor próprio TOTVS utilizando como base as bibliotecas do ACBR, com o objetivo de abstrair a comunicação com os periféricos e permitir implementações de novas funcionalidades como controle de fila. 

Importante: As diversas interfaces irão se comunicar sempre com a mesma classe ACBR.

Vantagens

• solução ACBR é código aberto (https://pt.wikipedia.org/wiki/GNU_Lesser_General_Public_License)
• fundada em 2004, carrega 19 anos de expertise com periféricos e os modelos/versões de periféricos mais utilizados no Varejo
• comunicação direta com os periféricos, sem depender de dll´s de fabricantes
• colaborativa, diversos desenvolvedores contribuem com a evolução da ampla camada de periféricos compatíveis 
• fórum com mais de 75.00 usuários que colaboram e trocam experiências 
• já utilizada e elogiada pelos times Winthor, Virtual Age(Moda) e Consico
• pode ser implementado pelo time Protheus Varejo no modelo de Biblioteca/Dlls, modelo já utilizado para comunicação com periféricos atuais, sendo esforço similar com o esforço de conectar uma nova impressora, porém, iria conectar todos os modelos existentes no ACBR
• Permite que seja idealizado o desenvolvimento do modelo de TOTVS Monitor, onde seria possível abstrair a comunicação com periféricos e implementar novas funcionalidades, muito parecido com o Modelo 1,.

Desvantagens

• Se desenvolvido o TOTVS Monitor, teríamos uma camada intermediaria para comunicação com o periférico, podendo impactar em lentidão e complexidade.
• Caso o projeto seja descontinuado um dia, será necessário time para dar continuidade, porém, não é uma desvantagem para o Modelo 1, pois já seria necessário esse time na concepção.

Considerações

• O desenho de arquitetura do modelo 1 foi apresentado para os times de engenharia corporativa e local, onde foram sinalizados pontos como o aumento da complexidade para suporte e custo de desenvolvimento.
• ISSUE com análise e considerações da engenharia local: DENGVDARQ-2227 - Obtendo detalhes do item... STATUS
• Tivemos agendas com os times de Winthor, Virtual Age(Moda) e Consinco, todos elogiaram muito o ACBR e sinalizaram que o tema periféricos não é um problema para eles, mostraram preocupação em ter que utilizar um Hub pois isso também poderia aumentar a complexidade para o suporte/desenvolvimento, informaram que já utilizaram solução similar com a proposta do Hub para comunicação com SAT¨(Fiscal Manager) e tiveram muitas dificuldades e lentidão na comunicação com o periférico, pois não era mais uma comunicação direta e sim para uma Solução HUB.

Conclusão

• Atualmente o tema Periféricos é um problema exclusivo da solução Protheus Varejo, podendo ser superado com a utilização da mesma solução ACBR por meio de DLL e com baixo esforço(similar com a implantação de apenas 1 modelo novo de periférico)  de desenvolvimento.