I have a funny feeling I am missing something important here, so perhaps I just need sufficient "clue" to get further along.
I want to be able to display our products on our Drupal site, but using the existing postgresql product data from SQL-Ledger (ie, not have to import repeatedly or run two copies of our product data).
I currently run SQL-Ledger with more than 134,000 product lines, only a few thousand of which are typically active, but any and all could be ordered in for customers on demand. We run a retail store so we have inventory control, POS, shipping etc already via SQL-Ledger.
At this stage we won't be looking to integrate sales processing with Drupal, only displaying product details and pricing. We might then move to cart functionality later, and later again payment/shipping processing, but for now all of that would be handled internally with a manual process and SQL-Ledger.
I have been looking at some of the ecommerce docs and the import/export API info as well, but either I'm missing something or it doesn't quite head in the direction I'm looking for. Given that I am only after the product display functionality, would I be better off writing a standalone module to glue drupal and my product db together, avoiding the ecommerce package entirely until I need more of it's features, or is there an elegant way to support an external product database from within eCommerce?
Or am I thinking entirely backwards on this?
Any suggestions (that don't involve dropping sql-ledger) would be most appreciated - including clue-by-fours to the head!
Cheers,
Ash
Comments
based on Drupal nodes
Drupal ecommerce's charme is that in theory any node (content type) of Drupal can be sold, rented or auctioned or at least that was the intention of the module set. From what I read, your situation is different. Your products are stored in an database external to Drupal and e-commerce does not fit your bill unless you are willing to import your full product database into Drupal nodes as product nodes. The other day I saw a videocast how easy it can be to import data to nodes, but I never did it myself for products in the ecommerce.
You also have to be willing to make that step and I don't know if it is really that convenient afterwards. For instance in Drupal ecommerce you won't easily find price and product description together in one table. So exporting from Drupal ecommerce is not simply a matter of dumping a table.
This all depends. If the
This all depends. If the external database is something that you can query in real time, then just create a special product which will do things like get the product information from the external data in real time. The price can be adjusted using the productapi('adjust price') and at that time query the external system.
Then just add a cron query and import any new products as they become available.
Yes you do need to keep a copy of the product locally on the system, but this only needs to be a skeleton of the product so that the Drupal can do things like index the searchs, and so that E-Commerce can anchor products for transactions to a nid.
At actually did a proof of concept to access there stock control database in real time, get the product information from there.
Again you only really need a place holder node, you do not need the entire product information, since most of the calls can be intercepted from the productapi() and the others can be done via the nodeapi.
If the inventory system is not accessible in real time, then you can just create a custom import process which load product into the database.
--
Gordon Heydon
Similar problem, other take
I have a problem a bit similar: a fairly large catalog (+/- 100k products), imported from +/- 20 external databases and price lists updated by third parties from daily to monthly, or in some cases maintained by hand directly on EC.
The approach being developed is to manage synchronization between this set of incompatible pricing sources and the EC-based product catalog as a one way process, always pushing product updates to EC, considered as the reference product DB at any time, to avoid discrepancies with what customers see. The twist to making it work was the idea of using even the EC repository as yet one more import source, with a degenerated update workflow looping on itself.
Updates are performed importing and converting the various formats to some directly usable variant (no direct EC conversion to remain lightweight on the upstream converters) on a back office system (non-Drupal), then uploading from there to EC using XML-RPC. EC to EC update downloads the products using the same route. Upstream import, converters and publishing to EC are local apps being done in PHP-GTK. It's portable, reasonably easy to use, and surprisingly fast (actually faster than an older version done in Delphi), but the downside is the very long upload time using XML-RPC. A full DB sync takes a bit above 24 hours currently.
For now, stock management has simply been avoided by considering no product as being directly available, but using a "typical delay" attribute.