Sistema híbrido: web e desktop

Muito legal o desafio, tambem estou ancioso para saber as respostas de alguem que realmente trabalhou nesta solução

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!

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!

O que você acha?

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.

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.

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!

x@ndy:

O que você acha?

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

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.

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.