# Wednesday, 03 June 2009

Microsoft-Commerce-Server-LogoBack in 2007 I was faced with designing a multi-currency catalog solution for Commerce Server. I knew from previous experience that we would need a general purpose solution, which we could employ for many clients.

Back then Commerce Server 2007 was new thus performance characteristics were new territory as well. I ended up designing a solution based solely on virtual catalogs. Basically one catalog for each price group/currency. You can read the details on multi-currency/price groups, which we’ve employed successfully numerous times since then.

Since 2007 we’ve gotten a new version of Commerce Server though no significant new features were added in the catalog system, and we’ve gained valuable new knowledge on both the pricing scenarios and limitation of the Commerce Server catalog system. With that information in hand I’m going to try my hand at redesigning the original multi-currency catalog structure from 2007 to both address performance issues and increased flexibility.

Virtual Catalogs are Slow

Virtual catalogs are slow and so they make a poor choice to expressing essentially a single piece of data. You might say that virtual catalogs perform perfectly well if you materialize them and you would be right. You gain in the order of 10x performance by materializing a virtual catalog but lose the ability to make any changes in them in the process.

Basing my original multi-currency solution on virtual catalogs seemed to make perfect sense, but with the added requirement of changing the category hierarchy two levels of modifiable virtual catalogs were needed, thus the ability to materialize was lost.

To make matters worse we rarely deal with clients who are inclined to go with an Enterprise license for their Commerce Server solution, so we don’t see very many full fledged staged solutions, which would take care of the challenge handily.

Virtual Catalogs Two Levels Deep

Virtual catalogs are by nature limited to two levels, i.e. you can have a total of three levels of catalogs, one with base catalogs and two with virtual catalogs. Are we to use one of these levels of virtual catalogs for pricing we lose it for other purposes, and gain very little other than the ability to store another price group per catalog.

Pricing is a Separate Issue

What I’ve come to realize over the years is that product pricing is a completely separate issue from the product itself. While the two might seem like one and the same; in reality they aren’t. Sure the customer needs to be told a certain price, but more often than not the price is determined by context surrounding the product, rather than the product itself.

An example would be a seasonal business, which is highly dependant on calendar time, the product would probably sell for a higher rate at specific times of the year and lower rates the rest of the year, e.g. ChristmasTreesOnline.com. The context in this particular instance is time.

Now for business to business scenarios the context might be especially convoluted as you might go for pricing granularity, which allow organizations, groups within the organization, even individual people in the organization to have specific prices, e.g. memberships to the gym provided by your company or framework agreements made between supplier and customer. The context deciding the price is who you are in this case, not the product itself.

Pricing is a Service

To handle the separate issue of pricing we need something akin to a service in domain driven design parlance. The service is responsible for looking up the right price based on whichever context is present for a given customer request.

Of course we need some sort of structure to maintain the pricing for individual price groups, and catalogs come in handy to solve this as I’ll show you next.

The Product Catalog

Our product catalog would in the new scheme continue to exist as we know and love it with one minor exception. The list price of the product is either to be ignored or used only to get an idea of what the pricing is like. The list price will not be picked up from the product catalog, which contains the marketing data for a product. Please note that I define marketing data in this instance as data used to display to potential customers, but other than that serve no purpose to the system.

The Pricing Catalog

In Commerce Server we have the notion of different types of catalogs, i.e. the product catalog and the inventory catalog. I’m going to introduce a third kind called the Pricing Catalog. As you might imagine a pricing catalog concerns itself only with price and as such contains only the bare minimum of data to identify a product.

The pricing catalog will have metadata to indicate that it is in fact a pricing catalog. Each pricing catalog reflects a single price group such as “Internet Users”, “Gold Customers”, whatever makes sense for the particular scenario.

Having pricing split out like this means that we can price products based on the calendar time context as a standard Commerce Server catalog has dates associated with it to allow us to display it within only a given period of time.

For a pricing catalog these fields are used to determine whether a price is valid or not, so you could have the seasonal pricing expressed as two different pricing catalogs for our ChristmasTreesOnline.com, one for holiday pricing and one for the rest of the year. The pricing service would then grab the pricing from the proper Pricing Catalog and display it to the customer.

Pricing Definitions

Finally I propose a new kind of definition called the Pricing Definition. What this is is a specialized Product Definition used for creating Pricing in the Pricing Catalogs for advanced scenarios, e.g. complex pricing matrices defined in external systems such as an ERP.

Products, i.e. Prices, created based on a Pricing Definition would contain at least the SKU, name, description, and of course the list price. These specialized products go into a Pricing Catalog as we discussed in the previous paragraph.

Tying it All Together

Another context we discussed in a previous section is the organizational context, which might also influence product pricing. Fortunately Commerce Server comes with CatalogSets as a neat way of bundling catalog together. CatalogSets leveraged with our Product Catalogs and Pricing Catalogs would allow us to do multi-currency and, incidentally, a bunch of even more interesting scenarios.

Imagine if you will a scenario where our online retail outlet would like to give Internet customers access to only currencies, which make sense for their particular region, e.g. here in Denmark Euro and our national currency Kroner would make sense, while UK customers should be enabled to shop in either Pounds or Euro.

Simple! Create two catalog sets one called Denmark and one called UK. For the Denmark catalog set select our one product catalog containing all products or the one which reflects the range available in Denmark and select the two Pricing Catalogs Kroner and Euro. For the UK catalog set select Euro and Pounds Pricing Catalogs.

By way of the metadata on the catalogs we’re now able to display the same range for both UK and Danish customers, but in three different currencies with Pound being available to the British and Kroner available only to the Danish customers.

posted on Wednesday, 03 June 2009 14:21:57 (Romance Daylight Time, UTC+02:00)  #    Comments [2] Trackback
# Thursday, 13 March 2008

Commerce-Server-2007-Logo In my mini series about the Commerce Server development experience I did a piece called Magic Strings Galore which describes the general tendency to have all data in the various CS objects accessible via strings. Imagine a product with a rich description. You would access that like a hashtable, e.g. product["RichDescription"]. No way of knowing the return type , no discoverability via intellisense, poor refactoring support. Sure ReSharper takes care of some of that by looking at string literals when doing refactoring but surely there must be a better way to fix this. It turns out there is and I'm going to let you in on the secret :)

In my previous post .NET Framework 3.5 and Microsoft Commerce Server 2007 A Match Made in Heaven I discussed some options for using extension methods to add missing functionality to the built-in Commerce Server classes. Using this method you can augment the existing interface of Commerce Server but it doesn't really provide you with a nice place to put all the domain logic that is bound to turn up eventually. To solve this problem I came out with an automatic mapping layer sitting on top of the Commerce Server Profile System which translates the stock Profile into rich domain entities filling in the gap and giving you that place to put your custom logic and at the same time doing away with all the problem with magic strings that I described above. I call it the ProfileRepository.

The ProfileRepository is not a true object relational mapper in the sense that I'm not really converting from the relational model. Luckily all that is taken care of for me by the profile system of Commerce Server so I pretty much just have to provide the type safe abstraction.


ProfileRepository My requirements for the ProfileRepository is the following. I want the developer using the framework to easily be able to map an entity, say User, to a profile, say UserObject.

Additionally I want to abstract the actual implementation of the entity by only working with interfaces so the consumer of the framework has the freedom to switch implementations, e.g. for unit testing or later in the development phase of the application.

Finally I want the consumer of the entity to be blissfully unaware of Commerce Server sitting underneath the repository; basically a full implementation of the repository pattern as outlined by Martin Fowler.

With that in mind we end up with a basic class hierarchy in place as depicted in the class diagram in the picture to the right.

Mapping Engine

ProfileMapper With the basic class hierarchy in place lets take a look at how the actual mapping of a Commerce Server profile to an entity happens.

Interestingly the Profile System operates with a type system completely separate from .NET and indeed COM making mapping interesting. The type system is pretty weak and doesn't express everything needed to perform mapping of all data types. For example there's no way of telling the difference between an association between two profiles and a string; they both turn up as a string.

To work around this limitation I went with assumptions based on the target of the mapping. So from the type of the actual target property on the entity I can deduce that we're dealing with an association because the actual type is IProfile and not string. Same thing goes for GUIDs and strings which also show up as the same thing; a string. Now I love the string type as much as the next guy but this is borderline ridiculous :)

To perform the mapping I employ a mapping engine which knows about all the mapping rules supported by the engine like rules for handling primary keys, one-to-one relationships, one-to-many relationships, value types, DateTimes, Guids, etc..

Each rule is an implementation of the specification pattern meaning that the engine will evaluate against each mapped property of the target entity and determine whether a particular rules is applicable to current property. Each rule employs reflection to determine whether that is case so the GuidMappingRule would use reflection to determine whether the type of a property on the entity is in fact a Guid.

Creating a Mapped Entity

To create a mapped entity you need to perform three simple steps: Create the interface which will expose the entity, e.g. the IUser interface. Second create the actual implementation of that interface, e.g. the UserObject class. The third and final step is to decorate the properties of the implementation with mapping information. Simple and easy. The code for IUser and UserObject might looks like this:


public interface IUser : IProfile


    string FirstName { get; set; }

    string LastName { get; set; }

    IAddress PreferredAddress { get; set; }




internal class UserObect : IUser



    public string FirstName


        get { ... } set { ... }




    public string LastName


        get { ... } set { ... }




    public IAddress PreferredAddress


        get { ... } set { ... }




Loading an Entity

With the mapping complete loading an entity is pretty straightforward: You new up the profile repository and call the generic method Get<T> with the key of the profile you want and presto you get an instance of the IUser interface returned to you complete with associated entities, the preferred address in the case. The Key class might seem superfluous but there's a point to it as it enables support for multiple key types like Guid, int, etc..


IProfileRepository profileRepository = new ProfileRepository();

