pm4everyone's blog

SharePoint and Groove Bidirectional Syncing with MS Project and MindManager

Unclaimed Blog — Mon, 06 Nov 2006 22:53:00 GMT

Those series of articles I wrote about SharePoint and Groove web services have finally turned into a real project. Well, still in Beta, but getting close enough for both demos and downloads.
The product works with both SharePoint 2003 and 2007, as well as Groove 2007.

Demo #1 shows TeamDirection publishing MindManager topics and subtopics to a SharePoint server-- and a hosted one at that (free publicity for you, Apptix). Team members then use their browser to update an assigned task in the task list. TeamDirection gathers the latest data and reports back to MindManager. We still have to package it nicely with our site layout, but you can get a direct, sneak peak here.

Demo #2 is similar, but this time TeamDirection publishes MS Project tasks and subtasks to a Groove workspace. Groove doesn't actually ship with a Task List, so TeamDirection provides one for you. It's similar to the SharePoint Task List, and only people with proper permissions can update their tasks. Once again, TeamDirection gathers the latest data and reports back to MS Project. Again, nice packaging to follow, but you can get a direct, sneak peak here.

These demos show TeamDirection Project Plus 2007. If you like what you see, go download the beta here and share a task or topic today.

And yes, that's my voice narrating. Sorry about that.

Posted on SharePoint Blogs

Welcome Microsoft Tech Ed 2006

Unclaimed Blog — Thu, 02 Nov 2006 10:21:00 GMT

If you got here via the Groove presentation at Microsofts Tech Ed conference in Barcelona, here are the links you'll be interested in. If you got here by any other means, I think you'll still be interested in these links. They show you how to get started using Groove (and SharePoint) web services in clear and understandable language. It worked for me!

Part I -- Starting to Talk
Part II -- Comparing SharePoint and Groove Web Service Constructs
Part III -- Working with Tools
Part IV -- SharePoint Lists and Groove Forms Interaction

These four steps form the basic working blocks of our TeamDirection application.

Happy Coding!

Posted on SharePoint Blogs

SharePoint 2003 Querying with GMT DateTime

Unclaimed Blog — Tue, 03 Oct 2006 09:23:00 GMT

The issue is resolving ows_Created and ows_Modified timestamps for users in different timezones. Perhaps the documentation is wrong, but I noticed slightly different behaviour than what was described.

The problem at hand. We are integrating with the basic SharePoint Task List and are heavily dependent on proper date time-- especially across time zones. What I needed was timezone information in a well formed ISO date time format with the UTC hours and minutes, or the date time set to GMT. What I got was neither a well-formed ISO date time or a GMT date time.

So off to Google to find out how to get a SharePoint servers timezone. To my dismay, it wasn't available via a web service call. Horrors! It was, of course, available via the SPModel, but that must run on the server and that isn't an option for our application.

So I went back to the above documentation that describes the Lists.GetListItems web service call and particularly the QueryOptions. From the documentation:

<QueryOptions>
   <IncludeMandatoryColumns>FALSE
      </IncludeMandatoryColumns>
   <DateInUtc>TRUE</DateInUtc>
</QueryOptions>

DateInUtc

TRUE to return dates in Coordinated Universal Time (UTC) format.
FALSE to return dates in ISO format. This element is optional, and
its default values is TRUE.

And I had code doing this:

XmlDocument xmlDoc = new XmlDocument();

XmlNode ndQuery = xmlDoc.CreateNode(XmlNodeType.Element,"Query","");
XmlNode ndViewFields = xmlDoc.CreateNode(XmlNodeType.Element,"ViewFields","");

string viewFields = "<FieldRef Name='" + s_vfID + "' />";
viewFields += "<FieldRef Name='" + s_vfTitle + "' />";
viewFields += "<FieldRef Name='" + s_vfCreatedOn + "' />";
ndViewFields.InnerXml = viewFields;

XmlNode node = null;
node = ls.GetListItems( m_nativeID, null, ndQuery, ndViewFields, null, null);

One would think that would use the default QueryOption behaviour. But then one would be wrong. I found out through much trial and tribulation (once again) that you can't always trust the documentation, or at least your interpretation of it.

If you really want that CreatedOn field to be GMT, you have to specify the QueryOption fragment like this:

XmlDocument xmlDoc = new XmlDocument();

XmlNode ndQuery = xmlDoc.CreateNode(XmlNodeType.Element,"Query","");
XmlNode ndViewFields = xmlDoc.CreateNode(XmlNodeType.Element,"ViewFields","");
XmlNode ndQueryOptions =      xmlDoc.CreateNode(XmlNodeType.Element,"QueryOptions","");

string viewFields = "<FieldRef Name='" + s_vfID + "' />";
viewFields += "<FieldRef Name='" + s_vfTitle + "' />";
viewFields += "<FieldRef Name='" + s_vfCreatedOn + "' />";
ndViewFields.InnerXml = viewFields;

ndQueryOptions.InnerXml = "<DateInUtc>TRUE</DateInUtc>";

XmlNode node = null;
node = ls.GetListItems( m_nativeID, null, ndQuery, ndViewFields, null, ndQueryOptions);

The next question I'm working on: why do RichText fields in SharePoint return html when retrieved via web services? Go head, use that rich text control in a sharepoint task description, and then look at it in MS Word. Hmmm....

Posted on SharePoint Blogs

Do You Know Who You Are?

Unclaimed Blog — Thu, 31 Aug 2006 10:10:00 GMT

Collaboration infrastructure can be a great thing. But it has one major stumbling block; a really big block. And it's preventing the next generation of applications from really taking off. The big stumbling block is you. More precisely, who you are. Or really more precisely, who you are to the collaboration system.

Don't you realize you can be anybody?

Not in the sense of John turning into Bob, though that's possible too, but maybe johnm@hotmail.com turning into johnm@teamdirection.com. Or worse, multiplying johnm's at hotmail, gmail and yahoo in addition to your company.

The problem is one of synergy, in this case the lack of it. Most well-architected systems are built upon smaller well architected building blocks. Do I need to mention how everything in the universe is made up of varying combinations of 100+ elements? Operating systems, office applications and modern conveniences, however, don't quite embody the same elegance.

