Talk:Projects/Ecommerce Integration/Technical Documentation

Purpose

What are your arguments in favor of a real time based system? At http://smile.fr we thought about that quite a bit and came to the conclusion that it was easier and probably better to have a batch based sync rather than real time.

Easier: Indeed, this is easier to achieve because you only need to populate the e-commerce database in a very few operation rather than extend the e-commerce system at various places to ensure it will always talk to the ERP rather than its own backend. By targeting real-time, you are relying a lot more on the e-commerce architecture and extensibility. That's probably more risky specific e-commerce coding.

Better: with a batch based sync, you are preserving the independence of the two system. You can more easily start tweaking at your ERP system without having to shut down your e-commerce.

Still effective: Every time you sync the system (possibly very often), you update stocks so their is little risk of an unanticipated stock shortage (unless you are selling a lot outside from the e-commerce compared to your stock levels but that's quite unlikely).

Also, I strongly suggest driving the sync system FROM THE ERP and not the contrary. Why? Because ERP's are supposed to be designed for back-office easy extensibility (forms+database structure+webservices). E-commerce systems rarely have those clean extension capabilities; they usually don't have something like an application dictionary. So extending the back office of an ERP to support the required forms and buttons is supposed to be easier. Also, by doing so, you are building a unique ERP back office and sync system that could be reused in a variety of e-commerces.

Design issues

Keep in mind that the e-commerce will output its sale orders referencing its own product ids in its sale order lines. So, in order to print an invoice and trigger the accounting properly, you should, within the ERP be able to associate the sale order line corresponding products within the ERP referential! The same goes for business partner references, addresses, product and tax categories. That's why a requirement is to be able to easily extend the ERP datamodel in order to add an e-commerce id column to all those business objects. If you look at the OpenERP module Smile did for its Magento connector, we are extending OpenERP objects to add those columns when you install the plugin, see code here: http://code.google.com/p/magento-openerp-smile-synchro/source/browse/magento_openerp_smile/magento.py

I think a similar system is required in the case of Openbravo. Also having a simple way to package those MVC extensions properly might be a requirement before even building a connector. Not sure about what is the preffered way to package such MVC extensions in the current OB versions.

Also, why not keeping those sync IDS in the e-commerce? Well, because again e-commerces had other priorities than data model extensibility while this is supposed to be easy an ERP. Also, once you compare Magento way or eZPublish way of storing product attributes - everything in a 'god' attributes table with very fat requests then to retrieve everybody properly - to the clean normalized tables you have in ERP's such as Openbravo, then you are likely to keep everything you can rather inside the ERP database.

Also, on the e-commerce side, web services should be have a few requirements: 1) They should be RESTFul at least in the sense that creating or updating a resources should return the resource ID so we can then properly populate the corresponding e-commerce ID in the ERP database for each created/updated resources. Magento native webservice are fortunately done this way, meaning that a few ones could be used natively.

2) But sometimes pure REST is not the easiest way. Take product creation, what if the product category doesn't exist in the e-commerce? At Smile, we made the choice to create the e-commerce category on the fly. But then what we should answer are two ids, the product ID and the e-commerce category ID, so we can keep them in sync. That's not exactly REST but rather a compromise. REST would still be possible here of course but that would mean more webservices calls, slower here (while not in general) and more complex here. See our PHP code here for Magento: http://code.google.com/p/magento-openerp-smile-synchro/source/browse/magento_openerp_smile/Magento_extension/Smile_OpenERP_Synchro/openerp-synchro.php -> IMPORTANT UPDATE : Actually REST is the only way to go. It's impossible to create product categories on the flight as suggested because it's product categories would probably get generated in a random order while Magento requires that all appropriate parent categories are properly set up before you can add some child categories. So the only proper way to proceed is to create the categories tree first and update product categories ids eventually if category exist on product update. This is how we did with the version 0.9.6 of our connector.

3) Sale orders webservices should include sale order lines or at least the sale order lines ids or corresponding product ids. Native Magento webservices were not including those lines so we couldn't use them natively and had to build our own, that's largely what justifies we have our own PHP extension for Magento insead of having just noting. This is an option, an other option would be to toss the Magento guys so they have more appropriated native web services. Guys, that one is also true for Openbravo: either you have rock solid perfect RESTful and all shiny webservices (but that's unlikely as you just see for Magento), either you simply have an extensible webservice system that doesn't involve getting their hands dirty with Axis and all the bloatware. I saw such plans for 2.5, that connector case is just onw illustration why those clean and powerfull web-services are so important. And with Jersey and JAX-WS, you have no excuse not to build shiny webservices ;-)

Finally, http://www.smile.fr had a great experience coding such a connector for Magento and OpenERP and we are using Magento daily for real customers. We would be very happy to help you folks, but we would have to discuss business opportunities then. Don't hesitate to contact us to discuss them.

Open source e-commerce systems

I don't advice to even look at OSCommerce: it's a dying PHP4 system. Magento which as be built by Varien, a former OSCommerce integrator is clearly the viable successor of OSCommerce. As for the others, fine.

Web services

It is necessary to extend the current Openbravo ERP web services to support ecommerce integrations.

Enhancements needed

• UpdateCustomer can only update already existing customers not to create new ones. Extend UpdateCustomer or create an createCustomer method?

User stories

Suggested changes

As for the stock shortage, I think that the ERP has to update stock levels (just like prices and product attributes) every time a synchronisation is triggered (cron job or by hand). Then I think that notifying the user about a stock shortage is the entire business of the e-commerce frontal, not of the connector.

Questions

Product Variants

How to deal with product variants? This is a common requirement in e-commerce systems. Like if you are selling T-shirts, what you want is that you have size and color variants for instance so you rather use the variant system to populate your catalog instead of having to bloat you catalog with a many product as the Cartesian product of the variants. So usually, a variant system allows some kind of properties inheritance so that you can manage your catalog with only afew templates no matter the number of variants. Is there such a system in Openbravo that could then match what is usually offered in good e-commerce frontal? If yes, how to map variants? Indeed, Once in the e-commerce frontal, this is likely the administrator want to alter there definition in some ways, so preserving the variant system in the frontal would be highly appreciated.

Rvalyi comments