Arquivo Discussoes de Programacao e Tecnologia Gostaria de saber se existe alguma possibilidade de se ter um sistema de PDV rodando a partir de um Servidor, sendo o micro do operador de caixa apenas uma “interface”, um meio pelo qual o leitor de código de barras e a impressora fiscal funcionaria, porém todo o processamento ocorreria no servidor?
Alguém já viu isso? :roll:
[color=olive](pensei em algo tipo um “thin client”, que acessaria um servidor “parrudo” que processaria tudo, ofereceria uma interface web bem mais aprimorada etc)[/color]
Gostaria de saber se existe alguma possibilidade de se ter um sistema de PDV rodando a partir de um Servidor, sendo o micro do operador de caixa apenas uma “interface”, um meio pelo qual o leitor de código de barras e a impressora fiscal funcionaria, porém todo o processamento ocorreria no servidor?Alguém já viu isso? :roll:
[color=olive](pensei em algo tipo um “thin client”, que acessaria um servidor “parrudo” que processaria tudo, ofereceria uma interface web bem mais aprimorada etc)[/color]
só com java não sei como faria… talvez acessar a aplicação via telnet.
abraço.
Se não me engano a rede de lojas Camicado (vende um monte de bugigangas que as mulheres adoram) tem um sistema + ou - assim, não consegui descobrir muito a respeito porque a operadora não podia dizer muito a respeito (afinal ela apenas opera o caixa). Esta loja existe em alguns shopping aqui de São Paulo (não sei vc é de Sampa).
Possibilidade, tem sim. O desafio está na arquitetura; vamos dizer que vc tenha várias lojas e os servidores estejam na matriz e repentinamente a energia elétrica é cortada no local. Quer deixar um gerente de vendas louco e falar pra ele que tem caixa inoperante em uma loja; isso tem que ter uma super explicação. Por isso é dificil fazer um sistema destes no formato “thin client”, não que seja impossível, só é bastante desafiador e requer compromisso de muitas partes, particularmente acho que vale a pena o desafio.
Fora isso tem a questão dos periféricos dos caixas que normalmente requerem dlls / so (linux) cedidas pelos fornecedores; e falando sério, administrar um software em java cheio de dlls so (linux) é um p#$@ pé no s@$#.
flws
Será que é tão complicado assim mesmo? Será que os fabricantes dos leitores ópticos/impressoras fiscais têm tanto problema assim com drivers, .dll’s e .so’s? E quanto à Arquitetura, será que é crítico o negócio?
Tô tentando “imaginar” como arquitetar uma solução neste sentido… Algum insight? :roll:
De qualquer maneira, o primeiro link para “sistema camicado” no Google me retornou isto aqui:
http://w.inteq.com.br/Clientes/camicado-houseware
Talvez seja o caso de dar uma investigada.
pcassiano, explica melhor o que vc quer por favor
Prezado Rodrigo,
O que eu quero é o seguinte:
[color=blue]Desenvolver uma solução para PDV onde, ao invés do lojista ter um “sisteminha” rodando em cada micro, como normalmente acontece, um sistema PDV “de verdade” rodaria em back-end, onde a interface com o Operador de Caixa poderia ser via thin client, ou não, mas necessariamente seria beem melhor que os “swingão” da vida…[/color]
Sem contar que uma solução deste porte seria muito mais robusta, melhor gerenciável e teria tudo o que uma aplicação servidor (web) tem.
[color=red]Só não sei como exatamente ficaria a comunicação dos Leitores de Código de Barra com o Servidor…[/color] :roll:
Alguma dica?
[color=olive](vou ver o link que você indicou, thingol)[/color] 
Soluções com “thin clients”, devido exatamente ao problema dos periféricos, podem ser um pouquinho chatas de implementar corretamente.
Por exemplo, uma vez fui chamado para ajudar a vender um thin client para uma determinada companhia, e a venda não deu certo porque o tal thin client não funcionava muito bem com os tais periféricos.
Quando vejo sendo usado um thin client, normalmente os periféricos são impressoras que ficam num determinado servidor da filial; não impressoras ligadas diretamente ao thin client. Um leitor de código de barras ainda é tolerável (porque ele simula um teclado), mas uma impressora fiscal já dá um pouco de problemas com thin clients.
Outra coisa chatinha: thin clients, se forem rodar programas em Java, irão requerer um servidor com quantidades absurdas de memória.
Apesar do recurso de “class data sharing” do Java 5.0 e superior, ainda assim programas em Java são notoriamente gastões se forem usar Swing (por exemplo). Não sei quantos usuários simultâneos você conseguiria suportar em uma máquina com 4GB de memória.
E se,
No lugar dos thin clients, forem micros “comuns”, porém acessando um Sistema no Servidor, muda muita coisa? Já imaginava que thin clients fossem ser chatinhos de implementar…)
Com relação à robustez do Servidor, penso que se necessário alguma solução de balanceamento de carga possa ser implementada, não? :roll:
[color=olive](A discussão tá legal, vamos debater mais?)[/color]
Geralmente em cada loja existe um sistema de retaguarda que dá a carga no pdv, essa carga pode ser feita de forma que fique praticamente online. O sistema de retaguarda tambem faz a comunicação com o centralizador de informações (escritório, CD, etc). Não sei se ainda é dessa forma mas por lei os caixas devem funcionar mesmo que o servidor não esteja funcionando, logo você já exclui a possibilidade de usar uma única impressora fiscal. Um outro requerimento que impede o uso de uma só impresora fiscal é que a medida que os produtos são passados no caixa, eles devem ser impressos no cupom fiscal, logo fica impossível mais de um programa usar a mesma impressora. Algumas empresas de TEF, instalam um programa no caixa e o seu programa deve se comunicar com ele e não sei se é possível usar somente um programa no servidor, já que na maioria das vezes a comunicação é feita por troca de arquivos. Existem algumas empresas que fornecem webservices para TEF também. Não sei como faz com leitores, gavetas e afins mas acho que só dá para usar 1 para cada máquina.
Se você tiver alguma informação de como é possível fazer o que você quer por favor poste aqui, pois tambem quero saber.
E se,Eu não consigo imaginar uma situação em que você precise de balanceamento de carga já que não são tantos clientes assim.No lugar dos thin clients, forem micros “comuns”, porém acessando um Sistema no Servidor, muda muita coisa? Já imaginava que thin clients fossem ser chatinhos de implementar…)
Com relação à robustez do Servidor, penso que se necessário alguma solução de balanceamento de carga possa ser implementada, não? :roll:
[color=olive](A discussão tá legal, vamos debater mais?)[/color]
Cara eu trabalho com automacao a 10 anos. Essa sua solucao eh um tiro na cabeca. Pois vc vai sempre depender do servidor. Se ele parar a loja para de vender.
Tem pensar muito bem nesse tipo de arquitetura. De deixar tudo no servidor. Não tenho experiencia em PDV, mas é como thimor disse, pode te dar uma dor e cabeça tremenda. Algmas coisas sim você pode deixar no servidor.
Mas se quiser seguir essa arquitetura da uma olhda em EJB + Glasfish.
Da uma olhada neste framework, OpenSwing: http://oswing.sourceforge.net
Agora igual o colega aí comentou, vai ficar dependente do servidor.
Bom, um amigo tava desenvolvendo um sistema de compras com ExtJS+JavaDB(acho que com o Jetty Embarcado, ou algo assim), em que cada máquina(micros normais AX2 com 2GB de RAM)registrava as compras/dados e no final do dia tudo seria passado a um servidor central.Como não vi o produto final, não posso falar muito, nem sei a solução que ele usou para fazer a comunicação cliente-server.
Olá!
Cara, acredito que essa abordagem é bem interessante, mas como já disseram, os riscos também são grandes. Quanto a indisponibilidade do servidor, um servidor de “reserva” ajudaria - se o servidor não ficar localizado no mesmo espaço físico dos clientes, pois uma queda na rede ou na energia elétrica com o servidor compartilhando a mesma energia / rede não adianta nada server reserva, nem nada, pois os clients também sofreriam independente de serem thin ou não. (pensando bem, queda de rede ou de energia, não tem jeito mesmo aheuehauehau). Um sistema de cache local e enfileiramento de mensagens muuuuito bem implementado resolveria o problema da rede e / ou indisponibilidade do servidor.
Quanto aos perifericos locais, se for uma web app, teria que usar algo como componentes COM (não sei bem disso) se for para Win32, mas deve ser algo realmente chato como o thingol falou anteriormente. Agora se forem pequenas apps java conversando com o servidor por algum protocolo seu, acredito que possa ser implementada pelo menos essa parte de controle de periféricos localmente, distribuída com Java Web Start, ou algo assim.
Em relação a escalabilidade, EJB seria legal pra distribuir suas regras de negócio e fazer balanço de carga (não sei bem se precisa de tudo isso), mas isso se tornaria algo bem complexo.
Se falei besteira, por favor me corrijam.
Abraços
Eu Tenho um sistema em java , onde se cai o servidor os outros pc param , isso é horrivel mas nao sei como fazer os caixa trabalharem offline , seria como falaram aii o servidor dando carga nos terminais isso seria otimo .
Mas eu tenho sorte que o sistema é muito estavel e nao da pau , como meu socio morreu eu fiquei na mao em muita coisa e to correndo atras do preju …se alguem estiver interessado . o sistema é otimo so que falta coisas importantes , como TEF , hj funciona com daruma , bematech com a nota fiscal paulista com controle de estoque contas a pagar a receber, expedição, aaaaaa muita coisa tem .
se alguem quiser ver todo meu projeto estou a disposição .
[email removido] (gtalk)
[email removido](msn)
o q é PDV??? fiquei curiooso :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:
Gostaria de saber se existe alguma possibilidade de se ter um sistema de PDV rodando a partir de um Servidor, sendo o micro do operador de caixa apenas uma “interface”, um meio pelo qual o leitor de código de barras e a impressora fiscal funcionaria, porém todo o processamento ocorreria no servidor?Alguém já viu isso? :roll:
[color=olive](pensei em algo tipo um “thin client”, que acessaria um servidor “parrudo” que processaria tudo, ofereceria uma interface web bem mais aprimorada etc)[/color]
você pode usar um sitema de acesso remoto tipo Microsoft Terminal Service ou Citrix MetaFrame.só com java não sei como faria… talvez acessar a aplicação via telnet.
abraço.
Hoje em dia isso é totalmente possível e plausível, vários fabricantes de equipamentos de automação tem OCXs/ActiveX para uso em browser, com javascript, procure nos sitios deles. Caso queira usar somente java, eu não sei se tem como acessar código externo a não ser que você mude as configurações do browser, para ficar menos restritivo.
Minha opinião é que você use, nesse caso, servidor web + java no lado servidor (servlets, etc…).
Um amigo meu usa um sistema parecido, mas com Linux + MySql + servidor web + java no lado servidor e um programa “normal” (sem ser em browser) no lado cliente, mas só fazendo a interface, todo o resto é no servidor. Só que ele usa servidores turbinados, montados em racks, sistemas redundantes (RAID), etc…
[]´s.
É perfeitamente possível.
No caso do leitor ótico então, chega a ser ridículo. Este é ligado na mesma porta que o teclado e funciona exatamente como tal. A diferença é que ao invés de digitar, você tem de fazer a leitura do código de barras.
Com relação à impressão, também é possível. Basta redirecionar a saida para a porta adequada, e os fabricantes inclusive oferecem suporte a Java (neste caso, web não seria bacana, porque você não tem como enviar dados para a porta pelo navegador, a não ser que seja usando um applet).
No caso do processamento, pode ser feito no servidor a partir de uma das técnicas abaixo:
Qualquer coisa, a gente pode até trocar idéias fora do GUJ.
também estou um problema parecido com esse,
tenho um sistema no servidor e tenho 2 pdvs , como fazer a carga para o pdv ?
para que o mesmo não fique dependente do servidor
estou usando java desktop e meu bd é mysql
se alguem tiver algum ex , manda ai pr esclarecer melhor a solução
vlw,galera