IUser user = profileRepository.Get<IUser>(new Key("{EEDA89C9-E231-4002-AC24-7FD7FAB2F2FD}"));


All the Rest

Your spider sense is probably tingling by now. How's the ProfileRepository able to figure out which implementation of the IUser interface to instantiate? The answer to that is a piece that I omitted in my previous description: Sitting inside the ProfileRepository is an inversion of control container (IoC), in this case Windsor from the Castle project, which dynamically instantiates the correct type based on a configuration file.

Interestingly Windsor will be a key component in coming features in the ProfileRepository. As it stands today there are a number of improvements that can be made to it. Most prominently is implementation of lazy loading. All associations are eager loaded today which means that if you ask for a any one profile entity you'll get a complete object graph back which might not be suitable for all scenarios especially if we're dealing with many associated profiles.

With Windsor in place I intend to employ dynamic proxies to instantiate modified types with the lazy loading pattern injected into the relevant properties. Thanks goes out to Søren Skovbøll who came up with the idea for this and even provided me with POC code. His general knowledge on ORMs came in handy for a couple of things on this too :)

There are several opportunities for other performance improvements. The ProfileRepository uses reflection quite extensively to perform the automatic mapping which as you know is a costly operation. For a future release of this guy I'd like to throw in some caching for the rules which employ the reflection routines. The net result here would be that the rule is evaluated once per property and entity and from that point on reflection is only used for actually initializing the values of the properties.

Finally the ProfileRepository is load-only at this point and naturally I'd like to get create and update functionality in there as well. A customer self-service module would definitely need this feature in place to enable users to edit their user profiles, signing up for newsletters, etc..

With ProfileRepository I've tried to bring the full power of the profile system as a general purpose data access to bear in the sense that what we've got with the profile system is very cool and flexible but needs just that little bit extra to provide a nice development experience as well as something that supports the overall maintainability of the system.

posted on Thursday, 13 March 2008 21:46:16 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Wednesday, 12 March 2008

Commerce-Server-2007-Logo Imagine this scenario: The year is 2003 and you're a Commerce Server developer who is setting out on the first Commerce Server 2002 and .NET project. Exited? You bet I was :) Way back we were asked to subcontract on a large ticket booking system developing the user profiling piece for the solution. With my background in OO naturally I wanted to go ahead a create business entities from the profiles in Commerce Server by inheriting them building entities specific to my needs.

Now you know what I ran into by trying to do that right? Pretty much a brick wall behind yet another brick brick wall. What I ran into was the fact that the Profile class is sealed and the brick wall behind it was the ProfileContext which is also sealed. Pretty much my idea was dead in the water at that point. So to return to the point of this post. Today several years after the fact it dawns on me that I have the perfect new tool to actually get some of what I wanted back then: Extension Methods.

As you probably know extension methods is a way of spot welding new functionality onto existing classes whether they are sealed or not. Basically a handy way of making external functionality available where you need it. Lots and lots of articles about extension methods have been written about the topic so suffice it to say that you put your extension methods in a particular namespace and to make them available on the target types you simply import them into your current context via a using or Imports statement depending on your particular language fetish :) With that out of the way lets skip right ahead to how you might use them in Commerce Server.

You can envision a scenario where you augment the profiles with specific functionality based on what you're doing. Say you're creating a product review profile in which you store the customer's opinion about a particular product. Use extension methods on that guy to include rendering a star rating, setting the customer review description, or administrative methods like approve/reject review.

For the product classes like ProductFamily, Category, etc. which are also sealed you could opt for something else entirely. From time to time we utilize the concept of search category, i.e. a category where the child categories and/or products are determined by a search criterion. Instead of putting this functionality in a helper somewhere you could go for a extension method to load the child objects of your current search category.

But why go for the individual entities themselves, why not go for the services published by Commerce Server like ProfileContext or CatalogContext to provide enhancements to the core functionality? I can certainly see some interesting scenarios enabled in the Marketing system, a subsystem which traditionally hasn't been very open to extensions.

To sum up extension methods is a brand new extension point for Commerce Server. Commerce Server has traditionally been very extendable but some areas are completely locked down. Until now that is. The scenarios I describe above is one way to do away with a lot of helpers floating around. Of course a much better way of accomplishing this is fashioning a facade layer on top of Commerce Server which will accommodate not only your custom logic but more importantly support your automated test suited (you do have one, don't you? :)). The facade layer will be the subject of a future post as I feel very strongly that architecturally this is a great thing to have in place to support you now and in the future.

Also let this post be a cry to the powers that be at Cactus to open up the APIs for inheritance. I certainly understand the need for sealing stuff especially with COM lurking under the covers but please, pretty please don't let that baggage spill over in future versions when COM is completely removed from the product. Finally sprinkle some interfaces on top and I'll promise to be a good boy from here on in :)

posted on Wednesday, 12 March 2008 16:28:20 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Tuesday, 05 February 2008

Commerce-Server-2007-Logo A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really want to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.

Check out part 1 Secure By Default where I discuss the security aspects of Commerce Server, part 2 Three-way Data Access in which I write about the various ways of getting data into your applications, part 3 Testability which not surprisingly is all about how CS lends itself to unit testing, part 4 Magic Strings Galore where I take on low level aspects of the APIs, part 5 Pipelines where COM makes a guest appearance in our mini series, part 6 which is all about getting your solution into production, and part 7 where I rip into the reference shop implementation: The Starter Site.

The Good Stuff

In this the final part of my mini series about developing Commerce Server I'm going to cover the stuff that I love about working with Commerce Server 2007. While I didn't start out with a particular roadmap for this series of articles I've noticed a trend when I look back over the posts: They aren't very positive about Commerce Server. Why is that? Does it mean that Commerce Server is a bad product? The answer to that eluded me for a while until our salesman pointed out a particular fact about engineers: Our job is to know the weak spots of the technology we're working with in order to produce the best possible solutions. While this is great trait for an engineer it certainly doesn't make for a great sales person :). I guess the reason for my negative slant stems from this fact: For me and my team to deliver the very best Commerce Server solutions we have to be constantly aware of any and all weaknesses of the product which is why I naturally gravitate towards that mode of describing the development experience.

So to answer the question posed above: Is Commerce Server a bad product? Certainly not, actually I enjoy working with a very mature platform which provides a lot of great features out of the box. Actually I've found myself in the fortunate situation of being able to tell a customer that, "yes we can do that out of the box", more often than not. I truly enjoy that part of my job because I find that customers are used to not getting anything out of the box if they're coming from the traditional business which started out on the web on a custom solution.

Actually I come across two types of distinct businesses when I go out and do Commerce Server work in the field: The business which primarily grew out of the web with the webshop at the core and the traditional business with the ERP at the center. As I mentioned above Commerce Server is a very compelling offer for the webshop-centered business because it provides a much more sound foundation than the custom built solution. The benefits for the traditional business are of course the same but interestingly I've found that Commerce Server is aligned very well with the way ERP guys typically think about a business. A good example of this is the rich way in which we can express business data in Commerce Server, in the areas of the ERP which concern a webshop we're able to not only match the capabilities of ERP systems but in some cases even surpass them, e.g. richness of the order schema and the way shipping is handled, the flexibility of the catalog, etc..

Were I to use a single word to describe Commerce Server it would be "flexible". Flexible in every sense of word as you can customize every aspect of the product to the suit the needs of the customer. Pretty the only limitation you'll come across is your own knowledge about the platform. With the right knowledge you can shape Commerce Server to suit the particular requirements of your customer which is why getting the right people working on your Commerce Server-project is essential for the success of it. You might argue that this is the case for all types of projects but I've seen how bad I project can go if the people working on a Commerce Server project lacks the proper skills to do so. The sound foundation I wrote about previously suddenly starts to look pretty wobbly and you end up in a situation where the platform is working actively against your business instead of with it.

So what happens if you get the right people working on your project creating the right architecture? Something akin to magic that's what. With the projects we've got going on right now I see one particular trend: The architecture that we're putting in place on top of Commerce Server leveraging the platform without working against it is actually opening up new avenues of possibilities for us as the projects move forward. Instead of feeling barred in by the choices we make I increasingly find that our solutions just support new requirements from the customer either "automagically", with reconfiguration of the existing system, or with very little modification to the system because the features were built on the sound foundation that is Commerce Server. That and of course the fact that I've got the privilege of working with the best damn e-commerce team out there :)

posted on Tuesday, 05 February 2008 21:21:13 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback

Commerce-Server-2007-Logo In light of the success of the Aarhus .NET User Group on Facebook I went ahead and created a Facebook group for Microsoft Commerce Server for all of us working with the product. If you have an interest in getting in touch with people with deep Commerce Server knowledge please don't hesitate to join the group. Prominent people like Ryan Donovan and Max Akbar are already in there so why aren't you? ;)

Microsoft Commerce Server Facebook group

posted on Tuesday, 05 February 2008 19:42:14 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Wednesday, 23 January 2008

Commerce-Server-2007-Logo A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really want to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.

Check out part 1 Secure By Default where I discuss the security aspects of Commerce Server, part 2 Three-way Data Access in which I write about the various ways of getting data into your applications, part 3 Testability which not surprisingly is all about how CS lends itself to unit testing, part 4 Magic Strings Galore where I take on low level aspects of the APIs, part 5 Pipelines where COM makes a guest appearance in our mini series, and part 6 which is all about getting your solution into production.

The Starter Site

Ah the fabled Starter Site... When I look at my search logs for this blog I see that people are very interested in the Starter Site and are doing lots of searches for it. Ever since Commerce Server 2000 Microsoft has provided a reference implementation of a commerce site for developers to learn from. Ever since Commerce Server 2000 it's been and all-around bad idea to actually use the Starter Site in production. As a Commerce Server developer you'll cross paths with these guys so it's important for you to know what they're al about.

