openerp-expert-framework team mailing list archive

[Jean-Sébastien Suzanne <jssuzanne@xxxxxxxxx>]

2012/12/17 Cloves Almeida <cjalmeida@xxxxxxxxxxxxx>

>  Hello Raphael,
>
>
> Well yes, and today we already live with that. Because synchronization is
> slow and not guaranteed, today the catalog exportation, inventory
> exportation and shipping synchronization are all scheduled jobs anyway and
> these aren't any bottleneck even I would say in the current connector.
>
>
> For the scale OpenERP is built, I wouldn't believe integration of any sort
> would be a bottleneck :)
>
>
> Nope, unfortunately, with its EAV tables and internal modeling Magento
> ends up with a pretty different data model and API than OpenERP.
>
>
> I didn't made myself clear: I was talking about using OpenERP data model
> as basis for the "canonical model". In a nutshell, the "Canonical Model" is
> an integration pattern that establish a standard company-wide data model
> for message payload and every system must import-from/export-to such data
> model.
>
> Say you develop a SugarCRM-OpenERP connector and a Magento-OpenERP
> connector.  If both connector follow a common message payload model, a
> "Customer Email Update" message originating in SugarCRM could be directed
> to both OpenERP and Magento.
>
> Overall, I would say that they are many things more important to evolve
> than the Queue API in these connector. Nevertheless, if it's contributed,
> it's still a nice to have thing. Also I totally respect the RabbitMQ module
> form Anybox.  I just said once on Twitter that unfortunately,
> Magentoerpconnect and its dependencies is already a hassle to track and
> install...
>
>
> I was thinking using the experience for building an integration framework
> for the new connectors. If existing ones are working, no reason to mess
> with them. But achieving good integration is both hard and needed. Anything
> but the most basic implementations need to talk to existing systems
> (payroll, taxes, POS, e-commerce, EDI, etc.).
>
> Fortunately integration is becoming a mature discipline and there are a
> lot of good open source resources to built upon. Adding a few more
> dependencies (using apt or pip) is a good trade-off for such useful tools
> like RabbitMQ. As for OpenERP module management...
>
> Regarding the Anybox module: really impressive work. My only (and probably
> deal-breaking) issue is that most configuration is done using OpenERP
> objects.
>
I understand, you can define already declared queues and exchanges, but not
the consumer or the publisher(or producer). Uou must have a min of
configuration to define your consumer or publisher, else the connector is
not in OpenERP and he must call OpenERP by web service.

> IMO, the openobject framework is very powerful but should be used mostly
> for user-centric "transactional stuff". Configuration should be as
> expressive as possible. For exemple, the Apache Camel example below takes
> an incident received through a WebService call,  generate a text file using
> a Velocity template, store the file in a directory, log what happened and
> return OK:
>
>  	// first part from the webservice -> file backup
>         from(cxfEndpoint)
>             // we need to convert the CXF payload to InputReportIncident that FilenameGenerator and velocity expects
>             .convertBodyTo(InputReportIncident.class)
>             // then set the file name using the FilenameGenerator bean
>             .setHeader(Exchange.FILE_NAME, BeanLanguage.bean(FilenameGenerator.class, "generateFilename"))
>             // and create the mail body using velocity template
>      &nb
>  sp;&nbsp
> ;     .to("velocity:etc/MailBody.vm")
>             // and store the file
>           &nb
>  sp;&nbsp
> ;.to("file://target/subfolder")
>             // return OK as response
>    &nbsp
>  ; &
> nbsp;      .log("Wrote ${file:name} and returning OK response")
>             .transform(constant(ok));
>
> Written in Java! I'm thinking of building something using Jython and
> Camel. I'll make some tests to see if it works.
>
> Best Regards,
>
> Cloves
>
>
>
> Em 17/12/2012 10:58, Raphael Valyi escreveu:
>
> Helo Cloves,
>
>  nice to see to are still hanging around, some inline remarks:
>
>  The drawback is that for a brief moment, you lose synchronization -
>> you've got a new product  on OpenERP and no product in Magento. But in most
>> cases, one can live with that.
>>
>
>  Well yes, and today we already live with that. Because synchronization
> is slow and not guaranteed, today the catalog exportation, inventory
> exportation and shipping synchronization are all scheduled jobs anyway and
> these aren't any bottleneck even I would say in the current connector.
>
>>
>> The other major advantage, is that you decouple both systems. OpenERP
>> need not to know about Magento. All it need to know is that it must post a
>> message in a canonical data model (probably very close to OpenERP data
>> model)
>
>
>  Nope, unfortunately, with its EAV tables and internal modeling Magento
> ends up with a pretty different data model and API than OpenERP.
>
>
>> to given queue when it create/update a product. The receiving part
>> (usually a thin adapter) need not to know about OpenERP, only that when a
>> message arrives in a given queue, it need to process the message. If you
>> ever decide to change Magento to Prestashop or Spree, no change to OpenERP
>> is necessary, you just have to change the thin adapter.
>>
>
>  This is more or less what we do already, just change the interface by
> overriding things, even if we have no queue yet. It's only this way we were
> able to create a new Prestashop or OpenbravoPOS connector that quick..
>
>>
>> BTW, I'm using ActiveMQ (JMS+Stomp) to integrate OpenERP, our legacy
>> manufacturing system and POS'es which are geographically dispersed on
>> crappy ADSL connections.
>
>
>  That would indeed help increase the reliability and monitoring of these
> jobs as Guewen said.
>
>
>  Overall, I would say that they are many things more important to evolve
> than the Queue API in these connector. Nevertheless, if it's contributed,
> it's still a nice to have thing. Also I totally respect the RabbitMQ module
> form Anybox. I just said once on Twitter that unfortunately,
> Magentoerpconnect and its dependencies is already a hassle to track and
> install, specially for non specialized third parties and this largely comes
> from the OpenERP naive module management system I already highlighted in
> other posts. Adding some 3 queue modules more and a new piece of
> infrastructure will certainly not help here although once installed the
> connector could be better. So eventually if we could reuse a simple queue
> built'in Postgres with the ability to send message upon in from outside
> OpenERP using some standard protocol, I'm all for that, I'm not sure yet
> the connectivity part is easy, I've seen a Ruby solution over Postgresql
> but none in Python.
>
>
>  Regards.
>
>  --
>  Raphaël Valyi
> Founder and consultant
> http://twitter.com/rvalyi <http://twitter.com/#%21/rvalyi>
>  +55 21 2516 2954
> www.akretion.com
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 

Jean-Sébastien SUZANNE

jssuzanne@xxxxxxxxx

06 51 35 50 50