February 2005 - Posts

Sharepoint Include and Exclude Content and the Site Directory
22 February 05 11:01 AM | madsn | 4 comment(s)

Internally we're using several site directories around the portal to categorize external content, both WSS sites and other stuff.

We are pretty liberal in allowing people to create sites and add links to sites with relevance. There's YASQ related to this. First let me explain how the Site Directory area template works.

The Site Directory template is really just an Area with a list. I usually compare the Directory to a whitepages listing that allows you to tag content with metadata, like you tag people with addresses and phone numbers in the phonebook. If your address changes there are no high coupling to the phonebook so using Site Directories provides more flexibility than creating site hierarchies in WSS to indicate associations.

When clicking "Create Site" from the Site Directory Area Template (no matter where it is instantiated) you're basically going to perform three functions:

1. Create a new top-level WSS site (yes, always top-level)
2. Create an entry in the "whitepages", i.o.w. tagging your new site with metadata relevant for the Area you're creating it from (we often customize the list to provide accurate categories and metadata)
3. Register the site/external resource for search (make it appear in the "Manage crawls of Site Directory -> Approved Sites")

So, no matter where you create a Site Directory in your portal, the template is going to perform these operations. By default all sites will also be registered for search in the same place, not differentiating on which Area you created the site from.

The other function provided by the Site Directory template is "Add link to site". This allows users to add unlisted WSS sites or external content to the directory, and also make Sharepoint crawl these resources and include them for search. For internal WSS sites all is good, but if you add an external resource using this function you might get a nasty surprise.

I added my weblog to our portal Site Directory with the url http://weblogs.asp.net/mnissen. Forgetting about this YASQ I arrived the next morning finding that our portal was still indexing content starting 01:00 AM last night. Sharepoint was indexing the entire http://weblogs.asp.net site, thank God I hadn't "Include linked content" enabled.

To correct this behaviour I had to add a couple of new rules to the Non_Portal_Content index. One excluding http://weblogs.asp.net/* and one including http://weblogs.asp.net/mnissen/*. I feel somehow that this should have been the default behaviour, and provide this as a clear warning to administrators that enable the "Add link to site" feature without approvals. For every external resource included in the site directory you have to think carefully about your include and exclude rules.

Filed under: Office System

Site Definitions and Templates
20 February 05 02:11 PM | madsn | 3 comment(s)

Kris got his article published on the .NET Developers Journal and Patrick comments on the use of custom site definitons. I agree with Patricks pros and cons of using Site Definitions and I'd like to elaborate a bit aswell.

I've done several template based Sharepoint projects and usually I don't create site definitions. The primary driver for avoiding it is development time and upgradeability. I generally use the very simple "Save site as Template", or ".stp"  approach. This enables me to create the templates really fast in Frontpage, and deployment is done with spsadm in seconds. Technical customers even learn to do it themselves.

There is a drawback to this approach however. When we do comprehensive customizations to the ghosted STS template, the entire changeset is instantiated for each site, making each site consume a lot of space on the SQL Server. So far we have been doing quite massive site generation using this technique without sacrificing much more than diskspace, but there is a x-factor here I'm not entirely comfortable with, compared to ghosted scenarios.

Additionally you have the Sharepoint Portal Server templates where you don't have the option of saving an area as a template. Here I generally recommend to do customizations manually for each area, but in some cases you might want to create an area template to save time. Just make sure you're really going to save time. Usually you can customize a lot of areas in frontpage in the time it takes to develop and test a area definition.

 

Filed under: Office System

Sharepoint Content RSS Feeds unlocked
19 February 05 03:25 PM | madsn | 1 comment(s)

I usually don't bother crosslinking plainly obvoius fantastic stuff, simply because everyone else does it, and noone really needs another "i've also seen it" posting. However this time I just can't help myself.

I recently unlocked Sharepoint content using RSS with Jan and Patricks early beta of the RSS feed generator. Now they've done it again:

RSS Feed Generator Available for Download

In addition to their (and Maxims) already much appreciated SmartPart this release builds significant value on any Sharepoint installation. Why Patrick wasn't accepted for Teched US this year beats me, but I'd sure like to know this; how did you guys get the day expanded from 24hrs to a 100:-)

Impressive contribution. Just impressive...

Filed under: Office System

Light-weight extension of Sharepoint Document Management
17 February 05 12:04 AM | madsn | 6 comment(s)

I recently helped the Norwegian video-conference company Tandberg get more value out of their Sharepoint installation through extended project support features and improved desentralized internal publishing.

