Business Data Catalog Filters for SSRS Web Part

A couple of weeks ago a colleague asked me about web part filters in Sharepoint that could be used to drive context for other web parts on a page.  In particular, establishing context for SQL Server Reporting Services web parts. 

In our system in production today we have a set of custom ASP.NET web parts which get their context established from another custom web part.  For example we have a page which allows the user to select a particular portfolio, and a series of web parts on that page get populated with projects from that portfolio for different aspects they are interested in (projects with milestones that have recently been achieved, projects with milestones which have recently been pushed back/up, etc.).  It looks something like this (actual project names have been removed, and I’m only showing one of the child web parts on the page).

We happened to have tasks for the current sprint to replace some of these custom web parts with out-of-the-box web parts, so as to reduce the amount of code we’re supporting and utilize more of the features of the Microsoft SQL Server BI stack.  So I attempted to replicate this page with OOB web parts like the Business Data Catalog Filter web part for the portfolio selector, and SSRS reports and web parts for the other milestone web parts.

We already had a BDC app definition for the portfolios, and so dropping a BDC Filter web part on the page was easy.

The business also had a new requirement to be able to change the number of days used in the query.  So I added a Text Filter web part to the page.

Developing the new tables as SSRS reports was also very easy, and I dropped the SSRS Report Viewer web part on the page for the first report (Milestones Achieved).

Then it was a matter of connecting them up.  The BDC Filter web part had a connection option for sending the filter value to another web part – such as the SSRS Report Viewer web part on the page. 

When selecting this a dialog appeared asking which parameter from the SSRS report I wanted to hook up to.

The Text Filter web part was pretty similar.  This was hooked up, the page was published, and I took it for a spin.

It worked, however, it didn’t quite look and feel the way I had hoped.  In our custom web part we had the portfolio selector in the form of a drop down list.  Click the drop down arrow, pick a new item, and the page refreshes with the new context.  With the BDC Filter web part you are presented with the obtuse checkmark and book icons:

If you click the book icon, you get the familiar (if you’re familiar with Sharepoint and BDC that is) business data item picker dialog where you can search and pick a value. 

This is great if you have hundreds or thousands of items you need a person to choose from.  This is not so convenient if you only have a small handful of items that the user should be able to pick from a drop down list.  In the web part properties there appears to be a way to modify how the list is presented, but I only saw a single value of ‘Search dialog’ in the ‘Display list as’ field.

Perhaps something in the BDC app definition determines what options are possible here.  I will need to explore this a little more.

Note that manually typing in a value in the text field for the BDC filter does work fine, but you need to enter an exact match.  Not very nice for longer named list items.  Another option may be to use something like the Business Data List web part as a filter source.  But even then I don’t think you have an option to display items as a drop down list.

The Text Filter web part worked ok as well, but there are no options for controlling the type of text that can be entered.  For example, I’d like to restrict it to integer values only.  A different option here might be to use a Choice Filter web part and restrict the choices to something concrete like -30, -60, -90, etc.

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.