The Microsoft SharePoint 2010 platform has really come of age. In my three recent video podcasts, I showed some of my favourite features in SharePoint 2010:

• SharePoint 2010 Enabling Business Agility using Workflow
• SharePoint 2010 Business Connectivity Services and Offline Synchronisation
• SharePoint 2010 Sandbox Solutions

But there’s so much more for the SharePoint Developer to enjoy!

• Visual Studio 2010 SharePoint Projects and Project Items
• Client Object Model (for .NET, Sliverlight and JavaScript)
• LINQ to SharePoint
• Solution and Feature Lifecycle with the Versioning and Upgrade Framework
• SharePoint Designer 2010 and Visio 2010 Integration
• InfoPath 2010 Forms
• Claims Based Security
• SharePoint Powershell Integration
• Lists and Libraries Enhancements
• Branding Improvements
• Enterprise Content Management Improvements, Taxonomies
• Search Improvements
• Excel Services, PerformancePoint Services, PowerPivot for SharePoint
• Access Services
• Office Web Access
• …More! More! More!

To round off my week as the Firebrand Blog guest blogger, I’ve made a high level video overview of some of the new Business Intelligence features in SharePoint 2010. A quick look at the Business Intelligence Center site definition, a look at Excel Web Access and the Excel Web Access Web Part, and finally a peek at the REST API for Excel Services.

Don’t forget you can find all my videos as podcasts on iTunes! Just search for “joelblogs tv” and you’ll find them.

Technorati Tags: Business Intelligence, Charting, Excel Services, Excel Web Access, SharePoint 2010, SharePoint Videos, Training, Videos

Popular Misconception #1: “I can’t test my UDFs in Excel! When I write a UDF class and method, my spreadsheet works on the server, but I get #NAME? showing up when I try to build my spreadsheet in Excel on my desktop.”

This is kind of true. A UDF is just a .NET assembly that has bee appropriately attributed to mark the Class and Methods as discoverable and usable by Excel Services. You deploy this to Excel Services by installing it in the GAC on the server and registering it in the Shared Service Provider (SSP) for Excel Services.

Excel Client 2007, on the other hand, does not know what to do with these .NET assemblies. You can try adding these .DLLs as Excel Add-Ins or COM Add-Ins and Excel will complain that your assembly is not a valid add-in.

So how do we work around this? Some say you can wrap your .NET assembly in a .XLL library written in C++. Some say there are third party wrappers that will do this for you at a premium.

You don’t need to go that far.

Let’s have a look at a simple (trivially so) UDF for Excel Services.

   1: namespace JoelsUDF

   2: {

   3: // Mark this class as an Excel Services UDF

   4:     [UdfClass]

   5: public class JoelsUDFClass

   6:     {

   7: #region UDF bits

   8: /// <summary>

   9: /// My very complex UDF method... 

  10: /// </summary>

  11: /// <param name="value">Some number.</param>

  12: /// <returns>Passed in value inc
remented by one.</returns>

  13: // Mark this method as an Excel Services UDF method

  14:         [UdfMethod]

  15: public double AddOne(double value)

  16:         {

  17: return value + 1;

  18:         }

  19: #endregion

  20:     }

  21: }

Very, very simply, this marks the class as a UdfClass, with a single UdfMethod that takes a double and returns the value incremented by one. This can be signed and deployed into Excel Services using the method described in my previous post on Excel Services and UDFs.

