Quick Talk

Ela não existe. Na verdade a rotina imprime na impressora padrão do Windows.

Mover a impressora Bematech não-fiscal para outra porta USB (especialmente por troca da placa-mãe) pode eventualmente fazer com que a impressão não saia mais, porque o Winthor está imprimindo na porta serial virtual errada. Eu não tive tempo para checar se poderia resolver isso através de configuração da impressora mas desinstalar o driver e instalar de novo resolve o problema.

A operação do Winthor numa empresa de varejo hoje requer quatro servidores:

• Servidor principal Linux (Oracle) – requer a assistência de um DBA Oracle pois a TOTVS não dá suporte a ele;
• Servidor DocFiscal Windows – Responsável por toda comunicação com a SEFAZ;
• Servidor WTA (Winthor Anywhere) Windows – Requerido para atualização dos programas (rotinas) e para a operação do DocFiscal;
• Servidor de faturamento Windows – responsável por coletar as vendas dos caixas e enviar para o servidor principal;

Eu estou atendendo a uma empresa que tem duas operações desse tipo e por isso tem oito servidores dedicados ao Winthor.

Por um lado eu acho que usar servidores distintos reduz o risco de uma atualização em um requisito do sistema conflitar com a operação de outro e facilita a manutenção e a redundância. Por outro lado gera um problema para manter quatro máquinas rodando e sincronizadas. Você só percebe esse último problema quando se depara com a necessidade de mover uma ou mais delas entre redes e alterar os respectivos endereços IP e se pergunta: “onde eu tenho que configurar cada um dos servidores e cada um dos clientes que acessam esses servidores para não quebrar a operação?”

Depois que você sabe é “fácil”, mas como eu esperava as configurações são espalhadas:

• Mudança no endereço IP do servidor principal:
  • No próprio servidor, além da óbvia mudança do IP na configuração do Linux é preciso editar o arquivo listener.ora;
  • Cada estação que acessa o chamado “menu Winthor” precisa ter o arquivo tnsnames.ora editado;
  • Cada caixa precisa ter o “dblink” recriado pelo menu F5 “Manutenção checkout” da 2075 pois do contrário apesar de supostamente a operação da 2075 ser “offline” existe uma carga obrigatória no início do dia que não poderá ser feita e a rotina se recusará a abrir o caixa;
  • O servidor DocFiscal precisa ser reconfigurado com novo endereço via sua interface web.
• Mudança no endereço IP do servidor DocFiscal precisa ser informada na rotina 132;
• Mudança no endereço IP do servidor WTA precisa ser informada na rotina 132;
• Mudança no endereço IP dos caixas precisa ser informada ao servidor de faturamento no programa de gerenciamento;

Virtualizar todas as máquinas Windows é uma possibilidade, mas o número de outros problemas que tenho a resolver é tão alto que isso vai ficando para depois.

Sobre o servidor principal, no início eu estranhei a TOTVS não dar suporte a ele mas depois a razão disso ficou mais clara. Aparentemente a TOTVS quer deixar evidente que os dados pertencem ao cliente e que ela só fornece um conjunto de programas para manipulá-los. Na maioria dos sistemas comerciais que eu já vi só quem sabe a senha do banco de dados é o suporte técnico do sistema comercial mas com o Winthor, pelo contrário, a TOTVS não sabe a senha, o que já sugere que ela seja diferente para cada cliente, o que por sua vez dificulta a criação de um vírus que tenha como alvo o servidor principal Winthor nacionalmente. E é o cliente que precisa digitar as credenciais durante a instalação dos softwares. Infelizmente o fato de ser usado um SGBD tão complexo quanto o Oracle e ser necessária a contratação de um DBA para cuidar de seus problemas é um ponto negativo.

