The actual batches synchronizations have to be replaced by a queue system with tasks. It means that each action on OpenERP that would require to interact with Magento would become a task pushed in a queue and one or more worker would execute the tasks.
A very basic and naive queue could be implemented using the OpenERP's crons, either each task being a cron itself either one cron running tasks from a table.
It could be extended and improved using a message broker like RabbitMQ and a task queue library like Celery, enabling multi-process, easily registering of new tasks from other systems and all the Celery abilities.
Once the task queue exists, the tasks still have to be created.
For the actions triggered by OpenERP (modification or creation of a product, status change, creation of a picking, ...), we'll have to push a new task immediately.
An observer pattern should be implemented on the 'observable' events (create, write, but also more specific like adding a tracking number, ...). Each connector would be able to plug its own tasks creation on the events.
For the actions which are done on Magento and have to be imported (a new sale order has been created, it has to be imported, a payment has been done, ...). We'll have to adapt the current cron jobs. Actually, they import the new sale orders (or create the payment, etc.) directly. Instead, they will just search the new orders (payment, etc.) and create the appropriate tasks.
Later, we could replace (or put as an alternative) the latter cron jobs by a direct push (with XMLRPC or RabbitMQ) of the tasks from Magento. So, for example, once a sale order is created on Magento, it pushes a task on OpenERP. This latter will process it and import the sale order nearly instantaneously (a priority has to be defined on tasks).
The importer class has to be redesigned in the task queue spirit. It would be simpler at end because it won't have to handle batches synchronizations.
Same than for Generic Importer_
The goal is to replace the actual mappings stored as CSV by pure (extensible) Python code.
Have to be re-implemented on top of the Generic Importer_:
- Products (with:)
- Links between products
- Images
- Products Categories
- Customers
- Addresses
- Sale Orders
- Customer Groups
- Referential Settings (websites, ...)
- Attributes, Sets, Groups
They can be implemented gradually on the new Importer.
Have to be implemented on top of the Generic Exporter_:
- Products (with:)
- Links between products
- Images
- Products Inventories
- Products Categories
- Customers
- Addresses
- Sale Orders
- Sale Orders State
- Shipments
They can be implemented gradually on the new Exporter.
All the mappings have to be ported from the CSV files to the Generic Mappings_.
This will probably be done alongside with the other changes, progressively when we'll implement the importers and exporters.
On a side note: actually, the mappings transform data from Magento to OpenERP and the reverse. They also import some records if they are missing (a product order for instance). This change the state during the mappings and should be avoided. The dependencies will have to be imported in the Importer.
Clean dead code and simplify.
Actually, the calls to the Magento API are done directly throughout the code of the connector. It prevents the customization of the interactions with the API in sub-addons (it happens that a call for a service has to be replaced by a custom one). It has to be decoupled and extracted in its own class, and a pattern allowing to customize the service used.
Strong tests must be implemented (using unittest2 on OpenERP 7)