Why Can’t I Easily Port SharePoint Designer Workflow Solutions From One List to Another? Part 1
Every first-time SharePoint Designer workflow author faces this problem:
- Design a workflow solution.
- Create a new workflow solution.
- Test it.
- Gain user acceptance and sign off.
At this point, everything is going swimmingly until it’s time to …
5. Move to production … full stop.
Today, there is no End User friendly way to move a functioning SharePoint Designer workflow solution from a dev/test environment to a separate production server. SharePoint Designer itself offers no method to do it.
A site export/import process is not guaranteed to work. And even if export/import did work, it would only work once since repeating the export/import process would overwrite production the second time around. Templates don’t help.
SharePoint Designer workflow does not transfer via the template saving process (and again, even if it did, it would only be useful once).
This article explains the “why” and the next article in this two-part series will describe an approach that some End Users may feel they can follow to migrate a SharePoint Designer solution from one environment to another.
In order to understand the “why” of the problem, and then to understand the “how” of it next week, we need to consider the big picture. Today, SharePoint offers three main workflow solutions:
- Out of the box (OOB) workflow: SharePoint provides a handful of approval oriented workflow solutions which are always available for all lists and document libraries. These are “take it or leave it” in nature. They cannot be modified by End Users or developers.
- SharePoint Designer workflow: The subject of this article.
- Visual Studio Workflow: Experienced programmers use this state of the art development tool to craft SharePoint solutions.
End Users work with SharePoint Designer to create what is called a declarative workflow. There’s a very technical definition in a computer science sense of the word declarative. However, it boils down to this: End Users define in English like sentences what steps a workflow should take from start to finish.
SharePoint Designer provides a decent, albeit very click-heavy, user interface for this purpose. We can define conditions, actions, steps. We can define variables, look up data from lists, collect feedback from users, rearrange actions and steps. And again, although it can take a lot of clicks to get the job done, the user interface is pretty good.
SharePoint Designer does a lot of work behind the scenes. All of that clicking, variable-defining and step rearranging hides the real heavy lifting. SharePoint Designer validates the workflow, creates XOML and supporting files and teaches SharePoint about the connection between that workflow and the list or document to which it is attached.
What is XOML? First, it’s pronounced “Zommel.” Many End Users won’t ever bother to look at the XOML file, but it’s full of interesting stuff. It’s more or less English readable because it’s in a format called XML (extensible markup language). Unlike the OOB workflows (which cannot be looked at) and visual studio workflows (which are compiled into machine language), SharePoint Designer declarative workflows are readable text. In fact, you can open up a XOML file directly, view it and even change it. The next article leverages this fact to describe how to move a SharePoint Designer workflow from one system to another.
We can think of XOML as being fuel for a car engine. We pour some XOML into the workflow engine and the engine runs.
When we create a workflow for the first time, SharePoint Designer creates a new XOML file based on the steps, conditions and actions we declare. When we edit a workflow, SharePoint Designer retrieves the steps, conditions and actions we had previously declared, allows us to edit them and then saves them back into a new XOML file with the same name.
Given this, it’s easy and sensible to ask: why is it so hard to move a SharePoint Designer workflow from one server to another? If all of the information resides in this XOML file, can’t we just copy it to the production server and it should work? Sadly, we cannot.
When SharePoint Designer creates a XOML file, it not only saves steps, conditions and actions, it also saves references to users, the site and the list or library to which the workflow is attached. Worse, it saves that information in a non-portable manner.
For example, assume we’ve defined a workflow against a list named, “Environmental Permits.” That list is named “Environment Permits,” but SharePoint maintains an internal unique identifier that looks something like: “6D2DB4A4-230B-4C75-93A9-8F70D0BE7E6D”. Sadly, the XOML file uses that unique identifier (called a GUID) instead of the name, “Environmental Permits.”
To put the final nail in the coffin, that internal unique ID (the GUID) will never be the same on two different servers. So, even though we may have an identical list named “Environmental Permits” on two different servers, their GUID will not be the same. Since the XOML references the list name via GUID, we can’t just copy it from one server to another.
There are a few other minor issues, but that is the core problem, summarized here:
- SharePoint Designer creates XOML files.
- XOML files contain embedded references to lists and document libraries
- These references are always unique from one environment to the next.decentdecent
Next week’s article describes how to overcome this problem.
Author: Paul Galvin, Microsoft MVP – SharePoint
Web site: Paul Galvin’s SharePoint Space
on
Greetings! As always, I try to monitor and respond to comments or questions left with my articles.
–Paul Galvin
Hi Paul,
One of the examples in my book, which should be on the shelves any day (probably early next week, but as late as the end of the month), creates a SharePoint Designer add-in to export SPD workflows and convert them for use in Visual Studio. This particuar chapter was written by Bryan Phillips, using techniques pioneered by Todd Bleeker along with my implementation suggestions. For the *really* curious, the example’s source code is actually already available for download from Wrox’s web page for the book.
– Woody -
Paul,
Really looking forward to the solution in the next episode. At the moment (for me) SPD is a non-runner in any environment because of the issues you’ve outlined above.
I’d be interested if you have any inside knowledge on why Microsoft thought it would be useful to design workflows that couldn’t be re-used?
Joe
One way I copy workflows from a dev workspace to live is by changing the version number of the workflows to 1.0 within the wfconfig.xml file in SharePoint Designer before saving the workspace as a template.
I can then recreate the workspace in live from the template using the existing workflows. Some minimal customisation of the workflows may be necessary to repoint things in the right direction.
I've never tried this before, but could you put the list name instead of the GUID in the XOML file? I might have to give that a try...Anyways, looking forward to next week!!When I develop eventhandlers in VS I have the option of using the string value as the list name. If the XOML file is sending XML at the code behind, could you wire it up to send a key-value pairing to the code?
Angie – You’ve spoken two ‘verboten’ words here at EndUserSharePoint… ‘VS’ and ‘code’. You are treading on thin ice. Would you like to restate your problem? We are always willing to give second chances. — Mark
Can wait to read your solution to this problem.
Azha – I assume you mean “can not” as in a compliment to Paul. I am also waiting to see how this plays out. — Mark
“… why Microsoft thought it would be useful to design workflows that couldn’t be re-used?”
Maybe because reuse is not the only criterion?
I’d rather have non-reusable workflows now than have to wait until the solution is perfect.
Christophe
Hi, One thing missing from problems mentioned above is that if SPD workflows uses Collect data -activities is that those activities are actually created as Content types to associated task list. These are not automatically created to new location and they are also left behind if Collect data -activity is removed from workflow.
It is possible to create Content to new location by clicking through options of the activity in the SPD interface.
Another way to make it a little easier to migrate the workflow is to regularly synch up your prod and dev environments by using SQL backups instead of stsadm. By copying the database itself you end up with the exact same GUIDs in both environments – at least for lists and sites created before the snapshot. This makes some other tasks easier for developers too.
That is also easy to do as an enduser – you just call your DBA!
woody i just used your tool to port a sharepoint designer workflow to c sharp i got this
namespace Microsoft.SharePoint.Workflow {
using System;
using System.Drawing;
using System.ComponentModel;
using System.ComponentModel.Design;
using System.Workflow.ComponentModel;
using System.Workflow.ComponentModel.Design;
using System.Workflow.ComponentModel.Compiler;
using System.Workflow.ComponentModel.Serialization;
using System.Workflow.Runtime;
using System.Workflow.Activities.Rules;
using System.Collections;
using System.Collections.Generic;
using System.Workflow.Activities;
using Microsoft.SharePoint.WorkflowActions;
public partial class ROOT : Microsoft.SharePoint.WorkflowActions.RootWorkflowActivityWithData {
private void ID1_Invoked(object sender, ExternalDataEventArgs e) {
__context = new WorkflowContext();
__context.Initialize(__initParams);
__list = __initParams.List.ToString();
__item = __initParams.ItemId;
__workflowId = __initParams.WorkflowId;
}
}
}
seems pretty useless to me!
explain how this can be useful and i will buy your book!
Hi Jon,
I just saw this comment. I’m calling it to the attention of Bryan Philips, who wrote the workflow export/add-in code and chapter. Hopefully he will be able to respond directly.
– Woody -
Jon,
Can you post your xoml file, too? It contains the activities defined in your workflow.
SharePoint Designer-created workflows are declarative meaning that the activities and their settings are stored in XML format rather than code. This is the same as creating a workflow in Visual Studio choosing the item template “Sequential Workflow (with code separation)” rather than the item template “Sequential Workflow (code).” The C# code-beside file created in Visual Studio or by using the SharePoint Designer Add-In stores event handler code for the activities in the workflow.
The method in the C# file you posted is actually the event handler for the OnWorkflowActivated activity which is required as the first activity in any SharePoint workflow (regardless of how it was created). Handling this event gives you access to the workflow’s initialization parameters and the list and item that fired the workflow.
Let me know if this does or does not clarify things.
Thanks,
Bryan
Hi
I followed exactly the same steps what you posted here to migrate workflows.However I got error when trying to finish the workflow in the migrated environment as
Errors were found when compiling the workflow. The workflow files were saved but cannot be run.
When looked in to details of the error I could find something like
(0, 0) Activity ‘ID3′ validation failed: Can not find the condition “__Rule_ID3″.)
Can you help me in resolving this bcoz i got the same error when I tried with other workflow also
Thanks
Sireesh
Thanks Paul…great series!
Had a quick question about global find/replace for hard coded (absolute) links in some of our workflows. Is there a way to access the full “code behind” for workflows built in Designer; in other words, not just the “[filename].xoml.wfconfig.xml” and “[filename].xoml.rules” files, but the full code, so that you could actually leverage a search/replace type of tool for changing out bad links?
Any thoughts on this would be greatly appreciated!
Thanks,
Tom
Good info. I have a related question, sort of.
Is there any way to visually document a SharePoint designer workflow? I am not looking for a status report but a visual representation of the workflow without having to manually create one in Visio.
I’ve used this method and it works well:
http://nickgrattan.wordpress.com/2007/10/17/applying-a-sharepoint-designer-workflow-to-multiple-lists/
You really can export them!