Solutions Customization and Integration – Part III

It has been a while since I posted an update on this project… So here it goes.

Since my last post, the project I am working on has evolved to a 3-piece solution tying in AspDotNetStorefront ML 7.0, Community Server 2007 SP1 and a fully custom e-Learning solution built on Flash and .NET controls.

Due to the complexity and unique features on this project, the architecture and design grew to be very specific and custom – beyond the normal skinning of the out-of-box products and turning features on/off. The final architecture came down to an intermediate Data Application Layer (DAL) and Business Logic (BL) layer that encapsulates and partly overrides the methods/classes provided by Community Server and AspDotNetStorefront. The thinking behind this implementation is to retain the core functionality of both systems, allowing us to implement software upgrades easily and support the application maintenance and enhancement lifecycle. The e-Learning system, being that it’s designed from scratch, will expose a custom BL and DAL.

Interfacing with Community Server’s and AspDotNetStorefront’s API allows us to work outside the framework of classes/methods provided by both products, as well as build our own custom layer of methods/classes to define and produce entities that consume/provide data apparent to the application as designed. The presentation layer, will be modeled around the common ASP.NET practices of .aspx files, custom controls and a selection of controls from ComponenetArt’s WebUI product.

The single sign-on architecture has changed slightly since my last post. The approach taken now, for the sake of simplicity and ease of management, is to have Community Server act as the central point for account management/creation using ASP.NET’s membership provider, and have back-end processes that replicate billing/transactional data to AspDotNetStorefront. This allows us to collect all the data we need about a user in a User entity from the Community Server and AspDotNetStorefront databases.

The project is currently undergoing the initial stages of development, with a target date for launch of mid-2008. Stay tuned for more updates…

AspDotNetStorefront Configuration Best Practices

Below is a list of some “critical” items that should be configured in your AspDotNetStorefront production environments.

> Rename and secure the “admin” folder:

1. Change AppConfig.AdminDir
2. Change the folder’s name
3. Assign a Windows-level login to that folder

> Change admin username from admin@aspdotnetstorefront.com to something within the site’s domain

> Change admin password to something cryptic and set AppConfig.AdminPwdChangeDays to something reasonable/safe

> Set strong passwords (optional)

AppConfig.UseStrongPwd = true

> Cycling your encryption key

The admin will auto-notify you based on AppConfig.NextKeyChange value. Use this page in the admin to reset your encryption key manually: changeencryptkey.aspx

> Set this AppConfig so the user is not always trapped in an SSL state after hitting My Account and/or Checkout pages.

AppConfig.GoNonSecureAgain = true

> Reset Cache

This is actually a call to a stored procedure and can be automated in the DB as a trigger whenever a catalog change occurs.

exec aspdnsf_CreateMissingVariants

You should always run it after any product catalog changes, as well as AppConfig and String Resource updates.

> Admin SSL

Configure IIS to force SSL on the admin folder.

> Caching

AppConfig.CacheMenus = true

> Monthly Maintenance

This should be run monthly on weekends late at night… Admin/Misc/Monthly Maintenance

AspDotNetStorefront Scalability

With the recent buzz and excitement around AspDotNetStorefront (ASPDNSF), and not to mention their amazing growth from a less than $100 shopping cart to what they are now, one can only wonder how far can this thing go? The moon? The stars? Well, it all depends on what you want to accomplish with it, and how scalable ASPDNSF is.

A little side note on the staff/team at ASPDNSF, who I had the pleasure of meeting (including the CEO – Rob Anderson) at a recent event in El Segundo hosted by them and Interprise Solutions (since they are partnered and “integrated” now). Overall, a great team and very energetic. Their hightened participation with the developer community has taken the Open Source model, to a certain extent, and brought it to the .NET community – offering their entire source code to customize as you please is a big plus. In fact, sending them recommendations for enhancements is encouraged, which is great. Keep on keeping on ASPDNSF!

Now, back to scalability… According to Wikipedia’s entry on scalability: scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged. So what does that mean for ASPDNSF?

If anything, the main area of focus for scalability concerns is with order processing – how many orders can the site process concurrently and continue to stay online. I cannot throw out any numbers because every environment is different – from hardware to bandwidth selection, and Windows to IIS optimizations.

ASPDNSF can scale very well in a Web farm and meet fairly high demands on order processing. For example, in a 4 server Web farm one can easily handle 2-3,000 orders per day and around 2-3 million hits. Selecting a good load balancer is critical, as well as configuring it right to handle requests gracefully enough so IIS can keep running smoothly.

