The problem with normal workflow actions is that they are designed to work inside a single web. It is not possible, for example, to create a new list item in a different web. Creating list items in different webs is a very powerful feature, because it allows us to interact with different site areas and we might also want to initiate new workflows over there.

To overcome the short come of these standard workflow actions, we can use the SharePoint web services. But there is one major problem: SharePoint Designer Workflows don’t have a workflow action that allows you to call SharePoint web services.

Luckily I found a project at CodePlex which allows us to do just that. The iLoveSharePoint project contains a subproject with the name SharePoint Designer Actions V1.0. Download this expansion for SharePoint Designer and install it at your SharePoint farm.

Below I will provide a few demonstration steps that will use the following new SharePoint Designer Actions from iLoveSharePoint:

• Call a WebService
• Query XML

The “Call a WebService” action will allow us to communicate with the Microsoft SharePoint web services and provides us with an almost unlimited range of extra development possibilities. The small downside is that these actions are advanced and that it takes some time to configure them.

Step 1: Create the required sites and lists
For this demo we have to prepare the SharePoint environment with 2 blank sites.

Create a site which will function as the parent site. Give it the name “Demo” and create a standard list with the name “SourceList”.

Continue with the creation of a second site. This site should be a sub site of the demo site. Give it the name “Sub Site”.  Add a new standard list with the name “TargetList” and also add an extra column with the name “Information”.

In my demo the urls are

• http://moss2007dev/Demo
• http://moss2007dev/Demo/SubSite

Step 2: Use SharePoint Designer to create a new workflow

Start SharePoint Designer and open the Demo site we just created.

From the file menu choose to create a new workflow.

Name our workflow “WebServiceDemo” and attach it to the “SourceList”.

Choose to start the workflow manually and when a new item is created.

Step 3: Create the first step

We will now add our first step. During this first step we will call the lists.asmx web service and create a new item in the Sub site “TargetList” list.

Give a name to the first step like “Create an item in the Sub Site target list.”

SharePoint designer won’t be able to create an item in the “TargetList” because it is not located in the Demo site. To work around this issue we will use the SharePoint Web services.

Add a new action to the first step and search for the “Call a Web Service” action. This action should be available if you installed the iLoveSharePoint SharePoint Designer actions.

The “Call a Web Service” action accepts a few parameters:

• Address – Url to the web services
• SOAP Version – Soap version to use
• SOAP Action – Redundant in our case
• Envelope – The XML message we’ll send to the web service
• Response – The XML message returned from the web service
• User – Username
• Password – Password for the specified user

In all our web service calls we will not specify the SOAP Action and the User/Password combination. Without any provided credentials the web service will be executed using the service account.

I do also always specify the SOAP Version as 1.2.

Now let’s provide the parameters with some data:

Address
http://moss2007dev/Demo/SubSite/_vti_bin/lists.asmx

SOAP Version
Soap 1.2

Envelope

Response
Store the response in a string variable called “WorkflowResponse”.

We have now completed the first step in our workflow and we should be able to create a list item in the “Sub Site” by adding a new item in the “SourceList” list located at the Demo site.

Save and publish the workflow.

Step 4: Check and run the workflow.

Navigate to the Demo site and open the “SourceList” list. Create a new item and provide the value “Hello World” as Title, because every demo should include a “Hello World” example, right?

If everything works correctly the “SourceList” list should show a “WebServiceDemo” column with the value “Completed”.

Navigate to our “Sub Site” en open the “TargetList” list. Our new list item should be shown here!

Step 5: Create a demo workflow in the “Sub Site” site

An interesting scenario would be that we trigger a new workflow when an item is created in the “TargetList” list. To demonstrate this open the “Sub site” site in SharePoint designer and create a new workflow on the “TargetList” list.

Name the workflow “UpdateTitleField” and attach it to the “TargetList” list.

Choose to start the workflow manually and when a new item is created.

Step 6: Configure the first step to update the Title field

Give a name to the first step like “Update the title field”.

Add a new action to the step and search for the “Set Field in Current Item” action.

Configure the action to update the “Title” field and set the value to “Updated by Workflow”.

Save the new workflow.

Step 7: Test the “UpdateTitleField” workflow

Navigate to the “TargetList” list and open the item menu of our first created item.

Choose the option “Workflows”.

You will now see a screen with all available workflows. Click the “UpdateTitleField” workflow and start the workflow.

The workflow should complete and update the title field of the item.

Step 8: Test the complete flow

We have now completed our flow:

1. An item is manually created in the “SourceList” list
2. The “WebServiceDemo” workflow is triggered
3. An information list item is created via the web service call in the “TargetList” list
4. The “UpdateTitleField” workflow should be triggered
5. The title of the list item is updated

So let’s start by creating the manual item at the Demo site. Now quickly navigate to the “Sub site” to see the result. But you’ll probably see that step 4 of our flow didn’t trigger! It didn’t work as it should.

If it did work correctly you are in luck because your AppPool identity was differently configured. In most cases the service account is not allowed to auto start workflows.

This behavior is explained by Microsoft in KB947284:

“This behavior occurs because a security fix in Windows SharePoint Services 3.0 SP1 prevents declarative workflows from starting automatically under the system account.”

Step 9: Collect the item url of the newly created item

To overcome the auto start problem we can trigger the workflow with a web service call.

For this call we need the path of the new item and the templateID of the workflow. In this demo we will retrieve the templateID in the workflow, but once you know the templateId you can of course hardcode it in your web service call to minimize the system load.

