| Thread Previous • Date Previous • Date Next • Thread Next |
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. 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
.to("velocity:etc/MailBody.vm")
// and store the file
.to("file://target/subfolder")
// return OK as response
.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 <http://www.akretion.com/>
| Thread Previous • Date Previous • Date Next • Thread Next |
