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