December 16, 2004

Getting Sharepoint subsites to communicate part 2

Following my previous post, I have taken the connections between subsites further using connected data view web parts, where one web part provides an input to filter the data presented in the second web part.

Scenario: http://server/subsite1 holds a master list of projects, and a document library of documents for each project. http://server/subsite2 is to provide a subset of the project list, and when an item is selected, provide a list of the documents for that project. (Ideally it would provide links to the actual documents and enable them to be downloaded, but that issue is yet to be overcome - it turns up in plenty of sharepoint blogs.)

Approach: the above is accomplished relatively easily with data view web parts and FrontPage 2003. The only tricky bit that I found was setting the connection parameters to retrieve the correct view. (Note that the web part only retrieves the first page of the view on the other site, so if the list is very long you may need to create a unique view with a large item limit to ensure that all of the data is returned. And you will need to find the GUID of the view to use as a parameter in the connection.)

References: the following articles provide a good basis to understand what is going on:

Building XML data-driven websites with FrontPage 2003 provides a good overview of the data view web parts and using the data source catalog in FrontPage;

Web Services Description Language (WSDL) explained is an older article, but I found it very informative when looking at the code behind the cross-site queries.


Screenshot - connected DVWP's retrieving items from another sharepoint site

This is a screenshot of subsite2. The web part at the top of this screenshot retrieves a subset of list data from subsite 1. Selecting an item in the list provides an input parameter to the second web part, which filters the items in a document library on subsite 1 accordingly, and presents the results. (The two sites concerned are both at the same level in the site hierarchy, not parent-child sites.)

Now onto how to accomplish the connections.

The first step is to connect to the data source using the data source catalog - this has been covered in the Frontpoint blog, the relevant article is linked in my earlier post here.

In my case, I wanted DVWP#1, which provides a list of projects, to influence DVWP#2, which is providing a list of drawings. First, use the directions in the above blog post to make a age containing teh two web parts, and get both web parts to retrieve the information that you are after. The data in DVWP#1 can be filtered as desired by going to Data View Properties... and setting the Filters as required. DVWP#2 will not doing any filtering until after a web part connection is established, so the data you see in FrontPage will not necessarily look like the final view that you are after.

Open the page you want to work on in FrontPage, right-click the second web part and select Web Part Connections... This opens the Web Part Connection Wizard. The web part you have selected will be the source, then select an action, in my case Modify using parameters from... Click next, and select the target web part (which is the other web part on the page) that will provide the filter criteria. The 'target action' is Provide data values to... Click next. This brings you to this screen:

Web part connection wizard

Select the column in target web part that you want to use as the input parameter. (In my case this is a project number.) Click next. If you want the first web part to highlight which item is selected, tick the box Indicate current selection using... And you are done.

Now set the filter criteria on the second web part. Right-click the web part and pick Data View Properties..., data view details appear in the task pane. Click on Filter, and set the criteria that you want. Note that the input paremeter passed in the web part connection is available as a value to use in the filter criteria:

Filter dialog using input parameter

Save the page, and that's it! Now you have two web parts retrieving items from another site, and the first one providing filter values to the second.

Some related notes 1) if you pick the first web part when setting up the web part connection, the process is much the same but the source and target are reversed and consequently the actions are reversed as well, giving the same end result; 2) if your cross-site connection requires a login, consider setting up a separate account just for this purpose with minimal rights (i.e. 'Reader').

And finally, I would love to know how to retrieve files from a document library across sites. By adding the document library to the data source catalog with Manage catalog..., I have successfully set up a web part that links to the relevant documents with a full absolute URL. And as I have the correct permissions, I can use this web part to retrieve the documents from the other site. But the data sources added with 'Manage catalog' reside with the Frontpage installation, not the sharepoint installation, so this web part will not work for other users of the site. So a web part is needed as a go-between to provide the correct login for the source site. This works OK for attachments to list items, but at this stage does not appear to be available for documents in document libraries. Ughh!!

If you find this post has been helpful, please leave some feedback.

Posted by Jeffrey at 04:09 PM | Comments (0)

November 28, 2004

Getting sharepoint subsites to communicate

I finally came across the answer to an issue that has had me tearing my hair out: Howto: Display list or document library data from a parent site within a different site.

In my case, I have http://server/subsite_1 which is private and contains a master list of data, and http://server/subsite_2 which is for a different user base but needs to display a subset of the master list data.

I had tried some very long URL's to retrieve the XML of the right information; this worked within Frontpage but failed on the server. The above post uses the data view web part to retrieve information on the other site. I see no reason why it would not work just the same with sites on another server.

Update 29 November: It occurred to me that the login credentials need nothing more than Reader privileges to retrieve information, so I created a new user solely for use in cross-site data view web part connections.

