Viewpoint : SharePoint 2007

The Truth About How Daily SharePoint Alerts Actually Work

Chris Domino — Thu, 26 Aug 2010 16:26:00 GMT

A document changes.

An Email gets sent.

What could be easier?

Well, off the top of my head: open-heart surgery, underwater basket-weaving, and giraffe tooth-brushing to name a few things. SharePoint alerting architecture is a powerful communications tool that provides a convenient mechanism for users to consume information from around the site.

That is, if you don't mess with them.

But of course, we are going to mess with them. We want to control the time, frequency, and appearance of the Emails. The default out-of-the-box settings work, but not quite well enough. All that my client wanted to do was simplify (not go nuts, but simplify ) the standard digest (daily) Email template, and have the notifications shoot out at 9:00 AM. I estimated about a day to do this.

All we had to do was comment out some CAML from the alerttemplates.xml file (located in 12\TEMPLATE\XML) and run an STSADM command, right? Remove the links and columns that they didn't want in the template, and set the time when alerts go out. RIGHT?

WRONG!

To make a story that is longer than it is interesting shorter and more interesting, we went from OOTB alerts to a custom template to a custom handler using IAlertNotifyHandler to alerts not working for a month to users getting Email bombs of duplicate alerts. We went through three different solutions, two different Microsoft support representatives, and one scary spelunk into the SharePoint database. However, we came out safe and sound on the other side, with a cathartic clarity around how SharePoint daily alerts actually work. It wasn't a perfect outcome; there was quite a bit of drama, but a happy client is a happy client.

What I'm not going to do is take you through all the steps required to either customize an alert template, or wire up a code handler to build the Email from scratch (which is what I opted for, since alerttemplate.xml is 10,211 lines long and besides I really like writing code). Someone already did a good enough job of that here.

Instead, I want to provide a high level description of how SharePoint 2007 alerting infrastructure is put together. As I dug though the dumpsters of the Internet looking for any clues to this end, I heard a lot of rumors and false positives and frightening tales. I also came across a new golden nuggets, either from dependable sources, my own research, or the words from Microsoft's mouth itself. So what I'm going to do is simply list out the pieces that work together to make alerts work, having already scrubbed out all the wrong turns I made while traversing down this path.

So here are the truths about daily alerts, in Q & A form...

Which timer job executes daily alerts?

The "Immediate Alerts" job.

Wait isn't that job that runs the immediate alerts?

Yes.

So the one job handles all alert notifications?

Yes.

There is no "Daily Alerts" job?

No.

Promise?

Promise.

Which server physically executes this job?

