We are happy to announce that December Cumulative Update for Office SharePoint Server 2007 and Windows SharePoint Services 3.0 is available now. Beyond the fixes and improvements, this new update package is also an effort to create a more convenient way for SharePoint administrators to keep all files in their SharePoint installations up-to-date. In this post, we will guide you on how and when to update, and the background of this new update model improvement.

December Cumulative Update Steps & Suggestions

[IMPORTANT UPDATE 12/21: Please read the highlighted instructions below before starting your installation.] 

Customers do not need to install these updates unless they are affected by the specific problems described in the KB articles. These cumulative updates will be rolled in to Service Pack 2.

To keep all the files in a SharePoint installation up-to-date, we recommend that customers install updates in the following sequence:

1. Windows SharePoint Services 3.0 Service Pack 1

2. The 2007 Microsoft Office Servers Service Pack 1

3. December Cumulative Update for Windows SharePoint Services 3.0

4. December Cumulative Update for Microsoft Office Servers

After applying the preceding updates, run the SharePoint Products and Technologies Configuration Wizard or “psconfig –cmd upgrade –inplace b2b -wait” in command line. This needs to be done on every server in the farm with SharePoint installed.  The version of content databases should be 12.0.0.6335 after successfully applying these updates.

For more in-depth guidance for the update process, we recommend that customers refer to the following articles. These articles provide a correct way to deploy updates, identify known issues (and resolutions), and provide information about creating slipstream builds.

Deploy software updates for Windows SharePoint Services 3.0

http://technet.microsoft.com/en-us/library/cc288269.aspx

Deploy software updates for Office SharePoint Server 2007

http://technet.microsoft.com/en-us/library/cc263467.aspx

The detail of December Cumulative Update (CU) for Office SharePoint Server 2007 and Windows SharePoint Services 3.0 can be found here:

Description of the Windows SharePoint Services 3.0 cumulative update package: December 16, 2008 (The link will be active soon)

Description of the SharePoint Server 2007 cumulative update package: December 16, 2008 (The link will be active soon)

Background Information of the New Cumulative Update

