Bom dia…
Estou com um problema aqui…sei que deve ser meio batido para voces, mas para mim surgiu agora a necessidade deste tipo de implementação…
Bom vamos ao problema…
Tenho um sisteminha desktop em java que gerencia vendas, estoque, enfim… a parte de controle de uma loja pequena…
Só que agora me apareceu um cliente que tem duas lojas e ele quer que rode nas duas em rede… tipo…se vendeu algo na loja 1 , que apareça na loja 2 o registro disso, assim como saber também quanto tem de estoque nas duas lojas num mesmo pc…
Meu sisteminha roda em rede beleza…mas rede interna… mas agora em rede externa…daí a coisa fica mais cabulosa…pelo menos pra mim…pois meu sistema não é web, o qual facilitaria muito…
Alguém já implementou algo assim…como resolveu o problema para ligar os sistemas das filiais?
Por enquanto visulaizei uma maneira para resolver
1- ter uma base centralizada numa das lojas…e dar um jeito de o cliente conseguir um ip fixo… ou usar o no-ip para mapear a base central em vez do ip fixo
Mas aí surjem algumas dúvidas… não vai ficar mais lento na filial para cadastrar, consultar os dados tendo um banco remoto?
ou teria alguma outra forma…tipo… duas bases , uma em cada filial, onde em determinado momento as duas bases “conversariam” caso necessário?
A legislação baseada no convênio PAF/ECF exige que o programa dependa, única e exclusivamente, do equipamento onde está instalado para ser executado, logo, base de dados remota não seria permitido.
Dê uma olhada na legislação, precisa ver se o que pretende fazer é permitido e pode ser homologada.
Há algumas opções para o que quer:
Bom, acho que já é hora de pensar na escalabilidade do seu sistema.
Acho que a solução mais simples é centralizar o banco de dados em uma das lojas e montar uma VPN entre as duas redes. Assim, a não ser que você tenha chapado o endereço do banco no código, você praticamente não alterara a sua aplicação.
Porém, acho que o principal você não disse: quanto o seu cliente está disposto a investir ? Essa pergunta é o cerne de toda a questão, porque na prática é o que define como você vai montar a infra-estrutura necessária para suportar o negócio. Na minha opinião, o esforço maior é de infra-estrutura, e não de aplicação. Pois além de montar o acesso, há toda uma questão de segurança que você precisa se preocupar agora: configurar firewall, restringir acesso, etc.
[quote=drsmachado]A legislação baseada no convênio PAF/ECF exige que o programa dependa, única e exclusivamente, do equipamento onde está instalado para ser executado, logo, base de dados remota não seria permitido.
Dê uma olhada na legislação, precisa ver se o que pretende fazer é permitido e pode ser homologada.
Há algumas opções para o que quer:
Socket
EJB
Sincronização via banco de dados[/quote]
Mas isso se aplica somente às frentes de caixas, ou o software específico que se comunica com impressoras fiscais. Se for esse o caso, talvez seja necessário separar a frente de caixa do back-office.
Estive dando uma olhada nesse esquema do VPN…vou dar uma pesquisada…pois não entendi muito bem esse esquema… seria como uma sub-rede na net…estou certo ou viajei…?
Como o colega ai em cima disse,
vc deve estar atento à legislação, que
proibe bufferização de dados.
Mas o estoque vc pode centralizar em uma
das lojas fazendo o acesso pela web,
ou por uma vpn. (pela web seria praticamente de graça, usando
no-ip, acessando o banco pela url. Cuidados com segurança devem
ser feitos).
Como ja foi dito, separar os modulos é uma
boa pra não ter problemas com a fiscalização.
Na minha opinião, independente de legislação, se o seu sistema for para venda direta, tipo caixa de supermercado, recomendo que ele trabalhe com uma base de dados local e que tenha um mecanismo de sincronização com uma de base centralizada. Uma vez estava no Livraria Cultura e caiu a comunicação com o servidor. Os caixas chavearam para um modo “standalone”, podendo continuar com as vendas. A única crítica que faço neste esquema da Cultura é que demorou mais de meia hora até o caixa entrar neste modo standalone.
E se a empresa onde você for instalar este seu sistema usar links diretos não dedicados (via internet), a recomendação aumenta mais ainda, pois o risco de instabilidade na rede vai ser grande.
Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.
Mas realmente aconselho a pensar em migrar para a Web, é o futuro próximo e poderá evitar dores de cabeça que surgiram futuramente.
[quote=petter]Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.
Mas realmente aconselho a pensar em migrar para a Web, é o futuro próximo e poderá evitar dores de cabeça que surgiram futuramente.[/quote]
Até onde eu me lembro, o convênio PAF/ECF proíbe sistemas web, justamente por não dependerem exclusivamente do próprio ambiente(?).
O convênio PAF/ECF e a legislação correspondente não deixam claro o que é um sistema de frente de caixa e qual é um sistema de gerenciamento de emissão de cupons fiscais, pelo que li, ele considera ambos a mesma coisa.
A solução mais comum é manter o frente de caixa como sendo o gerenciador do emissor de cupom fiscal (ECF - impressora) rodando com uma base de dados local que, a cada período de tempo, é sincronizada a uma remota (seja na lan ou em algum lugar do mundo).
Na verdade o sistema não seria para PAF-ECF… seria mais a parte gerencial, quando citei vendas, quis dizer uma tela de consultas das vendas realizadas…o módulo do paf, eu tenho separado… meu problema seria a comunicação entre os sistemas gerenciais…pois achando uma maneira de fazer isso, todo o resto estaria resolvido…
[quote=petter]Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.
[/quote]
Seria uma opção…sincronização de tempos em tempos… a questão seria…
1-em que momento seria sincronizado…
2-O que seria sincronizado, (criar flags na base para saber o que foi modificado, incluído ou deletado???) pois se de tempos em tempos mandar por exemplo todos os produtos e clientes vai ocorrer uma grande perda de desempenho
Concordo plenamente…já tinha pensado nisso e já estava me planejando para isso, porém ainda não sobrou um tempo pra isso, meus planos é migrar tudo para Web… mas esse sistema está pronto pra desktop e tenho um prazo pequeno no qual não conseguiria implementar o todo ele para Web (pelo menos para este cliente)…então decidi fazer este módulo de comunicação entre lojas…
[quote=drsmachado][quote=petter]Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.
Mas realmente aconselho a pensar em migrar para a Web, é o futuro próximo e poderá evitar dores de cabeça que surgiram futuramente.[/quote]
Até onde eu me lembro, o convênio PAF/ECF proíbe sistemas web, justamente por não dependerem exclusivamente do próprio ambiente(?).
O convênio PAF/ECF e a legislação correspondente não deixam claro o que é um sistema de frente de caixa e qual é um sistema de gerenciamento de emissão de cupons fiscais, pelo que li, ele considera ambos a mesma coisa.
A solução mais comum é manter o frente de caixa como sendo o gerenciador do emissor de cupom fiscal (ECF - impressora) rodando com uma base de dados local que, a cada período de tempo, é sincronizada a uma remota (seja na lan ou em algum lugar do mundo).[/quote]
sim, eu sei que o convênio é cheio de regras, mas quando falei em solução Web não foi todo o ERP, casos como frente de loja podem atuar stand alone desde que preparados para uma interface com o restante do ERP, assim é mais fácil obter escalabilidade e a agregação de novas filiais se torna muito mais transparente.
[quote=leopoldof][quote=petter]Você passou poucas informações de como é a arquitetura do seu sistema, mas acredito que a opção mais viável para o momento é ter uma base de dados local que sincronize em tempo real os dados de uma base remota, isso vai resolver problemas que possam ocorrer como queda de conexão, fiscalização e se o seu sistema for construído a contento praticamente não terá que alterar ele, fazendo toda a artimanha via BD.
[/quote]
Seria uma opção…sincronização de tempos em tempos… a questão seria…
1-em que momento seria sincronizado…
2-O que seria sincronizado, (criar flags na base para saber o que foi modificado, incluído ou deletado???) pois se de tempos em tempos mandar por exemplo todos os produtos e clientes vai ocorrer uma grande perda de desempenho
Concordo plenamente…já tinha pensado nisso e já estava me planejando para isso, porém ainda não sobrou um tempo pra isso, meus planos é migrar tudo para Web… mas esse sistema está pronto pra desktop e tenho um prazo pequeno no qual não conseguiria implementar o todo ele para Web (pelo menos para este cliente)…então decidi fazer este módulo de comunicação entre lojas…[/quote]
Seguinte, além de Java tenho experiência com Oracle, esse sincronismo poderia ser acertado via o próprio BD e não pela aplicação, o que seria sincronizado é uma decisão pertinente de uma análise profunda dos processos empresariais e processos sistêmicos.
Cara, tenta o mais simples primeiro. Eu imagino que você deve usar um banco de dados em modo servidor, ao invés de um BD embarcado. Sendo assim, instale o programa na filial e configure-o para acessar o banco de dados da matriz diretamente. Uma vez que a configuração esteja pronta, é só acompanhar o pessoal usando o sistema para saber se a responsividade está satisfatória.
Eu não diria embarcado…pois não seria um banco em cada máquina…mas sim um banco de dados em cada loja, ou seja em cada “lan”…e sincronizar os bancos de tempos em tempos…
Pensei nisso também…deixar na “matriz” a base de dados… e instalar na filial somente o programa… depois, por consequencia, configurar um endereço no-ip para que a filial acessar a base de dados na matriz, configurar o modem-roteador da matriz o redirecionamento de portas para o pc que possui base de dados central… + config de firewall…e por aí vai…
Mas assim o sistema não ficará “instável”?
e o sistema na filial não ficará lento…?
mas seria a solução mais rápida…creio não não dará problemas…
Já estou com um nó na cabeça…o que não quero é que o sistema fique instável…caindo toda hora… nunca implementei com redes externas…o que tenho medo é que aconteca o que já presenciei em farmácias e em outros tipos de lojas…que o cara vai comprar uma coisa…e quando vai fazer uma consulta de preço ou estoque… ou até mesmo fazer um pagamento (em determinados casos)…e o atendente fala lá que o sistema caiu e que tem que esperar voltar…kkkkkkkk…e lá se vão 10,15 minutos esperando…
Veja bem, esse tipo de infra-estrutura você vai precisar montar de qualquer maneira. Eu pensaria seriamente na VPN, mas isso depende SO que você vai usar, acho que as versões mais caseiras do Windows não permitem você montar VPNs, em compensação, acho que qualquer distro Linux suporta esse recurso.
Como eu disse, 1 problema de cada vez. Eu acho bastante complicado fazer suposições sobre o comportamento do sistema. Como eu disse, uma vez que a infra-estrutura de rede esteja pronta, instalar a aplicação é simples, é só configurar os dados de conexão. Você só vai saber se o sistema vai ficar lento ou não colocando ele em uso.
De fato, seria tolice ignorar o fato de que a conexão pode cair. Nesse caso, eu não vejo solução melhor do que manter uma base auxiliar na rede local e sincronizar os dados. Mas por exemplo, você não precisa replicar toda a base, mas apenas as tabelas necessárias para manter o processo de venda. Dados gerencias podem ficar apenas na matriz.
Mas resumindo, você não precisa resolver todos os problemas de uma vez. Implante a infra-estrutura necessária, coloque o sistema em produção e trabalhe para implementar a tolerância a falhas no nível desejado. É provável que no meio do caminho surjam outros problemas sobre os quais você nem pensou ainda.
Também teria uma outra solução… uma espécie de “sincronização assíncrona” he he he…
no qual entraria uma terceira máquina… que poderia ser o server daqui da empresa, já que este tem funcionalidades de gerenciar as atualizações dos sistemas nos clientes, já implementaria mais um programinha server pra ficar rodando direto…no qual ficaria um esquema assim…
A matriz com seu BD Local e a filial com o seu BD Local…
Então de tempo em tempo a filial geraria um arquivo com os registros pertinentes, (Dados excluídos, alterados e incluidos como Vendas , clientes, produtos, contas recebidas, etc) e mandaria esse arquivo para uma terceira máquina , que seria o server daqui da empresa…
Entao o server daqui da empresa guarda esse arquivo
Então a matriz de tempo em tempo também consulta o server para ver se não tem nenhum arquivo de sincronização…se tiver…atualiza os dados da filial na base da matriz…
também funcionando de maneira reversa… onde a matriz gera o arquivo e as filiais consultam as atualizações…
Prós que visualizei de inicio.
1)Velocidade do sistema nas filiais, e matriz, pois o banco seria local
2)Abriria mão de configurações de roteadores, modens, firewal, locação de ip fixo… e por aí vai
3)Eliminaria o problema de a rede cair e o sistema travar nas filiais
Contras
1)Implementar um módulo para importar dados modificados podem dar conflitos e varios outros problemas de inicio
2)Dependendo do tempo definido para sincronização, a consulta de estoque , por exemplo não estaria “correta”
3)Essa terceira máquina o qual faria o meio de campo… seria um tendão de aquiles para o sistema…