As though being belittled by Microsoft's decision to not support Commerce Server 2002 (the latest RTM version of Commerce Server) with ASP.NET 2.0 and SQL 2005 (the latest RTM of their respective technologies) wasn't enough, another exciting source came along that wanted to know why our website had its own client information that wasn't in sync with the rest of our enterprise data. Why couldn't people change their address/contact etc data on the website and have all our systems reflect the change? Why would people call in and change their email address in customer service and still get emails to an old address from our site?
These are the things that truly allow you to change the way you do things. Especially in Commerce Server, where the UserObject table reigns supreme.
How do you do this? Kludge something together with triggers that updates the one data store when the other is changed? Change the profile system to write somewhere other than the UserObject table (It looks like this would be possible, but painful at best)?
After looking at the current site, the first thing that came to mind was, "Why are we still using Commerce Server anyhow?"
The short answer is "because we are", The longer answer is we have a robust eCommerce Solution that has Commerce Server at its core. It managers the catalogs of products, the order/basket system and the customer profile and contact/address data.
Looking at these components individually, What can I replace before something breaks? What does ASP.NET 2.0 bring to the table that can help/improve what is already in place?
The business requirement was to get the customer information into the central enterprise store. This fits in perfectly with the Profile/Membership components in 2.0, that are very customizable to datastore with a pluggable data provider model. Check. Done.
The only painful part to this piece was that we are using LLBLGen for our data access tiers, which is an awesome tool, but building a provider out of it meant not using any functionality built into the existing SQLProvider and having to implement *ever* method by hand from a Base Provider. Not something to do if you only have an afternoon.
The next piece was dealing with the Commerce Piece and the requirements for the pipeline. Part of moving all the customer information out of UserObject was also moving all the addresses out of the address tables. The pipeline requires address information to complete and order (of course), so the addresses are currently being genned on the fly.
What about the baskets? Commerce Server users the GUID from the UserObject table to tie a basket back to the customer, and we conveniently already had a GUID field in the users table for our enterprise store. (Things actually ended up being more complex, since we have a need for a customer to have more than one basket of different types. This was solved by adding a baskets table that was not in Commerce Server's database that had the customer's id key, genned GUIDs, and a basket type. The genned GUID were used to link the customer to the basket table in Commerce Server.)
At this point, everything is working perfectly. The UserObject table is no longer being used. The only thing that is still being used is the catalog tables, and the ordergroup etc tables.
What does the future hold? That is a good question. At this point, with Microsoft's *attitude* towards us even though we are using current technology, it would not be that difficult to remove the remaining dependencies on Commerce Server. Will we do that? I don;t know. In Commerce Server 2006, the ASP.NET 2.0 profile etc pieces are already used, and I was pretty careful to make sure that our providers could be used in that environment with little change. So, moving to Commerce Server 2006 could be done with little pain.I guess it will come down to what Commerce Server 2006 has to offer. Commerce Server in general is a very powerful application, do you stop using an application that fills your needs nicely because of the creators behavior? That is the price of staying with Commerce Server, and it will need to be weighed carefully.