So is it still a bad idea to put the reference implementation for Commerce Server 2007 in production?Yes and no, while the Starter Site is a step up from previous reference implementations it's still not what I'd call production ready. The Starter Site provides great insights into the workings of the Commerce Server APIs but it's not exactly a shining example of web application architecture.

The Starter Site is done as a web site project in Visual Studio which by itself is not an issue. The problem though is that there is no separation between UI and application logic. All business logic is placed in the App_Code folder of the web site which means that it lacks reusability completely.

Additionally the code which is there lacks support for testing as well, all components are implemented directly on top of the CS APIs which as I discussed in part 3 Testability means that we have no means of creating unit tests for our custom code. Not only that but the entry point to the subsystems used is the CommerceContext which is initialized by a number of HTTP handlers during execution of the ASP.NET pipeline, this means that we're effectively bound to an ASP.NET context which in turns blocks the ability to test anything.

Now the abstraction provided for the Profile System does show some good ideas. Profiles are abstracted in nice type safe objects which in turn are mapped to the underlying Profile System by use of attributes. Great idea but I'd like to have seen the idea carried a few steps further. For instance relationships are implemented by a pattern that the developer needs to redo for every single property which reference another profile or list of profiles.

Oh and some corners are cut here and there: We have a nice abstract BaseProfile class which serves as the base for all profile implementations, perfect but in an especially grievous example a method in the BaseProfile is implemented with knowledge about one of its inheritors, see that's bad OO design right there.

Finally the Profiles which is most Commerce Server projects serve as the data store for domain objects are bound to ASP.NET like the rest of the business logic of the Starter Site meaning you can't reuse them in other contexts like winform apps.

All that said the Starter Site is a very nice running reference from which you can learn a great deal. There's no code like running code, all else aside the Starter Site is probably the best reference and source of learning Commerce Server especially if you're already familiar with earlier versions of Commerce Server.

Provided with the code base is the control gallery which is a collection of ASP.NET controls that you can use in your own site. They're implemented as server controls which means that they're easily transferred to other sites. That's ten points right there :)

So while the Starter Site is an exercise in bad web application architecture there are very good reasons for downloading it and taking a look at it. Learning is the obvious route but if you find yourself tight for time or money on your particular e-commerce project you can get some good results with the Starter Site as a foundation provided you take care and identify the weaknesses of the code base and rearchitect accordingly.

posted on Wednesday, 23 January 2008 20:42:01 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Monday, 17 December 2007

Ever since beginning my work with Commerce Server it was apparent that we needed some way to link the disparate subsystem with each other in a uniform way. Sure there are lots of links between catalog, order, and even profiles out of the box but the problem with them is that they're all done in different ways.

My colleague Brian found an excellent solution to this problem by introducing a concept he calls Extension Profiles which is basically a profile you tag on to other data objects in Commerce Server. With this in place you can use the extension profile in a number of ways like mapping objects or extending non-extendable CS objects like ShippingMethods and Payments.

I've been bugging Brian to write about them for a while and during the weekend it seems that he finally got around to it.

Check out How to extend Commerce Server Payment Methods and Shipment Methods

posted on Monday, 17 December 2007 08:29:05 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Friday, 14 December 2007

Commerce-Server-2007-Logo A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really want to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.

Check out part 1 Secure By Default where I discuss the security aspects of Commerce Server, part 2 Three-way Data Access in which I write about the various ways of getting data into your applications, part 3 Testability which not surprisingly is all about how CS lends itself to unit testing, part 4 Magic Strings Galore where I take on low level aspects of the APIs, and part 5 Pipelines where COM makes a guest appearance in our mini series.


When time comes to deploy your application we've got a number of options when it comes to custom apps crated purely on top of the .NET framework: Installers, xcopy deployment, automatic build processes, etc.. When it comes to Commerce Server the deployment procedure is a bit more involved but aspects of the deployment are supported by some interesting tools as we'll see in a minute.

Commerce Server comes with a handy tool for publishing your application in a single file called a PUP file. This works great the first time around and greatly simplifies first-time deployment unfortunately it only works for the initial deployment subsequent deployments are more involved because manual deployment is required unless you're fortunate enough to be working with the enterprise version.

Let's first deal with the manual deployment because that's frankly the most fun to write about :) Commerce Server is split across a number of different subsystems each running on top of a separate database. Each subsystem has different deployment requirements and steps that you'll need to follow. I won't bore you with the actual steps here just know that deploying a Commerce Server application requires a lot of steps and I do mean a lot involving a number of disparate tools.

Security requirements of authorization manager further complicates deployment because the business data is protected by an additional layer of security different from what's found at the system level. All this has to be created either manually or via a command line tool provided with the product.

One alleviating factor to the long list of manual deployment steps is the fact that Commerce Server is split across a number of different databases, one for each subsystem. You can isolate changes to each subsystem thus easing deployment by the fact that you can deal a subset of your Commerce Server application at a time.

It becomes really interesting when we start talking about the enterprise version which brings another tool to the table which will automate deployment of most of your application: Commerce Server Staging (CSS). The staging tool allows you to move business data and files from one server to the next. this means that you can enforce pretty much and hands off policy on your production server and only have your business users work in a staging environment for creating and testing purposes.

The only caveat to staging is that it doesn't support profiles, you can however use a more crude approach to deploying your profiles automatically. Notice that I wrote business data and files. You can basically have CSS move binary files to production and have it execute a command pre and post transfer which could be a bat file, a custom executable which essentially makes CSS a very unique and useful tool not just in conjunction with Commerce Server.

Just think about what can be done with a tool like CSS with a regular old ASP.NET app. You could basically have CSS move your compiled ASP.NET app and SQL script to production, have it move the assemblies in place, and finally execute your SQL scripts. Voila automatic deployment, only downside is that you need an enterprise version of Commerce Server around :) I really think that Cactus should look into making this a standalone tool.

posted on Friday, 14 December 2007 07:00:06 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Wednesday, 12 December 2007

Did you know that each field you post using the HTML form element is limited to 100KB? I sure didn't and it can cause trouble if you still have to deal with Commerce Server 2000 and 2002 because the Bizdesk rely heavily on XML islands on the client to create a rich client side experience.

Specifically this can cause trouble when you add a large number of variants to a product all at once. You can work around it by creating a limited number of variants at a time.

PRB: Error "Request Object, ASP 0107 (0x80004005)" When You Post a Form

posted on Wednesday, 12 December 2007 08:45:44 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback

Commerce-Server-2007-Logo A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really want to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.

Check out part 1 Secure By Default where I discuss the security aspects of Commerce Server, part 2 Three-way Data Access in which I write about the various ways of getting data into your applications, part 3 Testability which not surprisingly is all about how CS lends itself to unit testing, and part 4 Magic Strings Galore where I take on low level aspects of the APIs.


When I first encountered pipelines in Commerce Server 2000 they were a nice feature to have available and they made sense because they handle a much bigger load due to the fact that they're essentially COM objects executed in an ordered fashion. All this made a great deal of sense back in the day when we were dealing with plain old VBScript and ASP.

When Commerce Server 2002 came out it still made sense that they stuck around because the .NET support in Commerce Server 2002 came in the form of managed wrappers for the COM objects which came with the product.

Would you be surprised to learn that COM based pipelines stuck around for Commerce Server 2007 too? Well they did which means that you have to know a little something about COM to get it going. Especially when it comes to debugging problems with a server setup. Weird HRESULTS is something you still have to contend with although the situation is vastly improved from the older versions.

Fortunately you can go ahead and build your pipeline components in .NET and expose those to COM so all is not lost. It does however mean that you need to make sure that your pipeline components behave as expected at runtime in order to avoid cycling objects in and out of the GAC. The keyword is developer productivity, you don't want to spend too much time mucking about with getting everything good to go for every little change you make to your pipeline components.

Traditionally pipelines is the area where people ask the most questions because it's a pretty opaque topic to dive into at first. Every time I create a new pipeline component it pains me to know that we have the nice System.Transactions namespace available to us in .NET.

Luckily Cactus feels our pain and has a replacement on their roadmap for the next version of Commerce Server but until then you better get those interop skills up to speed and. Alternatively you can choose to forego the pipeline system altogether and do any custom business logic outside pipeline components but that's not always an option.

Developing with Microsoft Commerce Server 2007 Part 6: Deployment

posted on Wednesday, 12 December 2007 07:00:23 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Monday, 10 December 2007

Commerce-Server-2007-Logo A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really want to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.

Check out part 1 Secure By Default where I discuss the security aspects of Commerce Server, part 2 Three-way Data Access in which I write about the various ways of getting data into your applications, and part 3 Testability which not surprisingly is all about how CS lends itself to unit testing.

Magic String Galore

One of the first things I noticed when I started working with Commerce Server a number of years back was the extensive use of "magic strings" to access various custom properties of data objects. In fact the use of magic strings was pervasive across the entire product from the catalog system over the profile and orders system to the marketing system. With the current version (2007) that changed for the better with regards to the order system but still holds true for the other subsystems.

Magic strings of course is a term which describes the use of a string to identify a particular element in structures like arrays, dictionaries, and the like; an example would be myArray["myMagicString"].

The reason behind the use of magic strings is that each of the individual subsystems of Commerce Server offers a great deal of flexibility including the ability to define your own schemas for almost everything. This means that the actual structure of say an profile is known only at runtime. Employing magic strings is a nice and easy way of getting the job done but it does leave a lot to be desired when developing with the product.

One of my pet peeves is explorability; by explorability I mean the ability to use intellisense to get an idea of what you've got at your disposal on any given API. Commerce Server allows for this for the most part but when it comes to catalog objects and profiles sadly this is not the case which leaves you referencing other tools to look up the magic strings for accessing a particular property on an object. Not exactly a productivity booster. Of course the remedy is fairly straightforward: You simply build an abstraction layer on top of the weakly typed objects and work off of that instead. This does produce more code that we need to maintain ourselves and with that an increased cost to our customers. Alternatively you could go low budget and maintain a library of magic strings in a central class or even combine that with the abstraction layer.

