SharePoint

SharePoint Saturday Presentation Slide Deck

Adam McKee — Mon, 09 Nov 2009 16:11:07 GMT

As promised, here's the slide deck for my SharePoint Saturday presentation:

Thanks again for attending!

Speaking at SharePoint Saturday Raleigh on Nov. 7th

Adam McKee — Fri, 23 Oct 2009 20:41:23 GMT

Hey everyone,

I'm super-excited (and a little nervous) that I was given a speaking slot at SharePoint Saturday Raleigh on Nov. 7th! (Link goes to presentation overview.)

There are quite a few SharePoint heavy-hitters attending (Michael Gannotti, Dan Lewis, and Joshua Carlisle to name a few), so go register today - seats are filling fast!

Cheers,

Adam

Migrating SharePoint Content to Oracle UCM #2

Adam McKee — Tue, 20 Oct 2009 00:39:08 GMT

So we landed on a solution. It's not ideal by any stretch, but it does accomplish the purposes we set out to meet, and it does give us a (small) step in the right direction in terms of moving the client to using Oracle UCM as the sole company-wide content repository.

To recap, here's the skinny on what we're facing:

There is a mandate in the company to move all "content" to Oracle UCM (a content unification measure)
There is a significant amount of content in SharePoint (in the form of lists) that needs to make its way into Oracle UCM
Business users do not want to stop using the SharePoint interface for data entry (not to mention get all the "for-free" stuff that comes with SharePoint, such as alerts, content approval mechanisms, permissions, and workflow).
It is not feasible to move all of the lists over at once (we have a 3-week scope to move "something" over from SharePoint to UCM)

We came up with two approaches that had varying payoffs and risks.

The Simple Approach

Seeing how it was very important to keep all of the existing functionality in SharePoint in whatever solution we devised, we first thought of "replicating" list content to the UCM from SharePoint. This approach involved writing a custom workflow that would fire on list item update, and would intelligently call a checkin function in UCM.

This "simple" solution wouldn't come without risks - the first (and most obvious) one being that we'd have duplicated data that needed to stay in sync. After thinking about the implications, we found that this risk wasn't terribly bad. Since no content contribution happens on the UCM-side with this implementation, there's no harm if SharePoint goes down - there just wouldn't be any new data. If the UCM goes down, syncing the data would mean saving the items again (a solution acceptable by the client).
The UCM-Heavy Approach

This approach was quite a bit more aggressive in terms of planning, execution, and support, but yielded a much bigger step towards migrating the list content from SharePoint to UCM.

The plan was to "switch out" standard SharePoint CrUD (and other) functionality for custom functionality that manipulated UCM content directly. The idea was that all point-foward content would be manipulated directly in Oracle UCM through the SharePoint interface. We felt that if we could nail this approach that we'd set a good proof-of-concept for migrating other content to UCM from SharePoint.

This approach was monstrously invasive. It involved re-writing a lot of stuff that comes for free with SharePoint, and was therefore expensive and risky. However, the payoff of making such a big step towards UCM would be a huge win for the client.

The Accepted Solution

It will probably come as no surprise to many of you that we landed on solution #1. What killed solution #2 was that UCM doesn't have an OOB way to handle broadcasting alerts based on permissions (on the item level) when content was created or updated. Sure, we could write a workflow to sorta-kinda handle it in UCM, but we didn't have the time or budget for it.

Next time, I'll tell you a little about how we're going about implementing solution #1, and what sorts of challenges are cropping up.

Oh Where, Oh Where Did My Team Collaboration List Templates Go?

Adam McKee — Wed, 14 Oct 2009 19:41:07 GMT

I stood up a standard publishing site on a vanilla MOSS instance for some custom workflow development I'm doing. I went to make a list from the Announcement List template (the one that comes OOB), and found that most of the list and library templates that I was accustomed to seeing weren't there at all.

It turns out that by default, the OOB Publishing site definition does not activate the Team Collaboration Lists feature. Go to Site Features and activate it for your publishing site, and they will appear.

Migrating SharePoint Content to Oracle UCM

Adam McKee — Wed, 07 Oct 2009 03:21:56 GMT

I’ve got an interesting challenge a client has asked me help with. We are attempting to move items from multiple custom SharePoint lists to Oracle UCM and continue to manage/review/approve the data through the SharePoint interface.

