Saturday, December 20, 2008

SPD Workflow: The changes performed in the workflow are not reflected on the site

A. Introduction: I have recently encountered a very weird problem while working with SPD workflows:
  • Open the workflow's XOML file.
  • Perform some changes to the workflow steps.
  • Click the Finish button, in order to save the changes.
  • Although the changes are saved successfully, the next time the workflow is triggered the old version of the workflow is run. In other words, the changes done to the workflow are not refelected on the site.
B. Unsuccessful Trials: Trial 1:
  • Restart SharePoint Designer.
  • Open the workflow, perform any simple change (e.g. Log To History List) and click Finish.
  • Trigger the workflow -> Changes are not refelected.
Trial 2:
  • Close SharePoint Designer.
  • Open the workflow settings of the list to which the worklfow is attached.
  • Remove all the workflow instances attached to the list.
  • Open SharePoint Designer.
  • Open the workflow, perform any simple change (e.g. Log To History List) and click Finish.
  • Trigger the workflow -> Changes are not refelected.
C. Solutions: This section provides two solutions of the described problem. One of them is how my team has fixed the problem and the other is taken from a colleague of mine who has coincidentally heard about our problem and told us that he has encountered it once and how he has fixed it then. Solution 1:
  • Close SharePoint Designer.
  • Open the workflow settings of the list to which the worklfow is attached.
  • Remove all the previous versions of the workflow instances attached to the list. (Cleanup step)
  • Save the list as a template. NOTE: Select the Include Content checkbox.
  • Delete the list to which the workflow is attached.
  • Create a new list using the saved list template.
  • Open SharePoint Designer.
  • Open the workflow, perform any simple change (e.g. Log To History List) and click Finish.
  • Trigger the workflow -> The changes are refelected correctly.
Solution 2:
  • Close SharePoint Designer.
  • Open the workflow settings of the list to which the worklfow is attached.
  • Remove all the the workflow instances attached to the list, including the current version.
  • Open SharePoint Designer.
  • Create a new workflow on the same list and add any simple condition and any simple action to it.
  • Click Finish, in order to save and publish the new workflow. Note that the new workflow has the files [workflow name].xoml and [workflow name].xoml.rules.
  • Using Notepad, copy the content of the old "xoml" file into the new "xoml" file.
  • Using Notepad, copy the content of the old "xoml.rules" file into the new "xoml.rules" file.
  • Open the new worklfow and quickly go through all the conditions and actions, to make sure that no variables are corrupt. Note: In case you use a Collect Data From User action in your workflow, I recommend that you create a new action and remove the old one.
  • Click Finish, in order to save and publish the new workflow.
  • In case the new workflow is saved properly, delete the old workflow in SPD. This can be done by right-clicking the workflow's name under the Worklfows node, selecting Delete and confriming the deletion when the warning message appears.
  • Finally, trigger the workflow -> The changes are refelected correctly.
D. Source of the problem: There is still a question lying there unanswered, namely What is the cause of this weird SPD behavior? Although the previous section provided a fix, but the more important issue is: How can we avoid this annoying problem in the future? Currently, I do not have the answers to these questions. As soon as I do, I would update the article. Meanwhile, any contributions would be highly appreciated.

Wednesday, December 17, 2008

SPD Workflow: How to deploy an SPD workflow to another site?

A. Introduction SharePoint Designer provides a very simple workflow editing tool. Workflows authored in SPD can be developed very quickly. However, this ease of use come with a cost: SPD workflows cannot be reused from one list to another or one site to another. Well, the truth is, you can re-use your workflows on multiple lists by making a few careful modifications to your workflow files that exist within SPD. Nevertheless, this method is not recommended nor supported by Microsoft. B. Migration Steps For accomplishing this task, you have to manually perform changes in the XOML file(s). The following articles provide step-by-step guides: Re-using SharePoint Designer workflows in multiple lists: http://www.sharepointblogs.com/tbone/archive/2007/11/20/re-using-sharepoint-designer-workflows-in-multiple-lists.aspx Re-parenting a SharePoint Designer workflow to a different list: http://www.sharepointblogs.com/andynoon/archive/2007/09/18/reparenting-a-workflow-to-a-different-list.aspx Applying a SharePoint Designer Workflow to multiple Lists: http://nickgrattan.wordpress.com/2007/10/17/applying-a-sharepoint-designer-workflow-to-multiple-lists/ Porting SharePoint Designer Workflows to Visual Studio: http://blogs.msdn.com/sharepointdesigner/archive/2007/07/06/porting-sharepoint-designer-workflows-to-visual-studio.aspx

Sunday, December 14, 2008

SPD Workflow: What happens when I edit an item while the workflow is In Progress?

A. Introduction If one designs a workflow that should start either when an new item is created or whenever an item is changed, then a typical question that popps into one's mind is: What happens if a workflow is In Progress and the item on which the workflow is running gets changed? Possible answers are:
  • The Edit operation gets aborted till the workflow finishes.
  • The Edit operation triggers a new workflow instance that starts running immediately.
  • The Edit operation triggers a new workflow instance that waits in a queue till the first instance of the worklfow finishes.
  • The Edit operation does not trigger a new workflow instance.