The Microsoft Office team has heard your feedback around how hard it has been to manage which SharePoint cumulative updates you need to apply for your systems to be up-to-date.  We are pleased to announce that from this point forward each Cumulative Update will also consist of a package that contains the latest of every hotfix patch that we have shipped.   Consider a scenario where you want to build a new MOSS server.  You can apply the latest service pack, the latest WSS Cumulative Update package and the latest MOSS Cumulative Update package and be completely up-to-date.  However, while we recommend it, you are not required to install the latest service pack.  If you cannot install the latest service pack, we support installing a cumulative update on top of an older service pack that is still with-in lifecycle (For more information, see http://www.microsoft.com/lifecycle ). A few key points should be noted on the structure of the new update format:

• WSS continues to remain separate and is not included in the MOSS package
• All of the latest Global and Local patches for WSS are in the WSS package
• All of the latest Global and Local patches for MOSS (Excel Server, Document LifeCycle, etc are part of MOSS), InfoPath Forms Server, Project Server are in the Office Server package
• The list of what is in the package is an accumulation over time of what we have shipped since RTM
• The package includes the Infrastructure Update, there is no reason to install it separately.

Currently the WSS Cumulative Update contains (“x-none” means Global where a regional codes like “en-us” indicates Local):

Dw20w-x-none.msp

Sts-x-none.msp

Wssmui-en-us.msp (and every other language)

The MOSS Cumulative Update contains:

Coreserver-x-none.msp

Coreservermui-en-us.msp (and every other language)

Dlc-x-none.msp

Dlcmui-en-us.msp (and every other language)

Ifswfe-x-none.msp

Lpsrvwfe-x-none.msp

Msxml5s-x-none.msp

Pjsrvapp-x-none.msp

Pjsrvwfe-x-none.msp

Xlsrvapp-x-none.msp

Cumulative updates are scheduled for every two months, so customers can be better prepared to test and apply new updates. Any customer who needs an emergency fix can still request a critical on-demand (COD) fix. For information, please refer to http://support.microsoft.com/kb/953878.

We investigated the WSS Search error and resolved the problem.  If you are experiencing the WSS Search error, then please re-download the WSS package for 960010 and re-apply it.

Dan Winter

SharePoint Program Manager

Jie Li & Dave Pae

SharePoint Technical Product Manager

Today, we are excited to announce the release of the Web Services for Remote Portlets (WSRP) Toolkit for Office SharePoint Server 2007.  The WSRP Toolkit for SharePoint provides sample code for producing WSRP conformant data from SharePoint lists and libraries.  External portal platforms (e.g. BEA AquaLogic Portal, IBM WebSphere Portal, SAP NetWeaver Enterprise Portal etc.) can then render SharePoint data natively through their WSRP consumer portlets.  The Toolkit is available now for download from the MSDN Code Gallery.

The WSRP Toolkit for SharePoint consists of the following assets:

1. Visual Studio sample projects that demonstrate two different approaches to producing WSRP conformant output from SharePoint lists and libraries
2. A whitepaper that provides details on the different architectural approaches of the two WSRP producer samples
3. Screen casts showing the two WSRP producer samples in action

The Toolkit demonstrates two possible methods of exposing SharePoint data through the WSRP interface and is intended to provide a starting point for customers who are interested in surfacing SharePoint data in non Microsoft portal environments.  The first method focuses on maintaining high fidelity with the SharePoint user interface and the second method focuses on providing flexibility and control over the rendered output.  We are releasing the source code for the two methods under the Microsoft Public License (Ms-PL), allowing developers to customize the solution to meet their specific requirements.

Here is a screen shot of the WSRP Toolkit in action:

And here are two screen casts of the configuration of the two WSRP samples:

Of course WSRP is just one of many options available to support portal interoperability and Microsoft continues to invest in open standards for interoperability including XML based web services, CMIS, Office Open XML, RSS and REST.  Microsoft is also investing heavily in Silverlight, designed to deliver rich user experiences and applications across multiple platforms.  For more details on the SharePoint interoperability story, visit the TechNet Office SharePoint Server Interoperability TechCenter.

Ryan Duguid
Technical Product Manager
Microsoft Corp

Yesterday, we released a security bulletin summary for December 2008.  Within the bulletin summary, you will find Microsoft Security Bulletin MS08-077 which is a security update that resolves a privately reported vulnerability.  This security update is rated as important and addresses the elevation of privilege if an attacker bypasses authentication by browsing to an administrative URL on a SharePoint site.   The affected products are SharePoint Server 2007 and Search Server 2008.  The security update was included within the October Cumulative Update so for those that have not applied the October CU, we recommend  applying this security update at the earliest opportunity.  Finally, we are planning to include this security update in Service Pack 2.  Please follow best practices by testing and also make sure you have a recoverable backup of your environment before final deployment.

Jie Li & Dave Pae
SharePoint Technical Product Manager

Microsoft IT works to address the needs of a large and demanding business organization.  They are asked to implement and support systems that cover core business functions (computers, networks, security, etc.) all the way to advanced technologies that grow and drive a global business.  SharePoint is one of the business systems that is globally available internally and externally at Microsoft. 

On 1/27/2009, Jad Honein, Microsoft IT Software Development Engineer, will host a TechNet Webcast on "How Microsoft Does IT: Designing, Developing, and Deploying SharePoint Server 2007 Publishing Portals."  If you are interested in attending this event, then you can register here.

Dave Pae
SharePoint Technical Product Manager

I was looking at my Outlook calendar and wanted to share some of the larger conferences scheduled in the upcoming months.  As we get into the Spring, I'll update the community with an updated list.

Cheers!

Dave Pae
SharePoint Technical Product Manager

SharePoint Technology Conference
January 27–29, 2009: Burlingame, CA
For three exciting days in January, you'll be eating, drinking, sleeping, talking and living Microsoft Office SharePoint Server and Windows SharePoint Services. The first day at SPTechCon is filled with intense full and half-day workshops, half in the morning, half in the afternoon. The next two days are filled with more than 50 break-out classes to choose from. Build your own custom program! This conference is hosted by BZ Media LLC. 

SharePoint Best Practices Conference
February 2–4, 2009: San Diego, CA
The SharePoint Best Practices Conference eliminates design, deploy, organization and administration confusion, replacing disorder with Clarity, Direction and Confidence.  This conference is hosted by Mindsharp. 

Microsoft FASTforward '09
February 9–11, 2009: Las Vegas, NV
3 days of compelling discussion on the evolving business environment and how search is enabling companies to succeed.  This conference is hosted by Microsoft.

Microsoft MIX09
March 18-20, 2009: Las Vegas, NV
Now in its fourth year, MIX is a unique technology conference that connects web professionals with industry thought leaders to explore the future of the Web together.  This conference is hosted by Microsoft.

Microsoft Tech Ed North America 2009
May 11-15, 2009: Los Angeles, CA
This will be the 17th year for Microsoft's premier technical education and networking conference.  Sessions and events are presented by Microsoft product team members and industry experts.  This conference is hosted by Microsoft.

I'd like to introduce today's guest blogger - Mike Fitzmaurice, ex-Microsoft SharePoint Product Manager and currently the Vice-President of Product Technology at Nintex.  As a Microsoft Gold Partner, Nintex aligns with Microsoft's strategic and architectural direction to develop products on the SharePoint platform. 

A common request for many SharePoint deployments is to provide more advanced reporting about a SharePoint farm than what is currently available out-of-box.  For today's blog, Mike explains the reporting needs and then dives into how Nintex Reporting works by providing insight into their technical approach and rational around a few of their design decisions such as using SQL Server's data warehousing capabilities to incorporating Silverlight into their web parts.  I hope Mike's article helps you to envision solutions that can be built on the SharePoint platform.  So over to Mike...

Dave Pae
SharePoint Technical Product Manager

How We Did It: Nintex Reporting

The name indeed merits a moment of clarification: Nintex Reporting is all about content/collaboration analytics reports for anyone who owns/manages any SharePoint assets.  It’s reporting about SharePoint farms, not reporting for SharePoint farms.  Nintex Reporting will tell you things like:

1. The size of your site collections, sites, lists, and libraries
2. Which documents are being viewed/downloaded/edited/checked out, etc.
3. Relative amounts of activity at different points of the day/week/month/year, broken down by type of activity if desired
4. What content you have in your document libraries, broken down by file type, content type, etc.
5. Which features have been activated in which sites
6. How content is distributed across content databases
7. Which discussion boards (or which lists of any kind) are being regularly used
8. Which users are contributing list content and/or authoring document/page content
9. Which documents have been checked out for a long period of time.
10. Which sites have gone unused for too long
11. Who’s using search, which queries are being run, and from which scopes
12. How often content is viewed vs. updated

It’s actually a long list.  There are 75+ reports in the box, many of which have drill-down report definitions.  And if you want to just install it and use it, go for it – it’s designed for a happy experience that way.

But it’s how it works that we think is interesting, and on the assumption that you’d find that interesting as well…

Background

Remember a while back when Mike Fitzmaurice warned people to stay out of SharePoint configuration and content databases? Part of the feedback received was “but I need to be able to report on what’s going on in my SharePoint farm”.  It’s a legitimate issue. If you’re not querying the database, the remaining option is to query the object model, a la SPSReport, not that such a technique is fast or prone to a lot of ad-hoc examination and analysis.

There’s a better way that combines the best of both worlds, and that’s Nintex Reporting.  The process, upon which we’ll elaborate in a moment, goes like this:

1. Collectors crawl the SharePoint object model regularly and log what they find to a data warehouse.
2. The data warehouse holds information collected in an easy-to-query ROLAP schema (snowflaked dimensions and multiple fact tables, to be exact).
3. A data management service runs reports on a scheduled basis and saves their results to a result cache database.  This lets us build up a set of report results that can be quickly retrieved over and over again without having to rerun the query every time.
4. The user interface, a custom SharePoint site application that makes heavy use of Web Parts containing custom Silverlight controls, queries and displays data from the result cache (most of the time) and the data warehouse itself (when someone wants to re-run a report and/or drill down into the details).

Philosophically, the collectors (one for the SharePoint object model and one for Windows Performance Monitor counters) are the only things that really come in contact with a SharePoint farm.  Everything else is out of band; even the UI is essentially a SharePoint site with Web Parts that query a database.

So let’s look at each of these building blocks in turn…

Collectors

These are lightweight, managed code services that run on one or more Web front ends (WFEs) in a SharePoint farm.  We’ve created a standard API for writing collectors, and we ship with two of them, one for Performance Monitor counter data, and one for collecting data from the SharePoint object model.

The SharePoint Collector, on a throttle-able schedule, navigates through the SharePoint farm hierarchy to inventory every web application, site collection, site, list/library, and item/document.  Whatever it finds, it logs into the data warehouse.

Structure and content are easy, but what about activity?  Well, as it turns out, the only way to get truly useful activity info is to activate the auditing policy on lists/libraries for which you want activity data.  Even if you only have Windows SharePoint Services, auditing policies are there; there’s just no exposed UI to get to them.  We can turn on auditing everywhere programmatically.  We can even prune the audit logs as we harvest data from them to keep content databases from filling up.

We looked at plenty of alternatives – this is the one that provided the most useful data with the least risk of negative impact.  For example:

• Culling the IIS logs won’t tell you much about what’s happening.  You’ll know what is happening to (if it’s a page or a document), but you won’t really know what’s going on.  IIS logs cannot distinguish between draft save, check-in, or document publish activities.  Almost nothing but auditing can.
• Sticking a JavaScript token into every page isn’t an option for SharePoint assets that aren’t pages (e.g., documents), plus we’d prefer not to require users to modify every master page.  Plus, oftentimes it’s not about pages; when you’re editing a task list item, what’s the salient thing you want to measure, the fact that are you changing an item or the fact that you’re posting a page?
• Writing a HTTP Handler could work, but that would be extra intrusive and potentially destabilizing.  One should not tread lightly down this path.
• Culling the output from WSS/MOSS usage analysis processing was an option we also considered, and would have used but for the fact that (a) there’s some information it doesn’t provide, and (b) it pre-aggregates too much information, leaving us without raw data to slice/dice by user, by type of request, etc.

Trumping all of this is the fact that auditing might well already be turned on to address compliance concerns, and in such scenarios Nintex Reporting represents zero additional overhead.  Moreover, Microsoft has already done what it can to minimize the impact of auditing policies on a farm’s behavior (it’s non-zero, to be sure, but all techniques are non-zero).

Collectors log gathered facts directly to the data warehouse database.  If collectors are installed on multiple Web Front Ends, they make use of semaphore-like information in the warehouse to ensure that no two collectors grab the same data.

Finally, you can have the collectors ignore certain kinds of activity (e.g., the MOSS search gatherer, the portal administrator) and certain kinds of content (e.g., CSS files).

Data Warehouse

Nintex Reporting actually makes use of two databases, one purely for storing the actual data warehouse data, and another database for everything else, which includes configuration data and cached results of previously-run reports.

The data warehouse revolves around three kinds of fact tables, specifically devoted to performance monitor counters, search executions, and content audit events.  List Items/Documents are actually a dimension table, although when it comes to reports about content or structure (as opposed to activity), they behave like a de facto fact table.

In addition, a report (which should actually be thought of as a report definition) is actually a SQL Server stored procedure.  To make authoring/compilation a bit easier, we keep these reports in the data warehouse database as well.

Actually, there’s just a little bit more data in the warehouse to help the collector services as well, primarily a place to read/post collection information so multiple collectors don’t attempt to collect the same data.  It’s kept in this database so the collectors only need to maintain one database connection.

Configuration/Cache Databases

The configuration/caching database is responsible for, well, everything else.  It holds the set of report schedules (which report to run on which day at which time with which parameters), the access control lists that determine which users can view/edit/execute which report schedules, layout information for formatting dashboard statistics, subscription information, and a lot more.

Of extreme importance is the presence of one output cache table for every report definition.  When scheduled (as opposed to ad-hoc) reports are executed by the data management service, their results are redirected into these output cache tables so they can be quickly retrieved as needed without having to rerun the entire report.  It also allows one to rummage through the entire history of results from previous executions.

Data Management Service

The Data Management Service is responsible for checking the report execution schedule and running reports as needed. It also maintains the data warehouse and config/cache databases, purging old warehouse data and/or report results according to administrator preferences.

While the Data Management service could be installed on any machine, the work it does is out of band from standard user requests. As such, we recommend that it be installed on whichever machine you have running WSS/MOSS timer jobs and other scheduled tasks.

User Interface

There are three key parts to the Nintex Reporting interface, a single report view, a dashboard (which shows several reports at once), and the administrative UI. We deliver these inside of a Nintex Reporting SharePoint site, which you can create in the location of your choice.

The view of a single-report schedule (again, one report definition may have many schedules, each with its own parameters, execution frequency, and permissions) is made up of four Web Parts, and looks like this:

What you’re seeing above consists of Web Parts that display (1) the schedule’s parameters and execution history (in case you want to see results from an earlier point in time), (2) the Silverlight-based graphical view of the report, (3) the tabular view of that same data, and (4) possible actions that can be performed on the report (e.g., run now, edit schedule, export to PDF or Excel, subscribe).

The Web Parts are capable of retrieving their data independently of each other, but they’re connectable, and by default receive info on which set of report results to retrieve from Web Part 1 in the above figure (Parameters/Archived Reports). When multiple parts on a page attempt to retrieve data, they will make use of pooled/cached Object Data Sources whenever possible.

The graphical Web Parts make use of Silverlight 1.0 controls of our own creation, which retrieve data by calling an ASP.NET page that returns ready-to-load XAML data from the aforementioned Object Data Source. We opted for Silverlight because it allowed us to build a rich, interactive visualization method that would scale down to WSS and up to MOSS with one codebase, leverage our .NET development skills in the process, and allowed us to offload graphics processing to the browser to keep the load on the server down. We didn’t look at more recent versions of Silverlight because they weren’t shipping at the time.

Dashboard pages employ a set of graphical Web Parts, so while each makes use of an Object Data Source for retrieving/caching data, there will be more data being retrieved/cached for a dashboard page than a single-report page.

We keep track of which report schedules are being displayed in which dashboard, in case a user wishes to subscribe to a dashboard as opposed to an individual report. Subscription checking/notifications, by the way, are handled by a custom SharePoint Scheduled Task job.

Delivering the UI in a Nintex Report Center site serves two purposes. First of all, it puts all of the elements into a single location for navigation, configuration, etc. Second of all, it allows administrators to secure reports by only allowing specific users/groups of that site to edit/run/view specific report schedules. We needed to make use of SharePoint users/groups because we didn’t want to depend on an Active Directory-integrated security model being in effect.

Any and all report schedules can be viewed in Web Parts placed in any other site in any other site collection (e.g., a user’s My Site), but the report schedule will still be subject to the permissions assigned to it in the Nintex Reporting site.

Summary and Upcoming Developments

The goal of Nintex Reporting is to ensure that users get the most information possible as responsively as possible with the lowest impact on IT-managed resources as possible. It’s business intelligence technology applied to content/usage analytics for collaborative content.

What’s particularly significant is that it treats a SharePoint farm as something special. SharePoint sites are not just a set of Web pages, but rather a set of collaborative assets (Web content management sites are both, and we’ll get to that in a moment). What’s more important, a page that renders list items or the items themselves? The solution delivered in the box focuses on the latter case, although the architecture of Nintex Reporting allows both.

We’re delighted to have the product in the marketplace, but we’re by no means resting. In the months to come, Nintex will be focused on three key areas of innovation for Nintex Reporting:

Software Development Kit. This should be ready very, very shortly, actually. It will be primarily focused on showing interested parties how to add new and modify existing report definitions to meet their needs. It will include thorough descriptions of our data warehouse so you’ll know what data is available to be queried, and several examples of custom reports. SQL Server stored procedure development skills will be needed to do this, but new reports can be exported to XML and imported elsewhere, allowing for build-test-deploy scenarios.

Updates to the SDK will include how to create custom collectors to populate the warehouse with entirely new kinds of data, as well as examples of how to make use of the warehouse with SQL Server Analysis Services and Reporting Services.

Per-Item Usage Inspection. Most of our ready-to-use reports support being able to drill down into individual activities for inspection purposes, but this will bring the capability down into individual documents, list items, etc. The data for this already exists; this is strictly an addition to the UI to make more of the data warehouse investment.

Automatic Provisioning of Site-Specific Reports. It’s already possible to create report schedules scoped to specific sites, as well as being able to create new Web Part pages in those sites that contain Web Parts that display those report schedules. This will allow the reports to be provisioned and the page to be added to the affected site in one action (activating a feature on that site). It will make it much easier for IT to be able to offer a set of Nintex Reports as a service to individual site owners.

Reporting on Site/List/Item Security. We do not yet report on permission changes (although they are captured by auditing and can be placed in our warehouse), but an update in the medium term will introduce such reports to our repertoire, as well as reports on who can do what with which sites/lists/items.

Reporting on Web Page Analytics. The above comment about paying attention to what SharePoint sites contain rather than how the application renders it remains true, but Web publishing sites are a separate case. We are at work on an alternate means of gathering usage data for such sites that will be more in line with other Web analytic solutions so Nintex Reporting users will be able to look at page hits, click-through's, etc. Because of the separation of collection from data warehousing from report generation from presentation, however, this is likely to be a matter of a new custom collector as opposed to a radical enhancement to the product’s design.

We actually think you’ll still want to use both the current means of audit-based activity collection for sites where content is authored, edited, and prepared for testing. The combination of approaches will give you a picture into, for example, who’s developing content (which we already do) and how much of that content is being read by the public (which classic Web analytic products do now and we’ll do relatively soon).

Longer-term, we’ll look at taking further advantage of the data warehouse to create entirely new solutions leveraging data mining technology. Compliance monitoring, threshold-based alerts, and administrative actions triggered by observed patterns are all scenarios to which the architecture lends itself – but that’s a story for another time.

How We Did It – Automating Service Requests using InfoPath Forms Services

Overview

Today's guest blog post is from ThreeWill, a Microsoft Managed Gold Partner located in Alpharetta, Georgia that focuses on SharePoint development and integration. ThreeWill recently worked with Microsoft to build a generic Service Request Office Business Application (OBA) using InfoPath Forms Services. The application addresses the need for enterprises to have a no-code way to quickly turn around service request based SharePoint sites (i.e. sites that are using electronic forms to initiate a request and tie that request to a workflow).

Some Service Request examples are:

• Request for Marketing Funds
• Request for Laptops or other equipment
• Request for Project Site Creation

The solution is packaged up as a SharePoint Feature to enable deployment to a Server Farm and standard SharePoint provisioning. The application supports integration with Active Directory to pre-populate user information and provides easy access to Web Services from InfoPath using Data Connections. Finally, configuration information is stored in a SharePoint List for secure yet convenient access to Site Administrators.  Over to ThreeWill on how they did it.

Pej Javaheri, SharePoint Product Manager.

In Figure 1 you see the home page for the site. As you can see from in the Quick Launch navigation, users can create, edit, and view requests. This enables self service applications that can be easily configured for a multitude of purposes.

Figure 1 – Home Page for the Service Request Application

Core Usability Features

One of the main goals for the project was to make some key changes to standard InfoPath Forms behavior to improve the user’s experience. For example, when you go to create a request from the “Create Request” link in the Quick Launch navigation, it brings you to the “Create/Edit Request” page with the InfoPath Form embedded as a Web Part Page.  When the user saves the request, it is saved with an auto-generated name and the user is brought back to the Home page of the Service Request site. These “tweaks” to the interaction with the Form improved the overall user experience of the site.

To implement these features, the team wrapped an instance of the XML Form Viewer in a Web Part.

To apply the standard naming convention we overrode the SubmitToHost event to save the form with a naming convention based on the user name and the current time.

void _xmlFormViewControl_SubmitToHost(object sender, SubmitToHostEventArgs e)

{

const string formLibraryName = "Requests";

SPWeb currentWeb = SPContext.Current.Web;

// Get the contents of the form and put them into a byte array

XPathNavigator nav = _xmlFormViewControl.XmlForm.MainDataSource.CreateNavigator();

System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();

byte[] contents = enc.GetBytes(nav.OuterXml);

//load in the xml document so we can extract out fields by name

XmlDocument xmlDocument = new XmlDocument();

xmlDocument.LoadXml(nav.OuterXml);

Dictionary<string, ArrayList> documentFields = Utility.GetNameValuePairs(xmlDocument);

//retrieve InfoPath form keys from the Configuration list

Dictionary<string, string> configuration = Utility.GetConfiguration(SPContext.Current.Web);

string [] formKeyFields = string.IsNullOrEmpty (configuration[Utility.ConstInfoPathFormKeysParameterColumn])?

new string [0]:

configuration[Utility.ConstInfoPathFormKeysParameterColumn].Split(',');

//begin to build the filename

string filename = "";

//iterate through each form key field

foreach (string formKeyField in formKeyFields)

{

//if the form key field is found in the InfoPath form, add it to the filename

if (documentFields.ContainsKey(formKeyField.Trim().ToUpper()))

{

foreach (string fieldValue in documentFields[formKeyField.Trim().ToUpper()])

{

filename += fieldValue;

filename += "_";

}

}

}

//name files using the user name and date if the infopath form keys could not be found

if (string.IsNullOrEmpty(filename))

{

filename = SPEncode.UrlEncode(currentWeb.CurrentUser.Name.Replace('\\', '-')) + "_" + DateTime.Now.ToString("yyyyMMdd_hhmmss") + ".xml";

}

else

{

//trim any training underscores, add the file extension

filename = SPEncode.UrlEncode(filename.Trim(new char[] { '_' })) + ".xml";

}

// Determine the URL of the new file

string saveUrl = currentWeb.Url + "/" + formLibraryName + "/" + filename;

// open document library as a folder

SPFolder docLibFolder = currentWeb.GetFolder(formLibraryName);

// Save the form by adding its contents to the document library

if (string.IsNullOrEmpty (_xmlLocation) == false && docLibFolder.Files[_xmlLocation] != null)

docLibFolder.Files[_xmlLocation].SaveBinary(contents);

else

docLibFolder.Files.Add(saveUrl, contents);

}

The Close event is where we handled sending the user back to the home page.

void _xmlFormViewControl_Close(object sender, EventArgs e)

{

// Inspect the QueryString

if (this.Page.Request.QueryString["Source"] != null)

{

SPUtility.Redirect("", SPRedirectFlags.UseSource, this.Context);

}

else

{

SPUtility.Redirect(SPContext.Current.Web.Url + "/default.aspx", SPRedirectFlags.CheckUrl, this.Context);

}

}

Also, the “Edit My Request” link included some usability improvements. When a user clicks this link and they have only one request for the site, that request is loaded. If they have no requests, it is like creating a new request. And if they have multiple requests they are brought to the list of requests. A Service Request Redirector class was created to handle these cases.

public class ServiceRequestRedirector : LayoutsPageBase

{

private const string FORMS_LIST_NAME = "Requests";

private const string QUERY_DEF = "<Where><Or><Eq><FieldRef Name='Author'/><Value Type='User'>{0}</Value></Eq><Eq><FieldRef Name='Editor'/><Value Type='User'>{0}</Value></Eq></Or></Where>";

protected override void OnLoad(EventArgs e)

{

// get current site, web and user

SPSite siteCollection = this.Site;

SPWeb site = this.Web;

SPUser currentUser = site.CurrentUser;

//get list of fields to return "<Where><Or><Eq><FieldRef Name='Author'/><Value Type='User'>{0}</Value></Eq><Eq><FieldRef Name='Editor'/><Value Type='User'>{0}</Value></Eq></Or></Where>"

string viewFields = GetViewFields();

//build the query string for querying the Request list

//to retrieve any item created or modified by the current user

string requestQueryFields = string.Format(QUERY_DEF, currentUser.Name);

string redirectUrl = default(string);

try

{

SPListCollection lists = site.Lists;

SPList timesheetList = site.Lists[FORMS_LIST_NAME];

SPQuery requestQuery = new SPQuery();

requestQuery.ViewFields = viewFields;

requestQuery.Query = requestQueryFields;

SPListItemCollection listItems = timesheetList.GetItems(requestQuery);

if (listItems.Count == 0)

{

redirectUrl = site.Url + "/SitePages/norequests.aspx";

}

if (listItems.Count == 1)

{

string url = Request.RawUrl;

redirectUrl = site.Url + "/SitePages/editrequest.aspx?XmlLocation=" + site.Url + "/Requests/" + SPEncode.UrlEncode(listItems[0].Title) + "&Source=" + SPEncode.UrlEncode(site.Url + "/default.aspx");

}

if (listItems.Count > 1)

{

try

{

if (Request.QueryString["Title"].ToString() != "")

{

redirectUrl = site.Url + "/SitePages/editrequest.aspx?XmlLocation=" + site.Url + "/Requests/" + Request.QueryString["Title"] + "&Source=" + SPEncode.UrlEncode(site.Url + "/default.aspx");

}

}

catch (System.ArgumentOutOfRangeException)

{

//no Title in QueryString, just continue to display all items

redirectUrl = site.Url + "/Requests/Forms/MyItems.aspx";

}

catch (Exception ex)

{

//no Title in QueryString, just continue to display all items

redirectUrl = site.Url + "/Requests/Forms/MyItems.aspx";

}

}

}

catch (SPException spe)

{

System.Diagnostics.Debug.Print(spe.Message);

}

//redirect to the correct page for the number of requests

SPUtility.Redirect(redirectUrl, SPRedirectFlags.CheckUrl, HttpContext.Current);

}

Other Key Features Implemented

The solution also included the provisioning of reusable web services that are consumed through Data Connections in InfoPath and a SharePoint Designer Custom Action.  Therefore, the Site Designer just needs to know how to use InfoPath to design some pretty sophisticated forms.

Some web service features are:

1. Connection to AD to pre-populate user profile information into a form based on the logged in user
2. Retrieve SharePoint Group (if available) - used to simulate “role-based” functionality in a browser-enabled form.
3. Cascading Filtering of List based data – allowing users to consume list data that is related by master/child relationship (e.g. State drop down driving the automatic filtering of a City drop down)

SharePoint Custom Actions included a new custom action in SharePoint Designer (runtime approvers) that provides the SharePoint Approval workflow with the list of approvers at run-time.

Form is pre-populated with information from Active Directory

User can select item in drop down list and other fields are updated based on that selection

Form can show master/child relationships

Figure 2 - Create/Edit Service Request Example

We had some key lessons learned when simplifying these services. Kirk ran into a gotcha when accessing a web service with anonymous access and trying to work with the current user. We also learned more about registering a Windows SharePoint Services 3.0 Hosted Web Service on the project and Pete followed up with a blog post to address the problem. Also, because some SharePoint web service calls do not have well defined schema for input and output parameters and/or the input/output schema is not easily consumed by tools such as InfoPath, we created a simplified Web Service class.

private SPList GetList(SPWeb site, string listName)

{

// Get the list

SPList list = null;

try

{

list = site.Lists[listName];

}

catch (Exception ex)

{

throw new Exception(String.Format("List [{0}] does not exist within site [{1}].", listName, site.Url), ex);

}

return list;

}

private List<ListItem> ExecuteQuery(SPList list, SPQuery spQuery, string fields, bool unique)

{

// Run the query

SPListItemCollection items = null;

try

{

items = list.GetItems(spQuery);

}

catch (Exception ex)

{

throw new Exception("Unable to execute query.", ex);

}

// Turn the output into our format

List<ListItem> response = new List<ListItem>();

Dictionary<String, String> uniqueItems = new Dictionary<String, String>();

foreach (SPListItem item in items)

{

StringBuilder uniqueSb = new StringBuilder();

// Populate a response item

ListItem responseItem = new ListItem();

responseItem.ID = item.ID;

responseItem.Title = item.Title;

responseItem.Fields = new List<Field>();

// Populate the fields for the response

foreach (string field in fields.Split(','))

{

string fieldName = field.Trim();

if (!item.Fields.ContainsField(fieldName))

{

throw new Exception(String.Format("Field [{0}] does not exist within list [{1}].", fieldName, list.Title));

}

Field responseField = new Field();

responseField.Name = fieldName;

object fieldValue = item[fieldName];

responseField.Value = (fieldValue != null ? fieldValue.ToString() : String.Empty);

responseItem.Fields.Add(responseField);

// Keep track of a unique key if we care about uniqueness

if (unique)

{

uniqueSb.Append(responseField.Value).Append('\0');

}

}

// Include the list item in the responses

// But don't include it if the user requested unique values and this item is not unique

if (!unique)

{

response.Add(responseItem);

}

else

{

string uniqueKey = uniqueSb.ToString();

if (!uniqueItems.ContainsKey(uniqueKey))

{

response.Add(responseItem);

uniqueItems.Add(uniqueKey, null);

}

}

}

return response;

}

List Based Configuration

To simplify administration of the sites the configuration is stored in a SharePoint list that is only accessible to the Site Administrator. The configuration parameters are stored as name/value pairs and allow the Site Administrator convenient access to configuration data through the familiar SharePoint interface.

Figure 3 - Configuration of Service Request Application

Summary

The benefit of this solution is an enterprise class Services Request application that requires no coding and can be configured for a number of purposes. The application has a number of key usability enhancements like auto generating form names and simplifying the process of working with forms. You can easily build the forms for the application using InfoPath and there are a number of key services that you can use like pre-populating information from Active Directory or building forms based on SharePoint list data. Configuration information for the application is stored in a SharePoint list to make it easy and secure to access.

Project Team Members

The team members who worked on this project included Pete Skelly, Eric Bowden, Kirk Liemohn, Chris Edwards, and Jerry Rasmussen. We would also like to thank Donna Hodges of Microsoft for her innovative enthusiasm to drive the concepts behind this project to reality. Finally, we want to thank Kern Sutton from Microsoft who was the business liaison that helped refine the business requirements and ensured that the necessary resources from the client and Microsoft were provided to effectively solve the business problem.

About the Authors

Pete Skelly – Pete is a Senior Consultant with ThreeWill. Pete is certified as a MCSD using Microsoft .NET, a MCTS: SharePoint Services 3.0, Application Development and is a Certified Scrum Master. Pete would prefer to play golf for a living, but playing with his two sons and paying bills always seem to get in the way.

Eric Bowden – Eric is a Senior Consultant with ThreeWill and enjoys recreational running (yes, there is such a thing), camping, outdoors with family, and optimizing commute times. Eric is certified as an MCSD as well but don’t let that fool you, he’s actually a strong coder with mad SharePoint developer skills.

Danny Ryan - Danny is a co-founder of ThreeWill and enjoys chasing his two little girls around the house when he is not talking to enterprises about how SharePoint slices bread. Danny writes a monthly newsletter, called SharePoint for the Enterprise, which covers key topics about successfully building “enterprise class” SharePoint applications – http://www.threewill.com/newsletter/ .

The SPSite and SPWeb Dispose() methods are an important thing for developers who work with Microsoft SharePoint Products and Technologies to master. Many SharePoint API's allocate COM based memory that is not released by CLR garbage collection and must be released by calling the Dispose() methods. Microsoft Guidance for when to call SPSite and SPWeb Dispose() methods have been published in this MSDN whitepaper by Mike Ammerlaan and Scott Harris. In addition, Roger Lamb has provided additional detail and discussion on his MSDN SharePoint Developer blog. This guidance applies only to customers building custom software that they compiled to .NET assemblies that make use of SharePoint API calls.  Also, an update to the MSDN whitepaper is being planned to reflect key guidance from the blogs.

Microsoft wants to help developers build better quality code that manages available memory better. We are now building a console tool that will help to evaluate customer code against the guidance that is provided. The tool, called SPDisposeCheck, will open your custom compiled assemblies recursively and validate them against the Microsoft published guidance. The output from the tool will contain messages that may indicate the SPSite and SPWeb Dispose() methods guidance are not being followed in the customers source code. While these messages need expert evaluation in order to determine if the software is not performing properly, in some cases just running the tool on your custom code can lead you to simple fixes that improve the quality and performance of custom code on SharePoint. This tool is planned for release during the coming North American Winter.  Customers who are currently experiencing difficulties with memory management in their custom applications should review the guidance listed above.  Customers who are currently experiencing difficulties with Microsoft Office SharePoint Server 2007 should contact their regular Microsoft Customer Support Services contact, or refer to http://support.microsoft.com.

References:

Best Practices: Using Disposable Windows SharePoint Services Objects

Best Practices: Common Coding Issues When Using the SharePoint Object Model

Roger Lamb's SharePoint Developer Blog

Last week, the Microsoft User Research team reached out to me regarding a set of studies they were planning to execute in the upcoming months.  In a nutshell, the team focuses on how people interact with hardware and software products; and then the information and feedback gathered is translated directly into product improvements.  For their next series of studies, they are looking for individuals who use SharePoint at least once a week.

The studies will be held at the Microsoft campus in Redmond, WA so they are looking for participants in the Puget Sound area. 

If you are interested please email itusable@microsoft.com with your contact information and insert SharePoint into the subject line.

This week at TechEd EMEA in Barcelona,  Jason Zander, the GM for Visual Studio, announced and demonstrated the Visual Studio 2010 tools for SharePoint.  Here's a quick summary of what he showed:

• Server Explorer for SharePoint viewing Lists and other artifacts in SharePoint directly inside of Visual Studio

• Windows SharePoint Services Project (WSP file) Import to create a new solution

• Added a new web part project item and showed the Visual web part designer which loads a user control as a web part for SharePoint

• Showed adding an event receiver for SharePoint and using the wizard to choose the event receiver and to just create a source file with that event receiver.

• Added an ASPX workflow initiation form to a workflow project and showed how this workflow initiation form has designer capability

• Showed the packaging explorer and the packaging editor which lets you structure the SharePoint features and WSP file that is created

You can learn more on Channel9 and the Visual Studio 2010 homepage.

Last week at IT Forum in Barcelona, we announced the Microsoft Certified Master (MCM) for Office SharePoint Server 2007 and the Microsoft Certified Architect (MCA) for Office SharePoint Server 2007.

The Master program is designed to be the top-tier technical certification for SharePoint Products and Technologies for years to come. The goal of the MCM is to provide a means for training, recognizing, and developing the top SharePoint technical experts in the world. Specifically, the MCM is intended for technical professionals whose primary responsibilities include designing, building, configuring, deploying, and supporting large, often complex, MOSS 2007 environments.

Building on the MCM, the MCA certification is designed for professionals who possess an additional skill set focused on the larger business strategies and technical architecture as a whole. This skill set includes the ability to communicate with business and technology leaders, to understand the customer’s current and long-term organizational and technical needs, and to design a solution to meet those needs. To receive the MCA for SharePoint, students must first graduate from the MCM for SharePoint program and will then have the option of sitting for a comprehensive Review Board interview conducted by Microsoft experts and MCA’s.

If you feel you have the skills and experience to excel in this program, and are interested in being one of the first SharePoint Masters and/or MCA’s, I’d encourage you to visit the the MCM homepage for additional detail and prerequisites for the program.  We are accepting applications into the program here.

Overview

Today’s guest blog post is from ThreeWill, a Microsoft Managed Gold Partner located in Alpharetta, Georgia that focuses on SharePoint development and integration. You might remember them from a previous article about the SharePoint Connector for Confluence. They worked with Microsoft on a recent project to extend some of the features of SSRS Web Parts to meet the needs of the enterprise.

In this project, ThreeWill helped a large telecommunications organization address their concern of being bound to one SSRS Reporting Server with the web parts. This concern was primarily because they did not have the luxury of combining all reports into one scaled SSRS environment. Of course, like so many other projects, the client needed a solution today, not months from now… this article has the details behind what they did on a week by week basis. Over to ThreeWill.

Pej Javaheri, SharePoint Product Manager.

First, a little bit more background. The core requirements of the solution were to enable SSRS web parts in SharePoint Server 2007 to point to multiple SSRS environments, a capability available in SSRS web parts for SharePoint 2003, with parameterization capability with the filter framework in SharePoint Server 2007. In essence, combine the best qualities of SSRS web parts from 2003 with 2007, as well ensuring usability was easy for end-users with minimal or no training required.  Here’s how we did it and our approach.

Week 1

Getting Started

The obvious starting point for the project was to evaluate existing SSRS Web Parts available from Microsoft. We took a look at the v2 and v3 SSRS Web Parts available for SharePoint. We had a technology spike to determine whether to extend or rewrite either version of the Web Parts. After discussing the options with the SQL Server Product Team, we decided to implement two new Web Parts that use a similar design pattern used by the v2 Web Parts. From that foundation, we added additional features like managing Reporting Parameters either through the Web Part Editor or through Web Part Connections. Below is a comparison of the existing SSRS Web Parts compared to what was custom built.

The objective of the project was to build the following Web Parts:

• Report Explorer (Top Web Part) - allows you to browse existing reports on a SSRS Server and eventually select a report that is passed to the Report Viewer
• Report Viewer (Bottom Web Part) - allows you to display a preconfigured report (or a report determined at runtime through Web Part Connections).

Requirements Baseline

Due to budget and timeline, we had to make a judgment of what was appropriate to reuse from the architecture of SSRS and the existing SSRS Web Parts. We found the architecture of the v2 Web Parts were the best place to start to allow for code reuse and connection to multiple servers. The v2 Web Parts leverage the use of IFrames to an ASPX page hosted on the SSRS Server. This allowed the end user’s security credentials to pass through from the browser to the Report Server vs. a double hop through custom code in the Web Part. This also saved time with not having to recreate the UI elements and behaviors needed for a Report Explorer and Viewer. We extended the v2 capabilities in the Report Viewer by giving support for report parameters through Web Part Properties. The properties for the parameters leveraged the Web Services interface of the Report Server to, at runtime, render labels and controls for each available parameter on the report. By the end of the first week we finalized the product backlog – see below table for a sampling the product backlog items for each of the Feature Groups.

Week 2-3

Implementing the Report Explorer Web Part

To start the second week, we hit the ground running on building the new Web Parts that included a new Report Viewer and Report Explorer. In the interest of time, we did our best to leverage patterns and assets used by the v2 and v3 SSRS Web Parts. Note that SSRS Server natively hosts an ASPX page that contains the Report Explorer UI that is found in the v2 SSRS Web Part and leveraged by the SSRS built-in Report Manager. The Custom Report Explorer Web Part uses an IFrame to host this ASPX page. There are two parameters that are used to configure the Web Part – the “Reporting Server URL” and the “Starting Path” (screen shot of the Web Part Properties can be seen below). Note that the UI of the Report Explorer Web Part renders a view much like Windows Explorer (as shown earlier in this post). The “Report Server URL” points to the location of the SSRS Reporting Server. The “Starting Path” describes where to start in the view in case you wish to start in a subfolder. For example, you can configure the Web Part to start in the “HR Reports” folder when configuring for a HR SharePoint Site.

Adding Web Part Connections

To make Web Parts more useful, you can develop a Web Part to accept connections from other Web Parts on the same page. By creating connectable Web Parts, you have the ability to create new and more meaningful ways to view data and interact with a Web Part Page. In the case of the Report Explorer and Report Viewer, we want to pass the id of the SSRS Report Viewer Web Part back to the Report Explorer Web Part. The SSRS Report Explorer uses this id to specify which Report Viewer Web Part instance should be the “target” when a report link in the Report Explorer Web Part is clicked. In the screen shot below, we are setting the Web Part connection on the Report Explorer Web Part to connect to the Report Viewer Web Part.

The IWebPartField, shown below, is one of several standard interfaces used to create connectable Web Parts. As the name implies, IWebPartField is intended to pass a “field” of data while IWebPartRow and IWebPartTable are meant to pass a row and table respectively. Connections are enabled through the use of ConnectionProvider and ConnectionConsumer attributes.

Report Explorer Implementation

[ConnectionProvider("Report Explorer")]

public IWebPartField GetConnectionInterface()

{

_isWebPartConnected = true;

return this;

}

Report Viewer Implementation

//Get the connection

[ConnectionConsumer("Report Viewer", "ReportViewer",AllowsMultipleConnections=false)]

public void SetConnectionInterface(IWebPartField fieldProvider)

{

CustomReportExplorer reportExplorer = fieldProvider as

CustomReportExplorer;

if (reportExplorer != null)

{

reportExplorer.ConsumerId = this.ID;

_isWebPartConnected = true;

}

}

To learn more about Web Part Connections, see documentation on the SPWebPartConnection Class.

Implementing the Report Viewer Web Part

Like the Report Explorer Web Part, the Report Viewer Web Part renders content provided by the SSRS server through use of an IFrame for the ASPX page. Key features implemented to manage the interaction with the ASPX page are: a) a connection to the Report Explorer Web Part to allow a report to be passed to the Report Viewer, b) support for MOSS Filter Web Parts to be able to pass in reporting parameters through Web Part Connections, and c) ability for report parameters to be specified in the Web Part properties.