Moving this list content to OUCM is part of a bigger strategy to centralize all of the “business truth” (content) to OUCM, while keeping SharePoint for collaboration. There are a lot of things to consider, and lots of risks to document.

I'm just now getting to documenting the state of the system, so I'll share some challenges and insights we've come across when we've landed on an approach - should be fun :)

SharePoint 2010 Beta in 2 Months

Adam McKee — Sun, 17 May 2009 07:44:43 GMT

Even though SharePoint 2007 still has the new car smell in many ways, SP 2010 is just around the corner.

http://www.networkworld.com/news/2009/051509-microsoft-sharepoint.html?hpg1=bn

Lessons Learned From Making SharePoint Recommendations

Adam McKee — Wed, 22 Apr 2009 10:24:05 GMT

I was recently asked what lessons I've learned when recommending SharePoint for for meeting a business need. While books are written on this topic, I've distilled the list down to what I think are the core of the decision-making process.

Know what your stakeholders require in objective, actionable terms

This is known as extracting core business drivers. Note that I didn't say requirements. Requirements are what you hand to your developers - core business drivers are what you use to make your recommendation.

Right questions to ask at this time:
- How does process x drive revenue?
- How much productivity loss constitutes a bottleneck in x process?
- How much must efficiency increase for x process to meet your defined goals?

Wrong questions to ask at this time:
- What problems do you have with your current system?
- What do you want your new system to look like?
- How do you want the system to function?

Note that the difference between the right and wrong questions is objectivity vs. subjectivity. If you can't get a quantifyable answer, the question should never be asked. And in reality, you should be answering those wrong questions yourself once you have digested the business drivers.
Map the core business drivers up to things that SharePoint does well

Another way to say this is, “Don't try to make SharePoint do something it's not designed to do.” This concept is simple, but it's very hard to establish effectively because SharePoint does so many blasted different things.

It's at this point where you'd decide whether using WSS or a full-blown MOSS implementation will fit the bill.

Be careful not to get into technical debt when mapping things up. If you've never used Form Services before, you'd better be darn sure it's the right fit for the job.

Every SharePoint feature you decide to implement should correlate to a core business driver. If you stick to this principle, you will avoid a lot of tehnical debt.

Just because SharePoint can do something doesn’t mean that you have to use it. Not every solution has a problem, so don't expect to use the entire of the SharePoint canon of functionality.
Decide whether the benefits outweigh the costs

Even if all of your quantified core business drivers are covered by your recommendation, there are a lot of unquantifiable things that will crop up. I'm talking about things like the personalities/predispositions of the stakeholders toward SharePoint, to the adoption propensity of the user base.

Rules are FAR more important than tools. Be smart on where governance is required to keep your SharePoint instance humming (even more books have been written on this matter, so I’m not going to get into it now), and build it into your proposal.

SharePoint Configuration Values Best Practices

Adam McKee — Fri, 06 Mar 2009 03:52:30 GMT

Every ASP.NET developer is accustomed to writing configurable values into the web.config for directing programming logic at runtime. This practice has always made a lot of sense for storing things that will change depending where assets (such as databases, web services, etc.) are going to live come production time.

The tricky part comes in when you need to store configurable values that change the behavior of your code, but don't apply to other systems in any meaningful way. An example of one such configuration setting would be a magic number that is meaningful to determine the state of a piece of data in your system, but is entirely useless to the rest of the world.

While you can get away with storing values (such as magic numbers) in the web.config for most standard ASP.NET applications, doing so with SharePoint is a major no-no. SharePoint can overwrite sections of the web.config not supported by WSP/features when solution deployments are made, and you don't want to run the risk of your values being wiped out. It also goes without saying that the less cluttered you can make the web.config, the better - it's complicated enough as it is.

So, if not in the web.config, how and where should you store configurable values for your custom SharePoint code, and how do you got about fetching it safely and efficiently?

It takes two components:

An XML document (stored in a known location - a document library is ideal) to store the configuration settings
A class to cache, and then fetch the values at runtime

Simple enough, eh? Here's an example of what your XML document should look like (You'll notice that it looks identical to the <appSettings> node in a standard web.config file):

<?xml version="1.0" encoding="utf-8"?>
<appSettings>
<add key="FeedCacheTime" value="300" />
<add key="DataInProcessId" value="92" />
<add key="BuyoutThreshold" value="42" />
</appSettings>

