Hello!
Our customer is running a large scale ERP for onsite as well as online sales.
Can we interface into this system, as it provides Web Services of all kinds (inventory, checkout, customers..)
Basically, we do not want to use nopCom's database, but directly hook into the existing msSQL database via WebServices. (Two way- get Items,Categories,registered Customers, and write sales back to that database)
Could this be done with nopCommerce?
Thank you!
Reinhard
Integration with existing ERP
- 68
- 1573
- 8/4/2009
- United Kingdom
Yes, you could interface with another system via webservices.
You will have a lot of work to do of course, and probably face a lot of challenging problems.
On a very superficial level...
You'll need to re-write most of the data access stuff to read from and consume a web service, then transform it into something meaningful for nop to reflect as data.
In reverse, you'll have to write data from nop in a format for the ERP app to use.
There are a lot of things in nopCommerce that you'll probably want to ignore, so you can just leave them out. There may be things in nopCommerce you will want to use and utilise, but don't have in the ERP stuff, so you may choose to use some nop database and functionality.
You have the issue of product/category images and management to think about before even thinking about the complexities of product, variant, attributes and combinations.
What will you do with membership (user accounts). This might be quite simple if you capture these details into nopCommerce for login and buying purposes and distribute to the ERP app for order storage.
The more I think about it, the more I see the 'easy' way is to duplicate data, which is never a good thing, so this makes the transformation and consumption of data all the more significant.
One thing in your favour is that nopCommerce is really well written and strongly structured with objects, collections and managers that reading into a dataset for mapping from a webservice rather than a SQL stored proc doesn't actually seem that big a task other than the transformation stuff.
My 'PITA' jobs are looking a little easier now anyway. :)
You will have a lot of work to do of course, and probably face a lot of challenging problems.
On a very superficial level...
You'll need to re-write most of the data access stuff to read from and consume a web service, then transform it into something meaningful for nop to reflect as data.
In reverse, you'll have to write data from nop in a format for the ERP app to use.
There are a lot of things in nopCommerce that you'll probably want to ignore, so you can just leave them out. There may be things in nopCommerce you will want to use and utilise, but don't have in the ERP stuff, so you may choose to use some nop database and functionality.
You have the issue of product/category images and management to think about before even thinking about the complexities of product, variant, attributes and combinations.
What will you do with membership (user accounts). This might be quite simple if you capture these details into nopCommerce for login and buying purposes and distribute to the ERP app for order storage.
The more I think about it, the more I see the 'easy' way is to duplicate data, which is never a good thing, so this makes the transformation and consumption of data all the more significant.
One thing in your favour is that nopCommerce is really well written and strongly structured with objects, collections and managers that reading into a dataset for mapping from a webservice rather than a SQL stored proc doesn't actually seem that big a task other than the transformation stuff.
My 'PITA' jobs are looking a little easier now anyway. :)
- 2
- 10
- 3/4/2011
- Australia
[email protected] wrote:
This is the route I ended up going with - keep the nop database there and keep it in sync. It's actually quite simple if you can modify the source code for the ERP directly, as I can (it's my program).
Let the customer configure nop to do everything they need, then just update the category, product, customer and image related tables. I do it on every save and delete in the ERP so the nop database is a mirror of the ERP database. This also removes the ERP's need to configure all sorts of ecommerce only things like shipping, payments handlers, etc.
From concept, a bit of experimentation, to coding the loading of categories and products has taken about 2 days. I'm also writing it in such a way that I can do the same updates to any other ecommerce platform if the customer wishes, because conceptually they are all pretty much the same - it all comes down to working out what fields you need to fill to get the desired result.
If you don't have access to the ERP code, I guess you could do it from triggers on the SQL database.
Hope this helps.
I'm also considering either doing this or interacting with the NopCommerce Database. Be very interested to hear how people have found this
This is the route I ended up going with - keep the nop database there and keep it in sync. It's actually quite simple if you can modify the source code for the ERP directly, as I can (it's my program).
Let the customer configure nop to do everything they need, then just update the category, product, customer and image related tables. I do it on every save and delete in the ERP so the nop database is a mirror of the ERP database. This also removes the ERP's need to configure all sorts of ecommerce only things like shipping, payments handlers, etc.
From concept, a bit of experimentation, to coding the loading of categories and products has taken about 2 days. I'm also writing it in such a way that I can do the same updates to any other ecommerce platform if the customer wishes, because conceptually they are all pretty much the same - it all comes down to working out what fields you need to fill to get the desired result.
If you don't have access to the ERP code, I guess you could do it from triggers on the SQL database.
Hope this helps.