What we lose is the ability for our poor application designers and developers to tie different collaboration pieces together. Why is MS Office successful? Because they are very well integrated. But these are pieces one company produces, maintains and upgrades. What about your identities? Your identity spans everything from Active Directory to Social Security to your Family agreeing who you are.

Sure, integrated instant messaging will work IFF you use matching SIP or EMAIL ids. Calendaring will work IFF everyone agrees this is your name. My cell phone will be useful IFF I can keep the same number. My drivers license works until I change my address. And so on. If I change anything, I'm screwed. It used to be newlyweds either didn't take a man's last name or hyphenated it as a means to demonstrate empowerment. But now, changing your last name as a result of marriage necessitates a wrenching digital re-identification.

Can we come up with a means to absolutely identify yourself? Social Security number? Phone number? Email? CPU Chip ID? Bio metrics?

Bio metrics is interesting in theory, but you know, I used to not like cantaloupe. Really. I liked watermelon alot, but even though cantaloupes always looked pretty tasty, I had to spit it out every time. Until my thirties. Then I found cantaloupe started tasting really good. Something about my chemistry seems to have changed. So just like changing email, cell phone numbers or home addressses, I have this funny feeling that being able to eat cantaloupe means my bio-metric id has changed too.

At this point, you're expecting me to write something like "But I have the solution. Use the JohnM identification system and everything is solved." And while I think it could work, the rest of the world will likely remain unconvinced.

Unfortunately, I think the answer lies in being able to manage the chaos. The only parallel I'm able to draw is the world wide web and URLs. URLs don't dictate the type of things we can address, rather they give *something* an address in canonical form. Maybe everyone just needs to be canonically addressable.

http://johnmilan.id/

Could house all the forms of identification for John Milan. Yes we still need to agree on what the acceptable forms are, but at this point we still need a way to find them.

Or we can all be GUIDs.

Posted on SharePoint Blogs

Open Groove Question for the SharePoint Community

Unclaimed Blog — Thu, 17 Aug 2006 13:00:00 GMT

I'm not totally dating myself because this movie was a bit before my time. However, 'The Day the Earth Stood still' immediately popped in my mind as I feel like a visitor from the planet Groove touching down in the SharePoint community.

Klaatu Barada Nikto

I mean you no harm :)

But I do have a question (or two) as I ramp up on SharePoint knowledge: What does the SharePoint community think of Groove?

a) Groove is the perfect solution for SharePoint offline
b) SharePoint is the perfect solution for Groove online
c) A means to hire Ray Ozzie
d) SharePoint Uber Alles
e) Interesting, but I'm not sure how it fits
f) Other (please post in the comments section)

The reason I'm asking is I see a natural symmetry between SharePoint and Groove (so much so that we're betting our company on it), and I believe Microsoft does too since they grouped SharePoint, Groove and Project together. But I'm approaching it as the new kid on the block excited to be here. What about you guys who have been around the block a few times?

SharePoint has been immensely successful and seems to be gaining momentum. Does Groove have to prove anything to you? Is it obvious how to connect the two? Package them for your clients?

I hope I get lots of comments, because the silence would be deafening.

Posted on SharePoint Blogs

SharePoint Groove 2007 Web Services Part IV -- Adding Data

Unclaimed Blog — Mon, 14 Aug 2006 12:03:00 GMT

It's time to get our elbows a little dirty. Oh sure, we can initate a conversation with SharePoint/Groove, we can add workspaces to SharePoint/Groove and we can even add tools to SharePoint/Groove. But this is all preliminary stuff. What have you done for me lately? How about adding a little data to our tools? And what's really nice, it further supports my claim that SharePoint and Groove could really have their web services unified and become SharePoint Groove, or Groove SharePoint, depending on your point of view.

I'll pick two tools that I've been working with extensively for the past two weeks. Yes, its taken me a couple weeks to figure out how best to present this information. This may be a bit longer than my earlier posts, but its chock full of information.

The tools we will examine are the standard Task List in SharePoint 2003 and the unstandard TeamDirection Task List in Groove 2007. Why the Task List? My company does Project Management software and I'm partial to tasks. Why an unstandard TeamDirection Task List? Because, as of right now, there is no standard Task List for Groove 2007. We're hoping to change that; whether Microsoft ends up using ours or creates their own, we believe Groove needs a task list (and Project Management, as you might expect :)). In any case, you can download the TeamDirection Task List here, if you'd like to follow along.

The SharePoint Task List is really a SharePoint List and the TeamDirection Task List is really a Groove Form. Remember, I'm claiming SharePoint Lists and Groove Forms are equivalent. Although, in all honesty, I'm not the only one to see the similarities. Groove did too, a couple of iterations ago. I'm sure that's why SharePoint Lists and Groove Forms line up so nicely.

Let's start with the SharePoint Task List. The first thing I'd like to do is add tasks. To accomplish this, you first have to take a detour and meet CAML. I'm not exactly sure what it stands for, and to be honest it doesn't really matter. All I will say is it is aptly named, since its ungainly and something only a mother could love. BUT, its what we have to work with, and in fact it can cross the sands of stateless data transfer. It's just that what makes this journey particulary daunting is the documentation on this kind of CAML is so minimal that its next to useless. Thankfully, we have the ultimate reference implementations in Microsoft Office, and the ultimate HTTP sniffer tool in Fiddler. Fiddler Rocks and is a detour worth taking. If you are serious about WSS, GWS and any WS development, its worth its weight in gold to see what's really going on to make things work. Note: There is a server side object model available from Microsoft here; but it won't help you do smart clients, which is why I'm writing this.

Where were we? Right, CAML. You can add a task with CAML following these three easy steps. We will lift the curtain and start with Step 3 first:

