What I missed – MOSS Camp 2007 (Chicago)

There were many reasons to miss the MOSS Camp 2007 in Chicago that the MS DPE team hosted.  It conflicted with SharePoint Connections (which I didn’t attend) and TechED Europe (which I also didn’t attend).  The reason I didn’t make it was that I was supporting a Women’s Ministry candle light dinner at my church.  I committed to that before knowing about the MOSS Camp event.  It was held on 11/9/2007.

Larry Clarkin posted a report about how it went.  There were some “grievances” aired.  I want to respond to a few of them because I think that they could look at the problem from a better angle or they’re the result of some relatively simple errors.  In all honestly several others I don’t understand (Filtering views is not clear, having all fields available on contacts, etc.).  If someone wants to explain them to me perhaps I can dispel a few of them too.

1. Column level security on lists – Another perspective on this is helpful.  How many people use column level security in their database?  (Does the word “none” come to mind?)  The real core issue here, the thing that’s absolutely missing is relationships between lists.  Two relationship types — one-to-one and one-to-many relationships – would be a great help.  With a one-to-one relationship you can suddenly just put fields that you want to control access to in a separate table.  So I’m not saying that we don’t have issues here – we do, but the real problem – the one that the product team can solve and get more scenarios – is relationships.  By the way, as a workaround, it’s possible to set a field not to display on the display form and it’s possible to change the forms to your own forms so people don’t see those fields if they don’t need to.
2. Impersonation testing – I can only assume people are having problems with the SPSecurity.RunwithElevatedPrivileges() call.  This is pretty common. Most of the time it’s someone trying to use SPContext.Current.Site (or SPContext.Current.Web).  These already contain the authentication information for the current user – you have to create your own instances inside the RunWithElevatedPrivileges call.
3. HTML Editor – Yea, ok, the built in editor is weak.  However, Telerik offers their commercial RadEditor that can be dropped in as a replacement.  Or you can get the commercial version or the free lite version off the version selector page.  Admittedly Telerik’s site is impossible to navigate.  However, with those links you should be able to get everything you need.
4. Lotus Notes Integration – This is one of those items that is on the line for me not understanding their point.  From my perspective, SharePoint should be used to replace Lotus Notes except where rich offline support is needed.  Notes can be searched and you can embed direct links to Notes documents if the client has Notes installed.  What else do you want/need?
5. Relative links are broke(n) – Yea, they are.  Server relative links work.  Absolute links back to the SharePoint server are converted to server relative links and thus work across different access paths (think internally (server) vs. externally (server.mycompany.com))  Fully relative links don’t work, and here’s why:  You don’t know where the content will be displayed.  If I display it on the home page vs. on the listing page the path is different.  Thus the relative paths wouldn’t work.  So yes, the system totally strips them and you can’t prevent it from doing this.  That being said, server relative links can be used as a workaround if you plan correctly.
6. WYSYWIG on Web Parts – Another perspective on this is helpful.  There isn’t a WYSYWIG for server controls either and people don’t complain about that – they user controls.  Web Parts are essentially sophisticated server controls.  So my response is use user controls wrapped in a web part.  There are public samples of how to do this all over the place.  The most famous is undoubtedly SmartPart.  Admittedly there are issues there.  However, I have a configuration management supported process that works well for this – I just haven’t had time to convert it into a book yet.  (If someone wants to engage me to show them how to do it I can.)

Two quick things I agree with:

1. Service Unavailable Message – We need better control of error messages.  The 404 error is another example of this.
2. XHTML Compliance –Some of this is fixable with new master pages and new page layouts – however, there’s some that can’t be fixed.  The ListViewWebPart and ListFormWebPart are tops on my hit list for this.  In addition to standards compliance issues, they hardcode attributes rather than using CSS.  (Check the output of a display form, you’ll find hardcoded cell widths.)

Feel free to send me mail on this if you don’t agree – or you need more details.

Training Resources for Web Content Management

[Note: I put this together for a client a few months ago and forgot to post it here.]
[Note: 07-11-12: Updated a few links.]

This is a list of resources for Microsoft Office SharePoint Server 2007’s (MOSS) Web Content Management feature (WCM).

On-Line

The following resources are On-Line resources.  This includes web casts, blog entries, articles, etc.

Microsoft (Free)

The following links are free links from Microsoft’s web sites.

Microsoft eLearning

The following resource is a for-pay resource available from Microsoft:

• Course 5253: Implementing Content Management Solutions by Using Microsoft Office SharePoint Server 2007

Microsoft Blogs

The following are Microsoft sponsored blogs that contain content relative to Web Content Management:

• Enterprise Content Management Team Blog
• SharePoint Products and Technologies Team Blog

Books

The following books may be of assistance with Web Content Management topics.  I didn’t list books which were not available today:

Training

There’s only one course available for Web Content Management right now.  That is Developing Publishing Sites with SharePoint Server 2007 WCM.  It’s available as an on-site or an on-line version.

SPWorkflowAssociation.AutoCleanupDays

One of the things I like (mostly) about working with SharePoint is that I get the opportunity to learn stuff almost every day.  I say mostly because although I love to learn, sometimes I have to learn by making mistakes – and that’s never fun.

