HttpCode

The next integration method that I want to discuss is the collection of data. As a web developer you’ve no doubt been asked to create a form that does X a number of times, you might even have created some tools to aide in this, it’s pretty common. So now that you’ve moved across to the dark side of MOSS development we need to break your thinking, if you want to create a form, first have a look at Microsoft InfoPath, InfoPath files can be published to MOSS running the InfoPath Forms Service.

The benefits to this approach are:

• Less development – I won’t go as far to say that even the worst coder on your team could use this tool, that guy can’t do anything, but for simple stuff it’s not too hard to get your head around.
• Central management of forms – You can easily keep track of your forms, how many times have you written a form that has already been developed? But seriously because each form is a content type, you can manage the metadata of a form from a single location, regardless of how many libraries you’ve added the content type to.
• Can easily use existing MOSS features - This is the biggest feature, you can easily add workflow capabilities or publish your results to a list, I bet most of your forms currently just send an email and get written to a database.

The disadvantages are:

• It requires a different way of thinking - This might not be a bad thing, but some large organisations have teams of programmers who spend 90% of their time doing some sort of forms based programming. It might be a hard sell for these guys.
• Anonymous access might cause some issues – I’ve seen a few issues around anonymous access to forms, it’s by no means a show stopper, but you should think about this before you deploy.

I think the benefits far out weigh the disadvantages, in any case hopefully the next time you hear a developer say they’ll create a web part for a form, you’ll think about it a little more carefully.

I previously posted about a simple integration pattern that used the Page Viewer web part. The approach I’m going to discuss today again does not involve any custom coding, but will have a huge impact on your end users.

If your goal is to make your corporate data more available this is an easy option.

I’ve posted about this diagram before:

This is the Business Data Catalog (BDC). It can source data from either a database or a web service, once you have built an Application Definition File (the only development work needed), your data can then reach custom lists, profile information, search and custom solutions.

The benefits to this approach are:

• Reach – You’d be hard pressed to develop a feature that has more end user impact. Firstly your data can be searched, secondly your data can now be used in ways that couldn’t be foreseen. This might be a scary prospect for a lot of organisations, but this will change over time, I plan to discuss this further in another post.
• Searchability – The younger generations have grown up with the web and expect to be able to do everything via search, you’ll probably find that your search engine is the most popular MOSS feature, why not plug more data into it?
• Fits with a SOA – Yes, it’s buzzword compliant, don’t forget that the BDC in MOSS can call web services, so if your organisation has a Service Oriented Architecture, this will likely be an easy sell.

The disadvantages are:

• Doesn’t work well for complex data – It really only works well if your data is simple, for example if your trying to expose a product list or the locations of your stores.
• Read Only Data – Indexing and Searching are read only operations, as simple as that. If you want your users to rate your data or tag it, then your going to need a different strategy.

I’ve been doing some thinking around how MOSS can be integrated into a large and complex organisation, an organisation that has many disparate applications which act as an information silo. Most developers who are not intimately familar with MOSS will suggestion just using the page viewer web part if the external system is web based. The page viewer web part is basically an IFrame, so MOSS is in effect a window to the external application.

The benefits to this approach are:

• Low Cost – The external system has already been developed, so it’s not going to cost you anything significant in terms of developer hours. This is assuming that no technical hurdles exist in simply referencing the application via a page viewer. I’ll discuss the authentication issues in the disadvantages section.
• Quick – Its quick and easy to do, if you plan to redevelop your system to be MOSS aware, this is a good interim measure.

The disadvantages are:

• Systems remain isolated – You still have to maintain that existing system, this might be OK but, it’s likely to be mature and stable.
• The information is still in a silo – This continues from the last point,MOSS isn’t taking full advantage of the system, you can’t personalise the information from the system, you can’t drop a filter web part on the page and get the exact data your looking for. Sure you might be able to crawl the external site and provide it via the Search Centre, but can your users build a custom list and use this information in a way that makes sense to them?
• Authentication – How is your authentication handled, MOSS is just providing a window to the external application, your external system has to do all the heavy lifting in terms of authentication and authentication.
• Inconsistent User Experience – Your external system probably has its own navigation, style and theme that probably isn’t the same as the MOSS implementation that your trying to sell to your users. It has gives off this feeling that its all held together by sticky tape.

I think this approach is fine if you fully understand what your doing, I plan on discussing some of the other approaches in some upcoming posts.

I’ve just uploaded the code that I’ve been blogging about recently to CodePlex:

http://www.codeplex.com/JQueryWebParts/

This contains:

• Tag Suggestion Web Part
• Rounded Corner Web Part
• Image Carousel Web Part
• Extended Script Manager

This is now the best place to continue development of these tools.

I’ve previously posted a demo that made use of a tag suggestion web part, as you type the web part will make an ajax call which will return the tags that match the current input. The user can click on the suggestion tag and it will populate the textbox, multiple tags can be entered into the textbox.

The most interesting part of this web part is the server side call, which I’ve implemented as a HttpHandler in the Tags.ashx file:

public class Handler : IHttpHandler {

    public void ProcessRequest(HttpContext context)
    {
        context.Response.ContentType = "text";

I’ve made use of the System.Web.Extensions JavaScriptSerializer to render the string array of tags to JSON:

   1: List<string> tagList = new List<string>();

   2:  

   3: //add all the tags to a collection, JSON serialize the list

   4:  

   5: System.Web.Script.Serialization.JavaScriptSerializer serializer = new System.Web.Script.Serialization.JavaScriptSerializer();

   6:  

   7: context.Response.Write(serializer.Serialize(tagList.ToArray()));

   8:  

I’ve put this handler in the /_vti_bin/ directory of SharePoint which maps to the ISAPI folder under the 12 hive.

I’ve used the same code to generate the tags as I did with the tag cloud web part, so once again the generation of these tags won’t scale to large lists, this is just an example of how to implement a JQuery based Tag Suggestion web part.

The source code for this web part can be found here.

Just a quick tip, if your crawling external sources with the MOSS (or Enterprise Search), you might find that your crawl doesn’t finish or hangs, it might be worthwhile checking to see if the site you are crawling has a calendar with links:

You will need to determine the URL and then add a crawl rule to exclude that path, the crawler will see an infinite number of pages (it thinks each date and next link is a separate page).

I recently had a project where I needed to bind some business objects to a SPGridView in a web part, which on its own is trivial, but I also needed to create the columns for the SPGridView on the fly, since a number of business objects could be rendered in this control.

The main problem was the naming of these columns, if I just bound them directly to the Grid, I would get the ugly naming of my properties (I say it’s ugly, it’s actually pretty awesome if your a developer, but those pesky end users like pretty names).

The sample grid looks like this by default:

So what I came up with isn’t exactly new or innovative, I created a custom attribute called Alias:

    public class AliasAttribute : System.Attribute
    {
        protected string[] aliasName;

        public AliasAttribute(params string[] alias)
        {
            this.aliasName = alias;
        }

        public string[] Alias
        {
            get { return aliasName; }
            set { aliasName = value; }
        }
    }

This attribute gets applied to each property on your business object with a pretty name:

        [Alias("Internet URL")]
        public string InternetAddress
        {
            get { return internetAddress; }
            set { internetAddress = value; }
        }

Now the code that performs the binding looks for properties with a custom attribute and pulls out the alias as the HeaderText:

BoundField newBoundField = new BoundField();
newBoundField.HeaderText = Helpers.GetPropertyAlias(field.Trim());
newBoundField.DataField = field.Trim();
grid.Columns.Add(newBoundField);

public static string GetPropertyAlias(string propertyName)
{
    //Change the next line for your business object ..
    PropertyInfo[] propInfos = typeof(BusinessObject).GetProperties();

    foreach (PropertyInfo propInfo in propInfos)
    {
        if (propInfo.Name.ToUpper().Equals(propertyName.ToUpper()))
        {
            object[] attribs = propInfo.GetCustomAttributes(typeof(AliasAttribute), true);
            foreach (object attrib in attribs)
            {
                if (attrib is AliasAttribute)
                {
                    AliasAttribute alias = (AliasAttribute)attrib;
                    //return the alias
                    return alias.Alias[0];
                }
            }
        }
    }

    //if we don't find the custom attribute, just return the same value we passed in
    return propertyName;
}

The end result is a nice pretty grid:

A sample project can be found here.

If you work in an organisation that has an organisation hierarchy it might be worth setting this up within MOSS, so that when you view a user’s profile you will get the following view:

This is driven off the Manager profile field, it can be setup so that it is driven off either active directory or a custom source such as a SQL database in which case the BDC will need to be used. The Colleague suggestions and notifications make use of the organisation hierarchy as well, so it is worthwhile to set it up.

One thing but, regardless of your localisation settings, the heading ‘Organization Hierarchy’ will be spelt with a ‘z’, so for us Aussie’s we just have to cop the American spelling.