These numbers are not entirely aligned with an “enterprise level” site (e.g. Amazon, Eastbay etc.), something Commerce Server 2007 is designed to scale and handle very well, but they are definitely ideal for small to mid-size businesses. ASPDNSF IS, which is still in its “birth phase”, offers more room for growth since the Web admin system has been removed and now entirely resides using the IS client-based Windows applications (this is very similar to the strategy Commerce Server 2007 has taken).

Some other key features to consider with ASPDNSF, so as to not put you in fear of how scalable it is:

• FAST SQL option on queries (increased db performance)
• Built in page and data caching
• Designed to handle up to 500,000 SKUs (ML/IS versions)

Another thing to consider are some of the impressive sites already running on ASPDNSF. Below are numbers/stats (collected from Compete) for some of the sites listed on ASPDNSF’s gallery:

• Crocs.com – 250,000 visitors per month
• InPhonic.com – 4M visitors per month
• ReStockIt.com – 150,000 visitors per month

That’s about it! Comments are welcome, and keep checking back for more ASPDNSF and Commerce Server articles.

Solutions Customization and Integration – Part II

Update on this project… So far I am in the stages of selecting an Learning Management System (LMS) that is SCORM compliant and offers tools to manage courses, students, learning material and deliver it in a lightweight format. One of the biggest hurdles is selecting one that has an open API/SDK to interface with Flash Streaming Video and even synchronize content with the video – e.g. time coding frames etc.

As for the social networking and commerce tools, I have selected Community Server 2007 Enterprise and AspDotNetStorefront ML. Integrating both solutions should not be too complicated since they are both .NET 2.0 solutions, offer the entire source code with the license, and operate on IIS, SQL Server 2005, ASP.NET etc.

The biggest challenge with integrating these pieces is architecting a single sign-on model. LDAP and Active Directory are possible options, with the latter more in the headlights since we are working in a 100% Windows environment. ASPDNSF and CS 2007 can integrate fairly easily for the single sign-on, and since both are somewhat independent systems, there should be little effort to get that going.

The LMS solution will be more involved since we have to map data across the community site and LMS site (e.g. learning material, class forums and discussion groups, blogs on courses etc.). Table structures are fairly open and scalable, however we will very likely use SQL Server Replication and SSIS packages to handle the back-end integration and sharing of data across systems. On the user-facing site, meshing everything together will involve a blend of ASP.NET Master Pages (what CS 2007 uses), and XML/XSLT packages (what ASPDNSF uses), and possibly a customized Master Page and .ascx control architecture for the LMS solution.

The physical architecture that has been mapped out so far includes:

> 2 load balanced Windows 2003 Web servers – 200GB HD, 4GB RAM, 32-bit dual-core, RAID config.
> Single 64-bit SQL Server, 8GB RAM, 200GB HD.
> 1TB SAN (EMC or DELL) – blogs, photos and a subset of videos.
> Fibre Channel across all machines
> Load balancer, firewall etc.
> Content Delivery Network for bulk of Flash videos and larger photos

More details on these integrations in my next post…

Solutions Customization and Integration – Part I

When faced with a Web project, one always wonders: Someone must have done that before, right?

Almost always the answer is a resounding “Yes!”, and that puts you on the path towards purchasing, customizing and launching the solution to meet the project’s requirements.

Recently, I took on a project involving a “mash-up” of a Social Networking, eLearning and eCommerce site. How do you even start on a project like that? What are the implications and costs? These are only a few of the questions that come to mind with a project of this size.

Aligning Requirements with Solutions

After extensive online research, and referencing past experiences with projects of a similar nature, I finalized the foundation of the site down to 3 products: AspDotNetStorefront ML (eCommerce), Community Server 2007 (Social Networking) and Adobe Connect Professional (eLearning).

The biggest task is to start aligning the client’s expectations and requirements with what each of the products above offer “out of the box”, and to also produce customization points that will be required in the final site.

This process generally involves hands-on meetings, product demos, documenting and the like, all towards an effort to produce documentation outlining the User Experience supported with Use Cases and Business Requirements.

Design Phase

Approaching the design is probably one of the most challenging parts of any IT project, as it requires you to essentially build the solution on paper. However, in this situation we have to approach things a little differently.

Since we are not building everything from scratch, we have to create documentation that supports several key areas of the project:

• Integration Requirements – how each solution will integrate together and deliver functionality, such as “single sign on” and data sharing
• Customization Requirements – what parts of each solution need to be customized accross all 3 layers (UI, business logic, database)
• Physical Requirements – what type of hardware and networking equipment are needed to meet the demands of the site and each solution

These documents create a foundation for us to start the project and move towards the development phase with near 100% certainty as to what the final site should look like and function. Furthermore, these documents should dictate the tasks required by a developer to be heads down in the project without much concern on how everything should be done.

Next month I will post an update on this project, with details on how the design phase progressed.