Paul Galvin's (old) SharePoint space [SharePoint

Just another WordPress.com site

Category Archives: SharePoint Solutions Design

Content Query Web Part: SharePoint’s Swiss Army Knife

Advertisements

Pre-existing Conditions: SharePoint Alert Templates to the Rescue (?)

One of my clients worked with a previous contractor to build out a small but useful HR application for the enterprise.  That contractor used SharePoint Designer to implement the workflow portion of the solution.  It’s a bit of a mess.  For instance, there are nine SPD workflows in support of a single logical workflow process and up to five of them may fire simultaneously at any given time given the right conditions.  It’s not easy to debug 🙂

My customer has a number of still-outstanding requirements, one of which is to generally provide more context when the system sends out email alerts – both in the email itself as well as associated task forms.  As SPD workflow implementers know, the “collect data from user” SPD action actually creates a task with a custom content type.  When we use that action, we don’t get to specify much.  We can prompt for some values (e.g. “approve” or “deny”) and we can specify a hard coded value in the title and description.  That’s about it.

My customer’s requirement is two fold:

  1. When SharePoint sends an email about a task assignment, include a lot of information about the task in the email body.
  2. More importantly, by far – when the user clicks on the task link in the email, the task form should have all the information the approver needs in order to make his/her approve or deny decision.  Right now, the manager needs to click on the item link itself to drill down into the underlying details and no one likes that.  You have to click in the email.  Then you need to click a sort of obscure link on the task item.  Then you can look at the underlying data (an InfoPath form in this case).  Then you click back/back, etc.  Everyone hates it.

I’ve inherited this somewhat messy technical solution and I want to make changes in the least intrusive way possible.

The approach I’m taking right now is to create a custom alert template.  You can read about that here.  The flow works like this:

  • SPD workflow runs.
  • At some point, it assigns a task to a manager.
  • SharePoint system automatically sends out an alert to that manager.  This is not part of the SPD workflow but rather “what SharePoint does.”  (The SharePoint timer service, I believe).
  • A custom alert handler is invoked in favor of the standard alert process (following magic rules as described in the above referenced article).
  • When my custom alert handler runs, it generates a beautiful email.  More importantly, since it has the task in hand, it also decorates the actual task with all the context information necessary to meet the business requirement.
  • The user gets the email and it’s full of useful context information.
  • User clicks on the task link and the task itself is full of useful context information.
  • Everyone goes home to have watermelon and ice cream.

I did a quick POC and it works well in a lab environment.  I get my custom email alert as expected.  I also get to update the task description and title itself.

The only tricky bit, so far, is to avoid a situation where the alert updates the item, triggering another alert.  This doesn’t worry me.

Looks promising so far…

The great thing about this is that I don’t need to muck about with any of the existing SPD workflows.  They are blissfully unaware that an alert handler is “IIZ RUNNIN IN DA BAKGROUND, DECORATIN TEH TASK LIST WIF MOAR CONTEXT”.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

SharePoint Demonstration: Leverage SharePoint to Build a Vertical Business Application

[Note: I want to straight away say that I have a financial interest in the desired outcome of this demonstration, which I mention in the interest of full disclosure, etc.  This is actually the first time I’ve ever blogged about an event where I stand to benefit personally in this way.]

This web demonstration takes place Thursday, 06/04 at 12:30 EDT, ending at 1:30PM EDT.

In cooperation with my excellent business partner, Integrated Systems and Services Group (ISSG), I have been working to develop a vertical business application using SharePoint as the platform.  In this case, we’re building an application that serves the needs of manufacturers that make customized product for their customers.  In these cases, a great deal of collaboration needs to take place between the customer and the manufacturer.  There’s also a great deal of collaboration required between different groups within the manufacturer, including sales, engineering, research and development, legal and other groups.

The demo is going to show an application that facilitates that kind of collaboration, along with a discussion on how all of those collaboration bits need to integrate with a backend ERP system.