E justamente o fato do cliente saber a senha permitiu a existência de processos paralelos para obter informações do banco. Um deles já existia quando eu cheguei e eu acabei tendo que criar outro: um programa para consultar o banco de dados e gerar etiquetas de preços com código de barras para os produtos nas gôndolas. O processo anterior era enrolado demais até para mim e estava com uns bugs muito estranhos (do tipo que faz você arregalar os olhos e dizer baixinho: “mas que p***ra é essa?!”) então decidi que criar um software, além de ser um exercício de programação para Oracle, iria me poupar de dores de cabeça com as chamadas de suporte para o processo existente.

O servidor da faturamento roda também um servidor FTP Filezilla. Na primeira vez que vi isso rodando eu não sabia ainda o propósito e tive ânsia de desativar, mas me contive porque tudo era possível nessa empresa. Mais tarde fiquei sabendo que é por FTP que os caixas transferem informações para o servidor de faturamento.  Um problema aí: as credenciais são padrão para toda instalação do Winthor: usuário “caixa” e senha “caixa”. O mesmo ocorre nos caixas: cada um deles tem um servidor Oracle XE com as mesmas credenciais, onde estão armazenadas todas as informações sobre as vendas. Por que o servidor de faturamento precisa de um servidor de FTP para receber as informações quando poderia buscar as informações diretamente nos servidores em cada caixa ainda é um mistério para mim. Um vírus dedicado ao Winthor (ou um funcionário mal intencionado) pode apagar/alterar todas as informações dos caixas (testado) e, se o usuário FTP tiver permissões de apagamento (acaba de me ocorrer que tenho que checar isso) bagunçar tudo no servidor de faturamento também.

No Winthor a “Rotina 2075” é o programa usando nos caixas, também chamado de “Winthor Varejo”. Supostamente (falarei sobre isso em outro post) essa rotina funciona completamente offline, pois mantém seu próprio banco de dados local (Oracle) em cada caixa com todo o necessário para efetuar uma venda. O processo de sincronizar esse banco de dados local com o banco principal, também Oracle, é chamado de “carga”.

Quando cheguei a essa empresa fiquei espantado com o fato dessa carga levar até 15 minutos. O servidor principal ficava em outra cidade e essa comunicação ocorria via internet usando uma VPN, mas ainda assim não se justificava, porque o banco de dados era pequeno, a banda efetiva (testado) era de 3.5Mbps e uma observação do uso da rede durante a carga mostrava que uma fração desprezível dessa banda estava sendo usada. Não havia congestão do link pois essa demora acontecia a qualquer hora, mesmo quando as empresas nas duas cidades ainda estavam fechadas.

Isso era um problema para a operação, porque qualquer mudança de preços efetuada durante o dia levava no mínimo 15 minutos para ser propagada. “No mínimo” porque como o caixa não podia operar durante esse processo isso tinha que ser feito em um caixa de cada vez. Também era um problema para a manutenção, porque muitos testes envolviam efetuar a carga e às vezes era preciso fazer isso múltiplas vezes.

A única pista que eu tinha da razão estava na latência. Um ping através dessa VPN levava no mínimo 70ms, não sendo incomum ficar em um mínimo de 100ms. Eu suspeitei de programação mal feita. Em vez de coletar toda a informação em um pacote só e aí esses 100ms seriam irrelevantes, a 2075 provavelmente estava dividindo a carga em milhares de querys. Digamos que você tenha 10 mil produtos cadastrados e consulte cada um deles individualmente: numa rede local, cabeada, cuja latência não passa de 1ms essas querys não devem levar mais que (10000×0,001) 10 segundos e um “erro” desses passa despercebido. Mas quando a latência é 100 vezes maior temos 1000s (16 minutos) desperdiçados para efetuar a mesma operação. Note que não é preciso usar uma VPN para ter esse tipo de problema. Basta querer conectar os caixas via Wi-Fi para ter latências piores.

Por essa e outras razões ficou decidido mover o servidor principal para a mesma rede local dos caixas, na outra cidade. Depois que efetuei essa operação, que exigiu semanas de planejamento por causa da complexidade do Winthor, a carga dos caixas passou a levar até 15s.