The existing routines for document management were heavily based on a centralized assignment of unique document numbers. Early in the process it was agreed that internally both the document url and the Sharepoint guid were unique identifiers for documents, but none of these could be used externally. This called for extending Sharepoint with functionality for assigning unique document numbers.

A primary goal in the project was not to choose solutions that required deploying custom code on the Sharepoint server. We tried several approaches but they were rejected on poor user experience (extensive use of lists and custom relations and custom auto-numbering). The final solution was based on a service oriented approach, and a simple chubby client implementation in the Sharepoint UI. The result was a simple web service interface delivering unique document numbers and two lines of html in the EditForm.aspx of the template document libaries. This is how the solution is presented to the users:

When needed, users click the link in the bottom toolbar and the Document Number metadata field is assigned a unique number from the DocumentNumber WebService.

Behind the scenes we deployed the Web Service Behaviour and a custom JavaScript that handled calling the webservice and rendering the html for the toolbar. The script and htc was placed under the _layouts folder on the server as you can see from the url. The result was only two additional lines needed in the default Sharepoint EditForm.aspx:

The tricky part of this solution was really to reverse engineer Sharepoint JavaScript rendering logic to figure out the id's of the textboxes in the EditForm.aspx UI. This script snippet will give you an idea of how to go by to get a hold of your metadata values in Sharepoint forms:

Summarized we ended up with an extremely low impact solution that proved as a significant improvement over the existing solution, thus making the migration to Sharepoint easier for the users. Another really cool thing is that it is easily extensible. The getToolBarHtml() function can return a more comprehensive toolbar with more features, and the features can be easily exposed as webservices and called with the chubby client approach. All of this done from a single location in your Sharepoint server.

For my own part I have to admit that Sharepoint forces me to appreciate client-side scripting more than I'd like to:-)

Filed under: Office System

InfoPath + Amazon Web Service = wtf!?
09 February 05 04:22 PM | madsn | 4 comment(s)

UPDATE: The InfoPath team have affirmed that this is a bug and provided a general and specific work-around. Read about it here.

Wow. I'm getting into InfoPath these days and wanted to use the Amazon E-Commerce Service 4.0 to retreive some data. I've tried and reproduced this on two machines so far:

1. Open InfoPath
2. Design a form > New blank form
3. Tools > Data Connections > Add
4. Receive Data > Web Service > Paste URI http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl
5. Select an operation > ItemLookup > Next > CRASH!

Who's to blame? InfoPath or the Amazon WebService. Well, FrontPage consumes the service without violently terminating without giving any errormessages. Anyone else able to reproduce?

Filed under: Office System

Disappearing Sharepoint folders in Explorer view
08 February 05 01:17 PM | madsn | 3 comment(s)

Heads-up on this one people (YASQ - yet another sharepoint quirk):

When having content approval enabled for a document library and using explorer view to make changes, content are not automatically approved when adding items or making changes. This can give the impression of stuff disappearing in your document libray.

If you've got content approval enabled and add or rename a file or folder in Explorer View it will simply disappear from the All Documents view. You'll have to approve the change in the Approve/Reject view to make it appear again. Very scary if you had a million documents in that folder.

To make the confusion complete you'll also need to be aware of possible caching in the Explorer View control. If you create a folder called "test" in Explorer View, then return to the Approve/Reject View and select "Delete" on the item pending and return to the "All Documents" view the "test" folder is gone. If you open the Explorer View again the folder "test" is still there (at least in my browser). Clicking the folder will give you an errormessage.

These things just gave me the chills, but fortunately it was less severe than first expected.

Filed under: Office System

Sharepoint and non-IE browsers
07 February 05 12:15 PM | madsn | 1 comment(s)

Sharepoint is really picking up and more and more user is getting into the product. At the same time there are several browser out there not developed by Microsoft, like FireFox and Opera. There are several issues related to using Sharepoint with other browsers and it's about time that the community starts to track this in a structured manner.

For this purpose I've created a GotDotNet workspace. The primary goal is to get the Sharepoint community to report issues with non-IE browsers and Sharepoint in a structured way. When we have shared view of the issues we can start considering options for extending Sharepoint to better support other browsers, and deliver user-friendly guides on how to set up other browsers to get the best Sharepoint experience.

Who knows, maybe even Microsoft will adjust things in upcoming patches to make Sharepoint more accessible?

Please spread the word, and feel free to report any issue you've encountered related to this:

