I’ve been talking a bit about workflow foundation lately. Basically I’ve been trying to set a background for what was coming – Talking about Workflow in SharePoint 2007.
So far I’ve talked about –
What is Windows Workflow Foundation?
Workflow Foundation: The Hello World App
CompositeActivities: Workflow activities that contain one or more child activities.
.. and finally, some theory and criticism of ..
Transaction support in Workflow Foundation
I still owe you a number of topics on Workflow Foundation, including custom services, persistence, correlation, and of course the workflow compiler and runtime. Time permitting I will talk more about those in subsequent blog posts.
For now, let us dive straight into a simple “Hello World’ish” example of Workflow in SharePoint 2007.
In this blog post, I will write up a simple workflow example, associate it with a simple custom list. The workflow is super simplistic, it simply takes the newly added list item, and does some activity behind it. There is no human interaction involved. This kind of workflow is perfect for doing system work behind the scenes, such as shooting an email, or throwing a wait condition etc. In a future blog post I will talk about associating workflows with human input using InfoPath 2007 forms, or ASPX’es.
So let us get started.
The first step is to create a SharePoint Sequential Workflow Library as shown below.
I’m calling it SMWorkflow, you can call it whatever you wish.
Next, open the workflow1.cs file, and it should look a bit like this.
Now you can add more activities if you wish, but I am going to keep this super duper simple. So I will double click on the green blurb, and simply add the following code in the _Invoked event handler.
private void onWorkflowActivated1_Invoked(object sender, ExternalDataEventArgs e)
": Processed by Custom Workflow";
As you can see, I am simply getting a hold of the current item, and updating appending “: Processed by Custom Workflow” to its Title Text. You can make this workflow complicated if you wish – you can add custom activities etc. To keep this example simple, I am going to skip that, but trust me – it’s rather easy to extend this.
Next you need to do some hardwork in installing this workflow.
Now as it turned out, my code snippets were broken, so I had to hand-type the feature.xml, workflow.xml and install.bat files. What a pain in the donkey!!
Anyway, here goes. First the workflow.xml file (I’ve already strong named my assembly, and pulled out the public key token etc.):
<?xml version="1.0" encoding="utf-8" ?>
Name="SM Workflow Example"
Description="This is a simple workflow I created."
CodeBesideAssembly="SMWorkflow, Version=188.8.131.52, Culture=neutral, PublicKeyToken=bf67e65a604d67e1"
Then the feature.xml file which do note that it has a reference to the workflow.xml file.
<?xml version="1.0" encoding="utf-8"?>
ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=184.108.40.206, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
<ElementManifest Location="workflow.xml" />
<Property Key="GloballyAvailable" Value="true" />
<Property Key="RegisterForms" Value="*.xsn" />
And finally the install.bat file which throws my assembly in the GAC (which means I need to strong name it), and installs and activates the feature in SharePoint 2007 at site scope.
echo Copying the feature...
rd /s /q "%CommonProgramFiles%\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\SMWorkflow"
mkdir "%CommonProgramFiles%\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\SMWorkflow"
copy /Y feature.xml "%CommonProgramFiles%\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\SMWorkflow\"
copy /Y workflow.xml "%CommonProgramFiles%\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\SMWorkflow\"
xcopy /s /Y *.xsn "%programfiles%\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\SMWorkflow\"
echo Adding assemblies to the GAC...
"%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" -uf SMWorkflow
"%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" -if bin\Debug\SMWorkflow.dll
echo Activating the feature...
pushd %programfiles%\common files\microsoft shared\web server extensions\12\bin
stsadm -o deactivatefeature -filename SMWorkflow\feature.xml -url http://localhost
stsadm -o uninstallfeature -filename SMWorkflow\feature.xml
stsadm -o installfeature -filename SMWorkflow\feature.xml -force
stsadm -o activatefeature -filename SMWorkflow\feature.xml -url http://localhost
echo Doing an iisreset...
Whew !! That was a mouthful.
Now just run Install.bat. I am going to skip posting the scary screenshot of the gazillion unixy command line thingies the installation throws at you. I seriously think given the love SharePoint has for fragile XML files and Batch files, and GAC, I think SharePoint is a closet unix-o-sexual. But that is a whole another discussion.
Great, the feature is installed and ready to use (activated). Let us go ahead and set up a simple custom list.
In the custom list, go to List Settings, and under Permissions and Policies, click on “Workflow Settings”
Fill in the ensuing form a bit like this:
Then go back to your list, and add a new item.
You would note that the item has been added as shown below:
WAIT A MINUTE!! Where is my workflow?
Well, the workflow did get fired. Since it was asynchronously fired, you don’t see it yet. But hit Refresh (F5), and you will see that your item has been processed by your custom workflow.
HOW NEAT IS THAT!!! :)
Not only that, you can debug your workflow by attaching to the w3wp process. Just for kicks, modify this workflow properties so it is kicked automatically when the item is changed also.
Observe what happens!! Can you explain the behavior? ;-)
.. Well hope you enjoyed this blog post, sometime in the near future, I shall talk about workflows in SharePoint that need human IO, and of course other workflow foundation topics.