Posts

Showing posts with the label Workflow

Displaying workflow item information from a custom ASPX task form

When building custom workflows, often we want custom Task edit screens as well.  A custom Task Content Type allows us to collect much deeper data than 'completed'.  However, since we are ditching the default Task edit pages, we lose a couple of useful features; a link to the underlying Workflow item as well as the implied context of the Task. Given the need to provide context to the user when overrriding the default task form, you may come across the desire to display some file information, custom columns/properties, links, etc on the task edit page.   To accomplish this, we need to gain two pieces of understanding: How and when to modify ASPX page elements from the code-behind c# class How to extract the underlying information from the Workflow's original item When: during the page_load() of inherited class; protected void Page_Load(object sender, EventArgs e) { if (!Page.IsPostBack) { ...

Security and Audit Trail of Workflow Tasks in SharePoint 2007 & Visual Studio 2008

Image
Two requests that are probably part of every SharePoint workflow design: Permit only the users who are assigned a WF tasks to edit (i.e. complete) them Record the user name of the person who completes a task (instead of the System Account) Not suprisingly, neither of these pretty simple, seemingly obvious design concepts can be done out of the box / without some customization.  Also, certain configuration screens might trick you into thinking you can do this directly within the SharePoint UI (you can't; more on this in the deeper blog posts). Part 1: Security of Workflow Tasks in SharePoint 2007 and Visual Studio 2008 Part 2: Audit Trail of Workflow Tasks in SharePoint 2007 and Visual Studio 2008   There are a couple of good blog sources for each of these customizations, but I didn't find any of them to be thoroughly detailed with screenshots, pitfalls, etc.  So what I hope to do in this two part blog post is cover some portions I think those...

Workflow LogToHistoryList UserID and Task Activity Executor in SharePoint

Image
This topic is within a SharePoint 2007 workflow, how do we get the Workflow History to reflect the user who modified a task, rather than the "System Account".  I've successfully implemented the solution suggested by Julie Kramer , from the office dev blog.  Here we go: snippet of a workflow design in VS2008 - focus on the two red activities Assign a new field to the Executor property of the OnTaskChanged activity in question (you'll see this property in the property window on the activity). Note we use this new field in a later LogToHistoryListActivity's Method_Invoking() by assigning the UserID property of the LogToHistoryListActivity's object Add a userid lookup/helper function to guarantee a valid SharePoint user id is in place private SPUser GetUserObject(string accountID) { try { if (accountID.IndexOf(@"\") > 0) { SPUser use...

The e-mail message cannot be sent. Make sure the outgoing e-mail setting for the server are configured correctly

It seems like there are hundreds or thousands of people out there that have come across this little SharePoint sendemail bug. Beware this error message is a red herring! My suspicion is that through a series of unfortunate events around the sequencing / pipelining of workflow activities, the sendmail activity gets terminated prior to having a chance to become a fully dehydrated object. Postulations aside, here is the fix I used: Observation 1 from 12's hive logs (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS): w3wp.exe (..) 0x.. Windows SharePoint Services, General, 8kh7, High, Cannot complete this action. Please try again. Observation 2 from Workflow History: Error, System Account, The e-mail message cannot be sent. Make sure the outgoing e-mail settings for the server are configured correctly. So I fixed my <sendmailobject>_MethodInvoking by binding the sendmail activity's email fields (to:, cc:, body:, etc) to class variables and then ass...

Workflow History versus Audit Trail

MOSS removes the association between workflow tasks, history items and the workflow 60 days after the workflow has been completed through the workflow cleanup timer job for performance reasons. Consider this next suggestion a workaround for that bad design; most companies that develop custom workflows will want that history around for some time. Several alternatives are available, albeit brute-force methods, but the one I elected to go with is to place the following bit of configuration in the workflow.xml prior to associating a workflow. workflow.xml <Elements> <Workflow> .. <MetaData> <AutoCleanupDays>9999</AutoCleanupDays> </MetaData> .. See Brian Farnhill for more documention on this issue.

secret lengths of OnBehalfReason

As I was setting up a custom SharePoint workflow to work with an external user outside of the domain, I noticed some quirky behavior and error messaging from SharePoint. e.g. it works if its a short piece of text like the MOSS 2007 SDK: createPartnerReviewTask_TaskProperties1.OnBehalfEmail = "null@void.com"; createPartnerReviewTask_TaskProperties1.OnBehalfReason = "This user does not have access to this Windows SharePoint Server site."; but dies like this when its too long: WinWF Internal Error, terminating workflow Id# 7c4d... System.ArgumentException: Value does not fall within the expected range. at Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties.set_OnBehalfReason(String value) what range is specified in the reference? undocumented.
Following Robert Shelton's well documented series on creating MOSS 2007 workflows in Visual Studio 2008, I ran across a bit of a snafu. Basically, his recommended dev machine setup stipulates WSS3, VS2008, etc. However the Visual Studio 2008 wizards/templates for Sequential Workflow expect MOSS, not WSS. The workaround should get me positioned to develop, debug, package and deploy workflows in VS2008. I found the most complete workaround write-up on this issue on the Visual Studio SharePoint Tools Blog by Roger Best. Here is his writeup in full (in case the link stops working one day..) "Getting Visual Studio 2008 SharePoint 2007 Sequential / State Machine Workflow projects working with Windows SharePoint Services 3.0 Published 19 August 08 02:18 PM I wanted to create a SharePoint workflow using VS 2008 on WSS 3.0. The documentation is set that only Microsoft Office SharePoint Server 2007 can be used but I figured I would lay out the modifications needed to allow a pro...
After arm wrestling the 64 bit version of MOSS 2007 + Windows 2008 x64 + Visual Studio 2008 x64 (and Visual Studio 2010 Beta 1 x64) , and LOSING - I was cornered into SharePoint Designer for development of workflows. Now, I know the inefficiency I'm invoking by doing this - instance creation versus template creation! But deadlines beg, you know. So how pleased am I that when I eventually get my x86 (ow, what year is it? I think I've been writing for x86 platforms for something like 20+years, yikes) VM dev instance in HyperV up and running, I'll be able to reuse/import the SPD built workflow logic into Visual Studio. Warning, there is excessive winking in this blog entry: http://blogs.msdn.com/sharepointdesigner/archive/2007/07/06/porting-sharepoint-designer-workflows-to-visual-studio.aspx The other nugget of the day is that I think I'll write up my findings of first release of Google Chrome for Mac OSX and the SharePoint experience. Chrome is built on webkit rendering,...
This is Yet Another Blog on how to properly install & configure a SharePoint 2007 development client installation. I've read many different blogs and noticed pretty substantial inconsistencies and invariably most come to the conclusion that Your Mileage May Vary. Case and point, in my dev environment, I'm optimized for the current bleeding edge, and there is a whole lot of blood. Dev setup: OSes Windows 2008 Server 64 bit for the Dev Server One configuration that didn't work for the Dev Client - Windows 7 RC1 (Build 7100) 64 bit (HP Compaq workstation, 2gb ram); the reason that I need to have a client/server is due to a limitation of Visual Studio 2008 and VS 2010 Beta 1's SharePoint Workflow Project creation running on a 64 bit OS - http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=325668 Dev Client - Windows XP SP3, dual core E2220 CPU at 2.4 GHz, 2GB RAM Configuration to be continued...
After installing VS2008 pro on the sharepoint 2007 64 bit win2k8 server, I create a new SharePoint Sequential Workflow project and get the dreaded "Object reference not set to an instance of an object" dialog. A similar project creation failure occurs using Visual Studio 2010 Beta 1 on the 64 bit MOSS 2007 server too. In the case of the newer IDE however, there is no dialog box, rather the status bar on the bottom says Creating project 'SharePointWorkflow1'... project creation failed. So it seems like the "plan" as indicated by the Program Manager is currently half implemented. The VS2010 Beta 1 actually shows these project templates to the user on a 64 bit environment (not according to plan), however the project creation fails (seemingly by design). >"The plan for Visual Studio 2010 is to still not support SharePoint 2007 Workflow projects on a 64bit workstation. VS 2010 will avoid the problem of throwing exceptions by hiding the Project Templates ...