And here's the code for fetching the values at runtime (please note where you are to supply where you store the XML configuration document you created in the previous step):

using System;
using System.Collections.Specialized;
using System.Configuration;
using System.Xml;
using Microsoft.SharePoint;

namespace Utilities
{
    public static class CustomConfigurationManager
    {
        private static NameValueCollection _configurationItems;

        static CustomConfigurationManager()
        {
            LoadConfiguration();
        }

        private static void LoadConfiguration()
        {
            XmlDocument configurationDocument = new XmlDocument();

            string portalUri = string.Empty;
            string relativeUrl = string.Empty;
            string requestUrl = string.Empty;
            string xmlString = string.Empty;

            SPSecurity.CodeToRunElevated secureCode = null;

            if (secureCode == null)
            {
                secureCode = delegate
                {
                    portalUri = HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Authority).ToLower();
                    relativeUrl = GetRelativeUrl(URL TO CONFIGURATION XML FILE);
                    requestUrl = portalUri + relativeUrl;

                    using (SPWeb web = new SPSite(requestUrl).OpenWeb())
                    {
                        Uri uri = new Uri(requestUrl);
                        SPFile file = web.GetFile(uri.AbsolutePath);

                        if (file != null)
                        {
                            byte[] bytes = file.OpenBinary();
                            xmlString = Encoding.ASCII.GetString(bytes);
                            bytes = null;
                            configurationDocument.LoadXml(xmlString);
                        }
                        else
                        {
                            xmlString = string.Empty;
                        }
                    }
                };
            }
            SPSecurity.RunWithElevatedPrivileges(secureCode);

            LoadAppSettingsCollection(configurationDocument);
        }

        private static void LoadAppSettingsCollection(XmlDocument configurationDocument)
        {
            _configurationItems = new NameValueCollection();

            XmlNodeList configNodes = configurationDocument.GetElementsByTagName("add");

            foreach (XmlNode node in configNodes)
            {
                string key = null;
                string value = null;

                if (!string.IsNullOrEmpty(node.Attributes["key"].Value))
                {
                    key = node.Attributes["key"].Value;
                }

                if (!string.IsNullOrEmpty(node.Attributes["value"].Value))
                {
                    value = node.Attributes["value"].Value;
                }

                if (!string.IsNullOrEmpty(key) && !string.IsNullOrEmpty(value))
                {
                    _configurationItems.Add(key, value);
                }
            }
        }

        private static string GetRelativeUrl(string url)
        {
            StringBuilder builder = new StringBuilder(url.ToLower());
            if (url.ToLower().IndexOf("https://") > -1)
            {
                builder.Replace("https://", string.Empty);
                builder.Remove(0, builder.ToString().IndexOf("/"));
            }
            else if (url.ToLower().IndexOf("http://") > -1)
            {
                builder.Replace("http://", string.Empty);
                builder.Remove(0, builder.ToString().IndexOf("/"));
            }
            return builder.ToString();
        }

        public static NameValueCollection AppSettings
        {
            get { return _configurationItems; }
        }
    }
}

To access your configuration settings, you'd call it like this:

string feedCacheTime = Utilities.CustomConfigurationManager.AppSettings["FeedCacheTime"];

This methodology accomplishes a few things:

The call to the configuration is almost identical to getting it out of web.config (no real learning curve to implement)
The configuration file is only loaded once per IIS session, so you don't have the overhead of lots of calls to the configuration document library, nor do you waste time waiting for it to load something that isn't going to change very frequently
You "shield" the rest of the world from your code-specific configuration (good encapsulation practice)
You don't have to worry about SharePoint wiping your configuration due to other solution deployment changes.

Workflow SPListItem modified by SHAREPOINT\system

Adam McKee — Mon, 23 Feb 2009 23:36:46 GMT

I came across this last week. It took me entirely too long to get it fixed, considering how simple the resolution was. It turns out that my understanding of how Workflow operates wasn't up to snuff.

Scenario

I have a workflow attached to a forms library, activating when a list item is modified. The intent of the workflow is to modify one or more fields on a particular list item in this list, after it is edited by another process. Each of these fields are modified in different methods, which are tied to different nodes in the workflow - in other words, I couldn't update them all at the same time with the same workflowProperties.Item.Update() call.

