Excel Services with Excel 2003

You don’t actually need the Excel 2007 client installed in order to create and deploy Excel workbooks that can be used in Excel Services in MOSS 2007.  In order to use Excel Services, you *do* need MOSS Enterprise 2007.  And workbooks used by Excel Services *do* need to be in Excel 2007 format, but as long as you have the Office 2007 Compatibility Pack installed, you can use Excel 2003 to save your workbook in a compatible Excel 2007 format.

Named Areas
One of the capabilities provided by Excel Services is displaying a specific range of cells or a specific chart on a web part page in Sharepoint.  The behavior and implementation of how you setup these named areas is slightly different between Excel 2007 and Excel 2003.  With Excel 2003 it provides a default name for each chart that is created.  This looks like “Chart 1″, “Chart 2″, etc.  You can override this name by selecting the chart object and entering a new name in the Name Box field, which appears by default in the top left portion of the screen. 

Note that the trick to selecting the chart object so that you get this Name Box populated with the actual name of the chart is to hold down the Ctrl key while clicking the chart.  Otherwise you’ll end up selecting a particular element of the chart (e.g., Chart Area, Plot Area, etc.).  This is slightly different behavior than Excel 2007, and it drove me nuts trying to figure this out.

To get a range of cells to be a named area, simply select the range of cells and type in a name in the Name Box.  To change the name you need to select the identical range of cells before the Name Box will populate with your name to change.  Again, not obvious.

Save As Excel 2007 Workbook
Once you’ve done this, simply save your Excel workbook in the Excel 2007 Workbook format with the Save As menu item.

You can then upload this workbook file into your Sharepoint document library, like any other file you might want to make available in a library.  I won’t go into details on Trusted File Locations, but you do need to have your document library setup as trusted in Sharepoint Central Admin in order for Excel Services to display your workbook in the web part or a web page.  Also note that there are a variety of unsupported features and requirements that you need to keep in mind when preparing your workbook for Excel Services consumption.

Sidebar - Excel 2007 Publish Option
Excel 2007 provides you with a an alternative approach to making your workbook available to Excel Services.  It has the idea of “publishing” your workbook to Excel Services.  You’ll see a new menu item for this in the Excel 2007 client.

When you select this option you basically get the same Save As dialog, but with a couple of extra options.  One of which is the Excel Services Options button.

Clicking this button presents a dialog where you can restrict which specific worksheets, named range of cells, or specific charts you want to make available for viewing in Excel Services.

In the text of this dialog it reiterates that what you are specifying is really only restricting what is seen in the browser view of the document.  A user with privileges to open the workbook in their Excel client will be able to see the entire contents.  All that Excel is really doing when you specify these options is adding some metadata to the file so that Excel Services knows what to show in the browser view of the workbook.  So don’t think of this as a high level of security control over the contents.  However, you actually can restrict users to only opening the workbook in the browser view by only granting them View Only access in Sharepoint (instead of Read, for example).

This Excel Services Options dialog is also used to specify specific cells that you want to make available as Parameters in Excel Services.

‘Show’ and ‘Parameters’ - Not Features in Excel 2003
Note that these two features in the Excel Services Options dialog are two features you will not be able to support if you’re using Excel 2003 to create your workbooks for Excel Services.  So, if that’s important to your solution, then you’ll need to upgrade to the Excel 2007 client.

Excel Web Access Web Part
Once you have the workbook saved in the document library you can make it available on a Sharepoint page using the Excel Web Access web part.

Then modify the web part properties to specify the specific Excel 2007 file, and the named item/area.

The Named Item field corresponds to the Named Area within the Excel workbook, and will restrict what is actually shown in the web part on the page.  You can use multiple instances of the Excel Web Access web part on the same page if you want to display multiple charts or multiple cell regions.

I’ll provide another post in the future that demonstrates how to hook up Sharepoint filters to dynamically control the named area shown.

Excel Services Open in Browser Default

If you create a Report Center site in Sharepoint 2007 and use the Reports Library document library which is created by default, then any Excel workbooks you view from that library are displayed in the Excel Viewer web page by default.  Simply clicking on the Excel workbook within the document library opens the Excel document using the Excel Web Access web part in a full web page.

If you are using your own custom library to contain Excel workbooks for viewing via Excel Services however, you won’t get this behavior by default.  Instead, when clicking on the workbooks in the document library they will be sent down to the client PC and subsequently opened in the Excel client.

You can still accomplish viewing the workbooks in the web page viewer by clicking the drop down menu associated with the workbook file and choosing View in Web Browser.

This may not be your desired preference though, and you can override this default behavior.  The key is in the Advanced Settings section of the document library that houses the workbooks.  Select the “Display as a Web page” option here to have the workbooks displayed in the web page viewer by default.

K2 blackpoint Announcement

K2 will be announcing their new product offering, named K2 blackpoint, tomorrow at Microsoft TechEd.  K2 blackpoint will be a new SKU, which is a subset of the K2 blackpearl offering.  It will be targeted for Sharepoint developers who want to easily build more sophisticated workflows and process driven applications than what you can do with Sharepoint out-of-the-box workflows, Sharepoint Designer, and Windows Workflow Foundation (WF).  It will also be an entry point for those wanting to test the waters with K2, and will provide an upgrade path to the more complete K2 blackpearl product offering.