Lastly, this isn’t going to be a SharePoint demo.  This is a demonstration of a solution for a specific niche problem that happens to use SharePoint as the platform.

So, why would you bother to sign up and see this demo?  I don’t expect too many readers of my blog to be all that interested in a solution for make-to-order manufacturers 🙂  Your take-away would be the concept itself – using SharePoint purely to deliver a business solution without regard to SharePoint itself.

If you’re interested, please sign up here(https://www323.livemeeting.com/lrs/8000043750/Registration.aspx?pageName=skmqfwbr5smmlx20).

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

You Can Pry SharePoint Designer From My Cold, Dead Hands

My latest article is up at www.EndUserSharePoint.com.  I wrote about SharePoint Designer, End Users and the outline of a strategy that End Users might try and follow in order to demonstrate competence and build trust around this tool.

The comments are more interesting than the article itself.

Check it out.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Technorati Tags: ,

MOSS User Profile as the Authority for User Language Preference

On my current project, some of the users will travel around the world and when they arrive at different destinations, use whatever machine is handy at the time.   Those guest machines will be running Windows and installed and configured for the local locale.  (I’ve just realized that the guest machines may not have the right language packs… probably won’t, in fact… I’m parking that one for now).

SharePoint needs to provide a mechanism whereby the user can pick their preferred language and then have MOSS honor that language regardless of how the user accesses MOSS.  In other words, disregard whatever the browser tells IIS/MOSS and instead look up that preferred language and use it. 

We’re going to investigate two approaches:

  1. HTTP Handler: A custom HTTP handler installed on IIS will look up the user’s MOSS profile, figure out the preferred language and then switch the HTTP header around as needed before passing control to MOSS.
  2. global.asax: Modify global.asax to do the same thing.  We may modify something else, but the idea is that we find some place where we can insert our locale-switching logic. 

The other complicating factor is that we need to support 60k users, about 1,000 of which may be simultaneously accessing MOSS at peak load.

The HTTP handler seems pretty drastic, but possibly the best place to put the code since it’s at the IIS level and all-knowing.  It’s a good single point of work.

We’re leaning toward a global.asax type approach, mainly because we believe we’ll have more options for caching data at that point.

I’ll be blogging more on this subject as I learn more.

If you have know anything about this, please post a comment 🙂

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Capturing “mailto:” Metrics

I’m on a project where we need to collect metrics around a function named "Share a Story."  The idea is very simple — if you’re looking at an interesting article on the intranet and want to share it with someone, click a link labeled "Share this story" email it to your buddy.

We played around with a custom form for this purpose, but in the end, common sense won the day and we just use the familiar <a href=mailto:…> technique.  (<a href mailto:…> is a surprisingly robust little bit of HTML; as a bonus, that link brings me back to my old UNIX man pages days; those were the days!).

This technique provides a great interface for end users since they get to use their familiar MS Outlook client (or whatever email client they have installed).

It makes things harder on us poor developer types since they client *also* wants to run a report in the future that shows how often users share stories and even which stories are shared most often.

We whiteboarded a few potential solutions.  My favorite is to carbon copy (CC) a SharePoint list.  That way, the end user still gets the outlook client while we get to capture the event because we’ll get a copy of the email ourselves.  There are some obvious drawbacks.  The main problem is that the user could simply blank out or otherwise mangle the CC address.  And, we need to manage that event library of emails.  We have a scheduled job on the white board responsible for that cleanup.

If you have some clever approach to solving this problem, please do tell.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Defining “Great” SharePoint Requirements

As requested and promised, I’ve uploaded my presentation on how to obtain "great" requirements from end users for SharePoint projects and implementations.  It’s here: http://cid-1cc1edb3daa9b8aa.skydrive.live.com/self.aspx/SharePoint/Paul%20Galvin%20Great%20Requirements.zip

I presented this at the SharePoint Best Practices conference in Feb 2009 (www.sharepointbestpractices.com).  If you attended the conference, you’ll also get this on the conference DVD.

The presentation includes a lot of notes with most slides.  It’s not just bullet points.

(See here for my other presentation on a governance case study: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!3099.entry

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Self-Service Site Creation Isn’t Exactly About Creating Sites

Like many SharePoint consultant types, I’ve been exposed to a lot of SharePoint functionality.  Some times, I dive pretty deep.  Other times I just notice it as I’m flying by to another set of menu options.  One of those is "self-service site creation."  I haven’t had a need for it until this week.

This week, I need to solve a business problem which I think is going to become more common as companies loosen up and embrace more direct end user control over SharePoint.  In this case, I’ve designed a site template to support a specific end user community.  Folks in this community should be able to create their own sites at will using this template whenever the urge strikes them.

I recalled seeing "self-service site creation" before and I’ve always tucked that away in the back of my head thinking that "self service site creation" is SharePoint lingo meaning, obviously enough, something like "turn me on if you want end users to be able to create sites when they want to."

So, I turn it on, try it out and for me, it’s not creating sites.  It’s creating site collections.   Pretty big difference.  That’s not what I want, not at all.

It is possible to let end users create new sub sites via a custom permission level.  This is exactly where I would have gone in the first place except that the label "self-service site creation" label deceived me.  Via twitter, I learn that it’s deceived others as well 🙂

I’m still working out how to provide a little bit of a more streamlined process while staying purely out of the box, but there’s a definite path to follow.  Just don’t get distracted by that label.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Technorati Tags:

Spinning Up Temporary Virtual WFE’s for Fun and Profit

I was one of 20 or 30 (or maybe 100?) panelists last night at the New York SharePoint Users Group meeting.  Instead of the usual presentation format, this was all about Q&A between the audience and the panel members.  Early on, Michael Lotter introduced me to a new idea and I wanted to share.

An audience member described how his company had paid a consultant to write an application for his company.  The consultant wrote it as a console application using the SharePoint object model.  As a result, this meant that the program had to be run on a server in the farm.  This meant that anyone that wanted to use the app would have to log onto the server, do the work and log off.  At first, this wasn’t a problem, but soon, more and more (non-technical) users needed to use the utility.  His question was (paraphrasing):

"What are my options?  I don’t want to keep letting users log directly onto the server, but they need that functionality."

Michael Lotter suggested that he configure a new virtual machine, join it to the farm as a WFE and let users run the application from there. 

This is a pretty stunning idea for me.  Generalizing this solution brings to mind the notion of essentially temporary, almost disposable WFE’s.  I think it’s a pretty neat concept.  This temporary WFE can run a console application that uses the SharePoint object model.  You could also use it to run stsadm commands.  It doesn’t have to be part of regular local balancing.  If it goes down or gets wrecked, you can just spin up a new one.  I repeat myself, but I just have to say that I think it’s a really neat idea.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Technorati Tags:

Large-scale MOSS Document Management Projects: 50k Per Day, 10 Million Total

This past week, someone asked a question about creating a SharePoint environment that would handle a pretty high volume of new documents (10,000 +/- in this case).  I don’t know much about this, but thanks to this white paper, I feel much better informed.

For me, this white paper is pretty much just a book mark at the moment, but I did start reading through it and thought I’d highlight my main take-away.  SharePoint can be scaled to handle, at a minimum, this load:

  • 50k new documents per day.
  • 10 million documents total.

I write the 50k/10MM figures because they are easy enough to remember.  As long as you know they are minimums, you won’t get into trouble.  The maximums are at least 10 percent higher than that and with extreme tuning, possibly a lot higher.

Thanks, Mike Walsh, once again for his weekly WSS FAQ updates and corrections post.  If you’re not subscribed to it, you should seriously think about doing it.

</end>

 Subscribe to my blog.