Well, in this article I would like to illustrate the results of my experiments around this issue. B. Preparations Create a new list, which we would attach the workflow to. For this demo, I have created a custom list called Overlapping Workflows. C. Experiments C.1. Experiment 1: Create one workflow for Create and Edit events C.1.1 Prepare the workflow - Open Microsoft Office SharePoint Designer 2007. - Click File > Open Site. - Enter the URL of the site containing our custom list called Overlapping Workflows. - Now click File > New > Workflow. - On the Define your new workflow page, enter the following data:
  • Name: Check Overlapping Workflows
  • Attachment List: Overlapping Workflows
  • Start Options: Automatically start this workflow when a new item is created and Automatically start this workflow whenever an item is changed
- Click Next, in order to start designing the workflow steps. - Enter Add tracking logs as the Step Name. - In the Actions section, select the action Build Dynamic String. - Click dynamic string link and type the text Title before Pause is:. Now click the Add Lookup button. For the Source select Current Item and for the field select Title. Click to close the lookup window. Then click OKOK again, in order to close the String Builder window. - Click the Variable link and select Create a new variable. Type TitleBefore as the Name and select String as type and click OK. - Add the action Log to History List. - Click the this message link and click fx. For the Source select Workflow Data and for the field select Variable:TitleBefore. - Add the action Pause For Duration. - Change the duration to 5 minutes. - Add the action Build Dynamic String. - Click dynamic string link and type the text Title after Pause is:. Now click the Add Lookup button. For the Source select Current Item and for the field select Title. Click to close the lookup window. Then click OKOK again, in order to close the String Builder window. - Click the Variable link and select Create a new variable. Type TitleAfter as the Name and select String as type and click OK. - Add the action Log to History List. - Click the this message link and click fx. For the Source select Workflow Data and for the field select Variable:TitleAfter. - Click Finish, in order to save and publish the workflow. C.1.2 Test the workflow Steps: 1. Create a new item with title Title 1. 2. Edit the item, before the workflow instance completes by changing the title to Title 2. 3. After the workflow completes, edit the item again by changing the title to Title 3. 4. Now edit the item, before the new workflow instance completes by changing the title to Title 4. Observations: 1. Only one workflow instance is running on an item at a certain point in time. The Edit operation in step 2 does not start a new workflow instance. 2. After this workflow completes, the history looks as follows: 3. The Edit operation in step 3 triggers a new workflow instance. 4. After this workflow completes, the history looks as follows: C.1.3 Conclusions 1. If an instance of the workflow is running, no other instance gets created. 2. The workflow's action deal with the current values of the item. The actions cannot differentiate whether these values are the original ones that have trigged the workflow or not. C.2. Experiment 2: Create separate workflows for Create and Edit events C.2.1 Prepare the workflows I would not write this section into so much detail like C.1.1, because we will use the same actions as before but with different configurations. Hence, I will keep my description simple. - Create a first workflow with the following definition: * Name: On Create Workflow * Attachment List: Overlapping Workflows * Start Options: Automatically start this workflow when a new item is created - The only step of this workflow is exactly like the one described in section C.1.1. - Create a second workflow with the following definition: * Name: On Change Workflow * Attachment List: Overlapping Workflows * Start Options: Automatically start this workflow whenever an item is changed - The only step of this workflow is exactly like the one described in section C.1.1. C.2.2 Test the workflow Steps: 1. Create a new item with title Title 1. 2. Edit the item, before the workflow instance completes by changing the title to Title 2. Observations: 1. The Create operation in step 1 triggers the On Create Workflow. 2. The Edit operation in step 2 triggers the On Change Workflow, while the On Create Workflow is running. 3. After the On Create Workflow completes, the history looks as follows: 4. After the On Change Workflow completes, the history looks as follows: C.2.3 Conclusions 1. It is possible to run more than one workflow instance on an item, if these instances are not of the same workflow. 2. The workflow's action deal with the current values of the item. The actions cannot differentiate whether these values are the original ones that have trigged the workflow or not. D. Applications Well, in the previous section, I have just illustrated the results I have found out from my experiments. In other words, this is how it works out-of-the-box. Now comes the question of how to apply this to our workflow solutions. In this section, I would like to provide tips and suggestions of the FAQ in related topics. Question 1: When I create a workflow that starts when a new item is created OR whenever an item is changed. The actions performed in both situations are the same except for one step which should differ based on whether the processed item is a new one or just an updated one. How can one find out whether the workflow was triggered due to an item's change or a new item's creation? Answer 1: Check this article: http://samar-hossam-sharepoint-spot.blogspot.com/2008/11/moss-workflow-was-workflow-started-due.html Question 2: I have a workflow that starts when a new item is created OR whenever an item is changed. Whenever a workflow is running on an item, I would like to lock this item for further edits until the workflow finishes. Answer 2: You should write a custom activity which locks/unlocks an item. You should use this activity at the beginning of the workflow, in order to lock the item and use it again at the end of the workflow, in order to unlock it. Check the following custom SPD activity on CodePlex: Grant Permission on Item