The components you get with K2 blackpoint:

K2 Studio
K2 will be reintroducing the standalone designer concept that K2.net 2003 had with the new K2 Studio (which was previously blogged about and previewed).  There will be no dependency on having Visual Studio for constructing workflows.  The new K2 Studio provides an Office 2007 like application (complete with ribbon like interface) for dragging, dropping, and clicking workflow processes.

K2 Studio is targeted towards less developer-focused individuals, and will have very similar wizard driven steps for configuring the processes as in K2 blackpearl, but will not have the ability to drop into code or modify WF schedules.  Designing workflows will also include a set of stepwise Guides (which are extensible and customizable) for assisting the user in composing their workflows on the design surface.

Process Portals
K2 blackpoint will include Process Portal functionality (which was also previously previewed on K2 Underground).  This will take the place of the Workspace for the K2 blackpoint product, and will provide a set of Sharepoint web parts for centrally managing/monitoring/reporting on workflow processes.  You set up a Process Portal via Sharepoint Central Admin, and can either instantiate a new site, or extend an existing one.

Sharepoint Integration
As mentioned earlier, the primary drive behind K2 blackpoint is Sharepoint integration.  While K2 Studio will not have a specific SmartObject designer, you will have the ability to create SmartObjects from Sharepoint libraries and lists via Sharepoint menus.

These Sharepoint SmartObjects can then be consumed within processes authored in K2 Studio.  Other types of SmartObjects will not be accessbile, but you always have the option of integrating with line-of-business systems via web services.

Other points of Sharepoint integration include having all of the Sharepoint Event templates (e.g., Sharepoint Publishing, Sharepoint Lists Items, Sharepoint Search, etc.), integration with Sharepoint users and groups, integration with Sharepoint content types and workflows, and integration with Sharepoint events.

Other
Other functionality includes:

(*) Out-of-Office integration with Outlook/Exchange, allowing redirection of tasks
(*) Extensibility via ADO.NET data provider
(*) Extensibility of custom templates, wizards, etc.
(*) Out-of-the-box reports, and ability to customize SSRS reports
(*) Graphical representation of processes in progress
(*) Future release will include a Silverlight based design canvas in addition to the K2 Studio designer

Some notable exclusions:
(*) No BDC integration
(*) No built-in report designer

K2 blackpearl
As mentioned before, one of the goals with blackpoint is to serve as a starting point for those interested in the K2 products.  There will be an upgrade path available for moving from K2 blackpoint to K2 blackpearl.  All of the workflows authored in K2 Studio and running on the K2 blackpoint server should work as-is when moving to K2 blackpearl.  It should also be worth noting that the K2 Studio, Process Portals, Out-of-Office integration, etc. will be a part of K2 blackpearl releases.

More information on the product, the beta information, and pricing is available on the K2.com blackpoint page.

Delete InfoPath Form from Script Code

A pattern I’ve seen appear multiple times with InfoPath solutions is around having two document libraries store the forms.  One typically serves as a drafting area, and the other serves as an approved or archived area.  This is typically done when security requirements dictate having two separate access lists for each library.  At some point during the life of the form it needs to move from one library to another.  The key here is move.  You don’t want to find it in both places.  It’s pretty simple to set up two data connections for submitting an InfoPath form, and have rules or code dictate which connection to use for submittal.  However, there’s no out-of-the-box functions for removing the InfoPath form from a library it was previously saved to.

One solution to this problem is to use the Scripting.FileSystemObject.  This class has a DeleteFile method and can use a UNC path to the file in a Sharepoint library/folder to delete the file.  However, the FileSystemObject class comes from an ActiveX component which is not marked as ’safe for scripting’.  Best practices for InfoPath development indicate you should avoid referencing these types of components.  InfoPath relies on Internet Explorer security settings as part of its security model.  By default all zones (Internet, Intranet, local) except for Trusted Sites do not allow execution of unsafe ActiveX components.

An alternate solution is to use the XMLHTTP class.  This class comes from a component which is marked as safe, and uses HTTP to perform the delete operation (which is typically faster than the file system approach with FileSystemObject).  Below is a snippet of JScript code which demonstrates how to use this within InfoPath:

try
{
    // Get full URL of the current form
    var docUrl = XDocument.URI;
   
    // Create an xmlhttp object.
    var xmlHttp = new ActiveXObject(”MSXML2.XMLHTTP”);

    // Delete the Working area document.
    xmlHttp.Open(”DELETE”, docUrl, false);
    xmlHttp.Send();
}
catch (ex)
{}

Another approach a co-worker recommended was around using Sharepoint Designer to construct a workflow.  I like this idea because typically these solutions are based on a consistent workflow.  However, there are some downsides to this approach - including having to learn Designer, having “code” and logic in multiple places, and security around execution of the workflow.  I’m going to try and explore this option some more and will post some results.

Merge Documents View Missing

I’m not sure what I was doing with an InfoPath 2003 solution I was working on today, but somehow the “Merge Documents” view in the form library I published it to on a Sharepoint 2007 server disappeared. 

 

I double-checked the “Enable form merging” option within the Form Options of InfoPath, and it was checked. 

In fact, when opening a new instance of the form, the Merge Forms option was available.  The view was just missing from Sharepoint.

To resolve the issue I simply unchecked the option, published the form, then rechecked the option and published the form again.  The view then magically appeared.