The Report Viewer Web Part uses the GetReportParameters method of the ReportServices2005 Web Service to retrieve report parameters. The Report Parameters from this method call are used for two purposes.

1. The parameter prompt (i.e. Display Name) is used in the IFIlterValues Interface so that the connecting MOSS Filter Web Part can choose which report parameter is receiving data.

2. The parameter display name and default values are used to build the list of parameters in the Web Part editor.

Note that if parameters are not supplied to the Report Viewer Web Part the ASPX page provided by SSRS Server renders input boxes at the top of the report as seen below.

Our client required that the reporting parameters also be provided through the Web Part Properties Editor and through Web Part Connections. Below is a view of supporting the parameters through the Web Part Properties Editor. This required dynamically discovering and rendering the label and input controls for the report parameters.

From a programmatic standpoint, the first step is to retrieve and store the report parameters so that we can use these for Web Part Connections and Web Part Properties. A CustomReportParameter class is used to store report parameter name/value pairs that are retrieved by an SSRS Web Services call.

ReportingService2005 svc = new ReportingService2005();

parameters = svc.GetReportParameters(ReportPath, historyID, forRendering, values, credentials);

if (parameters != null)

{

//look through each report parameter returned, and add to our list if not

//already in the list

foreach (ReportParameter rp in parameters)

{

if (!_customReportParameters.ContainsKey(rp.Name))

_customReportParameters.Add(rp.Name, new CustomReportParameter(rp));

}

Now that we know the parameters that are available in the report, we can use these parameters for Web Part Connections and Web Part Properties. We implemented the IFilterValues interface to support MOSS Filter Web Parts (Web Parts used to filter other Web Parts see MSDN for more details). To implement the IFilterValues interface, the Report Viewer Web Part must provide the filter value provider (e.g. Choice Filter Web Part) with a list of parameters which can be used to filter the report. Here is a simplified version of filling those parameters:

List<IFilterValues> _providers = new List<IFilterValues>();

[ConnectionConsumer("Parameters", "IFilterValues", AllowsMultipleConnections = true)]

public void SetConnectionInterface(IFilterValues provider)

{

if (provider != null)

{

//add this provider to our collection of providers

_providers.Add(provider);

//Call the ReportServices2005 web service to build a list of parameters

FillParameters();

//create a ConsumerParameter for each of our Report Parameters

List<ConsumerParameter> l = new List<ConsumerParameter>();

//iterate over each ReportParameter and fill the list of

//ConsumerParameters

foreach (CustomReportParameter crp in _customReportParameters.Values)

{

//Note: We are adding parameters by "Prompt" and not by

//parameter name

l.Add(new ConsumerParameter(crp.ReportParameter.Prompt,

ConsumerParameterCapabilities.SupportsAllValue |

ConsumerParameterCapabilities.SupportsMultipleValues |

ConsumerParameterCapabilities.SupportsEmptyValue |

ConsumerParameterCapabilities.SupportsSingleValue));

}

provider.SetConsumerParameters(new

ReadOnlyCollection<ConsumerParameter>(l));

}

}

Below is a Web Part Configuration dialog for the Web Part Connection between a Filter Web Part and the Report Viewer Web Part. Note, the code above provides the “Filtered Parameter” list. This particular report has both “Customer ID” and “Account ID” as available reporting parameters that can participate in a Web Part Connection.

Once the Web Part connection has been established, the Report Viewer Web Part retrieves the filter values from the IFilterValues provider. Below the FillParametersFromWebpartConnection method is called each time the Web Part is rendered to retrieve parameter values from the filter provider in order to build a query string. The query string is used to pass parameter values to the SSRS ASPX page, which is then rendered in the Web Part.

private void FillParametersFromWebpartConnection ()

{

//iterate through each provider

foreach (IFilterValues provider in _providers)

{

//now find our parameter and populate the values

//remember though, we have to search for it by Prompt

foreach (CustomReportParameter crp in _customReportParameters.Values)

{

//match up the provider with the report parameter by prompt

if (crp.ReportParameter.Prompt == provider.ParameterName)

{

if (provider.ParameterValues == null)

{

break;

}

else if (crp.ReportParameter.MultiValue)

{

crp.Value = "";

foreach (string val in provider.ParameterValues)

{

//encode to account for semi-colons in

//mutli-value selects

crp.Value += val.Replace (";",@"\;");

crp.Value += ";";

}

}

else if (provider.ParameterValues.Count > 0)

{

crp.Value = provider.ParameterValues[0];

}

//break out of the foreach loop;

//we have found the parameter

break;

}

}

}

}

Here is an abbreviated sample of building out the query string.

//fill parameters from web part connection, if any

FillParametersFromWebpartConnection();

//loop through each report parameter and build parameters on the query string

foreach (string paramName in _customReportParameters.Keys)

{

if (_customReportParameters[paramName].Value != null)

{

reportUrl += "&" + paramName;

reportUrl += "=";

reportUrl += _customReportParameters[paramName].Value;

}

}

Below are a series of screen shots showing the use of a MOSS Filter Web Part where it is connected to and providing parameters to the Report View Web Part. Below shows a Filter Web Part with preconfigured name/value pairs

Next, we use the Filter Web Part to the select a Customer

And after a customer is selected, you see the filtered report that uses the filter’s value.

Summary

In Summary, this solution leveraged the following to allow a quick turnaround:

• Use of existing Report Explorer and Report Viewer UI provided by SSRS Server through use of IFrames.
• Use of the SharePoint Web Part Framework to leverage Web Part Connections for connecting the Report Explorer to the Report Viewer and for passing in report parameters from Filter Web Parts yielding a richer user experience.
• Use of Web Services within Web Part Properties to dynamically provide configuration of Report Parameters.
• Use of Agile development techniques to build weekly solutions that could be tested and adapted to an enterprise grade solution in 3 weeks.

Key tools that helped in the Web Part Development were:

STS Dev – The STSDev tool is an excellent tool used to quickly create base SharePoint features which can be easily packaged into SharePoint solution files.

SharePoint Solution Installer – The SharePoint Solution Installer is a terrific alternative to stsadm commands. This tool checks for basic SharePoint prerequisites and will deploy or retract your solution using a friendly wizard based interface.

About the Team and Authors

Eric Bowden is a Senior Consultant with ThreeWill who implemented the Report Viewer features.

Tim Coalson is a Senior Consultant with ThreeWill who implemented the Report Explorer features.

Donna Hodges from Microsoft was the technical decision maker that was able to keep the team focused on getting the most bang for the buck.

Audie Wright from Microsoft was the business liaison that defined the business requirements, and ensured that the necessary resources from the client, and Microsoft were provided to effectively solve the business problem.

Tommy Ryan is a co-founder of ThreeWill who helped pull together the article with assistance from the project team and Danny Ryan.

Today, in Day 1 of the PDC Keynote, Ray Ozzie unveiled the Azure Services Platform. Azure makes it possible for developers to create applications and services that run in the cloud or to create web, mobile, or hybrid applications that extend the value of on-premises applications. To learn more about Azure, go to http://www.azure.com .

In the Azure Services Platform, a number of developer services were mentioned including Microsoft SQL Services, Microsoft Dynamics CRM Services & Microsoft SharePoint Services. Keep in mind that this not the same as Windows SharePoint Services 3.0 which shipped in Windows Server.  Microsoft SharePoint Services is a developer service that will be available as part of Azure in the future.

The keynote also emphasized Microsoft’s investment in cloud applications that developers can extend and customize. Specifically, David Thompson (VP of Online Services) talked about Microsoft SharePoint Online  and demonstrated how developers can write code against SharePoint Online web services as well as make customizations with SharePoint Designer. For example, using the Data View Web Part to surface data from an external source – this could be a web service living in Windows Azure. In fact, later in the week at PDC, there’s a breakout session that walks through the different ways SharePoint Online can be customized.

Here are answers to a few frequently asked questions:

What is Microsoft SharePoint Services in Azure?

In the future, developers will have access to SharePoint functionality in the Azure Services Platform (“Microsoft SharePoint Services”). With the flexibility to use familiar developer tools like Visual Studio, developers will be able to rapidly build applications that utilize SharePoint capabilities as building blocks for their own applications. Developers can expect a breadth of SharePoint capabilities across the spectrum of on-premises, Online and the Azure Services Platform.

Where can I find more information about Microsoft SharePoint Services in Azure?

We have not announced any further detail or release dates. We will release more information about this in the future.

How do developers get ready for Microsoft SharePoint Services?

Keep developing on SharePoint technology (MOSS, WSS, SharePoint Online)! You can learn more about SharePoint Development here.

Stay tuned for more news from the PDC 2008!

Office Service Pack Team announced Service Pack 2 for 2007 Microsoft Office System.  This new service pack will be released between February and April 2009.  It will contain both client and server updates.  Here are some of the SharePoint related topics that we will be expanding upon in later posts.

• Improved Read-only Content Databases
  Whenever a content database is marked read-only, all of the site collections in that database are automatically marked as read-only. 
• ECM Performance and Manageability Improvements
  Improved performance and manageability in variations, including STSADM commands for repairing links between source and target pages.
• Improved Index Rebuild Timer Jobs
  SharePoint content databases running in SQL Server 2005 will undergo an automatic index rebuild, which helps stop defragmentation, and stop the database from degrading in performance.
• Upgrade Checker
  This will scan your SharePoint farm in advance of applying SP2 and will provide feedback on the environments readiness to upgrade.

So please stay tuned!

Regards,

Jie Li & Dave Pae

SharePoint Technical Product Managers

Daylight Saving Time (DST, in some countries it is called summertime) exists in many countries. The start dates and end dates of DST change from year to year, and countries may change their policies for DST occasionally. This DST update is an effort of SharePoint product team to reflect these new changes. It includes updated time zone definition information for the following countries:

• Iraq
• Argentina
• Chile
• Iran
• Morocco
• Pakistan
• Venezuela

For more detail of this update, please refer to

http://support.microsoft.com/kb/956612

The update can be download here: x86 x64

You can always refer to this article for Windows SharePoint Services 3.0 update deployment guidance.

Jie Li

Technical Product Manager, SharePoint

Tester bloggng fra Micorosoft Live Writer

Web

Mobile photos

Blog Images