Posted by Jeffrey at 11:37 PM | Comments (0)

November 11, 2004

Productivity improvements of sharepoint

Microsoft have published a white paper outlining the results of some independent research on the benefits of a collaboration platform.

Some of the highlights are a 34% reduction in project cycle times, 35% reduction in time allocated to meetings, and a 37% reduction in travel. Suprisingly, the productivity improvement from this is only estimated at 0.2 to 4.0%.

My organisation had already adopted an anti-meeting stance before we introduced sharepoint, but it has facilitated much quicker document retrieval and definitely reduced the round-trip time for review, amendment, approval and release of drawings to our clients. And subjectively the productivity improvement is much better than 4%.

An added benefit is the improved relationship with clients by use of sharepoint sites as extranets. This has been very well received.

Posted by Jeffrey at 03:59 PM | Comments (0)

September 18, 2004

FP2003 and WSS revisited

Dustin Miller has posted a blog article in reponse to the MSD2D article (see my post 28 August) bagging Frontpage 2003. It seems the dire warnings may have been slightly alarmist.

Posted by Jeffrey at 03:07 PM | Comments (0)

August 28, 2004

FP2003 and WSS

I came across an interesting article with some warnings regarding editing WSS sites with FP2003. It relates to the way that site definitions are stored, and describes a subtle yet important change that occurs when a page is opened with FP2003 and saved (even if unmodified). The term is 'ghosting', and the full article is The Dangers of using Front Page 2003 with SharePoint Sites (registration is required to download the document). Worth a read.

Posted by Jeffrey at 10:59 PM | Comments (0)

August 04, 2004

Sharepoint at work

We recently took on board a virtually endless stream of design projects from a new client. We faced a dilemma - we were to do the structural design, but drawings were to be done by the client's own drafting staff. Somehow we needed to keep control of the drawings so that everyone that needed them could access the latest revisions, but they were not available for production until they had our approval. The existing system being used simply used email to send the drawings around to whoever wanted them. This made it difficult to keep track of revisions and to know who had access to which drawings.

The solution - a sharepoint subsite to act as an extranet and retain all of the drawings. This took about half an hour to set up the way that we wanted it, and then we invited the various users that needed access to the information. To control the drawings, we simply turned on document approval for the document library. Then the drafting team could post drawings to the library but they did not become visible to the production site until we had reviewed and approved them.

This is a very simple application of Windows Sharepoint Services, but it suited our needs perfectly, provided structure to a system that was not working previously, and will save us (and our client) a lot of time.

Posted by Jeffrey at 02:59 PM | Comments (0)

June 23, 2004

Retrieving filtered sharepoint lists with InfoPath

Dustin at the sharepoint university has blogged about extracting XML from Sharepoint with a properly formatted URL: Don't forget: Web Services/SOAP isn't the only path to XML from SharePoint. This and some thoughts on InfoPath had me intrigued.

As I have blogged before, Jan Tielens has shown in is blog how to connect to a sharepoint list from Infopath SP1. I had this working, but I could not see how to filter items and only retrieve those in a specific view of a sharepoint list. And I do not have local access to establish custom web services.

Dustin's XML retrieval process fills the gap! Here's how to do it.

In InfoPath, open an empty form and place a list box control on it. Double click the control, and click Add... beside Data connection. Then select XML document and click Next. Now you need to enter the complete URL that you obtained using Dustin's procedure (including the &View= parameter if you want use a specific view). Click Next, and InfoPath will make the connection.

Now you need to select the Entries, Value and Display name. The available fields will be those that are defined in the sharepoint view, and they will be listed under rs:Data in the XPath dialog. (I found that the field names were nothing like the actual list fields, so some trial and error was required.) Once you have selected the target items, preview your form.

Voila! - a drop down list populated with the items from a sharepoint list, filtered (and ordered) using the view of your choice. And not a web service, SOAP or custom script in sight. If you like this idea, I would love to hear your feedback.

Posted by Jeffrey at 04:44 PM | Comments (0)

June 01, 2004

Infopath and sharepoint lists

Objective: a timesheet form created in InfoPath that records time spent on multiple projects, and accesses existing sharepoint lists for project and worker details. The form would be published in a form library on a sharepoint site for distribution.

The answer: well, I had just been reading about secondary data sources, and I think Jan Tielen's article Utilize the Secondary DataSource Data in InfoPath (SharePoint List Example) is exactly what I was after. Evidently the book I bought on InfoPath was before SP1, as they do not mention lists as secondary data sources.

Now I am left to create the form and see how it goes! I shall post the results when it is complete. Thanks, Jan.

Posted by Jeffrey at 02:08 PM | Comments (0)

May 21, 2004

Issues lists

