July 2007 - Posts

Webparts, Wonderful Webparts
by Mark Strawmyer 07.19.07

No Comments

As we were designing out the myColts.net site we went through a lot of possible design concepts. We were chasing after the ability to be able to support a site where you could radically changes the look or layout without a ton of effort. The Colts are in the entertainment business, so there is an extreme need to be fast and nimble and change on a dime to take advantage of opportunity. Do you use content management and templates? Use concepts similar to DotNetNuke where there is one page that loads webparts dynamically? During design exploration I just kept coming back to thinking about SharePoint and the way that portals work. The idea of being able to allow users to have various templates from which they could choose to make their profile page look, or even possibly give people the option to design their own page altogether was very appealing.

We did some early prototyping to see how far we could push some of the webpart plumbing that was newly available in Microsoft .NET 2.0. We were concerned that it would be extremely difficult to figure out how to get something workable to provide the plumbing we were going to need. As it turned out, we had a couple of parts that fit very well together. We had a custom built content management system that is database driven. We tossed a few web part zones into an ASPX page with a master page with multiview to support display and edit mode. The edit mode allows webparts to be pulled from the webpart catalog and stored on the page. The structure was then stored in our CMS. The entire blob could then be retrieved that had the page structure set with webpart placement. The webparts would then render. This set the stage for us to provide different templates by loading the page in edit mode, setting up the webparts differently, and then saving the metadata of the page layout off in the database. At runtime we then retrieve the desired page template for display. And a flexible and dynamically set system is born!

From the results to date, I would definitely call it an early success. We launched the myColts.net site back in mid-June. Since then we've added another profile layout which consists of nothing more than a page template with the webparts laid out differently on the page. Users have the option to set which layout they want, which is nothing more than storing the ID of the page to display with the chosen layout. Additionally, just today, I'm happy to announce the launch of myIndianaFootball.net. myIndianaFootball is a site that is built on the myColts.net technology to provide a site dedicated to Indiana High School football. The beautiful part about it is that it really isn't much more than a different theme applied to a set of webparts built to provide specific functionality for the high school site. It is running in the exact same shell as myColts.net, so there is an ultimate amount of code reuse in the core site.

Unreliable Network Connections
by Daan De Brouckere 07.13.07

No Comments

Can you believe there are still places in this world where an always-on connection to the internet is not a given?

I was recently working on a project for a company that was in the process of finding a new system for their mining operations. This system would need to support employees in their field offices as well as management in their headquarters. As they were going through the selection process, they quickly eliminated systems based on their performance. The systems performed very well in “demo-in-a-box” situations. However, when a pilot was attempted at one of the field offices, network issues made all of the “web-based” contenders nearly unusable. Beyond terrible response time, the network would just plain drop off at random points during the day.

The easy answer that came to mind was: FIX THE NETWORK! After several meetings with business and IT senior leadership, it became clear that this easy answer was not feasible due to the dynamics of the organization. Why would IT improve the network for one business unit?

The next alternative that came to mind was: REPLICATION! Why not put a server at each of the field offices and replicate? Although much marketing material is written around replication by the major relational database vendors, basic concerns still need to be addressed such as uniqueness and conflict resolution. If the same item is edited by two users at different locations, is it ok for one of those users to lose their changes? Should a system administrator manually resolve this conflict? How quickly should users in other offices see changes? How do you assign a unique “business-relevant” identifier to an item?

We decided to go down the replication path. A master database was implemented at headquarters and slave databases at each of the field offices. We started with a replication period every 24 hours but quickly changed that to every 5 minutes when we discovered the importance of sharing the latest, greatest data with all sites. We currently have automatic conflict resolution configured so that the master database always wins in case of a conflict. Combined with the 5 minute replication, we’re seeing very few conflicts!

The key to a successful replication solution is ensuring these technical concerns are evaluated in light of the business requirements and expected customer experience.