Corey Roth [MVP] : Workflow

What you need to know about copying workflows with Metalogix Migration Manager for SharePoint

CoreyRoth — Fri, 20 Jul 2012 00:39:32 GMT

I was recently doing a SharePoint migration project and one of the tasks I was trying to do was copy SharePoint designer workflows (plus history) to a new SharePoint server. We weren’t doing a database attach in this case because we were significantly restructuring the site. When version 5 of Metalogix Migration Manager for SharePoint announced this functionality, I was excited to try it out. The tool can in fact copy these workflows but there are a lot of asterisks. These are the things you don’t know until after you try it and have opened up a support case. :) If you are thinking about migrating workflows in this manner, this post may be of some help to you.

There are a few things you need to know about migrating workflows:

You can only copy workflows if you are doing a Full Site migration (no incremental or anything like that).
You need to activate the SharePoint 2007 Workflows feature on the target site collection.
Migrated workflow instances cannot be completed.
You must set the EnableDBWriting element to true in EnvironmentSettings.xml located at %APPDATA%\Metalogix Software Corp\Migration Manager for SharePoint.

You probably just read that last bullet point thinking “Is that doing what I think it is?” The answer is “Yes”. You can only check the copy workflow instances settings in the Migration Manager if you have this value enabled. What does it do? It writes directly to the content database. Should red flags be going up? Probably, but when your client is screaming at you to get those workflows migrated at all cost, the option looks better and better. However, if you have an issue down the road and Microsoft support find out about it, they may be less inclined to help you. Does it work? Maybe. In my tests, I have found that it in fact does successfully attach the workflow to the list or content type you migrated. However, the running instances count shows as zero. I am not sure if this is part of the issue with the workflow instances not being able to be completed or it is a bug.

To actually copy workflows, close migration manager and go edit the EnvironmentSettings.xml file. Once you set the EnableDBWriting flag, re-open Migration Manager. Pick the site you want to copy and use the Copy Site command. Then use the Paste Site command at the destination. On the workflow tab, you will see a new section that is no longer disabled.

You’ll want to check the Preserve checkboxes for List scope or Content type scope depending on where your workflow is. Then you will want to check the Preserve workflow instance data checkbox along with Preserve running workflow instance statuses. Run the job and when the site is create with luck your workflows will be there.

I’ll continue testing this as I have time. If you try it out, let me know how it works for you.

Follow me on twitter: @coreyroth.

Using LINQ to XML to access the data of a form saved to a form library in a workflow

CoreyRoth — Wed, 06 May 2009 21:40:37 GMT

As I have mention in the past LINQ to XML is a great way to manipulate the XML data out of an InfoPath form. I thought I would show how you can also use the same technique to work with the data of a form saved to a form library which launches a workflow (although you could apply this technique to the association or task forms as well). The first thing we need to do is get the XML of the InfoPath initiation form, before we can work with it.

For the purpose of my example, my OnWorkflowActivated activity writes to a public SPWorkflowActivationProperties property called workflowProperties. In my Invoked event handling method of my OnWorkflowActivated activity, we use the Item object on my workflowProperties to open the file and get the XML. You can then use the File object along with OpenBinary() to get the raw bytes of the XML.

byte[] xmlBytes = workflowProperties.Item.File.OpenBinary();

You can then takes those bytes and read them into a regular string.

string xmlString = System.Text.Encoding.UTF8.GetString(xmlBytes);
if (xmlString[0] == (char)0xfeff)
    xmlString = xmlString.Substring(1);

If you are curious about the 0xfeff business that is used to deal with the byte-order mark character in Unicode. I picked up this trick from another post somewhere, but I can’t remember where currently.

Now we need to get the XML string into an XDocument class so that we can query it and manipulate it. Since we have a string, we will need to create a StringReader to read it.

XDocument documentsXml = XDocument.Load(new System.IO.StringReader(xmlString));

If you wanted to work with the Association form instead of the form that started the workflow, you would use a line like the following. The InitiationData property of the SPWorkflowActivationProperties object provides XML that can be loaded into the XDocument class.

XDocument documentsXml = XDocument.Load(workflowProperties.InitiationData);

InfoPath documents always have a namespace defined for my so we need to use the XNamespace object for any future references inside the InfoPath form.

XNamespace documentNamespace = "http://schemas.microsoft.com/office/infopath/2003/myXSD/2098-05-03T16:48:38";

At this point you can start using LINQ to XML to get the data you need out of the InfoPath form. For example, if I had a field called my:FirstName at the root of the document. I could use something like the following to get the value.

string firstName = documentsXml.Root.Element(documentNamespace + "FirstName").Value;

If you are working with other data types, you can always cast it like this.

int customerId = int.Parse(documentsXml.Root.Element(documentNamespace + "CustomerId").Value);