http://workspaces.gotdotnet.com/sharepointbrowserenabler

Update: this is a GDN workspace and by nature (or at least experience) not stable. Currently the link is down so please try again later. If you can't access the workspace but have something to report, please do not hesitate to send me an email with your issues, and I'll be sure to register them when GDN wakes up.

Filed under: Office System

Blogmap in 15 seconds
07 February 05 10:53 AM | madsn | 2 comment(s)

Through Mark Bower:

I just placed my blog on the Map(Point). Very cool, even though MapPoint seems to have a funny look at Oslo (It's really not "Frognersætra", but "Frognerseteren", and it's not located right next to Skillebekk).  Check out Chandu Thota  and his blogmap project , takes just about 15 seconds to get it going!

And btw: man I want to make some location aware software *drewl*.. And btw2: I recon I'll put this on my Sharepoint MySite aswell (just so I could add this to my Sharepoint feed:-)

Filed under: .NET General, General Opinions/Comments, Office System

Creating Site Roll-ups in Sharepoint with RSS
04 February 05 04:35 PM | madsn | 1 comment(s)

Roll-ups of information from several (top-level or nested) Windows Sharepoint Services sites has been a “nice-to-have” feature mentioned in several Sharepoint projects I've been involved with. Commercial solutions is available in the market, like the CorasWorks package. However these solutions tend to be too expensive to justify.

 

By using a combination of RSS feed generation and RSS feed consumption webparts (both opensource or freeware) it is possible to create roll-up like functionality with minor configuration effort.

 

The Leadit.Sharepoint.Services, written by Jan Tielens,  provides an RSS feed for every site in the portal, and the SmilingGoat FeedReader displays such feeds in a webpart. (More Sharepoint RSS solutions listed by Daniel here).

 

By configuring the FeedReader as illustrated we can extract information about changes in all or selected Sharepoint lists on a certain site. The FeedReader of course allows us to configure several feeds for display thus creating a nice rollup of for example all Issues lists or Announcements lists.

Some minor features are missing to make this a really powerful setup. Jans "What's New" service should be able to use list inclusion instead of exclusion, and probably you'd be more flexible using multiple intances of George Tsiokos DataView RSS solution for display.

 

All in all this is a couple of hours of configuration at max makes for a pretty cost-efficient roll-up solution which also gives users the possibility to aggregate Sharepoint content in their favorite RSS reader.

 

Filed under: Office System

Enterprise Continous Integration
03 February 05 12:41 AM | madsn | 1 comment(s)

Mike Roberts, one of the lead devs of the CruiseControl.NET project, has just published a paper on Enterprise Continous Integration.

Mike is addressing a very importan issue of Continous Integration and automated build processes, namely "What to do when the build takes too much time?". Integration time was one of the hot potatoes at last years BoF with James Newkirk at TechEd. Mike outlines a solution for splitting up those 10 min -> 12hrs (!?!!?) builds.

We have practiced a lightweight solution of Mikes approach for a good while. In our CI projects we don't use the file system monitor. We've included extended targets for release builds of our "root" projects. When a project is built in release and other projects have dependancies to it, the project deploys the new components directly into the sourcecontrol of the dependant projects. This will automatically trigger a build just as any other change.

Of course, this is not as robust as Mikes approach, but very quick to implement with only some simple checkout/checkin operations.

I've talking a lot about CI for .NET developers these days, related to the upcoming release of Team System and what we can do today with tools like CCNET. I like to address two issues before getting into the details of CI.

Because most development projects that are looking into CI has an existing codebase it's important to acknowledge the physics of Software Reengineering in such a change process. Software Reengineering is the art of regaining control of your codebase by reverse engineering, refactoring and forward engineer your application to improve its evolvability.

Software reengineering is often about introducing improved structure (architecture) and improved platform (technology) at the same time to revitalize legacy software.

The point here (to make it shortish) is that if you're looking at getting into CI, and your software is a potential "2hrs builder", then improved architecture should probably come before new platform. The entire fuzz about Service Oriented Architecture the past years is all about decoupling systems and applications into loosely coupled services, without the need of binary dependencies.

ECI is a necessity, and I'm looking forward to explore how Team Foundation Server is addressing this aswell as following Mikes lead for now, but the most important thing is to keep the services in the architecture managable and loosely coupled. It's easier to publish a new (versioned) WSDL file than dealing with binary dependencies.

Finally: Great work Mike, it's truly appreciated!

 

Filed under: Continous Integration