Show All

# About Human Workflow Services support

Human Workflow Services (HWS) is a service provided by Microsoft BizTalk Server 2004 that enables client applications to build and manage human-oriented workflow. Microsoft Office InfoPath 2003 provides access to this service by way of the Workflow task pane. In this task pane, users can start and track HWS actions and respond to HWS tasks. InfoPath does not provide a designer interface to enable the Workflow task pane; all HWS functionality is enabled by modifying the form definition file (.xsf).

## Using the Workflow Task Pane

The Workflow task pane allows the user to start or extend a workflow or respond to a task.

The three sections of the Workflow task pane are:

- Start Workflow Consists of the action buttons that can be used to start a workflow. This section is only visible for forms that are HWS enabled and that do not have an existing workflow associated with them.
- Action Tracks the status of actions and their associated tasks. Once a user starts an action, the action runs and is tracked by the HWS service. InfoPath displays the status of the action and who is assigned the task.
- Task Allows the user to work with tasks. When a task is assigned to a user, InfoPath displays the status of the task, a button to respond directly to the task, and one or more buttons to start new actions.

Enabling the Workflow task pane

To enable the Workflow task pane, modify the form definition file (.xsf) to include the hwsWorkflow element, as follows:

    <hwsWorkflow taskpaneVisible=”yes”>
     <location url="http://test/hwsservice/hwsservice.asmx"/>
     <allowedActions>
      <action name=”approval” actionTypeID=”{guid}” canInitiateWorkflow=”yes” caption=”Get Approval”/>
      <action name=”delegate” actionTypeID=”{guid}” canInitiateWorkflow=”no” caption=”Delegate”/>
     </allowedActions>
     <allowedTasks>
      <task name="getManagerApproval" taskTypeID="435" caption="Send Response"/>
      <task name="getVPApproval" taskTypeID="436" caption ="Send Response"/>
      <task name="delegateToManager" taskTypeID="420" caption="Respond"/>
     </allowedTasks>
    </hwsWorkflow>

Adding allowed actions to forms

An HWS service may provide many different actions, but the form may not require every action provided by the service. Each action must be separately enabled for the form; thus, the form can include a subset of the actions deployed on the HWS service.

Available actions are represented in the Workflow task pane as buttons, depending on the state of the document within the workflow and the user’s permissions as defined in the HWS constraint system. In the form definition file (.xsf), list the enabled actions, identified by their actionTypeID attributes. If the action can initiate a workflow, the canInitiateWorkflow attribute should be set to "yes". Use the caption attribute to provide a display name for the button label of the action.

Note InfoPath allows users to start only one new action based on the current state. The Workflow task pane does not allow users to start multiple actions from a given state because of the way InfoPath tracks the history of an instance of a document. InfoPath associates each instance of a document to a workflow by one taskTypeID or one actionTypeID. The workflow is considered complete when the activity flow reaches the inactive state.

Adding allowed tasks to forms

Tasks are mini-actions that define the work that needs to be completed by a user. A task is assigned to a user by the HWS service on the basis of the logic set in the action and the task parameters. An action can be designed to assign multiple tasks, serially or in parallel. In most cases, the action expects a task response from a user in order to continue the workflow. If the InfoPath form is associated with a task, the Workflow task pane exposes the task assigned to the user in the form of a button. However, if the task status is set to Deferred, Declined, or Cancelled, the task buttons will not appear, even if the activity flow is active. Like actions, each task must be enabled for the form. The taskTypeID attribute identifies the namespace of the task and is unique for each task. The caption attribute is used to provide a display name for the button label of the task.

Note Because the Workflow task pane does not allow you to add more properties and customize controls, use a custom task pane to display more information about the workflow. To use the hwsAdapter element without showing the Workflow task pane provided by InfoPath, set the taskpaneVisible attribute to "no".

Using the OnClick event to add action and task buttons

The Workflow task pane displays actions and tasks in the form of buttons. Button functionality must be defined in the form code by adding an OnClick event for every enabled action and task. Use code to, for example, switch views, switch task panes, or submit directly to the HWS Web service. Use the name of the action or task as defined in the hwsWorkflow element of the form definition file (.xsf), as shown in the following example:

    function approval::OnClick(eventObj)
    {
     // Switch view that contains Action/Task parameters with submit button.
    }

## Creating an HWS Adapter

Because the Workflow task pane does not submit data to the HWS service automatically, you must create an HWS adapter to submit the form.

There is no designer interface associated to the submit adapters. To enable these adapters, modify the form definition file (.xsf) to include the hwsAdapter element within the dataAdapters element.

Like other InfoPath Web service adapters, the element must include a name for the adapter and the location of the Web Services Description Language (WSDL), and must specify whether the adapter allows submitting and querying. Because these adapters are only used to submit data to an HWS service, the submitAllowed attribute must be set to "yes". The queryAllowed attribute can be omitted, which corresponds to a default value of "no", or it can be included and set to "no".

As part of the design of actions and tasks, you can specify additional parameters that are specific to each action or task. Below is an example of an adapter that starts a workflow with an Approval action. The value to use for the hwsOperation element type is "addActionToNewActivityFlow". The typeID attribute uses the actionTypeID attribute value, which is a GUID.

    <xsf:hwsAdapter name="Start Approval" wsdlUrl="http://.../HWSService.asmx?WSDL" submitAllowed="yes" queryAllowed="no">
     <xsf:hwsOperation type="addActionToNewActivityFlow" typeID=”{guid}” serviceUrl="http://.../HWSService.asmx">
      <xsf:input source="HWSMessage1.xml">
        <xsf:partFragment match="/ns1:HWSMessage/ActionSection/param1" replaceWith="/my:myFields/my:param1" />
        <xsf:partFragment match="/ns1:HWSMessage/ActionSection/param2" replaceWith="/a:foo/b:bar" dataObject=”Aux1” />
      </xsf:input>
     </xsf:hwsOperation>
    </xsf:hwsAdapter>

The hwsAdapter element has the same default interface as the other submit adapters supported by InfoPath, but the HWS submit adapters do not appear in the interface. Instead, to invoke a submit action, you must add it to your code, as shown in the following example:

    XDocument.DataAdapters.Item("Start Approval").Submit();

At runtime, when the submit operation is invoked, a button with the caption, Get Status, appears on the Workflow task pane. This button allows the user to refresh the task pane so that it shows the current workflow information.

Defining HWS submit operations for actions

InfoPath provides three types of submit operations that interact with the HWS service:

- addActionToNewActivityFlow
- addActionToActivityFlow
- sendTaskResponse

To use the HWS submit adapter, XML instances must be defined for each action. The XML instances are defined by using the BizTalk editor to export the Activation XML instance of each action. The XML instance should be named and added as an InfoPath resource in the form definition file (.xsf). For the HWS submit adapters to know which XML instance to use, the input element must be updated with the name of the XML file to use, as shown in the previous example of an adapter. This update is only required for hwsOperation, addActionToNewActivityFlow, and addActionToActivityFlow elements. Task responses, defined by the sendTaskResponse value for the type attribute, do not need an XML instance, because by querying the server with the GetTaskInfo receive operation, the HWS service returns the XML instance used to respond to the task. For tasks, the source attribute for the input element must be blank.

Each action conforms to a BizTalk Action Message schema, as shown in the following example. This schema is used to communicate with the HWS service. The action can include additional parameters that are specific to the action; for example, a priority and a due date. These parameters are stored within the ActionSection element of the Action Message schema, as follows:

    <ns0:HwsMessage xmlns:ns0="http://tempuri.org/Hws_Activate_SampleDoSomething">
      <HwsSection HwsMessageType="Hws_Activate">
        <ActivityFlowID>00000000-0000-0000-0000-000000000000</ActivityFlowID>
        <InitiatingActor>Contoso\johndoe</InitiatingActor>
        <ActionTypeID>00000000-0000-0000-0000-000000000000</ActionTypeID>
        <ActionInstanceID>00000000-0000-0000-0000-000000000000</ActionInstanceID>
        <ActionInstanceDescription>D</ActionInstanceDescription>
        <ParentActionInstanceID>00000000-0000-0000-0000-000000000000</ParentActionInstanceID>
        <ParentTaskID>00000000-0000-0000-0000-000000000000</ParentTaskID>
        <ActivityModelTypeID>00000000-0000-0000-0000-000000000000</ActivityModelTypeID>
        <ActivityModelInstanceID>00000000-0000-0000-0000-000000000000</ActivityModelInstanceID>
        <ActivityModelStepID>10</ActivityModelStepID>
        <IsDependentOnParent>false</IsDependentOnParent>
        <ActivityFlowProperties>
          <Property Name="Name_0" Description="Description_1" Type="Type_2">Property_0</Property>
          <Property Name="Name_0" Description="Description_1" Type="Type_2">Property_1</Property>
          <Property Name="Name_0" Description="Description_1" Type="Type_2">Property_2</Property>
        </ActivityFlowProperties>
        <ActionProperties>
          <Property Name="Name_0" Description="Description_1" Type="Type_2">Property_0</Property>
          <Property Name="Name_0" Description="Description_1" Type="Type_2">Property_1</Property>
          <Property Name="Name_0" Description="Description_1" Type="Type_2">Property_2</Property>
        </ActionProperties>
        <HwsWebServiceUrl>http://localhost/HwsService/HwsService.asmx</HwsWebServiceUrl>
      </HwsSection>
      <ActionSection>
       <priority>1</priority>
       <dueDate>02/19/04</dueDate>
      </ActionSection>
      <Payloads>
       <Payload ID="ID_0"></Payload>
      </Payloads>
    </ns0:HwsMessage>

Defining HWS receive operations

InfoPath makes calls to the HWS service to retrieve the current workflow information and populate the Workflow task pane. For every Web service call that InfoPath makes, a secondary data source should be specified to temporarily store the retrieved data.

The HWS Service provides four web methods that InfoPath receive operations can interact with:

- GetTaskInfo
- GetActionInstance
- GetActivityList
- GetActivityFlowInfo

Note Use the default name, as shown in the list, for any of the secondary data connections. The initOnLoad attribute should always be set to "no."

####

©2003-2004 Microsoft Corporation. All rights reserved. Permission to copy, display and distribute this document is available at: http://msdn.microsoft.com/library/en-us/odcXMLRef/html/odcXMLRefLegalNotice.asp