I have been doing some tests/prototypes using Excel Services (included in MOSS2007). Excel Services is a new product, a server-side implementation of Excel. Its big selling point is that it allows business users to keep their excel sheets, where logic has accumulated over the years, but now expose it on the server, where it can be shared enterprise-wide.
The product includes 2 main components: Excel Web Access (EWA) and Excel Web Services (EWS). EWA is in essence a web part that displays a mostly read-only view of an Excel spreadsheet. You can input single-valued parameters and see the calculations being updated. EWS is a web services layer in the front of an Excel spreedsheet. You can input values, individual cells or ranges, and get both results of a binary snapshot of the spreadsheet.
I was really surprised about how much I can do with the product, and how easily. The ability to save a spreadsheet I half filled with Web Service calls, the ability to use Ajax to invoke the web services (with some sample code availablle on the net) on the browser, the power of the User Defined Functions, developed in C# and which can access databases or whatever, etc. It IS a very interesting product, and I strongly recommend it.
This said, I think this first version, included in MOSS 2007, still has space to evolve in a couple of different areas, improving it’s fit to several more design/architecture problems.
First, EWA has to be improved to support full read-write, instead of simple single-cell input, using ranges, lists-of-values, etc. While this doesn’t happen, it’s usefullness is mostly in data display and very simple usage scenarios.
The second is more strategic: the Excel “client” is not really a Client App to Excel Services. They are different applications. If would be nice if one could have Excel (client) open a spreadsheet and do the calculations and data access on the server only.
Let me give an example, related to the product’s main selling point: imagine you have an Excel spreadsheet initially developed in the 80’s. It has hundreds of formulas, some 20 sheets, reference data, dozens of input fields/ranges, charts, etc. A living nightmare to IT, not necessarily so to the business users. Now I can store this spreadsheet on the server, true, but what do use as a client? I know I can interact with it using EWS, but the development of a specific Smart Client to access it, replicating some of the rules, is clearly an expensive option. This should be done directly in Excel Client, because that is the application the the business users love and know how to use, and because that’s what minimizes development effort. I can use VSTA and develop in Excel Client to do this, and this is probably the best option at the moment.
Developing this idea, two more thoughts: it would be nice to have a “Excel Click-Once” functionallity, where a spreadsheet open in Excel (client) could be updated with the latest information from the server spreadsheet. Also, one of the problems with current Excel spreadsheets build up over the years, is that they get lost in people’s hard drives. Some kind of mechanism could be in place to avoid or control this, so that people are always using the most up-to-date version of the logic.
Two further aspects, non-technical: when a business user is presented with a solution based on Excel Services, the reaction can easily be of surprise: “is this it?!“. They are used to IT giving them apps, web sites, etc., not saying: “Just use Excel“. People still have the impression that, to be good, you have to pay for it.
Which brings me to the second aspect: licensing (which is where you do pay). To use Excel Services, one has to fully license MOSS2007 Enterprise. That is, to use Excel Services, you have to pay for SharePoint Server, Forms Services, BDC, etc. All the components of SharePoint Server. Interestingly, this does not happen with Forms Services: you can simply license WSS 3.0 + Forms Services.
Anyway, these were just some ideas. Excel Services is an excelent start for a new product, and will surelly have very interesting developments in the following years.
Most of the information I’ve used while developing my prototypes where based the SharePoint 2007 SDK, but I also recommend LuisBE’s blog, and Cum Grano Salis (where you can find the Ajax library I mentioned). Also, this ExcelPackage CodePlex project seems very promising (don’t get me started in the power of the new formats :-)).
