meus caros colegas, estou desenvolvendo um sistema que terá duas partes: um módulo desktop e um módulo web. Trata-se de um sistema PDV (desktop) com emissão de cupom e nota fiscal, nfe, etc, e um módulo (web) com administração financeira, relatórios, etc. (A legislação me impede de desenvolver um sistema web para emitir cupom fiscal.)
Os dois módulo terão algumas funcionalidades em comum, como por exemplo, montagem de vendas, processos financeiros, etc.
Tenho duas questões cruciais:
A minha primeira dúvida é: como resolver a questão de unificar a regra de negócio para que ambos os módulos utilizem o mesma biblioteca que define essas regras?
Eu pensei em simplesmente criar uma biblioteca com essas regras e compilá-la como um JAR nos dois módulos. Existe algo mais eficiente? Quais as vantagens e desvantagens dessa solução?
A segunda dúvida é: as bases de dados dos módulos estarão separadas… como resolver o problema de sincronismo? Por exemplo, alguém dá baixa num título de um cliente usando o módulo web… como fazer a atualização para o módulo desktop? e vice-versa… eu pensei num esquema de sincronismo via webservice, mas sabemos que isso sempre dá problemas… imagine se alguém resolve editar o mesmo cliente ao mesmo tempo.
[quote=ddso]meus caros colegas, estou desenvolvendo um sistema que terá duas partes: um módulo desktop e um módulo web. Trata-se de um sistema PDV (desktop) com emissão de cupom e nota fiscal, nfe, etc, e um módulo (web) com administração financeira, relatórios, etc. (A legislação me impede de desenvolver um sistema web para emitir cupom fiscal.)
Os dois módulo terão algumas funcionalidades em comum, como por exemplo, montagem de vendas, processos financeiros, etc.
Tenho duas questões cruciais:
A minha primeira dúvida é: como resolver a questão de unificar a regra de negócio para que ambos os módulos utilizem o mesma biblioteca que define essas regras?
Eu pensei em simplesmente criar uma biblioteca com essas regras e compilá-la como um JAR nos dois módulos. Existe algo mais eficiente? Quais as vantagens e desvantagens dessa solução?
A segunda dúvida é: as bases de dados dos módulos estarão separadas… como resolver o problema de sincronismo? Por exemplo, alguém dá baixa num título de um cliente usando o módulo web… como fazer a atualização para o módulo desktop? e vice-versa… eu pensei num esquema de sincronismo via webservice, mas sabemos que isso sempre dá problemas… imagine se alguém resolve editar o mesmo cliente ao mesmo tempo.
obrigado![/quote]
Bom a meu ver não é necessário utilizar 2 sistemas. O PDV que seria Desktop é bem simples, ele somente consumiria e enviaria dados. Toda a regra de negócios ficara no servidor web.
Faz muito tempo que não mexo com isso mas não é necessário um sistema complexo para emisão do Cupom fiscal. O PDV apenas registraria venda no sistema principal e emitiria o cupom fiscal. O registro de venda pode ser feito via WebServices o que desacoplaria totalmente o PDV do resto do sistema! Sei que pela legislação atual o sistema tem que ser tolerante a falhas, como a perda da conexão com o servidor. Mas isso você pode fazer localmente, baixando todos os dados dos produtos ao iniciar o sistema e armazenando as vendas até ser possível envia-las ao servidor!
[quote=fabiobp2000]Olá aqui onde trabalho temos um server windows 2008 com banco de dados.
Colocamos um ip valido nele e um da rede local, sendo assim consigo acessar os dados do banco de qualquer lugar.
O banco que uso aqui é SQL Server 2012.
Deixamos o banco aqui local por segurança de bkps e tals, se a interner cai pelo menos a rede local funciona.[/quote]
Para o PDV não pode ser assim. Um dos testes que eu sei que eles fazem na homologação é tirar o cabo de rede do computador para simular uma desconexão e mesmo assim o sistema deve continuar funcionando!
[quote=x@ndy]O que você acha?[/quote]Eu acho a sua ideia muito boa, desacoplar o desktop do restante do sistema e tratá-lo como um simples emissor de cupom me parece a melhor solução… mas eu não teria problemas com a legislação? Com quem ou aonde eu poderia obter mais informações sobre esse tipo de dúvida? Posto Fiscal? Um contador? Um advogado?
Não acredito que isso seja problema, visto que a maioria dos PDVs são assim (supermercados são um grande exemplo). Quanto a um profissional que te de uma orientação específica realmente não sei responder. Aqui voce encontra o guia com a legislação para o desenvolvimento do PAF-ECF e aqui você encontra o roteiro de homologação. Acho que pode ser um começo
[quote=wellington.nogueira]Esse é um sistema com um requisito bem complexo: Tolerância a falhas. A primeira dúvida que fica é: Onde ficarão armazenadas as informações? Como elas serão atualizadas?
Eu penso que pode ser possível baixar todas as informações de forma estática (apenas para leitura) de todas as informações que o PDV tiver necessidade (gerando, por exemplo, um XML) e registrando todas as transações (em outro XML) e gravando, enquanto possível, no servidor. Quando o mesmo não possuir conexão, os dados não sincronizados começarão a ser acumulados e, posteriormente, sincronizados.
Mas aí entra uma série de fatores: Identificar o retorno da conexão, sincronização das mensagens que não poderão tolerar mensagens de erros e/ou alertas, etc.
Você deverá tentar mapear todos os possíveis pontos críticos e levar aos “donos” do sistema e validar com eles até onde vai a tal tolerância e as formas de contorno quando não tiver jeito (por exemplo, o arquivo gerado para sincronização foi corrompido).
Não é improvável que nem todos os casos possam ser mapeados num primeiro momento e, possivelmente tenha mudanças durante testes/homologação ou pós-produção.[/quote]
Concordo e saliento que por todos esses motivos é muito importante deixar a aplicação o mais simples possível. Outro motivo é a própria homologação. Após feita e realizada a assinatura digital do aplicativo e não se pode mais muda-lo! No caso de qualquer mudança é necessário nova homologação!
Esse é um sistema com um requisito bem complexo: Tolerância a falhas. A primeira dúvida que fica é: Onde ficarão armazenadas as informações? Como elas serão atualizadas?
Eu penso que pode ser possível baixar todas as informações de forma estática (apenas para leitura) de todas as informações que o PDV tiver necessidade (gerando, por exemplo, um XML) e registrando todas as transações (em outro XML) e gravando, enquanto possível, no servidor. Quando o mesmo não possuir conexão, os dados não sincronizados começarão a ser acumulados e, posteriormente, sincronizados.
Mas aí entra uma série de fatores: Identificar o retorno da conexão, sincronização das mensagens que não poderão tolerar mensagens de erros e/ou alertas, etc.
Você deverá tentar mapear todos os possíveis pontos críticos e levar aos “donos” do sistema e validar com eles até onde vai a tal tolerância e as formas de contorno quando não tiver jeito (por exemplo, o arquivo gerado para sincronização foi corrompido).
Não é improvável que nem todos os casos possam ser mapeados num primeiro momento e, possivelmente tenha mudanças durante testes/homologação ou pós-produção.