Interestingly the orders system allows for strongly typed properties. As I wrote in part 2 Three-way Data Access the order system is an ORM in its own right which provides strongly typed properties on the object, all that is require is a little mapping via XML. With that in mind it seems strange that we have to create our own abstraction layers on top of the other subsystems.

The use of of using magic strings means that we end up with runtime errors instead of compile time errors because we can't rely on the compiler to check the validity of magic strings. Refactoring rapidly becomes more difficult at this point leading me to a second pet peeve of mine: Catching errors as early as possible. I really like me to be the first one to know about any errors in the code I write, especially when they're as trivial as misspelling a magic string.

Now one could argue that ORM isn't practical on top of the catalog system due to the very extensible nature of it. It's intended to be expanded by business users, a tool is even provided to enable them to do so making mapping of the catalog object less feasible. The problem however is that with most Commerce Server solutions you'd need a developer to actually use the newly added product definitions and fields for something, e.g. displaying them in the UI, leveraging them in the pipeline system, etc.. This leaves us with the original problem: Developer productivity.

From my point of view there's a single solution available to us: Code generation. To effectively work with the subsystems in a consistent and effective manner code generation could be employed but it requires some heavy lifting as you'd have to create specialized generators for the individual subsystems. The good news is that meta data is indeed available to allow for the process.

One might argue that a second option is available; namely to rewrite the data access schemes of the profile- and catalog system to more closely match that of the order system in order to leverage ORM principles. That however remains closed to anyone but the developers at Cactus Commerce.

posted on Monday, 10 December 2007 15:33:23 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Monday, 03 December 2007

Commerce-Server-2007-Logo A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really wanted to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.

Check out part 1 Secure By Default and part 2 Three-way Data Access.


A topic which is very near and dear to my heart is testing. For a number of years I've been thinking about and trying to implement unit testing and test-driven development in Vertica but only recently have we been making progress on that front. Why then has it taken so long to get going with test driven development and unit tests in a shop where a lot of dedicated and enthusiastic people work?

The reason is simple: We' do most of our work on Microsoft server products like Commerce Server, Office SharePoint Server, and BizTalk and those products are not very well designed with regards to enabling unit testing scenarios. Now this post is entitled developing with Microsoft Commerce Server so naturally I'm going to focus on this.

Test driven development and unit testing require a lot from your architecture to make it work. In order to do effective unit tests in a system we need to able to divide the system up in just that, units. I'm not going to delve into the aspects of unit testing techniques here as that topic alone would require numerous posts to cover but suffice it to say that interfaces play a import role in enabling the scenario, class inheritance does as well.

Now how does this relate to Commerce Server? It turns out that you're going to have to look long and hard to actually find interfaces to enable mocking. Everything in Commerce Server is a concrete class, in some instances even classes which have a natural relationship doesn't share a common interface or even a base class which hampers our attempts at creating structured tests.

When developing with Commerce Server the Adapter pattern will become your friend, simply create an adapter for a particular piece of functionality in Commerce Server and work off of that instead of the real API and you're set. Unfortunately this means extra work for you as the developer if you want to create proper tests for your solution.

A lot of the functionality of Commerce Server is accessed via a class called CommerceContext, this works in much the same way as the HttpContext we know a love. Unfortunately it's heavily reliant on HTTP modules to initialize it thus making it tough to test. As a Commerce Server developer it's natural to go to the CommerceContext and access the various subsystems form there. Doing this however tightly couples you to HTTP which is a bad thing if you need your logic in a different context like say for unit testing. The remedy is simple but you need to be aware of this fact otherwise it will bite you in the ass at some point. I did a post on working with the profile outside of the ASP.NET context back when I was working with Commerce Server 2002; it just so happens that this particular technique is still viable today.

The bottom line with respects to structured testing in Commerce Server is that we're faced with many of the challenges we see when working with legacy code which has not been designed specifically for unit testing. By no means does this mean that it's impossible to do unit testing with Commerce Server; it does however mean that you need to be aware of the fact and design your architecture accordingly and that there will be areas which you won't be able to touch with your automated tests.

Developing with Microsoft Commerce Server 2007 Part 4: Magic Strings Galore

posted on Monday, 03 December 2007 07:40:26 (Romance Standard Time, UTC+01:00)  #    Comments [2] Trackback
# Friday, 23 November 2007

Commerce-Server-2007-Logo A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really wanted to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.

Check out part 1 entitled Secure By Default.

Three-Way Data Access

Commerce Server provides a lot of functionality out of the box; in fact it provides not one, not two, but three disparate data access schemes. Talk about getting your money's worth :) What this translates to is two things: Blazingly fast performance and a high bar of entry for developers.

Basically each subsystem in Commerce Server comes with its own data access system which means that you as a developer will need to learn and master them all to be able to leverage the features provided by the product. There are some general traits to the various data access model: You won't have to do much SQL, if any.

The Profile system is our general purpose data access system that we use whenever we have a custom piece of data we need to store; user profiles, addresses, cities, etc.. You can think of the Profile system as half of an ORM, it will help you get your data into your application in a nice fashion without you having to do SQL which is nice but it doesn't provide the last part of an ORM, the O, the part that actually turns the data in objects. You could call the Profile system an RM because what it provides you a general purpose name value collection that you can build on top of. When everything is set up the profile system is quite nice to work with, sure the API is a bit primitive compared to a full fledged ORM but it certainly gets the job done and a couple of nice abstractions on top will get you a nice domain model to work with.

The Order- and Catalog systems are a different story in that they are very specific in their purpose; they only deal with specific domain objects: Order- and catalog objects.

I would point to the Catalog system as the very best part of Commerce Server, it feels complete and very well done, both feature-wise and data access-wise. There are no nasty XML files, no having to map multiple levels of abstractions before getting the job done, it all works and works beautifully. The Schema Manager tool is to Commerce Server Catalog system what Enterprise Manager was to SQL Server 2000: Your one stop place to setup schema for your database. Everything is handled in a graphical manner which is translated to SQL statements, procs, and physical tables. The Catalog system is set up for performance which is clear if you go ahead and poke around the database, tables are denormalized, physical objects are created for new catalogs, and so forth. Interestingly you can actually learn a lot from the performance database design by going through the various databases of Commerce Server.

Finally we've got the Order system where we have the third and final data access system and also the newest one in our happy little family. CS 2002 introduced XML mapping files to map orders, lines, payments to actual objects. In that respect we are actually dealing with a full ORM here, only it handles orders and various associated object but nothing else. You'll have to get your hands dirty with multiple XML files and you'll have to do manual updates to the database to get everything going. You won't however have to do anything to actually use the subsystem that's nice squirreled away in the API.

It's interesting to note that across all the data access schemes Commerce Server actually contains some very powerful APIs, if only they were combines and unified to provide the full flexibility to all the subsystems. As a developer you'll have to wrap you head around all the models; on the upshot of this the individual models are not that complicated to work with so it's not exactly a Herculean effort you need to put into learning the APIs: It's mostly a matter of knowing where to look. There are good reasons for the subsystems not being unified but I'd really like a single architect at Cactus to sit down and consider what needs to be done to leverage either a preexisting ORM or to unify the functionality found in the disparate DALs.

Developing with Microsoft Commerce Server 2007 Part 3: Testability

posted on Friday, 23 November 2007 07:00:08 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Wednesday, 21 November 2007

Commerce-Server-2007-Logo A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really wanted to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.

Now I started this out with the intent of covering everything in a single post but as that post got longer and longer I decided to split it up into multiple parts. So here's the first installment with a couple more to come soon.

Secure By Default

The first thing you'll come to realize in the first couple of hours working with CS is that security is a big deal in this release; both a blessing and a curse. A blessing in the sense that the security system provided out of the box provides rich possibilities for securing the various subsystems of Commerce Server. If setup properly all components are protected by multiple layers of security and you even have the possibility to go one step further than that by leveraging business data security. Basically the last layer of security allows you to specify what data users or roles can access, not only that but you can go down to operation level and specify which operations are available to particular groups of users. While this sounds like role-based security it's not, this is much richer than that and is more akin to code access security only with a business focus rather than a technical focus.

I started out by stating that the rich security features are both a blessing and a curse, so how can that be the case with all of the above? The fact of the matter is that with security comes complexity, imagine a setup with multiple web sites running in IIS each with its own app pool of credentials, this goes all the way to the database where the individual services have very specific roles assigned to them. Debugging an error in a setup like that is very difficult and this is some of the more bland stuff you'll encounter :)

Commerce Server leverages a lot of platform technology, one that comes to mind immediately is Distributed Transaction Manager the very same used by System.Transaction in .NET Framework 2.0. Basically MSDTC is great when it's working, when it's not you'll really come to loathe it. I've been through numerous debugging sessions where MSDTC either wasn't running on all machines, it couldn't do reverse name lookups over the network, firewalls were blocking ports, etc.. As I said it's a pain when it's not running.

What this is all boils down to is that not only do you need to know Commerce Server as a product; you'll also need to know the basics of the Windows platform. This probably seems straightforward, if it does all the more power to you, but with more and more abstraction levels on top of the metal people do have a tendency to forget the underlying platform.

Developing with Microsoft Commerce Server 2007 Part 2: Three-way Data Access

posted on Wednesday, 21 November 2007 21:42:04 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Monday, 15 October 2007

Commerce-Server-2007-Logo  We're working on a couple of Commerce Server projects right now and common for both of them is the fact that we need to support multiple currencies and languages. "That's easy", you might think, "you just add additional languages to the catalog and you're done". Indeed that is the case for multiple languages but it turns out that supporting multiple currencies is a little more involved.