<?xml version="1.0" encoding="UTF-8"?>
<ows:Batch OnError="Continue" xmlns:ows="http://tempuri.org/">
<SetVar Name="DatesInGregorian">TRUE</SetVar>
<SetVar Name="TimesInUTC">TRUE</SetVar>
<Method ID="New">
<SetList Scope="Request">{DF1CC702-9C1F-4C05-8805-BFEF41F5CC28}</SetList>
<SetVar Name="Cmd">Save</SetVar>
<SetVar Name="ID">New</SetVar>
<SetVar Name="urn:schemas-microsoft-com:office:office#Title">My New Task</SetVar>
<SetVar Name=\"urn:schemas-microsoft-com:office:office#AssignedTo\">0</SetVar>
<SetVar Name=\"urn:schemas-microsoft-com:office:office#Status\">Not Started</SetVar>
<SetVar Name=\"urn:schemas-microsoft-com:office:office#Priority\">(2) Normal</SetVar>
<SetVar Name=\"urn:schemas-microsoft-com:office:office#PercentComplete\">0</SetVar>
<SetVar Name=\"urn:schemas-microsoft-com:office:office#StartDate\">2006-08-14T15:00:00Z</SetVar>
<SetVar Name=\"urn:schemas-microsoft-com:office:office#DueDate\">2006-08-16T00:00:00Z</SetVar>
<SetVar Name=\"urn:schemas-microsoft-com:office:office#Body\"></SetVar>
</Method>
</ows:Batch>

So what does this all mean? For one, like a camel, its very finicky. If any of your data types are wrong, for instance your StartDate isn't in Zulu time, the web service request fails. If you mistakenly place the 'DatesInGregorian' element after the 'Method ID=' element, the web service request fails. This is where fiddler shines in that you can set up the exact scenario your smart cilent is trying to produce in MS Word or Excel and watch how they do it.

Some other points of interest are the Method element and the SetVar Name='Cmd' element. Because we are creating a new task, the Method element's value is 'New' and the SetVar Name='Cmd' value is New. As you might expect, when updating, these values change to Update and a real task id, respectively.

A word of caution, though. Don't rely purely on the MS Office applications, for they may not tell you the whole story. For example, if you watch Word create a task, you'd never know you can set the start date. It only sets the due date. How can you find all the available values for your tasks? In other words, how do you find the schema for the list? Ah, that was Step 2:

SharePointProxies.Lists ls = new SharePointProxies.Lists();
... set up the credentials and Url ...
XmlNode result = ls.GetList( listID );

The result XML divulges the schema of a particular list. I put a sample of the SharePoint Task List schema here. This schema gives you important information on what's available, either purely for reading (like creation and modification stamps) or updating (like our StartDate).

So how do you find that list ID? That is Step 1, Finding your List ID:

SharePointProxies.Lists ls = new SharePointProxies.Lists();
... set up the credentials and Url ...
XmlNode result = ls.GetListCollection();

The result XML divulges all you lists, descriptions and identifiers. I put a sample of the SharePoint list collection XML here.

So let's review the SharePoint steps to add data in order:

Step 1
Get a listing of all the lists in your SharePoint Workspace and associate ids with lists you want to work with.

Step 2
Get familiar with what the schema for your list has to offer. Ideally you will have an application you can sniff that works with your list.

Step 3
Start adding data. Here's a fuller example for creating a task. Remember that big CAML up above? Here's how you send it (Note that it goes to a Document Workspace Service instead of a Lists service!):

SharePointProxies.Dws dws = new SharePointProxies.Dws();
dws.Credentials = this.Credentials;
dws.Url = m_uri + "_vti_bin/dws.asmx";

string result = null;

try {
result = dws.UpdateDwsData( camlString, null );
}

The resulting XML of this call is a list of new ids for all the tasks you have created. We will leave this as an exercise for the reader to match new identifiers with tasks (hint: its returned in order of creation).

Are you ready for a bit of Groove Form task creation? Let's get started on that.

If you go to the TeamDirection SharePoint Groove Solutions page, you see a TDWorkspace. Download and double click on this to install it in Groove 2007 if you'd like to apply these samples to something real.

Like the SharePoint Task creation, it takes 3 general steps to perform a Groove Task creation, but we will cover the steps in more detail.

Step 1
Get a listing of all Forms within your Groove Workspace

We covered this a bit in Part III of the series with the acquireTelespaceTools example code.

Step 2
Get familiar with what the schema for your form has to offer.

Where SharePoint uses CAML to manipulate list data via WSS, Groove 2007 made the (good) decision to use System.Data.DataSets to manipulate form data via GWS. I have to bone up on SharePoint 2007 and their support of DataSets, but I like the idea in general as DataSets represent a nice abstraction. You can still work with XML if you really want to, and in fact I'll show you a Groove XML schema for our Task List, but DataSets will make your life easier. And don't forget about Hugh Pyle's blog and his samples.

If we've completed step 1 successfully, we get the forms schema by querying for it. SharePoint lists also support querying, of course, but unlike Groove provides a distinct schema acquisition method. Groove supplies the schema by query flags. The code looks like this:

protected System.Data.DataSet getSchema() {

GrooveProxies.Forms2 svc = new GrooveProxies.Forms2();
buildRequestHeader( svc );

GrooveProxies.RecordQuery recordQuery = new GrooveProxies.RecordQuery();
recordQuery.FormURI = "";
recordQuery.IncludeFileAttachmentContent = false;
recordQuery.QueryMetadataOnly = true;
recordQuery.UnreadRecordsOnly = false;
recordQuery.ViewURI = "";
recordQuery.WhereClause = "";

// The query is really a schema retrieval, but this is the mechanism to retrieve
WSDLProxies.Forms2RecordDataSet fds;
fds = svc.QueryRecords(recordQuery);

// Make a DataSet to contain the records
System.Data.DataSet recordDataSet = new System.Data.DataSet("RecordDataSet");

// Load the schema into the DataSet
if (fds.Schema is System.Array) {
System.Xml.XmlNode[] schemaNodes = (System.Xml.XmlNode[])fds.Schema;
foreach (System.Xml.XmlNode schemaNode in schemaNodes) {
System.IO.StringReader schemaReader = new System.IO.StringReader("<?xml version=\"1.0\"?>" + schemaNode.OuterXml);
recordDataSet.ReadXmlSchema(schemaReader);
}
}

recordDataSet.AcceptChanges();
recordDataSet.EnforceConstraints = false;
return recordDataSet;

}

If your curious what a Groove Form schema looks like, here is the xml for our Task List.

