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.
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.
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.
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.
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.
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 :)
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.
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 :)
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.