# 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, 14 January 2008

My favorite news reader of all times, FeedDemon, is now free for anyone to download and use. What makes this guy stand out from the competition is not the simple and easy to use UI, it's not the fact that you get a nice Hot/Not list of feeds, not the fact that you can subscribe to any quirky feed on the planet.

No what really makes FeedDemon shine and what made me cough up $29,95 having tried the product only a couple of times is the synchronization features. Simply put FeedDemon has made me use RSS more than I did in the past because I don't have to worry about reading my feed in multiple locations. Now to be fair Google Reader does provide the same feature but I simply can't bring myself to read my feeds in a web interface. With lots of information rolling by I need a nice work flow to process everything; while Google has done everything possible to make this happen in their web interface it's simply no match for a well designed desktop application.

To put it short, download FeedDemon, synchronize and be happy. Even if you don't read feeds in multiple locations you'll still have off site backup for your feeds ;)

posted on Monday, 14 January 2008 21:52:25 (Romance Standard Time, UTC+01:00)  #    Comments [0] Trackback
# Sunday, 13 January 2008

I'm starting to look into the ASP.NET MVC Framework and needed to download the CTP just now which is not all that interesting. What is interesting though is the fact that I was greeting with a dialog asking me whether I wanted to try the new Silverlight version of the MS Download site. Naturally I couldn't resist :)

Check out the MS Download Center beta done in Silverlight.

posted on Sunday, 13 January 2008 14:42:45 (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.

Deployment

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.

Pipelines

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