About a month ago Dave Wollerman learned something about the way workflow’s worked and blogged about it.  The post titled “Huge MOSS Workflow Issue… What is Microsoft Thinking!!!!”  The post lays out how workflows based on the out of the box workflows – Approval is the one he calls out – lose their workflow history after 60 days.  In his post he’s frustrated (as in fact I might be) because he expects that workflow history stays around as long as the item does.  He mentions that there’s a performance reason for doing this but doesn’t dig behind the scenes.

In a recent conversation with some folks on the product team I got to mention Dave’s post and talk through it with them.  Out of that conversation I was struck by a few things.

First, there is a real performance issue that they were trying to address.  Because of the way that lists are implemented there’s a soft limit around 2000 items per “view” where the performance starts to decrease.  It’s a long story about the database table that items are stored in, how SQL treats the query, etc.  The short of which is that you need to be cognizant of how big lists get.  Steve Peschka wrote a white paper on this “Working with large lists in Office SharePoint Server 2007”.  It’s good reading if you want to know more about this.  But what does this have to do with Workflow History?

Well, each workflow history entry is placed into a big list.  In that list you have all of the workflow history items for all of the workflow instance for every workflow association that has that workflow history list associated with it.  If you figure on five workflow history entries per workflow it’s easy to see that even a few hundred items with workflow can quickly cross that 2,000 item mark.  As a result deleting items – making sure that the list doesn’t get really, really huge, is an important part of maintaining performance on the system.

Second, Dave’s thinking about the workflow history list as a permanent audit record.  MOSS provides an audit mechanism – but the workflow history list isn’t it.  I have to admit that I’ve fallen into this trap.  I do have some workflows that I think of the workflow history list as a part of the auditing – so I need to go back and revisit these workflows.  A better way to think about the workflow history list is a log.  The log files that MOSS creates – the ULS Log – are automatically recycled. Based on the schedule you set new logs are created and eventually deleted.  Workflow histories are designed to be like this.

Third, there’s a gap in the documentation.  It’s not precisely clear how this automatic recycling of the list takes place.  The object model reference lets you know that SPWorkflowAssociation.AutoCleanupDays exists, however, it doesn’t offer any additional information about how it works, why it exists or how it works.  I’ve found only a few references to this property in the Blogosphere.  I haven’t found an article or book that covers it (including my chapter in Real World SharePoint 2007 or articles.)  That means that it’s not going to jump out at you – unless you go looking for it because you already know it’s there.

Fourth, and finally, I’ve not been able to find any place that it is documented how to set the AutoCleanupDays when the workflow is associated.  However, a buddy on the program team showed me where this can be set so it will apply to every new association of the workflow – it won’t solve the built in workflows but it can help you with your own workflows.  Note the addition of an node in the following sample Element Manifest Xml:

<Elements …>
<Workflow …>
<MetaData …>
<AutoCleanUpDays>9999</AutoCleanupDays>
</MetaData>
</Workflow>
</Elements>

That’s pretty cool and not unlike the idea of feature stapling – where you can handle all of the new instances created even if you have to go back and update the existing associations.

[Update: 2007-10-16: It turns out that autocleanup doesn’t actually clean out the workflow history.  It does, however, remove the entry from the workflow instances that connects the workflow history to the item that the workflow ran on.  It also turns out it deletes any tasks that were created by the workflow.  The net effect of this is that the actual auditing is OK — the user interface just doesn’t look so good.]

InfoPath Form Services and Workflow Tasks

InfoPath Forms Services and Workflows in SharePoint can deal a one-two punch to your business problems.  It’s a simple form to create and a framework to take action on those forms.  However, there are a few caveats, however, one of them is that getting a form to open up in InfoPath Forms Services can be setup in the library where the form is stored but when a workflow task is created the link back to the item will try to open up in the InfoPath client (if present) – not in forms services.

Getting the document library to force the InfoPath form to open in InfoPath Forms Services can be done from the document library home page by selecting  Settings-Document Library Settings-Advanced Settings and changing the Browser-enabled Documents to Open browser-enabled documents to “Display as a web page”.

If you want to change the link so that it will open in the browser you’ll have to add a handler to the CreateTask activity.  I’ve added some support routines to break the code up into meaningful chunks. (that you can copy into your project).  The result looks something like:

private void createTask_MethodInvoking(object sender, EventArgs e)
{
string formsServerUrl = GetFormsServerUrl(workflowProperties.Item);
WorkflowTaskProperties.ExtendedProperties[SPBuiltInFieldId.WorkflowLink] = CreateUrlFieldString(“Open form for – ” + workflowProperties.Item.File.Name, formsServerUrl);
}

public static string CreateUrlFieldString(string name, string url)
{
return (string.Format(“{0}, {1}”, url, name));
}

public static string GetFormsServerUrl(SPListItem item)
{
return (item.Web.Url + “/_layouts/FormServer.aspx?XmlLocation=” + HttpUtility.UrlEncode(item.Web.ServerRelativeUrl) + “/” + HttpUtility.UrlEncode(item.Url) + “&OpenIn=Browser”);
}

Working from the bottom up, the GetformsServerUrl takes in the item you want the forms server URL for.  It does this by referencing the formserver.aspx and providing the correct parameters.  Above that CreateURLFieldString takes in the URL and a text description to create the string that you have to put into the field.

The actual MethodInvoking event for the createTask activity calls GetFormsServerUrl to get the actual URL and then CreateUrlFieldString to create a meaningful description for the link.  It then uses the SPBuiltInFieldId to get the Guid for the WorkflowLink field.

The net is a link that displays with a customized message and opens in the browser.