Nick Swan's SharePoint Blog

a day in the life of a Sharepoint and .NET guy!

My Links

News




Post Categories

Archives

Blog Stats

Blogroll

Books

VB-tech website

VB-tech work

Xbox

Deploying a custom MOSS 2007 workflow

Hopefully you’ll have read the epic blog post yesterday on how to create a custom workflow template with Visual Studio 2005 and InfoPath 2007. Once you’ve followed through all the steps and the solution succesfully builds, we’re going to want to deploy our workflow to our MOSS 2007 server.

A workflow is basically a Feature. For a good definition of what a Feature is take a look here:

http://msdn2.microsoft.com/en-us/library/ms460318.aspx

To deploy our Feature we’re going to edit feature.xml, workflow.xml and Install.bat.

Feature.xml

In this file we’re going to add the xml that defines our features. If the ECM starter kit installed correctly you can add a code snippet to give you the outline of the feature.xml. If however your code snippets don’t work like mine, you can copy and paste this and edit it:

<?xml version="1.0" encoding="utf-8"?>
<Feature  Id="553c6150-a1fb-4856-b06c-94c1fb1036e7"
          Title="Demo Workflow"
          Description="Demo Workflow Description."
          Version="12.0.0.0"
          Scope="Site"
          ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
          ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver"
          xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest Location="workflow.xml" />
  </ElementManifests>
  <Properties>
    <Property Key="GloballyAvailable" Value="true" />

    <!-- Value for RegisterForms key indicates the path to the forms relative to feature file location -->
    <!-- if you don't have forms, use *.xsn -->
    <Property Key="RegisterForms" Value="*.xsn" />
  </Properties>
</Feature>

The bits you need to worry about are:
Feature Id – generate your own guid for this
Title – give the Feature a meaningful title
Description – and a meaningful description.

The ElementManifest points to other files that are going to describe things that need to be deployed with your feature. Finally the Properties descibe that we want to register all the forms in the directory with a file extension .xsn. This is why we published our InfoPath 2007 forms to the same VS 2005 project directory.

Workflow.xml

Second xml file we need to edit is workflow.xml. Again you can either use a code snippet, or copy and paste the code below and edit it:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Workflow
       Name="Demo Sample"
       Description="Demo Sample Description."
       Id="28a74f98-1bef-4ca4-bd6b-a899315ea8c6"
       CodeBesideClass="DemoWorkflow.Workflow1"
       CodeBesideAssembly="DemoWorkflow, Version=3.0.0.0, Culture=neutral, PublicKeyToken=43ec7384e2e51f5a"
      TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"
       AssociationUrl="_layouts/CstWrkflIP.aspx"
       InstantiationUrl="_layouts/IniWrkflIP.aspx"
       ModificationUrl="_layouts/ModWrkflIP.aspx">

    <Categories/>
    <!-- Tags to specify InfoPath forms for the workflow; delete tags for forms that you do not have -->
    <MetaData>
      <Instantiation_FormURN>urn:schemas-microsoft-com:office:infopath:DemoInitiation:-myXSD-2006-08-29T10-55-32</Instantiation_FormURN>
      <Association_FormURN>urn:schemas-microsoft-com:office:infopath:DemoInitiation:-myXSD-2006-08-29T10-55-32</Association_FormURN>
      <Task0_FormURN>urn:schemas-microsoft-com:office:infopath:DemoReview:-myXSD-2006-08-29T13-42-24</Task0_FormURN>

      <StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl>
    </MetaData>
  </Workflow>
</Elements>

Bits we need to worry about:
Workflow Name – give the workflow a decent name
Description – an again a good description
Id – generate another new Guid. This must be different to the Guid generated for feature.xml
CodeBesideClass – your project (assembly) name first, with the actual workflow class second.
TaskListContentTypeId – I don’t actually know what this part is for. If anybody knows please leave a comment!!!
Instantiation_FormURN and Association_FormURN – these are the Id’s of our DemoInitiation InfoPath form. You can get this by opening DemoInitiation.xsn in design mode, going File -> Properties, and copying it from the ID textbox

Also do the same for Task0_FormURN which needs the Id of DemoReview.xsn.

