openerp-brazil-team team mailing list archive

[Cloves Almeida <cjalmeida@xxxxxxxxx>]

Raphael,

A solução mais simples e madura para cuidar do transporte de mensagens
seria o Apache Camel. A idéia é usar ele para todo o roteamento,
validação e tratamento de exceção. O chato incluir a dependência para
Java.

Eu não pretendo usar o XML+RPC diretamente. Um módulo teria a função de
transformar a estrutura de dados do Python (dict) para o XML no formato
especificado pelo XML Schema.

Em relação ao transporte, usar JMQ via Jython seria lindo. Mas como vai
demorar a adaptação, posso usar o Camel via HTTP. Nada de SOAP, apesar
das especificações "WS-*" darem boas dicas de implementação.

Não duvido o processo será mais complexo que eu imagino. Porém, acho
mais simples que criar uma solução PDV madura o suficiente, com todos os
requisito legais atendidos, e que atende diversos segmentos verticais. A
equipe do Stoq está tentando faz alguns anos tentando e ainda não chegou
lá. Como minha empresa precisa dessa solução para daqui a alguns meses,
não posso esperar até que o OpenERP tenha uma solução PDV a contento.

Grosso modo, o processo seria:

Evento: Nova venda finalizada no POS
 * POS gera arquivo XML condizente com o XML Schema fornecido
 * Agente POS envia arquivo (POST) para uma URL "outbox" fornecido pelo
Camel
 * Camel valida o arquivo usando o XML Schema
 * Camel direciona o arquivo para a URL "inbox" do servidor
 * O módulo de integração do OpenERP, via pooling, verifica por novas
mensagens
 * O módulo busca e transforma o conteúdo da mensagem em um objeto do
OpenERP
 * O módulo executa o workflow de vendas (ou uma variante).
 * Se não houver exceções, remove a mensagem do "inbox" (ou move para um
endpoint "dead")
 * Se houver, "marca" a mensagem como rejeitada. 
   * O Camel a rotearia para um endpoint "rejected" para análise futura
e reprocessamento.

Em umas duas semanas já quero ter um protótipo para testar essas idéias.

Abs,

Cloves

Em Qua, 2009-09-09 às 15:29 -0300, Raphaël Valyi escreveu:

> Cloves,
> 
> 
> 
> um problema apenas technico que eu vejo:
> 
> 
> Voce fala que voce quer usar de um "pattern" de messagem XML. So que
> infelizmente o OpenERP tem pouco supporte para messagems. Ele trabalha
> bem com XML (RPC) em tempo real, mas nao esta integrado com um
> "service bus" (ESB) de messagems asynchronos, tipos JMS como com Mule
> ou ServiceMix (alias milito para que ele rola no Jythpon e servidor
> J2EE para se integrar bem com ESB's SOAP e outras coisas legacy), isso
> acontece no final do ano eu acredito
> (leia http://rvalyi.blogspot.com/2009/05/openerp-jython-unladen-swallow-where-do.html  se o assunto te interessa).
> 
> 
> Ja que o OpenERP é veloz e que esse tipo de coisa nao consume muito
> (se for rede national esquece o OpenERP por enquanto), da para
> trabalhar em tempo real com o XML/RPC dele e o mais facil, pois todo
> que se faz pela interface existe em XML/RPC e a brincadeira de criança
> por novos servicios respeitando workflows e regras de accesso.
> 
> 
> Porem, com um pouquinho de cuidado, da para trabalhar a tempo real e
> porem ser seguro tembam. Por exemplo, quando faz uma operaçao que nao
> seja "idempotente" tipo criar, escrever recursos, voce pode se
> proteger contra o fato de que o servvidor pode nao receber a messagem
> e vc ter problemas mandando de novo. O 'truc' e de mandar tambem um
> numero de transaçao. Se mandar de novo, os servidor checa esse
> transaction id, caso existe nao cria/altera de novo. Enquanto vc nao
> recebe confirmaçao que o servidor mandou, continua mandando a mesma
> messagem para ele.
> A gente fez isso na Smile.fr para um projeto gigante de transporte
> urbano com Veolia, da bem certa.
> 
> 
> Cuidado tambem que messagems XML, toma cuidado com SOAP. A bibliotecas
> de SOAP em Python sao pessimas a relaçao de lidar com namesppaces e
> todas essas coisas que so no J2EE/.Net da certo (e nem quando e
> heterogeno).
> 
> 
> Agora, se voce realmente quer "pattern" de messagems, talvez o melhor
> seria du usar da blioteca de ETL que a Tiny esta acabendo de
> desenvolver. A Interface grafica ainda esta nao pronta, agora o
> backend funciona, acabamos de usar para meu cliente Anevia (para
> importar pagamentos do banco).
> 
> 
> Imagino que voce pode se inpirar do conector Magento - OpenERP que eu
> criei: http://code.google.com/p/magento-openerp-smile-synchro/
> pois vai ter varias coisas semlehantes entre interface POS e ecommerce
> (estamos melhorando esse connector, tenho novo cliente com ele a
> proxima semana, a Smile tb tem um e trabalhamos com o Indiano Sharoon
> Thomas ou o espanhol Jordi Esteve que tambem ajudam para cassette,
> queria extrair uma interface generica dele para usar com outros
> ecommerce, Spree sendo aquele que eu mais acredito no futur, porque
> tem codigo e banco de dados limpo a contrario do Magento ou OSCommerce
> que tem muito lixo dentro).
> 
> 
> Por final, nao sei muito se esse estragetia de messagem genericos vai
> dar certo. Por enquanto Tiny ta completemente utrapassada pelo sucesso
> mundial, nao vai conseguir lidar com uma especifiçoe dessa, tem que
> vir da comunidade. E tem cara que nem o sraps no forum (aquele cara
> que te respondeu) que ta meio batento forte contra Tiny (ve os emails
> dele), entao nao sei depende bastante dos recursos que voce bota la.
> Para mim o mais imediato sera intergaçao caseira usando XML/RPC com
> coisas tipo Openbravo POS (ja esse e bem melhor do que o ERP tem nada
> ver na verdade, e o ex TinaPOS que tem varios sucessos) ou outro
> software de POS. Agora concordo, fazendo isso, vc nao alcance um
> grande publico porque e apenas uma soluçao de POS.
> 
> 
> Tambem acredito que vai passar a existir um bom POS com o OpenERP
> mesmo, mais nao antes de um ano, porque nao é prioridade. Dai talvez
> no longo prazo esses esforços de integraçao passam a ser inuteis, e
> possivel. Por ter trabalhado com interface de ERP com outra coisas,
> aviso que da sempre muito mas trabalho que se acha no inicio (como
> lida com erros, pulgins de cada lado, verçaoes de cada lado,
> conectividade, segurança, gestao dos parametros de conexao....), se
> tivesse um bom POS no OpenERP seria o melhor provavelmente. Integraçao
> so funciona bem quando a superficia de interface e muito limitada, por
> exemplo ICS para calendario, arquivo com DMS... Agora, isso e um
> trabalhao...
> 
> 
> 
> 
> Outra coisa que pode te interessar, botando uma camada super macia e
> bem feita de um plugin Rails entre o OpenERP e seu cliente, o OpenERP
> passa a falar REST em HTML, JSON e XML. optionalmente, usando JRuby on
> Rails, um cliente Java (ou JRuby ou Jython...) consegue trabalhar com
> quelquer objeto OpenERP remotamente e transparentemente, abstraindo os
> webservices. Ainda nao fiz muita "propaganda" do plugin mais mesmo
> assim ele nao esta mais "padulando na batatinha" e ja esta usado em
> produçao naquele site de ecommerce:  http://www.homecinesolutions.fr .
> O a documentaçao sobre o plugin e aqui por enquanto:
>  http://ooor.googlecode.com/svn/trunk/README
> 
> 
> 
> 
> Bom, desejo sucesso, manda noticias sobre o assunto.
> 
> 
> 
> 
> Raphaël Valyi
> http://www.akretion.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 2009/9/9 Participante da lista <work-dont-complain@xxxxxxxxxxxxxxx>
> 
>         Cloves,
>         
>         
>         > crei um blueprint sobre o andamento da solução para PDV e um
>         wiki com um
>         > rascunho da especificação. Em resumo, a estratégia que eu
>         pensei para
>         > implementar foi a de usar "mensagens" XML para integrar com
>         soluções PDV
>         > de terceiros.
>         
>         
>         Esqueci de mencionar no último e-mail.
>         O link para o blueprint no Launchpad:
>         <https://blueprints.launchpad.net/openerp-brasil/+spec/pdv>
>         está quebrado.
>         
>         []s,
>         
>         JCF
>         
>         --
>         ----------------------------------------
>         Do it first, then complain.
>         ----------------------------------------
>         
>         _______________________________________________
>         
>         
>         Mailing list: https://launchpad.net/~openerp-brazil-team
>         Post to     : openerp-brazil-team@xxxxxxxxxxxxxxxxxxx
>         Unsubscribe : https://launchpad.net/~openerp-brazil-team
>         More help   : https://help.launchpad.net/ListHelp
>         
> 
> 
>