What immediately stands out in this schema as opposed to the SharePoint Task List schema is the presence of multiple Tables. Groove Forms, and DataSets, can contain multiple tables, whereas the SharePoint 2003 (at least) lists contain only a single table. This makes Groove Forms not only able to handle SharePoint list schemas, but even richer tools like InfoPath schemas as well (which in fact Groove 2007 does). By the way, the table defining our task is named "_451_465619523540032702E_43034". I'm going to ask our developer if we can name it 'Task' instead.

GOTCHA NOTE: Its always the little things that eat up time, and here's one that I found. When you build your request headers, the Url value you use changes depending on the context of your web service call. Let's revisit a sample web service request Url.

/GWS/Groove/2.0/Spaces/grooveTelespace/8ecctni3u4hzrvpxhhymbmqcdd8q8itexbttk7s

Which is fine if I send requests to the Spaces proxy, but I need to change Spaces to Tools like so:

/GWS/Groove/2.0/Tools/grooveTelespace/8ecctni3u4hzrvpxhhymbmqcdd8q8itexbttk7s

And, when you talk to specific tools, like the Forms, you need two changes: no only from Tools to Forms, but you need to append DataModelDelegate. DataModelDelegate is a Groove API construct from way back and represents the Data controller of a Model View Controller pattern. So talking to a form requires an url like:

/GWS/Groove/2.0/Forms2/grooveTelespace/8ecctni3u4hzrvpxhhymbmqcdd8q8itexbttk7s/DataModelDelegate

Finally, when dealing with records within a form, you append the record id like so:

/GWS/Groove/2.0/Forms2/grooveTelespace/8ecctni3u4hzrvpxhhymbmqcdd8q8itexbttk7s/DataModelDelegate/12321.212352233

Step 3
Start adding data.

Here's the easy part with the Groove Forms interface. Since it works so well with System.Data.DataSets, adding a task to our task form is as easy as adding it to our data set. In fact, Hugh has a nice example of exactly this.

For our task specific application, it might look like this:

DataTable dt = ds.Tables ["_451_465619523540032702E_43034"];
DataRow dr = dt.NewRow();

dr["Title"] = "Task 1";
dr["description"] = "I am the first task";
dr["startDate"] = "2006-08-14T08:00:00";
dr["dueDate"] = "2006-08-15T17:00:00";
dr["Priority"] = "(2) Normal";
dr["Status"] = "In Progress";
dr["PercentComplete"] = 0.5;
dr["AssignedTo"] = "grooveIdentity://asdfawtadfglksa";

dt.Rows.Add(dr);
tool.Insert(ds);

Both SharePoint and Groove provide a means to create, update and delete data. We haven't looked at deleting data, but its there. The other thing we might have noticed is query capabilities for Groove. Rest assured SharePoint has query capabilities as well. And rest assured we will cover querying in the near future.

Now if I had a company, and I knew a little something about SharePoint and a little something about Groove-- possibly even enough something to make me dangerous-- do you think I'd be looking into a way to seamlessly transfer data to and from SharePoint Lists and Groove Forms? Yeah, I think so.