And that’s all you’ll need to edit. Apart from the last file that is, Install.bat. I’m not going to list this file as it’s pretty easy to edit. Basically rename the text MyFeature with the name of your project, wherever it is in Install.bat.

Now you need to remember that the workflow I wrote about yesterday is being developed on the same virtual machine as MOSS 2007. Because of this we can just run Install.bat locally where it is. If you wanted to install the workflow somewhere else you’ll need to change the paths, and server names respectively, or just copy the project to the server and run Install.bat from there.

posted on Monday, September 04, 2006 10:15 PM

Get email alerts when this blog is updated!

Feedback

# re: Deploying a custom MOSS 2007 workflow 9/6/2006 7:03 AM Nick Swan

One major part I did miss out from the above, as you're deploying your workflow assembly to the GAC it'll need to be strongly named!

# re: Deploying a custom MOSS 2007 workflow 9/11/2006 5:07 PM Morna Tirona

I get an error when I try add this workflow to a shared document library. I have been back over the information several times and double checked my source code. I was wondering about the workflow.xml file: AssociationUrl="_layouts/CstWrkflIP.aspx"
InstantiationUrl="_layouts/IniWrkflIP.aspx"
ModificationUrl="_layouts/ModWrkflIP.aspx">

I don't find these pages when I was looking around at SharePoint. Do I need to create these pages?

# re: Deploying a custom MOSS 2007 workflow 9/14/2006 9:01 PM Henry O.

Hey Nick, thanks for the great article. Would you by chance know what this error means: "Value does not fall within expected range"

I get that error when I try to press the next button on the "Add a workflow" page. Thanks!

# TaskListContentTypeID 10/17/2006 7:58 PM Peter Christensen

Here's what MSDN has to say about TaskListContentTypeID:

TaskListContentTypeId
Optional Text. Specifies the content type ID of the content type assigned to the workflow task list.