Of course I need to support multiple currencies and languages but also multiple price groups so I can have different prices in countries using the same currency, say Spain and Holland where both use euro. Also I need to support pretty prices, i.e. the business user can specify the price like $9,99 or kr 5,95. I don't want to link a single currency to a particular country, e.g. I want Danish customers to be able see prices in Danish kroner as well as euro (the Danish euro price and not the Spanish one as they may differ).

Finally I need to support BizTalk integration with an ERP system with an internal category structure which makes sense to the business users and an external category structure for retail customers as defined by marketing. Of course I want all this to fit well in the Commerce Server way of doing this without compromising architecture and maintainability.

Requirements summed up:

  • Multiple languages
  • Multiple currencies
  • Price groups
  • Don't link currency to country
  • Internal hierarchy and completely different external hierarchy
  • Fit into CS way of doing things

Commerce Server Support

There are a number of features in Commerce Server which can help me support my requirements it's just a matter of using them in the right fashion to achieve the desired end result. Multiple languages are supported right out the box simply by specifying on each catalog which language to support. From there on in you can switch language when you're viewing any item in the catalog and edit text in whichever language you want. The catalog schema is fully extendable so you can use that to add a new field for each currency or price group you wan to support. We have virtual catalogs which allow you to move a product from another catalog into the virtual one and override values there. Finally we have catalogsets which is a way to bundle catalogs together and associate them users or groups.

In summary we have the following tools to work with:

  • Multiple language support on catalogs
  • Extendable catalog schema
  • Virtual catalog for overriding field values
  • Catalogsets to associate catalogs to users

What Not To Do

Now you could go ahead and use the multiple language feature to support multiple currencies but there are two problems with that: 1) Numbers are not overridable like text so you can only specify a single value across languages, you can remedy this by creating a text field and override that but then we'd be working with text values instead of decimal values and you would need to make modifications to the standard pipeline components which are looking for the ListPrice field on the products. Additionally you'd have to come up with a naming scheme for languages if you want to support multiple currencies in the same country essentially creating redundant text data because of it.

As a better alternative we could create new fields for each currency but it would break our requirement of maintainability as we'd have to create a new field each time we want to support a new currency. Even worse we'd have to come up with a naming scheme to support the same currency but in different countries, e.g. Spain_EUR_ListPrice, Holland_EUR_ListPrice, and come up with code which can support it in our pipelines. Interestingly this is one of the scenarios Microsoft is pushing needless to say that I don't agree in the least with this recommendation. Also each catalog in Commerce Server has a base currency specified which would be rendered useless or even worse would confuse the business users.

Using multiple fields would however make the integration story very easy because we simply map the fixed fields coming from the external source to Commerce Server.

What To Do

This is how I propose we solve the problem using virtual catalogs. Everything needs to be imported into a single base catalog which won't hold any price information, optionally you could use the base catalog for the currency which the company operates in internally but for our purposes I'll leave it blank as to only have a single model for multiple currencies.

Virtual Catalogs for Currency and Price Groups

Remember that each catalog in Commerce Server has a currency configured we'll leverage that by creating a virtual catalog for each currency we wish to support additionally we'll need to go one step further to support our price groups. In order to do that we'll extend the catalog schema with a field called price group which along with the currency will identify the correct catalog to look for when displaying products to the retail customers and when BizTalk is updating. To make the solution more maintainable we do a single "include all"-rule for each of the price group catalogs which will allow the BizTalk developers to assume that the product will always be present in all currencies, of course you can elect not to this but it will need a higher level support either manually or in the integration piece.

Base catalog - virtual catalog

Now I mentioned include rules in passing above so allow me to elaborate on them here a bit: To include products, variants, or categories from another catalog in a virtual catalog we do it by creating virtual catalog rules. We have four types to choose from: Include everything, include category, include product family, and include variant; for each of those you can specify that we're excluding instead of including. There's a fifth rule type which I'll mention for the sake of completeness though I won't use them in here: pricing rules which is a way of adjusting prices in the catalogs. In summary I chose an "include all"-rule to support my price group catalogs above which will bring in all categories, products, and variants which are imported by BizTalk.

Support for BizTalk Integration

Whenever BizTalk imports a new product it needs to lookup the correct price group catalog for each price group on the product and update accordingly while this makes the integration piece a little more complicated it allows the Commerce Server developers to use the product in the intended way.

Virtual Catalog Considerations

For maintainability it's important to only update price information in the virtual catalogs we've created. Updating anything else will break the override chain which means that future updates to say product description will not populate to the virtual catalogs in which we overrode the value. It may be what you want but you need to be aware of this behavior.

Custom Hierarchy for Retail Customers

Remember that we want to provide the business with the opportunity to completely customize the category hierarchy for the retail customers while maintaining an internal hierarchy which makes sense from a business point of view. Now we have the business view of things in our Import catalog which is reflected in our price group catalogs as well due to the "include all"-rule we've added to the catalogs but we need a way to do a different hierarchy for our retail customers.

Unfortunately we can't do an "include all"-rule because that effectively includes categories as well and once you've included a category you're effectively stuck with it in your virtual catalog, there's no way to remove it without removing the products within as well. This means that we need to do include rules for every product family we want to include which provides the ultimate flexibility but also requires more from the Catalog Manager tool. Basically you can do with Catalog Manager but that doesn't mean that you should :) The workflow for adding an include rule basically involves opening the virtual catalog, clicking rules, then add new rule, search for the product you want, select the product, click next a couple of times, and then you need to add it to your new category in the virtual catalog which is another couple of steps. Imagine doing that for 4000 products :) Obviously some work need to be done on the Catalog Manager to make the workflow more smooth, maybe drag and drop within the catalog hierarchies or some kind of two-pane UI with the two catalogs on either side. In any event something needs to be put into place to handle the workflow but that's for a different post.

With that done we have something like this:


Finally we do a catalogset for each required user segment to line up the catalogs for the correct users programmatically. Once that's done we should have all our requirements covered.

In Conclusion

Working with Commerce Server to support our requirements is essential even though it might involve a bit extra work to get there. We could've added an extra field for each currency we needed to support but that would have cornered us and ultimately created a less flexible system which might not support us in the future. We want to work within the restraints of Commerce Server without jeopardizing our systems design which in the end would render the decision to go with Commerce Server useless.

With an integrated solution it's important to keep in mind the opportunity which we have to keep some of the ugliness found in the systems we're integrating with at our system boundary enabling us to stay with a nice and clean design.

As with any standardized product it's important to know the tools available to us and how to use them in the correct fashion. Our little exercise above shows some of the capabilities of the catalog system and how you could leverage them to achieve a flexible solution while not compromising the design.

posted on Monday, 15 October 2007 11:15:56 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Monday, 10 September 2007

04092007 cleaned When Max announced that he was leaving Microsoft a while back it was a good/bad news kind of thing. Bad news because Max had been my access to the Commerce Server team for a while and very good news because he announced that he would be providing Commerce Server training for the masses; a market that has left a lot to be desired over the years.

A short while after the announcement Microsoft let us know that they would be running a training course on Commerce Server with none other than Max doing the training. Needless to say that I was sorely tempted to go but in the end we decided against it due to the traveling involved and the lack of information regarding the tech level of the course. It all worked out quite nicely as we enquired as to whether he'd be interested in coming to Denmark and do some training for the entire e-commerce team at Vertica which he accepted to do.

Let me start out by saying that I'm extremely impressed with the material and the way he handled himself the entire time both before he got here and when doing the actual training. There's no doubt in my mind that Max provides the single best source of training on Commerce Server today, bar none. Our team consists of people of varying degrees Commerce Server experience and he managed to organize the training in a way which kept both the proficient and less proficient interested. He did this by not only request specific areas of interest on Even before he got here he wanted us to come up with very specific areas on which to focus the training and he kept tweaking and tuning the training on the fly based on our feedback. Very nicely done indeed.

So what gives Max Akbar the edge over the competition? Well first of he's worked with Commerce Server on actual projects for customers such as CostCo, Costco.ca, GAP, and Banana Republic which definitely gives him a unique perspective on CS solutions. Additionally he was part of the CS team as a program manager. Both of these facts color his outlook which means that he's got a definite enterprise-y look on things. Not surprisingly enterprise in the US definitely doesn't equal enterprise in Denmark and getting a perspective on that part of the story was very interesting to say the least. Also it helped keep the training relevant and interesting because he was able to relate most of the material to real-world scenarios albeit on a much larger scale than we're used to. Finally we got some interesting insights into the inner working of the Commerce Server team something that helps us understand why a particular feature in the product is done the way it is. It almost felt like getting into the psychology of the product :)

The training consisted of three days worth of tightly packed information. Rather than regurgitating every note I took I'd much rather like to focus on the highlights; there were more than a few too :)


The whole Cactus affaire left me a bit confused mainly due to the fact that Ryan Donovan posted that Microsoft is committed to Commerce Server as a product only to finish off that particular announcement with the fact that they're effectively outsourcing development of the product to Cactus Commerce. Now what's interesting here is the fact that Microsoft does this with other products it's just never clear which ones they are. In the case of Commerce Server Cactus has actually been involved in the development of the product even in version 2007 so what's happening here is the logical extension of that. Whether a good or a bad thing remains to be seen but the fact of the matter is that when Microsoft announces that they're committed to a product like they did with Commerce Server they're committed for years to come so I'm not too worried here. Now the story might be very different if Vertica was based in Canada which Cactus calls home because we'd be competing with the company which effectively controls the Commerce Server source code. Not exactly what I'd call equal footing and definitely not something that works very well with the Microsoft partner strategy.

Management API of Commerce Server

Shifting gears completely we learned that the old Commerce Server 2002 APIs are still available in 2007. The Commerce Server team just doesn't advertise this fact very loudly. Basically it's possible to use many of the well known management samples from the 2002 installation so be sure to take a look at that if you need to automate deployment of sites and stuff like that. You'll find the stuff you need in the SDK\Site Management directory under the Commerce Server 2002 installation directory.

