Groovin' (or not) With Sharepoint Workflow
I'm up in Irvine this week at a partner level technical training for Sharepoint. A lot of the content is introductory and not news to me so I've been spending time helping and listening to the questions being asked around me. This post was already written once but my browser (or the crappy Internet connection) ate it and I lost the whole thing. So let's try this again.
Groove Workspaces
One of the cool things that I've done today is learn about Groove workspaces. A cool little feature to share a Sharepoint document library via the Groove interface, edit, upload and share documents with a user not given permissions in your Sharepoint site. Useful for collaboration but sorta a bummer since most clients aren't going to have Groove.
Workflow Tips
We just finished a session on workflow so I'm going to go over a few of the tips that came up:
Workflow Public Key Tokens
Sharepoint workflow assemblies must be strongly named. The feature installation requires that you indicate the publick key token for the workflow assembly. There are a number of hoops one can jump through in order to obtain this public key. Here's some I've heard today:
- Drag the built assembly into the GAC, browse to the GAC, copy and paste the public key token from the explorer window;
- Drop to a command prompt, browse to the SDK/Bin directory, use the SN.EXE command line tool to retrieve the public key token, copy all the contents of the command window into notepad, find the public key entry, copy and paste into your xml file
or
You can be a lazy programmer like me and simply take the following steps:
- In Visual Studio
- Tools/External Tools
- Title: Get Public Key; Command: C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sn.exe; Arguments: -Tp "$(TargetPath)"; use Output Window
Now you'll have an option on your Tools menu called "Get Public Key." Simply build your strongly named assembly, select Tools/Get Public Key and in the output window you'll be presented with the public key token, simply copy and paste... wala lazy programming shortcut.
I actually learned about that little shortcut on someone else's blog but I can't remember who or I'd duly give them credit for the tip.
Workflow Task ListItemID Field
People have asked about this property and what it's use is. The ListItemID essentially provides a handle the actual item in then workflow task list. I use this property frequently when I am sending an email from my workflow and want to send a link directly to the task item. Simply create the property, the workflow will populate it for you and you can then use it in your workflow to get (or give) a handle to the task item in the workflow task list. Apparently there is a bit of confusion about this particular property because, by default, the property window shows this property as -1. This is the default but does not reflect that the property has actually been created or will be set by the workflow during run-time. You must actually create the property just like all the other properties you have to create.
Workflow LogToHistoryList UserID and Task Activity Executor
I got asked a question today about the unsightly "System Account" entry in the workflow history list. System Account will always be the default but it makes more sense that the person who actually completed or executed the task or event associated with the log item is listed as the user in the workflow history list. To make this happen, make sure you have created the Executor property on your OnTaskChanged activity (you'll see this property in the property window on the activity). Also create the UserID property on the log activity. In your code, correlate the two and wala, the unsighly System Account will be changed to the Executor of the task changed event.
Update With Code:
Supporting Function:
private SPUser GetUserObject(string accountID)
{
try
{
if (accountID.IndexOf(@"\") > 0)
{
//this needs to come out of Active Directory
SPUser user = this.workflowProperties.Web.SiteUsers[accountID];
return user;
}
else
{
//this needs to come out of Active Directory
SPUser user = this.workflowProperties.Web.SiteUsers[@"OSS\" + accountID];
return user;
}
}
catch
{
//default to Administrator
//this should be changed to someone in your organization
SPUser adminUser = this.workflowProperties.Web.SiteUsers[@"OSS\Administrator"];
return adminUser;
}
}
In the OnTaskChanged event:
SPUser executor = GetUserObject(onTaskChanged_Rejected_Executor);
log_RejectChanged_UserId = executor.ID;
Updating Your Workflow Assembly
Just a quick note to reiterate and clarify confusion I heard today. You do not have to reinstall your entire feature each time you make a change to the code. You can simply re-GAC your workflow assembly, maintaining versioning on the workflow and simply updating the code. I usually create a secondary bat file which just re-GACs my assembly.