Officially: All timer jobs run on all front end servers. So any web front end (or indexer, as I've seen) that has the proper assets deployed to it for a particular timer job (DLLs, XML files, etc.) can execute it successfully. Unofficially: not really; even though Central Administration -> Operations -> Timer Job Status reports that the Immediate Alerts job runs on all servers, only one is actually doing the work.

To determine which one, you have to dive into the database. I know. It's ugly; it hurts. Shush. Run the following query against the content database for your web application:



	SELECT * FROM TimerLock

What this does is return the one and only row there will ever be from this table. The two columns are a name of a server, and a date. All we really care about is the name of the server: this is the one that's going to do the notification work. If you want to change it to another server, stop the "Windows SharePoint Services Timer" service on this box, and wait for another server to jump in and acquire this lock.

When do daily alerts get sent?

OOTB, alerts are enabled, and the Immediate Alerts job runs every five minutes. What these runs do is ask the question: Are there any alerts that want to be sent out, but haven't been? All alerts that answer "Yes!" get sent out.

So how do daily alerts know that they want to be sent?

Every alert has a time. For daily alerts, this time defaults to one day (or, more accurately, 24 hours) from the instant they are created. If you create an alert OOTB, you can select an hour on the UI, and the alert will be sent 24 hours from that time. In either case, this "Alert Time" is stored as a real, absolute time, not a TimeSpan.

So every time the Immediate Alerts job runs, it checks for alerts whose time is less than the current time. For each one, it fires the Email, and increments this time by another 24 hours.

What about the job-immediate-alerts property?

All this does is regulates how often the Immediate Alerts job runs. This has no effect if alerts are disabled (the "alerts-enabled" property is set to false). Remember, these properties are specific to a web application.

And what about the job-daily-alerts property?

The main purpose of this property is to confuse the hell out of everyone. This command has been deprecated since SharePoint 2003, but was never removed from the command line.

It has NO effect.

On anything?

NOTHING. Don't ever think about it. Ever.

So in summary?

In summary, alerts store the next time they want to be sent. Every execution of the Immediate Alerts timer job on the server that has acquired the "TimerLock" (for that content database) will send any daily alerts whose time is in the past. Finally, it will increment these times by 24 hours.

Anything else?

Now, there's one other phenomena that I've observed with all this alert stuff: duplicates. And just duplications, but DUPLICATES - as many as a half dozen extra Emails per each unique notification. The most bizarre case we saw was when a user had an alert against a document library that saw five changes in one day, and he received five Emails: one with all five changes listed, one with only the first four, and so on, down to one Email advertising just one change.

What was causing the duplication? The prime suspect was of course the customization of the template, which, admittedly, had a bug, and was broken for some time: there were no alerts for weeks. But eventually I fixed it, and proved it by writing to the ULS logs each time the handler was invoked. And indeed, it was called exactly once for each Email the aforementioned user received. So why was one alert sending out so many notifications?

The most bizarre aspect of this problem was how it was solved, because it solved itself. It was as though the SharePoint alerting infrastructure had a cold: it got worse and worse, barfed, and then started to get better and better. Seriously. My user reported that he got fewer and fewer duplicates each day, until it completely worked itself out and only sent out one notification per alert; each Email containing a list of changes that that document library had experienced over those last 24 hours.

Of course this is unsettling; problems that solve themselves usually have the propensity to start themselves back up. I had a hunch, and I don't blog about hunches. However, I will blog about hunches that Microsoft Premier Support endorses!

<HUNCH>

First, a bit of background: there is another database table that people seem to get their hands dirty with when it comes to fixing alerts: EventCache. What from I can tell, this is the backlog of all changes made to all document libraries. We can then think of alerts as sort of queries into this table. Once an alert gobbles up a change, that change is marked as processed and won't be alerted against again.

Therefore, a daily alert notification is actually the intersection of all unique changes that an alert (which is welded to a document library) "finds." What happens if those changes in EventCache are never processed? They are dangling there, like icicles, waiting to melt back down to the ground. If alerts are broken, these changes seem to just stack up.

Eventually, when alerts are fixed, that stack will topple. It will be like unclogging a drain. However, that's not what happened. The Email duplications diminished slowly, as if each alert could only pull changes from one day at a time. In other words, the alert, when activated by the Immediate Alerts job, doesn't seem to blindly ask EventCache for "all unprocessed changes for this document library" (as I would assume) but rather for "some 24 hour block of changes." Maybe it's that timeframe that gets out of whack, and changes from two different days are processed in the same batch. Or perhaps the logic is flawed, and times aren't updated properly if the notification system is malfunctioning due to a bug somewhere in the template customization.

It still makes more sense to me that, once repaired, all notifications will be shot out in the next batch. Furthermore, I think it's counterintuitive that "old" changes should be notified at all. If a user hooks up an alert, they want new information - new content. The apropos availability of old news isn't new news.

</HUNCH>

Each day as the alerts were "worsening" and then "healing" themselves, my client user forward me all the Emails he got. So did another user, who only had one alert, and only got dups sometimes. The point is that there were no discernable patterns. I poured over the frequencies among alerts, number of Emails, and number of changes in each Email, but came up with nothing. I spent hours digging though verbose ULS logs, only to further validate that my custom handler was called exactly once per whatever it was that SharePoint was detecting as a notification.

When my Microsoft rep backed up the above hunch, I was encouraged, but not satisfied. Unfortunately, this remains a mystery to this day. Microsoft closed the case without any more discussion. My client closed the bug without any more discussion. It's like everyone but is happy that this one little bug - which was only supposed to take a day to implement - has magically disappeared.

Well it's time for me to join their ranks, as there is no more time, money, calories, or sanity to invest into the duplicate alert issue. Usually my posts have happy endings, but alerts are emo like that. If anyone out there has any ideas, please don't hold back. Hopefully I was able to at least help a little bit in terms of cracking open the black box of enigmatic SharePoint 2007 daily alerts.

InfoPath Browser Enabled Forms and Crossing Web Applications

Jeremy Williams — Fri, 13 Aug 2010 17:09:15 GMT

Scenario:

A browser-enabled InfoPath form was to be built that allowed users to fill out a form, email it to themselves, attach a document to be uploaded to SharePoint, and then sent to an individual that understands SharePoint. Sure, the easy answer here is to make the user upload the file directly and just classify it there. The problem is that many users are unwilling to be trained on SharePoint, so this was elected as a compromise to fully utilizing SharePoint. There’s some other border-cases that this form solves, but this is neither here nor there.

Challenge:

The form has a number of drop-downs in it, some are SharePoint ‘choice’ fields, and two are SharePoint ‘lookup’ fields. The choice fields all function just fine since I’m using a nice little XML file to specify those dropdowns (they rarely change and it’s much quicker to load than querying all of the lists). The lookup lists do need to be refreshed on each form load, since those are subject to additions. However, InfoPath Browser forms have a nasty habit of ordering SharePoint-list-data source values by ID rather than Title. [To add further insult to injury, the full-blown InfoPath client orders by Title..] Users wouldn’t go for that on lists that contain upwards of 500 choices, so I had to find a way to order by Title…

After reading some great articles on using owssvr.dll to get a XML output for a particular list, I figured I had the problem licked. This method would allow me to return live data (on form-load), required no code-behind, and seemed straight-forward. So I followed the instructions (http://blogs.msdn.com/b/infopath/archive/2007/01/15/populating-form-data-from-sharepoint-list-views.aspx), and then pressed enter to get a plain-white IE window (no XML as promised). After verifying that this wasn’t some obscure browser setting, I looked at the lists I was referencing and they were (both) custom lists that also had lookup columns contained within. I then suspected that the lookup column (especially one that allowed multi-select) wasn’t supported by the owssvr.dll method. Luckily for me, we are running a nifty little master-list data synchronization on this environment. The custom code basically reads a list (considered the ‘master’) on Web Application A, Site Collection A, and then writes any add/update/delete actions to copy-lists stored other Site Collections under Web Application B. Anyways, the ‘synchronized’ lists don’t contain the lookup columns, just the ‘ID’ and ‘Title’ values. Effectively, this allowed me to test owssvr.dll reading a ‘simple’ list…

After running a quick test, I discovered that owssvr.dll worked famously with the sync-lists! So, I rebuilt my form data connections, redeployed the form, and then BAM! Yet another error about SharePoint not being able to access data sources [Error ID 6932](and all of my dropdowns of lookup lists were blank). After some poking around, I surmised that InfoPath form services (even with cross-domain enabled) doesn’t like crossing SharePoint web applications, even though the user account I was using had permissions to both web applications.

Fix…Workaround:

So, to get the form to play nice, I simply deployed my form and associated data sources in a site under Web Application B. By doing this, my owssvr.dll XML files could reference the appropriate sync-lists correctly and in the same web application. After I did this, the form worked as advertised and I simply changed all of the applicable links to point to the new form location.

I realize that this is a fairly unique scenario, but I think there are a couple of important takeaways. First of all, for users that are running into the blank-white IE screen when using owssvr.dll, hopefully this post helps you in your test cases by trying the method after removing lookup columns. And Second, for those who might be considering/trying to get InfoPath Browser Forms to cross web applications, realize that you may have to somehow provide a simplified version of your list-data.

At the end of the day, the form worked as advertised, and the correct columns were returned (and ordered).

Customizing People Search Results in MOSS 2007 – Part 3 of 3 – Search Results Customization

Jeremy Williams — Mon, 14 Jun 2010 17:51:28 GMT

This is the third and final post of a three part series, if you missed it, here’s Part 1 and Part 2. This post will go into the details of consuming the managed properties we configured last time around, and then displaying them in our search results.

As a review, here’s where we are:

User Profile Properties Changes
SharePoint Search Changes
Search Results Page Customization

Add Managed Properties to List of Columns to Query

The first step to displaying your newly added managed properties in the search results is make sure they’re being returned as part of your result-set! To do this, navigate to the people search result page on your Search site. A quick and easy way to do this is to run a search (using the ‘People’ scope) for your own name. Once you’re on the search page, go ahead and edit the page. Once you have the page in edit mode, click on the context menu for ‘People Search Core Results’ and select ‘Modify Shared Web Part’. On the pane that appears to the right, go ahead and expand the ‘Results Query Options’ Group, then click the text box under the ‘Selected Columns’ heading; and finally, click on the button with the ellipsis (…). This will pop up a text editor. To prevent yourself from going a little crazy, I highly recommend editing this text in something else, like Notepad/Wordpad/your favorite IDE/etc. You will want to add a line (below) for each of your newly added custom managed properties.

<Column Name="YourManagedPropertyNameHere”/>

In the screenshot below, you can see that I’m adding my ‘StreetAddress’ managed property:

Once you’ve added all of your properties, go ahead and paste your XML back into SharePoint pop-up text box and click ‘Ok’ on the web part property pane to save your changes. Now, your custom property is available to and for our final step…

Reference columns in custom XSLT

Now that the people search core results web part is properly returning your managed columns, you’ll want to customize it’s XSLT (style sheet) to include the newly added column(s). Same as last time, I highly recommend you edit this XSLT in your favorite IDE, as it’s really painful to work with code in SharePoint’s popup text-editor. Anyways, to access the XSLT, go ahead and click ‘Modify Shared Web Part’ on the People Search Core results web part, and click the ‘XSL Editor…’ button.

The XSLT sheet that ships with SharePoint is about 360 lines long, and there’s a couple of places you’ll need to add your column(s). For the example, I’m simply going to stick in the ‘StreetAddress’ field after a user’s title, department, phone, and office. Certainly, you can do much cooler things here with the XSLT, but I’ll save that for another day. The first place you’ll need to add your column is around line 137. In my example below, I have established my XSLT variable for StreetAddress as ‘street’ (mainly to illustrate the naming differences).

Important Note: in the ‘select’ value, be sure to use ONLY lowercase text; if you do capitalize names here, you run a very high risk of the proper field not being returned.

The next place to add the property is around line 337, as shown below:

And finally, I’ve added an XSL if-block with street around line 355:

Doing this will yield the following results:

Before:

After:

Final Thoughts

Clearly, the trickiest part of this process is the XSLT customization, which is why I’ve chosen to show you how to simply add a property to the XSLT. You can do all kinds of cool things with XSLT, such as return the users in a grid pattern with key information beneath their picture, or return people with a contact-card styling, the list is as long as your imagination.

Thanks for sticking through all three posts with me; I hope this helps clear up any confusion on the whole process.

Errata

Random Error

Sometimes, SharePoint will throw a false error at you after clicking ‘Ok’ to web part changes. The error looks something like this:

If you do come across this, simply check in your page and then click in the URL bar and press enter (don’t just refresh the page). If you still get the error after that, you’ve most likely made a coding error in your XSLT.

Field Not Displaying

If your field isn’t returning, and you’re fairly confident that you’ve written valid XSLT and added/configured/mapped all your properties correctly, you might need to refresh your user profiles. To do this, initiate a full import on your people profiles in SharePoint. Once the full import has completed, start an incremental search crawl to pick up these changes. Once complete, go ahead and run your people search again and your field should now appear:

Example of Missing Field (notice the hanging ‘-' after ‘Downtown’; this is where Street Address should be:

Example of the Missing Field existing as expected:

Customizing People Search Results in MOSS 2007 – Part 2 of 3 – Search Configuration

Jeremy Williams — Wed, 09 Jun 2010 17:36:00 GMT

This is the second post of a three part series, if you missed it, here’s Part 1. This post will go into the details of taking the User Profile Properties we created the last time around, and making sure that they’re available to us in Search.

As a review, here’s where we are:

Run an incremental crawl

If you haven’t already, be sure to run a full import on your user profiles (This should be done after you’ve added all your custom profile properties from step one) Assuming that a full import has run, the next step is to run a crawl on whatever content source is crawling people. 9 times out of 10, this would be the ‘Local Office SharePoint Server Sites’ content source. This can be done by going to your Search Administration page, clicking on ‘Content Sources’ then selecting ‘Start Incremental Crawl’ from the ‘Local Office SharePoint Server Sites’ context menu.

After the crawl has completed, it should have picked up all of your newly defined user profile properties as a crawled property. Next, we’ll want to use those newly crawled properties in the creation of our managed properties. The managed property will (ultimately) be used to return information about a user in the search results.

Add mapped profile properties as managed properties

To create a new Managed Property, navigate to your SSP management page. From there, click on Search Administration, and then click on ‘Metadata properties’. Once at the Metadata Property Mappings window, click on the ‘New Managed Property’ link, which will take you to a screen similar to the one shown below:

This is where you will be defining the name (to be used in search) of all your people profiles. Personally, I like to use the same name as that returned by the crawled property. This is due to the fact that I handled the naming of the property when I created it. It simply makes life easier to remember only one property name that to track the property through all phases (AD, Profile Property, Crawled Property, Managed Property, XSLT variable). In the screenshot above, I have created a managed property for Street Address. Assuming you’re following my advice above, you will use the same profile property name for naming the managed property. In my example, this yields a Property name of: “StreetAddress”. Filling in a description is strictly optional, I have elected not to do so in my example. Be sure to leave the ‘Text’ radio button checked, as this will act as a filter on crawled property search we’re about to run. [Obviously, if you’re adding a crawled property that is an integer value, be sure to change this radio to reflect as such] Next, you will need to click ‘Add Mapping’ to select the crawled property(-ies) referenced by this managed property. In my example, I know that I named by Profile Property ‘StreetAddress’, so I’ll search for ‘Street’ in the dialog:

This is an easy one, as only 1 result was returned. Generally speaking, if you get more than 1 result, be sure to select the result prefixed with ‘People’. Click Ok and you’ll return to the ‘New Managed Property’ Screen. The remaining options shouldn’t impact us, so you can leave them alone. Go ahead and click Ok. Voila, you’ve created a Managed Property for StreetAddress, bringing you one step closer to your customized People Search experience. Repeat as necessary for all of the properties you’ve added to User Profiles.

Run an incremental crawl

When you’re finished adding all of your new Managed Properties, you’ll need to run an incremental crawl. Disclaimer: Most (if not all) Microsoft documentation claims that you have to run a full crawl at this point. I’ve only had to do that once for people profiles and their associated metadata properties; typically, the incremental crawl works for me. The purpose of this crawl is to ‘pick up’ all of your newly update managed properties. Once you start this crawl, go ahead and get yourself a cup of coffee and marvel at your SharePoint prowess!

That wraps it up for the second step of the process. I hope to have the third and final post up soon, so stay tuned!

Customizing People Search Results in MOSS 2007 – Part 1 of 3 – User Profile Properties Change

Jeremy Williams — Tue, 25 May 2010 14:03:00 GMT

One of the niceties (at least for us implementer-folk) of SharePoint’s search is that both the content and display of the result page can be changed with a few tweaks to some the profile sync process, managed properties, search query result web part properties, and the result XSLT. Okay, so I’ll admit, it isn’t the most straightforward process, but it’s still pretty cool that this can all be accomplished without any custom code! If you have liberal definitions of “out of the box SharePoint functionality” like I do, then you’re in luck. Everything we’ll be going through here can be considered Out of Box!

Alright, so this post-series will be fairly detailed, therefore it will be broken up (for both author and reader sanity) into three parts:

User Profile Properties Changes
SharePoint Search Changes
Search Results Page Customization

For those of you that have done any searching on the subject, you will find a decent amount of custom people search XSLT result sets out there. However, what you’ll struggle to find is an end-to-end instruction set to fully implement a customized people search experience. I know it’s a lofty goal, but I hope this series of posts can help you get from zero to your custom people search experience. At the very least, it should get you pretty close!

So here’s the process that we’ll be going through:

If you are only going to use the 21 or so default mapped properties, feel free to skip ahead to the second post. Again, this first part is only required if you have non-standard user properties that you would like to display in People Results. My favorite example of a non-standard attribute is the ‘Mobile Phone’ value. In most AD implementations, a standard user account will not be able to ‘read’ this attribute into SharePoint’s user profiles. In order to properly access these properties, work with your AD administrator to secure a Profile Import Account with the correct level of access. Basically, the account will need the ability to read each of the fields that you’re working to import. I’m not going to dive into the details of setting up the correct permissions in this series, perhaps in the future I’ll tackle that subject. In the meantime, if (and only if) you’re in a test environment, the easy solution is to use a Domain Administrator account; please do not do this in your production environment.

To change this account, navigate to the Shared Services Provider (SSP) that you’ll be working on (you may have a direct link and/or it’s accessible from Central Administration). Once on the SSP homepage, click the ‘User Profiles and Properties’ link. From the next page, you will want to click on the ‘Configure Profile Import’ link. From the following page, select the ‘Specify Account’ radio button in the ‘Default Access Account’ heading and enter in the credentials for your elevated account.

The next step in the process is to add whatever additional fields you need to the ‘User Profiles and Properties’ area. To do this, navigate to SSP homepage, and click on the ‘User Profile Properties’ link. Near the bottom of this window, you will see a heading called ‘User Profile Properties’; click on the ‘Add profile property’ link. This will bring you to the form shown below. If you’re looking to display the ‘mobile’ attribute (or whatever value you’re adding here) to all employees, feel free to mirror the settings in the screenshot below. If not, tweak the settings to your liking.

The hardest part of this form is the dropdown near the end where you actually select what Active Directory field you will be mapping to. These field names are not necessarily intuitively named. For example, city is called ‘l’. To get an idea of what field you’re looking for, go ahead and and fire up ADSI Edit and connect to your favorite domain controller. From here, you’ll want to navigate to an OU that contains a User Account with the property that you’re looking for. Once you find the user account, go ahead and right click on it, and select properties. This will bring you an exhaustive list of that object’s AD attributes. Go ahead and find the property you’re looking for and then select that property in SharePoint’s Add User Profile Form. Be sure to note the AD-names of all properties that you add as you’ll need this list later.

After clicking OK and repeating this process for all of the non-standard fields you want to import you should be ready to move on to the next post, which I’ll finish up in the next couple of days.

Building a Better SPGridView

jrupp — Tue, 30 Mar 2010 17:15:00 GMT

Sometimes with SharePoint customizations, you run into a scenario where you want to do something that is “just like this OOTB thing, but a little bit different.” Sometimes, that turns out to be trivial. Sometimes it turns out to be a fair amount of work to get what you want. SPGridView is one the latter – sounds great, but takes more work than I’d like to be at feature-parity with the less generic components.

Recently, I had two different projects that wanted something that looked like a ListViewWebpart, but had a more complex data source than a simple view on a list (both involved fetching data from multiple sites within the site collection and joining it to a couple of other lists). Seems simple enough, right? Fetch the data needed from all the source lists (and/or cross-site queries via SPSiteDataQuery) into custom objects, join them together via LINQ-to-Objects, stick the results in a DataTable, display it with SPGridView, and off to the next task, right? Well, yes. It does look right, but sorting and filtering don’t work. Even when you add ObjectDataSource to the mix, there are issues with sorting and filtering getting in each other’s way.

After a bit more digging online, I found a few sources that pointed me in the right direction of what I’d need to do to make it all work:

With these, plus a bit of tinkering, I got it to work like my first client wanted. However, I had to do a lot more work than I wanted to make it happen – until the last piece was in place, it wouldn’t work quite right. Two weeks later, I had another client ask me for almost the same thing (obviously, the data involved was quite a bit different, but the basic idea was the same – custom data fed into a table that looks like a normal SharePoint one). Since I’m a heavy opponent of “reuse by copy and paste”, I thought I’d separate out the “fixes” to the SPGridView from the particulars of this implementation and build a control I could use in the future when this kind of scenario came up.

In my mind, the developer wanting to use this control should only have to provide the information relevant to the problem domain (data, columns) and leave the implementation details (wiring sorting/filtering to work and work together) up to the control. To that end, I present SmartSPGridView:


    1 using System;
    2 using System.Collections.Generic;
    3 using System.Text;
    4 using Microsoft.SharePoint.WebControls;
    5 using System.Web.UI.WebControls;
    6 using System.Data;
    7 using System.Web.UI;
    8 
    9 namespace SPGridDemo
   10 {
   11     /// <summary>
   12     /// Wraps up everything needed for automatic sorting and filtering.
   13     /// Heavily based on:
   14     ///   http://www.reversealchemy.net/2009/05/01/building-a-spgridview-control-part-1-introducing-the-spgridview/
   15     ///   http://www.reversealchemy.net/2009/05/24/building-a-spgridview-control-part-2-filtering/
   16     /// Triggering binding is left up to the parent control -- call GridView.DataBind() -- GetData event will be raised for you to supply the data.
   17     /// Also http://vspug.com/bobsbonanza/2007/07/02/filtering-with-spgridview/
   18     /// </summary>
   19     public class SmartSPGridView : WebControl, INamingContainer
   20     {


   21         public SmartSPGridView()
   22         {
   23             // initialize the ObjectDataSource and SPGridView, wire them together and hook in the needed event handlers
   24             DataSource = new ObjectDataSource()
   25             {
   26                 SelectMethod = "SelectData",
   27                 TypeName = this.GetType().AssemblyQualifiedName,
   28                 ID="DS",
   29             };
   30             GridView = new SPGridView()
   31             {
   32                 AllowSorting = true,
   33                 AllowFiltering = true,
   34                 AutoGenerateColumns = false,
   35                 FilteredDataSourcePropertyName = "FilterExpression",
   36                 FilteredDataSourcePropertyFormat = "{1} = '{0}'",
   37                 ID="view",
   38             };
   39             GridView.DataSourceID = DataSource.ID;
   40             DataSource.ObjectCreating += new ObjectDataSourceObjectEventHandler(DataSource_ObjectCreating);
   41             DataSource.Filtering += new ObjectDataSourceFilteringEventHandler(DataSource_Filtering);
   42             GridView.Sorting += new GridViewSortEventHandler(GridView_Sorting);
   43             GridView.RowDataBound += new GridViewRowEventHandler(GridView_RowDataBound);
   44         }
   45 
   46         public SPGridView GridView { get; private set; }
   47         public ObjectDataSource DataSource { get; private set; }
   48


   49         /// <summary>
   50         /// Add filter header pieces
   51         /// </summary>
   52         void GridView_RowDataBound(object sender, GridViewRowEventArgs e)
   53         {
   54             if (sender == null || e.Row.RowType != DataControlRowType.Header)
   55             {
   56                 return;
   57             }
   58 
   59             SPGridView grid = sender as SPGridView;
   60 
   61             if (String.IsNullOrEmpty(grid.FilterFieldName))
   62             {
   63                 return;
   64             }
   65 
   66             // Show icon on filtered column
   67             for (int i = 0; i < grid.Columns.Count; i++)
   68             {
   69                 DataControlField field = grid.Columns[i];
   70 
   71                 if (field.SortExpression == grid.FilterFieldName)
   72                 {
   73                     Image filterIcon = new Image();
   74                     filterIcon.ImageUrl = "/_layouts/images/filter.gif";
   75                     filterIcon.Style[HtmlTextWriterStyle.MarginLeft] = "2px";
   76 
   77                     // If we simply add the image to the header cell it will
   78                     // be placed in front of the title, which is not how it
   79                     // looks in standard SharePoint. We fix this by the code
   80                     // below.
   81                     Literal headerText = new Literal();
   82                     headerText.Text = field.HeaderText;
   83 
   84                     PlaceHolder panel = new PlaceHolder();
   85                     panel.Controls.Add(headerText);
   86                     panel.Controls.Add(filterIcon);
   87 
   88                     e.Row.Cells[i].Controls[0].Controls.Add(panel);
   89 
   90                     break;
   91                 }
   92             }
   93         }
   94


   95         void GridView_Sorting(object sender, GridViewSortEventArgs e)
   96         {
   97             // sorting loses the FilterExpression, so we have to restore it
   98             if (ViewState["FilterExpression"] != null)
   99             {
  100                 DataSource.FilterExpression = (string)ViewState["FilterExpression"];
  101             }
  102         }
  103 
  104         void DataSource_Filtering(object sender, ObjectDataSourceFilteringEventArgs e)
  105         {
  106             // save the filter expression built when we add a filter, so we can restore it when sort blows it away
  107             ViewState["FilterExpression"] = ((ObjectDataSourceView)sender).FilterExpression;
  108         }
  109 
  110         protected override void LoadViewState(object savedState)
  111         {
  112             base.LoadViewState(savedState);
  113 
  114             // clear the saved filter so we don't restore it if the user sorts
  115             if (Context.Request.Form["__EVENTARGUMENT"] != null &&
  116                  Context.Request.Form["__EVENTARGUMENT"].EndsWith("__ClearFilter__"))
  117             {
  118                 // Clear FilterExpression
  119                 ViewState.Remove("FilterExpression");
  120             }
  121         }
  122


  123         void DataSource_ObjectCreating(object sender, ObjectDataSourceEventArgs e)
  124         {
  125             // called by the ObjectDataSource to create an instance of this object
  126             e.ObjectInstance = this;
  127         }
  128 
  129         protected override void CreateChildControls()
  130         {
  131             // add the ObjectDataSource and SPGridView as children
  132             base.CreateChildControls();
  133             this.Controls.Add(DataSource);
  134             this.Controls.Add(GridView);
  135         }
  136 
  137         protected override void OnLoad(EventArgs e)
  138         {
  139             base.OnLoad(e);
  140             this.EnsureChildControls();
  141         }
  142 
  143         public DataTable SelectData()
  144         {
  145             var e = new GetDataEventArgs();
  146             OnGetData(e);
  147             return e.DataTable;
  148         }
  149


  150         #region GetData event+args
  151         public class GetDataEventArgs : EventArgs
  152         {
  153             public DataTable DataTable { get; set; }
  154         }
  155         public event EventHandler<GetDataEventArgs> GetData;
  156         protected virtual void OnGetData(GetDataEventArgs e)
  157         {
  158             EventHandler<GetDataEventArgs> eh = GetData;
  159             if (null != eh)
  160             {
  161                 eh(this, e);
  162             }
  163         }
  164         #endregion
  165     }
  166 }

Basically, it’s a UserControl with an ObjectDataSource and SPGridView wired together and with the events needed to get full sorting/filtering working already in place. To use this, all you have to do in your webpart is:

Create an instance of SmartSPGridView
Hook the GetData event and supply the DataTable
Call DataBind() at the appropriate time (OnPreRender works well)
Configure and add the view to your webpart (usually in CreateChildControls)
- Add the columns
- Populate the FilterDataFields property
- Add the view to the webpart’s Controls collection

ObjectDataSource makes sorting work, FilterDataFields makes filtering work, and several event handlers keep them from tripping over each other. And, I don’t have to keep fighting the same battle every time I need this kind of solution for a project. Now, I’m off to pick another fight with Sharepoint.

The downloadable version of the code is linked below.

Datasheet View Extras – Who Knew?

Jeremy Williams — Mon, 15 Mar 2010 15:40:18 GMT

I often tell my clients that I learn something new about SharePoint everyday, and (today) I have the perfect anecdote to prove it! For those that have already found the sweet toolbar on the datasheet view, the rest of this post may be a bit boring to you; however, if you haven’t found the datasheet view task-pane, read on!

Recently, I was working on some list items in datasheet view on SharePoint 2007, and I accidentally clicked on the little right arrow on the right side of the datasheet view:

Much to my surprise, this handy-dandy little task-pane came zooming out:

While the task-pane doesn’t offer any earth-shattering features, it’s still a handy little tool. The undo feature is nice to have around, as was the sort option (much easier/quicker than clicking all of the header in an attempt to get the perfect sort). Also, the ‘Clear Filters’ button was handy as well, and stopped my previous habit of refreshing the browser to get back to a clean-slate on the data sheet viewer.

SharePoint 2007 Search Administration: Scheduling and the UI

Jeremy Williams — Fri, 19 Feb 2010 17:40:00 GMT

As an SSP administrator, one can control and tweak the many aspects of SharePoint Search. One piece of the puzzle an admin can configure is a content source. For the uninitiated, a content source is simply a location where SharePoint Search is going to go out and look for files. Some examples of content sources could be all of your SharePoint sites, a file share, or even your public website. When configuring a content source, an administrator must choose how often that source will be crawled.

There are two types of crawls, a full crawl and an incremental crawl. While there is an (almost) infinite number of schedules one could set up for their content source, I often see a full crawl happening relatively infrequently (once a week or month, depending on content size), and incremental crawls happening quite frequently (every 5-60 minutes). Why? Let’s say a user uploads a file to SharePoint and tells their buddy, “Hey, I just uploaded the document about Client ABC to SharePoint, go check it out!” Their buddy (since he doesn’t know where the file is located) goes right to his trusty SharePoint search box and searches for “Client ABC”. If an incremental crawl hasn’t run since the file was uploaded, then it won’t appear in the results. This in turn makes for frustrated users, and an all around ‘bad’ SharePoint experience [but alas, I digress..]

Back to the point, when scheduling an incremental crawl, here’s a fairly typical starting point (picture below):

Everything seems to make sense in there, except for the last two text boxes. One way to interpret that section is, “Repeat the incremental crawl every 15 minutes and allow it to run for 1440 minutes”. Based on this interpretation, one may be lead to believe that an incremental crawl could start and run as long as 1440 minutes (that’s 1 full day). Well, as an SSP admin, I would hate for there to (potentially) be 1 crawl each day, so I’m going to change that 1440 to 20. Great, I’ve got crawl set up and my users should always be able to find their files (relatively) quickly, right?

Sadly, the answer is No. That text is actually interpreted as, “Repeat the incremental crawl every 15 minutes, and continue crawling every 15 minutes for 1440 minutes.” So, in my example above, the text becomes, “Repeat the incremental crawl every 15 minutes continue crawling every 15 minutes for 20 minutes.” This will yield you exactly 2 incremental crawls everyday, one around midnight, and the other around 12:15…After that, you’ll have to wait until midnight rolls around again.

For some users, this might have been a “duh” type of post because they interpreted the text and control in the manner Microsoft intended. However, other users may have incorrectly interpreted the text/controls as my example pointed out…

MySites and Quotas: The Nuances

Jeremy Williams — Tue, 16 Feb 2010 17:15:00 GMT

Site Quotas in SharePoint 2007 are a great tool, but they can sometimes be misunderstood. One of the most common confusions with quotas comes with their interaction with MySites. MySites (IMHO) are a great feature of SharePoint 2007, and are only getting better in SharePoint 2010. However, the adoption of MySites in many organizations is organic and unplanned. Right around the time that MySites near critical mass, the desire to wrap some additional governance around the sites crops up. Arguably, one of the most obvious governance tools for MySites is a Site Quota. So the governance committee decides on some thresholds and passes the implementation down to their Farm Administrators…

Let’s put on our ‘Farm Administrator’ hat…

I need to enforce a Personal Site quota on my users, so I’ll just set up the thresholds on the Personal Site quota template, and apply that to MySites. After that, everyone now has that quota, right? Wrong!

Okay, so that didn’t work and now I’m getting yelled at because users are uploading their personal photo and music collections to their MySites, thereby eating up all the space on our SAN. Since editing the quota template didn’t do the trick, let’s go ahead and create a new template and apply that to MySites. Alright, now everyone has that quota right? Wrong Again! [Aside: Remember, you can always block certain file extensions from ever being uploaded to SharePoint in Central Administration.]

Darn it SharePoint, you’re really raining on my parade, what am I doing wrong?!?!

Like many really annoying problems, this boils down to semantics…Quotas are called ‘Quota Templates’ for a reason, they are a template, and act just like a site template would. After applying a template, if I make a change to the template, all new sites using the template will take the new values; but the old sites will remain static. Here’s a laundry list of nuances, and a quick demo/proof of this behavior:

To reliably change the quotas of MySites, don’t create a new template, you’ll just want to edit the Personal Site Template. I’m not saying that you can’t create your own templates, but why work harder if you can work smarter?
Quotas act like site templates; they’re a snapshot…So if I make site A when personal site quota = 10/8; then I change the quota to 50/40 and create site B, site B quota = 50/40, site A quota = 10/8
Don’t always rely on Central Admin to tell you the truth about site quotas and what a particular collection’s quota is; instead use the stsadm –o enumsites command. Screen-cap below:

- Administrator was a manually set quota
- Test1 was using the initial Personal Site Template Quota
- Then I changed the Personal Site Template Quota, did an iisreset for good measure, and made test2’s MySite.
- So Test 1 and Test 2 used the same template, however they have different values since the template was different during each site’s respective build-time.

At the end of the day, the best approach is to properly plan for MySites and enact a reasonable quota template right from the beginning. If that isn’t an option, you can customize (or search for other’s customizations/extension) stsadm.exe to iterate through MySites and manually apply your new template.

Living in the Social Media Age: Are You?

jwillinger — Mon, 11 Jan 2010 22:20:00 GMT

Living in the Social Media Age: Are You?

More than 56% of marketers plan to incorporate social media into their businesses next year, according to a recent survey by the Center for Media Research.

With so many social media channel options to choose from, which one do you use for your marketing communications strategy?

In July 2009, Russell Herder and Ethos Business Law study of national business leaders highlighted that the most popular social media channels were the following:

Facebook (80%)
Twitter (66%)
YouTube (55%)
LinkedIn (49%)
Blogs (43%)

In my first blog post, my audience confirmed that Facebook and Twitter were the most popular social media platforms. So, as a marketer, should I use the most popular social media channel or a combination of both? Well, the short answer is that it depends. Since each tool works in a different way and with the social media landscape changing everyday, the key is to find out what your targeted audience likes to use.

The bottom line is that you need to be a part of A conversation because these conversations are happening, whether you are in the social media game or not. My next post will be focused more around SharePoint as that platform for an enterprise to build that social computing platform upon.

401 Reasons Why SharePoint Web Services Don't Work Anonymously

Chris Domino — Thu, 07 Jan 2010 06:43:00 GMT

<RANT>

I am always weary of using third party controls in my solutions. I feel that the risk of slightly reinventing the wheel is much less severe than that of getting to the end of project and realizing that some minor requirement that the control in use doesn't support will become a show stopper. When you don't have 100% control over your functionality (or the time/budget to customize open source code) then you had better make damn sure your third party components either FIT PERFECTLY or that your client won't mind cutting features.

That's why when I party with SharePoint, it's always "first party." Who wants to go to a third party when the first party is way cooler?

</RANT>

That said, I ran into such an issue in my last project. We were using a third party tool that, at the 11th hour (or, more accurately, around 9:45) immediately failed when we were informed that its SharePoint site had to be anonymous. Now our client probably pushed this requirement to the back burner because the functionality of this component had nothing to do with authorization. (I am purposely not going to share which component it is, because, well, I'm not a douche.)

The problem is that OOTB SharePoint web services, at least the ones this web part was calling, do not support anonymous access. The two in question here are SiteData.asmx and List.asmx. However, the depth of this unsupportedness far exceeded my expectations - as you'll see.

The client first noticed the problem when "random pages" would challenge for credentials exactly twice, which is of course two more times than an anonymous site should challenge anyone. These random pages were of course the ones containing the web part in question. So I fired up Fiddler and immediately saw the two 401s resulting from calls to the aforementioned web services.

"Easy fix," I thought as I remoted into the server and fired up IIS. Once there, I navigated to the web site corresponding to the web app in question, expanded it, and set the _vti_bin virtual directory to anonymous, using the app pool identity for impersonation.

And shazzam, no more challenges!

Now the next day, heading to the status meeting, I prepared myself for praise and glory resulting from my victory over yet another third party control's nonsensical way of doing things. I mean, come on! This is a web part; this is server side code. ALWAYS. Why call the web services? Why not just use the API? If this was our code, I could just fix it, or at least have an arch-to-arch heart-to-heart and inquire as to why this was the chosen method, as there could have been some weird requirement or dependency of doing things that way.

But I'm a consultant. Every project is an edge case in some way. That's why third party controls fail me so often.

So I sat down at the meeting, and was immediately informed that, despite the lack of challenges, there was still "something wrong" with the web part. It was scarcely noticeable, but still not right. So I went back to Fiddler, and indeed saw that 401s were still being returned. Looking into the raw HTTP, I noticed that only one line of text was being returned: "401 UNAUTHORIZED."

I then flipped _vti_bin back to Windows auth, and saw the challenges again. Back in Fiddler - and here's the interesting part - I saw the familiar markup of IE's default 401 error page! This makes sense; IIS wants windows credentials, IE didn't give it any, so it returns a 401, and the web service call fails and dies quietly.

But when anonymous is set, we get that one line message: "401 UNAUTHORIZED." Obviously, this is not coming from IIS. My only guess, after going through the trouble of Reflecting what I could of Microsoft.SharePoint.dll, is that code inside the web method sends this response if the current user is not authenticated, regardless if it's virtual directory is set to be anonymous. Here's what I dug up in Reflector:

Note: I couldn't get the actual web service code loaded into Reflector, so I can't be sure about this assumption. I tried OWSSVR.dll, which lives in the ISAPI folder in the SharePoint hive, but Reflector couldn't load it since it does not contain a CLI header.

So that's a dead end: it appears as though the OOTB SharePoint web services explicitly send 401 responses even if their virtual directory is set to be anonymous. This is certainly, IMHO, another knock against using them for anything server side. Maybe that's why it was so hard to get them to work in InfoPath 2003...

However, SharePoint 2010 is upon us! Next step: see if this is still an issue in the new product.

Stay tuned!

5 of the 10 Best Intranets in the World Run SharePoint

jwillinger — Wed, 06 Jan 2010 22:07:00 GMT

Jakob Nielsen, the world's leading expert on Web usability has listed his best in class intranets. It is no surprise that half of the sites were developed in SharePoint, which i live and breathe daily.

SharePoint 2010 is the business collaboration platform that enables you to connect and empower people through formal and informal business communities, within the enterprise and beyond, and to manage content throughout the information lifecycle. Whether deployed on-premises or as hosted services, SharePoint’s integrated capabilities are enhanced by search technologies and enable you to rapidly respond to changing business needs by making data-driven decisions and by deploying customized solutions quickly and securely. The consolidation of collaboration solutions onto SharePoint 2010 makes it possible to cut costs by lowering training and maintenance expenses and increasing IT productivity, all within a governable and compliant platform.

10 Best Intranets of 2009

Summary:
Intranets are getting more strategic, with increased collaboration support. Team size is growing by 12% per year, and platforms are becoming integrated, with a strong showing for SharePoint. Improving usability increased use by 106% on average.

The winners of the award for 10 best-designed intranets for 2009 are:

Altran, a large engineering and innovation consultancy (France)
Advanced Micro Devices (AMD), a developer of computer and graphics processors (USA)
BASF SE, the world's leading chemical manufacturing company (Germany)
COWI Group A/S, a consulting group focusing on engineering, environmental science, and economics (Denmark)
Deloitte Touche Tohmatsu (DTT), a global professional services network providing audit, tax, consulting, and financial advisory services (a Global member organization)
Environmental Resources Management (ERM), one of the world's leading providers of environmental consulting services (Global)
HSBC Bank Brazil (Brazil)
Kaupthing Bank (Iceland)
L.L.Bean, a vendor of apparel and outdoor equipment (USA)
McKesson Corporation, a large provider of pharmaceuticals, medical supplies, and health care information technologies (USA)

Deloitte Touche Tohmatsu also won in 2002 for its Australian member firm's intranet; this year, DTT's worldwide intranet is the winner. As such, DTT joins a very small, elite group of companies that has won the award twice: Cisco Systems is the only other member.

As we've seen every year, great intranets are found around the world and in all industries. This year, we have our first winner from Latin America. We also have the first winners from Denmark, France, and Iceland; Germany and the U.S. have both provided many winners in the past. We have one other first this year: In a sign of ongoing globalization trends, we have winners that are not headquartered in any individual country.

The consulting sector is this year's best-represented industry, with 3 winners. Given the knowledge-intensive nature of consulting and this year's trend toward more collaboration-focused intranets, this fact makes sense.

Bigger Intranet Budgets

As we've seen the last few years, large companies dominate among the winners. Among this year's winners, the average organization has 37,500 employees. Even so, fairly small companies like Kaupthing Bank with 3,200 employees can still win. Good user experience doesn't require size or humongous budgets; it requires talent and emphasis on meeting the users' needs.

One of the strongest trends over the years that we've run this design competition is that intranet teams have been getting bigger. As the following chart shows, when we started honoring intranet projects in 2001, the average winning team had 6 members; today, the average team size is 14.

The long-term trend is toward bigger intranet teams, with a growth rate of 12% per year.

Still, what holds for company size also holds for the size of teams: You don't have to be big to win. This year's winners include one team with 5 members and another team with 6 members. In earlier years, we've honored winners with 1- or 2-person teams.

Even this year's average team size of 14 is fairly small when it comes to providing a key work tool for organizations with 37,500 employees on average. One way to leverage intranet staff is to call on external resources as appropriate. Today, the predominant approach to running intranet design projects is to engage one or more consultants and external agencies to contribute parts — and only parts — of the design, while keeping overall control inside the company itself.

This year, 6 of the 10 winners were designed by some combination of in-house and outside resources. The remaining 4 projects were done completely by the company's own staff. None of the winning intranets were designed exclusively by an external agency, even though this was a fairly common approach in earlier years.

It's a healthy trend for companies to take more ownership of their intranets and devote resources to building sufficiently large intranet teams. In so doing, they gain in-house expertise in the main areas of intranet user experience. Not all companies can afford intranet teams that are big enough to do everything on their own, however. And, in any case, there are at least three reasons to periodically engage outsiders:

To get a fresh, independent perspective. People who work on the same project for years can become too accustomed to a certain way of doing things. (Disclaimer: Because Nielsen Norman Group sometimes serves this role through impartial usability reviews or unbiased user testing, we might certainly be too sympathetic to the value of an outside perspective.)
To provide deep expertise or a narrow skill set that the intranet team cannot justify adding to their permanent, full-time headcount.
To alleviate workload during crunch times, particularly during large redesign projects or rollouts.

Strategic Intranets

Bigger intranet teams and increasing internal ownership of the intranet user experience both reflect the intranet's growing strategic role in supporting work processes.

Intranets today do much more than simply host the company phone book and HR manuals — though these components remain critically important, and teams are continuing to improve them. COWI, for example, supplemented employee profiles with a feature that highlights commonalities between directory users and the profiled employees they view (an interesting combination of personalization, social networking, and the traditional staff directory.)

Nonetheless, with bigger teams and budgets and increased respect and strategic recognition, intranet functionality is expanding beyond such basic features. A simple statistic to quantify this trend is the fact that, at 473 pages, this year's Intranet Design Annual is the most voluminous ever (326% longer than the first Design Annual in 2001, and 31% longer than last year's report). As intranet teams accomplish more, more space is required to document the winning designs.

Another indication of the intranet's growing strategic importance is the fact that ERM is the first winning team that reports directly to the company chairman. As in past years, most other winners report to either Corporate Communications or IT, and having teams report to the top isn't likely to become commonplace. But this year does show dramatically increased executive visibility for the intranet in many of the winning organizations. This executive involvement typically results from companies viewing the intranet as a collaboration tool and appreciating the increased business efficiency that a good intranet brings.

Collaboration Features

This year's winners showed a substantial increase in both collaboration support and social networking features. Although inspired by the open Internet's "Web 2.0" sites, these features often have a much stronger business model within the enterprise, simply because they're more useful and less subject to noise and information pollution by bozos.

The most symbolic instantiation of this trend might be at Deloitte Touche Tohmatsu, where employees can add their own videos to the corporate TV network. Quite the enterprise YouTube.

Teams are also adding Facebook-like features to employee directories to enrich the profiles. That said, the designs are for a work environment — not for commenting on personal photos or supporting teenage dating behaviors. So, while it's appropriate to be inspired by popular social networking websites, your actual user interface and features must be freshly designed specifically for the intranet. Internal blogs — whether by employees, department heads, or company leaders — were also thicker on the ground than in previous years.

The vast majority of our winning intranets feature CEO blogs. This is not new; we've seen some CEO blogs in earlier years. Indeed, HSBC Bank Brazil's CEO blog started in 2005 and has since been viewed more than 2 million times and accumulated 8,000 employee comments. These statistics imply about 1 comment for every 250 employee viewings of the CEO blog, a level that's consistent with other research on user participation in online communities. You can use this level as a rough benchmark to assess whether your own CEO blog is sufficiently inviting of employee participation.

Clearly, it's a well-established feature. What's new this year is the sheer prevalence of this communications tool; we now have enough good examples to specify 9 guidelines for an intranet CEO blog.

Another example of a striking social feature is ERM's interactive forum. This tool has achieved mission-critical status in allowing consultants to post urgent requests for advice from their colleagues around the world. The forum has virtually eliminated panicky broadcast emails at ERM, thus improving the productivity of the many knowledge workers who are no longer interrupted by requests that they might have no qualifications or experience to solve. Even more important, this community feature often helps the company quickly construct better proposals for key clients on short deadlines.

Personalization and Customization

As many of this year's winners show, intranet personalization is becoming increasingly sophisticated. The leading application of personalization is to provide each employee with news updates focused on their job role and personal interests. If intranets show everyone everything, information overload ensues and people either ignore the news area or squander their time reading irrelevant stories.

Simple customization can often generate sizeable productivity wins. For example, at McKesson, sales people can create a My Product List and My Favorite Reports, freeing them from having to wade through the much longer lists of all available options. Much appreciated when you're on the phone with a customer and would prefer to focus your mental resources on closing the sale, rather than navigating the intranet.

At AMD, users can customize links directly in the main menu bar, which integrates the user's personal favorites much more tightly with the intranet navigation than the traditionally separate Quick Links feature.

Multilingual intranets also make good use of personalization to increase usability by presenting pages in the user's preferred language as much as possible. BASF's main user interface elements are available in 13 different languages, and several other winners also have internationalization and localization support that goes far beyond what we see in most Internet websites.

Technology Platform: Unification Begins

In all previous years, the only conclusion regarding technology was that there was no universal platform for designing good intranets. Winners typically used an extraordinarily wide diversity of implementation packages.

Although this conclusion continues to hold this year, it is less pronounced.

Among the winning intranets, many are built on a single intranet platform that integrates most of the supporting features they need — including a content management system (CMS) and search. Some winners supplement their main platform with a few selected tools for specialized purposes — mainly Web analytics. If we were to hazard a prediction, it would be that traffic statistics, search log analysis, and other analytics tools will be substantially beefed up and integrated in future releases of the main intranet software platforms.

In total, the 10 winners were built on 26 different products — substantially fewer than the 41 used in 2008 or the 49 used in 2007. Most impressively, fully half of the winning intranets used SharePoint, especially the recent MOSS platform (Microsoft Office SharePoint Server 2007). As the following chart shows, SharePoint use has grown dramatically in recent years. This is particularly impressive given that, from 2003–2006, the winning intranets didn't use earlier versions of SharePoint at all.

Microsoft SharePoint has seen substantially increased use among well-designed intranets in recent years.
(In 2007, Microsoft's own intranet was a winner, and they obviously used their own software, so the 2007 dot should be a notch lower if you consider only third-party projects.)

Despite this big growth in SharePoint use among the best intranets, the contest is far from over for intranet software platforms. Many other good enterprise software vendors offer widely used solutions. This year, for example, multiple winners used Autonomy, Google Search, and WebTrends.

Usability Growth

Over our intranet award's 9-year history, we've seen a steady increase in user-centered design. The following chart shows the proportion of winning intranets that employed various methods across three different 3-year periods. The use of all methods has substantially increased; it's particularly gratifying to see the extent to which designers are embracing paper prototyping and other low-cost testing methods.

The percent of winning intranets that employed some of the main usability methods in their design process.

To assess the ROI of intranet redesigns, teams primarily relied on usage metrics in terms of users, visits, or page views. Across this year's winners, the average increase in intranet use was 106%. This is about the same as we've seen in previous years: The average usage increase in the 2005–2008 winners was 110%. So, roughly speaking, improving an intranet's usability will double its use.

L.L.Bean conducted a benchmark study comparing their old and new designs. The old intranet had a success rate of 67% and an average time-on-task of 1 minute and 52 seconds. The new intranet has a success rate of 88% and users require only 54 seconds on average to perform the same tasks. In other words, users can perform more than twice as many tasks per hour with the new design. This improvement is somewhat more than the average across our intranet usability metrics benchmarks, but then L.L.Bean does have an award-winning intranet.

I am Director of Business Development and Marketing at Rightpoint, the country's premier SharePoint knowledge repository with end to end solutions around everything SharePoint. You can reach me at jwillinger@rightpoint.com

Extending SharePoint Approval Workflows Using Custom Initialization And Association Data

Chris Domino — Wed, 30 Dec 2009 17:15:00 GMT

It is always with a bit of hesitation that I recommend using Out-Of-The-Box SharePoint Workflows to my clients. It's not because they are exactly terrible or anything; it's just another application of the 80-20 rule. And since I take such good care of my clients, they seem to become fairly well acclimated to never hearing phrases like "No" or "That's out of scope" or "That's not in the budget" or "No thanks, I've already eaten."

So when the need arises for a quickie approval process on a document library or list, the OOTB Approval Workflow should bubble into your mind immediately. But as soon as a client squeaks about some minor customization here, or drops a "would it be possible" there, the bubble will quickly pop, sending you off to Visual Studio 2008 and the WF Workflow Designer, ultimately reinventing about ninety percent of the wheel.

Despite the fact that there are a lot of configuration options for the OOTB SharePoint workflows, modeling a business process is so specific to an organization's way of doing things that a generic "Approval" workflow can rarely be expected to get the job done. Except for the most remedial cases, the Approval workflow is not a panacea for content approval.

However, that doesn't mean that it's time to immediately build a workflow from scratch! By using the SharePoint workflow API and some nifty manipulations of the Association and Initialization data, we can leverage the OOTB Approval workflow and customize, or, more accurately, force it to do what we need.

One customization that always seems to come up is assigning a dynamic approver to an instance of an Approval workflow. On the association screen, you can specify a list of static approvers, but that's really it. If your workflow is set to kick off automatically (via an ItemAdded or ItemUpdated event), there's no opportunity to specify initialization data for that instance.

So what I'm going to show is how to programmatically create and start an instance of an Approval workflow with custom initialization data that is built from metadata on the list that the workflow is associated with. Let's start by an overview of the architecture of this scenario:

A custom list is associated with the Approval workflow. One of the columns is of type "Person" which accepts an SPUser object. This user will be the approver of the instance of this workflow.
A custom web part captures data from a user, and creates an item in a list.
A Feature provisions the above list, and welds on the Approval workflow with custom Association data.
Event receivers are installed for the custom list as well as the task list the workflow uses. These will kick off the workflow, and execute code when it is approved.

Taking the last item first, here's some sample code for a feature receiver's FeatureActivated event, scoped at the site level:



	public override void FeatureActivated(SPFeatureReceiverProperties properties) { try { //open site using (SPSite site = properties.Feature.Parent as SPSite) { //open web site.AllowUnsafeUpdates = true; using (SPWeb web = site.RootWeb) { //create list for workflow web.AllowUnsafeUpdates = true; SPList list = web.Lists[web.Lists.Add("Request List", "This list holds the requests to be approved.", SPListTemplateType.GenericList)]; //add fields to list List<SPField> fields = new List<SPField>(); fields.Add(list.Fields.GetFieldByInternalName(list.Fields.Add("Client Name", SPFieldType.Text, true))); //hide title SPField title = list.Fields["Title"]; title.Required = false; title.Hidden = true; title.Update(); //add approver field SPField field = list.Fields.GetFieldByInternalName(list.Fields.Add("Approver", SPFieldType.User, false)); field.Hidden = true; field.Update(); //create lists for workflow tasks and history SPList tasks = web.Lists[web.Lists.Add("Workflow Tasks", "This list holds the tasks used for the Request workflow approvals.", SPListTemplateType.Tasks)]; web.Lists.Add("Workflow History", "This list holds the historical data for Request workflows.", SPListTemplateType.WorkflowHistory); //get workflow association SPWorkflowTemplate wk = web.WorkflowTemplates.GetTemplateByName("Approval", new CultureInfo(1033)); SPWorkflowAssociation association = SPWorkflowAssociation.CreateListAssociation(wk, "Request Approval Workflow", web.Lists["Workflow Tasks"], web.Lists["Workflow History"]); //configure workflow association.AllowManual = false; association.AutoStartCreate = false; association.AutoStartChange = false; association.AllowAsyncManualStart = false; association.AssociationData = association.AssociationData.Replace("<my:AllowDelegation>true</my:AllowDelegation>", "<my:AllowDelegation>false</my:AllowDelegation>"); association.AssociationData = association.AssociationData.Replace("<my:AllowChangeRequests>true</my:AllowChangeRequests>", "<my:AllowChangeRequests>false</my:AllowChangeRequests>"); list.AddWorkflowAssociation(association); //wire up event handlers list.EventReceivers.Add(SPEventReceiverType.ItemAdded, "Request, Version=1.0.0.0, Culture=neutral, PublicKeyToken=97c72abbf6e1c840", "Request.EventHandlers"); tasks.EventReceivers.Add(SPEventReceiverType.ItemUpdated, "Request, Version=1.0.0.0, Culture=neutral, PublicKeyToken=97c72abbf6e1c840", "Request.EventHandlers"); tasks.Update(); //update main view SPView view = list.Views["All Items"]; view.ViewFields.DeleteAll(); foreach (SPField f in fields) view.ViewFields.Add(f); //save view.Update(); list.Update(); web.Update(); } } } catch (Exception ex) { //log and throw EventLog.WriteEntry("Request Workflow Feature Receiver - Activated", ex.ToString(), EventLogEntryType.Error); throw; } }

I know that's a long method and there's a lot going on, so let's look at some of the important lines in the above listing. The rest are examples of how I like to customize my sites via code executed in feature receivers, instead of mammoth XML site definition files.

Line #28 creates the task list for the workflow, and stores a reference to it.
Lines #31 and #32 are the meat and potatoes for programmatically creating a workflow.
Lines #34 - #39 configure the workflow. Notice that some of the properties of the association can be set "normally" while others are set via (shitty) string manipulation of the association metadata. This is the first taste of how we will be setting a dynamic approver. The association metadata should be manipulated when you want to customize default settings per instance of a workflow; the Boolean properties are for the workflow's behavior as a whole.
Lines #42 and #43 implement the wiring of the event receivers for the actual request list, as well as the workflow task list. Notice in Line #35 we are not auto-starting any workflow instances, because this does not give us the opportunity to customize our initialization data. Instead, we use an event receiver on the list to read in the list data and programmatically kick off a workflow. In Line #43 , I hook the same ItemAdded event on the workflow task list, so, pending the outcome, I can react to approvals or rejections.

Next, let's look at the code that kicks off the workflow:



	public override void ItemAdded(SPItemEventProperties properties) { //impersonation SPSecurity.RunWithElevatedPrivileges(() => { try { //initialization base.ItemAdded(properties); //open site using (SPSite site = new SPSite(properties.SiteId)) { //open web site.AllowUnsafeUpdates = true; using (SPWeb web = site.RootWeb) { //get list SPListItem item = properties.ListItem; SPList list = web.Lists[properties.ListId]; SPWorkflowAssociation wfAssociation = list.WorkflowAssociations[0]; //set approver SPUser user = properties.ListItem["Approver"] as SPUser; string data = wfAssociation.AssociationData.Replace("<my:Reviewers>", string.Format("<my:Reviewers><my:Person><my:DisplayName>{0}</my:DisplayName><my:AccountId>{1}</my:AccountId><my:AccountType>User</my:AccountType></my:Person>", user.Name, user.LoginName)); //set description data = data.Replace("<my:Description></my:Description>", string.Format("<my:Description>{0}</my:Description>", item.Title)); //start workflow site.WorkflowManager.StartWorkflow(item, wfAssociation, data); } } } catch (Exception ex) { //log error EventLog.WriteEntry("Request Workflow List Event Receiver - Item Added", ex.ToString(), EventLogEntryType.Error); } }); }

Everything boils down to Line #27 that invokes the StartWorkflow method on the WorkflowManager class, which hangs off of an SPSite object. This method takes in three parameters:

The SPListItem on which the workflow operates.
The SPWorkflowAssociation , which associates a workflow with a list.
A string representing the initialization data for this instance. In the Visual Studio Intellisense, the name of this parameter is "eventData" which is very misleading. Why isn't it named something more intuitive to imply that it represents the initialization data for this instance? Something like, say, "initializationData?"

It is this third parameter that inspired this post. Where the hell does the initialization data come from? If you Bing around, you'll see that the idea is to pass in XML (most desirably a serialized object) to define the metadata of the instance of the workflow. Now this probably isn't a big deal for a custom built workflow, but how do you anticipate what the initialization data will be for an OOTB workflow?

Turns out, it's the same XML as the association data! This can easily be inspected in debug mode by checking out the value of the "association" variable in the first listing above, after Line #33. Then, down to the second listing, all I do to set an approver is grab the SPUser object from the list item data in Line #22, and use its properties to fill in the XML of the initialization data string in Line #25.

Then simply pass your modified XML, along with the list item and the association object, to the StartWorkflow method, and you're off!

The last step here is to figure out how to get code to run when the workflow instance is approved. My approach was to use another event receiver, but this time on the workflow task list itself. Hooking the ItemUpdated event and checking the task item's "Outcome" column for a value that starts with "Approved" will get us there. Here's the code:



	public override void ItemUpdated(SPItemEventProperties properties) { //impersonation SPSecurity.RunWithElevatedPrivileges(() => { try { //initialization base.ItemUpdated(properties); //open site using (SPSite site = new SPSite(properties.SiteId)) { //open web site.AllowUnsafeUpdates = true; using (SPWeb web = site.RootWeb) { //get the workflow item SPListItem item = properties.ListItem; SPList list = web.Lists[new Guid(item["WorkflowListId"].ToString())]; SPListItem wfItem = list.GetItemById(Convert.ToInt32(item["WorkflowItemId"].ToString())); //make sure the item was approved if (item["Outcome"].ToString().StartsWith("Approved")) { //do stuff here } } } } catch (Exception ex) { //log error EventLog.WriteEntry("Request Workflow Task List Event Receiver - Item Updated", ex.ToString(), EventLogEntryType.Error); } }); }

Lines #19 and #20 give us a reference to the list item that the workflow instance just approved (verses the task list item in the workflow task list).
Line #22 is, of course, a bit of a kludge, but safe for the Approval workflow. Don't use the "Status" column, as that is the status of the task itself, not the workflow. Hence the kludge.

That's it! As you can see, you can push OOTB workflows pretty far beyond the customizations available on the association page during configuration. But don't go too nuts extending these workflows; depending on your requirements, it might just take less time to build it from scratch!

Have fun!