Create a new step in the “WebServiceDemo” workflow and name it “Collect WF parameters”.

Add a new action. This time we will use the iLoveSharepoint “Query XML” action.

The “Query XML” action accepts 3 parameters:

• XML Input – the XML to be processed
• XPath – The XPath query to run
• Result – The variable in which the result will be stored

Let’s provide the parameters with some data:

XML Input
Variable: WorkflowResponse

XPath
//@ows_EncodedAbsUrl

Result
Create a new string variable with the name “ItemUrl”

To be able to analyze any result, add a second action of the type “Log to History List”. This action will write given information into the workflow history list. Configure the action to log the variable “ItemUrl”.

Save the workflow with our latest changes.

Step 10: Run the workflow and see if the new item url is collected

We will now check if the item url is logged in workflow history.

Navigate to the “SourceList” list and create a new item.

After submit wait until the workflow “WebServiceDemo” is completed and then click the completed link.

You will find the workflow history on this page and you should see the url of the new item.

Step 11: Collect the TemplateID of the workflow

To retrieve the TemplateID of a workflow we can use workflow.asmx web service.

Open the “WebServiceDemo” again in SharePoint designer and load the “Collect WF parameters” step.

Add a new “Call a Web Service” action and provide the following parameters:

Address
http://moss2007dev/Demo/SubSite/_vti_bin/workflow.asmx

SOAP Version
Soap 1.2

Envelope

Response
Store the response in the existing variable called “WorkflowResponse”.

To query the Workflow Template Id add a new “Query XML” action and use the following parameters:

XML Input
Variable: WorkflowResponse

XPath
//@TemplateId[1]

Result
Create a new string variable with the name “WFTemplateID”.

Note that the workflow result is returning namespaces. Because of the namespaces it is quite difficult to do a full XPath query. The //@TemplateId XPath works but when you have more as 1 workflow on the list, play with the [index] option to find the correct templateID.

Finish the “Collect WF parameters” step by logging the “WFTemplateID” into the history list.

Step 12: Check the workflow history for the Workflow Template ID

We will now check if the workflow TemplateID is logged in workflow history.

Navigate to the “SourceList” list and create a new item.

After submit wait until the workflow “WebServiceDemo” is completed and then click the completed link.

You will find the workflow history on this page and you should see the ID of the Workflow Template ID.

Step 13: Start the “UpdateTitleField” workflow via a web service call

We now have all the information required to start the “UpdateTitleField” workflow on the automatically created items.

Open the “WebServiceDemo” workflow again in SharePoint designer and add a third step with the name “Start UpdateTitleField workflow”.

We only need to add a single workflow action here of the type “Call a Web Service”.

We configure the parameters to use the “StartWorkflow” action of the workflows.asmx web service:

Address
http://moss2007dev/Demo/SubSite/_vti_bin/workflow.asmx

SOAP Version
Soap 1.2

Envelope

Save the workflow when you are finished configuring the action.

Step 14: Run the final test

We should now have really completed our flow.

1. An list item is manually created in the “SourceList” list
2. The “WebServiceDemo” workflow is triggered
3. An information list item is created via the web service call in the “TargetList” list
4. The “UpdateTitleField” workflow should be triggered
5. The title of the list item is updated

So let’s try it again. Navigate to the “SourceList” list and create a new item. Check if the “UpdateTitleField” workflow completes successfully and then navigate to the “Sub site” and the “TargetList” list to check the result.

If the configuration was successful you will now see that all the steps in our flow completed successfully!

This demonstration showed you how to

• Call web services from SharePoint designer
• Extract xml values from the web service responses
• Trigger a workflow via a web service call

Thanks to the iLoveSharePoint SharePoint Designer Actions you have a lot of new workflow possibilities. Enjoy and be creative!

The only other option on the page is to schedule the compilation, but it can only be scheduled to run once a day. Not very useful during development.

After some digging I found the command line application to control the audience job and luckily it wasn’t very complicated to use. Just run the application to get some more information:

The best of it is that the application provides you the GUIDs of available Shared Service providers.

To start a new compilation from scratch for all the audiences, run the command with the given GUID and the two other parameters:

This blog post from Alexander Windel provided enough information about the process of migrating Sharepoint users. For WSS sites you can use the “stsadm -o migrateuser” command, but this is not enough for a Sharepoint 2003 Portal Server. The problem is that you’ll also need to use code to call the function PortalAccountMigrationManager.MigrateAccount() in the object model.

Last evening I created a small Sharepoint user migration utility, to make our life a bit easier. It will run both commands for you and it will allow you to migrate a larger batch of Sharepoint users at once.

Step 1)
Scan for users in your site collection to create the basic user xml file:
MigrateSPUsers.exe -detectusers http://mysitecollection -userfile users.xml

Step 2)
Edit the user xml file. Remove users that should not be migrated or add missing users. Change the “NewLogin” nodes to include the new account information.

Step 3)
Start the Sharepoint user migration by providing the tool the following parameters
MigrateSPUsers.exe -migrateusers -userfile users.xml
or for a Sharepoint Portal Server use
MigrateSPUsers.exe -migrateusers -userfile users.xml -portal -ignoresidhistory

Step 4)
Done! Check your Sharepoint site to see if all your users are correctly migrated.

Please note that you have to run this application at the Sharepoint server with enough user rights. The server should also contain the .Net2 runtimes. This utility is for use with Sharepoint 2003 only and it is for use on your own risk.

Click here to download MigrateSPUsers v1.0