Recently, some of our clients have been asking for more complex shipping solutions, for example, where shipping restrictions need to be implemented or when one particular product triggers an additional shipping cost.

During the past month, we have implemented the following shipping solutions in ASPDotNetStorefront MLv9 (but the same changes should also be possible in v7 and v8):

- Shipping costs that vary by product type
- Additional shipping costs for specific products
- Restricted shipping for certain products (e.g. product x cannot be shipped to country y)
- Shipping method restrictions (e.g. product x cannot be shipped via Air)

At checkout, the Customer is shown a clear description of their shipping costs along with any rules that have applied to their cart. They have the choice of adjusting the cart at this stage to alter the shipping costs applied.

If your business has a requirement for more complex shipping solutions than provided in the standard ASPDotNetStorefront installation, then get in touch and Webopius will be able to discuss your specific requirements.

Well-written Ajax pages give a site a much more interactive feel without the constant need for page refreshes to generate new content each time something is clicked.

Unfortunately, at the time of writing this article, there are still a number of areas within ASPDotNetStorefront that could benefit from Ajax. One of these is the product ratings / product comments system.

An Ajax product comments module for ASPDotNetStorefront

Currently, within ASPDotNetStorefront MLv9 (and earlier releases), product ratings and comments can be shown within the product page. To add a new rating, a customer is presented with a popup window where they enter their rating. They then click submit and the product page is refreshed with the new details.

As more comments for the product are entered, the customer can move between different pages of comments – again, this involves refreshing the same product page.

We didn’t feel the existing comment/rating system was suitable so Webopius recently built a new Ajax-based product comments module for a client that has the following features:

• New product comments can be entered directly on the page without refreshing
• Comments enter a moderation queue and a new administration page allows site owners to filter comments before they are published
• It is now possible to move between pages of comments dynamically on the page without requiring a page refresh
• The comments block can be collapsed and hidden from view by the user
• The system records the details of the user submitting the comment but the user can choose a display name themselves to keep the comment anonymous
• New comments are validated at the time the customer submits and basic errors are reported back to them immediately

If you would like a similar Ajax ASPDotNetStorefront module installed within your ASPDotNetStorefront site (including versions 7,8 or 9) then please get in touch with us to discuss your requirements. Almost anything is possible with ASPDotNetStorefront, in many cases without requiring the source code and Webopius have extensive experience of extending and modifying the product for both large and small customers.

Once you get beyond a few thousand products, you may find yourself looking for a faster method of importing products into your store. This is almost certainly going to be the case if you regularly need to update your products along with pricing and stock availability.

High volume product import for ASPDotNetStorefront

Webopius have recently developed a high-volume ASPDotNetStorefront import module for a couple of clients. In one case, the client have in excess of 100,000 products that they need to update daily. The updating involved creating new products, updating existing products, handling variants, category mapping, pricing and inventory – a lot to do quickly.

Using the standard ASPDotNetStorefront import methods on this number of products took hours to run. Even our initial attempt to develop a module resulted in a processing speed of approximately 1,000 products a minute. Fast, but not fast enough.

By making some enhancements to the code, at the time of writing this article we now able to import and update between approximately 10,000 and 15,000 products per minute. [Note: Of course, performance will vary depending on many factors and each installation is different]

Performance tuning the ASPDotNetStorefront product import

The high-level steps we took to create a fast product importer are listed below. If you would like Webopius to create a custom product import system for your ASPDotNetStorefront site, then please contact us.

1. Use XML as the source format

The first step we took was to get the source data into an XML format. XML is the ideal language of choice for ASPDotNetStorefront, SQL Server and ASP.Net. The resulting files can be parsed and passed quickly between the various site components.

2. Use XMLTextReader to parse and read the source file

If you’ve ever looked through Microsoft’s XML documentation, you’ll see there are a myriad of ways to read and write XML – XMLReader, XMLTextReader, XPathNavigator, XmlDocument …

XMLTextReader is ideal for processing large XML document streams. It reads forward through the file without doing a great deal of validation or using XPath/XSLT. Basically, it’s quick.

3. Process the data in batches

Rather than processing the data a product at a time, you should process blocks of products in one go. In our case, we read 1,000 products, then package them up in a single call to the database.

If you don’t do this, every product incurs one or more calls to the database and slows the processing down significantly.

4. Move all processing to the database

Of all the performance tuning, this is the one for focus your effort on. Move as much of your data checks and processing to SQL Server as possible.