But what you may not know is Groove Forms must be designed by the Groove Forms Designer. Unlike SharePoint, which allows me to modify list schema via WSS (that's a whole nother topic!), Groove can only inject 'well formed' forms into a workspace. So we can't quite achieve total data mobility, however, what we can do is move data between well understood workspaces. An example would be data between a default SharePoint Document Workspace and a richer Groove Workspace. I'm partial to the TD Workspace myself, and soon I may just point you to a tool that does exactly what I've described.

Posted on SharePoint Blogs

SharePoint and Groove 2007 Integration -- A Vision, Some Samples

Unclaimed Blog — Sat, 05 Aug 2006 02:09:00 GMT

Sometimes while blogging an idea hits you, and you have to decide whether to pursue it or let it go. Well, I chose to pursue it. And I convinced some smart people to pursue it too, so it just might work!.

I've been doing a series on SharePoint and Groove differences and similarites with respect to web services. What struck me in Part II was not just how similar SharePoint and Groove web services are, but also how similar the end products are. In fact, the biggest, obvious difference between the two is the richness of tools available for the two systems. For instance, a default Document Workspace in SharePoint contains 9 tools where a default Groove Workspace contains 3. If only Groove Workspaces had a few more tools.

TeamDirection will be happy to provide a few more tools.

Today on our site we are opening the first, simple Solutions Center whose goal will be bringing parity to SharePoint and Groove. Not just with the tools, which we will be fleshing out and making available as they come, but also with integration and synchronization products. Things that will enable you to move data easily from one collaboration solution to the other.

For a developer, this will mean a library that abstracts collaboration workspaces. This means you can create a workspace and tell the library if you want it to be SharePoint or Groove. Or create tools with either a SharePoint or Groove template.

For a user, this will mean a product (like, Project Management) that allows you to pick where to collaborate (SharePoint and Groove again) and also how to collaborate-- with a smart client on everyone's desktop, or with a single, manager desktop that synchronizes data with SharePoint lists and Groove forms.

We've been with Groove since the early days-- way back in 2001. Through hard work and great products, we became the leader in Groove tools. And now here in 2006, we plan on more more hard work and more great products; and we'd like to be a leader in providing SharePoint tools too.

Posted on SharePoint Blogs

SharePoint and Groove Web Services Part III -- Adding Tools

Unclaimed Blog — Mon, 31 Jul 2006 21:49:00 GMT

We authenticated in Part I, and created Workspaces in Part II, and we are about to add our first tools here in Part III. But first I'd like to revisit SharePoint and Groove workspace creation, for I did them a disservice by not talking about custom templates. These are templates created by you, that describe either the components of a workspace, or describe a component itself.

In Part II I stated that Groove's workspace creation is designed to be much more generic than SharePoint's Document Workspace. This is not entirely true. As a few people pointed out, and as Microsoft's Working with Templates page attests, you can in fact create, load and instantiate custom templates with SharePoint. SharePoint calls these Site Templates and List Templates. In Groove nomenclature, these are called Groove Space Archives (.gsa file extension) and Groove Tool Archives (.gta file extension) and while they're not techinically templates, you can use them as such.

Where SharePoint and Groove differ with regard to populating custom spaces is how they differ with populating custom tools themselves. You cannot register a custom template with SharePoint strictly using WSS. With Groove GWS, however, you can, sort of. SharePoint site templates and Groove space archives are really immaterial to the problem of created templated workspaces. The root of the problem lies with the tool templates. By this I mean both SharePoint and Groove allow you to create empty workspaces and to add new tools based on a template-- so your tool layout could exist purely in your smart client code if you wished.

For SharePoint, you must be use their HTML based administration UI to add a custom template to the system, which then allows WSS to add that custom template to a workspace. SharePoint then acts as its own distribution mechanism for the template, but cannot propogate the template to other SharePoint servers.

Groove, on the other hand, because of its peer-to-peer nature, can. In fact, Groove used to allow you to add a general template as long as you identified a server on the internet to fetch it from (this is how our first PM tool works). You can't do that anymore, but you can add a Groove Form with a custom schema, design and view, and not need to identify a server to fetch it from. Why? Because a Groove Form is self-contained. And once its registered on an endpoint, it is propogated to other endpoints by Groove itself. And this process of adding a custom Groove Form can be done by GWS.

But that's yet another part. Hugh Pyle has been extremely helpful in showing me how this works, but I have to work through it myself first before I can write about it. In the meantime, on to the this weeks installment: Adding tools to SharePoint and Groove.

What is a workspace without any tools? Not much. So both SharePoint and Groove provide a set of default tools a developer can add via web services. SharePoint and Groove also provide a way to create default workspaces that contain a default set of tools. As we saw in Part II, a SharePoint Document workspace comes packaged with tools like Announcements, Share Documents, Task List and such, while Groove's default workspace contained only Files, Discussion and Members. (By the way, this is an disparity we hope to correct soon!).

But what if our SharePoint space needs a second Document Library tool, and our Groove workspace needs a Groove Form? We add them with the code outlined below.

For SharePoint, I need to identify the tool template I would like to use. Assuming I have the workspace in mind, maybe even a workspace I just created, I would use the Webs service method

GetListTemplates();

This will return an XML string you can parse for specific template names and identifiers. It's generally human readable, which is good, since you do have to know what you're looking for. But once you've identified the template id for a Document Library ("101"), you could code something like:

public void AddDocumentLibrary() {
    // We've gotten the templates via Webs, now we use the Lists service
    // to add a tool based on a template
    SharePointProxies.Lists l = new SharePointProxies.Lists();

// We're caching our credentials
l.Credentials = this.Credentials;

// and using the workspace we created in Part II
l.Url = "http://myserver/myroot/uniquename" + "/_vti_bin/lists.asmx";

// The result xml from the AddList method XmlNode resultNode = null;

   // the display name of the tool we will add
   string toolName = "My Display Name";

   // its template id
int toolID = 101;

    try {

        // if successful, the result will be XML we can parse for
        resultNode = l.AddList( toolName, "My Description", toolID );

        // the result id, which looks a alot like a GUID
        // I like to check for both name and id
        resultID = parseForID( toolName, toolID.ToString() );

}

   catch ( System.Exception ex ) {
        reportError( aReporter, ex.Message );
    }

   finally {

       if ( l != null ) {
           l.Dispose();
   l = null;
   }

   }

}

// a simple routine to find the ID from the AddList result XML
private string parseForID( System.Xml.XmlNode xmlNode, string name, string templateID ) {

    System.Xml.XmlAttributeCollection attrs = xmlNode.Attributes;

XmlNode idNode = attrs.GetNamedItem( "ID" );
    XmlNode titleNode = attrs.GetNamedItem( "Title" );
XmlNode serverTemplateNode = attrs.GetNamedItem( "ServerTemplate" );

string id = ( idNode == null ) ? "" : idNode.Value;
    string title = ( titleNode == null ) ? "" : titleNode.Value;
    string serverTemplate = ( serverTemplateNode == null ) ? "" : serverTemplateNode.Value;

    if ( title == name && templateID == serverTemplate )
        return id;
    else
return null;

}

The end result of the above code is the addition of a new Document Library to the SharePoint workspace. An interesting thing about this particular tool is it also supports Web Distributed Authoring and Versioning, or WevDAV. This is a nice tool in two respects: 1) You have a choice of using SharePoint WSS or WebDAV to work with it and 2) It supports versioning-- which is very hard to do in a purely peer-to-peer environment.

The pattern for adding a Groove Form to a new Groove workspace is very similar. First we call the Groove version GetListTemplates, which is part of the Tools service and is called:

ReadAvailableTools();

Also similar to SharePoint is you have to know what you are looking for. This call returns an array of templates you can iterate through. Each template contains a human readable Name and a not so human readable ComponentResourceURL (your remember those?). The ComponentResourceURL is like the SharePoint template identifier. The code for adding a Groove tool via GWS follows:

// Here is an OSD URL that identifies a Groove Form and its version
private static string s_grooveFormComponentResourceURL = "http://components.groove.net/Groove/Components/Root.osd?Package=net.groove.Groove.Tools.Business.GrooveForms.Groo veForms_TPL&Version=5&Factory=Open";

public string AddGrooveForm() {
    // Tools is the container we add a Tool to
    GrooveProxies.Tools tools = new GrooveProxies.Tools();

// refer to Part I or Part II for more detail
    buildRequestHeader( tools );

    // refer to Part I or Part II for more detail
    tools.Url = m_grooveHost + m_grooveTelespaceTools;

    // instantiae a tool to fill out
    GrooveProxies.Tool tool = new GrooveProxies.Tool();

    // with name
    tool.Name = "My Display Name";

    // and all-important identifier
    tool.ComponentResourceURL = s_grooveFormComponentResourceURL;

    // the result is the tool identifier you can append to
    // m_grooveHost
    string toolID = tools.Create( tool );

     if ( toolID == null || toolID.Length == 0 )
         return null;
    else
return toolID;

}

