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>
    

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.

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".

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.
}

    

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>

    

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."