Tools, Tools, Tools

Max has taken the time to write a lot of useful tools and utilities for Commerce Server 2007. Many of which he's already mentioned on his own blog like PackageThis for creating stand-alone versions of the documentation from the MSDN web site.

More interestingly he's created a tool called Secure Commerce Server 2007 Tool which will automate the entire security configuration process setting role membership on everything from the database, file system, to Authorization Manager stores. Unfortunately the GotDotNet page is down but hopefully he'll get around to creating a Codeplex site for it soon. It takes my own idea of simply scripting the database security permissions to a different level for sure.

How many times have you needed to extract a file from a PUP archive and had to do a custom unpack just to get at that single file? Whenever I've gotten in that particular situation in the past it's been a pain so I was very glad to learn about PUPViewer which will allow you to not surprisingly view the content of the PUP file but additionally it'll allow you to extract that annoying little file you were missing.

Secrets of Commerce Server

OK so not so much a secret as a good tip: Take a look at the contents of the installation directory of Commerce Server 2007. Chances are that you'll find some interesting stuff which is not listed in the start menu. I'd not even thought about doing so myself but in truth I've been missing out because of that. Among other stuff in the \tools folder you'll find tools for automating import and export, resynchronizing scopes in AzMan stores. You've probably taken a look at the \sdk folder but if you haven't you need to. Interesting stuff in there for sure.

Staging Service

The most under appreciated feature of Commerce Server 2007 is the staging service. What you can do with this thing is move data from one environment to the other basically automating a task which typically has been quite complex in the past. An example would be to allow business users to edit catalogs on a staging environment and then push the catalog into production once they're happy with their work. Not only does this alleviate some of the complexities of deploying business data but it also allows for some interesting deployment scenarios, e.g. have the staging environment on the LAN and the customer store front at a hosting provider allowing for a very smooth user experience for both the business users AND the actual customers. I'll definitely look into the various uses of this one some more. Unfortunately it's only part of the enterprise version and it doesn't support a truly flexible deployment model because you need an enterprise version on each of the servers you deploy it to.

Interestingly the staging service is useful for other solutions than Commerce Server ones because it also allows you to more files from one server to the other; add to this the fact that you can run tasks before and after moving the files and you've got yourself a very powerful deployment system for doing scheduled deployments. Basically you can keep your hands off of your production environment if you get this right.

Scopes in Authorization Manager

Role based security is a well known technique but AzMan introduces another layer on top of this (it actually introduces two but that's not interesting here). I call this additional layer Business data security. This is my own self invented term so bear with me if the meaning isn't clear. Basically what scopes allow you to do is to define security on the data itself instead of the functions of your application. This is hugely useful in scenarios where you want very tight control over your users and your business data. I've already got a couple of instances where this will be useful so I'm definitely glad I got it cleared up. There's no magic involved in the process, if we take the catalog system new scopes are created whenever you create a new catalog, properties, etc.. The secret sauce is a naming convention which means that the catalog subsystem knows whether a user has access to view a particular catalog, e.g. a user would have to be assigned to the CatalogScope_<CatalogName> scope. Easy, isn't it :)

Data Warehouse Demystified

The last day took us into the data warehousing capabilities of Commerce Server. It's an area we aren't too familiar with so it was great to get some insight into what makes this feature tick. What DW boils down to is a PUP package with existing cube and DTS definitions that's pretty much it. Having created those you need to run a little tool to get Reporting Services going by deploying the report definitions to the server. That's it. Having successfully done that you'll have access to the data warehouse capabilities. Do keep in mind that they're only available in the enterprise edition.


Nothing new was revealed for us here but I still think it's valuable to know this so I've included it in this post anyway. Max had a couple of pointer on how to debug problems with Commerce Server. Two tools came up: The tried and true Fiddler and reliable Reflector. These two have helped us more times than I wish to count.

If you don't know already Reflector allows you to peek inside compile .NET assemblies by decompiling the IL to readable C# or VB. The only thing lost in this translation are the actual variable names but you still get the idea behind the code. What we use Reflector for is basically for finding the right places to plug into Commerce Server when we're doing generic extensions for the product.

Fiddler comes in handy due to the fact that Commerce Server 2007 introduces a web service API. Fiddler is extremely good for figuring out what goes wrong in a request or simply trying to understand how a particular feature works. Take for example the business user applications which provide access to also every single part of the CS API. The interesting thing here is that if you can do an operation from the business tools you can do them programmatically; very useful for figuring out how to accomplish some specific task.

If you're doing any kind of integration with Commerce Server you need Fiddler installed on your machine. Period.

In Conclusion

Having Max come to Vertica and do his training has been a very good experience. Both for the guys who's been working with Commerce Server for a long time and the less experienced guys. For me personally it means that I now feel very comfortable with the product because I was affirmed in my knowledge on the product at every turn. What Max provided me was insight into why some of the feature were done the way they were and some tips and tricks which I'd probably never have thought of on my own.

Not only is Max very solidly founded in Commerce Server he's also a great guy who's very easy to be around. The casual training session is certainly attests to that fact and I'm sure that we all learned a great more due to this fact. I'm certain that we'll have him back when our team grows even bigger.

So thank you Max and we'll be seeing you :)

posted on Monday, 10 September 2007 16:48:51 (Romance Daylight Time, UTC+02:00)  #    Comments [4] Trackback
# Friday, 10 August 2007

CommerceServer Well whadda ya know Commerce Server is going mainstream with Computerworld actually reporting on the roadmap for the product. I'm impressed. Guess we're going to have to revoke its niche status pretty soon.

Microsoft udsender køreplan for Commerce Server

For those interested the story is a Danish version of Ryan Donovan's more in-depth post about the product roadmap for Commerce Sever code named "7"; interestingly the CS team uses the same code name as the Windows team. Grand aspirations anyone? :) Maybe they're looking to CS as the next-gen OS platform ala what people are talking about with the browser :D (kidding, you can delete that e-mail you were writing now :))

Seriously you need to check out the roadmap Ryan Donovan put up. There's some interesting stuff in there.

In-Depth: Commerce Server Product Roadmap & Information Desk Program Announcement

posted on Friday, 10 August 2007 10:58:06 (Romance Daylight Time, UTC+02:00)  #    Comments [2] Trackback
# Wednesday, 08 August 2007

CommerceServer Placing orders on the out of the box StarterSite is a bit tricky due to the fact that credit card numbers are verified in the pipeline component called creditcard.pcf. Of course you can disable credit card verification in the pipelines but that's not really the best way around. Luckily for us Microsoft has a KB article with some card numbers for testing to avoid that.

Sample Credit Numbers for Testing Credit Card Functionality

posted on Wednesday, 08 August 2007 15:38:48 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Thursday, 26 July 2007

CommerceServer My initial reaction was surprise when I learned that the order tracking numbers jump in intervals of 5000 whenever the AppPool of our Commerce Server applications is recycled. The behavior is usually not one that business users like to see because they just don't find it logical; additionally there's a nice soft benefit to being able to see how many orders you've processed up to a certain point just by looked at the tracking number.

Colin Bowern had the same experience and went digging. Basically he learned that the jump is a design change which was made to improve counter performance. To increase perf the tracking numbers are preallocated in lots of 5000 when the application fires up. Luckily Colin went and found a different way of assigning tracking numbers which don't exhibit this behavior.

Changing Order Number Behaviour in Commerce Server 2007

posted on Thursday, 26 July 2007 10:37:25 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Wednesday, 13 June 2007

CommerceServer We decided to go ahead and put the "smart" in Smart Client and use ClickOnce deployment for the business tools of Commerce Server in order to make initial deployment and future updates to the client machines easier. In short a good idea which unfortunately met a speed bump due to the fact that we're deploying the business tools from the source code and not the compiled version shipping with Commerce Server 2007.

Basically everything went fine until we got to the Customer and Orders Manager which just didn't work. Every time we ran the ClickOnce installer locally or remotely we would get a SecurityException telling us that we didn't have FileIOPermission. Additionally Visual Studio reported that various assemblies didn't allow access to partially trusted assemblies. Baffled we started debugging. New certificates, strong naming assemblies, various ClickOnce deployment modes, changing trust levels for ClickOnce, etc. etc..

In the end the clue that helped us in the right direction was a warning in Visual Studio saying, "Invalid value for 'TargetZone' of item 'LocalComputer'.". Searching through the entire solution yielded nothing. Finally we used a text editor and opened up the .csproj file for Customer and Orders Manager project to have a look at the actual XML of the file. Lo and behold an element called <TargetZone> was defined with the value LocalComputer. Removing the element altogether and redeployed fixed the problem.

I'm assuming that the <TargetZone> element in the csproj file is a leftover from a partial trust deployment setting. Interestingly enough it turns out that this element is defined in the Microsoft Commerce Server 2007 Partner SDK source code distributed by Microsoft which means that everybody trying to do a ClickOnce deployment of Customer and Orders Manager from the supplied source code will encounter the same issue as we did.

Other than this issue configuring the business tools for ClickOnce deployment is a snap I think our client will be very pleased with this particular deployment model.

posted on Wednesday, 13 June 2007 12:36:20 (Romance Daylight Time, UTC+02:00)  #    Comments [2] Trackback
# Monday, 11 June 2007

David Messner gave a talk on Commerce Server 2007 architecture at TechEd 2007 Orlando. I didn't think too much of it when I saw that he had posted his slides to the Commerce Server Team blog because the slides are usually worthless without the actual presenter going through them. I was however pleasantly surprised to find that he had actually put some effort into adapting the slides to a PDF making the content very useful to those us not fortunate enough to be a TechEd Orlando.

Take a gander at the Commerce Server 2007 Architecture PDF on the Commerce Server Team blog. I believe that this is required reading for anybody working with Commerce Server.

