Navigation


Upcoming courses:

  • Aarhus, Denmark, March 5 - 9, 2012
  • New York City, USA, March 26 - 30, 2012
Read more on our website

About me

Brian Holmgård Kristensen

Hi, I'm Brian. I'm a Danish guy primarily working with ASP.NET e-commerce solutions using Microsoft Commerce Server.

I'm co-founder and core-member of Aarhus .NET Usergroup (ANUG), which is a offline community for .NET developers in Denmark.

You can visit my View Brian Holmgård Kristensen's profile on LinkedIn or follow me on Twitter @brianh_dk. Also please feel free to contact me via e-mail Send me an e-mail.

Categories

On this page

Archive

Blogroll

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

RSS 2.0

Send mail to the author(s) E-mail

Total Posts: 36
This Year: 0
This Month: 0
This Week: 0
Comments: 10

Sign In

Follow me on Twitter @brianh_dk
 Sunday, 16 December 2007

By default Microsoft Commerce Server 2007 is highly extensible for example in regards to extending the object model in the Order System (e.g. creating new classes or extending existing ones). Also the Profile System is properly the most extensible subsystem in Commerce Server being a general purpose data repository that allows the developer to define and store any custom data in it. While this is all great and good news, not everything on the Commerce Server platform is possible to extend and this post will focus on one specific lack of extensibility in regards to extending Payment Methods and Shipment Methods.

If you want to read more about Commerce Server 2007 seen from a developer and architect's point of view, I recommend reading my colleague Søren's "Developing with Commerce Server 2007"-series on his blog publicvoid.dk.

Requirements

In Denmark we have a national wide postal service called Post Danmark which we use as our carrier for sending letters, packages etc. This is defined in Commerce Server as one of the Shipment Methods on the specific customer solution I'm currently working on. Post Danmark also offers a service allowing the end-customer to postpone the actual payment of the order until the physical arrival. By having this option, we created a Payment Method in the system called "Post Danmark Efterkrav" ("Post Danmark Cash On Delivery"), so the customer can choose this in the checkout process. To be able to use this payment method we demand that the customer has already chosen Post Danmark as the shipment method. If the customer has chosen another shipment method we will not allow the customer to choose the cash on delivery payment method from Post Danmark, thus having the payment method depending on the chosen shipment method.

Management of Commerce Server Payment Methods and Shipment Methods takes place in the Customer and Orders Manager application. When creating a Payment Method it is possible to specify e.g. Payment Type (Credit Card Payment, Gift Certificate Payment, etc.). It is also possible to specify Name and Description of the Payment Method in the languages you want to support, plus a few more options. Unfortunately this is one of the areas in Commerce Server where you seemed to be locked by this model or behavior and you cannot do any obvious extending. Nonetheless we needed some way to do it, because we wanted to be able to specify a relation or dependency between Payment Methods and Shipment Methods. We wanted to make it possible to specify that a specific Payment Method should only be available when a specific Shipment Method was selected in the checkout process. And of course we wanted to accomplish this using as much Commerce Server standards as possible, so future service pack upgrades would not cause problems among other obvious reasons :-)

The solution

As mentioned earlier the Profile System in Commerce Server is our general purpose data repository where we can model almost anything and leverage from Commerce Server API's to do data access operations and provide security to our data store. The solution we came up with was to create two new profiles in the Profile System; one for payment method extended properties (PaymentMethodExtensionProfile) and another for shipment method extended properties (ShipmentMethodExtensionProfile) and link these profiles to the Shipment Method and the Payment Method types.

Shipped with Commerce Server comes a Software Development Kit, which among other very nice things contains the complete source code to all the business applications (except the Catalog and Inventory Schema Manager). There are two classes in the Customer and Orders Manager project responsible of displaying the dialogs for management of Payment Methods (PaymentMethodEditView) and Shipment Methods (ShippingMethodEditView) respectively. In each of these Windows Forms dialog classes, we added a new button in the toolbar, gave it an icon and named it "Extended Properties". When the user clicks on this button, we execute some code, that depending on whether it is executed from a Payment Method or Shipment Method basically just performs a search for a specific profile (our extended properties profile) specified by the unique id of for instance the Payment Method, and depending on whether the profile exist or not we open the standard profile management dialog in the right state (edit or new). If the profile does not exist, we initialize it with the unique id (our relation-key value). This is all done in a relatively few lines of code, where all we do is basically the same steps as a business user would manually do to either create a new profile or search for an existing one. All the code pieces for this is of course already in the solution, the hard part was just to find these exact pieces and assemble them to suit our requirements.

I have attached some screenshots below that shows how our feature is implemented in the Customer and Orders Manager application.

payment_method_list

The figure above shows the list of payment methods in the system.

payment_method_dialog

The figure above shows the new button we have added to the dialog, that, when the user clicks on the button, executes our custom logic that opens up the profile management dialog (either a new one, or an existing one), related to the payment method.

payment_method_extension_profile_dialog   

The figure above shows the actual profile which we use for extending the properties for a specific payment method in the system.

payment_related_shipping_method 

The figure above shows the actual relation between the payment method and the shipment method. The logical relation is established between the two extension profiles of the "Post Danmark" shipment method and the "Post Danmark Efterkrav" payment method.

Conclusion

The solution I have described here for extending Payment Method and Shipment Methods in Commerce Server 2007 works really good for us and we have added a lot of extended properties to both the Payment Method type (see screenshots supplied) and the Shipment Method type. Some of the functionality this provides is the ability to filter a specific shipment method to a specific country as well as filter a payment method based on the items added to the basket. Really cool and useful features and the best part of it: we are using standard Commerce Server all the way! :-)

Another very cool thing to mention is that when we had Max Akbar at Vertica to provide us some educational days of concentrated Commerce Server training, I gave him a demo of the feature, and his responses to it were really good.

If you have any questions or want me to elaborate more on this subject please don't hesitate to contact me in any way.

Posted on Sunday, 16 December 2007 20:12:41 (Romance Standard Time, UTC+01:00)
# | Comments [0]
Comments are closed.