SQL Server is a data crunching powerhouse. Why do product SKU lookups or Category mapping in your C# or VB code when calling the database can do the same job hundreds of times faster?

Originally, our code logic looked something like this:

- Take product SKU from XML, call the database to get a Product ID
- If ProductID was 0 (SKU not found), then this is a new Product, DB insert needed, otherwise DB Update needed
- If insert performed, lookup the new ProductID for the Category mapping
- For each category mapping in the XML source file…
- Look for an existing category mapping, create one if none exists
- Delete any mappings that aren’t in the XML source file.

A sensible approach but crazy when SQL Server is sitting around waiting to do the job for you. We moved as much of the ASPDotNetStorefront import processing into SQL Server stored procedures as possible. We pass the batch of 1,000 products in XML format to a custom written stored procedure that create/update products and variants and a second procedure to handle the category mappings. This second category mapping procedure was the most complex to write as it has to handle deleting category mappings accurately and quickly.

The new code logic looks something like this

- Pass 1,000 Products in XML format to SQL Server
- [In Database], Move the XML source file into a temporary database table
- [In Database], Lookup the ProductIDs based on the XML SKU field value
- [In Database], Any non-matching SKUs will have a Product ID of 0, insert new products and variants for these
- [In Database], For the other non-zero Product IDs, update products and variants
- Pass Category mappings for 1,000 Products in XML format to SQL Server
- [In Database], Create new Product Category mappings based on XML file
- [In Database], Remove any Product Category mappings for the products in XML where category IDs don’t exist in the source file.

5. Optimize your ASPDotNetStorefront SQL Server indexes

Finally, we took each of the key SQL Select statements used in the above processing and ran them through an Execution Plan in SQL Server Management Studio.
This highlighted a number of areas where additional indexes could be created to increase performance – particularly in the SKU lookup step.

High volume, fast product data importing in ASPDotNetStorefront

If you would like a custom product importer written for your ASPDotNetStorefront site, then please get in touch. In addition to the module described above, other examples of import/export modules Webopius have written include:

• Excel-based product importer supporting multiple languages
• XML product importer to enhance product listings with data from ICECAT.biz
• Excel importer with custom field support such as Author, Account codes, Publisher etc.
• XML export routine to auto notify warehouse provider of new orders, also updates ASPDNSF shipping dates, tracking details

Other articles about ASPDotNetStorefront

Sometimes, your business needs a more complex, scheduled solution that can automatically update your product, category, manufacturer and inventory data based on external data sources or triggers. Alternatively, you may want to notify third party providers of changes to your product or order date. This can include ERP, Accounting, CRM, Warehouse and Fulfilment systems.

Custom ASPDotNetStorefront (ASPDNSF) automated data updates

Webopius have developed a number of custom in-bound and out-bound data feeds for ASPDotNetStorefront. We can integrate with almost any system that can provide data as XML, CSV, Excel, via an API or other file formats.

Some examples of custom data modules we have developed for ASPDotNetStorefront…

• Enhanced Excel product and category importers
• Inbound inventory feed that automatically updates product stock levels based on warehouse stock/customer returns. Runs daily.
• Outbound order feed to a fulfilment provider – notifies them of new orders and updates the ASPDNSF shipped/tracking info as items are shipped. Runs hourly.
• Inbound product feed from ICECAT
• Inbound XML product and inventory feed module based on data from third party product database

None of the above modules have required changing the core ASPDotNetStorefront source code and most sit alongside the existing store and are scheduled to run on a regular basis.

If you would like to enhance your ASPDNSF site with near real-time data updates, then contact Webopius with your ASPDotNetStorefront requirements for a no obligation estimate.

This is one of the first UK sites to be running on ASPDNSF version 9 and almost certainly the first to be running v9 with the Sage Pay UK payment gateway.

Custom ASPDotNetStorefront Development

Not content with a straightforward upgrade, Webopius also developed a number of custom features for the new Urban Excess site including:

• Wordpress blog integration with ASPDotNetStorefront
• Lots of nice JQuery effects
• SagePay error reporting module, no longer just ‘payment not accepted’, also tells the Customer why there card didn’t work
• Dynamic Sizecharts
• JQZoom for product images
• Custom product pricing display in the category and product pages
• ‘Sale’ image overlays on products for sale
• Dynamic CSS using XMLPackages depending on the category (e.g. Mens, Womens)
• Product filtering by Brand, Price, Sale etc on the category pages
• Custom paging control
• Fixes for some ASPDotNetStorefront VAT issues