private bool acquireTelespaceTools() {

    // We go through Spaces container to find the Space tool
// to find the Tools container.
    GrooveProxies.Spaces spaces = new GrooveProxies.Spaces();

    // refer to Part I or Part II if you
// want to see headers built
    buildRequestHeader( spaces );

    // again, refer to Part I or Part II for more detail
    spaces.Url = m_grooveHost + m_grooveTelespace;

    // retrieve data about the space
    GrooveProxies.Space space = spaces.ReadSpace();

    if ( space == null )
        return false;

    // retrieve the Tools container for the space
    m_grooveTelespaceTools = space.Tools;

return true;

}

The Groove Forms tool also has lots of nifty features, but we'll get to them in another installment, I promise. In the meantime, what you have seen is how to add not just SharePoint Document Libraries or Groove Forms, but any tool given the proper template id. For each system, you could iterate through the templates returned by either GetListTemplates or ReadAvailableTools and add them to a workspace, thus creating a workspace containing every possible web part or Groove tool.

In this case, SharePoint and Groove are nearly identical in how you discover and add tools. The real differences lie in the tools themselves. Each tool tends to, understandably, acquiesce to the strengths and weaknesses of their architecture. The SharePoint Document Library supports versioning as well as robust internet protocols, while the Groove Form supports peer-to-peer distribution of schema, design and content.

We will take a more detailed look at both in Part IV.

Posted on SharePoint Blogs

SharePoint and Groove web services comparison and how to -- Part II

Unclaimed Blog — Mon, 24 Jul 2006 22:04:00 GMT

We left off with how you get past the authentication gate and talk to both SharePoint and Groove. SharePoint uses the familiar challenge/Response pattern and Groove implements a localhost/registry solution. Now that we have our clearance, let's see what awaits us on the inside. Here is a table outlining the basic services for each system:

SharePoint

Administration	Manage Site Collection
Alerts	Alerts for list items
Document Workspace	Manage document workspaces
Forms	HTML Display forms for list content
Imaging	Manage picture libraries
Lists	Working with lists and data
Meetings	Manage Meeting workspaces
Permissions	SharePoint Services Security
Sites	Information about workspace templates
Users and Groups	Manage users and groups
Versions	Working with file versions
Views	Presentation views of Lists
Webs	Managing workspaces and subworkspaces

Groove

Accounts	Provide Account and Identity info
Calendar	Manage Calendar Tool
Contacts	Contact info for Identities
Discussion	A Form presented as a Discussion tool
Events	Read events you subscribe to
FilesBase64	A Files tool in Base64
FilesDIME	A Files tool in DIME binary attachments
Forms	Highly configurable Groove Form (Kind of like HTML Form, but more powerful)
Local	Methods that invoke the Groove UI
Members	Workspace membership info
Messages	Read and Send instant messages
Properties	Version info for Groove client and web services
Spaces	Manage Groove workspaces
Subscriptions	Monitor Groove events with subscriptions
Tools	Manage tools within a Workspace
VCard	Detailed info for an Identity

I've been claiming that SharePoint and Groove are more similar than not. What do you suppose a merging of the two might look like? While its not a one-to-one correspondence, there are definitely similarities between the two web service APIs. But first let's define a few terms:

A Workspace is a SharePoint Site is a Groove Workspace.
A Tool is a SharePoint Web Part is a Groove Tool.
A User is a SharePoint User is a Groove Account and Identity.

And finally, the most important:

A Form is a SharePoint List is a Groove Form.

Given the above terms, I can claim that the following web services are similar:

SharePoint	Groove
Administration, Sites	Spaces
Alerts	Events, Subscriptions
Document Workspace	Space*
Meetings	Space*
Lists, Views, Forms	Forms
Users and Groups	Accounts, Members
Webs	Spaces

*Groove follows a container/item pattern whereby the web service often exposes a container, which in turn manipulates specific items within that container. For spaces, we can ask Groove for all workspaces, identify a particular Space, and then drill down for more information.

So let's do some sample code. First up is SharePoint.

Now that I can talk to SharePoint, I'd like to create a Workspace. First I must determine where I want to locate it. SharePoint follows a hierarchical convention much like a file system. It happens to be a database under the covers, but the effect is that standard URL addressing works just fine.

Let's say we have a SharePoint server set up at

http://myserver

And that we've set up a root site at

/myroot

We can then address the location we want to base our creation as

http://myserver/myroot

So we use the SharePoint Document Workspace Server (which we will call DWS) in the following code:

// the Document Workspace Service
SharePointProxies.Dws dws = new SharePointProxies.Dws();

// we're caching our credentials
dws.Credentials = this.Credentials;

// the web service address
dws.Url = "http://myserver/myroot" + "/_vti_bin/dws.asmx";

string result = "";

try {

    result = dws.CreateDws( "uniquename", "", "My Title -- Hello World!", "" );

}
catch ( System.Net.WebException webex ) {
    reportError( webex );
}
catch ( System.Exception sysex ) {
    reportError( sysex );
}
finally {

    if ( dws != null ) {
        dws.Dispose(); // Don't forget to dispose these web service calls!
   dws = null; // I try to help the garbage collector whenever I can.
}

Uri newWorkspaceLocation = parseResultForUri( newWorkspaceLocation );

And voila, you have created a new Document Workspace 'under' http://myserver/myroot with an address of

http://myserver/myroot/uniquename

Now what is a Document Workspace? It is a blank workspace with the following web parts added:

1) Announcements
2) Shared Documents
3) Tasks
4) Contact List
5) Event List
6) Discussion
7) Surveys
8) Links
9) Members

Obviously all these web parts weren't individually represented in the SharePoint services defined above. What most of them are (Announcements, Tasks, Contacts, Events, Discussion, Links, Surveys and Share Documents) are permutations of a SharePoint List. You can verify this by making a SharePointProxies.Lists.GetListCollection call, which tells you the lists in a SharePoint workspace. In fact, the only thing that is not a list is the Members web part. Hmmm... interesting...

And now let's look at instantiating a Groove Workspace.

Groove has a shallow addressing scheme, which means yes there is a hiearchy for workspaces, but its a single parent/child relationship. You can organize workspaces into hiearchical folders via the Groove Launchbar UI, however, for addressing purposes, you usually work with an url like:

http://localhost:9080/<groove service>/<identifier>

The Groove version of the SharePoint Document Workspace Service is the Spaces service. Spaces is short for Workspaces and, unlike SharePoint, Groove provides the unique identifier for you. In fact, Groove usually provides the unique identifier for everything.

Here is code to create a Groove Workspace.

// This bundle of info is an identifier for the Groove default workspace.
// It's a more generic version of the SharePoint Document Workspace
// in that there are many different Component Resource URLs you
// could use to instantiate a space. This one specifies we
// should use version 4 of the default workspace, which
// comes with a files tool and a discussion tool.
private static string s_grooveWorkspaceComponentResourceURL =
"http://components.groove.net/Groove/Components/Tools/System/SystemTools.osd?Package=net.groove.Groove.Tools.Syste
m.GrooveDefault_CST&Version=4&Factory=Open";

// remember the context that Groove needs?
// this assumes you went through the discovery process in Part I
// and have cached the necessary values.
private void buildRequestHeader( WSDLProxies.Spaces spaces ) {

    spaces.GrooveRequestHeaderValue = new GrooveProxies.GrooveRequestHeader();
    spaces.GrooveRequestHeaderValue.GrooveRequestKey = m_grooveRequestKey;
    spaces.GrooveRequestHeaderValue.GrooveIdentityURL = m_grooveIdentity;

}

private bool createGrooveWorkspace() {

    // Spaces is the container service for Space operations.
    GrooveProxies.Spaces spaces = new GrooveProxies.Spaces();
    buildRequestHeader( spaces );
    spaces.Url = m_grooveHost + "/GWS/Groove/2.0/Spaces/";

    // setdata to the particular item
    GrooveProxies.Space space = new GrooveProxies.Space();
    space.Name = title;

    // use the container to invoke the operation
    string grooveTelespace = spaces.Create( space, s_grooveWorkspaceComponentResourceURL );

    // grooveTelespace now contains the <groove service> and <identifier>
    // so you can concatenate m_grooveHost and grooveTelespace for future
    // calls.
}

The result of createGrooveWorkspace is a new, default Groove Workspace. Now what is a default Groove Workspace? As of today, it is a blank workspace with the following tools added:

1) Files
2) Discussion
3) Members

The files web service is provided by either GrooveFilesBase64 or GrooeFilesDIME. The discussion web service is provided by GrooveDiscussion, however, it is actually a GrooveForm with discussion semantics-- much like those SharePoint lists masquerading as various tools. And the member web service is provided by GrooveMembers.

As we noted above, Groove's workspace creation is designed to be much more generic than SharePoint's Document Workspace. It used to be, in Groove, you could create your own workspace templates and feed that workspace's component resource url and presto, you'd have a workspace designed to your template specs. However, I don't believe this feature is available anymore. Maybe in the future.

What you can do is manipulate individual tools to configure the Groove workspace how you'd like. For instance, our product will be adding a Groove Forms tool. However, the Groove Forms tool cuts a wide swath of functionality, and really deserves its own part.

Perhaps Part III?

Finally, for all you old timers out there, no you weren't dreaming. You were probably thinking that Groove component resource URL looked a lot like something from the Open Software Description Specification. And in fact, you would be correct. Pre-Groove 2007 you could use OSD specifications to inject new functionality into Groove.

This is on hiatus for the moment, but I wouldn't be a bit surprised if OSD injection becomes available once again in a future version.

Posted on SharePoint Blogs

SharePoint and Groove web services comparison and how to -- Part I

Unclaimed Blog — Wed, 19 Jul 2006 00:18:00 GMT

I've always wanted to start a series. And while I'm no Alexandre Dumas, I'm sure the topic will be no less exciting: Comparing SharePoint web services with Groove web services. OK, so maybe there's not as much intrigue but with the convergence of SharePoint and Groove its no less interesting and quite a bit more relevant.

My company produces Project Management software for both SharePoint and Groove. We just released our SharePoint product that uses web services and while we've been shipping a Groove tool for the past three years, we're making a transition to web services for Groove 12. Over the course of several web posts, I will share my experiences with both web service platforms and hope to draw a conclusion on where things are headed. As a teaser, I believe SharePoint and Groove will oneday converge since their models are very, very similar. I talk about this a little bit here.

Note: for brevity, I will refer to SharePoint Web Services as WSS, and Groove Web Services as GWS. Also, I will assume you can set up the web service proxies for both systems. There's plenty of help for WSS. For GWS, a good jumping off point is Hugh Pyle's blog. I'm here to help you get up and running. On to the story....

Everything has a beginning and when talking web services you have to start with authentication. If you're not authenticated, you won't get far. So how to authenticate?

For both systems, authentication information is bundled into each web service request. However, how they bundle the information is quite different. With WSS, each web service request contains credential information. This is standard SOAP that works with the System.Net.CredentialCache. For example:

SharePointProxies.Lists l = new SharePointProxies.Lists();
l.Credentials = this.System.Net.CredentialCache.DefaultCredentials.

If your default credentials are not sufficient, you will need to create your own credentials, preferably with the credentials UI Microsoft provides. This is the standard Challenge/Response scenario common to Client/Server... oops, I mean Smart Client/Web Service computing.

That's about it for SharePoint since you can only log in as a single entity. Now that you have the proper credentials, you can access WSS for site information, member lists, tools and such. Just be sure to keep that credential handy.

Groove is a different beast, however. While it is a web service endpoint, it is in fact the world's smartest smart client. By this I mean you will most likely be accessing GWS via localhost on the same computer as your application. Because of this, GWS does not use System.Net.ICredentials, but instead creates a separate authentiaction requirement: windows registry lookups for key values.

What's happening is this: because Groove is a smart client most likely running on your local machine, it sets keys for access into the CURRENT_USER hive in your registry. Specifically:

// Read GrooveLocalHTTPPort
Microsoft.Win32.RegistryKey grooveRegKey =     Microsoft.Win32.Registry.CurrentUser.OpenSubKey( "Software\\Microsoft\\Office\\12.0\\Groove" );
string grooveHost= "http://localhost:" + grooveRegKey.GetValue(    "GrooveLocalHTTPPort" ).ToString();

// Read LocalRequestKey
Microsoft.Win32.RegistryKey grooveWebServicesRegKey = Microsoft.Win32.Registry.CurrentUser.OpenSubKey( "Software\\Microsoft\\Office\\12.0\\Groove\\WebServices");
string grooveRequestKey = (string)grooveWebServicesRegKey.GetValue( "LocalRequestKey");

There is a third key for remote access, but it's left to the user to transport the key value from the computer running GWS to the machine that wants to talk to GWS. Because these keys are generated every time your start Groove, its a non-trivial challenge. The port is also generated by Groove in that 9080 is preferred, but it will bounce higher if another process has already grabbed 9080. So we perform the lookup on this as well.

Once you have the keys, you still must figure out who you want to be. This is done by accessing the GrooveAccounts. You can have multiple user accounts in Groove, much like multiple logins in Windows. Additionally, each account can have multiple identities. GWS wants to know exactly what Identity you want to be in order to work. Maybe you only have one Account with one Identity, in which case life is simple. But if you have multiple Accounts with multiple Identities, then you will need to settle on one. Here is how you can iterate through the choices:

// Create the GrooveAccounts service
GrooveProxies.Accounts accounts = new GrooveProxies.Accounts();
accounts.GrooveRequestHeaderValue = new GrooveProxies.GrooveRequestHeader();
accounts.GrooveRequestHeaderValue.GrooveRequestKey = grooveRequestKey;
accounts.Url = grooveHost + "/GWS/Groove/2.0/Accounts/";

// Read the accounts-- this is the actual Web Service Call
GrooveProxies.Account2 [] result = accounts.Read2();

// Display accounts and identities
foreach ( GrooveProxies.Account2 account in result) {

    System.Console.WriteLine( account.Name );

    foreach ( GrooveProxies.Identity2 identity in account.Identities) {

        System.Console.WriteLine( "\t" + identity.Name );

    }

}

Once you select your Identity, you have the GWS equivalent of the WSS System.Net.ICredential.

Did you notice the GrooveRequestHeader? This is how GWS extends basic SOAP packets to include its own keys and identity information. Whereas WSS uses a basic SOAP property

SharePointProxies.Lists.Credentials

GWS requires that you use:

GrooveRequestHeader

for authentication. And remember, those GWS key values will change every time the Groove process is restarted, so you can't cache keys. Instead, you should have a routine that does lookups for you when you start a series of operations. Also, unlike WSS, you cannot use the Microsoft credentials UI since GWS does not use System.Net.ICredentials. In fact, Groove has its own login UI that will challenge the user for a password. However, people (like me) often choose the 'Remember Password' option in Groove and rely on a successful Windows login for user validation. Once GWS is accessible, it will provide you the choice of Accounts and Identities you can use.

Wouldn't it be nice if Groove used the System.Net.ICredentials system as well? I suspect this will happen in the future.

Congratulations, you've just been cleared to talk WSS and GWS! But remember that this is a series. We will find out how to gather information about Sites and Workspaces in Part II.

Posted on SharePoint Blogs

SharePoint Web Part vs. Smart Client using WSS

Unclaimed Blog — Tue, 11 Jul 2006 08:10:00 GMT

Suppose you wanted to build a Project Management solution and you thought SharePoint was pretty neat. Then you got a group of programmers you respected and you knew could do the job. Then imagine this group of programmers had to decide whether to build a web part or a smart application. At the end of the discussion would you a) have consensus and begin coding right away or b) have to come back the next day with doughnuts and alms to ease the tension and hash it out again.

If you're like us, then the answer was .... errr... (b). The arguments were plentiful and forceful, but mostly boiled down to ease of deployment and management for web parts vs richer UI and offline mobility for smart clients.

Before I get too far down the road, however, I should point out how overweighted towards web parts the SharePoint community seems to be. For instance, doing a cursory search of SharePointBlogs.com yielded only two(!) mentions of smart client technology:

Henk Hooiveld's blog on SharePoint and Office
Todd Baginski's SharePoint 2003 and MOSS 2007 blog

Obviously the developer community has spoken and it's web parts in a runaway. But the right decision for a particular circumstance is the right decision, even if everyone else thinks you're wrong .

For me it came down to the nature of the application and mobility. Mind you, I have my set of biases. Before SharePoint we developed a product for Groove (also project management), which carries smart client technology to the nth degree (must have been doing something right though, since Microsoft bought them and created the SharePoint, Groove and Project group).

The application aspect of the decision is the most rock solid for me. Project Management has enough complexity that it can be difficult to manipulate the various components without a lot of serious DHML and vbscript. And even then it seems problematic to do drag and drop scheduling in an interactive gantt chart through your browser without an ActiveX control of some sort-- and that would obviate the east of deployment advantage. While some approximation has been done by a few companies, it has taken them several iterations to approach basic usability. And we wanted to make usability one of our selling points.

The mobility aspect of our decision really comes down to when you believe will happen. I fully believe that some day no matter where you are, you will be able to access the internet. But that day has not arrived yet, and it won't arrive by the end of this decade either. And the day it does arrive, it actually won't because that will be the day they announce public travel to the moon, with internet connectivity coming soon. But maybe you reading this at Starbucks on your Danger Sidekick and shaking your head at the crumudgeon who just doesn't get it. Well, go start your own company .

Now I absolutely acknowledge the inherent distribution superiorty of a web application, or web part. However, I would argue its not quite as superior as it once was. Sure, if faced with the choice of purchasing boxes of software and installing them machine by machine, then I bow down before the web server and chant 'ease of deployment'. HOWEVER... those were the bad old days. Today, tools like SMS and technology like .NET reduce the web application distribution advantage to almost even. I recall a recent conversation with an IT person at a Fortune 500 company who stated they can update all 15,000 machines with new software in under 60 minutes.

So our decision came do to this: If you believe your application is complex enough and you don't believe in an 'always on anywhere' internet, then the benefits of a smart client will outweigh the single (but substantial) benefit of deployment. If you want to build the world's best name, rank and serial number data entry application, then I think a web part makes absolute perfect sense. But if you want to create an app that that is focused on user experience and furthers what's possible with todays rich UIs, then a rich, smart client is the way to go.

We certainly hope so.

Posted on SharePoint Blogs