Issues lists are worthy of mention, as there are none in a default sharepoint site, but they provide the closest thing to workflow automation that can be achieved without programming your own event handlers.

To create an issues list, select 'Documents and lists', and then 'Create'. At the bottom of the lists group, there is an 'Issues list' item. These are customisable to some extent, and provide a very useful way of tracking issues which may be assigned to different people in the course of their resolution.

We use them within our workplace to assign work and record drawing amendment and design checking processes. The person initiating the work creates the issue and assigns it to the recipient. They receive an email automatically (this is an option available when setting up the list) notifying them of the issue. When they have dealt with it, they open the item and edit it, where they have the opportunity to add comments to the item. They can assign it to someone else or close it depending on what is required next. Each set of comments are recorded chronologically in the item, and as far as I can tell are not editable after they have been posted (this may be either good or bad depending on your viewpoint).

You can add custom fields to the basic issues list form, and link these to other lists on the site if desired. In our case we maintain a list of unique project numbers, which we often link to in other lists and discussions. Attachments are also permitted on issues list entries. Overall, the Issues List is a useful tool in the default Windows Sharepoint Services website.

Posted by Jeffrey at 04:20 PM | Comments (0)

May 19, 2004

Web parts: WSS building blocks

WSS functionality is presented through the extensive use of "web parts". This concept may be foreign at first to those used to building HTML pages, but it provides a modular approach to adding your own content to a WSS site. In this article I outline the types and uses of the basic web parts, and how to insert them on pages of a WSS site.

If you have administrator rights for the WSS site, click on the 'Modify shared page link' and select 'Design this page'. This will then present the page to you in Design mode. A number of boxes appear around the page content. These denote the 'web part zones', and are basically containers for web parts. To see the available web parts, click on 'Modify shared page' | 'Add web parts' | 'Browse', and a toolpane listing the available web parts will open.

All of the document libraries and lists in the site will be represented in this list, along with some others - Content editor web part, Form web part, Image web part, Members web part, Page viewer web part and XML web part. To add a web part, just drag it from the list to the web part zone in which you wish it to appear. You can then select 'Modify shared web part' from the drop down list on the web part titlebar to open a toolpane that enables options for the web part to be set, such as the width, height, title, etc.

It is worth noting that the document library and list web parts provide views of site data, and do not contain the content themselves. If you delete the web part, the source data is unaffected.