If I now want to deploy this same assembly into Excel Client 2007 as an add-in, I could add a few lines of COM registration code. Once again, don’t forget to sign your assembly!

   1: namespace JoelsUDF

   2: {

   3: // Mark this class as visible in COM

   4:     [ProgId(JoelsUDFClass.ProgID)]

   5:     [Guid(JoelsUDFClass.ClassID)]

   6:     [ClassInterface(ClassInterfaceType.AutoDual)]

   7:     [ComVisible(true)]

   8:

   9: // Mark this class as an Excel Services UDF

  10:     [UdfClass]

  11: public class JoelsUDFClass

  12:     {

  13: #region COM bits

  14: // COM ClassID (GUID) and ProgID (Type Name)

  15: const string ClassID = "81FCB6CB-E4F1-4728-A6A7-8BBA85D0B5EA";

  16: const string ProgID = "JoelsUDF.JoelsUDFClass";

  17:

  18: // Registers COM class in the registry

  19:         [ComRegisterFunction]

  20: public static void RegistrationMethod(Type type)

  21:         {

  22: if (typeof(JoelsUDFClass) == type)

  23:             {

  24:                 RegistryKey regKey = Registry.ClassesRoot.CreateSubKey(

  25: "CLSID\\{" + ClassID + "}\\Programmable");

  26:                 regKey.SetValue("", System.Environment.GetFolderPath(

  27:                     Environment.SpecialFolder.System) + @"\mscoree.dll");

  28:                 regKey.Close();

  29:             }

  30:         }

  31:

  32: // Unregisters COM class from the registry

  33:         [ComUnregisterFunction]

  34: public static void UnregistrationMethod(Type type)

  35:         {

  36: if (typeof(JoelsUDFClass) == type)

  37:                 Registry.ClassesRoot.DeleteSubKey("CLSID\\{" +

  38:                     ClassID + "}\\Programmable");

  39:         }

  40: #endregion

  41: #region UDF bits

  42: /// <summary>

  43: /// My very complex UDF method... 

  44: /// </summary>

  45: /// <param name="value">Some number.</param>

  46: /// <returns>Passed in value incremented by one.</returns>

  47: // Mark this method as an Excel Services UDF method

  48:         [UdfMethod]

  49: public double AddOne(double value)

  50:         {

  51: return value + 1;

  52:         }

  53: #endregion

  54:     }

  55: }

I’d then need to register the assembly with RegAsm.exe (from the %SystemRoot%\Microsoft.NET\Framework\v2.xxxx folder).

RegAsm.exe /codebase UDFExample.dll

Finally I’d add it to Excel as a Excel Automation add-in. Under Excel Client 2007, this is available in File –> Excel Options –> Add-Ins, then select Manage: Excel Add-ins.

Next, select Automation and find your registered Add-in class.

This *can* cause Excel to complain with the following error:

It’s important that you say “no” to this.

Then you can start using your UDFs in Excel as if they were built in functions.

If you’d like the Visual Studio 2008 solution for this example, you can download it here:

Technorati Tags: Excel, Excel Add-ins, Excel Services, MOSS 2007, Office Server, SharePoint, SharePoint Architecture, UDF, User Defined Functions

I’m going to start with a MOSS Excel Services tip. If you’re already using this in anger, then I’m preaching to the converted. If you’re considering using Excel Services, or you’re about to advise a client on Excel Services, there’s a few things you need to know.

First off, some stuff you’ll probably know. Excel Services is a great platform for consolidating spreadsheets and bringing order for clients that are heavy Excel users. Investment banks – we know who you are – you folks with tens or hundreds of thousands of complex spreadsheets that get emailed about between users. Some of these spreadsheets are used to make multi-billion dollar decisions for the larger banks. Often, the authors of these spreadsheets are long since departed. Frequently, the banks daren’t make material changes to the business logic therein, just in case it all goes a bit Pete Tong.

Similar stories exist even when there aren’t decisions being made with quite such a high dollar-value. Government departments, pharmaceutical companies, accountancy firms, consultancies – the list goes on. All places with the potential to generate tonnes (can I measure digital data by weight?) of spreadsheets copied from user to user.

Microsoft Office SharePoint Server provides check-in and check-out to help restrict this kind of proliferation, as you’d expect in common with the rest of the Document Library features of MOSS. Excel Services gives us much more on top of that

When you add an Excel spreadsheet to a suitably configured Document Library, you can use Excel Web Access – kind of like Outlook Web Access - to view and interact with it. In fact, viewing through Excel Web Access is the default action on Excel spreadsheets in such a Document Library. There is also programmatic and web service access to Excel Services, which I’ll try and come to in another blogging.