Tuesday, December 2, 2008

MOSS Configuration: Configure outgoing e-mail settings

The following article describes the procedure to configure the outgoing e-mail settings for Office SharePoint Server: http://technet.microsoft.com/en-us/library/cc263462.aspx

Sunday, November 30, 2008

Workflows: Starting a workflow from a survey response

A. Problem Description I have encountered several questions on the MSDN forums which try to troubleshoot problems of running workflows on survey responses. The problem they describe is the following: - Whenever you add a new response to a survey, the attached workflow does not start. - Instead, the status of the workflow appears as Failed to Start. B. Feedback Well, starting a workflow from a survey response is not supported in Windows SharePoint Services 3.0. Although the Workflows option appears when you click the arrow next to a survey response, you cannot start a workflow from a survey response. Microsoft has confirmed that this is a problem in the following Microsoft products: - Microsoft Office SharePoint Server 2007 - Microsoft Windows SharePoint Services 3.0 - Microsoft Office SharePoint Online Click here, for more details about this problem. C. Further Information Check this blog article, for more information about this issue.

Thursday, November 27, 2008

SPD Workflow: How to send a reminder a few days before the start date of a calendar entry?

A. Introduction As the title conveys, in this article I would like to show how one can create a workflow (using SharePoint Designer), which sends notifications to a list of recipients 7 days before the start date of a calendar entry. B. Preparations Create a Calendar, which we would attach the workflow to. For this demo, I have created a Calendar called Team Meetings. C. Workflow - Open Microsoft Office SharePoint Designer 2007. - Click File > Open Site. - Enter the URL of the site containing our calendar called Team Meetings. - Now click File > New > Workflow. - On the Define your new workflow page, enter the following data: --- Name: ReminderForMeetings --- Attachment List: Team Meetings --- Start Options: Automatically start this workflow when a new item is created and Automatically start this workflow whenever an item is changed - Click Next, in order to start designing the workflow steps. - Enter Calculate the reminder date as the Step Name. - In the Actions section, select the action Add Time to Date. - Click the 0 link and type -7. - Click the minutes link and select days. - Click the date link and then click fx. For the source select Current Item and for the field select Start Time. - Click OK. - Click the output link and create a new variable called ReminderDate of type Date/Time. - Click OK. - Click Add workflow step in the right panel, in order to create another workflow step. - Enter Check whether a pause is needed as the Step Name. - In the Conditions section, select Compare any data source. - Click the value link, then click fx. For the source select Workflow Data and for the field select ReminderDate. - Click the equals link and select is greater than. - Click the value link. Click the ellipsis, select Current Date and click OK. - In the Actions section, select the action Pause Unit Date. - Click the this time link and click fx. For the source select Workflow Data and for the field select ReminderDate. - Click Add workflow step in the right panel, in order to create another workflow step. - Enter Send reminder as the Step Name. - In the Actions section, select the action Send an Email. - Click the this message link and configure the different e-mail settings. - Click Finish, in order to save and publish the workflow. D. Test the solution 1. Create a new calendar item, whose Start Date is less than 7 days. -- Check that the ReminderForMeetings workflow has completed successfully. -- Check that you receive a notification now. 2. Create a new calendar item, whose Start Date is greater than 7 days. -- Check that the ReminderForMeetings workflow has started successfully. -- Check that you receive a notification on the right date.

Tuesday, November 25, 2008

Workflows: Comparison of SharePoint Designer and Visual Studio for creating workflow solutions

SharePoint Designer and Visual Studio 2005 (or later) can be used to create workflow solutions for MOSS. In order to be able to choose which platform to use, one has to understand the differences between authoring workflows in SPD versus Visual Studio. In the following section, I have summed up all the comparison criteria, which I have read in different books/articles or ones that I have tried myself. 1. Authors: SPD: Designers can author solutions, not just developers. VS: Only developers can author solutions. 2. Types of Workflows: SPD: It is possible to author sequential workflows only. VS: It is possible to author state-machine as well as sequential workflows. 3. Site Content Types: SPD: Does not support site content types. VS: Site content types are supported. 4. Deployment: SPD: Workflows are attached to a single list and are data-bound to that list. VS: Workflows are authored as templates. Such a workflow can be packaged as a SharePoint feature and installed on multiple sites or lists. 5. Forms: SPD: ASP.NET forms are auto-generated and can be customized. VS: Designed forms (InfoPath or ASP.NET forms) 6. Extendibility: SPD: Reuse out-of-the-box or custom deployed activities. No code-behind, so tools are limited to what’s included. VS: Reuse out-of-the-box activities, as well as building your own activities Code-behind capabilities make it very flexible and powerful. 7. Debugging: SPD: No step-by-step debugging. VS: Step-by-step debugging is supported.