posted on Monday, 11 June 2007 12:58:47 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Tuesday, 29 May 2007

I ran into a pretty weird problem with the Commerce Server 2007 web services and Business User Applications. So much so that I wanted to write a quick note about it. Basically what we were seeing was that the Windows applications couldn't access the web services but we were able to get through to them using the browser. Notably the problem existed both when accessing the service via SSL and without. Further investigation showed that the problem happened on multiple development environments here. Weirdly enough the problem only existed with the Customers and Orders Manager tool the other tools were unaffected even when running with SSL.

Here's the error message which doesn't really tell us anything at all:

A couple of hours of debugging and fiddling around with Fiddler showed that installing the certificate created by SelfSSL.exe fixed the problem but I can't for the life of me explain why that is the case.

The steps I went through to actually install the certificate are as follows:

1) Navigate to the URL of the web service in Internet Explorer 7.

2) Click the red Certificate Error button and from the the View Certificates link.

3) Click the Install Certificate button on the Certificate window.

4) A dialog called Certificate Import Wizard will pop up click Next on the next two screens and finally Finish.

That's it. Hopefully the Business Tools should be able to communicate with the server now.

posted on Tuesday, 29 May 2007 09:02:56 (Romance Daylight Time, UTC+02:00)  #    Comments [7] Trackback
# Thursday, 24 May 2007

Ever since talking to Patrick Tisseghem I've been wondering whether Commerce Server would be rolled into SharePoint as a feature; a scenario I'm not particular fond of. Ryan Donovan was kind enough to share with the community a preview of the roadmap for Commerce Server in which he states that the product will indeed continue as a stand alone product. Very good news indeed.

"Commerce Server is not going to be merged into other products; e-commerce is a unique enough scenario with extremely demanding requirements that will often times warrant a standalone deployment; that being said, we are going to continue to vigorously pursue deeper integration with other Microsoft products and technologies as it makes sense to provide the best integrated story possible.", Ryan Donovan

Read his post Update on Commerce Server Futures where he also details a couple of other interesting tidbits such as the team's ambition of release incremental features outside of the regular release cycle very much like the ASP.NET AJAX team does with the ASP.NET AJAX Control Toolkit.

posted on Thursday, 24 May 2007 10:21:29 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Thursday, 19 April 2007

Our sales guy needed some Commerce Server picture and did what everybody does: Search Google Images. Little did he know ... :)

Google Image Search for "Commerce Server"

posted on Thursday, 19 April 2007 11:28:59 (Romance Daylight Time, UTC+02:00)  #    Comments [2] Trackback
# Monday, 05 March 2007

Finally some hard guidance is available from Microsoft on integration between SharePoint and Commerce Server. Code samples are included but they don't amount to much and the whitepaper clearly focuses on the installation and configuration and not very much on the more interesting problems like how we create dynamic layouts for product definitions, user editing of product data in a unified manner, all the good stuff we are looking into today.

Interestingly Ryan Donovan states that Microsoft has no plans for doing an integrated product which provides both commerce and content management functionality although the grapevine indicated that they did before the 2007 products were launched. His arguments for not doing such a thing are sound but I would have liked to see such a product.

posted on Monday, 05 March 2007 13:21:14 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Thursday, 01 February 2007

Today marks the day where Bolia.com adds an interior design feature (sorry the pages only exist in Scandinavian and German languages) to their site allowing you to decorate your own home with Bolia furniture. We've been working on the feature over the summer and it's great to finally see it in production. Having an interior design feature is something we've been talking about for years and years, in fact it's something I remember mentioned when I first started working on the project almost five years ago :) We did the backend web service integration for the feature and Voxtrup Innovation did the Flash frontend.

I think it turned out really well. I especially like the way the app scales automagically to the window size without messing up the design. Nice.

What's interesting technically about the backend architecture is that we needed a way to create a clean unified interface to the Bolia 1.0 application which is written partly in VBScript and VB6. We decided to go with .NET Framework 2.0 ASMX web services which in turn makes HTTP requests directly to the legacy VBScript code which then returns XML messages formatted according to the specified contract. Using this technique we're able to keep our interfaces to the Flash application even though the underlying implementation changes which is frequently the case and we employ new technology which is better suited for the future.

posted on Thursday, 01 February 2007 08:48:12 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Wednesday, 31 January 2007

Erik sent me a link today to Mei Ying's blog which has a post called Integrating Microsoft Commerce Server 2007 and MOSS. It's an older post from last year but it completely passed below my radar.

The post is pertinent to a project we are about to undertake as we're looking at integrating MCS and MOSS very tightly in order to leverage both products to create a highly flexible e-commerce solution. The problem consists of two pieces: product setup and integration of a MCS- and MOSS site and the meat of the problem which is all about the presentation of MCS content using MOSS as the driver for the site.

Basically Mei Ying's post takes care of the first issue of actually setting up the two products and getting their individual configuration files merged. Now on to the next problem. Of course there are lots more to it than just getting the two servers set up and create the middleware tier but it's a good place to start as we're seeing lots of interest in CS coupled with some kind of CMS.

posted on Wednesday, 31 January 2007 14:27:00 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Friday, 05 January 2007

Here's something interesting to hosters and developers out there.

This document describes a series of performance tests conducted for Commerce Server 2007 using the Commerce Server 2007 Starter Site. The hardware and software configurations used in the testing are described and the results are summarized. Some recommendations for improving performance are also provided.

Commerce Server 2007 Performance Guide

posted on Friday, 05 January 2007 11:46:51 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Friday, 24 November 2006

Remember the post I did about Ryan Donovan's Commerce Server 2007 presentation at TechEd? Well here's a chance to read about how he experienced the whole thing in his post aptly named How NOT to Demo CS2007 (and gain TechEd Infamy). I actually think he did OK considering that everything was against him that day.

posted on Friday, 24 November 2006 15:05:05 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Wednesday, 01 November 2006

CommerceServerThe Commerce Server team has released the final build of the Starter Site. I’ve already gone ahead and deployed it to one of my test environments and it looks solid. Not much different than the CTP version really.

More interesting is the fact that they have started a Commerce Server Team blog which I’m sure will bring lots of valuable information.

Download the Starter Site.

Check out the Commerce Server team blog.

posted on Wednesday, 01 November 2006 11:55:58 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Tuesday, 24 October 2006

CommerceServerThe sales material for Commerce Server 2007 states that standard edition supports Data warehousing and Analytics. Be advised that this is not the case. Microsoft is aware of the documentation issue and is working on fixing it.

posted on Tuesday, 24 October 2006 08:24:35 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Monday, 23 October 2006

CommerceServerSo I’ve been fighting with the Commerce Server 2000 BizDesk the last couple of days. On October 19th Microsoft issued a couple of security updates among which KB924191. This patch specifically disables MSXML 2.6 as detailed in knowledge base article MS06-061: Vulnerabilities in Microsoft XML Core Services could allow remote code execution, a good thing too considering the severity of the issue.

However this meant that people suddenly was unable to search for products in the BizDesk catalog system. Clicking the “Find” button simply didn’t do anything. I tracked down the code responsible for searching in the /Microsoft Commerce Server/Widgets/ListHTC/ListSheet.htc where, of course, I found hard coded version progids for MSXML2. Once found the fix was quite easy: Simply remove the version specific parts of the progid and the BizDesk is flying once again. Additionally several other pieces of code in the BizDesk are affected so you need to track down the 2.6 version progids adn remove them to get everything working. Specifically I found references to MSXML2.XMLHTTP.2.6.

Talk about detective work

posted on Monday, 23 October 2006 10:33:00 (Romance Daylight Time, UTC+02:00)  #    Comments [1] Trackback
# Wednesday, 30 August 2006

Having trouble viewing profile definitions in Commerce Server Manager on Windows Server 2003? I did and after some poking around I found the answer: Enhanced IE Security. Turns out that the hardenend IE disallows access to the profile editor resulting in a “Editor Loading…” message which just sits there… forever

To get the profile definition editor to load you need to do the following:

Open Add/Remove Programs.

Click Add/Remove Windows Components.

On Internet Explorer Enhanced Security Configuration click Details.

Uncheck the “For administrator group” and “For all other user groups” checkboxes. Alternatively you can uncheck only the “For administrator group” if you are running as admin.

Click OK and you are good to go.



posted on Wednesday, 30 August 2006 15:00:33 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Saturday, 26 August 2006

Hands on webcasts containing actual implementation examples of the various subsystems:

Commerce Server 2007 BizTalk Adapters In Action
Presenters: Brian Blum and Alan Faulkner, Microsoft
In this session, Brian and Alan walk you through all aspects of working with the Commerce Server BizTalk adapters. The session covers creation of send ports and receive ports, property schemas, configuration validation, schema deployment, and troubleshooting. Along the way, you'll learn invaluable tips and techniques for successfully developing integration applications with Commerce Server 2007 and BizTalk Server 2006.

Developing with the Commerce Server 2007 Marketing System
Presenters: Madhur Joshi and David Lott, Microsoft
The Commerce Server 2007 Marketing System provides rich user-centric targeting functionality including discounting and promotions capabilities, targeted advertising, and personalized direct e-mail campaigns. In this session, Madhur and David show you first-hand how to harness the power and flexibility of the Marketing System runtime. Topics covered include: house ads, paid ads, targeting expressions, direct e-mail template creation, web.config settings used by the Marketing System, code for running the basket pipeline for discounting, and troubleshooting techniques.

Commerce Server 2007 Product Catalog Deep-dive
Presenter: Austin Skyles, Microsoft
The Commerce Server 2007 Product Catalog System is a highly scalable and high-performance system for modeling electronic catalogs. It includes a flexible schema model, powerful XML import and export capabilities, rich search features, a Web service interface for building distributed applications, and out-of-the-box applications for catalog management. In this session, Austin explains these aspects of the system, covers a high-level view of the architecture, and shows how to get started with coding against the system.