Which brings us to:

Popular Misconception #1 – “You can edit the spreadsheet through the browser. The spreadsheet experience is just like the real thing – just like Google Docs.”

Nope. No you can’t. No it’s not. Sorry.

It’s good though! And what it offers is valuable. Instead, you get 60-70% of the core Excel desktop experience through the browser. Graphs, colour bars, pivot tables. All good, all decently rendered. And you can interact with the sheet through settable parameters and filters.

You can’t edit the sheet and you can’t save it. If you want to do that, you can either open the sheet in Excel client on the desktop, or create a “snapshot” – once again, for use in Excel client.

Why is this good? If you expose the sheet *solely* through Excel Web Access, none of your hard earned intellectual property – none of your business logic – ends up in the hands of your audience. You can build dashboards in MOSS that show regions of multiple spreadsheets or charts side-by-side with Key Performance Indicators (KPIs) or any other information you want to display.

Popular Misconception #2 – “I can take one of our complex spreadsheets and just stick it in Excel Services and have it run server side.”

Nope. Sorry. You’ve more than likely got some work to do. If your spreadsheet uses:

• VBA macros
• COM add-ins
• User Defined Functions

…you have some difficult decisions ahead of you.

If a lot of your business logic resides in VBA macros, you’ll need to consider recoding these as an Excel Services User Defined Function (UDF) in a .NET language. If your spreadsheet does lots of gnarly Monte Carlo analysis using a visual COM add-in, once again you’re left with a significant coding exercise.

If you’re lucky enough that your spreadsheet already uses client-side, C language User Defined Functions, you can either, once again, re-code them as an Excel Services Managed UDF – or write a managed wrapper for them.

There is a good list of unsupported and partially supported Excel client features in Excel Services here.

So, how do you do it? It can’t be easy, surely?

Popular Misconception #3 – “SharePoint Excel Services UDFs are difficult. It’s better just stick to simple spreadsheets and keep the complex ones as desktop spreadsheets.”

Very, very easy.

First, create a .NET 2.0/3.5 managed Class Library project in Visual Studio 2005/8.

Second, make a reference to Microsoft.Office.Excel.Server.UDF.dll, which is usually sitting here: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI on a server with MOSS installed.

Third, we’ll write our class and methods. Here’s a C# example.

   1: using System;

   2: using Microsoft.Office.Excel.Server.Udf;

   3:

   4: [UdfClass]

   5: public class MyUDFClass

   6: {

   7:     [Udfmethod]

   8: public double MyUDFMethod(double x, double y)

   9:     {

  10: return x * y + y;

  11:     }

  12: }

That’s more or less it. You’re now at liberty to fill your class and methods with as complex business logic as you see fit. The final step is configuration of the Shared Service Provider (SSP) for Excel Services, and deployment to a MOSS server – which may well be the topic of a future blogging.

To use your new UDF in a spreadsheet couldn’t be easier. You don’t even need to deploy the UDF to the desktop machine you’ll use to create the spreadsheet. Simply open a new spreadsheet, and use your function in a formula as if it meant something to Excel, thus:

Figure 1 – Using a Managed UDF in Excel Client

Yes, when you hit return it will get resolved to “#NAME?” as if it doesn’t recognise it. This is, of course, because it really doesn’t recognise it, and it won’t be recognised until you deploy that spreadsheet to a correctly configured Document Library.

That’s it for this time! :)

If you’ve been evangelising Excel Services having never used it, I hope this has cleared up a couple of common misconceptions. If you’ve been tempted to, but never quite made the jump, I hope this has given you a push to just *try* Excel Services. They’re pretty cool and, as I hope you’ll see, offer a compelling business story for bringing Excel spreadsheets back under control.

Technorati Tags: Excel Services, Excel Web Access, MOSS, SharePoint, UDF, User Defined Function, WSS