There are several options for migrating the SPD workflow:
1. Recreate the workflow in the new server: this option has the highest probability for success since the list options are picked specifically for the new environment but this is also the most time con-suming option.
2. Perform a Stsadm Backup/Restore: this option works well but is harder to incorporate when you have an existing site. The overwrite options could cause issues so this option should be deployed to a new location.
3. Create a site template file: the workflow may not work after deployment.
4. Contend deployment can be used to move workflows. This is the most attractive solution for moving SharePoint Designer created workflows.
The links below will give you an understanding as to what content deployment is and how to plan for it:
http://blogs.msdn.com/sharepoint/archive/2006/05/02/588140.aspx
http://technet.microsoft.com/en-us/library/cc263428.aspx
Once you have content deployment setup you need to do to run a job to migrate a SPD workflow. For the Deployment Options you can use Deploy only new, changed, or deleted content.
Hope it can help you.
Re-parenting a SharePoint Designer workflow to a different list
This will allow you to package a workflow up as a feature and deploy and use it in multiple locations in your farm. However for simple deploy-ments you may want to stick with SharePoint Designer, if you do – read on!
Within the same site:
So you've got a workflow and now you want to either move it to another list or attach it to another list at the same time. The list you want to attach it to is in the same site. You would think there was a way of associated a workflow with more than one list but in fact there isn't and to some degree it's understandable. A lot of the actions you define in the workflow are specific to the library you are working with, even if you were to abstract your logic away from the list then SharePoint Designer links actions such as "Current Item" properties to the underlying list.
So, unfortunately it's not as easy as just editing the configuration XML file:
[workflow name].xoml.wfconfig.xml
and pointing it at the XOML and RULES files for your existing workflow. Your workflow will almost certain-ly contain references to the original library or list, so just pointing the config file at you existing workflow will have some pretty uncertain outcomes!
The good news is that you can use a lot of what you've already created and apply it to a new workflow, as per…
1.Make sure the new list your working with is set up correctly (content types, columns, approval, check in /out…)
2.In SharePoint Designer, create a blank workflow with a dummy step defined
3.Copy the contents of your original XOML file named, [workflow name].xoml to the new XOML file that was created when you created the new workflow (use notepad) NOTE: The XOML contains all the variables and activity definitions for your workflow, but not the logic
4.Copy the rules [workflow name].xoml.rules file contents to the new rules file NOTE: The rules file con-tains the login for if, then…else comparisons
5.Compare your config [workflow name].xoml.wfconfig.xml file with the original config file and make relevant changes (probably just need to reference the content types created when requesting data from users)
6.Check through the workflow and change any fields linked back to the original document library – THIS IS THE MOST LABORIOUS JOB!
• UPDATE…ACTUALLY IT'S QUICKER AND EASIER TO OPEN THE XOML AND DO A GLOBAL SEARCH AND REPLACE LOOKING FOR THE GUID OF THE ORIGINAL LIBRARY AND REPLACING THAT WITH THE GUID OF YOUR NEW LIBRARY (GET THE GUID FROM THE URL LINKS ON THE SETTINGS PAGES, THE "AUDIENCE TARGETING SETTING' LINK IS PARTICULARLY HELPFUL!)
To a different site:
Your workflow is great and now everyone wants a go! You need to deploy not just within the same site but to another location in your farm
The steps here are similar to the above, with the exception that you will have to copy all the files that are re-quired to run the original workflow to the new location. These files are usually just the ASPX pages that are run when you collect data from a user, you'll need to change the config file to associate the workflow with the files in the new location. Better still copy the files to a central location and reference them this location in both workflow's. That way you only have one set of files to keep up to date.
After you've done this you can follow the steps above to make the necessary changes.
Neither of these approaches is really ideal and to be honest there should be tools to make this process eas-ier, you can kind of see from the structure here that there is an app waiting to be written for this and if I have the time maybe I'll put one together. In the meantime please feel free to comment if you know of a simpler method.
Porting SharePoint Designer Workflows to Visual Studio
In reali-ty, 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;).
I’d strongly recommend having a basic understanding of how VS workflows work prior to reading this. For general information about building VS workflows, the SharePoint blog is a good place to start.
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 com-puter. 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:
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;).
References:-
http://blogs.msdn.com/sharepointdesigner/archive/2007/07/06/porting-sharepoint-designer-workflows-to-visual-studio.aspx
http://vspug.com/andynoon/2007/09/18/reparenting-a-workflow-to-a-different-list/
http://sanketinfo.wordpress.com/2009/05/05/limitation-of-sharepoint-designerspd-workflow/
No comments:
Post a Comment