ASPDotNetStorefront v9 – plan in advance

Moving to Version 9 of ASPDotNetStorefront should not be taken lightly. A lot of preparation is needed in addition to migrating all your site skin templates to the new format. We spent at least 3 weeks beforehand running the site on a staging server and we also went through at least 5 dry runs of taking the existing version 7 database and upgrading it to version 9.

It’s early days, but the site is now running well. Despite all the preparation, we did have a few hours of panic when the site went live but this appears to have been resolved by recycling the IIS server’s application pool.

ASPDotNetStorefront v9 upgrade and migration services

Webopius have now worked on many ASPDNSF version 7, 8 and 9 sites and have particular strengths in getting European businesses running on ASPDotNetStorefront. If you would like to discuss getting a world-class e-commerce system implemented, then contact us for a chat.

It helps solve the problem where an order receipt sent to the Customer and displayed within the Admin pages calculates and displays the product prices and discounts incorrectly due to VAT.

VAT Calculations in ASPDNSF

In version 9 of ASPDotNetStorefront (and some earlier releases), products that have their prices stored excluding VAT/Tax store the price to 4 decimal places, as an example:

4.2574 plus 17.5% VAT (probably increasing soon!) = 5.002445 = £5.00 on screen rounded to 2 decimal places.

Unfortunately, the order receipt XSLT extension (ReceiptXsltExtension) doesn’t get this quite right and calculates to 2 decimal places before adding the VAT like this:

4.26 plus 17.5% VAT = 5.005 = £5.01 on screen which of course is not ideal.
In addition, any discount amounts in the order receipt are shown excluding VAT.

Fix for VAT rounding in ASPDotNetStorefront

To resolve this, you need to edit /App_Code/ReceiptXsltExtension.cs (make a backup first!). Within the ‘PreComputeLineItemIntrinsics’ method at about line 613, change the price calculation to 4 decimal places:


price = Math.Round(price, 4, MidpointRounding.AwayFromZero);


This will resolve the VAT problem. Then, to fix the discount issue, add the following code after the ‘displayExtPrice’ block at about line 630:


if (!isAKit && !isAPack) {
discount = (( Math.Round(displayPrice, 2, MidpointRounding.AwayFromZero)*quantity) - displayExtPrice);
discount = Math.Round(discount, 2, MidpointRounding.AwayFromZero);
}


That’s it. Give your site a few seconds to rebuild the new code and now, your order receipts should be correctly calculated.

Note: No warranty or support can be provided with this code. Make the change at your own risk!

In ASPDotNetStorefront ML9, at checkout you may find that the list of available Shipping methods are shown excluding Tax/VAT. However, the order subtotals and tax calculations are still correct so this is really just a presentation issue for your Customers.

Webopius have developed a fix for this that can be implemented without the full source code. If you would like this implemented on your site, then please contact us.

Order Total out by 1p / 1c

Depending on your tax rates, another issue that you may experience is that your Order Total is shown out by 1 pence / 1 cent.
Again, until a new release of ASPDotNetStorefront is available, Webopius can resolve this for you. You will require the full source code license though in order to have this change made for you.

If you would like this implemented on your site, then please contact us.

The order subtotal and tax calculations are correct based on the order items AND the shipping method selected however, no shipping details are shown in the summary.

How to fix the missing shipping in the order summary at checkout

It took us a while to debug this but the issue is due to the ASPDNSF CartSummary control not correctly detecting the value of the AppConfig ‘SkipShippingOnCheckout’. The control is expecting a value to be given to it (rather than looking up the AppConfig setting) and if none is found, it assumes that Shipping should be skipped which is why no shipping totals are shown at checkout.

The solution is to edit your site’s checkoutpayment.aspx file and look for the ‘Total Summary’ block which is using the aspdnsfc:CartSummary control. Within this control, you’ll see various parameters being set such as TaxCaption, TotalCaption, ShowGiftCardTotal etc.

Add the following line after ShowGiftCartTotal=”true” and before the closing />


SkipShippingOnCheckout="false"


That’s it! Now, your shipping costs should be correctly displayed at checkout.

For other ASPDotNetStorefront tips, advice and solutions, please click here

To contact Webopius about ASPDotNetStorefront development services, please click here

We’ve now tuned the migration process to be quick including changing skins to the new master template format (which is actually pretty straightforward once you’ve done it a few times).