Usage of most of the web parts is straight forward, but some are worthy of comment further. To insert your own javascript or html content on a page, use the Content Editor web part, and you can either type the content as rich text, or type it in as html source. To insert a view of an RSS feed from another site, you can use the XML web part. (You will need to supply an XSLT file to format the data; one source of these is Sig Weber's page.)

Web parts can be linked, so that the content displayed in one web part depends on the options selected in another on the page. I will leave the details of this for a future post. When editing a page in Frontpage, there is another web part available called the Data view web part. This web part is very powerful, and I hope to write a separate article about it at a future date.

Posted by Jeffrey at 02:01 PM | Comments (0)

May 11, 2004

PDF's and WSS

Just a short note about a topic that has been covered in depth elsewhere (try the WSS FAQ or demo site linked from my main page for a start).

By default, WSS does not have a pdf icon, and it does not index content within pdf files. Both of these can be achieved, but it requires admin rights on the local server. In my own case, we were able to convince our service host to install the Adobe iFilter and icon for us. Note that officially the iFilter is for Sharepoint Portal Server, but it works fine with WSS as well. MS knowledgebase articles 832809 and 837849 are a useful reference on this topic (and the former contains a link to the iFilter).

Posted by Jeffrey at 03:53 PM | Comments (0)

Backup a WSS site - updated

As soon as you take the time to add content to your WSS site, the obvious question is how do you make a backup? If you don't have admin rights on the local computer, the options are somewhat reduced.

You can either use Frontpage 2003 to open the website, and "Publish to.." a local drive, or you can use the Microsoft migration tool smigrate. Yes, even though it is a migration tool, it is intended to be used for backup/restore of WSS sites. The smigrate option does not give a full-fidelity backup as some customisations may be lost after a restore, but it is the best that can be achieved without local access. In the remainder of this article, I will outline how to obtain and use smigrate.

(I found a lengthy and very recent article on an MS site comparing the various methods of backing up WSS sites in detail, including the stsadm command line tool for those with local access. If anyone has the link to this article, please post it in a comment, as I cannot find the article again.)

(Update 7 July, 2004: A Frontpage whitepaper available here compares all of the backup options in detail (including those not available in Frontpage). An extract summarising the options can be viewed here (36 kb pdf).)

Smigrate can be obtained here, and the usage is as follows:

Usage (backup):
smigrate -w -f [-e] [-y]
Usage (restore):
smigrate -r -w -f [-x]
The following command-line parameters can be used with SMIGRATE.exe.

Parameter Description
-f Backup filename (required). Specify a filename with the extension .fwp.
-e Exclude subsites during backup (optional). No parameters.
-r Restore (optional). No parameters.
-w Website URL (required). Valid URL to a SharePoint Web site.
-x Exclude security during restore (optional). No parameters.
-y Confirm that you want to overwrite an existing backup file.
-u Administrator username.
-pw Administrator password. Specify * as the password to be prompted for a password.

One thing that I have noticed is that it will fail if I leave my firewall running, so that needs to be shut down beforehand. Even though it is a command line tool, I have made a shortcut to it which passes the necessary parameters, and it runs fine without ever needing to type anything in.

Posted by Jeffrey at 03:25 PM | Comments (0)

Shortcut to a document library

This topic is easy, but worth mentioning. With Office 2003, you can open documents from and save them to document libraries as easily as saving them to your local disk.

To save to a library and create a shortcut to it for future use, do the following:

1. With the document you wish to save open (in Word, for example), click Save as...
2. In the filename, type the full url of the sharepoint site, eg and click Save.
3. You will be prompted to login to the site, then a list of the available document libraries will be given.
4. Double click the destination library.
5. Click the Tools option on the Save as dialog, and select Add to "My Places". This will create an icon in the left hand pane for future use (the icon can be renamed if you wish).
6. Save the document.

The shortcut can then be used to access the library for both saving and opening documents.

Posted by Jeffrey at 11:29 AM | Comments (0)

May 06, 2004

Book review

Following are my comments on the book "Microsoft Sharepoint: Building Office 2003 Solutions", by Scot Hillier, published in 2004 by Apress (ISBN 1-59059-338-3).

The contents of this book are as follows:

Chapter 1: Sharepoint Business Solutions
Chapter 2: Sharepoint Products and Technologies Overview
Chapter 3: Sharepoint Portal Server Basics
Chapter 4: Sharepoint Content Development
Chapter 5: Building Web Parts
Chapter 6: The Microsoft Single Sign-On Service
Chapter 7: Advanced Web Part Development
Chapter 8: The Microsoft Office System
Chapter 9: Programming Sharepoint Services
Chapter 10: Sharepoint Portal Server Administration
Chapter 11: Office Solution Accelerators

As you can see from the contents, this book targets Sharepoint Portal Server. To follow the code examples provided, you need at least Microsoft Windows 2003 Enterprise Edition, Sharepoint Portal Server, and Visual Studio .NET. While the Web Part development topics are relevant to those using WSS only, they still require Visual Studio .NET. (That rules me out.) Still, I did glean some useful tips from this book, and it will be a useful reference in the event that I start developing Web Parts with Visual Studio .NET sometime in the future.

If you are interested in Web Part development, and want some examples for free, have a look at the companion content to the book "Programming Microsoft Outlook and Microsoft Exchange 2003", 3rd edition, by Thomas Rizzo (Microsoft Press, ISBN 0-7356-1464-4), which is available for download here. This download contains several supplemental chapters, some of which cover Web Part development.

Posted by Jeffrey at 11:31 AM | Comments (0)

May 04, 2004

Why blog?

I have started this blog as a place to outline my experience customising Windows Sharepoint Services. There are plenty of blogs about WSS, many of these are maintained by gurus with a lot of development experience. My blog is aimed at WSS beginners like myself with modest resources, specifically:

Frontpage 2003,
MS Office 2003,
Windows Sharepoint Services (not Portal Server), externally hosted,
Limited coding experience.

This blog will record tips and tricks as I come across them, and outline the solutions to the everyday issues that arise within my organisation. I hope that it encourages new users to take advantage of the built in features of WSS, and those that are considering WSS to jump in and get started, as well as outlining some of the customisation that can be achieved with minimal effort.

My involvement with Sharepoint began with Sharepoint Team Services (the predecessor to WSS). I work for a decentralised structural engineering consulting firm whose staff work from their own homes. STS offered intranet-like functionality for remote workers, so we jumped in and set up a site in 2003. With the release of Windows Server 2003, WSS came along and we made the transition from STS to take advantage of expanded features. (Our site is hosted with Alentus in Canada.)

The use of our WSS 'intranet' site has grown to the point where it handles a major share of our administrative records, internal correspondence and design process. We are very pleased with the facility, and have realised significant productivity improvements as a result. A planned future use is the provision of extranets for our projects to enable self-service drawing retrieval by clients/builders.

And we also use a customised WSS site as our external 'advertising' site, which you can view at Most of the customisations and content visible at this site were achieved within Sharepoint, with some minor modifications performed in Frontpage 2003.

Posted by Jeffrey at 01:08 PM | Comments (0)