For more information about task forms, see Workflow Task Forms (Windows SharePoint Services). (url: http://msdn2.microsoft.com/en-us/library/ms438856.aspx)

# re: Deploying a custom MOSS 2007 workflow 10/26/2006 2:12 PM G

Everytime I publish a form, it is per default published as restricted, which results in "FatalError: the restricted trust level is not supported";
if i change the security to "domain" or "fully trusted", the result is a "fatalErrorNoThrow: the form template has not been correctly published";
this behaviour was tested on 4 different systems, some of them beta2, some of them beta2tr;
great, i only found one article, which said: ignore this, it will work nevertheless;
but .. this is not true; i got my forms installed and in the formtemplatemgmt in the admin console they end up in a status called "installing";
what now?
pls help

# re: Deploying a custom MOSS 2007 workflow 10/27/2006 12:03 PM akjal

Hey Nick, thanks for the great article.

I have some doubts to share with you:
1.I also got an error as Henry O Got: "Value does not fall within expected range" I get that error when I try to press the next button on the "Add a workflow" page.

2.What does this node in feature.xml mean?
ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver"
3.I have no idea about these pages:
AssociationUrl="_layouts/CstWrkflIP.aspx"
InstantiationUrl="_layouts/IniWrkflIP.aspx"
ModificationUrl="_layouts/ModWrkflIP.aspx">

4.In feature.xml <Property Key="RegisterForms" Value="*.xsn" /> , should we give all infopath forms used(i.e. DemoInitiation.xsnDemoreview.xsn

Thanks!

# "Value does not fall within expected range" 11/4/2006 2:55 PM Walaa M. Atef

"Value does not fall within expected range"
Most probably due to a wrong value for the TaskListContentTypeID in the workflow.xml, I don't know what are the possible values but this one works: "0x01080100C9C9515DE4E24001905074F980F93160"

# re: Deploying a custom MOSS 2007 workflow 11/5/2006 6:13 AM jasper

Hi, Nick :
Thanks for your great artical, But I find that ...
(1) When I run Install.bat (I've modifed to fit to my environment), it show me the message as [MSG1] block;
(2) When I want to asscociate an Document Library to the sample Workflow Template, it show me the message as [MSG2] block.
Would please help me to sovle the problem?
Thanks A Lot,
Best Regards,

[MSG1]
Command 1: "C:\Program Files\common files\microsoft shared\web server extensions\12\bin\stsadm" -o verifyformtemplate -filename DemoInitiation.xsn
There were 1 errors and 0 warnings when verifying this form template.
FatalError : The restricted trust level is not supported.

Command 2: "C:\Program Files\common files\microsoft shared\web server extensions\12\bin\stsadm" -o verifyformtemplate -filename DemoReview.xsn
There were 1 errors and 0 warnings when verifying this form template.
FatalError : The restricted trust level is not supported.

Command 3: stsadm -o installfeature -filename InfoPathWorkFlowLib\feature.xml -force
The XSN can not be used on server. (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\InfoPathWorkFlowLib\DemoInitiation.xsn)
The XSN can not be used on server. (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\InfoPathWorkFlowLib\DemoReview.xsn)
Operation completed successfully.

[MSG2]
There has been an error while loading the form.
Click Try Again to attempt to load the form again. If this error persists, contact the support team for the Web site.
Click Close to exit this message.

This form cannot be opened. It is not workflow enabled.

# re: Deploying a custom MOSS 2007 workflow 11/6/2006 2:46 PM Sean Coughlan

Hi Jasper,

Try this: open your InfoPath form in design mode, then click on "design checker" in the design tasks pane. Click "Change Compatibility Settings" and select "security and trust" on the left side of the window that appears. If you uncheck the box for "automatically determine security level" and also click the "Domain" radio button and then re-publish the form, this should resolve your 1st error and possibly even your 2nd.

If you still experience problems, I've found that removing the access path for the published form can sometimes help. When you publish your form, publish to a network location as usual, click next, leave the path and filename the same, click next, then on this next window you should see a message starting with "If all form users can access the location...". Clear the text box on this window and click next. Click OK on the pop-up warning message.

Taking these steps resolved those errors for me when I was having the same problem. I hope this helps!

# re: Deploying a custom MOSS 2007 workflow 11/7/2006 12:00 AM jasper

Hi, Nick :
I've solved the error of "The restricted trust level is not supported", though there is still have some warnings as [MSG3], it can associate some Document Library with the Demo Workflow.

Thanks A Lot,
Best Regards,

[MSG3]
Command 1: "C:\Program Files\common files\microsoft shared\web server extensions\12\bin\stsadm" -o verifyformtemplate -filename DemoInitiation.xsn

There were 0 errors and 2 warnings when verifying this form template.

Ignored : This is a fully trusted form template. Only deploy fully trusted forms from trusted sources.
Ignored : One or more form templates with this file name already exist on the server. You may encounter problems from activation if a form template with the same file name is already present in the site collection.

# TaskListContentTypeId 11/15/2006 1:14 PM Boris

Hello,

For your information MOSS 2007 can have multiple item type (content type), for one list.
So when creating the task MOSS has to know what type of item to create (there can be many task types).
I tried with the value given higher but it didn't work so i went to the feature directory :
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES
and then to the TaskWorkflowContentType directory
and edited the TaskWorkflowContentType.xml file
You can find in it the content type id, wich was for me : 0x01080104
I then pasted the value for the TaskListContentTypeId attributes and it worked.

# re: Deploying a custom MOSS 2007 workflow 11/15/2006 1:18 PM Boris

Here are some more links on the subjects :
- Base Content Type Hierarchy : http://msdn2.microsoft.com/en-us/library/ms452896.aspx
- some explanations on workflow content types : http://msdn2.microsoft.com/en-us/library/ms438856.aspx

# re: Deploying a custom MOSS 2007 workflow 11/20/2006 2:41 AM chewyf

Hi,

How to I get a new Content Type Id?
Is there any sample to create a custom workflow without using InfoPath?

Thanks.

# re: Deploying a custom MOSS 2007 workflow 11/27/2006 10:51 AM newby

when i choose "myworkflow" on selected Item i get Erorr occured and in Log i get this:

Possible mismatch between the reported error with code = 0x81070504 and message: "There is no Web named "/sites/mysite/Lists/Team Discussion/AllItems.aspx"." and the returned error with code 0x80070002.

Any ideas?
tnx

# re: Deploying a custom MOSS 2007 workflow 11/28/2006 1:33 PM Mark Kamoski

Nick --

In the "Workflow.xml" file, in the node "Workflow", in the attribute "CodeBesideAssembly", isn't it the case that one does not know the value for "PublicKeyToken" until AFTER the Assembly is installed in the GAC?

I know that that is the case when deploying custom event handlers in this manner, except for event handlers the file is called "Elements.xml" and the structure is somewhat different -- so, maybe it does not apply here?

What do you think?

Please advise.

Thank you.

-- Mark Kamoski

# re: Deploying a custom MOSS 2007 workflow 12/7/2006 7:19 PM KJ

I tried all the ways to publish the form and yet it tells that the form is not workflow enabled. While running the install.bat it does not give any errors. I have checked the design compatibility for the form also and they are fine. Please help me with this error though it does not tell much.

# re: Deploying a custom MOSS 2007 workflow 12/7/2006 11:29 PM Anagha

A better description of what "TaskListContentTypeId" means as per MSDN -

This content type, included in Office SharePoint Server 2007, specifies custom task display and edit forms that include an Office Forms Server control for rendering InfoPath forms.

# re: Deploying a custom MOSS 2007 workflow 12/22/2006 3:13 PM Owen

Hi jasper

I wonder if you ever managed to get rid of the following warning you mentioned in your message:

Ignored : One or more form templates with this file name already exist on the server. You may encounter problems from activation if a form template with the same file name is already present in the site collection

It is annoying to see the warning when you try to verify a form template using stsadm. I even got the message on the first development of a custom workflow on a fresh installation.

# re: Deploying a custom MOSS 2007 workflow 12/26/2006 3:05 AM tarun

while deploying the workflow using install.bat file i m getting error

here were 1 errors and 0 warnings when verifying this form template.

FatalErrorNoThrow : This form template has not been correctly published to be br
owser-enabled. Open the form template in InfoPath Design mode, and click Publish
Form Template in the Design Tasks task pane. Follow the steps in the Publishing
Wizard to republish the form template, and then try again.


Even i ve published forms to the location where i created project for custom workflow.

please help me out what is the reason of such an error

# re: Deploying a custom MOSS 2007 workflow 1/3/2007 10:49 PM Thomas Andersson

Hi Nick,

Thanks for a great article! However, I have the same problem as many others around here that the InfoPath form is not getting installed correctly. When I look in the "Manage Form Templates" page it says "Status: Installing" and "Workflow Enabled: False". I have tried to change the Security Levels back and forth but without any luck. Also - It seems like the security level for the my features is not really updated correctly - even if I change to "Full Trust" it still says "Domain trust" in the property window in the "Manage Form Templates" page.

Do you have any more idea how to solve this problem that the forms is not installed correctly?

Thanks
Thomas

# re: Deploying a custom MOSS 2007 workflow 1/4/2007 10:00 AM Ahmad Atwi

Hi:
i followed the same steps as mentioned above, the workflow was deployed. I am trying to add the workflow to a document library, the workflow appears in the workflow list but upon clicking next an Unknown Error is reported.
any idea how to debug that error.

Thanks in Advance

# re: Deploying a custom MOSS 2007 workflow 1/10/2007 3:20 PM Cynthia

KJ, were you able to solve the "form is not workflow enabled" problem? I am having the same issue.
Thanks,
Cynthia

# "Value does not fall within expected range" 1/11/2007 12:14 AM gover

i was gettin the error ""Value does not fall within expected range"
" also. It seems to be caused by an invalid "TaskListContentTypeId" in the workflow.xml file. Ii removed the TaskListContentTypeId as wll as the AssociationUrl="_layouts/CstWrkflIP.aspx"
InstantiationUrl="_layouts/IniWrkflIP.aspx"
ModificationUrl="_layouts/ModWrkflIP.aspx"
and my worklow worked. I think maybe these elements are needed only for infopath related workflows. My workflow was based on a splist item being created.

# re: Deploying a custom MOSS 2007 workflow 1/24/2007 12:12 AM chris

Hi -

Thanks for the great article. The process goes OK but I get a "Failed on Start (retrying)" in the approval status column. Any idea what might be causing that?

# re: Deploying a custom MOSS 2007 workflow 2/5/2007 11:39 AM tom

KJ and Cynthia, I have found through various trial and error as well as research on the web that in order for the form to be workflow enabled, it has to be installed when the workflow is. To do this, publish the forms to the Visual Studio project base directory (make sure to clear the alternate access path when publishing). Then add a line like the following to the install.bat file: Xcopy /s/Y *.xsn “%programfiles%\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\<Name of Feature>\”

That should resolve the issue.

# re: Deploying a custom MOSS 2007 workflow 2/7/2007 11:44 AM User77

For "The XSN can not be used on server" / "FatalErrorNoThrow" error: It helped to publish the form in the form template library and then "save a copy".

# re: Deploying a custom MOSS 2007 workflow 2/7/2007 6:33 PM alex

Hi chris

I had the same problem when i removed the TaskListContentTypeId, AssociationUrl="_layouts/CstWrkflIP.aspx", InstantiationUrl="_layouts/IniWrkflIP.aspx"
and ModificationUrl="_layouts/ModWrkflIP.aspx" from the feature.xml as gover told.

My real problem is that sharepoint couldn't open the infopath form. Its only says that the form is closed. I just removed the TaskListContentTypeId from the feature.xml.

any solution or idea?

# re: Deploying a custom MOSS 2007 workflow 2/13/2007 5:45 PM Morten

Has anyone managed to replace SharePoint built-in Approval Workflow with a custom approval workflow like the one found in the SharePoint ECM SDK?

I have managed to get the ECM workflow running - but it runs in parallel with standard SharePoint workflow - causing a lot of end-user frustration.

I find it hard to believe that content approval cannot be replaced in SharePoint - but I might be wrong.

# re: Deploying a custom MOSS 2007 workflow 2/14/2007 6:35 AM User77

Problem:
When starting my workflow I did get a "Failed on Start" error.

Solution:
For me the reason was, that the CodeBesideAssembly Version didn't match. After changing from 3.0.0.0 to 1.0.0.0 it worked. More information can be found under http://blogs.msdn.com/sharepoint/archive/2006/11/30/developing-workflows-in-vs-part-6-deploy-and-debug-your-workflow.aspx.

# re: Deploying a custom MOSS 2007 workflow 2/21/2007 11:38 AM MAndrade

I have a simple workflow I've created, and am trying to deploy it to one of our Sharepoint servers, but i get the following error when the feature is either installed or uninstalled:

"Activating and installing the feature...
The farm is unavailable. "

I'm not sure what I'm doing wrong, but any help would save me a great deal of frustration! :) Very good blog by the way.

# re: Deploying a custom MOSS 2007 workflow 2/24/2007 8:44 PM Rich

Mandrade, If you check your event log, you will see that you do not have permissions to the database. An odd thing. You need to have permissions, not sure of the level (I just set myself as the dbo to make life easy)to the content database.
For some reason, this isn't processed through the service, your security context is picked up.

As for Morten's comments, I'm guessing that you would need to remove the default (which without looking, I'm guessing is a feature) then you can add your own workflow as the "approval" workflow.

Nick... Great Job on these articles.

# re: Deploying a custom MOSS 2007 workflow 5/16/2007 5:47 AM Pinster

The article was great. I have one doubt though:-

When the workflow is started, it assigned a task to the specified user. The user will then open the task in the specified infopath form and checked the 'Complete' box to indicate it's done. Everything works fine with the workflow of course, but if the user open up the task again, the infopath form doesn't seems to persists the data because the 'Complete' checkbox is again remain unchecked even though the task/workflow is already completed previously.

Is there any way we can persists the form's data?

# re: Deploying a custom MOSS 2007 workflow 5/21/2007 4:55 PM Bri

Hi Nick. I saw in the above explanations you said you didn't know what the 'TaskListContentTypeId' was. Well when I was researching how to deploy content types across farms, I came across this. Hopefully this is helpful. Thanks for the wonderfully helpful blog!

One important thing to pay attention to here is the ID attribute of the content element. These are not very well documented in the schema. The ID here is a combination of a

value that indicates what other content types it inherits from and a GUID. The “0x0100” portion of the ID tells SharePoint that this content type inherits the item content type. The remainder of the ID is just a standard 32 character GUID with all the dashes “-“ and curly brackets “{}” removed.

Title  
Name  
Url
Comments - All Comments are moderated and will not be displayed until approved by this blog's author    
Enter the code you see: