openerp-brazil-team team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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
>