Move Sharepoint designer 2010 workflow with a wsp

In SharePoint Designer 2010, you can create reusable declarative workflows. That means workflows created in SharePoint designer can now be generic (not tied to a list) and can be moved to other Site collection or sites via .wsp file. The "Save as Template" command can be used to create a WSP file containing a reusable workflow. The workflow can also be moved to Visual Studio 2010 for further Customizations.

Steps to Move Workflow are :

1. Create a SharePoint workflow using SharePoint Designer 2010.

2. After you are done with creating a workflow, Click on "Save as Template" button on Ribbon the bar. This will create a wsp file for you workflow, which will be uploaded in the current site collection itself.

3. Now, Open the Top Level Site or Site collection, in which you created the workflow. Goto View all site content and click on "Site Assets" library. You will see your saved workflow wsp (or soluiotn package) gets upload to this library. However, to deploy it in the site colletcion you will need to download this file and upload into Solution management.

4. To download this wsp you can open up the drop-down menu for this file and Choose Sent To -> Download a Copy.

5. Now to Upload it to Solution management of this or any other site collection goto
Site Actions -> Site Settings -> Under Galleries click on Solution gallery. Then Click on Solution tab(in ribbon bar) and click on Upload Solution and browse to the aboved saved file. Once the solution is uploaded click on "Activate solution" to activate it.

5. Since the workflow is deployed as a feature, you will now activate the workflow feature for the site where you want to use the Workflow. To do this goto Site Settings of that site and click on "Manage Features" now simply activate the workflow to use it in the Site.

Please note that another option in ribbon bar "Converted to be Globally Reusable" will only save your workflow to be globaly reusable. It will not create wsp file to be deployed in another farm. Also, the workflows created at the root level of the site collection can only be converted to be Globally Reusable but other ones created in sub sites cannot.

WorkFlows Migration from MOSS 2007 to SPS 2010

Workflows should continue to work fine. Only potential issue is in a database attach upgrade when you Prepare the new environment:

If you had disabled the Workflow Auto Cleanup timer job in your Office SharePoint Server 2007 environment, make sure that you disable this timer job in your new environment also. If this timer job is enabled in the new environment and disabled in the previous version environment, you might lose workflow associations when you upgrade. For more information about this timer job,

Disable automatic workflow cleanup

By default, Microsoft SharePoint Server 2010 runs a daily Workflow Auto Cleanup job to permanently delete workflow instances and related task entries that still exist 60 days after a workflow is completed or canceled. Workflow history items themselves are not deleted, but the entry point to view them on the status page for a particular instance of a workflow will no longer be available. You can disable the Workflow Auto Cleanup job if you want to keep workflow data available longer. However, as with any SharePoint list, as the workflow history and task lists grow in size, site performance may be compromised. If you are concerned about the size of these lists, keep the Workflow Auto Cleanup job enabled. Whether or not you keep the Workflow Auto Cleanup job enabled, you can create a separate history and task list for each workflow association to distribute items across lists.

To disable automatic workflow cleanup

1. Verify that you have the following administrative credentials:
   • To disable automatic workflow cleanup, you must be a member of the Farm Administrators SharePoint group.
2. From the Central Administration Web site, on the Quick Launch, click Monitoring.
3. On the Monitoring page, in the Timer Jobs section, click Review job definitions.
4. On the Job Definitions page, in the Title column, click the Workflow Auto Cleanup link that is associated with the Web application for which you want to disable automatic workflow cleanup.

   Tip:
   The Web Application column on the Job Definitions page contains the name of the Web application to which each timer job is associated.
5. On the Edit Timer Job page, click Disable to disable the Workflow Auto Cleanup feature.
   
   
   
   

   Porting SharePoint Designer Workflows to Visual Studio

   A lot of people ask if SPD workflows can be customized in Visual Studio so that you can deploy it as a reusable workflow template or add some code to it, and our official answer is that it’s not supported. But... it doesn’t mean it’s not possible to some extent;). In reality, an SPD workflow is a Workflow Foundation XOML file that’s compiled on the fly, so this file can be opened in the Visual Studio Extensions for WF. Today, I’ll show you how to get started;). (It’ll be our little secret!)

   I’d strongly recommend having a basic understanding of how VS workflows work prior to reading this (I will probably gloss over some of the VS specific details;)). For general information about building VS workflows, theSharePoint blog is a good place to start.

   Also, I should note that this works for workflows that do not have forms. Adding forms can be complex, so I’ll try to cover them in a separate post.

   
   

   Step 1: Create a VS Workflow Project

   In VS, go to File > New and select either a SharePoint Workflow Project (from the WSS or MOSS SDKs) or Workflow Foundation project. You will need Visual Studio Extensions for Workflow Foundation installed.

   
   

   Step 2: Copy the SPD .xoml and .rules files into the VS project

   

   With the new project in place, we’ll start porting the SPD xoml over to VS. First we need to extract the appropriate workflow files from SPD. To do this, open SPD and go to the Folder List. Right-click on the workflow that you want and choose the Publish Selected Files...option.

   In the Remote Web Site tab of the dialog that appears, select the File System radio button and choose a local location on your computer. This will create a folder called Workflows on your file system in the location specified.

   When you have these files, rename the .rules file (if you have one) from *.xoml.rules to *.rules. Then add the .xoml and .rules files to your VS project. If you double click on the .xoml file in the Solution Explorer, the WF workflow designer should open, and you should see all your SPD actions in place.

   
   

   Step 3: Generate a .cs file under the XOML (optional)

   If you want to add code behind your XOML, you’ll need a .cs file to go with it. By default, the copied XOML won’t come with this. To generate one, just bind a function to one of the activities in the designer. OnWorkflowActivated is there by default, so try typing an event handler name to its Invoke property. The .cs file created should automatically initialize the namespace and class name to match your XOML. If you don’t like the default names, change the attributes in the first line of the XOML in an XML editor before generating the file:

   <ns0:RootWorkflowActivityWithData x:Class="Namespace.ClassName"...>

   Step 4: Deploy and debug the workflow

   Fill out the rest of your deployment files and deploy the template as a SharePoint Feature the same way as with any VS workflow, then associate it for use. Since SPD workflows weren’t designed to be ported over, expect some kinks that you’ll have to debug through. But hopefully, the workflow provides enough of a base there to work through them, and with the ability to code, you can find some nifty workarounds;).