We have also created solutions to make the migration process as straightforward as possible including:

- Support for passing current entityID and entityName into XMLPackages
- Improved custom menus
- Minicart controls
- Fix for ASPDNSF tax/VAT rounding at checkout
- Fix for AddToCart form when products have TrackInventoryBySizeAndColor set
- Fix for Wishlist ‘continue shopping’
- Search products by Price, Ranking and other custom fields such as Sale Items

As a real-world example taking v7 to v9, we installed MLv9 on a staging server, ran the database upgrades to take the old site from 7 to 8 and then to 9. Finally, we changed the existing page templates to and copied the skin files into their correct locations. All done within 1 day followed by more testing.

Webopius can also assist in re-writing any of your custom code for ASPDotNetStorefront MLv9, even in cases where you may not have the original source code.

If you are interested in migrating to ASPDNSF MLv9 or are considering a new installation, then contact Webopius for a no obligation price.

In order to migrate your site to MLv9, you will need to go through an exercise where you update your existing skins to the new Master template format. This can take some time as you will need to change the menus, search and tokens amongst other things.

What is currently less well documented is that if you are using embedded XML Packages within your templates, the way the page name is passed to the XMLPackage has changed and the entity ID and ‘lastviewedentityinstanceid’ cookies do not appear to be sent to the package at all.

XML Package parameters in ASPDotNetStorefront MLv7 and MLv8

In previous versions of ASPDNSF, you could use an XMLPackage from within your skin templates by embedding some code like this:


(!XmlPackage Name="header.xml.config"!)


Within MLv9, this has changed slightly to the following format:


<asp:Literal runat="server" Text="<%$ Tokens: XmlPackage, header.xml.config%>" />


In previous releases, you could find out the following from within your XML Package:

The pagename

<xsl:value-of select="/root/System/PageName"/>


Returning, for example, ’showproduct.aspx’ which you could use to determine if the current page being viewed was a category page, product page etc.

The current category entity ID

<xsl:value-of select="/root/QueryString/categoryid"/>


Which would allow you to act differently depending on the entity being viewed. For example, to generate a different header depending on which category was being viewed.

The last viewed entity ID

<xsl:value-of select="/root/Cookies/lastviewedentityinstanceid"/>


ASPDotNetStorefront MLv9 custom XSLT Extension library

In MLv9, the page name returned is now the full page name, e.g. ‘c-2344-televisions.aspx’ and the query string parameters and cookies are no longer generated.

The solution…

Webopius have written a custom XML library that can be installed within any ASPDotNetStorefront installation and provides the following functions that can be used within any XML Package:

getEntityID

<xsl:value-of select="Webopius:getEntityID(/root/System/PageName)"/>

Returns the entity ID when passed the current page name. For example passing ‘c-4542-accessories.aspx’ will return ‘4542′.

This function will also write a cookie based on the entity type. In the above example, it would write a cookie called ‘lastviewedcategoryid’ which you can use in subsequent pages. Products, Manufacturers, Genres, Distributors, Vectors and Sections are also all supported.

getEntityName

<xsl:value-of select="Webopius:getEntityName(/root/System/PageName)"/>

This will return the current entity name based on the page being viewed, such as ‘category’,'product’,'manufacturer’ etc.

Using both of these functions, can assist in the migration of any of your MLv7 or MLv9 XMLPackages into the ASPDotNetStorefront MLv9 environment.

ASPDotNetStorefront Migration services from MLv7.x and MLv8.x to MLv9.x

If you have an existing ASPDotNetStorefront MLv7.x and MLv8.x store and would like to upgrade to MLv9.x, then please get in touch and we’d love to help.

Webopius can:

- Install your v7.x/v8.x site onto a staging server ready for upgrading
- Upgrade your database to ASPDotNetStorefront MLv9.x
- Handle any collation issues when migrating the database
- Import the updated MLv9.x string resource libraries for all your supported locales
- Update all your existing skin templates to the new MLv9.x format
- Update all your existing custom code to work within MLv9.x. If you have the source code to the changes this is a straightforward exercise. If not, we can usually re-write the code for you.
- Develop new custom components and XML packages as required to enhance your site within MLv9.x

Webopius have many year’s experience working with all ASPDotNetStorefront versions including MLv7.x, MLv8.x, MLv9.x, ML/DNN and the Interprise Suite versions. Contact us to find out more about the ASPDotNetStorefront services we can provide.