The first requirement is to allocate this task to all users in the voting panel. To enable this, we've defined the group SuspectItemPanel within our user repository. We don't want to allocate the task to the group, as this would only allow one user from the group to acquire and process the task. Rather we want to allocate it to all members of the group. To do that we can use the Identity Service XPath function ids:getUsersInGroup, as illustrated here:

ids:getUsersInGroup ('SuspectItemPanel', false())

Note the second parameter is a Boolean which, if set to true, will only return direct members of the group. Setting it to false causes it to return all members of the group.

Doing this will effectively create and assign a separate sub-task to every member of the group.

There is an issue with this approach so far, in that the second step will always be executed regardless of what happens in the first step. To prevent this we've specified the following skip rule:

/task:task/task:systemAttributes/task:outcome != 'DEFER'

The skip rule lets you specify an XPath expression which evaluates to a boolean value. If it evaluates to true then the corresponding participant will be skipped in the task.

In our case we are testing the outcome taken by the oBay administrator in the previous step. If they didn't defer it, that is they chose to either accept or reject the item, then this step is skipped.

When panel members are considering their decision they may want to confer with one another. By default anyone assigned a task will be able to see comments and attachments made by participants in previous steps of the task (that is, the oBay administrator), however, they won't be able to see comments made by other panel members.

To enable the sharing of attachments and comments between panel members we've selected the Share comments and attachments checkbox.

The final part of the group vote is to specify what the outcome is in the event that not all members are in agreement. There are two parts to this; the first is to specify what the default outcome is if there isn't agreement, in our case we want to REJECT the item.

The second part is to specify what constitutes agreement, this can either be unanimous, that is, everyone must agree, or the default outcome is selected. Alternatively, you can specify that only a majority need to be in agreement and what the size of that majority should be.

The size of the majority can be a fixed amount (60% as in our case), or can be based on an XPath expression which could calculate this value dynamically at run time.

The final option you have is to specify whether all votes should be counted or if once we have sufficient votes on which to make a decision the outcome should be triggered. In this scenario, any outstanding sub-tasks will be withdrawn.

In our case the panel consists of three members, so as soon as two have approved the task, the required consensus will have been achieved and the third member will have their task withdrawn.

The <types> section of the TaskQueryServiceInterface.wsdl file contains four import statements, the last of which (at the time of writing) contains an error. If we look at the following fragment of XML from this file, we can see that the import statement includes the attribute location.

<import namespace="http://xmlns.oracle.com/bpel/.../taskQueryService"
location="TaskQueryService.xsd"/>

We need to rename this attribute to schemaLocation as shown here:

<import namespace="http://xmlns.oracle.com/bpel/.../taskQueryService"
schemaLocation="TaskQueryService.xsd"/>

The other modification we need to make is to update the location attribute of the soap address for the Task Query Service defined in TaskQueryService.wsdl.

<service name="TaskQueryService">
<port name="TaskQueryServicePort"
binding="tns:TaskQueryServiceSOAPBinding">
 <soap:address location="http://localhost:8888/integration/Task
QueryService"/>

</port>
</service>

We need to modify location to point to the actual endpoint of the Task Query Service, so set the value of location to:

http://<hostname>:<port>/integration/services/TaskQueryService/ TaskQueryService

Here hostname represents the name of the machine on which the SOA Suite is running and port represents the port number.

Once we have copied these files into our project directory and modified them as described above, we are ready to create a partner link.

From this point on, we follow the standard approach for creating a PartnerLink; namely drag a PartnerLink from the Services section in the Component Palette onto your BPEL process. Click on the icon to Browse WSDL Files From Local File System and browse to and select our modified TaskQueryService.wsdl.

When prompted to make a local copy of the WSDL file and create a WSDL file that defines PartnerLink types select Yes in both cases.

When creating the credential element, we need to ensure that it doesn't include an empty onBehalfOfUser element. The service will try to create a workflow context for this empty user, which of course will fail and return an error.

This is an easy error to make, because the first time we use an assign statement to populate any sub-element of credential, for example doing a copy to populate the login element, BPEL PM, by default, will create an initialized credential element containing all its sub-elements including onBehalfOfUser (each with an empty value).

A simple way round this is to assign a fragment of xml, such as the following:

<credential xmlns="http://xmlns.oracle.com/bpel/workflow/common">
<login/>
<password/>
<identityContext>jazn.com</identityContext>
</credential>

Directly to credential, this acts as a template into which we can copy the required values for login and password. We do this using a copy operation within an assign statement, the key difference being that we specify an XML Fragment as the From Type as shown in the following screenshot:

Note, we have specified the default namespace in the credential element so that all elements are created in the appropriate namespace.

The displayColumnList element list contained within the taskPredicateQuery allows us to define which task attributes (or columns) we want returned by our query.

Simply include in here one displayColumn entry per task attributes we want returned, valid values include TaskNumber, Title, Priority, Creator, CreatedDate and State.

If we look at the WSDL definition for the getSoldItems operation we can see that it returns the values orderNo, itemId, orderDesc, buyerId, itemPrice, totalPrice, saleDate, orderStatus, lastUpdateDate, and nextAction.

At first glance only a couple of these match to actual task attributes; when we created the task we set the task title to hold orderDesc and the task attribute updatedDate maps to lastUpdateDate.

In addition, we have decided to use taskNumber for the orderNo as this makes it a lot simpler to tie the two together.

However, the remaining fields are all held in the task payload which we can't access through the queryTask operation. One solution would be to call the getTaskDetails operation for every row returned, but this would hardly be efficient. Fortunately we have an alternative approach and that is to use Flex Fields.

The next step is to specify the query predicate so that it only returns those tasks that we are interested in. We will first look at the query we need to construct to return all sold items for a particular seller.

The following diagram shows the structure of the query predicate. The assignmentFilter allows us to specify a filter based on who the task is currently assigned to. Valid values are All, My, Group, My+Group, Reportees, Creator, Owner, Previous, or Admin.

For our purpose we need to list all tasks related to items sold by the specified seller; so we will need to include those items which have tasks currently assigned to the buyer.

You may recall that when we defined our workflow we assigned the initiator (or creator) of the task to be the seller, so we can use Creator as the assignmentFilter.

So far our query will return all tasks created by the specified user, which could potentially include tasks created in other workflows, so we need to add an additional filter to further restrict our query.

One approach would be to use the keywords filter. This is an optional search string, which, if specified, will only return tasks where the string is contained in the task title, task identification key, or one of the task text Flex fields. However, this probably won't result in the most efficient query, so we should use an alternative if available.

For this we need to use the clause element (shown in the figure above). This allows us to specify one of more clauses against any of the task attributes.

One such attribute is the TaskDefinitionName, which contains the name that we assigned to our task when we defined it in JDeveloper (that is, OrderFulfillment). Adding a clause to filter on this would give us the following predicate:

<predicate xmlns="http://xmlns.oracle.com/bpel/workflow/taskQuery">
<assignmentFilter> Creator</assignmentFilter>
<clause joinOperator="AND">
<column> TaskDefinitionName</column>
<operator> EQ</operator>
<value> OrderFulfillment</value>
</clause>
</predicate>

Specifying the query predicate for the buyer isn't quite so simple as we want to list all tasks related to items bought by the specified buyer, so we will need to include those items which have tasks currently assigned to various sellers.

Unlike the seller's query, we can't use the Creator value as our assignment filter, and we can't use My either as this only return tasks currently assigned to us. Hence, the only option we have is to use All as our assignment filter. However, this will return all tasks currently in the system, so we need to find a way of restricting the list to just those tasks required by the buyer.

As you may recall we have already defined the Flex field textAttribute1 to hold the buyerId, so we just need to add an extra clause to our predicate to test for this condition. This will give us a predicate that looks as follows:

<predicate xmlns="http://xmlns.oracle.com/bpel/workflow/taskQuery">
<assignmentFilter> All</assignmentFilter>
<clause joinOperator="AND">
<column> TextAttribute1</column>
<operator> EQ</operator>
<value> $buyerId</value>
</clause>
<clause joinOperator="AND">
<column> TaskDefinitionName</column>
<operator> EQ</operator>
<value> OrderFulfillment</value>
</clause>
</predicate>

where $buyerId needs to be substituted with the actual userId of the buyer.

The ordering element list contained within the taskPredicateQuery allows us to define which task attributes we want to order our result set by. For our purpose we want to order by sale date, which is held in dateAttribute1; this gives us an ordering element which looks as follows:

<ordering xmlns="xmlns.oracle.com/bpel/workflow/taskQuery">
<clause>
<column> DateAttribute1</column>
<sortOrder> ASCENDING</sortOrder>
</clause>
</ordering>

The only area of complexity is updating the order directly within the task payload. This is for the same reason we mentioned earlier when implementing the getOrderDetails operation; as the payload is defined as xsd:any, we can't use the XPath mapping tool to visually map the updates.

The simplest way to work around this is to first extract the order from the task payload into a local variable (which we do in exactly the same way that we did for our getOrderDetails operation).

Once we've done this we can update the shipTo element of the order to hold the shipping details as well as update its status to Awaiting Shipping Costs to reflect the next step in the workflow.

Once we have updated the order, we must insert it into the task payload; this is essentially the reverse of the copy operation we used to extract it.

Once we have updated the task payload we then need to update the corresponding Flex fields so that they remain synchronized with the order. We do this using an assign activity in a similar way that we used to set the Flex fields when creating the task in our OrderFulfillment process.

Finally, we need to set the task outcome for the current step (this is effectively the same as specifying a task action through the worklist application). In our case we have defined two potential outcomes: COMPLETED or ABORTED.

For setShippingDetails (as with all of our operations), we want to set the task outcome to COMPLETED. Note that this won't actually complete the task, rather it completes the current assignment, and in our case since all our routing policies are single approver, it will complete the current step in the workflow and move the task on to the next step. Only once the final step is completed will the task complete and control be returned to the OrderFulfillment BPEL process.

To set the task outcome, we only need to set the outcome element (located in the task systemAttributes element) to COMPLETED. However, it isn't quite that straightforward; if you look at the actual task data returned by the getTaskDetailsByNumber operation, the outcome element isn't present.

Thus, if we use a standard copy operation to try to assign a value to this element we will get an XPath exception.

Instead what we need to do is create the outcome element and its associated value and append it to the systemAttributes element. To do this within the assign activity, use an Append Operation as shown in the following diagram:

The simplest way to create the outcome element is to use an XML Fragment and append it to the systemAttributes element as shown in the following screenshot:

Once we've done this we will have a completed task, so that all that remains to do is call updateTask to complete the operation.