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/>
_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help : https://help.launchpad.net/ListHelp