In my example from last week, you saw how you could use LINQ to XML to iterate through a repeating table. As another example to iterate through a repeating table called Items with an element of Item, you could do something like the following:

var items = from item in documentsXml.Root.Element("Items").Elements("Item")
            select item;
 
foreach (var item in items)
{
    Console.WriteLine(item.Element("Field1").Value);
    Console.WriteLine(item.Element("Field2").Value);
}

In this case, I use LINQ to return an IEnumberable<XElement> representing each repeating item. I can then use this in a foreach loop to print out the results. Yes I know you wouldn’t use Console.Writeline in a workflow, but you get the point here. LINQ to XML really offers a lot of flexibility to manipulate the XML data inside a form. Hopefully, it will make your experience with InfoPath and workflow a better one.

Handling ShortTerm CheckOut Locks in your Records Center Workflow

CoreyRoth — Thu, 29 Jan 2009 20:39:20 GMT

The other day, I posted about how to write a simple workflow to copy files to the records center whenever they were created or modified. Well the workflow I provided worked in all of the following cases.

Add new item
Upload Item
Upload new version to existing item
manual check out then check back in (with no changes to the doc.)
Edit document properties (When checkout required is set on the library)

Of course there was one place that I found that it doesn't work. It is when you use the New Document button or edit an existing document directly with Office 2007. The reason for this is that when you have a document open with Office, it creates a Short Term Check Out for the period of an hour. It also continues to reestablish the lock until you close the Office application (i.e.: Microsoft Word). Records Center will not accept any document that is currently checked out. This presented an interesting challenge on how to deal with this. The first thing I tried was adding code to check in the file (i.e.: SPFile.CheckIn). This method does not work when the CheckOutType is ShortTerm.

I tried an ItemEventReceiver to see if closing Office would trigger the ItemCheckedIn event, but it in fact does not. This means I can't handle this scenario that way either. So what I came up with was a hack, but it does in fact get the job done (provided the user eventually closes the Office application). Here is what it looks like.

I did say hack, didn't I? That's exactly what it is. The While activity contains the following code condition. All it does it execute the contents of the while activity as long as the CheckOutStatus is set to ShortTerm (meaning the user still has Microsoft Word open).

private void IsShortTermCheckedOut(object sender, ConditionalEventArgs e)
{
    e.Result = (workflowProperties.Item.File.CheckOutStatus == SPFile.SPCheckOutStatus.ShortTerm);
}

As you can see there is a Delay activity in there. These actually seem to work now, but you do need to be sure that you have the latest version of the .NET Framework installed as well as all updates applied to SharePoint. Otherwise there is a good chance that your workflow will never wake back up. I have the delay set to 15 minutes. This is because the workflow timer job runs every 15 minutes (by default).

Other than that the code is all the same from the previous post. I've ran it through several tests and it seems to work for me. I'd like to think there is a better way to handle this, but I can't think of anything right now. You might consider adding code to the while activity so that it eventually terminates if the user never closes Office, but that is up to you.

Workflow doesn't start when accessing SharePoint site via IP address

CoreyRoth — Thu, 29 Jan 2009 18:40:00 GMT

Now, I have always known there are some oddities when accessing a SharePoint server by IP and as a practice I tend to avoid it. I am sure the issue I am about to describe relates to alternate access paths in some way, but I thought I would tell people about it in case someone else runs into it. The scenario I have is quite simple. I have a custom workflow attached to a document library that executes whenever a file is created or modified. What I discovered was that when I was accessing the site on my virtual machine by name, the workflow was executing. When I tried to reach it from the host machine by IP address, it did not execute. It didn't give an error or anything. It simply did not start. The reason I was accessing by IP to begin with is because the server name wasn't resolving on my host machine and I was being too lazy to fix it. Next time, I won't make this mistake. Workflows will not automatically start when you specify the server by IP address in your browser.

InfoPath Task Form: An error occurred accessing a data source.

CoreyRoth — Mon, 15 Dec 2008 18:18:45 GMT

After building a workflow recently, I noticed I was getting the following error whenever I opened the task form.

An error occurred accessing a data source.

I have seen the error in the past when trying to connect to an external web service when it was down, but this form was much simpler than that. The only data source it had was ItemMetadata.xml. The weird thing was everything on the form was working. At this point, I decided to hit the LOGS folder and see if I could figure out what was going on. The error wasn't in there, but I found entries for my form along with an error stating that it could not read the ItemMetadata.xml file from the file system.

At this point, the answer was obvious to me. When I configured the secondary datasource, I somehow didn't set the option "Include this file as a resource in the form template or template part". I selected this option, republished my form, and then reinstalled the workflow. To no surprise, I saw that the error went away.