As the workflow ran, the first update to the list item (which happened to be a workflowProperties.Item.File.SaveBinary() call) worked perfectly. However, once the workflow got to the second field it was attempting to update, I got the following error:

Microsoft.SharePoint.SPException: A file with the name myfile.xml already exists. It was last modified by SHAREPOINT\system on 21 Feb 2009 15:31:28 -0500.

Troubleshooting

I figured that the error wasn't lying to me, but I wasn't sure how was supposed to make the code "aware" of the newly updated list item for the next update call. I tried all permutations and variations of the Update() and SaveBinary() with all their different overloads to no avail.

I then discovered a very important fact - when the workflow initially hydrates, it "fetches" the data stored in the workflowProperties object only once up-front, which means that if I am going to run workflowProperties.Item.Update() twice in a row (as I am doing in my workflow), I'm going to have to re-fetch the list item between Update() calls.

Solution

I added a property to my Workflow class (please forgive the flagrant use of VB.NET):

Private ReadOnly Property WorkflowItem() As SPListItem

Get

Dim library As SPDocumentLibrary

library = CType(workflowProperties.Web.Lists(workflowProperties.ListId), SPDocumentLibrary)

Return library.GetItemById(workflowProperties.ItemId)

End Get

End Property

From then on, instead of using workflowProperties.Item, I use myItem = Me.WorkflowItem (to force the fetch each time I need to get to the item), and then use myItem.Update(). The problem evaporated altogether.

References

http://www.k2distillery.com/2009/01/workflow-splistitem-out-of-date.html

How to Grow a MOSS Farm #1

Adam McKee — Sun, 01 Feb 2009 09:52:22 GMT

Okay, Mr. SharePoint Architect. You've been asked to lead your developers to SharePoint glory, and you're ready to whip out your MSDN DVDs, and stand up a brand spankin'-new MOSS farm. You know the drill, too - you've done this 10 or 20 times, so it's no sweat. Right?

Well, it isn't much of a sweat if the client wants a 100% vanilla, no-frills, no-customization MOSS instance. While this sounds ludicrous to you and me now, it brings me unending amusement how so many people bought SharePoint licenses thinking it would be a turn-key solution to all of their business problems.

"SharePoint is 100% configurable - all you'll need are some BA's who are savvy in XML to solve all of your business problems!"

No, that's not a real quote, but it's darn close to the fleece that was pulled over many of our client's eyes. But it's great news for me, because it means that I'm gainfully employed now that they all realize that they can't get where they want to go without help from us SharePoint magicians... but I digress (albeit, a little snootily).

So now that I'm done rambling, here’s the real reason I’m writing this post: I want to impart some questions that you should ponder before diving into an architecture diagram.

1. Will the environment be a 32-bit or a 64-bit environment?

Before we go any further, allow me to relay something to you that was stated to me by a member of Microsoft support staff when I was asking for help on a super-obscure error in the SharePoint log (the specifics of the error don’t matter, just his response):

“Yeah, MOSS isn’t really designed for a 32-bit implementation – it’s really meant for a 100% 64-bit platform.”

So there you have it, ladies and gentlemen – while MOSS will run in 32-bit, you’ll want to build a 64-bit environment realize the full potential of MOSS. You’ll run into less weird problems that require you to call granddaddy Microsoft for help.

Now, don’t get me wrong, I’ve done quite a few very successful 32-bit implementations, but I’ve seen far better perofrmance (in terms of speed and less utter lunacy in the error logs) from 64-bit installs.

2. What version of SharePoint should be installed (WSS 3.0, MOSS Standard Edition, MOSS Enterprise Edition)?

The differences can be found here. Your decision will mostly be driven by scale of the implentation, but here are a few “litmus” tests for weeding out what they really want:

Search requirements
Collaboration requirements
CMS requirements
Audience control requirements
Integrating with/searching external application data

3. How many web application servers are required in the farm?

This will be affected primarily by the load you’re expecting to see (among other things), and I may choose to write more about this later.

4. What type of external access requirements are there? What constitutes an “outside” user?

These questions have implications primarily in the authentication space, but depending on the answer, you’ll want to think about extending your content-bearing sites to include other forms of authentication (forms or windows), alternate access mappings, and the implications of who will get profiles.

You should be able to at least get the conversations started about how to architect your farm with these thoughts.

Next issue, I’m going to dive a bit into some system requirements for what I’ve seen work for development environments and production environments for MOSS Enterprise.