Workflow Status

Here is my finding for workflow status.

Not Started                       –> 0
Failed on Start                  –>  1
In Progress                       –>  2
Error Occurred                  –>  3
Canceled                           –>  4
Completed                        –>  5
Failed on Start (retrying)   –>  6
Error Occurred (retrying)   –>  7
Canceled                          –> 15
Approved                         –>  16
Rejected                           –> 17

Integrating Workflow Task Review Infopath Page as Content Type

This article is about how to relate workflow Task review InfoPath form with document library item where InfoPath form is deployed as content type.

InfoPath page is deployed in Library using content type thru central administration.Once the task is created
Reviewer might want to see the entire content before Approve/Reject etc…

For this create seprate custom Task Review ASPX page keep it inside Layout folder.

Create Feature.xml , workflow.xml and  workflowTaskContentType.xml
Feature.xml will look like ..

<?xml version=”1.0″ encoding=”utf-8″?>
<Feature  Id=”A558D1D0-BBA9-40ce-AC28-A61F80759A40″
Title=”MKS.APPROVAL”
Description=”MKS APPROVAL SYSTEM workflow works for various approval level.”
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/”&gt;
<ElementManifests>
<ElementManifest Location=”workflow.xml” />
<ElementManifest Location=”workflowTaskContentType.xml” />
</ElementManifests>
</Feature>

Similarly define your content Type xml register all the fields you want like.

<FieldRefs>
<FieldRef ID=”{3bcc76ec-77be-4781-83fa-5af750b773aa}” Name=”UserName” DisplayName=”UserName”/>
<FieldRef ID=”{d59e4bd2-bc55-424a-a617-589e1eee3fef}” Name=”Approved” DisplayName=”Approved”/>
<FieldRef ID=”{57559084-bf2c-4f98-a5d5-4e06ad8b34bf}” Name=”CommentFromApprover” DisplayName=”CommentFromApprover”/>
</FieldRefs>

Workflow.xml will not contain

TaskListContentTypeId=”0x0108010033183235333b49669090b2f2326ad85a”

This is the ID which is added in side workflowTaskContentType.xml

Inside the custom ASPX page add XmlFormView Control and set XmlLocation at runtime
to the library where infopath is enabled and the task is associated.

<cc1:xmlformview id=”XmlFormView1″ runat=”server” height=”250px” oninitialize=”XmlFormView1_Initialize”
onsubmittohost=”XmlFormView1_SubmitToHost” width=”100%”></cc1:xmlformview>

Workflow Task Form Processing for Custom Content Type Forms

When a user clicks the link to edit a task, Windows SharePoint Services must determine the task type content type. If the task was generated by using the CreateTaskWithContentType workflow activity, the content type is specified in that activity. If not, Windows SharePoint Services examines the workflow template definition to determine the task content type.

Windows SharePoint Services then examines the content type definition to determine whether a custom edit form is specified for this content type. If so, Windows SharePoint Services displays the specified form.

The workflow developer is responsible for the data that is passed initially to the task form, and for what actions happen when the user submits the form. For example, the developer could program the form to retrieve the contents of the Xml property of the SPListItem that represents the task, and use that information as a data source. Windows SharePoint Services always passes the task XML to the form as a secondary data source.

Similarly, when the form is submitted, we recommend that the form call the AlterTask method, passing the SPListItem object and the updated data as parameters. Windows SharePoint Services raises an OnTaskChanged event when this method is called. To handle this event, add an OnTaskChanged event activity to the workflow.

Workflow Task Types

To differentiate the task types your workflow creates, you assign each task type an integer identifier within that workflow. The first task type is 0, the second 1, and so on. This enables you to assign different content types, and different forms, to each task type. These task type identifiers must be unique only within a given workflow. For example, any workflow that creates a task has a task 0 task type; however, the task type does not have to be the same across all workflows.

When a user clicks the link to edit a task, Windows SharePoint Services examines the workflow template definition to determine the task content type. It then examines the content type definition to determine whether a custom edit form is specified for this content type. If so, Windows SharePoint Services displays the specified form. If no custom edit form is specified, Windows SharePoint Services displays its default rendering of the edit form.

For more information about content type definition, see Content Type Definition Schema.

Types of Custom Content Type Forms

You can specify two kinds of custom forms for content types:

  • Form templates, which are .asmx controls that render the central section of a SharePoint Web page—everything but the SharePoint frame elements (usually termed the “chrome”) on the page. Windows SharePoint Services renders the chrome for the page.For more information, see FormTemplates Schema Overview.
  • Form pages, which are .aspx pages that replace the entire default SharePoint page, including the SharePoint framing elements—the SharePoint “chrome.” For form pages, you must provide any navigational links or other elements you want that are usually found in the SharePoint chrome.For more information, see FormUrls Schema Overview.

For more information :http://msdn.microsoft.com/en-us/library/ms438856.aspx