Tag Archive for SharePoint

Word 2007 and Sharepoint Workflows

I’ve got a couple of questions about Word 2007 integration with Sharepoint 2007, and several problems that occur because of it:

The Mysterious Checked-Out Error

Let’s say I have a workflow attached to a document library which creates a data collection task, and when that task is completed updates the document metadata with the task data (say, “Ask for Comments”). For some reason if I leave the document open in Word and complete the task, I get an error in the workflow claiming the document is checked out and can’t be updated.

Needless to say, the document isn’t. Word only checks out the document before the actual save operation, not whenever it’s open. If my workflow updates the metadata directly, without a data collection task, it does work. If Word is closed – it does work.

Even more strangely – if instead of updating the metadata I try to delete the item, it works without a hitch. Update – no. Delete – no problem.

I’m pretty much stumped here, and I’d appreciate any idea.

 

Automatically Closing Word’s Connection

Now we have a different workflow – once I’ve saved my document to the library, a workflow evaluates the metadata and moves it to a new folder depending on the context. Copied aside and then erased, or possibly renamed based on some bit of metadata. The workflow works fine and the document vanishes from the library, but Word is still open and still points to the original location. If the user corrects a single word and presses Ctrl-S, the document will be resaved to the original location, the workflow restarted an a new copy made.

Is there a way to force Word to update the folder or file it’s pointing to? Alternately, a way to cause Word to close the document after saving?

“Trial Expired” errors in unexpected places.

I’ve installed MOSS 2007 RTM on a couple of test VPCs here, using the 180-day trial version. Everything worked fine until I tried to create a new page in my Publishing Portal – suddenly received a “The trial period for this product has expired” message and it won’t let me create it. This is strange, since I got this key from Microsoft Downloads 3 days ago. Switching the server to an MSDN key didn’t help either, so it wasn’t a licensing issue.

Strangely enough, most MOSS features did work – only a handful, like creating pages and associating a custom VS2005-build Workflow with a document library – caused this error. Other distinctly MOSS-based features like publishing and search worked like a charm.

The first suspect was the fact my server is running on a Domain Controller. Seems there’s a well-known problem with running MOSS on a DC, and an official workaround by Microsoft that sets some registry keys and reconfigures the server. This problem, however, should have prevented any site from loading, not only that specific error. And anyway, it didn’t help.

What several furious minutes of googling revealed is that this is caused by a server in a farm scenario (even a single-server farm) whose application pools are using non-admin accounts. In my case, it was the default NetworkService and LocalService accounts for the DefaultAppPool, MSSharepointAppPool and OfficeServerApplicationPool pools. When I switched them all to using a domain account with admin rights on the server, everything started working.

So in summary:

1) This error still happens on the RTM release, not just the B2TR release as mentioned in the forum post.

2) I can only assume that this doesn’t always happen, since I’m sure testing involved creating a single-server farm with all default settings. I have no idea why it happened./

3) The fix mentioned in the link works perfectly, and is heartily recommended.

MOSS Workflows are versioned

I was asked today about MOSS’s behavior when workflows are changed midstream. Say I have a document library with a Workflow attached to it, start a few long-running (non-immediate) workflows, then change the workflow before they’re completed – will they keep running? Will they use the new workflow or the old, from that point on?

I had hoped for the former, but expected the latter. You can’t switch flow in midstream (if you’ll pardon my mishmash of similar metaphors), since a newer activity might rely on a variable created by a previous action – one that never took place.

Armed with a burning scientific curiosity and a lack of something to do while the motorway was jammed due to an accident, I set out to check my hypothesis:

 

1) Create a document library with three fields – two text fields and a Yes/No field. The two text fields represent actions taken before and after the change, while the yes/no field is to simulate a long-running workflow that requires other user’s interaction:

 

2) Create a simple workflow that updates the Step1 field and then waits around until the Waiting field is set to No:

 

This worked fine, of course – a new document would start the workflow and get its field set to Step1, then wait until I unchecked the Waiting field and then completed. I created another document and left it in the Waiting state.

3) Update the workflow and add another action after waiting – simply setting a value to the post-wait Step2:

 

4) Try it out. I created a new document and verified that Step1 was set before waiting, and Step2 set after waiting. Then I unchecked the Waiting flag on the old document, created with the original workflow.

As expected, Step2 did not get assigned for that document. Despite the fact that the latest version of the workflow had a new action after the Wait, the document was attached to the older version of the workflow, and not the newer. This was also true when I added the second action in a different Workflow Step, rather than a second Action in the same step.

This can be easily seen inside Sharepoint Designer, where we can see that the Workflow’s XOML file is just another file stored in just another document library – and like any other document library, it supports file versioning:

 

 

This is a potential cause for confusion – if we have many workflows active and are then required to make a change to it, it’s hard to know which workflow is running for which document. The ideal solution would be to complete or terminate all workflows before making a change, but that’s hardly a realistic solution for modifying production systems.

Screencasts vs. Whitepapers

A few weeks ago, Lawrence Liu (a senior technical PM and community lead for Sharepoint at Microsoft) linked to a few screencasts for learning how to use various features in MOSS2007. In that entry, he mentioned how screecasts are more effective and efficient in training and learning to use a new piece of software. Me, I’m a bit divided about them:

1) Screencasts are great for getting a hands-on view of the system, that’s true. A picture is worth a thousand words, and a movie is worth about 30 frames per second. I know software authors that have replaced the help file completely with a small Camtasia screencast. This, of course, only works for simple programs with few use-cases.

2) As Lawrence mentions, most screencasts are way, way too long. It’s understandable – when speaking you want to be as clear and understandable as possible. Too often it turns into a slow, repetitive lecture. To illustrate: last month Microsoft Israel held a Developer Academy conference to give lectures on new Vista dev topics. I squeezed in one Office 2007 talk. Because I was too worried about being clear and understood, I ended up repeating myself. Even a completely non-technical listener who just came in to hear me speak (yes, indeed, it was my mother) said she got the point already and that I should get on with it.

My point? Too many screencasts are way too long. Jan Tielens’ SmartPart (and sons) is a wonderful web-part to use and to learn from, but the screencast takes 16 minutes to describe what the 2-page readme.txt contains.

3) Screencasts are mostly a solution to learn the how, not the why. I can use Lawrence’s screencasts to learn how to add a library to the Records Center, but I would have found that out myself with little effort. What I would really want right now is a good set of whitepapers to understand the goals of the Records Center and how to use, not abuse it in my solutions.

4) A final tip for screencasts and webcasts – when using Windows Media Player you can speed up playback without affecting the pitch. This is to mitigate slow lecturers and needless repetition. It might require downloading the video locally first. Speeding it up to 140% is usually perfectly understandable.
On my Media Player 9, it’s under View -> Enhancements -> Play Speed. Enjoy.

Bad naming – Sharepoint Features

Gaaah! Who, in the name of all that is holy, thought that naming a feature in Sharepoint “Features” would be a good idea? Sure, it describes it, but it also describes practically everything else. It’s impossible to find on Google and makes conversation sound more like a Marx Brothers sketch then a technical conversation.

Why? Why? Why?

Some thoughts on uninstalling Sharepoint ’12’ Beta 1

I’m uninstalling an old beta of the Sharepoint servers from a VPC I have on my computer to make room for the newer Beta 2 servers, and I noticed several things:


1) The installation originally required a then-current build of Windows Workflow Foundation to install. However, it appears that it also requires it to UNINSTALL. I had to find the old installation of WWF Beta 1.2 and reinstall it. It is no longer available on Microsoft Downloads except as part of the 100MB package containing the Visual Studio extensions. Actual package size – 2.5Mb.


2) Uninstallation CRAWLS under VPC (512MB RAM, running on a USB2.0 external harddrive).


3) Is it my imagination? Does it… is it…
No, it’s true. The progress bar for the uninstallation actually does go BACK a few pixels every once in a while. You probably won’t notice it if it isn’t crawling on a background VPC, but it’s true. It’s rocking back and forth. Weird.

CAML still has its humps.

The last few days I found myself wrestling quite a bit with CAML. The basic idea was to replace the standard “Create New Document” button in a document library with some logic – if no document template is specified for the doclib, replace the button with three different buttons – Create Word Document, Create Excel Spreadsheet and Create Powerpoint Presentation.

This involved several operations to the SCHEMA.XML – wrapping the proper buttons in an tag to check if the TemplateUrl property has been set, rendering the proper buttons, and adding a new createNewDocument javascript function to instantiate the Sharepoint.OpenDocuments class and open the new document in its proper editor.

All this sharply highlighted the problems with CAML as it stands today, and reminded me of what I felt when I first saw ASP code – total and complete panic. I remember opening Visual InterDev and being completely baffled by the huge mess of HTML layout and virulent yellow ASP tags, all thrown haphazardly and confusingly. It’s possible to write neat code in classic ASP that seperates content from layout, but it sure as hell ain’t easy. I loved ASP.NET and the code-behind model, even though it still has many drawbacks. I think it’s a great improvement and encourages readble, understandable code.

CAML, unfortunately, is still deep in the phase that Classic ASP was in. Instead of HTML layout with embedded server-side commands, we have the main CAML flow interspersed with and CDATA blocks. The CAML syntax itself takes some getting used to – like polish notation, it’s hard for someone used to the function(arg1, arg2) syntax to read the style. But it’s definitely doable. What makes it unreadable is the fact that in between the program flow and logic of the CAML code is the final rendered output, in full. So a simple condition such as:

if (TemplateUrl = “”)
   RenderThreeButtons();
else
   RenderOneButton();

Becomes a huge mass of HTML code, all escaped with CDATA delimiters. It’s hard to find what you’re looking for even when it’s right in front of you. This is due to several problems:

  1. Lack of inclusion support. CAML doesn’t allow me to define arbitrary chunks of code and then include them later on in the code. This means that I can’t abstract code, but have to have it fully written every time. It also means that I can’t reuse code – in the example above I needed to replace the button rendering code TWICE – once in the AllItems view, once in the WebFolder view.
  2. Lack of proper development tools and standards. Some of this is mitigated by a good XML editor, but certainly not all of them. This includes:
    • A proper CAML editor that supports nested syntax highlighting – for the top-level CAML, the embedded HTML, and javascript/vbscript embedded in the HTML.
    • Support for code-folding, like Visual Studio’s regions. The ability to view the CAML logic without the rendered HTML would clear up the mess immensely.
    • An ability to flatten a CAML structure into a templated rendered view. This means that the following structure (slightly snipped for clarity):
      Owner of list  is
      should be flattened into:
      “Owner of list <ListProperty Property=ListName> is ” – all HTML nodes normalized into a single string, with the intervening CAML nodes turned into placeholders.

This is, I suppose, a call for Microsoft to improve CAML support in future versions of Sharepoint – according to this post it will still be there in future versions, and several replies have echoed my problems.
Additionally, it’s a call for community efforts to improve CAML usability. U2U have already released a tool to ease creation of CAML queries, but there is still a lot more to do.
I will try, of course, to add my own contributions to the community’s struggle with CAML, but I can’t promise anything – my personal pet projects tend to get neglected after a while. :)

Automatic population of web-parts in a New Web Part Page.

When a new sharepoint is created, the default page is automatically populated with several default web-parts as described in the ONET.XML and the section. This is (relatively) well documented and clear.

However, if I create a new Web Part Page in an existing site (from the Create -> Web Part Page menu) based on one of the 9 templates in the DOCTEMPSMARTPGS directory, it is also populated with a web-part – the TitleBarWebPart, specifically. I don’t want this web-part added to my new pages, and I want others to be auto-added. However, I am yet to find where this population is defined – couldn’t find it in any XML file under the site definition, and the actual code that creates the webpage is in owssvr.dll, hence not managed code and not browsable with the Reflector.

Anyone know where this is hiding?

The Good, the Bad and the DataViewWebPart

Been wrestling lately with Sharepoint’s DataViewWebPart (DVWP, from now on). I’m still pretty ambivalent about it.

Pros:

  • Easy to set up  – just add a list as a web-part, open it in Frontpage, right-click and Convert to XSLT.
  • Very customizable. I like XSLT. I can tweak it any way I want, generating custom rendering for my fields that would otherwise require me to write a custom web-part or a custom FieldType, which is too much hassle.
  • Presentation only. All the data-access logic is taken care of behind the scenes, and I have all the properties of my list items as XSLT parameters to play with as I choose.

Cons:

  • Not Portable. If I build a menu off of a list (as detailed here, excellent article), that DVWP is linked to the list’s GUID. If I now want to copy that DVWP to a different subsite, I have to edit the hardcoded GUID or start messing with passing GUIDs as parameters and whatnot.
  • Messy, messy, messy. Tweaking unformatted XSLT in FP2003’s Code view is a big, big pain – and a slip of the keyboard can make the DVWP unrenderable with no real explanation where you screwed up.
  • Maintainability is hell. Code is embedded directly in the page. If I want that DVWP on every page in my site (for the menu), I have to add it to every page manually, and update every change manually – even if I export it to a DWP file and just import to each page, I still need to update manually when things change. Anyway, it’s a break from the content/presentation split that ASP.NET is pushing.

Right now I’ve given up on the DVWP approach and simply wrote a web-part in C# – it’s portable, integrates well with my source-control-provider-of-choice, and the distinctions between unit of functionality and the page it resides in is clear.

Anyone have any supporting/opposing POVs? Any hints or tricks that make DVWPs more useful outside of the single-site scope?

Quick Tip: Erasing many Portal Areas.

Erasing a Portal Area via the interface is a bit annoying – you go to the Manage Portal Site to get the Area Tree, right-click and Delete, then you have to confirm again, wait 10-15 seconds, then press another button to get back to the tree. If you’re erasing a whole bunch of areas (on a development server, for instance, when you want to start a new batch of tests), it can take quite a bit of time and patience.

So a little shortcut – drag all the areas you want to erase under one area. Dragging is quick and progressbar-less. Then erase that area  All subareas will be automatically erased, and no hassle.