Commerce Server 2007 Overview
Presenter: Mark Townsend is the Group Program Manager for the Commerce Server team.
Commerce Server 2007 is Microsoft’s answer to extend ASP.NET 2.0 to support e-business scenarios. This talk provides overview of the e-commerce functionality in Commerce Server 2007 plus the supporting Business User and IT Professional tools included to provide an end-to-end e-commerce solution.

Multi-Channel, Connected Commerce (BTS/CS integration)
Presenter: Caesar Samsi is a program manager on the Commerce Server team.
Enabling multi-channel retail scenarios beyond point-of-sale or online-only sales, integrating with line-of-business systems, and synchronizing data with B2B trading partners represent three of the largest challenges in e-business today. This talk provides an overview of how Commerce Server 2007, in partnership with BizTalk Server 2006, provides a compelling answer to this complex technology challenge.

Commerce Server 2007 Webcasts

posted on Saturday, 26 August 2006 15:59:42 (Romance Daylight Time, UTC+02:00)  #    Comments [1] Trackback
If you are interested in Commerce Server at all you need to add Max Akbar to your subscription list. He produces some very solid posts that I wouldn’t want to miss out on.
posted on Saturday, 26 August 2006 12:10:37 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback

As promised the Commerce Server team has released the Starter Site CTP which works with the RTM version of Commerce Server 2007. Be sure to read Ryan Donovan’s post as it does contain important information you need to know before messing around with the CTP.

Also worth of note the final version of the Starter Site should be available in October.

CS2007 Starter Site CTP Now Available

posted on Saturday, 26 August 2006 12:01:00 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Wednesday, 02 August 2006

CommerceServerIf you are anything like me you are currently hungering for concrete CS 2007 information on actual development. Well look no further, Microsoft has released three web casts covering the BizTalk Adapters, the Marketing System, and finally the Product Catalog.

Microsoft Commerce Server Webcasts on TechNet

posted on Wednesday, 02 August 2006 22:46:14 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Thursday, 27 July 2006

CommerceServerLooks like Microsoft has some more good news for people wanting to get their feet wet with Commerce Server 2007: The trial version which can be downloaded free from the Microsoft web site is actually the developer version meaning no expiration dates on the trial.

Very good news which I hope will get more people onto the Commerce Server-bandwagon. Get the your trial/developer edition from Micosoft and read Ryan R. Donovan’s post Commerce Server 2007 Developer Edition Available (and it's free).

posted on Thursday, 27 July 2006 13:53:53 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Wednesday, 28 June 2006

CommerceServerI can never remember what the different class types in the catalog table means, and finding the information in the documentation takes forever, so here they are for my own benefit more than anything else:

  • i_classType 4 == Product
  • i_classType 8 == Product Family
  • i_classType 2 == Variant
posted on Wednesday, 28 June 2006 10:41:33 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Tuesday, 27 June 2006

CommerceServerJeff Lynch has some pretty sound advice for developing Commerce Server solutions, and I’d go as far as to say any solution which requires integration with some kind of backend system.

As many of you know, I develop business-to-business e-commerce solutions for the company I work for. These solutions are generally built using Microsoft's SQL Server, BizTalk Server and Commerce Server products. My overall goal when developing an e-commerce solution is to automate B2B transactions between trading partners in our supply chain. In doing this, I've found that "beginning with the end in mind" is the only way I know to ensure the success of our development projects. In Commerce Server 2007, following Stephen Covey's 2nd Habit has been absolutely vital to our success.

Commerce Server 2007: Begin with the End in Mind!

posted on Tuesday, 27 June 2006 20:40:55 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Thursday, 22 June 2006

CommerceServerThere have been a couple of questions about how to use and integrate MSCS Authentication with ASP.NET Authentication.  For those of you that don't know, MSCS Authentication is Microsoft Commerce Server's authentication cookie/ticket that is used to identify Commerce Server Profile users.  With Commerce Server 2007, we recommend you use the ASP.NET's membership provider but then the question arises, how does our web analytics use and decode this cookie? “

Read more on Commerce Server 2007 Authentication with ASP.NET Authentication.

posted on Thursday, 22 June 2006 13:37:26 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Sunday, 18 June 2006

I forgot to point out one important piece of information from Ryan Donovan's CS 2007 release post. What I failed to mention because my job generally doesn't entail having to deal with licenses and such is that pricing and the editions of CS will remain the same for 2007 as they were for 2002. So that's good news :) Now we can back to the regular scheduled programming involving all the fun technical stuff :)

posted on Sunday, 18 June 2006 19:35:22 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Saturday, 17 June 2006

I am pleased to report that Commerce Server 2007 has shipped (or RTM-ed in MicroSpeak). Tonight the team has signed off on the Enterprise, Standard, and Evaluation editions in English, French, German, and Japanese. This is another remarkable day in Commerce Server history – as it represents the culmination of 2.5++ years worth of efforts to bring what we think is a very cool solution to market, featuring major enhancements“

Commerce Server 2007 has shipped!

posted on Saturday, 17 June 2006 09:22:22 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Tuesday, 13 June 2006

CommerceServerWith Commerce Server almost done it’s good to hear that the StarterSite is receiving extra attention and that it will be available as a web download meaning that we’ll see more frequent releases than we did with the retail sites.

I’m very much looking forward to seeing what the final StarterSite has to offer as the beta version didn’t have a whole lot to look at. Lets hope that folks have gotten the message and don’t base their entire frontend on the StarterSite which has been the case often times in the past.

Check out the Starter Site Update post by Ryan Donovan for more information.

posted on Tuesday, 13 June 2006 13:37:33 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Friday, 09 June 2006
CommerceServerYou can now find the CS07 RC documentation on MSDN.
posted on Friday, 09 June 2006 12:37:10 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Friday, 02 June 2006

Here’s an obscure fact for you if you’re still running Commerce Server 2000. Recently we needed to upgrade our database server which is running on Windows Server 2003 to Windows Server 2003 SP1. Now SP1 introduces some new security aspects for MSDTC which means that requests can be authenticated. Unfortunately for Commerce Server 2000 the default setting is to authenticate everything which renders CS unable to connect to its data store. The symptom of this is varied: I’ve experienced both a direct error from MSDTC and a non responding web site and, the former is easily diagnosed the latter is not.

The solution to this mess is the following:

Through Run in the start menu bring up dcomcnfg.

Expanded the Component Services / Computers nodes.

Right-click My Computer and choose Properties.

Click the MSDTC tab.

Click the Security Configuration Button.

Check the Network DTC Access.

Set No Authentication Required.

Click OK.






posted on Friday, 02 June 2006 15:50:41 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Wednesday, 31 May 2006

CommerceServerVinayak has a great post on the expanded virtual catalog feature of Commerce Server 2007. If you are wondering what the new version of CS will bring check it out. Here’s a snip for you:

“Virtual catalogs is a key feature we improved upon in Commerce Server 2007 to allow you to further customize your base and virtual catalogs. These features will enable additional  scenarios which were not possible in previous versions. If you are not familiar with virtual catalogs, read this post.”

New Virtual catalog features in Commerce Server 2007

posted on Wednesday, 31 May 2006 10:10:10 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Tuesday, 30 May 2006

CommerceServerIn case you were wondering whether we would be left out in the cold with regards to Business Tool customization you can put your unease to rest. Ryan Donovan blogs in no uncertain terms that we will be able to modify the Business Tools as Microsoft will be making the source code available. Great news indeed.

Thanks to Simon for pointing the post out as I missed it entirely:


posted on Tuesday, 30 May 2006 11:05:03 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Wednesday, 17 May 2006

CommerceServerLooks like we’ll have a release candidate of Commerce Server 2006 to play around with very soon according to Ryan Donovan’s post Release Candidate: On Final Approach....

I’m currently looking into the new stuff provided by the new release having previously worked with both 2000 and 2002. Lots of new stuff has been added along with improvements on what was already there making it cooler than ever.

Looking forward to getting my hands dirty with some code.

posted on Wednesday, 17 May 2006 14:53:35 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Wednesday, 20 April 2005

If you work with Commerce Server you will find the following tools invaluable. These tools were created by Max Akbar, who recently joined our Program Management team, but has been working on Commerce Server for a long time and has a very detailed knowledge of everything Commerce Server. Kudos to Max for sharing these out (for all these years!) with the community.

[Nihit Kaul's WebLog – Cool Tools for Commerce Server]

posted on Wednesday, 20 April 2005 10:02:59 (Romance Daylight Time, UTC+02:00)  #    Comments [0] Trackback
# Thursday, 17 March 2005

For the past months I’ve been working on putting together the new Bolia.com site, or rather some usability improvements suggested by an expert in the field. The main difference between the new and the old site is that the checkout process is a bit more intuitive and you’re able to click back and forth between the individual steps. Also the catalog has undergone major surgery and is now much better organized and presented than previously. Currently only the Living Room / Sofas category has been adopted to the new layout, so be sure to check back and see what they do with the remaining categories.

Finally search optimizations have been put into place which should make finding the furniture you want on the Bolia.com site much easier using Google, Yahoo, or whatever your favorite search engine might be. We have great plans for version 2.0 which will sport some cool URL rewriting features.

I for one think the new site reflects the current trends on the web much better (I should, shouldn’t I?). Also I had a chance to view the new design on our recently purchased Mac mini for testing purposes. What can I say the design fits right in there with Mac OSX.

This morning was the culmination of the development effort with a large deployment of the new design along with the entire catalog which has had 1600 new products added over the past weeks. Behind the covers this is a pretty big undertaking so much care and planning has gone into the deployment testing for my part. Of course that didn’t stop me from staying up all night yesterday fixing the small problems which invariably crop up.

Anyways go have a look around a tell me what you think, will ya?

posted on Thursday, 17 March 2005 08:55:42 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback