WID

WID
Human Task, Decision Table, Business Rules
Human tasks
A human task is, quite simply, a unit of work that involves a human. Quite often, this task requires that the human
interact with other services, and thus becomes a task within a larger business goal.
The WebSphere® Integration Developer tools have been designed so that users can easily compose integrative
business solutions without programming skills. To this end, you can easily define a human task in an intuitive
graphical programming environment called the human task editor.
Before you start to use the human task editor, you need to understand these key concepts about human tasks:
• An example of a human task
• Presenting a task to a staff member
• Escalations
• Collaborating with other staff members in a human task
Note: Human tasks can only be deployed to the WebSphere Process Server.
An example of a human task
Let us begin with an example of a human task. This graphic illustrates the steps involved when a staff member
accepts a task.
In this example, this particular task is likely part of a much larger process which stops and waits until the staff
member makes a decision.
Here are some terms that you will need to understand to use the editor:
Task Definition
A Task Definition is a representation of the task that includes the following:
• who can do the task (roles/people assignment criteria)
• what needs to be done (name)
• what happens when the task takes too long (escalation)
• how the task will be done (input and output data)
In the runtime environment, a task definition starts as a single work item. Over time, the task definition
may generate multiple work items.
To-do items
A to-do item is a work item that is presented to the user in the user interface. A staff member (employee)
can browse all the to-do items that they have the authority to claim, and then claim it.
Roles
A role is a group of employees who share the same level of authority and access rights. When a task is
assigned to a role, any staff member in that role group can complete the task.
People assignment criteria
This criteria define the members of each of the role groups.
Presenting a task to a staff member
When a human task is started, the staff member interacts with the task through a user interface in a
client environment.
If you take a look at the example again, you will see that you have already been exposed to a client, it
just was not spelled out that way. Take a look at the example again with a few minor changes.
In this modified example, we see that all interaction between the user and the task is facilitated by a
client. The task is delivered to the user through the client, and the resolution is returned in similar
means.
So far, both examples have shown what happens when the task can be completed without a problem.
What happens when that is not possible?
Escalations
An escalation is a course of action that is begun when an expected result from a task has not been
achieved within a set period of time. For instance, let us look at the same scenario again, and see
what happens when it isn't properly completed.
In this example, we see that the staff member who claims the task isn't able to complete it in the
specified period of time, and another staff member is alerted. Presumably, this second employee has
the authority to investigate the reasons behind why the task wasn't completed and proceed
accordingly.
There are three possible states for which an escalation can be configured:
Ready
When a human task is in a ready state, it is waiting to be claimed. You can configure an escalation to
trigger if it sits unclaimed for too long.
Claimed
If a staff member has claimed a task, but takes longer than the specified period of time to complete it, an
escalation is triggered and another staff member is notified.
Subtask started
A subtask is an additional unit of work that is split out from a parent task. If the subtask fails to complete
within a specified period of time, the parent task is escalated and indicates that it is still waiting on the
subtask.
Collaborating with other staff members in a human task
Ad-hoc tasks and transferred work items are created "on-the-fly" in the runtime environment,
usually because the situation that has created the need for the task did not exist when it was
initially developed. You can create such tasks either from existing task definitions
(collaboration and invocation tasks) or without any existing definition. You can use
WebSphere Integration Developer to allow for the creation of two types of ad-hoc tasks: the
subtask, the follow-on task, as well as the transferred work item.
Subtasks
In the runtime environment, if a person who claims a task finds that they are not able to complete it by
themselves, they can delegate portions of that original task to other people in the form of subtasks.
Follow-on tasks
In the runtime environment, if a person who claims a task finds that they are not able to complete it, they
can assign the remaining work to somebody else in the form of a follow-on task.
Transferred work items
can transfer the work item to another person or group.
Types of human task
There are four types of human tasks that you can define.
To-do task
This is where a service component (such as a business process) assigns a task to a human as
something for that person to do.
A to-do task can be implemented either stand-alone or inline.
To see an example of a to-do task that you can build and run yourself, go to
http://publib.boulder.ibm.com/bpcsamp/index.html, and click Human Task features > To-do ttask.
Note: You will need a connection to the internet to view this example.
Invocation task
This is where a human can "assign" a task to a service component. In such a case, a human is invoking
an automated service such as a business process.
An invocation task can be implemented either stand-alone or inline. When it is inline, an invocation task
allows humans to invoke the operations that a business process exposes through activities such as
receive, pick or event handlers. Through this, a user can start a process and define authorization for its
inbound activities.
To see an example of an invocation task that you can build and run yourself, go to
http://publib.boulder.ibm.com/bpcsamp/index.html, and click Human Task features > Invocation task.
Collaboration task
This is where a human assigns a task to another human.
A collaboration task is stand-alone, in that there is no interaction between it and any other component. It
is self-contained and implements a stand-alone human interaction without any reference or interface to
another service.
To see an example of a collaboration task that you can build and run yourself, go to
http://publib.boulder.ibm.com/bpcsamp/index.html, and click Human Task features > Collaboration
task.
Administration task
This type of task grants a human administrative powers such as the ability to suspend, terminate, restart,
force-retry, or force-complete a business process. Administration tasks can be set up on either an invoke
activity, or the process as a whole.
This type of task is only available within a business process (inline task).
Inline and stand-alone human tasks
You can implement a human task as part of the logic of a business process, or independently of other processes.
If the task is implemented within a business process, it is called an inline task. Otherwise, it is referred to as a
stand-alone task.
Inline task
An inline task is defined within an implementation of a business process. It can either be implemented directly in
the process using a human task activity, or as a property of an invoke, pick, receive, event handler, or on
message activity.
When you are first planning your human task, you should model it as an inline task if any of the following
conditions are present:
• You need information from the process logic to run human interaction. Although information from the
process can also be modeled into the input for a human task, the main reason to use an inline human
tasks is because they have direct access to the process context without the need to explicitly model the
required information into the input message.
• You want to define authorization rights on specific activities
The standard method of creating an inline task is to drop a human task activity on to the canvas in the business
process editor.
Stand-alone task
A stand-alone task exists independently of a business process, and implements human interaction as a service
that can be wired to any other component of the WebSphere® Integration Developer family of tools.
When you are first planning your human task, you should model it as a stand-alone task if any of the following
conditions are present:
• The task provides just another service
• You intend to replace the stand-alone task later on and don't want to change the component to which it is
wired.
Create a stand-alone task using the New human task wizard and then wiring the task to a business process using
the assembly editor.
Changing a stand-alone task to an inline task

If you would like to take an existing stand-alone task that is invoked by an invoke activity in a business process,
and transform it into an inline task that is implemented by a human task activity, proceed as follows:
1. In the assembly editor, delete the existing interface between the human task component and the
business process.
2. Delete the component as well.
3. In the business process component, right-click the invoke activity that originally connected to the human
task component, and select Change type > Human task.
4. In the Details tab of the human task, select New.
5. Select the interface that was used between the original business process component and the human
task component.
6. Define the settings for the human task.
7. From the main menu, click Project > Clean.
Human task clients
A human task client is a piece of software which provides an interactive link between a human task and the staff
member assigned to work upon the task.
A human task client delivers task-related information to a staff member in the form of an interactive application.
There are various types of client that you can generate for your human task:
• IBM® Lotus® Form
• Business Space powered by WebSphere®
• Business Process Choreographer
• WebSphere Portal portlet
• JavaServer Faces (JSF) client
Clients can be defined for both inline and stand-alone human tasks. You can create one client for all the human
tasks in a module, or you can create a separate client for each task. You can even provide multiple clients for the
same task, if you wish users in different roles to see different options for the task.
Clients are used to customize user interfaces for your human task. Two different clients may provide very similar
user interfaces to the staff member, and the staff member does not need knowledge of what client is being
employed in order to interact with the human task.
Note: Human task clients and user interfaces are not synonymous, although they are closely related
Human task user interfaces
The user interface of a human task is the means by which a staff member interacts with a human task in the
runtime environment.
A human task user interface is the interactive application that the staff member sees when they are working on a
task. The user interface is part of the human task client. You must generate a client before you can define a user
interface. You can generate a client manually, or using the client generator in the human task editor.
The user interface can be customized to your specific needs.

Note: Human task user interfaces and human task clients are not synonymous, although they are closely related.
Life cycle of a human task
A human task goes through a number of stages from its start to its finish.
Information on this topic can be found by following this link: Life cycle of human tasks or Life cycle of human
tasks if you have WebSphere Process Server installed.
Note: If this link fails, you need to install additional documentation. In WebSphere Integration Developer, open
the Resource perspective if you are not already there (click Window > Open Perspective > Other > Resource).
Then, in the main menu, click Help > Software Updates. In the Software Updates and Add-ons window, select
the Available Software tab. Click Add Site and specify the following location:
http://publib.boulder.ibm.com/dmndhelp/downloads/v6r2mx/wid/. Expand the results under this
repository location, select the documentation that you want, and click Install. You will need to restart WebSphere
Integration Developer to see the additional documentation.
Setting human task preferences
You can use the Preferences window to modify the Human Task editor settings for the choice of people directory
and assignment criteria.
To modify the Human Task editor preferences settings, follow these instructions:
1. From the main menu, select Window > Preferences to open the Preferences window.
2. Expand Business Integration and expand Human Task Editor.
Note: If you do not see the Human Task Editor in the Business Integration preferences, then expand
Workbench to select Capabilities, select Integration Developer and click Apply to enable the
business integration tools. Click OK to close the Preferences page. Go back to the first step to open
Preferences again, and you will see Business Integration.
3. Click People Directory to see the people directory settings that you can modify. You can select a people
directory to be the default for new human tasks. You can also add a new entry, edit or delete an existing
entry.
4. Optional: Add a new people directory.
a. Click Add. The Add people directory dialog opens.
b. Enter a name for the new People directory. Provide a meaningful name since this entry will be
used in other dialogs to refer to this people directory.
c. Enter the corresponding JNDI name for the people directory. This entry creates an association
between the JNDI name and the name that you provided in the People directory field. At run
time, the JNDI name is used to identify which staff resolution code to employ.
d. Select the set of people assignment criteria that are associated with this people directory.
Select the people assignment criteria for the new people directory. For each choice there is a
set of predefined criteria. When you are specifying people to work on a task the assignment
criteria that you are presented with are determined by this selection. For instance, if you select
LDAP as the people directory for your human task then when you come to assign people to that
task you will be presented with the LDAP-specific assignment criteria.
You can choose your own people assignment criteria (XML file) by selecting the final radio
button and using the Browse button.
5. Optional: Edit an existing people directory.
a. Click Edit. The Edit people directory dialog opens.
b. Optional: Modify the name of the People directory. Provide a meaningful name since this entry
will be used in other dialogs to refer to this people directory.
c. Optional: Modify the corresponding JNDI name for the people directory. This entry creates an
association between the JNDI name and the name that you provided in the People directory
field. At run time, the JNDI name is used to identify which staff resolution code to employ.
6. Click Apply when you are finished.
7. Click OK to save your preferences
Setting human task preferences

You can use the Preferences window to modify the Human Task editor settings for the choice of people directory
and assignment criteria.
To modify the Human Task editor preferences settings, follow these instructions:
1. From the main menu, select Window > Preferences to open the Preferences window.
2. Expand Business Integration and expand Human Task Editor.
Note: If you do not see the Human Task Editor in the Business Integration preferences, then expand
Workbench to select Capabilities, select Integration Developer and click Apply to enable the
business integration tools. Click OK to close the Preferences page. Go back to the first step to open
Preferences again, and you will see Business Integration.
3. Click People Directory to see the people directory settings that you can modify. You can select a people
directory to be the default for new human tasks. You can also add a new entry, edit or delete an existing
entry.
4. Optional: Add a new people directory.
a. Click Add. The Add people directory dialog opens.
b. Enter a name for the new People directory. Provide a meaningful name since this entry will be
used in other dialogs to refer to this people directory.
c. Enter the corresponding JNDI name for the people directory. This entry creates an association
between the JNDI name and the name that you provided in the People directory field. At run
time, the JNDI name is used to identify which staff resolution code to employ.
5. Optional: Edit an existing people directory.
a. Click Edit. The Edit people directory dialog opens.
b. Optional: Modify the name of the People directory. Provide a meaningful name since this entry
will be used in other dialogs to refer to this people directory.
c. Optional: Modify the corresponding JNDI name for the people directory. This entry creates an
association between the JNDI name and the name that you provided in the People directory
field. At run time, the JNDI name is used to identify which staff resolution code to employ.
6. Click Apply when you are finished.
7. Click OK to save your preferences
Human Task editor

The human task editor is a graphical programming environment that you use to configure the interaction between
a service and its associated human participants, or between two humans.
The Human Task editor is divided into several distinct areas, each with its own individual use. Each is described
below.
The areas are as follows:
1. The service interface area
o This area shows the interface that is associated with this human task.
o You cannot modify the fields in this area, but if you click the name of the interface, you can
launch the interface editor and make the necessary changes.
o
2. The people assignment area
o This area shows details about the assignments of people who initiate or receive tasks. The
display that you see will depend on what type of human task you are working with.
o The table shows a list of roles that users can assume when working with the task. When you
click the icon, you will see a list of the people assignments that you can add to this task. Click
the icon to remove the authorization role that is currently selected.
o
3. The user interface area
o Use this area to add additional, client type specific information to a human task that a client can
interact with in the runtime environment. Click to add a new interface to the palette and then
configure it in the Details area.
o
4. The escalations area
o The escalation settings define how a task should be handled when an expected result has not
been achieved within a set period of time.
o
5. The properties view
o This area displays properties that are relevant to the object that is currently selected in the
editor. Click on the tabs to the left of this view to toggle through the pages. Some pages display
properties in tabular format, and you can add or modify these properties by clicking the
appropriate cell and then interacting with the graphical interface that appears. Properties
marked with an * are mandatory.
o The contents of the page will differ on the object chosen. In all cases, you can press F1 (or
Ctrl+F1 on a Linux® system) to launch a help window and click the link to be taken directly to
the product documentation for more details.
• Assign people tab: Human Task editor

This topic includes a description of each of the fields on the Assign people tab of the Properties view.
• Description tab: Human Task editor

This topic includes a description of each of the fields on the Description tab of the Properties view.
• Details tab: Human Task editor

This topic includes a description of each of the fields on the Details tab of the Properties view.
• Duration tab: Human Task editor

This topic includes a description of each of the fields on the Duration tab of the Properties view.
• Environment tab: Human Task editor

This topic includes a description of each of the fields on the Environment tab of the Properties view.
• Interface tab: Human Task editor

This topic includes a description of each of the fields on the Interface tab of the Properties view.
• User interface settings tab: Human Task editor

This topic includes a description of each of the fields on the User interface tab of the Properties view.
Assign people tab: Human Task editor

This topic includes a description of each of the fields on the Assign people tab of the Properties view.
Choose the criteria for a query from the list. This selection determines the group of people who share the
same permissions and can, for example, claim the task.
The people assignment criteria that you see depends on the choice of people directory that you made on
the human task preferences page. You can choose from a list of pre-defined people assignment criteria
definitions or you can define your own. See related topics for more information.
Test
Click Test to confirm that the people assignment criteria that you use in your human tasks will return the
correct people by the people directory that you are using. This button is available for all people
assignment criteria except Everybody and Nobody, when all mandatory fields have a value, and
requires at least one running Process Server to be defined in Servers view.
If only one person qualifies, claim task automatically
This check box is only available when the Potential Owners authorization role has been selected.
Enable it in cases when your people assignment query returns a single person, and you want this
specific user to be automatically assigned the task in question. When the check box is clear, the user will
have the option of claiming the task.
Parameter table
Use this table to specify details like a group name and thus define the people that will be assigned by the
selected criterion at runtime. The value of the parameter can be changed by clicking into the value field
and editing it, the Names are all predefined, and those that are mandatory will be marked with a "*". You
can use content assist for some of the values if you see the icon of a light bulb appear when you click
the field. Press Ctrl+Space to launch content assist.
You can also specify replacement variables, and use parts of the task input or output message as values
for the parameters. See related topics for more information on replacement variables.
Description tab: Human Task editor

This topic includes a description of each of the fields on the Description tab of the Properties view.
Name
This is the name for the task template as it is known in the runtime environment. Unlike the display
name, it must not contain spaces or invalid characters. If you want to make changes to this value use the
refactoring tool, see related tasks for more information.
Display name
Use this field to define a name for a newly-created task. This name will be displayed to the user in the
runtime environment through a user interface, and can be as descriptive as necessary to ensure that
there is no confusion on the part of the user. It can also be translated into other languages.
Namespace
Use this field to specify the namespace for this human task. A namespace is a way to further differentiate
two files that may share the same name. If you want to make changes to this value, use the refactoring
tool, see related tasks for more information.
Folder
This field shows the name of the folder in which this task resides. Use refactoring to move the task to a
different folder.
Description
Use this field to provide a relatively short explanation of what the task does.
Insert Variable
Click this to see a list of predefined replacement variables that can be used in this field. When you
choose a variable from the list, it will appear as a replacement variable in this field (for example:
'%htm:task.readers%'). During runtime, it will be resolved by the WebSphere Process Server and
the actual value of the variable will be inserted with the placeholder.
Documentation
Use this field to expand upon the description, or display additional supporting material for the task.
Details tab: Human Task editor

This topic includes a description of each of the fields on the Details tab of the Properties view.
• Task level
• Escalations
• Business Process Choreographer Explorer
• Portal client
In all cases, mandatory fields are marked with a "*".
Task level
People directory
Use this field to specify the people directory to be used by the people resolution for this task.
Task priority
Use this field to specify the level of importance of this task. You may use any positive integer between 0
and 2147483647, with lower numbers having a higher priority.
In cases where the increase task priority attribute is enabled on an escalation (see the Details tab for
Escalations below), the priority value will decrease by a value of one with each escalation until 0 (the
highest possible priority) is reached.
Business category
Use this field to enter a name that can be used to group tasks that share similar characteristics in order
to facilitate sorting.
Default language
This field shows the language (based on the geographical location associated with that language) that
will be used in the client. This language will be used if a language-sensitive element of the task (for
example: display name, description, and documentation) is not available in the language requested by
the user client software.
Event handler name
This setting is used in conjunction with the event escalation notification type, or when using API event
handler. Use this field to specify the name of your event handler as installed in the runtime environment.
The runtime system will then send the event to that event handler where you can further process it
according to your needs.
Substitution policy
Use this field to specify what should happen should the task's preferred potential owners be unavailable.
You can use the setting to decide whether the task can be assigned to another user, and how this should
take place.
• No substitution
• This is the default setting for the substitution policy. Use it when you want the task
assigned to a specific owner, even when that owner is absent.
• Replace absent users with their substitutes
• Use this setting to assign the task to an alternate owner when the preferred owner is
away.
• Prefer present users
• Use this setting to make sure that the task can only be assigned to a user who is active.
Date (UTC) when task becomes valid
Use these fields to specify the exact date and time that you would like this task to start. Before this date
and time, the runtime engine cannot create instances of this task. Calendar values are represented in
Coordinated Universal Time (UTC).
Business-relevant
Select this check box if you would like to monitor this task in a runtime environment, and have an audit
trail generated.
Enable subtask creation
Select the Enable subtask creation check box when you want to allow the person who claims the task
to be able break the task up into pieces and delegate portions of that original task to other people in the
form of subtasks.
Task can be claimed when it is suspended
Select this check box if you want a potential owner to be able to accept the task even when the task itself
has been postponed.
Transfer task
Select the Transfer task check box if you want to give users the ability to transfer work items of this task
to other people, or to create or delete work items at runtime.
Enable follow-on task creation
Select this check box when you want to allow a user who is unable to complete a claimed task to assign
the remaining work to another person.
Bind the life cycle to the invoking business process
This field controls the autonomy of the invoked human task. Select this check box to make the human
task a child of the business process that invoked the task. In this case, the task is tied to the life cycle of
the invoking business process (the parent). Clear the check box to make the task a peer of its invoking
business process.
Give owner read access to surrounding process context data
Select this check box to allow the inline to-do task owner to view surrounding business process
information such as input messages, custom properties, or variables. By default this information is only
disclosed to process administrators and readers. This setting is only valid for inline to-do tasks.
Escalations
Expected task state

Use this field to specify the state in which the task should be when the escalation times out. If the task is
not in the state specified, then an escalation is thrown.
You will have the three following options:
• Ended
• Choose this as the expected end state when you want an escalation thrown if the task
is not complete by the end of the escalation period.
• Claimed
• Choose this when you want an escalation raised if, at the end of the escalation period,
the task has not yet been claimed by a user.
• All subtasks ended
• Choose this as the expected end state when you want an escalation thrown if the
subtasks associated with this task have not been completed by the end of the escalation period.
Escalate after
Use these fields to specify the period of time that will elapse before this task is escalated.
You can enter the values using the spin boxes provided, or click the secondary radio button and enter a
value that makes sense to the type of calendar (simple, WebSphere® CRON, user-defined) that is
specified in the task's Duration properties page.
Notification type
Use this list to tell the system how to deal with this escalation.
You have three options:
• Work item
• Choose Work item to inform the person of a task by delivering it directly to a
designated person's "to do" list.
• E-mail
• Choose E-mail to have an e-mail message that announces the escalation delivered to
a staff member. Once you select this option, a separate field becomes active from which you
can choose an appropriate e-mail message. Note that an escalation receiver work item will also
be created.
• Event
• Choose Event if you want to trigger an event handler in the runtime environment. If you
select this option, you then have to specify the event handler in the Event handler name field in
the task's Details properties page. Note that an escalation receiver work item will also be
created.
E-mail message
Use this field to select the e-mail message that will be delivered to the escalation receivers when the
escalation is raised (or thrown). You can create a new message, or select an appropriate message from
the list and click Edit to make any necessary changes to it. This field is active only if the Notification
type is set to E-mail.
Repeat notification every
Use these fields to specify the period of time that will elapse before the notification associated with this
escalation is repeated.
You can enter the values using the spin boxes provided, or click the secondary radio button and enter a
value that makes sense to the type of calendar (simple, WebSphere CRON, user-defined) that is
specified in the task's Duration properties page.
Increase task priority

Use this list to determine if and how this escalation's priority will change with each iteration of it.
You will have three options:
• No
• Choose No to leave the priority unchanged.
• Increase this time only
• Choose this if you only want it to boost the priority in the first iteration.
• Increase per repetition
• Select this if you want the priority augmented each time this escalation is repeated.
Business Process Choreographer Explorer
The settings in this table define the nature of the Java™ Server Page (JSP) that the staff member sees when
they are asked to interact with a task.
Click Add to define a new JSP, Remove to delete an existing definition, and Edit to make changes to existing
values. Click JSP editor to work with the actual JSP itself.
In the table, select one of two kinds of JSPs in the JSP type field, specify what fault will trigger it in the Fault field
if this JSP will be shown in the event of a fault, and then decide which role will see the JSP in the Apply to field.
You can then create a new JSP, or browse to an existing one, and use the context root field to define the
runtime path to the JSP.
Portal client
Use the settings on this page to configure the portal client UI element that will be associated with this human
task. Define its name in the Unique name field, and select a type for it from the Type list.
The process integration in WebSphere Portal is based on "task pages" that are assigned to human tasks and
displayed to the user when he selects a task in his task list. The content of a task page can be defined by the
portal administrator.
Therefore, the process designer can define a unique name for each human task, which is assigned by the portal
admin later on to the portal page he would like to be shown to a user when he selects a task in his task list.
For task pages there are two available options:

Page
In this case, the unique name is used to directly lookup a page which will be displayed. For all tasks of the same
type, the same static page is reused.
Page definition
When this option is used, the unique name defined above is used to lookup an instance template from which a
dynamic copy is created and added to the user's navigation in portal each time a task of this type is selected in
the task list. The template itself is not visible for the user.
When you are done, click Create Portlet.
Duration tab: Human Task editor

This topic includes a description of each of the fields on the Duration tab of the Properties view.
Task level
Calendar type
Use this field to specify a type of calendar that will measure the durations of this task.
You have the three following options:
• Simple
• This is, as the name suggests, a simple arithmetic calendar. Configure the time using
the spinners that are enabled when you choose this option.
• WebSphere® CRON
• This is a built-in calendar that uses a list of term expressions representing elements of
time to calculate the interval. Examples of this type of calendar can be found in the Related
Information section below.
• User-defined
• Use this option to select a calendar other than those provided. When you select it, two
new fields will appear that you can use to name the calendar, and point to a valid Java™
Naming and Directory Interface (JNDI) location.
• Business calendar
• There will be more than three options in the Calendar type field if a business calendar
is available. A business calendar can be used to model duration values for time-sensitive
aspects of your human task in order to account for such variables as regular working hours,
weekends, and holidays. See Related Tasks for more information.
Duration until task is overdue
Use this field to set the period that will elapse between the time this task is started and the time that it is
expected to be completed. The state of the task does not change when it is overdue.
You can enter a value that makes sense to the calendar you selected in the Calendar type field above,
or choose one of the following options:
• Immediate
• In this context, this setting means that the task will be considered due the moment it is
assigned.
• Never
• In this context, this setting means that the task will not be given a due date.
Duration until task expires
Use this field to specify the amount of time that should pass before this task reaches an end state of
"Expired". Users can not work on a task once it has expired.
You can enter a value that makes sense to the calendar you selected in the Calendar type field above,
or choose one of the following options:
• Immediate
• In this context, the task will be deleted the moment it expires.
• Never
• In this context, the task will not be removed from the system ever.
•
Duration until task is deleted
Use this field to determine when the task will be removed from the system once it is complete.
You can select either of the following:
• Immediate
• In this context, the task will be deleted immediately after it is completed.
• Never
• In this context, the task will not be removed from the system ever, and will never expire.
•
Auto deletion mode
This selection is not available if you choose Never on the Duration until task is deleted field. Use it to
decide whether or not to delete the task based on its outcome.
You have the following options:
• On completion
• Choose this option to delete the task from the system once it is finished, whether or not
it was successfully completed.
• On successful completion
• Choose this option to only delete the task when it has been successfully completed.
Calendar name
This field appears when you chose the User-defined option in the Calendar type field above.
Use this field to enter a name for your custom calendar.
User calendar JNDI

This field appears when you choose the User-defined option in the Calendar type field above.
Use this field to specify the Java Naming and Directory Interface (JNDI) location for your custom
calendar.
Environment tab: Human Task editor

This topic includes a description of each of the fields on the Environment tab of the Properties view.
Custom properties table

Use the fields in this table to work with the custom properties that are defined by two fields: Name and
Value.
Click Add to create a new property (in which case a new window opens that lets you enter the key value
pair), Remove to delete an existing one, and Edit to make changes to one.
Interface tab: Human Task editor

This topic includes a description of each of the fields on the Interface tab of the Properties view.
Use the settings on this page to select the single-operation Interface that is singularly associated with
User interface settings tab: Human Task editor
This topic includes a description of each of the fields on the User interface tab of the Properties view.
IBM® Lotus Forms client

Select where to store your Lotus® Forms
You can store your Lotus Forms as part of your module, or at a specified web location. Select Module to
store the form as part of the module, select Web Project to specify the web location of a form.
Input/Output
If a Lotus Forms client is defined for a human task, you must specify the form which will be displayed to
the user in the Lotus Forms Client.
For forms stored in the module, click Browse to use an existing form, or click New to a create a form.
For forms stored in a web project, click Browse to select an existing form in an existing web project, or
click New to a create a new web project, or a new form within an existing web project. Alternatively you
can type the ContextRoot and file name directly in the respective fields.
During run time, save the Lotus Form when a task is saved or completed
The generated client will save the transmitted Lotus Form after each Save or Complete request on the
server. By default Lotus Forms saves the files in the temporary directory of the WebSphere® Process
Server it is running in (to change the location where the forms are saved, or the way the forms are
stored, you must customize the generated client).
To customize the save options, modify the saveForm and getForm methods in the
PersistenceService class in the com.ibm.wbit.tel.client.form.persistence package on
the generated client.
Enable this feature to pass the complete form (including digital signatures) to the tasks that follow this
one, and which are working in the same form.
The building blocks of the human task editor

Compose your own human task using a combination of the following building blocks
• People assignment roles and criteria

• People assignment settings
• User interface settings
• Escalation settings
People assignment roles and criteria
Roles and criteria interact to identify staff members according to their access rights. More specifically,
authorization roles determine what their members are allowed to do in the runtime environment, and people
assignment criteria define who will be member of an authorization role.
To understand how this works, you have to keep in mind that a task is assigned first and foremost to a role, not
an individual. Each staff member in this role group has the permissions assigned to the role as a whole. Criteria
act to further refine the list of members who can claim the work. Officially, a people assignment criteria is a
database query that retrieves a list of members from the runtime engine.
People assignment settings
Use the staff settings to determine which roles can interact with your human task.
There are six possible roles to choose from, and those that appear will depend on the kind of human task that
you are working with.
• Administrators
Administrators have the authority to perform upper level duties like suspend, terminate, restart, force-
retry, and force-complete.
• Potential creators
Potential creators can create an instance of the human task, but cannot start it.
• Potential starters
Potential starters have the authority to initiate an existing instance. The starter role is subtly different
from that of creator, and although a creator can create a new instance, only a starter can start it. In many
usage scenarios, the same employee fulfils both roles.
This role is only associated with an invocation task.
• Potential owners
Potential owners can claim, work on and complete tasks.
• Editors
Editors can work with the content of a task, but cannot claim or complete it. For example, an editor can
receive the work item to review a document and add comments, but an editor is not able to finish the
task.
• Readers
Readers are allowed to view tasks, but cannot work on them. This role can be used in situations where
an employee wants to monitor as task without taking any action in it.
User interface settings
Use the User interface settings to determine how people interact with the tasks.
There are three user interfaces that you can chose from:
• IBM® Lotus® Forms client
Select IBM Lotus Forms client to present information to the user with the Lotus Forms Client.
• Business Process Choreographer Explorer
Select the Business Process Choreographer Explorer to use the standard client that is delivered with this
product.
With this option, the task is delivered to the staff member via an HTML-based web page. The look and
feel of this web page is determined by the JSP values in the User interface settings table. You can
modify these values as needed.
• Portal client
Select the portal client to specify a client that is executed on WebSphere® Portal
Escalation settings
Use the escalation settings to specify how long to wait for a task to complete, and which role to notify when it
doesn't. When you configure an escalation, you begin by specifying the state that the task is in when the
escalation period begins (this is also known as the activation state and there are three options shown in the
human task editor). Once you have chosen the activation state, you create an escalation for it by stipulating what
state the task should be in at the end of a specific period of time, and what to do if it isn't.
There are four possible activation states:
• Ready
When a task is in the ready state, it is waiting to be claimed.

Configure the escalation settings to notify people or escalation receivers should nobody claim it within a
specified period of time.
• Claimed
When a task is in the claimed state, a person has accepted the work and should currently be working on
it.
Configure the escalation settings to notify people or escalation receivers should the owner fail to
complete the work within a specified period of time.
• Subtask started
When a task is in the waiting for subtasks state, additional work was delegated to other people in order
to complete the parent task.
Configure the escalation settings to notify people or escalation receivers should the subtasks not be
completed within a specified period of time.
• Running
This state is only available with invocation tasks. When a task is in the running state, it has invoked the
service and waits for it to complete.
Configure the escalation settings to notify people or escalation receivers when the invoked service does
not return an output or fault message in time.
Invocation scenarios for invocation tasks

The various ways in which tasks can be invoked is described.
Information on this topic can be found by following this link: Scenarios for invoking tasks or Scenarios for invoking
tasks if you have WebSphere Process Server installed.
Replacement variables and context variables
While working with templates in the tooling environment, you might want to refer to a variable that will not be
resolved until the instance has been started in the runtime environment. This variable is known as a context
variable, because its value is dependent upon the task context in which it is exists (or the process context for
inline tasks). If you want to refer to such a context variable in a template, you must use a replacement variable.
Context variables can come from many sources. For example, they can originate from previous staff resolutions,
input/output messages, custom properties and, in the case of inline tasks, from the surrounding business
process. They can be used in many places within the tooling environment, including the following:
• staff queries of tasks
• staff queries of escalations
• in the description and documentation of tasks
• in the description and documentation of escalations
• in notification e-mails sent by escalations.
• durations of tasks
• priority of tasks
• the type property (business category) of tasks
• custom properties of tasks
• durations of escalations
• custom properties of escalations
Use of replacement variables
Context variables might only be available during specific periods of an instance's life cycle (a task owner is only
defined once the task has been claimed) and can resolve either to single or multiple values. Multiple values are
returned in a string array (which is represented as a comma separated list when used in an email) .
In cases when you can use a replacement variable, you will simply be able to click the associated Insert Variable
button and choose something appropriate from the Replacement Variable Selection window. However, you can
also enter a replacement variable into a template directly by encapsulating it in "%" signs. For instance
%htm:task.originator%
Note:
• Using percent signs within variable names is not allowed.
• If you want to use a percent sign in a string within the replacement variable, then you will need to use
two percent signs ("%%") instead of one.
• Variables can contain XPath expressions. If an XPath expression contains a "%" sign, it must be
escaped as specified by XML (using %).
The categories shown below contain specific details on which expressions can be used and when.
• Replacement variables in people assignment criteria and task descriptions

When used in descriptions for people assignment criteria and human tasks, replacement variables can
be used to represent context variables that will be fully resolved in the runtime environment.
• Replacement variables in staff e-mails

When used in escalation-based staff e-mails, replacement variables can be used to represent context
variables that will be fully resolved in the runtime environment.
• Replacement variables for escalation duration expressions

The Escalate within value can also be represented by a replacement variable that refers to a variable
that will get resolved in the runtime environment.
Replacement variables in people assignment criteria and task

descriptions
When used in descriptions for people assignment criteria and human tasks, replacement variables can be used to
represent context variables that will be fully resolved in the runtime environment.
To use a replacement variable in a template, encapsulate it in '%' signs. For instance %htm:task.originator
%
Note:
two percent signs (“%%”) instead of one.
• Variables can contain XPath expressions. If an XPath expression contains a “%” sign, it must be
Replacement variables for people assignment criteria and descriptions in human tasks can contain the contents
of variables and messages. In addition resolved people assignment criteria of sibling inline tasks can be used
from other inline tasks.
Available expressions differ depending on whether it is a stand-alone, or an inline human task.
Stand-alone human tasks
The following table lists all expressions that are available for stand-alone human tasks (i.e. tasks that are not
embedded inline in a process). When these expressions are used inside descriptions as well as people
assignment criteria, they must be enclosed in '%' characters.
Table 1. A list of all expressions that can be used in stand-alone human tasks.
Type of
variable Expression Description
Staff htm:task.originator the user ID of the originator of this

Variables task instance
htm:task.owner the user ID of the owner of this task

instance
htm:task.starter task starter name
htm:task.administrators list of task administrators
htm:task.potentialOwners list of potential task owners
htm:task.editors list of task editors
htm:task.readers list of task readers
htm:task.potentialStarters list of potential task starters
htm:task.potentialInstanceCreators list of potential creators
Task htm:task.property.customPropertyName value of the task's custom properties

variables
Note that only the string value of
properties can be evaluated. For
binary custom properties, the query
string will be evaluated.
htm:task.displayName default task display name
htm:task.description default task description
htm:task.instanceID task instance id

Table 1. A list of all expressions that can be used in stand-alone human tasks.
Type of
htm:input.[part][\XPath] data from task's input message is

provided using XPath expressions
(or htm:input.part[\XPath])
(Process Server messages usually
have a single part, in which case the
part name does not have to be
specified. When using messages
with multiple parts then the syntax in
parenthesis has to be used. Also
see the notes below.)
htm:output.[part][\XPath] data from task's output message is

(or htm:output.part[\XPath])
(Process Server messages usually
have a single part, in which case the
part name does not have to be
specified. When using messages
with multiple parts then the syntax in
parenthesis has to be used. Also
see the notes below.)
Note that task instances have no default

message.
Escalation htm:escalation.description default escalation description

variables
htm:escalation.expectedTaskState escalation's expected task state
htm:escalation.instanceID a string representation of the

escalation instance id
htm:escalation(escalationName).receivers escalation receivers
htm:escalation.property.customPropertyName value of escalation's custom

properties

binary custom properties, the query
string will be evaluated.
You can use either %htm.input.\XPath% or %htm.output.\XPath% to refer to input or output parameters
of the operation defined for a task interface.
For example, the WSDL code shown below defines a task interface comprising of an operation with one input
parameter (input1) and one output parameter (output1). In this case, the expressions
%htm:input.\input1%, %htm:output.\output1% can be used to reference the defined parameters.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:tns="http://variables/variablesInterface"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="variablesInterface"
targetNamespace="http://variables/variablesInterface">
<wsdl:types>
<xsd:schema targetNamespace="http://variables/variablesInterface"
xmlns:tns="http://variables/variablesInterface"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="operation1">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input1" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="operation1Response">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="output1" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="operation1RequestMsg">
<wsdl:part element="tns:operation1" name="operation1Parameters"/>
</wsdl:message>
<wsdl:message name="operation1ResponseMsg">
<wsdl:part element="tns:operation1Response" name="operation1Result"/>
</wsdl:message>
<wsdl:portType name="variablesInterface">
<wsdl:operation name="operation1">
<wsdl:input message="tns:operation1RequestMsg" name="operation1Request"/>
<wsdl:output message="tns:operation1ResponseMsg" name="operation1Response"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
In addition, expressions like %htm:input.part[\XPath]%, and %htm:input.part[\XPath]% can be used

to refer to input and output parameters associated with the different WSDL message parts defined for a task
operation. Currently, only single-part messages are generated, so it can only be used on expressions that
exclude message part names.
For example, the expressions %htm:input.operation1Parameters\input1%,

%htm:output.operation1Result\output1% are valid and equivalent to %htm:input.\input1%,
%htm:output.\output1% .
It is expected that XPATH will point to objects of type String, or String List. In general, and object will be replaced
by what the toString() method returns.
Inline human tasks
In addition to the expressions in the previous table, a human task that is embedded inline in a process can also
use the expressions listed in the following table for staff resolution. Note, that the description of an inline human
task is resolved by the Business Flow Manager (BFM) and must therefore be modeled to use the syntax
described in the previous section.
Table 2. A list of the expressions that can be use with inline human tasks.
Type of
Process wf:variable.VariableName\[part][\XPath] 'VariableName\[part][\XPath]' is passed to

variables BFM to resolve the variable/expression.
Table 2. A list of the expressions that can be use with inline human tasks.
Type of
wf:property.customPropertyName The 'customPropertyName' is passed to

the BFM to resolve the custom property.
Inline staff wf:process.starter The starter of the process.

variables
wf:process.administrators The administrators of the process.
wf:process.readers The readers of the process.
wf:activity(activityName).potentialOwners The potential owners of either the current

activity or the activity named in brackets
wf:activity(activityName).owner The owner of the activity named in

brackets
wf:activity(activityName).editors The editors of either the current activity or

the activity named in brackets
wf:activity(activityName).readers The readers of either the current activity

or the activity named in brackets
Note that inline staff variables which refer to sibling activities can only be resolved if the referred activity is also an
inline human task and is already started at the point in time when the staff resolution happens.
As with stand-alone tasks, it is expected that XPATH will point to objects of type String, or String List. In general,
and object will be replaced by what the toString() method returns.
Replacement variables in staff e-mails

When used in escalation-based staff e-mails, replacement variables can be used to represent context variables
that will be fully resolved in the runtime environment.
%
Note:
Table 1. A list of all expressions that can be used in e-mails.
Type of
Staff htm:task.originator the user ID of the originator of

Variables this task instance
htm:task.owner the user ID of the owner of this

task instance
htm:task.administratorss list of task administratorss
Task htm:task.property.customPropertyName value of the task's custom

variables properties

binary custom properties, the
query string will be evaluated.
htm:task.URLPrefix the link to the client that displays

the task details that is used to
construct HTTP references in e-
mails.
htm:task.URLPrefixAdmin the link to the administrative

client when a custom admin
client is used (otherwise, use
htm:task.URLBPCExplorer
instead).
htm:task.URLBPCExplorer the link to the Business Process

Choreographer Explorer URL
Type of
with task details
htm:input.[part][\XPath] data from task's input message

is provided using XPath
(or htm:input.part[\XPath]) expressions
(Process Server messages

usually have a single part, in
which case the part name does
not have to be specified. When
using messages with multiple
parts then the syntax in
parenthesis has to be used.)
htm:output.[part][\XPath] data from task's output message

is provided using XPath
(or htm:output.part[\XPath]) expressions
(Process Server messages

usually have a single part, in
which case the part name does
not have to be specified. When
using messages with multiple
parts then the syntax in
parenthesis has to be used.)
Note that task instances have no default message.
Escalation htm:escalation.activationState escalation's activation state

variables
htm:escalation.description default escalation description
htm:escalation.displayName escalation display name
htm:escalation.instanceID a string representation of the

escalation instance id
htm:escalation.property.customPropertyName value of escalation's custom

properties

binary custom properties, the
query string will be evaluated.
htm:escalation.receivers list of users who receive the

escalation
htm:escalation.URLPrefix the link to the client that displays

the escalation details used to
Type of
construct HTTP references in e-

mails.
htm:escalation.URLBPCExplorer the link to the Business Process

Choreographer Explorer URL
with escalation details
Process wf:variable.\messagePartName[\XPathExpression] This resolves the variable and

variables expression.
wf:property.customPropertyName This resolves the custom

property.

variables
wf:process.administrators The administrators of the

process.
wf:activity(activityName).potentialOwners The potential owners of either

the current activity or the activity
named in brackets
wf:activity(activityName).owner The owner of either the activity

named in brackets
wf:activity(activityName).editors The editors of either the current

activity or the activity named in
brackets
wf:activity(activityName).readers The readers of either the current

activity or the activity named in
brackets
Note:
For those expressions with XPath, it is expected that XPath will point to objects of type String, or String List. In
general, and object will be replaced by what the toString() method returns.
Replacement variables for escalation duration expressions

The Escalate within value can also be represented by a replacement variable that refers to a variable that will
get resolved in the runtime environment.
This variable that is referenced must contain a time specification that is valid when the escalation is evaluated (if
there are repeated escalations, then this is the time at which the escalation is evaluated the first time), and the
variable must exist at the escalation's creation time (otherwise you will get an error and the transaction will be
rolled back).
% or as shown in the screen capture below.
Note:
To specify the escalation time dynamically, proceed as follows:
1. Add a variable to your project that contains a string that will be passed to the human task in the input
message, and one that will contain a valid time specification at runtime.
2. Select the escalation object and go to the Details tab in the Properties view.
3. As the duration, enter %htm:input.\yourVariableName%, in this example
%htm:input.\myEscalationTime%.
Table 1. A list of all expressions that can be used in duration expressions.
Type of
Staff htm:task.originator the user ID of the originator of this task

Variables instance
htm:task.owner the user ID of the owner of this task

instance
htm:task.administrators list of task administrators

Type of
Task htm:task.property.customPropertyName value of the task's custom properties

variables
properties can be evaluated. For binary
custom properties, the query string will
be evaluated.
htm:task.URLPrefix the link to the client that displays the task

details that is used to construct HTTP
references in e-mails.
htm:task.URLPrefixAdmin the link to the administrative client when

a custom admin client is used (otherwise,
use htm:task.URLBPCExplorer instead).
htm:task.URLBPCExplorer the link to the Business Process

Choreographer Explorer URL with task
details
htm:input.[part][\XPath] data from task's input message is

(or htm:input.part[\XPath])
(Process Server messages usually have
a single part, in which case the part
name does not have to be specified.
When using messages with multiple parts
then the syntax in parenthesis has to be
used.)
htm:output.[part][\XPath] data from task's output message is

(or htm:output.part[\XPath])
(Process Server messages usually have
a single part, in which case the part
name does not have to be specified.
When using messages with multiple parts
then the syntax in parenthesis has to be
used.)
Note that task instances have no default message.
Escalation htm:escalation.activationState escalation's activation state

variables
Type of
htm:escalation.description default escalation description
htm:escalation.displayName escalation display name
htm:escalation.instanceID a string representation of the escalation

instance id
htm:escalation.property.customPropertyName value of escalation's custom properties

properties can be evaluated. For binary
custom properties, the query string will
be evaluated.
htm:escalation.receivers list of users who receive the escalation
htm:escalation.URLPrefix the link to the client that displays the

escalation details used to construct
HTTP references in e-mails.
htm:escalation.URLBPCExplorer the link to the Business Process

Choreographer Explorer URL with
escalation details
Process wf:variable.\messagePartName[\XPathExpression] This resolves the variable and

variables expression.
wf:property.customPropertyName This resolves the custom property.

variables
wf:process.administrators The administrators of the process.
wf:activity(activityName).potentialOwners The potential owners of either the current

activity or the activity named in brackets
wf:activity(activityName).owner The owner of either the activity named in

brackets
wf:activity(activityName).editors The editors of either the current activity

wf:activity(activityName).readers The readers of either the current activity

Refactoring a human task

When you refactor parts of your human task, dependencies on those parts are automatically and universally
updated throughout the product as a whole.
There are two ways in which you can refactor parts of your human task. You can either do it from an appropriate
field within the properties pages, or use a context menu in the Business Integration view.
1. To refactor parts of your human task from a properties page, proceed as follows:
a. Click the field that contains the property that you would like to refactor. These are the names of
the fields that you can change, as well as the property page on which they are located:
Field name Property page Description
Name Description Use this option to change the

name assigned to the task.
Namespace Description Use this option to assign a new

namespace to your task.
b. Once the refactoring toolbar appears, press Alt+Shift+R.
c. A new window will appear in which you can change the property as necessary.
2. To refactor using the context menu, proceed as follows:
a. In the Business Integration view, right-click the human task.
b. From the menu, hover over Refactor and then choose from one of the following three options:
Option Description
Rename Use this option to change the name assigned to the human task.
Move Use this option to move your task to a new folder or module.
Change Namespace Use this option to assign a new namespace to your task.
Supporting other languages

With the internationalization settings of the human task editor, you can display client-based information in multiple
languages.
You can use this functionality to provide text strings for the following:
• Task name
• Task description
• Documentation
• Escalations
To internationalize a human task, proceed as follows:
1. Right-click an empty area of the human task editor, and select Internationalization > Export.
a. In the Select Export Directory window, specify a file location and name for the output. The
window will then display a list of the property files that will be exported. A properties file will be
exported for each locale that is currently present in the human task.
b. When you are done, click Finish.
c. Have the content of each of the properties files translated, and rename each one according to
the language that it represents. For example, a German properties file would be named
TaskName_de_DE.properties. Make sure that the text is properly ASCII encoded. You can
use native2ascii tool that is provided with the Java™ SDK to transform a text file from the
platform's native encoding to ASCII.
Important: In the human task editor, do not rename the task or any of its escalations. There are
keys included in the properties files, and they have to match the original source material.
2. When you have the translated properties files, right-click an empty area of the human task canvas, and
select Internationalization > Import.
a. In the Select Import Directory and Property Files, browse to the folder where you stored the
properties files and click Open. The window will then display a list of the property files that can
be imported.
b. When you are done, click Finish.
3. Save your work.
4. To change the default client locale, proceed as follows:
a. In the Outline view, click your task to choose it as a whole.

b. In the Details tab of the properties area, select an appropriate language from the default
language field.
When you deploy this human task, the internationalization information will be passed to the runtime environment,
and the next time a template of this task is instantiated, the user interface will display the text in the language that
corresponds to the requesting systems's locale.
Assigning roles to your human task
A role is a set of employees who share the same level of authority. When it comes to working on tasks, the role
that the person belongs to defines their authorization.
To add a role to your human task, proceed as follows:
1. Launch your human task in the editor. The display that you see will depend on what kind of human task
you are working with. For example, there will already be a few roles selected, and the display for the
people assignment settings will differ as such:
Kind of task People assignment display
To-do Receiver
In this case, you will be configuring the roles for the people who will be able to claim
and work on this task.
Invocation Originator
In this case, you will be configuring the roles for the people who will be able to initiate
the task.
Collaboration Both receiver and originator

Since a collaboration task is assigned to one person from another, it has both receiver
and originator settings. See above for descriptions of each.
2. To add another role to this task, click the icon and select one from the drop down list. The drop down
list will only show those roles that are still available to be chosen. Here is a list and a description of each
of the roles that you will be able to work with:
Table 1. Available roles and their descriptions
Role (icon) Description
Administrators Administrators have the authority to perform higher level duties like suspend,
terminate, restart, force-retry, and force-complete.
Potential Potential creators can create an instance of the human task, but cannot start it.
creators
Potential Potential starters have the authority to initiate an existing instance. The starter role
starters is subtly different from that of creator, and although a creator can create a new
instance, only a starter can start it. In many usage scenarios, the same employee
fulfils both roles. This role is only associated with an invocation task.
Potential Potential owners can claim, work on and complete tasks.

owners
Editors can work with the content of a task, but cannot claim or complete it. For
Editors
example, an editor can receive the work item to review a document and add
comments, but an editor is not able to finish the task.
Readers Readers are allowed to view tasks, but cannot work on them. This role can be used
in situations where an employee wants to monitor as task without taking any action
in it.
3. To remove an existing role, select it in the table, and click .
4. In the Assign People tab of the properties area, use the people assignment criteria settings to specify
which people should belong to the role in question.
Configuring the people directory

Use this task to configure the LDAP or VMM people directory provider that Business Process Choreographer
uses to determine who can start a process or claim an activity or a task.
Information on this topic can be found by following this link: Configuring the people directory provider or
Configuring the people directory provider if you have WebSphere Process Server installed.
Defining the people assignment criteria
People assignment criteria are constructs that are used in the task model to identify sets of people that can be
assigned to an instance-based authorization role. At runtime, the people resolution uses the people assignment
criteria to retrieve the user IDs and other user information, for example, for composing e-mails.
Information on this topic can be found by following this link: People assignment criteria or People assignment
criteria if you have WebSphere Process Server installed.
• Predefined people assignment criteria

Predefined people assignment criteria are provided for retrieving sets of users from people directories.
• Customizing people assignment criteria

You can also extend the set of predefined people assignment criteria by customizing your own criteria.
• Creating queries
When an application is deployed, people assignment criteria definitions are transformed into sets of
queries that are specific to a people directory configuration. The resulting people queries are stored with
the task template in the Business Process Choreographer database.
Predefined people assignment criteria

Predefined people assignment criteria are provided for retrieving sets of users from people directories.
You can use people assignment criteria (previously known as staff verbs) in WebSphere® Integration Developer
to specify people assignments in a human task. These criteria are transformed during modeling and deployment
into a set of queries that can be run on a people directory. The parameters for the following predefined people
assignment criteria are listed here:
• Department Members
• Everybody
• Group
• Group Members
• Group Members without Named Users
• Group Members without Filtered Users
• Group Search
• Manager of Employee
• Manager of Employee by user ID
• Native Query
• Nobody
• Person Search
• Role Members
• User Records by user ID
• User Records by user ID without Named Users
• Users
• Users by user ID
• Users by user ID without Named Users
Consider the following when you assign people assignment criteria:
• If you are working with large groups of people, the Group people assignment criteria works best because
it handles the members of a group as a unit. This allows you to transfer a human task from one group to
another group easily. A person’s group membership is resolved when the person logs in and accesses a
human task.
• To individually assign people that belong to a group to a human task, the Group Members people
assignment criteria provides an alternative to the group assignment. The Group Members people
assignment criteria creates an assignment for each person individually. This assignment can then be
transferred to another person. Substitution can occur, that is, a person that is absent can be replaced by
another person. A variant of this people assignment criteria, Group Members without Named Users
supports the separation-of-duties assignment pattern.
Note: Assigning people to a group individually can affect performance at runtime, especially when
assigning more than a few people to the group.
• To assign a few people to a human task that do not all belong to the same group, consider using the
User Records by user ID people assignment criteria definition. You can also use this definition when the
people assignment is not statically defined during modeling, but includes replacement expressions.
Replacement expressions can refer to custom properties or the input message of a human task. The
Users by user ID people assignment criteria definition is similar to the User Records by user ID definition.
Although the Users by user ID definition performs better than the User Records by user ID definition at
runtime, it provides less functionality:
o It does not check if the user IDs are entered correctly
o It does not retrieve, for example, the e-mail addresses for the user IDs specified, which makes it
less suitable for assigning people to e-mail escalations
• The Everybody people assignment criteria definition is also worth considering. It indicates that all
authenticated users are assigned to the human task. While there are cases where all people in an
organization can do a certain job, this definition is particularly useful during development, or when rapidly
prototyping an application.
• The list of people assignment criteria that you see is filtered by your choice of people directory provider.
If you choose Lightweight Directory Access Protocol (LDAP) as your provider, then criteria that are
appropriate only for virtual member manager will not be displayed.
Department Members
Use this criteria to retrieve the members of a department. It is supported by the LDAP, and the virtual member
manager people directory providers.
Parameter Use Type Description
DepartmentName Mandatory string Department name of the users to

retrieve. The department name must
correspond to one of the following
values:
• For virtual member manager, a

unique name of a virtual
member manager group
• For LDAP, a distinguished
name (DN) of an LDAP group
IncludeNestedDepartments Mandatory boolean Specifies whether nested departments

are considered in the query.
AlternativeDepartmentName Optional string An additional department to which the

1 users can belong.
An additional department to which the

AlternativeDepartmentName Optional string users can belong.
2
Everybody
Use this criteria to assign every user that is authenticated by WebSphere Process Server to a task role. This
criteria has no parameters.
This criteria is supported by all of the people directory providers.
Group
Use this criteria to assign a group to a task role. This assignment creates a group work item instead of creating
user work items for every assigned user.
This criteria is supported by all of the people directory providers.
Group name of the users to retrieve. This

GroupId Mandatory string parameter supports replacement
expressions. The group ID must
correspond to one of the following values:
unique name of a group entry
• For LDAP, a DN of a group entry
• For the user registry provider,
the name format you use
depends on which user
repository is set for the
application server where the task
is deployed:
o For the local operating
system, use a group
name that is supported
by the local operating
system
o For a stand-alone
custom registry, use a
group name supported
by the custom
implementation
o For a stand-alone LDAP
registry, use a DN of a
group entry
Group Members
Use this criteria to retrieve the members of a group. It is supported by the LDAP, virtual member manager, and
the user registry people directory providers.
GroupName Mandatory string Group name of the users to retrieve. This

parameter supports replacement
expressions. The group ID must
correspond to one of the following values:

• For the user registry provider,
the name format you use
depends on which user
repository is set for the
application server where the task
is deployed:
system, use a group
name that is supported
by the local operating

system
o For a stand-alone
custom registry, use a
group name supported
by the custom
implementation
group entry
IncludeSubgroups Mandatory boolean Specifies whether nested subgroups are

considered in the query.
AlternativeGroupName1 Optional string An additional group to which the users

can belong.
An additional group to which the users

AlternativeGroupName2 Optional string can belong.
Group Members without Named Users

Use this criteria to retrieve all of the members of a group, except for the explicitly named users. It is supported by
the LDAP, virtual member manager, and the user registry people directory providers.

expressions. The group ID must correspond
to one of the following values:

• For the user registry provider, the
name format you use depends on
which user repository is set for the
application server where the task is
deployed:
system, use a group name
that is supported by the
local operating system
o For a stand-alone custom
registry, use a group name
supported by the custom
implementation
group entry

The user IDs of the users to exclude from

NamedUsers Mandatory string the retrieved group members list. This
expression.
Group Members without Filtered Users

Use this criteria to retrieve all of the members of a group except for a set of users that is defined by a search
filter. It is supported by the LDAP, and virtual member manager people directory providers.

expressions. The group ID must correspond
to one of the following values:


FilterAttribute Mandatory string Name of the attribute to use in the search

filter.
Filter value to use in the search filter. You

FilterValue Mandatory string can use the wildcard character, asterisk (*),
in the filter.
Group Search
Use this criteria to search for a group based on attribute matches, and to assign the members of the group. It is
supported by the LDAP, and virtual member manager people directory providers.
GroupID Optional string The group ID of the users to retrieve.
Type Optional string The group type of the users to retrieve.
IndustryType Optional string The industry type of the group to which the
users belong.
BusinessType Optional string The business type of the group to which the
users belong.
GeographicLocation Optional string An indication of where the users are

located.
Affiliates Optional string The affiliates of the users.
DisplayName Optional string The display name of the group.
Secretary Optional string The secretary of the users.
Assistant Optional string The assistant of the users.
Manager Optional string The manager of the users.
BusinessCategory Optional string The business category of the group to

which the users belong.
The parent company of the users.

ParentCompany Optional string
For virtual member manager, the Group entity has properties that are equivalent to the following Group Search
criteria parameters:
• GS_GroupID: cn
• GS_DisplayName: displayName
• GS_BusinessCategory: businessCategory
Manager of Employee
Use this criteria to retrieve the manager of a person using the person's name. It is supported by the LDAP and
virtual member manager people directory providers.
The name of the employee whose

EmployeeName Mandatory string manager is retrieved. The employee
name must correspond to one of the
following values:
• For virtual member manager, the
unique name of a person entry
• For LDAP, a DN of a person
entry
Manager of Employee by user ID
Use this criteria to retrieve the manager of a person using the person's user ID. It is supported by the LDAP and
virtual member manager people directory providers.
The login user ID of the employee whose

EmployeeUserID Mandatory string manager is retrieved. This parameter supports
replacement expressions.
Native Query
Use this criteria to define a native query based on directory-specific parameters. For LDAP the following
parameters apply:
QueryTemplate Mandatory string The query template to use. This must be one of
the following values: search, user, or
usersOfGroup.
Query Mandatory string Specifies the query. This parameter supports

replacement expressions. The type of query
depends on the query template.
• search template: a valid LDAP filter

• user template: a DN of a user entry
• usersOfGroup: a DN of a group
AdditionalParameter1 Mandatory string Specifies the query. This parameter supports

where replacement expressions. The type of
applicable parameter depends on the query template.
• search template: used to specify

whether recursive search is done.
Supported values: yes and no
• user template: not applicable
• usersOfGroup: Used to specify
whether recursive search is done.
Supported values: yes and no
AdditionalParameter2 Optional string Use this criteria to specify a base entry for
searching.
• a DN of a base entry
AdditionalParameter3 Optional string Use this criteria to specify an additional

parameter.
If you use the default mapping XSLT files, this

parameter is not supported.

parameter.

Use this criteria to specify an additional

AdditionalParameter5 Optional string parameter.

For virtual member manager (VMM) people directory providers the following parameters apply:
QueryTemplate Mandatory string The query template to use. This must be one of
the following values: search, user, or
usersOfGroup.
Query Mandatory string Specifies the query. This parameter supports

replacement expressions. The type of query
depends on the query template.
• search template: a valid search

expression
• user template: a unique name of a user
entry
• usersOfGroup: a unique name of a
group
AdditionalParameter1 Mandatory string Used to specify whether performing a people or

where group search. Mandatory depending on query
applicable template.
• search template: either person or

group
• usersOfGroup: not applicable
AdditionalParameter2 Optional string Use this criteria to specify a base entry for
searching.
• a unique name of a base entry, for

example, dc=mycomp, dc=com
AdditionalParameter3 Optional string Used to specify whether recursive search is

done. Supported values: true and false.
• search template: applicable when

AdditioanlParmeter1=group
• usersOfGroup: applicable

parameter.

Use this criteria to specify an additional

AdditionalParameter5 Optional string parameter.

Nobody
Use this criteria to deny users access to a task role. Only authorization inheritance and people resolution defaults
apply with this criteria. This criteria has no parameters.
Person Search
Use this criteria to search for people based on attribute matches. It is supported by the LDAP, virtual member
manager, and the user registry people directory providers.
UserID Optional string The user ID of the users to retrieve.
Profile Optional string The profile of the users to retrieve.
LastName Optional string The last name of the users to retrieve.
FirstName Optional string The first name of the users to retrieve.

MiddleName Optional string The middle name of the users to retrieve.
Email Optional string The e-mail address of the users.
Company Optional string The company to which the users belong.
DisplayName Optional string The display name of the users.
Secretary Optional string The secretary of the users.
Assistant Optional string The assistant of the users.
Manager Optional string The manager of the users.
Department Optional string The department to which the users belong.
Phone Optional string The telephone number of the users.
Fax Optional string The fax number of the users.
Gender Optional string Whether the user is male or female.
Timezone Optional string The time zone in which the users are located.
The preferred language of the user.

PreferredLanguage Optional string
For virtual member manager, the PersonAccount entity has properties that are equivalent to the following People
Search criteria parameters:
• PS_UserID: uid
• PS_LastName: sn
• PS_FirstName: givenName
• PS_MiddleName: initials
• PS_Email: mail
• PS_DisplayName: displayName
• PS_Secretary: secretary
• PS_Manager: manager
• PS_Department: departmentNumber
• PS_Phone: telephoneNumber
• PS_PreferredLanguage: preferredLanguage
Role Members
Use this criteria to retrieve the users associated with a role. It is supported by the LDAP and virtual member
manager people directory providers.
RoleName Mandatory string Role name of the users to retrieve.
IncludeNestedRoles Mandatory boolean Specifies whether nested roles are considered

in the query.
AlternativeRoleName1 Optional string An additional role name for the user.
An additional role name for the user.

AlternativeRoleName2 Optional string
User Records by User ID
Use this criteria to define a query for a user whose user ID is known. It is supported by the LDAP, virtual member
manager people directory providers. This criteria returns the user IDs, the e-mail information, and the preferred
locale, if set, for these users.
UserID Mandatory string The user ID of the user to retrieve. This

parameter supports replacement expressions.
AlternativeID1 Optional string An additional user ID. Use this parameter to

retrieve more than one user.
An additional user ID. Use this parameter to

AlternativeID2 Optional string retrieve more than one user.
Users Records by User ID without Named Users
Use this criteria to define a query for users whose user ID is known, while excluding an explicitly named user ID.
It is supported by the LDAP, virtual member manager, and user registry people directory providers. This criteria
returns the user IDs and the e-mail information for these users.



The user IDs of the users to exclude from the

NamedUsers Mandatory string user ID list. This parameter supports
Users
Use this criteria to define a query for a user who is known by name. It is supported by all of the people directory
providers.
Name Mandatory string The name of the user to retrieve.
• For virtual member manager, the

unique name of a person entry
• For LDAP, a DN of a person entry
• For the user registry provider, the
name format you use depends on
which user repository is set for the
application server where the task is
deployed:
system, use the user ID of
the user to assign
o For a stand-alone custom
registry, use a person name
supported by the custom
implementation
person entry
AlternativeName1 Optional string An additional user name. Use this parameter

to retrieve more than one user.
An additional user name. Use this parameter

AlternativeName2 Optional string to retrieve more than one user.
Users by User ID
Use this criteria to define a query for a user whose user ID is known. Use short names to specify values, for
example, wpsadmin. This criteria does not require access to a people directory. It is supported by all of the
people directory providers.


An additional user ID. Use this parameter to

AlternativeID2 Optional string retrieve more than one user.
Users by User ID without Named Users
Use this criteria to define a query for users whose user ID is known, while excluding an explicitly named user ID.
Use short names to specify values, for example, wpsadmin. This criteria does not require access to a people
repository. It is supported by all of the people directory providers.

expressions.


The user IDs of the users to exclude from the

NamedUsers Mandatory string user ID list. This parameter supports
Customizing people assignment criteria

You can also extend the set of predefined people assignment criteria by customizing your own criteria.
To create a customized people assignment criteria file, copy and modify one of the provided examples and then
add your new version to your human task preferences.
1. Copy one of XML files that contain the people assignment criteria definitions to a convenient location.
These files must be extracted from
com.ibm.wbit.tel.ui_6.2.version_number.jar
which can be found in the
shared_resources/plugins
directory (typically on Windows®, the shared_resources directory is C:\Program
Files\IBM\SDP70Shared).
2. In the copied version of the file, make the necessary changes.
3. Restart WebSphere® Integration Developer.
4. Add the new file to the workspace. From the main menu select File > Import > General > File System
and then browse to the new file. In the Into folder field select any module or folder within a module, the
new file only needs to be part of the workspace to be available. Click Finish.
5. Edit the human task preferences page and add a pointer to your customized XML file, and if desired
make it the default choice. See related tasks for details about setting human task preferences.
When you assign people to your task you should see your new people assignment criteria as an option.
Creating queries
When an application is deployed, people assignment criteria definitions are transformed into sets of queries that
are specific to a people directory configuration. The resulting people queries are stored with the task template in
the Business Process Choreographer database.
Information on this topic can be found at Mapping people assignment criteria to people queries or Mapping
people assignment criteria to people queries if you have WebSphere Process Server installed..
Defining substitution for absentees
The substitution feature allows a user to indicate when they will be absent so that a substitution policy can be
applied, and the work items can be assigned to somebody else.
A substitution policy defines how to deal with tasks and escalations that are assigned to absent users and is
defined when the task template is modeled. The same policy is applied for all of the task roles that are associated
with a task template. After the task template is deployed, you cannot change the policy.
If a user is absent, the substitution policy is applied to the results of the people resolution to determine who
receives the work items instead of the absent user. It is applied only to task roles that have people assignment
criteria. Substitution is refreshed if the people assignment criteria get refreshed.
Depending on the specific substitution policy, the following actions are applied:
No substitution (default):
The set of users remains unchanged
Replace absent users with their substitutes
If the user is present, then the work item is assigned to that user. However, for every absent user, the
first substitute who is present is used. If no such substitute exists, no substitute is used. If none of the
users and none of their substitutes are present, then the usual default user rules apply.
Prefer present users
In this case, substitution takes place only if none of the users that were resolved by the people
assignment criteria query is present. If any one of the group of users that were resolved is present, no
substitution takes place.
The substitution feature can be used in conjunction with the virtual member manager (VMM) people
directory provider. If an attempt is made to deploy a task template with a non-default substitution policy,
while specifying a people directory provider other than VMM, the deployment attempt will be rejected.
Note: VMM is the repository implementation provided by the WebSphere® Application Server for its
security realm ‘Federated Repositories’. This security realm has to be configured in WebSphere
Application Server in order to make VMM available for the substitution feature.
As substitution is a processing step after people resolution, it exhibits the same life cycle as people
resolution itself. For a given task role (e.g. Task Potential Owners), it is carried out, if a People
Assignment Criterion is associated with that role. Similarly, it is refreshed if the People Assignment
Criteria itself gets refreshed.
More information on this topic can be found by following these links:

Configuring people substitution
If you do not have WebSphere Process Server installed use this link: Configuring people substitution
Create and activate a Virtual Member Manager (VMM) property extension repository for Business
Process Choreographer to support user substitution.
Specifying absence settings

If you do not have WebSphere Process Server installed use this link: Specifying absence settings
If you intend to be away from the office for a certain time, specify a substitute for your tasks.
Specifying absence settings for users

If you do not have WebSphere Process Server installed use this link: Specifying absence settings for
users
If users are prevented from working on their tasks, for example, if they are on sick leave, specify a
substitute for the absent user's tasks.
Substitution for absentees

If you do not have WebSphere Process Server installed use this link: Substitution for absentees
The substitution feature allows you to specify absence settings either for yourself, or for members of the
group that you administer. A substitution policy defines how to deal with tasks and escalations that are
assigned to absent users.
Setting duration values for your human task
You can set a duration value for your human task to specify how long the task will hold before it is either due, set
to expire, or set to be deleted.
Note: The duration value is separate from the escalation function in human tasks. It will indicate when a task is
due, but the duration value will not trigger an escalation.
To set the duration values for your human task, proceed as follows:
1. In the Properties view of the task settings, click the Duration tab.
2. From the Calendar type field, you will have the following three options that will dictate the format your
calendar entries will take:
Option Description
Simple This is, as the name suggests, a simple arithmetic calendar. Use the Timeout
Option Description
Duration fields to select the amount of time that this activity should wait for an
action to occur before it expires.
WebSphere® This is a built-in calendar that uses a list of term expressions representing elements
CRON calendar of time to calculate the interval. Examples of this type of calendar can be found in
the Related Information section below.
User-Defined Use this option to select a calendar other than those provided. You can use the
calendar fields to name the calendar, and point to a valid Java™ Naming and Directory
Interface (JNDI) location.
Business There will be more than three options in the Calendar Type field if a business
calendar calendar is available. A business calendar can be used to model duration values
for time-sensitive aspects of your human task in order to account for such variables
as regular working hours, weekends, and holidays. See Using business calendars
within human tasks for more information.
3. The remaining fields on this page can be configured in any combination that you see fit, and according to
these choices:
Option Description
Use this field to set the period that will elapse between the time this task is started and
Duration the time that it is expected to be completed.
until task is Enter a value that makes sense to the calendar you selected in the Calendar type
overdue field, or choose one of the following options:
o Immediate
o In this context, this setting means that the task will be considered due
the moment it is started.
o Never
o In this context, this setting means that the task will not be given a due
date.
Duration Use this field to specify the amount of time that should pass before this task is moved
until task to the "Expired" state. A user cannot work on an expired task.
expires You can enter a value that makes sense to the calendar you selected in the Calendar
type field above, or choose one of the following options:
o Immediate
o In this context, the task will be expired the moment it is started.
o Never
o In this context, the task will not move to the expired state.
o
Duration Use this field to specify the amount of time that should pass before this task is
until task is removed from the system once it has reached a completed state. Completed states
deleted include: "Finished", "Failed", "Terminated", or "Expired". Deletion is also dependent on
Option Description
the choice you make in the Auto deletion mode field.

You can enter a value that makes sense to the calendar you selected in the Calendar
type field above, or choose one of the following options:
o Immediate
o In this context, the task will be deleted the moment it is completed.
o Never
o In this context, the task will not be removed from the system.
o
Auto This selection is not available when Duration until task is deleted is set to Never.
deletion Use this setting to configure the circumstances of the task's deletion.
mode You have the following options:
o On completion
o Choose this option to delete the task from the system once it is
finished, whether or not it was successfully completed.
o On successful completion
o Choose this option to only delete the task when it has been
successfully finished.
Calendar This field appears when you chose the User-defined option in the Calendar type
name field.
Use this field to enter a name for your custom calendar.
User This field appears when you choise the User-defined option in the Calendar type
calendar field.
JNDI Use this field to specify the Java Naming and Directory Interface (JNDI) location for
your custom calendar.
• Using business calendars within human tasks

When it comes to modeling duration values for time-sensitive aspects of your human task, you can use a
business calendar to account for such variables as regular working hours, weekends, and holidays.
Using business calendars within human tasks

When it comes to modeling duration values for time-sensitive aspects of your human task, you can use a
business calendar to account for such variables as regular working hours, weekends, and holidays.
A period of time that does not proceed in a sequential manner is called non-contiguous. So, when we say that the
business calendar can be used to model non-contiguous intervals of time, we are saying that the tool will take
into consideration the fact that a timeout duration is often affected by periods when a business may be closed, or
when an employee is absent. For example, imagine putting a human task activity in a business process, and then
assigning it a timeout duration of two days (or 48 hours). If an instance of this business process were to be
instantiated on a Friday afternoon, then it would be expecting a response by Sunday afternoon: a time when the
staff member to which it is assigned is away for the weekend. If however, we had modeled this timeout duration
using the business calender, it would be understood that the employee would be away from the office on
Saturday and Sunday, and would not expect a response to the task until Tuesday afternoon.
To use a business calendar in a human task, proceed as follows:
1. If you have not already done so, create a business calendar or import one from WebSphere® Modeler.
For detailed instructions on how to do this, refer to Business calendars.
2. In the Properties view of the task settings, click the Duration tab.
3. From the Calendar Type list, select the business calendar that you created or imported in Step 1.
4. Using the remaining fields, configure the amount of time that this human task should wait for an action,
knowing that the business calendar will compensate for all non-contiguous aspects of the interval of time.
Information on how to configure these fields can be found in the topic Setting duration values for your
human task
Using custom properties for human tasks
Custom properties are used to categorize a task, and can be useful for querying, sorting, and filtering tasks.
Search criteria can be defined for tasks, escalations and for the dynamic people assignment via custom
properties.
A task definition can contain an arbitrary number of custom properties. Each custom property has a name,
defined by a name attribute and a value of type string. For example:
Name = branch, Value = Chicago
Name = skill-level, Value = 3
Custom properties are defined on the Environment tab in the properties area.
Creating an escalation for your human task

An escalation is a notification that is sent out when an expected result from a task has not been achieved within a
set period of time. For example, an escalation could be used to alert a manager when a staff member is unable to
complete a task by the deadline.
Note: The duration value for a human task is separate from the escalation function. Although the duration value
will indicate when a task is due, it will NOT trigger an escalation.
When you create an escalation for your human task, you will need to know the following ahead of time:
• The state that the task is in when the escalation period begins (this is also known as the activation state).
• The state that you want the task to be in when the escalation period ends (it is when the task is NOT in
this expected state at the end of the period that the actual escalation is thrown).
• The escalation period, or how long you want the system to wait for the expected state to be reached
before notification occurs.
• The manner in which the notification takes place.
If you are creating more than one escalation for an activation state, you have two options:
Chained escalation
In a chained escalation, the escalations are executed sequentially, or one after the other. In such a case,
the first escalation must fully complete before the next one is initiated.
Parallel escalation
With a parallel escalation, the escalations are in two separate paths, and are executed at the same time
(or in accordance with the escalate after setting as described below).
To add an escalation to your human task, proceed as follows:
1. Launch your human task in the editor.
2. Under Escalation settings, choose the activation state from the following three options:
Option Description
Ready When a task is in the ready state, it is waiting to be claimed. Configure the escalation
settings to notify an authorized staff member should nobody claim it within the specified
period of time.
Claimed When a task is in the claimed state, a staff member has accepted the work and should
Option Description
currently be working on it. Configure the escalation settings to notify an authorized

employee should the staff member fail to complete the work within the specified period of
time.
Subtask A task is in the subtask state when the owner of the parent task must delegate part of the
task to other staff members. Configure an escalation for a subtask to make sure that it can
be completed in time enough for the parent task to be finished as well. If the subtask
cannot be completed within the required amount of time, the parent task is escalated and
indicates that it is still waiting on the subtask.
3. Click the Escalation icon to create a new escalation for the chosen activation state. A new
escalation appears below the selected activation state.
4. To add additional escalations to this activation state, proceed in one of the following two ways:
a. To create a chained escalation, select an existing escalation and click the Escalation
icon. A new escalation appears below the existing one as shown in the following image.
b. To create a parallel escalation, select an the activation state, and click the Escalation
icon. A new escalation appears beside the existing one as shown in the following image.
5. In the Details page of the properties area, configure the implementation as follows:
Option Description
Use this field to specify the state in which the task should be when the escalation
Expected task times out. If the task is not in the state specified, then an escalation is thrown.
state You will have the three following options:
o Ended
o Choose this as the expected end state when you want an
escalation initiated if the task is not complete by the end of the escalation
period.
o Claimed
o Choose this when you want an escalation initiated if, at the end of
the escalation period, the task has not yet been claimed by a user.
o All subtasks ended
o Choose this as the expected end state when you want an
escalation initiated if the subtasks associated with this task have not been
Option Description
completed by the end of the escalation period.
Escalate after Use these fields to specify the period of time that will elapse before this task is
escalated.
You can enter the values using the spin boxes provided, or click the secondary radio
button and enter a value that makes sense to the type of calendar (simple,
WebSphere® CRON, user-defined) that is specified in the task's Duration properties
page.
Notification Use this list to tell the system how to deal with this escalation.
type You will have three options:
o Work item
o Choose Work item to have the task delivered directly to a
designated staff member's "to do" list. Since a work item is always created
in an escalation, this setting creates a work item, and nothing else.
o E-mail
o Choose E-mail to have an e-mail message that announces the
escalation delivered to a staff member. Once you select this option, a
separate field will appear from which you can choose an appropriate e-mail
message.
o Event
o Choose Event if you want to trigger an event handler in the runtime
environment. If you select this option, you then have to specify the event
handler in the Event handler name field in the task's Details properties
page.
E-mail Use this field to select the e-mail message that will be delivered to the designated
message staff member in the event of the escalation. You can create a new message, or
select an appropriate message from the list and click Edit to make any necessary
changes to it.
Repeat Use these fields to specify the period of time that will elapse before the notification
notification associated with this escalation is repeated.
every You can enter the values using the spin boxes provided, or click the secondary radio
button and enter a value that makes sense to the type of calendar (simple,
WebSphere CRON, user-defined) that is specified in the task's Duration properties
page.
Increase task Use this list to determine if and how this escalation's priority will change with each
priority iteration of it.
You will have three options:
o No
o Choose No to leave the priority unchanged.
o Increase this time only
o Choose this if you only want it to boost the priority with one
iteration.
o Increase per repetition
o Select this if you want the priority augmented each time this
escalation is repeated.
2. In the Assign People page of the properties area, you can define the staff group
(criteria) and in so doing, specify the group of people that are notified should this escalation be
executed.
• Escalations
An escalation is a course of action that is implemented when an expected result from a task has
not been achieved within a set period of time.
• Assigning people to escalations

Use the Assign People tab of the properties area to specify the group of people that is notified
should this escalation be executed.
• Customizing an escalation e-mail notification

You can use an e-mail message to notify a staff member that they have a work item in the form of
an escalation.
• Notifying an event handler of an escalation

You can use customized notification event handlers within your application environment to deal
with escalations in your human task model.
Escalations
An escalation is a course of action that is implemented when an expected result from a task has not been
achieved within a set period of time.
You can use WebSphere® Integration Developer to model escalations for tasks that are in the activation states of
ready, claimed, or subtask.
A task in a ready state is escalated when it is not claimed in time, and a task in either a claimed or a subtask
state are escalated when the work has not been completed within the required time limit. For example, you could
use an escalation on a work item that has been sitting unclaimed for too long to send an email to a potential
owner to urge them to claim it. Or, an escalation can be used to notify first and/or second line managers when a
work item has lingered in a working state for too long. Or, you can model an escalation for a subtask to make
sure that it gets completed in plenty of time for the owner to finish the associated parent task.
An escalation can result in any one of the following actions:

1. the creation of a work item that can be claimed by a set of users,
2. notification of an appropriate staff member via e-mail,
3. notification of an event handler.
Designing an escalation
When you model an escalation to be created in the human task editor, you will need the following information to
complete it:
• to whom the resulting work item should be assigned,
• the period of time before it should be escalated,
• the state that you want the task to be in when the escalation value times out (if it is not in this state, then
an escalation is thrown),
• the action that should be taken in the case of an escalation,
• the mode of notification,
• whether the escalation should be performed again, and if so, how soon,
• whether the task priority should be increased during the escalation.
Life cycle of an escalation
Here is a brief description of the stages that a typical escalation will go through.
1. An instance of a task is created and, if it has an associated escalation, it remains inactive until the task
reaches the activation state.
2. When the task reaches the activation state, all associated escalations are initialized with the starting of
the Escalate within timer.
3. When a timeout occurs, the escalation state is changed to waiting, and the system checks to see if the
expected task state has been reached. If the task has reached or passed it, the escalation state is
changed to superfluous. If the expected state has not yet been reached, the escalation state is changed
to escalated, and the escalation action is invoked, and one of the three possible actions occur (work
item, e-mail notification, or event handler notification).
4. The escalation is repeated according to the Repeat notification every value.
5. The escalation's priority is increased according to the Increase task priority value. The priority can be
increased repeatedly if an auto-repeat duration is set.
Chained escalations
A chain of escalations is a series of escalations with the same activation state that are processed sequentially so
that only one is active at any one time. The wait duration for each of the escalations in a chain is cumulative. That
is, the timer on the second escalation in a chain will not start until the first escalation has timed out. This prevents
escalations that are further along in the chain from timing out before the ones at the beginning. Also, keep in mind
that an escalation with an expected state of end, cannot precede another escalation. Such a situation would
never escalate, and you will receive a validation error if one exists in your diagram.
This is a screen capture of an escalation chain built on a ready state.
Parallel escalations
Parallel escalations are one or more escalations that are processed at the same time as opposed to sequentially.
Each of the escalations has the same activation state but, in contrast to a chained escalation, its wait duration
fires independently, and any one of them can have an end state as the expected state.
This is a screen capture of an parallel escalation built on a subtask state.
Example
To see an example of a human task escalation that you can build and run yourself, go to
http://publib.boulder.ibm.com/bpcsamp/index.html, and click Human Task features > Escalation.
Assigning people to escalations
Use the Assign People tab of the properties area to specify the group of people that is notified should this
escalation be executed.
Use this field to choose the criteria for a query that will return the group of people who share the same
permissions and will receive a new work item as notification that an escalation has fired.
The people assignment criteria that you see is determined by the contents of an XML file. This people
assignment criteria file is a definition of queries to the user repository and the staff members that are
resolved by those queries. See related tasks for how to change your people directory or modify the
people assignment criteria.
Test
Click Test to choose a server, and check to see if the query will return an appropriate result. This button
is available for all people assignment criteria except everybody and nobody, and requires at least one
running Process Server to be defined in Servers view and all mandatory fields filled in.
If only one person qualifies, claim task automatically
This check box is only available when the Potential Owners authorization role has been selected.
Enable it in cases when your people assignment query returns a single person, and you want this
specific user to be automatically assigned the task in question. When the check box is clear, the user
must actively claim the task.
Parameter table
Use this table to specify details like a group name and thus define the people that will be assigned by the
selected criterion at runtime. The value of the parameter can be changed by clicking into the value field
and editing it, the names are all predefined in the XML file that contains your people assignment criteria
definitions, and those that are mandatory will be marked with a "*". You can use context assist for some
of the values if you see the icon of a light bulb appear when you click the field. Press Ctrl+Space to
launch context assist.
You can also specify replacement variables, and use parts of the task input or output message as values
for the parameters. See replacement variables and context variables for more information on this
Customizing an escalation e-mail notification

You can use an e-mail message to notify a staff member that they have a work item in the form of an escalation.
Before you can customize the e-mail notification, it is necessary to configure the WebSphere® Process Server as
described in Sending e-mails for escalations or Sending e-mails for escalations if you have WebSphere Process
Server installed.
To customize the e-mail message, proceed as follows:
1. Create an escalation for your human task.
2. In the Details page of the properties area select E-mail as the Notification type. The E-mail message
field becomes active with the default message chosen automatically as shown here.
3. To create a new e-mail message, select New from the E-mail message drop down list.
4. To make changes to an e-mail message, first select it from the E-mail message drop down list, and click
Edit. The E-mail editor will launch, as shown in this image:
To configure the e-mail message, proceed as follows:
a. Give the e-mail message a name and a subject. To insert a human task variable into the text of
the subject, click Add Variable and select an appropriate variable from the list. In the editor, the
variable will appear between "%" characters, but will be replaced when it is evaluated in the
runtime environment when the email is sent.
b. Compose your message in the E-mail window in HTML language. When you enter a "<"
symbol, a list of possible HTML code tags will appear along with a description of what that tag
would be used for. Click the tag you want to use, and hit enter. As before, you can insert a
human task variable by clicking Add Variable.
Tip: If you are composing a brand new e-mail message, and are unsure of how to proceed, take
a look at the existing default message for ideas.
c. To see what your e-mail message will look like when it is delivered, click the Preview tab.
Notifying an event handler of an escalation

You can use customized notification event handlers within your application environment to deal with escalations
in your human task model.
To implement notification event handlers, you can use either the NotificationEventHandlerPlugin interface, or you
can extend the default com.ibm.task.spi.NotificationEventHandler service provider interface (SPI) implementation
class.
To configure an event and add it to your business application model, follow these instructions.
1. Implement an event handler according to the steps below. You can package the implementation class of
the com.ibm.task.spi.NotificationEventHandlerPlugin into the same application as your human task, or
you can put it into a dependent utility project. This section describes how you add the notification event
handler implementation class to the same application as the human task.
a. In the Java™ perspective, right-click your Java module, and select New > Class.
b. In the New Java Class wizard, choose a Package and a Name for your new Class and click Add
beside the Interfaces field.
c. In the Implemented Interfaces Selection window, begin typing notif until a list of matching
types appear, choose NotificationEventHandlerPlugin, and click Finish.
Here is an example of an implementation of the escalationNotification method.
public void escalationNotification(Task task, Escalation escalation) {
System.out.println("--- Notification event received: " +

DateFormat.getDateTimeInstance().format( new
Date(System.currentTimeMillis())));;
if(task != null)
{
System.out.println("Task template name: " + task.getTaskTemplateName());
System.out.println("Task name: " + task.getName());
System.out.println("Event handler name: " + task.getEventHandlerName());
System.out.println("Is escalated: " + task.isEscalated());
}
else
{
System.out.println("Task is null");
}
System.out.println("Notification event received.");
if(escalation != null)
{
System.out.println("Escalation name: " + escalation.getName());
System.out.println("Escalate within: " +
escalation.getDurationUntilEscalated());
System.out.println("Repeat notification every: " +
escalation.getDurationUntilRepeated());
}
else
{
System.out.println("Escalation is null");
}
System.out.println("--- End notification event");
2. Create a service provider configuration file for the plug-in. This configuration file provides the mechanism
for identifying and loading the plug-in, and conforms to the Java 2 service provider interface
specification.
a. In the META-INF/services/ directory of your JAR file, create a file with the name
com.ibm.task.spi.plug-in_nameNotificationEventHandlerPlugin, where plug-
in_name is the name of the plug-in. For example, if your plug-in is called HelpDeskRequest
(event handler name) and it implements the
com.ibm.task.spi.NotificationEventHandlerPlugin interface, the name of the
configuration file is
com.ibm.task.spi.HelpDeskRequestNotificationEventHandlerPlugin.
b. In the first line of the file that is neither a comment line nor a blank line, specify the fully qualified
name of your plug-in class. For example, if your plug-in class is called MyEventHandler, and it
is in the com.customer.plugins package, then the first line of the configuration file must
contain the following entry: com.customer.plugins.MyEventHandler.
3. Declare a notification event handler for your task as described here:
a. In the human task editor click the Details tab.
b. In the Event handler name field, enter a name for your notification event handler.
Note: This name is not the name of the implementation class, it is the name that you gave the
event handler.
c. Click Save.
4. Add your plugin to your application:
a. Switch to the Resource perspective.

b. In the Navigator, expand your business integration project.
c. In the META-INF folder, create a new folder services.
d. Right-click the services folder and select New > File .
e. In the File name field of the New File wizard, enter
com.ibm.task.spi.EventHandlerNameNotificationEventHandlerPlugin Where
EventHandlerName is the event handler name you have specified for your task.
f. Click Finish. The editor opens for the new file. In the editor, add a line with the fully qualified
class name of your implementation class: bpc.samples.plugin.EscalationNotificationPlugin.
g. Click Save.
5. Specify an escalation with a notification type Event:
a. Switch to the Business Integration perspective and open your task in the human task editor.
b. In the Escalation settings section, select the escalation.
c. Click the Details tab.
d. Configure the escalation as needed (for help, see the Related tasks section below). For
Notification type, choose Event from the list of available options.
e. Save your work.
Example
To see an example of an escalation that uses a customized notification event handler, go to
http://publib.boulder.ibm.com/bpcsamp/index.html, and click Human Task features > Escalation.
Ad-hoc collaboration
When you create or modify a task in the user interface of the runtime environment, you can dynamically define a
task either as a subtask or a follow-on task.
Ad-hoc tasks and transferred work items are created "on-the-fly" in the runtime environment, usually because of
new circumstances that did not exist when the task was initially developed. Such tasks can be used when the
application is stand-alone, and when the task is either to-do or collaboration.
You can use WebSphere® Integration Developer to allow for two types of ad-hoc tasks (the subtask and the
follow-on task), as well as the transferred work item (see below). To create a pure ad-hoc task, you would use the
Human Task API to define a dynamic Human Task template, deploy this to an application server, and then start
an instance of it. For an example of such an ad-hoc task, go to http://publib.boulder.ibm.com/bpcsamp/index.html,
and click Human Task features > Ad-hoc Human Task.
• Subtasks
• Follow-on tasks
can assign the remaining work to somebody else in the form of a follow-on task.
Subtasks
Typically, staff members who have already claimed a task can create a subtask when they can't complete the
work by themselves. A subtask can be derived from an inline or stand-alone to-do task, as well as a collaboration
task, and can be realized either as a stand-alone invocation or a collaboration task.
The life cycle of a subtask usually looks something like this:
1. The staff member claims the parent task in the runtime environment through a user interface.
2. The staff member then initiates a subtask from an existing definition, and provides an input message for
the subtask.
3. The parent task enters the WAITING_FOR_SUBTASK state, and will remain there until all of its
subtasks, are complete. Subtasks cannot be deleted unless the parent task is first deleted. If the parent
task suspends, resumes, terminates, or expires, all subtasks will be as well.
4. The subtask will enter the work queue, where it can be claimed by anyone in the authorized group.
5. When all subtasks have entered an end state, the parent task can then be completed.
When you are creating the human task definition, you can decide if the business case justifies the need for the
creation of subtasks, and configure your definition accordingly. To control the creation of subtasks, proceed as
follows:
1. Open your task in the human task editor.
2. In the Details tab of the properties area, configure the Enable subtask creation check box according to
the following choices:
Option Description
Enabled If this check box is enabled, then this human task definition will allow for the creation of
subtasks in the runtime environment.
Cleared If this check box is clear, then users will not be able to delegate portions of this task in the
Option Description
from of subtasks.
Example
To see an example of a subtask that you can build and run yourself, go to
http://publib.boulder.ibm.com/bpcsamp/index.html or , and click Human Task features > Subtask.
Follow-on tasks
In the runtime environment, if a person who claims a task finds that they are not able to complete it, they can
assign the remaining work to somebody else in the form of a follow-on task.
Follow-on tasks can be derived from inline or stand-alone to-do tasks as well as collaboration tasks, and can be
realized as a collaboration or stand-alone originating task. They can also support subtasks, as well as further
follow-on tasks. The input, output, and fault message definitions of the completed and the follow-on task must be
of the same type. The initial task that spawns the follow-on task is called the predecessor task, and in cases
where there is a chain of follow-on tasks, the first task in the chain is known as the head task.
When you are first creating the human task template, you can decide if the business case justifies the need for
the creation of follow-on tasks, and configure your template accordingly. To control the creation of follow-on
tasks, proceed as follows:
2. In the Details tab of the properties area, configure the Enable follow-on task creation check box as
follows:
Option Description
Enabled If this check box is enabled, then this human task template will allow for the creation of
follow-on tasks in the runtime environment.
Cleared If this check box is clear, then users will not be able to delegate portions of this task in the
from of follow-on tasks.
Example
To see an example of a follow-on task that you can build and run yourself, go to
http://publib.boulder.ibm.com/bpcsamp/index.html, and click Human Task features > Follow-on task.
Transferring work items
In the runtime environment, if a person who has claimed a task finds that they are not able to complete it, they
can transfer the work item to another person or group.
When you are first creating the human task template, you can decide if the business case justifies allowing work
items to be transferred, and configure your template accordingly.
The following rules apply:
• Work items assigned to "everybody" cannot be transferred.
• The owner of a task instance can transfer the "owner" work item to a potential owner or an administrator
of the task instance.
• The starter of a task instance can transfer the "starter" work item to a potential starter or an administrator
of the task instance.
o A "starter" work item can be transferred in the expired, terminated, finished, failed, and running
state.
• The originator of a task instance can transfer the "originator" work item to a potential instance creator or
an administrator of the task instance.
• The originator of a task instance can transfer a "potential starter" work item to any person.
o A "potential starter" work item can be transferred in the inactive state.
• The administrator of a task instance can transfer all work items to any person.
o A "starter" work item can be transferred in the expired, terminated, finished, failed, and running
state.
o A "potential starter" work item can be transferred in the inactive state.
o A "reader" or "administrator" work items can be transferred in all but the inactive state.
o A "potential owner" or "editor" work item can be transferred in the ready or claimed state.
o An "escalation receiver" work item can be transferred in the ready, running, or claimed state
.
To control the transferring of work items, proceed as follows:
2. In the Details tab of the properties area, configure the Transfer task check box as follows:
Option Description
Enabled If this check box is enabled, then this human task template will allow for the movement or
work items between staff members.
Cleared If this check box is clear, then users will not be able to delegate work items to other staff
members.
For more information on this topic, go to Managing work assignments or Managing work assignments if you have
WebSphere Process Server installed.
Versioning human tasks
You can create new versions of your human task, so that multiple versions of those same tasks can co-exist in a
runtime environment.
Here are some possible examples of when you would create a version of a human task:
• In the likelihood that your human task will need to be modified over time. In such a case, you will want
the existing callers to be able to seamlessly pickup the newest version of the task the moment it
becomes effective.
• You have a solution where multiple versions of the same human task must coexist. Although the solution
as a whole cannot be uninstalled and reinstalled, you will need to be able to deploy new versions of the
task in such a way as to ensure that existing instances remain undisturbed, and are allowed to run their
course.
To create a version of a human task, it is important that you plan ahead. Specifically, you will need to consider
how the client interacts with the task, and how the task itself is set up. To allow for seamless introduction of new
versions, it is a good idea to anticipate the need ahead of time, and set things up in the manner described in the
associated topics.
Differentiating human task versions

Put simply, a version is a copy of an existing task that is slightly different from the original. To understand how
this differentiation takes place, you must first understand that a version of a human task is identified by the
following properties:
1. same component name
2. same target namespace
3. different valid-from date
In addition, it is important to note that interface specifications of different versions need to remain the same.
Of critical importance, the two versions must have the same name and namespace, but have different valid-from
dates. In addition, they must also have the same interface. In other words, it is with different valid-from dates that
multiple versions of the same task are distinguished. In practice, the runtime engine could use a new version of a
task that is set to become valid today, even if an older version of that task was still being used.
Invoking a human task
When a client invokes a task, that client can be configured either to choose a specific version each time, or to
pick up the currently valid version of the task. This is the basic concept behind early binding and late binding.
With early binding, a client is hard-wired to a task in such a way as to force a continued relationship between the
two of them, even if another version of the task becomes available. In contrast, with late-binding the relationship
between the client and the task is dynamic in that it is resolved in the runtime environment.
In other words, if the caller instantiates a task using early binding, a specific version of the task is used to create
that instance, and if they use late binding, the currently valid version of the human task is used.
Clients that want to use early binding must use SCA wiring.
Clients that want to use late binding can do it in one of the following ways:
• Using the Business Process Choreographer APIs (generic EJB API or generic Web Services API)
• Using the generated clients (JSF, Forms)
For more information
See the whitepaper on developerWorks® called Versioning and dynamicity with WebSphere® Process Server
and the podcast called WebSphere Technical Podcast series: SOA programming model, Part 5: Managing
change in Web services components and applications
Example
To see an example of a versioned process that you can build and run yourself, go to
http://publib.boulder.ibm.com/bpcsamp/index.html, and click Process modeling techinques > Versioning.
Although this example is not specific to human tasks, it can still help you to become more familiar with the
concept of versioning.
Creating a version of your human task
This section explains how to create a new version of your human task whose binding may be
dynamically resCreating a version of your human task
This section explains how to create a new version of your human task whose binding may be dynamically
resolved in the runtime environment.
To create a new human task, you begin by creating a new module that contains a new version of your task, and
install it in the same manner as the original.The runtime engine is able to recognize that the new task is actually a
more recent version of the other, and will select it over the older one. These steps assume that you have already
created the human task that you seek to version.
1. Make a copy of the module that contains the original version of your human task as follows:
a. In the Business Integration view, right-click the module that contains the human task and
select Copy.
b. Right-click on any white-space within the same view, and select Paste.
c. In the Copy Module window, change the module name as necessary (perhaps by adding a suffix
that indicates the version), and click OK.
d. Save the file. The new module name appears in the assembly editor.
2. Configure a date from which the copied human task will be valid, as follows:
a. In the Details tab of the properties area, enable Date (UTC) when task becomes valid. If this
check box is clear, then a valid-from date is implicitly specified so that the task becomes valid as
soon as the module is installed.
b. Configure the calendar fields to specify the date and time when the runtime engine is allowed to
create instances of this task. Click the calendar icon to choose a specific date, and then use the
remaining fields to configure the precise time.
Calendar values are represented in Coordinated Universal Time (UTC).
3. Save your work.
4. You can deploy this new module as you would any other module.
Example
To see an example of a versioned process that you can build and run yourself, go to
http://publib.boulder.ibm.com/bpcsamp/index.html, and click Process modeling techinques > Versioning.
Although this example is not specific to human tasks, it can still help you to become more familiar with the
concept of versioning.
• solved in the runtime environment.
Setting up a user interface for your human task

The human task editor provides various client types that you can use to customize a user interface through which
users can interact with the tasks in the runtime environment.
A client delivers task-related information to a staff member in the form of an interactive application. You can
generate various types of clients for your human tasks, and use the generated clients to customize a user
interface through which users can interact with the tasks in the runtime environment. Or, you can use generated
clients to quickly demonstrate a human workflow, for example as a proof of concept or prototype.
Using the client generator, you can generate clients for both stand-alone human tasks that exist independently of
a business process, and inline human tasks that have access to the execution context a business process. You
can create one client for all the human tasks in a module, or generate one client per task. You can also generate
one client for all human tasks in multiple processes or modules.
You may wish to provide a choice of user interfaces or to provide clients with different functionality for different
roles or simply to provide basic clients that can be re-used with a different look and feel.
User interfaces for your human tasks can make use of several types of technology. The human task editor
provides a User Interface section in order to add technology specific configuration settings to a human task. For
some of the client technology types included by default, the corresponding property page allows the creation or
selection of visualization files that match the Business Object data structure used by the human task.
There are two routes to creating user interfaces for your human tasks. A human task user interface wizard can be
used by selecting one or more human tasks in the Business Integration folder view. The wizard allows you to
rapidly generate a variety of user interfaces. The second route is to use the human task editor. There is a section
on the canvas called User Interface and you can add user interface settings to your task using the "+" button.
Some of the property pages where you specify the UI settings offer the possibility to create visualization artifacts
for the selected interface technology. Most situations can be arrived at using either of these two methods but
there are some considerations you should make before taking either route:
• If you want to create user interfaces for more than one task, the wizard is the more efficient choice, since
you can create user interfaces for multiple tasks, even if they are not in the same module.
• If you want to simply create a Lotus Form to directly interface with this task in this module, for example to
use the form in Business Space, use the human task editor. For Lotus Forms and JSF, the wizard
creates not only the generated artifacts but also stand-alone web applications that allow you to readily
use the generated artifacts.
• If you want to work in Business Space but do not have access to Lotus Forms, you can create an HTML-
Dojo user interface and use it in Business Space.
• If you want to use an existing Lotus Form for your user interface you must use the human task editor and
select the Lotus Form in the Properties view.
Note: The structure of the Lotus Form must match the business object structure of the interface used by
the human task. The simplest way to ensure this, is to create the human task using the existing Lotus
Form as a template. Select File > New > from Patterns to launch the New from Pattern wizard. Using
this wizard create a business process to contain the generated human tasks, create the human tasks
and select the Lotus Forms, the structure of which will be used to generate the interface used by the
human task.
You want to use the Lotus Forms technology to visualize a human task, you have several routes to achieving this
goal. One option would be to specify or generate a Lotus Form on the Lotus Forms User Interface Settings
property page, (through the human task editor). In so doing, you can directly use the form in Business Space to
work with the task. Another option would be to use the UI generation wizard to create a stand alone web
application. The wizard checks, if a Lotus Form has been specified on the corresponding property page. If a form
has already been configured, the wizard makes the generated application use it, otherwise it creates a new form.
• Before you begin: Client types and prerequisites

These are the types of clients that you can configure or generate for your human tasks. This topic
contains useful information that you may need before you proceed to generate your client.
• Defining user interfaces for a human task

In the Human Task editor, you can select the type of client, and configure properties such as inputs and
outputs for the client. You can specify existing configurations, or define new ones. You can then
generate a client.
• Generating HTML-Dojo pages or Lotus Forms for Business Space

.
• Generating Lotus Forms clients

Generate a client for your human task or process based on forms that you specify in the User interface
settings.
• Generating WebSphere Portal portlets

A portlet is a reusable Web module that runs on a portal server. In the human task editor, you can
specify a portlet as a client.
• Generating JSF clients for your human tasks

You can generate a client either from a module, a business process, or a human task.
• Customizing clients
You may need to customize the user interfaces to your human tasks. Information is provided for each
type of human task client.
• Deploying a generated client to an external runtime environment

After generating your client you have several choices for how to deploy it to the runtime environment.
Before you begin: Client types and prerequisites

These are the types of clients that you can configure or generate for your human tasks. This topic contains useful
information that you may need before you proceed to generate your client.
Client type Description Prerequisite
You can create an HTML file to be used

Business Space Business Space is a new client platform as a part of the Business Space user
powered by through which a user can interact with an interface using WebSphere Integration
WebSphere® instance of a human task in the runtime Developer, but it can only be deployed
environment. to, and used in WebSphere Modeler
Publishing Server, WebSphere Business
You can configure the visualization of Monitor, or WebSphere Process Server.
this user interface using an HTML/Dojo
file or a Lotus Form. When ported into If you intend to deploy Lotus Forms to
WebSphere Process Server, the Business Space, you will also need all
information in the HTML/Dojo file or the prerequisites associated with Lotus
Lotus Form will appear in the Task Forms, but note that you do not need the
Information Widget area of Business Lotus Forms Server API.
Space.
For more information on Business

Space, go to the IBM® WebSphere
Business Process Management
information center, and search for
Business Space.
IBM Lotus® Lotus Forms allows you to easily When you install WebSphere Integration
Forms integrate electronic forms with human Developer, you have the option to install
tasks. You can generate a client based Lotus Forms API, Lotus Forms Viewer,
on forms that you specify in the User and Lotus Forms Designer. You will
interface settings. need Lotus Forms Server API to process
a client on a server, Lotus Viewer to
You can deploy a Lotus Forms client view a client and Lotus Designer to edit
directly or you can present the form as a form.
user interface in Business Space. See Installing optional software and
documentation for information on
installing these Lotus products.
Important: Please note that, before you
can deploy this user interface to a
runtime environment, you will need to
install the Lotus Forms Viewer and the
Lotus Forms Server API on each
machine where the client will get
deployed (this includes the WebSphere
Test Environments and the WebSphere
Process Server).
If you intend to deploy your Lotus Forms

to Business Space, you will also need all
the prerequisites associated with
Business Space, see above. However, if
you intend to use your Lotus Forms in
Business Space you do not need to
have the Lotus Forms Server API
installed.
WebSphere Select the page on which the portlet will In order to generate portlets, you need
Portal portlet be placed in the page hierarchy of IBM the Portal Toolkit. When you install
WebSphere Portal by setting properties WebSphere Integration Developer, you
in the User interface settings. have the option to install the Portal
Toolkit.
Or, you can generate a portlet using the
portlet generator.
JavaServer The client generator for human tasks The JSF client generator is included in
Faces (JSF) generates a JSF-based web client that is WebSphere Integration Developer.
client useful for quickly prototyping human task
processes or as a starting point for
creating a custom client. The JSF client
is generated based on data described in
the interface that the human task
implements, and does not need any
input defined in the User interface
settings.
Business This is the standard client that is No prerequisites. Included in

Process delivered with this product. With this WebSphere Integration Developer.
Choreographer client, the task is delivered to the staff
explorer member via an HTML-based web page.
The look and feel of this web page is
determined by the JSP values that are
specified in the User interface settings.
You can modify these values as needed.
Defining user interfaces for a human task

In the Human Task editor, you can select the type of client, and configure properties such as inputs and outputs
for the client. You can specify existing configurations, or define new ones. You can then generate a client.
To define a user interface for a human task, proceed as follows:
1. Launch your human task in the editor.
2. Under User interface settings, choose the type of client.
3. In the Properties page, configure the client as follows:
Option Description
Business Space Use the Context root and HTML File fields to specify the location of the HTML
powered by file that contains the visualization of the user interface. Business Space uses
WebSphere® these two fields to compose the URL from which your HTML file will be uploaded
using the following format: http://localhost/<contextroot>/<pathAndFile>
If no HTML file exists, you can click New to create one. In the New HTML file
window, you can choose an existing Web Project in which to place the new
Option Description
HTML file or press New Web Project to create a new one. You can also create
folders within the Web project to better organize your files. To do this, select the
Web project, or one of the folders nested beneath it, and click New folder
Note: Modify the HTML file using a text or HTML editor.
For more information on Business Space, go to the IBM® WebSphere Business

Process Management information center, and search for Business Space.
IBM Lotus® Select whether to store your Lotus Forms as part of the current module or in a
Forms client Web project. The default behavior is to save the form as part of the module, but if
you want to use a form that already exists outside the module, or you want to
create a Lotus Form that you will use outside the module then select Web project.
Specify the input and output Lotus Forms for your client. If your input and output
data is identical, the input and output forms must also be the same.
The window has a different appearance depending on the choice of module or

Web project, but your actions remain essentially unchanged:
o Click Browse to select from a list of available forms, or

o Click New to generate a form based on the data used by the
service interface of the human task.
If no input or output forms are specified in this page, the client generator will use
the service interface data to create the forms.
Note: If you want to edit a form, install Lotus Forms Designer. See Installing the
Designer.
Select whether to save the Lotus Form automatically whenever the human task is
saved or completed. Note that this setting only applies to Lotus Forms clients, if
you deploy your Lotus Form to Business Space the form cannot be persisted.
Portal client Every human task must be identified by a unique name when it runs as a portlet
on the WebSphere Portal Server. Later you must create a page in the Portal
Server of the same name as this unique name and place this generated portlet
into it.
In the Properties details page, proceed as follows:

o Provide a value for Unique Name. If you leave this field empty
WebSphere Integration Developer will generate a unique name when the
portlet is created.
o Select the type Page or Page definition.
o Click Create Portlet to generate a portlet for this task.. In the
Portlet Generator Settings page, specify the project and select
WebSphere Portal 6.0 stub as the target runtime. If the WebSphere
Portal target runtime is not available in this dialog, you have not installed
the required Portal Toolkit. See Installing WebSphere Portal Version 6.0.
Note: Create Portlet will generate a portlet for this human task. If you
want to generate a portlet for multiple human tasks, use the client
generator.
Business With this option, the task is delivered to the staff member via an HTML-based
Process web page. In the JSP definition table, specify the input and output JSPs.
Choreographer o Click Add.
explorer o On the JSP definition page, select the JSP type. In the Apply
Option Description
to field, select the role that will see the JSP. You can then create a new
JSP, or browse to an existing one, and use the Context root field to
define the runtime path to the JSP.
o If you have WSDL faults defined in your interface, you can
select a Fault message JSP as the JSP type, and then select the fault
that will trigger it.
If no JSPs are specified, the standard client is used.
4. The JSF custom client is not included in this list because the client generator does not require any
properties to be configured in order to generate the client.
5. If you are using Business Process Choreographer explorer, you do not need to generate a client, as a
standard client is provided for it.
Next, generate your client.

Generating HTML-Dojo pages or Lotus Forms for Business Space
.
To generate a HTML-Dojo pages or Lotus Forms interface for your human task to work in Business Space,
proceed as follows:
1. In the Business Integration view, right-click the human tasks for which you want to generate a user-
interface, and select Generate Human Task User Interfaces. To generate a client for tasks in different
modules, select those modules in the business integration view by holding the Ctrl key while you select
each one. The User Interface Wizard for Human Tasks launches.
Note:
o If the generated client is intended to be able to start a process, then this process must have a
human task defined for the initial receive activities, or you must have another initiating task on
the assembly diagram wired to the process .
o If the human task is not represented on your assembly diagram, then you will get a warning
message.
o If a humans task contains an error of any kind, the task will not be listed in the wizard. A warning
message will be shown.
2. On the Client Generator Selection page, proceed as follows:
a. In the Generator type field choose HTML-Dojo pages or Lotus Forms for Business Space.
b. Use this list to choose the human tasks for which you want to generate the client. Expand the
tree until you find the required human tasks, and then select the associated check boxes.
2. Select how to display the human task in Business Space. Select HTML or Lotus Forms and indicate
whether you want to overwrite existing interface settings by selecting the associated check box. If you
selected HTML you also need to indicate the Web project where the HTML pages will be saved. Click
the Browse button to see a list of Web projects. In the resulting window you can choose from the list of
Web projects, create a new folder within an existing Web project or create a new Web project.
3. Click Finish
Generating Lotus Forms clients

Generate a client for your human task or process based on forms that you specify in the User interface settings.
The client generator will use the input and output forms that you specified in the human task editor. If no form is
specified, the client generator creates a form based on the service interface of the human task. For each task,
you can choose to generate either a Lotus® form or a JSP page to render the input and output message of the
human task in final client.
To generate a Lotus Forms client, proceed as follows:
Note:
message.
a. In the Generator type field choose Lotus Forms client application.

2. On the IBM Lotus Forms client configuration page, proceed as follows:
a. In the Name of dynamic web project field, enter the name of the web project in which the
generated client will be stored.
b. In the Company logo field, you can specify the file location of a graphic file containing a
company logo. This logo will appear as a banner on the top of the generated client's web page.
You can browse either to a GIF or JPEG file. If your image has a height higher than 60 pixels,
then it will automatically be shrunk to fit the space available. You can adjust the height of your
logo in the page Banner.jsp of the generated client. The background color of the banner is
defined in the style sheet styles.css, refer to class .Banner. The CSS file is located in the
generated web project in WebContent\theme\styles.css
c. In the Client location area, you have two choices. Select Generated client and related
processes and tasks reside on the same server (Local client view) if one server will be
used to deploy both the generated client and the related processes and tasks on the same
WebSphere® Process Server. Select Generated client and related processes and tasks
reside on different servers (Remote client view) if two or more servers will be used in the
same cell, and your generated client will be deployed on one server, and the related processes
and tasks on another. If you are using two or more servers, you will need to provide the IP
address of the server and the bootstrap port, the required format is:
iiop://REMOTE_SERVER_IP:BOOTSTRAP_PORT.
d. In the Style selection area, you can choose from the two styles that are provided for your
generated client, or add your own style file (CSS format). This custom CSS file must reside in a
web project in your workspace. The CSS file can contain your settings regarding color, font size
and style, but these settings have to have proper names since they are used as reference in the
generated client. The best approach is to modify one of the predefined style files of a generated
client (styles-IBM.css or styles-blue.css), and save it as your CSS file. In the Style field, you can
then click Add and Browse to select your CSS file.
e. When you are done, click Next.
3. On the second IBM Lotus Forms client configuration page, you can choose a forms or JSP user interface
for each task. The human tasks are listed under the Forms or Java Server Pages headings. If necessary,
select the human tasks and use the arrow buttons to transfer them to the opposite column.
4. When you are done, click Finish.

Your new client will be generated. Your next step is to deploy it to a runtime environment.
If you refactor a human task that contains a Lotus Forms client, the refactoring behavior depends on the way in
which the form was associated with the task. See related links for more information.
Important: Please note that, before you can deploy this user interface to a runtime environment, you will need to
install the Lotus Forms Viewer and the Lotus Notes® Server API on each machine where the client will get
deployed (this includes the WebSphere Test Environments and the WebSphere Process Server). For instructions
on how to install Lotus Forms into the WebSphere Integration Developer environment, see Installing optional
software and documentation.
Generating WebSphere Portal portlets
A portlet is a reusable Web module that runs on a portal server. In the human task editor, you can specify a
portlet as a client.
Prerequisite:
Before you can generate a portlet in WebSphere® Integration Developer, you must do the following:
• Install the Portal Toolkit. When you install WebSphere Integration Developer, choose to install the Portal
Toolkit. Information on how to set up WebSphere Portal Server to integrate business processes on
WebSphere Process Server can be found in the WebSphere Portal information center .
• Create a Portal Server connection.
• Generating a Portlet
The New Portlet Generator wizard will guide you through the process of creating a portlet within
WebSphere Integration Developer Software Development Platform.
Generating a Portlet
The New Portlet Generator wizard will guide you through the process of creating a portlet within WebSphere®
Integration Developer Software Development Platform.
To generate a new portlet proceed as follows:
Note: If a humans task contains an error of any kind, the task will not be listed in the wizard. A warning
a. In the Generator type field choose Portlet Generator. If Portlet Generator is not presented as
an option, ensure that you have fulfilled all the prerequisites listed in the topic Generating
WebSphere Portal portlets.
tree until you find the required human tasks, and then enable the associated check boxes.
3. On the Portlet Generator Settings page, enter a project name. Click Finish.
4. Now, you will have to manually copy all associated WSDL interfaces and Business Objects into the
generated portlet project. In other words, all WSDL and XSD files from all modules and associated
libraries that are directly or indirectly referenced by tasks that were selected during the user interface
generation need to be copied to the portlet project while maintaining their directory structure (if a WSDL
or XSD is in a subdirectory, this same subdirectory needs to be created in the portlet project as well).
The generation of the portlet can take a while. When the generation is finished, you will see your newly created
portlet project in the Business Integration view, along with a EAR. Your next step is to deploy it to a runtime
environment.
Generating JSF clients for your human tasks
You can generate a client either from a module, a business process, or a human task.
To generate a JSF client for your human task, proceed as follows:
Note:
message.
a. In the Generator type field select JavaServer Faces client application.

2. On the JSF client configuration page, proceed as follows:
a. Assign a name to this client in the Name of dynamic web project field.
b. In the Company logo field, you can specify the file location of a graphic file containing a
company logo. This logo will appear as a banner on the top of the generated client's web page.
You can browse either to a GIF or JPEG file. If your image has a height higher than 60 pixels,
then it will automatically be shrunk to fit the space available. You can adjust the height of your
logo in the page Banner.jsp of the generated client. The background color of the banner is
defined in the style sheet styles.css, refer to class .Banner. The CSS file is located in the
generated web project in WebContent\theme\styles.css.
c. In the Client view area, you have two choices. Choose Local if one server will be used to
deploy both the generated client and the related processes and tasks. Choose Remote if two or
more servers will be used in the same cell, and your generated client will be deployed on one
server, and the related processes and tasks on another.
d. In the Style area, you can choose from the two styles that are provided for your generated
client, or add your own style file. This custom CSS file must reside in a web project in your
workspace. The CSS file can contain your settings regarding color, font size and style, but these
settings have to have proper names since they are used as reference in the generated client.
The best approach is to modify a predefined style of a generated client (styles-IBM.css or styles-
blue.css), and save it in the your CSS file. In the Style field, you can then click Add and Browse
to select your CSS file.
e. When you are done, click Next.
3. On the second JSF client configuration page, you can select the custom properties (as defined in your
business process) that you would like have generated with the client. You can use custom properties as
filter criteria for the "Status" list.
4. When you are done, click Finish.
Your new client will be generated. Your next step is to deploy it to a runtime environment.
For more information about customizing JSF clients, see the white paper Understanding and enhancing the
generated Java Server Faces client for human tasks.
Customizing clients
You may need to customize the user interfaces to your human tasks. Information is provided for each type of
human task client.
You have generated a client for your human task, and you want to customize the user interface that your staff will
see.
The precise steps you need to take to customize your client depends on the type of client you have generated.
1. To customize a JSF client:
There is a very detailed description of modifying JSF task clients available in the white paper
Understanding and enhancing the generated Java Server Faces client for human tasks.
2. To customize a WebSphere Portal portlet:
The recommended way to customize a WebSphere Portal portlet client is to add additional portlets to the
portal. This is a simpler process than modifying the generated portlet. Creating and deploying additional
portlets is described in the WebSphere Portal information center for details.
3. To customize a Lotus Forms client:
WebSphere Integration Developer can generate a complete business process with all of the required
interfaces, business objects, and human tasks based on existing Lotus Forms. Although these artifacts
match the forms as much as possible, you might still need to perform some modifications to make the
client perform optimally. Customization involve modifying the generated business object to better match
the Lotus Form, or optimizing the created interface.
More information on modifying a Lotus Forms client can be found in the white paper Integrating Lotus
Forms and WebSphere Integration Developer.
Rather than generating a Lotus Form client, you can use an existing Lotus Form. The Lotus Forms
information center describes in detail how to design Lotus Forms.
Deploying a generated client to an external runtime environment

After generating your client you have several choices for how to deploy it to the runtime environment.
• Deploying the client: exporting to a deployment file

Deploy your client to a runtime environment by exporting the client to a defined deployment file and
installing that file on the runtime server.
• Deploying a generated client to a test environment

Deploy your client to a runtime environment by defining a server and then using the client-specific
deployment mechanism.
• Deploying a generated client to WebSphere Portal Server

After generating and exporting a client to run as a portlet on portal server, the next steps are to prepare
the Portal Server to work with the generated portlet and to install the portlet on the portal server.
Deploying the client: exporting to a deployment file

Deploy your client to a runtime environment by exporting the client to a defined deployment file and installing that
file on the runtime server.
Your choices for deployment depending on what sort of client your are working with. Choose from one of the
options described below:
Parent topic: Deploying a generated client to an external runtime environment
Deploying HTML-Dojo pages or Lotus Forms for Business Space
To deploy a HTML-Dojo or a Lotus® Forms client to Business Space, perform the following steps:
1. If you have not already done so, generate a user interface for your human task. The files that you need
to deploy to Business Space are generated automatically as part of the client generation.
2. Export the generated client files into a WAR file as follows:
a. In the business integration view right-click the Web project in which you generated your client,
and select Export > WAR file from the list.
b. In the WAR export window, identify the Web project and provide a Destination where your
WAR will be stored and click Finish.
3. Install the WAR file into Business Space, and you will be able to start the client.
Deploying a JSF or a Lotus Forms client
To deploy a JSF or a Lotus Forms client, proceed as follows:
1. If you have not already done so, generate a user interface for your human task. The
ClientNameEAR.ear file is generated automatically as part of the client generation. In addition, the
ProjectNameApp.ear is also created for your module, and contains the human tasks.
2. Export the generated client files into an EAR file as follows:
a. In the business integration view right-click your ClientNameEAR, and select Export > EAR
from the list.
b. In the EAR export window, select an ClientNameEAR name, provide a Destination where your
EAR will be stored and click Finish.
3. Install these two EAR files on your server, and you will be able to start the client.
Deploying a portlet
To deploy a portlet, proceed as follows:
1. In the business integration view right-click your portlet project, and select Export > WAR.
2. In the WAR export window, select a WAR file name, provide a Destination where your WAR will be
stored and click Finish.
3. Install this WAR file on your server, and you will be able to start the client.
Deploying a generated client to a test environment

Deploy your client to a runtime environment by defining a server and then using the client-specific deployment
mechanism.
To deploy your generated client to a test environment, follow these instructions.
1. Click the Server tab in the properties view. If this is not open yet, then click Window > Show View >
Servers.
2. Right-click the server that you intend to deploy your client to and select Add and Remove Projects from
the list.
3. In the Add and Remove Projects window, select the generated Client EAR project that you created, and
click Add.
4. Click Finish.
5. Invoke the client. You can start the client in either of the following ways:
a. With an external browser:

 If the security is disabled, go to: http://localhost:9080/webProjectName (the
hostname and port number might vary depending on your server configuration).
 If the security is enabled, go to https://localhost:9443/webProjectName.
b. Using WebSphere® Integration Developer:
i. Change to the Web perspective

ii. Open the folder with the name of your Web project, and then open the folder
WebContent.
iii. Right-click Index.jsp, and select Run > Run on Server
A browser window opens.
Deploying a generated client to WebSphere Portal Server
After generating and exporting a client to run as a portlet on portal server, the next steps are to prepare the Portal
Server to work with the generated portlet and to install the portlet on the portal server.
1. Installing a generated portlet

Installing the generated Portlet on the WebSphere® Portal Server makes it available to portal users.
2. Creating Task Page Definitions

Create the new task page definitions for each task processing Portlet. This allows you to claim each
Portlet as a task from a list in the MyTask Portlet.
3. Adjusting the Unique Name for the Task Page

You have to change the unique name of the Task Page to be identical to the unique name you gave the
Human task in the User Interface settings of the Human Task Editor. This allows the MyTask Portlet to
know which page it must hand off the task to.
4. Using the My Task portlet to run a Human Task from the WebSphere Portal Server
The My Task portlet displays the human task instances on the portal server. All potential owners can
claim a task that is displayed in the My Tasks portlet to indicate that they will work on it.
Installing a generated portlet

Installing the generated Portlet on the WebSphere® Portal Server makes it available to portal users.
To install the portlet, proceed as follows:
1. Log into the portal site using an ID with sufficient access rights to install a portlet.
2. Under Portlet Management in the navigation tree, click Web Modules. Alternatively in the Product
Links portlet you can choose Administration > Portlet Management > Web Modules.
3. Click Install.
4. Enter the location of the WAR file or click Browse to find the location of the file to install.
5. Verify WAR file info and click Finish to install the WAR file.
6. Once it is installed, you will then need to add the BPELib library to the generated portlet as follows:
a. Launch the IBM® WebSphere Portal administrative console.

b. Go to Applications > Enterprise Applications > your_portlet_module > Libraries, and click
Add.
c. Select BPELib, click Apply, and save your changes.
After the installation has completed, a message appears at the top of the screen indicating a successful
installation. If there are any problems during the process, an error message appears in the Manage Web
Modules page. Click the View Details link to examine the error log.
Creating Task Page Definitions
Create the new task page definitions for each task processing Portlet. This allows you to claim each Portlet as a
task from a list in the MyTask Portlet.
1. Choose Administration > Portal User Interface > Manage Pages. From the Select Search Type
combo box choose Title starts with and type “task” into the Search input field. Press Search.
2. The title Task Page Definitions will be displayed. Click the link Task Page Definitions
3. Click New Page. Type a title into the Title input field, note your title for the next task and press the OK
button. You will place the generated Portlet on the new Task Page Definition. The Portal Server
automatically generated a unique name. In a later step we will adjust this unique name.
4. From the Select Search Type combo box choose Title starts with and type “task” into the Search input
field. Press Search.
5. Click the Edit Page Layout button (this is the button with the pen symbol) for your page.
6. On the Edit Layout page press the Add portlets button.
7. From the Select Search Type combo box choose Title starts with and enter the title of your portlet into
the Search input field. Press Search.
8. 5. Check your portlet and press OK.
Adjusting the Unique Name for the Task Page
You have to change the unique name of the Task Page to be identical to the unique name you gave the Human
task in the User Interface settings of the Human Task Editor. This allows the MyTask Portlet to know which page
it must hand off the task to.
1. Choose Administration > Portal Settings > Custom Unique Names and select Pages from the
Resource type list.
2. To find your page select "Title starts with" from the Search Type list and type your page title into the
Search input field. Click Search.
3. Enter the unique name you defined for your human task. For details see the related topic: Defining user
interfaces for a human task. Click OK. Now the list My pages and unique names displays your page with
its new unique name that must be identical to the unique name you set for the Human Task in
WebSphere® Integration Developer.
Using the My Task portlet to run a Human Task from the
WebSphere® Portal Server
The My Task portlet displays the human task instances on the portal server. All potential owners can claim a task
that is displayed in the My Tasks portlet to indicate that they will work on it.
1. To place the My Task portlet on one of your portal server pages (for example, the "Welcome" page) click
Open Portlet Palette (this is the button with the "+" symbol). A list of available portlets opens.
2. Type "My Tasks" in the Search field and press the Search button. The My Task portlet will be displayed.
3. Simply drag and drop the portlet on your page. Clicking again on Open Portlet Palette (this is the button
with the "+" symbol) closes the portlet list.
4. If your process with human tasks was already started on WebSphere Process Server the tasks will be
displayed.
5. Select the checkbox for a task and click Claim.
6. The task in the My Task portlet becomes a link when it was successfully claimed. Click on the task-link.
The page with the corresponding portlet opens.
Testing human tasks
You can test several aspects of a human task before you deploy the task to the test environment or production
server.
• Testing people assignment criteria

You can test the people assignment criteria that you use in your human tasks to make sure that the
correct people are returned by the people directory that you are using.
• Testing a human-centric process
A human-centric process is one that has been designed in WebSphere® Modeler using human tasks to
model a manual process.
Testing people assignment criteria

You can test the people assignment criteria that you use in your human tasks to make sure that the correct
people are returned by the people directory that you are using.
To test your people assignment criteria, proceed as follows:

1. In your human task, select the role that you want to test.
2. In the Assign People tab of the properties page, click Test. This button is available for all people
assignment criteria except everybody and nobody, when all mandatory fields have a value, and
requires at least one running Process Server to be defined in Servers view.
3. In the Test People Search window, select one of the running WebSphere® Process Servers. If the
people assignment criteria contains one or more replacement variables, the dialog will contain an input
field for each variable.
4. Enter some data that is appropriate to your human task or the process the task is running in.
5. Click Submit. The WebSphere Process Server will be queried. Please note, this might take some time,
and, if the resulting list is too long, only a subset will be returned. The purpose of the test button is to
check if the query works, and not to verify the result set entirely.
Testing a human-centric process
A human-centric process is one that has been designed in WebSphere® Modeler using human tasks to model a
manual process.
This topic provides instructions on how to import such a process into WebSphere Integration Developer in order
to test it.
Before you can begin, you will need to have the exported process in the form of a project interchange file. This
export must have clearly defined staff information that can be used to populate the test people directory. For
more information on how to do this, see Rapid testing of human-centric processes
1. To import the project interchange file:
a. In the Business integration view, click File > Import.

b. In the Import window, select Other > Project Interchange.
c. Browse to the project interchange file, select it, and click OK.
d. Select all of the projects in the zip, and click Finish.
The new module will appear in the Physical Resources view. There will be two administrative scripts.
One will be to populate the people directory, and the other will be to clean that registry once you've
completed your testing.
2. Run the administrative script that populates the test people directory. This will create the test user
account(s) and associated group(s).
a. In the Physical Resources view, expand the new project until you see the Administrative scripts.
They have a PY extension.
b. Right-click your server, and select Run administrative script.
c. Browse to the script and click Run.
The test user entries are created in the registry. To see the user(s) in the Administrative Console, click
Users and Groups > Manage Users. Similarly, to see Groups, click Users and Groups > Manage
Groups.
3. To test the process:
a. In the Assembly diagram, right-click the process and select Test Component.
b. Launch the Business Process Choreographer explorer, and log in as a test user. You will note
that the user's To-dos list will be empty.
c. In the Events page, enter some test parameters, and click the Continue icon, select a
deployment location and click Finish.
d. When the test server is running, return to the Business Process Choreographer explorer, and
check the To-dos list. You should now have an entry that you can complete as needed to test
the process.
4. When you are done your testing, run the administrative script that cleans the test people directory.
Generating documentation of your human task

If you need a synopsis of each attribute of your human tasks, including how they interact with other resources
within the same project, you can create a report using the documentation generator.
A generated document can very quickly provide you with the following:
• a quick understanding of a project or resource
• an overview report about the details of an artifact within a complex project
• the visualization of the relationships and cross references of resources within a project
• a detailed report that can be printed out for certifications
To create documentation for your human task, proceed as follows:
1. In the Business Integration view, right-click your human task and select Generate Documentation.
2. Configure the Documentation Generation wizard according to the instructions in the Generating
documentation topic.
Programming support for human tasks
Additional programming support for human tasks is available through a set of APIs.
Business Process Choreographer provides a set of APIs that are implemented using Representational State
Transfer (REST) Services, and the resulting data returned is in JavaScript™ Object Notation (JSON) format. The
URIs are a set of REST services that access business process and task data.
To view these APIs, follow this link: Business Process Choreographer REST APIs or Business Process
Choreographer REST APIs if you have WebSphere Process Server installed.
Extending human tasks using plug-ins

Business Process Choreographer provides an event handling infrastructure for events that occur during the
processing of human tasks. Plug-in points are also provided so that you can adapt the functionality to your needs.
You can use the service provider interfaces (SPIs) to create customized plug-ins for handling events and the
processing of staff queries.
Information on this topic can be found by following this link: Creating plug-ins to customize human task
functionality or Creating plug-ins to customize human task functionality if you have WebSphere Process Server
installed.
Limitations for human tasks
There are current limitations that you should be aware of when using the human task editor, or when working with
human tasks.
• Due to a limitation in the Business Process Choreographer tag library in WebSphere® Integration
Developer, JSPs generated as human task clients will not be able to accomodate xsd:any, choice and
substitution group constructs out of the box. You will need to use your own custom code using the
Service Data Object (SDO) API in order to work with these constructs. For more information, see
http://www.ibm.com/support/docview.wss?rs=2308&uid=swg21306783.
Customizing behavior with visual snippets

To visually define custom behavior, use the visual snippet editor.
The visual snippet editor displays a diagrammatic representation of the Java™ programming language. Use this
tool to graphically create and manipulate snippets of Java code.
Click on any of the links shown below to learn more about that topic.
• Custom behavior
There are situations when a user has the opportunity to specify custom behavior within the context of
one of the WebSphere® Integration Developer family of tools.
• Visual snippet editor

The visual snippet editor is a diagrammatic programming environment that you use to graphically create
and manipulate Java code.
• Using the visual snippet editor to write Java code

When should you use the visual snippet editor to compose Java code instead of writing it yourself?
• The building blocks of the visual snippet editor

Compose your own visual snippet using a combination of the following building blocks.
• Creating a custom visual snippet

To create a new custom visual snippet, follows these instructions.
• Using inline expressions for simple equations

When you are coding an expression in the visual snippet editor, there are several ways that you can
compose the expression.
• Using mapping service snippets

When you want to transform data in a business object from one format to another using the visual
snippet editor, you can use one of the three mapping service snippets provided.
• Refactoring a visual snippet

When you refactor parts of your visual snippet, dependencies on those parts are automatically and
universally updated throughout the product as a whole.
• Configuring a custom event in a visual snippet

A custom event is a specific business-related message that can be declared in the visual snippet editor
to be emitted in the runtime environment.
Custom behavior
There are situations when a user has the opportunity to specify custom behavior within the context of one of the
WebSphere® Integration Developer family of tools.
The WebSphere Integration Developer family have been designed so that users can compose integrative
business solutions with minimal programming skills. One example of this is the visual snippet editor that you can
use to graphically compose customized behavior as snippets of Java™ code.
Before you start to use the visual snippet editor, you need to understand these key concepts:
• An example of customized behavior
• Business roles and customizing activities
An example of customized behavior
Perhaps you are composing a process in the process editor, and you need to modify your data in a way that the
available activities do not provide. In such a case, you could use the visual snippet editor to create some
customized behavior to make the process do exactly what you want it to do.
There are three different kinds of implementations that you can use within the editor:
Standard visual snippets
These snippets have been predefined for your general use. Their implementation is fixed and cannot be
viewed or modified by the user.
Java visual snippet
Use this snippet to embed a call to an arbitrary Java method directly into your diagram. Visual Java
Snippets can also be used to invoke constructors and access fields.
Custom visual snippets
Use this to create a snippet that captures a specific behavior. It can then be used within other snippets.
Business roles and customizing activities

An activity is unit of work or a building block that performs a specific, discrete programmatic tasks. These
activities can be created and customized using the visual snippet editor, and stored within the existing
libraries. As such, it is possible for activities to be created, customized and ultimately used by several
users of varying technical backgrounds, as the following graphic illustrates:
Figure 1. An example of using the library to avoid the replication of work.
In this example, the first user has extensive technical skills and a sound knowledge and background in
the business in question. This user determines what customized activities are likely to be needed,
creates them, and stores them in a library. The second user is able to easily access and use these
custom activities without having to know why and how they were created. UsiVisual snippet
editor
The visual snippet editor is a diagrammatic programming environment that you use to graphically create and
manipulate Java™ code.
This editor has been designed to make you, the user, feel comfortable and to facilitate your creativity. While you
are designing your visual snippet, think of it as an exercise in how to paint. The white space is called the canvas
and it's where you create your snippet from the objects that you pull from the palette to the left. Below that is an
interactive properties area that changes to display pertinent details about whatever object you currently have
selected on the canvas.
The visual snippet editor is divided into several distinct areas, each with its own individual use.

1. The palette
o The palette is the shaded area to the left of the canvas that houses the objects that you click
and drag onto the canvas to build your snippet.
o
2. The canvas
o The canvas is the white empty area in the middle of the editor that you use it to assemble the
activities to compose your visual snippet. When you click and drag an activity from the palette
onto the canvas, the icon beside your cursor has a plus symbol and you can decide where you
want to drop the activity. When the cursor becomes a crossed out circle, continue moving the
cursor until it becomes a plus sign again.
o Your visual snippet is visually organized on the editor in groups. These groups are composed of
one of more items connected with links, and individuated on the canvas with a group bracket.
When you drop an item onto the canvas, it automatically starts a group until you link to it from
another one.
o The run order in each group flows from left to right as shown in this image.
o
o If there is more than one group in the snippet, each one is processed sequentially from top to
bottom and will finish at the end of a snippet or when a return node is reached.
o
o
3. The expression builder
o The expression builder is a miniature dialogue that pops up when you click on an expression,
and provides prompts that you use to graphically compose your expression.
o
4. The tray
o The tray displays the Inputs, Outputs and Exceptions that are associated with your snippet.
o To create a new input, output, or exception, click the corresponding icon, or to remove one,
highlight it and click the icon.
o Click the black horizontal arrow to collapse or expand the tray.
o
5. The properties area
o This area displays properties that are relevant to the object that is currently selected on the
canvas. Click on the tabs to the left of this view to toggle through the pages. Some pages
display properties in tabular format, and you can add or modify these properties by clicking the
appropriate cell and then interacting with the graphical interface that appears.
o The contents of the page will differ on the selection. In all cases, you can press F1 to launch a
help window and click the link to be taken directly to the product documentation for more details.
6. The visual snippets view
o This area shows a categorized view of all of the existing snippets that are available to you.
o The list of snippets include those in the product's standard library , as well as any existing
custom user-defined snippets . To use one of these snippets, expand the appropriate
category, select the snippet, and then drag it to the location in your composition where you want
it to appear. To launch a user-defined snippet in the editor, simply double-click it in the Visual
Snippet view.
• Visual snippets view: visual snippet editor

This area shows a categorized view of all of the existing snippets that are available.
• Preferences view: visual snippet editor

This topic includes a description of each of the fields in the preferences view of the visual snippet editor.
Visual snippets view: visual snippet editor

This area shows a categorized view of all of the existing snippets that are available.
The list of snippets include those in the product's standard library , as well as any existing custom user-defined
snippets . To use one of these snippets, expand the appropriate category, select the snippet, and then drag it
to the location in your composition where you want it to appear. To launch a user-defined snippet in the editor,
simply double-click it in the Visual Snippet view.
ng this system, there is no reproducing the same work.
Preferences view: visual snippet editor

This topic includes a description of each of the fields in the preferences view of the visual snippet editor.
Launch the preferences view from the main menu by clicking Window > Preferences > Business Integration >
Visual Snippet Editor.
Use the Generate snippet Java files to derived folder setting to control how Java™ files that are generated for
visual snippets are derived to a CVS repository.
By default, the check box is cleared, and custom visual snippets are generated to ,<module>/<folder>.
If you select the check box, the files are instead generated to <module>\gen\src\<folder>, and the derived
flag is set. This flag indicates that these files are derived from other files during a build process, and so therefore
do not need to be kept in a CVS repository because they can be generated at any time.
sing the visual snippet editor to write Java code

When should you use the visual snippet editor to compose Java™ code instead of writing it yourself?
The answer to this is part personal choice, and part skill level.
If you are not familiar with the Java programming language, then this choice is made for you, and you must use
the graphical editor to visually compose expressions that can then be generated into valid Java code.
If you are comfortable coding using Java, then there will be times that you may find it easier to simply type it
yourself, especially for simple code. The biggest advantage of the visual snippet editor for experienced users, is
the fact that the editor will generate a lot of code very quickly, and ultimately save the user a lot of typing.
The building blocks of the visual snippet editor

Compose your own visual snippet using a combination of the following building blocks.
• Inputs
• Output
• Exceptions
• Visual snippets
• Links
Inputs
The inputs define the data that enters the snippet. This data can either be in the form of a Java™ type, a data
type or a business object.
There can be multiple inputs into a snippet.
Output
The output defines the result of the snippet composition. The data that is returned can either be in the form of
a Java type, a data type or a business object.
There can be at most one output from a snippet.
Exceptions
The exceptions indicate what fault handling may be required if the snippet cannot be completed successfully.
There can be multiple exceptions in a snippet.
Visual snippets
Within the context of the visual snippet editor, a visual snippet is a unit of work that performs a specific
programmatic task in order to achieve a larger programming goal. There are several items that can be dropped
onto the canvas from the palette, and each performs a different function.
There are a number of items that can be added to a visual snippet:
• Expression
Expressions carry user-defined values, and pass them into the snippet.
The kinds of values are varied, and the expression can also be visually composed using the inline
expression builder.
• Standard visual snippet
Use this to add a predefined snippet into the editor

When you drop this snippet on the canvas, you will be prompted to choose from a categorized list of
existing snippets. The system provides a number of standard, general purpose snippets that you can
choose from here. Similarly, if you or another colleague has already created custom visual snippets on
this system, they will appear here in the form of custom visual snippets.
• Java visual snippet
Use this to embed a call to an arbitrary Java method or constructor or access a field within the context of
the visual snippet.
When you click this item, the Select a Java Visual Snippet wizard will launch. Browse the existing types
and qualifiers, and then choose an appropriate snippet and drop it onto the canvas.
• Choice control structure
Use the choice control structure to create a branch in your snippet, and direct the processing according
to the Boolean value of the input.
You will embed two separate pieces of code into two separate areas of this control structure. One will be
executed when the input is 'True', and the other when it is 'False'.
• While control structure
Use the while control structure to repeat the same code as long as the input value is 'True'.
You will embed two separate pieces of code into two separate areas of this control structure. The code in
the bottom section is run as long as the input continues to evaluate to 'True'. When the input evaluates to
'False', control moves on to the next object in the snippet.
• For each control structure
Use the for each control structure to repeat the same code for each of the items of a list that is received
as input.
• Repeat control structure
Use the repeat control structure to iterate the same code a number of times. The number of repetitions is
determined by the value that is received as input.
• Try Finally node
Use the Try Finally node to attempt to perform an action ("initial action") and then to perform another
action ("final action"). The final action runs regardless of whether the initial action ran successfully or
caused an exception.
• Throw node
Use this to throw an exception.
• Return node
Use this when you want to return a result from the snippet.
• Comment node
Use this when you want to include a note of some kind in the structure of the snippet. The comment is
text based, and can be used to explain and describe portions of the code to make future modifications
easier.
Links
Links represent the flow of data and direct the sequence in which the processing of the nodes in
your snippet occurs
Creating a custom visual snippet

To create a new custom visual snippet, follows these instructions.
1. In the workbench, switch to the business integration perspective.

2. If you have already created a module, select it in the business integration view.
3. From the main menu, click File > New > Custom Visual Snippet.
4. In the New Custom Visual Snippet window, specify a module, and a name for the new snippet.
5. Expand the Category list, and choose one that is appropriate. This choice will determine where your
snippet will appear in the categorized list in the visual snippet view. Once you choose a category, the
folder name will change to match it.
6. Click Finish to create your snippet.
This creates a snippet, and launches it in a new visual snippet editor. Click on any of the following links to
configure the snippet.
• Adding an input or an output to a snippet

The input defines the data that enters the snippet, and the output specifies the result.
• Adding an exception to a snippet

An exception on the snippet defines what exceptions may occur during the processing of the snippet.
• Working with standard visual snippets

Many types of snippets are available in the editor, and you can use them when composing your own
visual snippet.
• Adding a Java visual snippet

Java visual snippets are predefined pieces of Java code that you can use in your snippet.
• Using a custom visual snippet

A custom visual snippet is one that contains an entire snippet within it.
• Adding a link to a snippet

Links represent data flow and direct the sequence in which the processing of the activities in your snippet
occurs.
Adding an input or an output to a snippet

The input defines the data that enters the snippet, and the output specifies the result.
To create a new input or output in your snippet, proceed as follows:
1. In the tray, click the plus icon ( ) to the right of either Inputs or Output. You can create an input or an
output in the same way.
Note: You can create as many inputs as you want, but only a single output.
2. In the Description tab of the Properties area, rename it if necessary, and specify an appropriate type.
You can choose a Java™ type, a data type or a business object.
Your newly created input or output appears in the tray.

Adding an exception to a snippet
An exception on the snippet defines what exceptions may occur during the processing of the snippet.
To create a new exception in your snippet, proceed as follows:

1. In the tray, click the plus icon ( ) to the right of Exceptions.
2. In the Description tab of the Properties area, rename it if necessary, and specify an appropriate type.
You can choose a Java™ exception type.
Your newly created exception appears in the tray.
Working with standard visual snippets
Many types of snippets are available in the editor, and you can use them when composing your own visual
snippet.
The visual snippets view to the left of the editor contains a categorized list of standard visual snippets that are
included with the product as well as custom visual snippets that have been user-defined. Proceed as follows to
add one of them to your snippet:
1. In the Visual Snippets view, expand the category and choose the snippet that you would like to add as
shown in the image.
2. Drag and drop this snippet onto the canvas.
The snippet appears as an node on the canvas, and you can wire it up as needed.
Note: Standard activities are fixed and cannot be modified. However, a custom activity can be opened in a new
editor by double-clicking it.
Table 1. A list and description of the available standard visual snippets.
Category Standard visual snippet Description
arrays array length Returns the number of elements in the array.
copy array element Makes a copy of a specific element in the array.
get array element Returns the value of a specific array element.
set array element Specifies the value of a specific array element.
converter convert integer to string Changes the value of the integer into a string.
convert primitive type Changes the value of the primitive into a string.
to string
convert string to Changes the value of the string into a double.

double
convert string to float Changes the value of the string into a float.
convert string to Changes the value of the string into an integer.

integer
convert string to long Changes the value of the string into a long.
convert to lower case Makes all of the characters in the string into lower case
characters.
convert to upper case Makes all of the characters in the string into upper case
characters.
date are dates equal Compares two dates to see if they are the same. Returns
true if they match.
create date from Creates a date object by combining a given pattern and
pattern date string.
create GMT date from Creates a date object by combining a given pattern and a
pattern date string that is in Greenwich Mean Time format.
current date and time Returns a value that is equal to the current date and time.
day of the month Returns a value that is equal to the current day of the
month.
day of the week Returns a value that is equal to the current day of the
week.
day of the year Returns a value that is equal to the current day of the
year.
difference between two Compares two separate dates, and returns the difference
dates between them in number of days.
format date to GMT Takes a patterned date as input and transforms it into a
string using pattern string that is based on Greenwich Mean Time.
format date to string Takes a patterned date as input and transforms it into a
using pattern string.
format locale date to Determines the current date and time based on the
string using pattern computer's locale, and uses a pattern to transform it into
a string.
get date pattern Returns a pattern that can be used to compose date and
time formulas.
is date after Compares two dates as input and returns true if the value
of the first date is after the second date.
is date before Compares two dates as input and returns true if the value
of the first date is before the second date.
events emit BO event Declares a business-related message that can be logged

in the runtime environment.
list add item to list Takes an existing list and a new object as inputs, and add
that new object to the end of the existing list.
clear all items from list Clears an existing list of all elements.
get item at index Takes an existing list and an index value as input, and
returns the specific item that is at the index point.
index of item Takes an existing list and a list object as inputs, and
returns the index of the specified list item.
is list empty Evaluates the list and returns true if it is empty, and false
if it contains any elements.
list contains item Takes an existing list and a list object as inputs, and
returns true if the list contains the specified object.
list size Returns a value that represents the number of items in

the list.
list to sort Takes the contents of a list, and arranges them

alphabetically.
remove item at index Takes an existing list and an index value as input, and
deletes the item that is at the specified index point.
remove item from list Takes an existing list and a list object as inputs, and
deletes the specified list item.
set item at index Takes an existing list, an index value, and an object as
input, and places the item at the given index point in the
list.
logic and Takes two boolean inputs, and returns true when they
themselves are both true.
inverse Takes a boolean input and converts it to its opposite. If it

comes in as true, it is changed to false and vice versa.
or Takes two boolean inputs, and returns true when either

one of them is true.
mapping advanced mapping The advanced mapping snippet builds on the basic
service mapping snippet (see below). It includes similar
terminals, but accepts a map of input and a map of output
business objects. It also provides an additional terminal
for an execution context (which may be null).
basic mapping Use a basic mapping snippet for general mappings

between two business objects. This standard visual
snippet provides terminals that you can use link to the
name and namespace of the map, the business objects
that you are working with, and three exceptions.
specific mapping Use a specific mapping snippet to reference an existing

business object map. Like the previous two options, this
standard visual snippet has terminals for inputs (that
automatically refer to the business objects as defined in
the business object map), exceptions and for execution
context
math absolute value Returns the absolute value of a number.
add Takes two numbers as input, and returns their sum.
divide Takes two numbers as input, and returns their quotient.
equal to Takes two numbers as input, and returns true if their

values are the same.
greater than Takes two numbers as input, and returns true if the value
of the first number is higher than that of the second.
greater than or equal Takes two numbers as input, and returns true if the value
to of the first number is higher than or the same as that of
the second.
less than Takes two numbers as input, and returns true if the value
of the first number is lower than that of the second.
maximum Takes two numbers as input, and returns the value that is
greater.
minimum Takes two numbers as input, and returns the value that is
lesser.
multiply Takes two numbers as input, and returns their product.
not equal to Takes two numbers as input, and returns true if the value
of the first number is different than that of the second.
power Takes a base and an exponent value as inputs, and

returns a value that is equal to the base number raised to
the power of the exponent.
square root Returns the positive square root of the number given as
input.
subtract Takes two numbers as input, and returns the difference

between them.
numbers format number to string Takes a maximum fraction digit and a number as inputs,
and returns the value as a string.
format number using Takes a pattern and a number as inputs, and returns the
pattern value as a string.
parse number for Formats a number according to the standards of the

locale current locale (for example either '1,000' or '1000' or '1
000)
relationship create participant Takes a relationship name, role name, and a business
service object as inputs, and creates a new participant for this
relationship service.
create participant with Takes a relationship name, role name, specified instance
ID ID, and a business object as inputs, and creates a new
participant for this relationship service.
deactivate participant Takes a relationship name, role name, and a business

object as inputs, uses them to identify a specific user, and
disables this user without completely removing it from the
system.
deactivate participant Takes a relationship name, role name, and instance ID as

by instance input, uses them to identify a specific user, and disables
this user without completely removing it from the system.
delete participant Takes a relationship name, role name, and a business

object as inputs, uses them to identify a specific user, and
completely removes this user from the system.
delete participant by Takes a relationship name, role name, and instance ID as

instance input, uses them to identify a specific user, and
completely removes this user from the system.
foreign key lookup Takes the following as input:

• foreign relationship name
• foreign input role name
• DataObject business object
• foreign keys business object
• foreign output role name
• output business object
• output business object foreign keys
• original input business object
• original output business object
• calling context
foreign key xref Returns a cross reference of a foreign key with the
following as input:
• foreign relationship name
• foreign input role name
• DataObject business object
• foreign keys business object
• foreign output role name
• output business object foreign keys
• calling context
get relationship Takes a relationship name, a property name, and an

property instance ID as inputs, and returns a relationship property.
get role property Returns a role property with the following as input:
• relationship name
• role name
• property name
• instance ID
• business object
maintain identity Maintains the identity of a relationship with the following

relationship as input:
• role name
• input business object

• calling context
retrieve instances Takes a relationship name, a role name, and a business

object as inputs, and returns a matching instance.
retrieve participants by Takes a relationship name, a role name, and an instance

instance ID as inputs, and returns all matching participants.
retrieve participants by Takes a relationship name and an instance ID as inputs,

relationship name and returns all matching participants.
retrieve participants by Takes a relationship name, a role name, and an instance

role name ID as inputs, and returns all matching participants.
set relationship Specifies a relationship property with the following as

property input:
• property name
• property value
• instance ID
set role property Specifies a role property with the following as input:
• role name
• property name
• property value
• instance ID
• business object
unset relationship Removes a relationship property as specified by following

property inputs:
• property name
• instance ID
unset role property Removes a role property as specified by following inputs:

• role name
• property name
• instance ID
• business object
SCA add item to soap-encoded Takes two business objects as input (one of them is an
services array item, and the second is a soap-encoded array), and adds
the item to the array.
are BO's Equal Takes two business objects as input, and returns true if
their values are the same.
are BO's Equal Takes two business objects as input, and returns true if
(shallow) their values are the same. A shallow function looks only
at that information which is on the first level of the BO. If
the BO contains a reference to another BO, then that
information will not be considered.
copy BO Takes either a business object or a business graph as

input, and duplicates it.
copy BO (shallow) Takes either a business object or a business graph as

input, and duplicates it. A shallow copy takes only that
information that is on the first level of the BO. If the BO
contains a reference to another BO, then that information
will not be copied.
copy list contents Takes two lists as input, and copies the contents of the
source list into the target list. (Copies are made for
business objects)
create BO Takes a namespace and a name as input, and returns a

new business object.
create specific BO Uses the Data Type selection wizard to create a specific
business object.
get Returns data from the business object Change Summary

BOChangeSummary Service.
Service
get BODataObject Returns data from the business object Data Object
Service Service.
get BOEventSummary Returns data from the business object Event Summary
Service Service.
get BOMetadata Returns data from the business object Metadata Service.
Service
get BOXMLSerializer Returns data from the business object XML Serializer
Service Service.
locate service Takes a service name as input, and obtains a reference

to the it.
SMO copy SMO Takes a Service Message Object as input, and duplicates
services it.
create SMO body Takes a namespace and a message as input, and

creates a body for the Service Message Object.
create SOAP header Creates a SOAP header from the following inputs:
• SOAP header name
• SOAP header namespace
• SOAP header prefix
• Business object
create specific SMO Uses the Message selection wizard to create a specific
body Service Message Object body.
get SMO body Takes a Service Message Object as input and returns its
body.
get SMO part Takes a Service Message Object and an XPath

expression as input, and returns the part specified by
XPath.
set SMO body Takes a Service Message Object and an SMO body as
input, and specifies its body.
text append text Takes two string as input, and combines their contents
into one.
remove whitespace Takes a text string as input, and clears all of the empty
from text characters from it.
split text Take as text string, a start index, and an end index as
inputs, and creates a substring of the given text using the
given indices.
text equal to Takes two text strings as input and returns true if they are
both the same.
text equal to (ignore Takes two text strings as input and, while ignoring case,
case) returns true if they are both the same.
text length Takes a text string as input, and returns its length in
characters.
utility BO print to logger Uses the Select Log Level wizard to specify granularity of
the log. You can choose from the following:
• Off
• Severe
• Warning
• Info
• Config
• Fine
• Finer
• Finest
• All
Then, the snippet takes the log message and business
object as inputs, and prints it to System.out.
print BO to log Takes a business object as input, and prints a textual

representation of it to System.out.
print to log Takes an object as input, and prints a textual

representation of it to System.out.
print to logger Uses the Select Log Level wizard to specify granularity of
the log. Then, the snippet takes the log message and
object as inputs, and prints it to System.out.
to text Takes an object as input, and returns a textual

representation of it.
Adding a Java visual snippet

Java™ visual snippets are predefined pieces of Java code that you can use in your snippet.
To import a Java visual snippet, proceed as follows:
1. From the palette, click the Java visual snippet activity icon .
2. In the Select a Java Visual Snippet wizard, browse the existing types and qualifiers, choose an
appropriate snippet and click OK
3. You can drop the activity into one of two places in your snippet:
a. To drop it onto an empty area of the canvas, drag the cursor out over the canvas.
b. To drop the activity into a structured activity that contains other activities, drag the cursor over
the appropriate activity.
In both cases, you will notice that the icon beside your cursor has a plus symbol when you are at a place
where you are allowed to drop the activity, and a thick black line will mark the location more clearly.
When the cursor becomes a crossed out circle, continue moving it until it becomes a plus sign again.
4. Click where you want to drop the activity.
Your newly created Java visual snippet will appear.

Parent topic: Creating a custom visual snippet
Using a custom visual snippet
A custom visual snippet is one that contains an entire snippet within it.
It is also called a composite visual snippet, and can be created as follows:

1. Create a new visual snippet in the editor. Pay close attention to the Category setting in the wizard in
which you are asked to specify a location for your new snippet.
2. Compose the visual code as necessary.
3. Save and close your work.
4. Create another snippet using the editor.
5. In the Visual Snippets view, expand the category where you saved your first snippet.
6. Drag and drop this snippet onto the canvas and wire it up as needed. The custom visual snippet appears
as an activity on the canvas. If you would like to make changes to it, double-click it and it will appear in
its own editor.
You have created a custom visual snippet.
Adding a link to a snippet
Links represent data flow and direct the sequence in which the processing of the activities in your snippet occurs.
You can either create a link automatically when your drop an object onto the canvas as described in the first step,
or link two existing objects as described in the second.
1. Create a link automatically in either of these ways:
a. Click an Input in the tray, and drag it onto an input terminal of an existing activity on the canvas,
or
b. Click an item in the palette, and then click a valid input or output terminal of an existing activity
on the canvas. The crossed out circle on your cursor will disappear when the terminal is a valid
choice for a link.
2. Link two existing objects on the canvas as follows:
a. Drop an activity onto the canvas. If it can take an incoming link, it will have a triangle on its left
edge . If it can take an outgoing link, the triangle will be on the right edge .
b. Move the cursor over an outgoing link until the yellow circle appears as shown in this image.
c.Click the yellow circle. The cursor will change appearance, and will look like a plus sign with a
crossed out circle beside it.
d. Drag the cursor out over the canvas. A yellow string is now attached to the cursor, and when
you hover over a valid incoming link icon, the crossed out circle disappears.
e. Click the activity that you want to link to. The link becomes a solid gray line and connects the
two activities.
f. To change the target activity, click the link so that it becomes highlighted, click the black box at
the target end of the link, and drag it to a new incoming link.
You have successfully created a link in your snippet.
Using inline expressions for simple equations
When you are coding an expression in the visual snippet editor, there are several ways that you can compose the
expression.
Most expressions can be represented diagrammatically in one of the following two ways:
Inline expressions
In this case, the equation is coded directly into the expression using the inline condition builder. The
finalized form appears like the one shown in this screen capture:
Prebuilt expressions
Prebuilt expressions can either be in the form of a Standard visual snippet or a Java™ visual snippet.
In both cases, the snippet contains specialized code that will perform the simple equation in question.
The finalized form appears like the one shown in this screen capture:
Of these two options available to you, the best practice is to use an inline expression when coding simple
equations.
Using mapping service snippets

When you want to transform data in a business object from one format to another using the visual snippet editor,
you can use one of the three mapping service snippets provided.
There are three types of mapping snippets available:

Basic mapping snippet
Use a basic mapping snippet for general mappings between two business objects. This standard visual
snippet provides terminals that you can use link to the name and namespace of the map, the business
objects that you are working with, and three exceptions.
Advanced mapping snippet
The advanced mapping snippet builds on the basic mapping snippet. It includes similar terminals, but
accepts a map of input and a map of output business objects. It also provides an additional terminal for
an execution context (which may be null).
Specific mapping snippet
Use a specific mapping snippet to reference an existing business object map. Like the previous two
options, this standard visual snippet has terminals for inputs (that automatically refer to the business
objects as defined in the business object map), exceptions and for execution context.
To add one of these snippets to your diagram, proceed as follows:
1. In the visual snippet editor, click the Standard visual snippet activity icon ( ).
2. In the Add a Standard Visual Snippet window, expand mapping services, chose one
of the three available options, and click OK.
Note: You will only be able to select a specific mapping snippet if there is an existing
business object map. You will be able to select it in the Business Object Map Selection dialogue
box.
3. Wire the terminals as needed.
Refactoring a visual snippet

When you refactor parts of your visual snippet, dependencies on those parts are automatically and universally
To refactor parts of your visual snippet, proceed as follows:
1. In the Visual snippet view, right-click the visual snippet as shown in the following screen capture.
2. From the list, hover over Refactor and then choose from one of the following three options:
Option Description
Rename Use this option to change the name assigned to the visual snippet.
Move Use this option to move your visual snippet to a new folder or module.
Change Namespace Use this option to assign a new namespace to your visual snippet.
Configuring a custom event in a visual snippet

A custom event is a specific business-related message that can be declared in the visual snippet editor to be
emitted in the runtime environment.
Once you have created your own custom event definition using the event definition editor, you can add it to your
visual snippet as follows:
1. In the Visual Snippets view, expand the events category, and select the snippet named emit event.
2. Drag and drop this snippet onto the canvas. The emit event snippet appears on the canvas, and a
dialogue opens that lists each of the events that are available to be emitted.
3. Select the event that you would like to emit and click OK.
4. In the snippet editor, create the expressions that will supply the emit event snippet with the data that is
necessary to emit the event in question.
Business rules
A business rule is a condition that must be satisfied when a business activity is being performed. A rule can
enforce a business policy, make a decision, or infer new data from existing data.
Using WebSphere® Integration Developer, you can compose integrative business solutions without programming
skills, creating and developing business rules in a graphical programming environment.
An example of a business rule

A vendor establishes the preferred status of each customer and creates a business rule to determine how much
each customer is charged for the same object. Here are some basic terms that define the building blocks of each
and every business rule:
Conditions
A condition describes a situation or state that must be in place in order for a specific action to occur. In
this example, the condition is the customer's status.
Actions
An action is the event that results from the evaluation of the condition. Each action is uniquely bound to
the condition that precedes it. In this example, the action is the quotation of the price; it is different for
each of the conditions that is encountered.
Table 1. A business rule is used to quote specific prices to customers depending upon their customer
status.
Customer status Quoted price
Bronze $5
Silver $4
Gold $3
The interaction between conditions and actions determines the form of your business rules. If the condition
is met, the action is performed. There are two possible forms, rule sets and decision tables, which are
described below.
Key concepts
Before you start to use this editor, you need to understand these key concepts about business rules:
• Rule groups
• Rule sets
• Decision tables
• Business roles in the development of business rules
• Templates
• Scheduling
Note: Business rules can only be deployed to the WebSphere Process Server.
Rule groups
A rule group is the highest level implementation component of a business rule. The rule group acts as a
gateway to the business rules since it is exposed as an SCA component in the runtime environment. The
rule group defines the interface and operation that the business rules will implement. Rule sets and decision
tables which share a common business focus can be gathered under the umbrella of a single rule group.
Rule sets and decision tables cannot be invoked directly and may only be invoked through a rule group.
One of the most important functions of the rule group is to define a date and time range during which a
specific rule set or decision table will be used.
Rule sets
A rule set is a set of business rules that are evaluated sequentially. There are two kinds of rule that can be
used in a rule set.
If-then rules
A rule in which if is the condition and then is the action. Only if the condition evaluates to true is the
action performed.
Action rules
An action rule is a rule in which the action is always performed.
An if-then rule set is a set of textual statements or rules where if is the condition of the rule, and then
is the action.
The first example we discussed used an if-then rule set:
Table 2. A business rule is used to quote specific prices to customers depending upon their customer
status.
Customer status Quoted price If-then rule
Bronze $5 If customer has bronze status

then price is 5.
Silver $4 If customer has silver status then

price is 4.
Gold $3 If customer has gold status then

price is 3.
In the runtime environment, each rule is evaluated sequentially, and each condition that evaluates to
true is acted upon, which could result in more than one action. An example might be a customer
loyalty scheme in which a customer that makes a purchase seven weeks out of ten receives a free
gift, and a customer that makes a purchase in all ten weeks receives an additional 10% discount
voucher for future use. Customers who made a purchase in all ten weeks evaluate to true for both
conditions and receive both incentives.
Decision tables
Another form that a business rule can take is a decision table.
Like the if-then rule set, the decision table is driven by the interaction between conditions and actions.
However, in a decision table, more than one condition decides the action. The conditional logic is
represented in a table where the rows and columns intersect to determine the appropriate action.
Each column represents a condition. In a decision table, several conditions may get evaluated, but
only one action is acted on.
For instance, in this example the customer status is represented by the rows in the table, and the
potential amount of money that the customer spends is represented by the columns. During the
transaction, the customer receives a bigger discount when he or she purchases more items. The
discount depends on the customer's status. The decision table enforces this business rule behavior
through the intersection of the status (rows) and items purchased (columns). The first column shows
us that the results of each of intersection is the same as the if-then rule set: if the customer with
bronze status buys less than 20 items, he pays $5 for each item; if the customer with silver status
buys less than 20 items, she pays $4 for each item; while the customer with gold status pays $3 for
each item.
Table 3. A business rule defined by a decision table.
Customer Buys less than 20 Buys more than Buys more than 30 Buys more than 40
status items 20 item items items
Bronze $5 per item $4.50 per item $4 per item $3.50 per item
Silver $4 per item $3.50 per item $3 per item $2.50 per item
Gold $3 per item $2.50 per item $2 per item $1.50 per item
Here are a few concepts that are unique to decision tables:
Otherwise condition
By using an otherwise condition, you can plan ahead when designing your decision table, and anticipate
situations where the conditions will not result in an action. For example, if a customer does not have a
status, at least according to the table, you can change the bronze row to use an otherwise condition so
that the customer who does not have a silver or gold status automatically receives the prices that the
bronze customer typically receives.
Initialization action rule
By using an initialization action rule, a specified operation is automatically performed while data is
passed to a decision table. You can also make initialization action rules into templates so that you can
modify the rule at run time.
Business roles in the development of business rules
Because business rules are developed and maintained by several users, you need to create
roles that indicate the different ways that different users create, implement, and modify business
rules, and how those users interact while working with a business rule.
There are two main roles for working with business rules:
Business analyst
The business analyst needs to have no knowledge about computer programming languages to create
business rules. The analyst applies his or her understanding of how the business works to create
business policies and business rules. When these rules have been deployed to a server, the analyst
applies his or her knowledge of the business environment and uses Web-based management tools to
keep the rules relevant.
Integration developer
The integration developer uses his or her knowledge of computer programming, to implement and deploy
the rules that the business analyst created. While implementing the rules, the integration developer uses
templates to determine what details can be modified later by another business analyst and writes
messages that will help that user make those modifications.
Figure 1. How two different roles interact in working with a business rule
Templates
One of the responsibilities of the business analyst is to keep business rules relevant. This
is especially necessary when a business environment must be dynamic to meet ever-
changing business needs. For example, your company might have to periodically adjust
sale prices to match the competition's prices. After deployment, you might still need to
modify your prices or other properties. It is rarely feasible or cost effective to get an
integration developer to make each adjustment.
In order to create business rules that are dynamically modifiable at runtime the business
rules must be based on templates. Decision tables can also be made dynamically
modifiable at runtime by basing the conditions or actions of the decision table on
templates.
A template defines what parts of a deployed business rule can be modified by an

authorized user. The template uses parameters and constraints to provide dynamicity.
Parameters and constraints define which values can be modified and by how much.
Parameters
Parameters are the elements of the business rule that can be modified dynamically. The "price" would be
a parameter if you want to adjust your sale price to match a competitor.
Constraints
A constraint is a restriction in a template that limits by how much a specified parameter can be modified.
There are two main types of constraints:
• Range constraints
• Range constraints apply to numeric parameters that are used in rules. An authorized
user may adjust a parameter but the parameter must be held within a certain numerical range.
For example you know that your product costs 100 to manufacture so your range of prices might
be between 105 and 500.
• Enumeration constraints
• Enumeration constraints are in a list that is either numeric or textual. The authorized
user must choose from one of the options in the list. For example, the user could upgrade a
customer's credit rating from "silver" to "gold".
Figure 2. An example of a template constraining a business rule
In this example, Vendor A can use a business rule template to adjust the price of the
item to beat Vendor B's pricing. However, when Vendor B tries to do something
similar, the constraint on the business rule template will not allow it. The constraint
does not permit a lower price than the one that is currently in place.
Scheduling
When changes to the business rules are mandated and expected, you can design
rules and deploy them to the server so that they become active when they are
needed. This functionality is important when, for example, business analysts have to
be prepared for changes to governmental tax regulations that will not go into affect
until the first of the year, or (as shown in the following example), when a special
price is put into effect for one special day only.
Figure 3. An example of how a business rule can be created for later use
When to use business rules
A business rule is anything that captures and implements business policies and practices. A rule can enforce
business policy, make a decision, or infer new data from existing data.
The WebSphere® Integration Developer tools have been designed so that users can easily compose integrative
business solutions without programming skills. To this end, you can easily create and develop business rules in
an intuitive graphical programming environment.
In general, you should use business rules to make a decision when any of the following conditions are met:
• you want to change the results at runtime, on a running server instead of hard-coded logic in your
solution.
• the decision itself naturally takes on the form of a table
• the decision itself naturally takes on the form of a series of textual if-then statements.
If you want to modify the business rule dynamically you must base your rule on a template. Basing rules on
templates gives you more dynamicity at runtime and allows you to modify settings without involving an integration
developer.
If your decision logic analyzes a collection of data or loops over a set of data, you should probably structure the
decision in a sequential process, and call out to a rule set whenever there is configurable data.
Building business rules: task roadmap

A high-level view of the development of a business rule is presented.
You are in the process of planning your business process.

1. Decide if a business rule is an appropriate solution for your business process. A business rule is an ideal
solution when you want to have flexibility to change your business process at runtime.
2. Create a rule group. The rule group is the primary element of a business rule, it provides the interface
between the business process and the rule logic. The rule group also defines date ranges during which
specific rule logic applies.
3. Decide which rule logic to use. Some business rules are better suited to a decision table, some to a rule
set.
4. Create your chosen rule logic. The rule logic is either a rule set or a decision table.
5. Create templates for your rule logic. By creating a template for your rule set or decision table you can
build up a library of rule logics that you can reuse in the future. The template also allows you to stipulate
which parameters of the rule logic can be modified by the business analyst using the Business Rule
Manager. Additionally constraints can be applied to these parameters so that the changes made with the
Business Rule Manager are within acceptable ranges.
6. Assemble your rule group into a business process, test and deploy.
Parent topic: Building business rules
Choosing between a rule set and a decision table
You can capture business rule logic using either a rule set or a decision table. Here are some suggestions for
how to decide which format to use.
Begin by sketching out a plan for your rules on a white board or a notepad. Use structure and terminology that is
natural to the business environment in which these rules will be used. Then, look for the following trends in the
finished product:
1. If your rules seem to take the form of a large number of unstructured sentences, then you should
probably use a rule set to capture their business logic. A rule set is more flexible than the more
structured decision table.
2. If you notice that every rule seems to use the same decision criteria, then it would be a good idea to use
a decision table. In this case, the decision criteria that all the rules share in common can be captured
once, and then you can define the parameters for each criteria.
3. If your rules naturally take the form of a table, then you should probably use a decision table.
4. However, if this table has a large number of holes, where some decision criteria are not applicable, or
where the output values are undefined, then you should use a rule set. The structure of the decision
table works well for regularity, but not for exception cases.
Creating a rule group

Create a rule group as a container for your business rules.
Create a new rule group by performing the following steps.

2. From the main menu, click File > New > Rule Group.
3. In the New Rule Group window, specify a module (or create one if necessary by clicking New), a folder
and a name for the new rule group, and click Next.
4. In the select an interface window, browse to an existing interface or click New to create one. If you
create a new interface here, you will have to create an operation using the interface editor before you
can use it in the rule group.
This creates a rule group, and launches it in a new editor. Click any of the topics listed below to configure your
new rule group.
Rule group editor
A rule group controls the timing and implementation of business rules.
The rule group editor is divided into several distinct areas, each with its own function.
1. The interface area
o This area displays the operations interfaces and references that you can choose from.
o To create a new interface or reference, click the icon, or to remove one, highlight it and click
the icon.
2. The rule logic area
o This area displays the possible rule logic that the operation can be routed to. You can visually
select your date and times using the interactive calendar, or create your own customized date-
based selection algorithm in the Selection criteria field. Use the date and time field when you
want distinct rule logics to apply during different periods. For example you may want to offer a
discount on weekends, or you may have a sale which runs until noon.
o To add new rule logic, click the icon, or to remove one, highlight it and click the icon.
o The contents of the page will differ on the activity or object chosen. In all cases, you can click F1
to launch a dedicated help window.
• Advanced tab: business rule group editor

This topic includes a description of each of the fields on the Advanced tab of the Properties view.
Advanced tab: business rule group editor

This topic includes a description of each of the fields on the Advanced tab of the Properties view.
Use the fields on this page to add a few custom properties to a business rule group. Custom properties represent
name-value pairs of type string that can be used to store user-defined information. They are used by generated
Business User clients and can be queried through an API at runtime.
Specifying the rule logic for a rule group

The rule logic is either a rule set or a decision table that is invoked at the designated time by the rule group.
To specify the rule logic for your new rule group, proceed as follows:
1. In the editor of your newly created rule group, click the operation that you want to associate with the
rules.
2. If this is a new operation, then it is unlikely that there will be rule logic defined for it, and you will have the
following options:
Option Description
Create Operation Click here to launch the rule group editor and specify the rule logic yourself.
Definition
Link to Orphan This option will be available if you have already created an operation and deleted
it. Click here to link to the rule logic that is still defined for the old operation.
3. Once you have made your choice, the rule logic window will appear.
4. Define the Default Rule Logic, by clicking Enter Rule Logic and either select an existing rule set or
decision table from the list, or create a new one.
Note: If you do not select default rule logic, and the rule logic that you provide does not cover all the
possible cases, a runtime exception will occur when the current condition is not covered.
5. Create your rule logic (you can create as many as necessary) by clicking the plus icon ( ) beside the
Scheduled Rule Logic label, and either select an existing rule set or decision table from the list, or
create a new one.
Scheduling rules using the rule group editor

The rule group editor can be used to schedule the running of a specific rule for a specific date and time.
To select start and end dates for a rule, proceed as follows:

1. In the rule logic area of the rule group editor, create a new Scheduled Rule Logic by clicking the icon.
Date fields will appear showing the current date.
2. To set a start or end date, click the appropriate calendar icon.
3. Use the interactive calendar to choose a date as shown in this image.
To set it to the current date, click Today, or to leave either the start or end date open (perhaps you do
not want it to expire), then click No Date.
4. In the Rule Logic column, click Enter Rule Logic to create a new rule, or select an existing one.
Standards for date and time selection in a rule group
There are a number of ways you can configure your rule group. Here are some suggestions that are based on the
number and nature of the available rule logic. In a rule group, date based selection can be used to delegate one
operation to a specific rule logic (note that overlapping rules are not supported, and only one can be called at a
time). The date selection data is composed of a set of rule logic rows and one default rule logic.
Here are some possible options, and some suggestions on what to do.
First option: one rule logic for the rule group
If there is only one rule logic for this rule group, it is recommended that you select it in the default rule
logic, and leave the dates empty.
Second option: two rule logics
If there are two rule logics one of which represents the current behavior and the other one the future
behavior of the rule group, it is recommended that you create two date rows in the table and leave the
default rule logic undefined.
Third option: standard behavior
If there is some standard behavior for the rule group, which is occasionally overridden for short
durations, it is recommended that you use the default rule logic for the standard behavior and create a
date range for each of the short term behavior rule logics.
Customizing algorithms for date and time selection

When you want to specialize the date and time selection criteria, you can create your own custom algorithm.
You can configure a rule group to work with the following:

• A date as specified using the tooling.
• A date returned from a Java™ expression
• A date stored in an attribute of the incoming business object.
By default, scheduling is based on the Current date. To change this, proceed as follows:
1. In the rule logic area of the rule group editor, create a new Scheduled Rule Logic by clicking the icon.
Date fields will appear with the current date.
2. In the Selection Criteria field, click Current date. You will then have the following choices:
Option Description
Current® Choose this to use the inline interactive calendar to select the dates graphically. If you
date choose this, then the system will create a Java snippet that will return a current
java.util.date object.
Java Choose this to use the visual snippet editor to graphically compose your own Java code
Option Description
that will obtain a date and a time, and return a java.util.date to the selector component.
XPath Choose this to specify an XPath to a xsd:datetime (java.util.date) parameter. The

parameter can either be a stand-alone, or it can be embedded within a Business Object.
Creating custom selectors

Selectors can be used to determine dynamically, at runtime, between two or more possible invocations. The
decision is driven by selection criteria that you can customize to your needs.
Selectors provide a simple way for you to filter the business logic in different directions depending on input
criteria. The possible selection criteria include: the location of the customer, whether you are currently offering
any discounts or if the customer is making a sufficiently large purchase to qualify for financing. You can use the
provided selectors for many circumstances, particularly those involving date-dependent discounts. In other
situations you will need to define your own custom selector. The process of creating a custom selector is
described briefly below, more in depth information about creating custom selectors can be found in related links.
1. Create the components that will be the target of the selector after the selection has been made. Any
WebSphere® Process Server component can be used as the outcome of the selector choice. You need
as many components as you will have possible outcomes. These components should all share an
interface.
2. Create a CustomSelector Java™ class. This is the class that will make the decision about which
component to select.
a. Open the New Java Class wizard. Select your Module in the Business Integration view, right-
click and select New > Other > Java > Class and then click Next.
b. In the Source Folder field browse to the current module folder.
c. Enter "com.ibm.customselectors" in the Package field.
d. Enter an appropriate name for the Java class, for example "CustomSelector".
e. Open the Implemented interfaces selection panel. Click the Add button.
f. In the Choose interfaces field of the Implemented interfaces selection panel type
"com.ibm.wbiserver.common.selection.S", and choose SelectionAlgorithm in the Matching
types field when it appears. Click OK.
g. Click Finish.
h. Augment the generated code with new code that will provide the new custom selection logic.
3. Create a new selector component.
a. Apply the same interface to the new selector that you used for the target components.
b. Choose one of the target WebSphere Process Server components as the Default Rule Logic.
c. Save and close the new selector.
4. Edit the code of the new selector to replace the default Java class with your custom code.
a. In the Business Integration view, right click the selector and click Show Files. This opens the
Physical Resources view, which displays the generated files for the project.
b. Right-click the filename.sel file, and select Open With > Text Editor.
c. Find the line of code:
<Selector>com.ibm.wbiservers.common.selection.GenericSelector</Selector
> and replace it with
<Selector>com.ibm.customselectors.CustomSelector</Selector> where
CustomSelector is the name you gave to your Java class.
d. Save and close the selector file.
5. Add the selector and all of the target components to the assembly diagram.
The project is ready to build and test.

Using rule set names in a rule group
Each operation in a rule group contains a rule logic table, which maps a set of date ranges to a rule set or
decision table. To avoid confusion, it is always a good practice to use rule set and decision table names which
are unique within the operation. If the same name is used twice, it is more difficult to see that there are actually
two different rule logics.
For instance, suppose you have one rule set to calculate the default discount rate, and another to calculate the
discount rate during a holiday period. These could be placed in different folders, with different namespaces, as
follows:
• http://www.yourNamespace.com/default/getDiscountRate
• http://www.yourNamespace.com/holiday/getDiscountRate
If you reference these rule sets within a single operation, only the local name for the rule set is shown, so the
references may appear identical in both the tooling and the Web environments.
Table 1. A situation where using the same rule set name might be confusing.
Label Name
Default getDiscountRate
July 1 to August 31 getDiscountRate
To avoid this problem, you should give each rule set a more descriptive name, as shown here:
• http://www.yourNamespace.com/getDefaultDiscountRate
• http://www.yourNamespace.com/getHolidayDiscountRate
If you do this, the names will be unambiguous, and there will not be any confusion.
Table 2. A situation where the rule set names makes sense.
Label Name
Default getDefaultDiscountRate
July 1 to August 31 getHolidayDiscountRate
Creating a rule set

This topic provides instructions on how to create a new rule set.

2. From the main menu, click File > New > Rule Set.
3. In the New Rule Set window, specify a module (or create one if necessary by clicking New), a folder and
a name for the new rule set, and click Next.
4. In the select an interface and operation window, browse to an existing rule group, or click New to create
one. If necessary, use the drop down lists to select a different interface and operation.
5. Click Finish.
This creates a rule set, and launches it in a new editor. Click any of the topics listed below to configure your new
rule set.
Rule set editor
A rule set captures decision-making business logic in the form of a series of if-then statements.
In a rule set, a business rule takes the form of an interaction between one condition and one action. In the rule
set editor, the rule is presented in a tabular format that you can edit as needed. The editor is divided into several
distinct areas, each with its own individual use as shown here.
The individual areas of the rule set editor
The areas of the rule set editor are as follows:
o This area displays the interface that is currently being referenced by the rule set.
2. The variables area
o This area displays the variables that are being used by the rule set to store its data.
o To create a new variable, click the icon, or to remove one, highlight it and click the icon.
3. The rules area
o Use this area to graphically compose your if-then rule sets.
o The previous screen capture shows two rules in this area ready to be defined. The first is an if-
then rule (a), and the second is a rule that is based on a template (b). The template on which
this rule is based is shown in the Templates section below.
4. The rules area toolbar
o The icons in the rules area toolbar perform the following functions:
Icon Description
Creates a new if-then rule.
Creates a new action rule.
Creates a rule that is based on an existing template.
Creates a template based on the current rule.
5. The templates area

o Use this area to graphically compose templates for a rule set.
o The previous screen capture shows a single if-then template (c) that is ready to be configured.
6. The templates area toolbar
o The icons in the templates area toolbar perform the following functions:
Icon Description
Creates a new template for an if-then rule.
. Creates a new template for an action rule.

o The contents of the page will differ on the activity or object chosen. In all cases, you can type F1
Working with the rule set editor

This editor gives you complete control over the configuration of your rule sets. Follow the links in the Related
tasks section below to learn how to do any of the following:
• Working with variables
• Create an if-then or an action rules
• Convert a rule into a template
• Create a rule that is based on a template
Adding a variable to a rule set
Variables store the data that are used by a rule set.
To create an additional variable, proceed as follows:
1. In the Variables settings area, click the plus icon ( ). A new variable will appear in the Name column.
2. In the Type column, click Select Type.
3. In the data type popup window, you have the following options:
Option Description
New Use this to select or create a business object.
Browse Use this to browse the Data type selection wizard for a data type. You will also be able to
choose from the XSD wildcards of xsd:any, xsd:anyType, or xsd:anySimpletype
Data Choose one of the pre-defined data types from the list.
type
You have successfully created a variable.

Creating an if-then rule in the rule set editor
An if-then rule determines what action to run according to the condition of the incoming message.
To create an if-then rule in the rule set editor, proceed as follows:
1. In the rule set editor, click the Add If-then rule icon ( ). A new rule appears as shown in this image.
2. In the Presentation row, write a sentence that will describe the rule to another user.
3. Compose the condition as follows:
a. In the If row, click Condition. A pop up window appears as shown in this image:
b. Use the choices in the window to build your condition. You can either choose an existing
template which will then prompt you for a value, or you can compose it yourself by clicking the
appropriate operators and values in sequence.
4. Set the action as follows:

a. In the Then row, click Action. A pop up window appears as shown in this image:
b. As earlier, use the choices in the window to set the action. You can either choose an existing
template which will then prompt you for a value, or you can set it yourself by choosing from one
of the other options.
Creating an action rule in the rule set editor
An action rule determines what action to run no matter what the incoming message is.
To create an action rule in the rule set editor, proceed as follows:
1. In the rule set editor, click the Add Action rule icon ( ). A new rule appears as shown in this image.
2. In the Presentation row, write a sentence that will describe the rule to another user.
b. Use the choices in the window to set the action. You can either choose an existing template
which will then prompt you for a value, or you can set it yourself by choosing from one of the
other options.
Creating rule set templates
Use a rule set template to define the implementation and parameters for an if-then or action rule. This template
can then be used to create new instances of the same rule using different parameters.
You can create templates for both if-then and action rules in the same way.
Business rules based on templates are dynamically modifiable in the runtime environment. The parameters of the
rule can be modified within certain constraints. Base your rule on a template if you want to give your business
analyst the ability to modify the parameters of a rule without involving the integration developer.
1. In the rule set editor, click either the Add If-then template ( ,) or Add Action template ( ) icon . A
new template appears as shown in this image (note that the window is slightly different for the action
template).
2. In the Parameters row, create a new parameter as follows:
a. Click the icon. A new parameter will appear.

b. In the Type column, click Select Type, and select an appropriate choice from the list.
c. To add a restriction on how the parameter can be configured, click None under the Constraint
column. A list showing the available choices will appear.
d. To specify an upper and a lower limit for a numerical parameter, click Range, and then use the
choices in the window to build your expression. You can either choose an existing template
which will then prompt you for a value, or you can compose it yourself by clicking the
appropriate operators and values in sequence.
e. To specify a list of choices, click Enumeration, and add items to the Enumeration Items table in
the Constraint tab in the properties view. The Value is the actual setting, and Presentation is
how it is displayed in an actual rule.
Note: If you apply a constraint to a parameter, the runtime user of a rule using this template will be able
to modify the parameter only in accordance with that constraint.
3. In the Presentation row, write a sentence that will describe the rule to another user. To insert a
parameter that the user can make changes to, click the triangular icon to launch a menu, and then
choose a parameter from the list.
4. Compose the condition as follows:
a. In the If row, click Condition. A pop up window appears as shown in this image:
b. Use the choices in the window to build your condition.
b. Use the choices in the window to set the action.
You have successfully created a template for an if-then or an action rule. Now you are ready to create a rule
based on it in the rule set editor.
Creating a new rule from a template in the rule set editor
Rules can be created from existing templates. In this way, you can create a similar rule without having to redefine
the implementation, and by making changes to the parameters within the constraints specified.
Business rules based on templates are dynamically modifiable in the runtime environment. The parameters of the
rule can be modified within certain constraints. Base your rule on a template if you want to give your business
analyst the ability to modify the parameters of a rule without involving the integration developer.
To use a template to create a new rule in the rule set editor, proceed as follows:
1. In the rule set editor, click the Add Template rule icon ( ). A drop down list appears showing all
available templates.
2. From the list, click the appropriate template. A new rule appears as shown in this image.
3. In the Presentation row, define the parameters by clicking Enter Value. If there is an enumeration
constraint in effect, a menu will appear showing your available options. Otherwise, you may enter a value
directly.
You have successfully created a rule based on a template.
Letting a Web user override the default values in a rule set

In a rule set, there are often situations where you want to allow a Web user to override the default output value as
programmed. To capture this in a rule set, use the following approach.
To allow a default value to be changed by a Web user, proceed as follows:
1. Create a rule set which sets the default value for the output.
2. Convert the rule set into a template, with a parameter for the default value.
3. Add a sentence to the template web presentation indicating that the default value should be overridden
by creating another rule after the default rule.
4. Create a few templates which capture the criteria when the default should be overridden.
5. Add a sentence to the web presentation for each of these, indicating that it should be used after the
default rule. There are currently no first class mechanisms to control rule order or creation, but these
comments should help the web user avoid mistakes.
Structuring an ordered rule set for modification
In some rule sets, there may be a tight dependency between the rules and their order of processing. This is the
nature of sequential execution. Here are some suggestions on how to plan for possible changes to an ordered
rule set.
For instance suppose you have a rule set which calculates the interest rate for a loan, given the loan amount.
It may look like this:
• Rule 1: primeRate = 5
• Rule 2: if amount < 1000 rate = primeRate;
• Rule 3: if amount >= 1000 rate = primeRate + 1
• Rule 4: if amount >= 5000 rate = primeRate + 2
In this situation, the behavior of the rule set will change significantly if you reorder the rules, and may even break.
Caution should be taken when you reorder these rules in the web client, and the logic must be correct before you
publish the changes. The best practice is to make the modifications in the tooling environment, test them, and
then copy those changes to the runtime system.
That being said, it is more likely that new rules will be added using a template in the web client. Caution should
be taken to make sure that the new rule is inserted correctly in the rule set. If the web user is skilled, they may be
able to position the new rule correctly. If not, you can take these precautions to avoid error:
1. Add a comment to the rule set which describes the general structure of the rule set, so that it is easier for
the web user to make changes to it.
2. Add comments to each template which clearly describe where the template instance should be located
within the rule set. You can do this by referencing existing rules in the rule set, and indicating that the
template should be placed before or after them.
3. Keep the rule set simple. If possible, limit the actual decision count in the rule set to one. In other words,
make one decision, not many.
4. Use the default pattern. In this pattern, we suggest you assign the default value at the start, and then put
the special case rules later. Your web users will come to learn this pattern.
5. Structure your special case rules so that they are mutually independent. For instance, the rule set above
would be more robust if rules 2 through 4 had the following form:
o if amount >= min and amount < max rate = primeRate + someValue
This rule could also be converted into a template which has plug-gable values for each parameter in
yellow.
6. If it is difficult to create mutually exclusive rules, then you should order the special case rules in
ascending or descending order. This gives the web user a pattern which is easy to follow.
Calling one rule set from another one

Currently, you cannot call one rule set from another directly, you can only call out to operations which exist in
another component. To work around this, separate the rule sets into two distinct rule groups, and then invoke one
from the other.
For instance, suppose you want rulesetA to call rulesetB. Here is how you would set it up:
1. Put rulesetA in rulegroupA.

2. Put rulesetB in rulegroupB.
3. Create a reference in rulegroupA with the same interface as rulegroupB.
4. In the assembly editor, wire rulegroupB to the reference in rulegroupA.
5. In rulesetA, add an invoke rule and select the rulesetB operation in the rulegroupB reference.
Creating a decision table
This topic provides instructions on how to create a new decision table.

2. From the main menu, click File > New > Decision Table.
3. In the New Decision Table window, specify a module (or create one if necessary by clicking New), a
folder and a name for the new decision table, and click Next.
4. In the select an interface and operation window, browse to an existing rule group, or click New to create
one. If necessary, use the drop down lists to select a different interface and operation.
5. If you want to configure the layout of the decision table, click Next.
6. In the Decision Table layout window, use the settings to determine how the decision table will appear in
the editor. The preview shows what the table will look like.
7. Click Finish.
This creates a decision table, and launches it in a new editor. Click any of the topics listed below to configure
your new decision table.
Decision table editor
A decision table captures multi-conditional decision-making business logic in tabular format.
Like the rule set, a business rule that takes the form of a decision table is driven by the interaction between
conditions and actions. The main difference being that, in a decision table, the action is decided by more than
one condition. The conditional logic is represented as a table where the rows and columns intersect to determine
the appropriate action.
In the decision table editor, the rule is presented in a tabular format that you can edit as needed. The editor is
divided into several distinct areas, each with its own individual use as shown here.
The decision table in this screen capture is an example of how an interest rate for a mortgage can be calculated
by considering both a customer's salary and credit rating. When this business rule executes, the initialization
action rule (in section 2) begins by taking the input values and assigning them to the output values. This is done
so that the business process that calls this decision table can continue to work with the original values. The light
grey conditions area of the table (section 6) shows the multiple conditions that will interact to determine the
customer's interest rate. The row along the top represents the customer's salary, and the column on the left, the
customer's credit rating. The intersection of the values that are passed into each of these two conditions specify
the action (section 7) that will determine the customer's interest rate. For example, if a customer's salary is
greater than 500, and the credit rating is 5, then they will receive the lowest interest rate of 5.0f.
The individual areas of the decision table

The areas of the decision table are as follows:
o This area displays the interface that is currently being referenced, as well as the inputs and
outputs that you can use in the decision table.
o
2. The Initialize area
o Use this area to configure an initialization action rule (an operation that will take place when
data first enters a decision table), as well as create a template for one.
o
3. The initialize tool bar
o Use the icons in the Initialize tool bar to perform the following functions:
Icon Description
Add an initialization action rule
Create a template from this action rule.
4. The Table area

o This area displays the table that shows the conditions and the actions that make up this
business rule.
o
5. The decision table tool bar
o Use the icons in the decision table tool bar to perform the following functions:
Icon Description
Add a new condition
Add a new condition value
Add a new action
Change the orientation of the condition (this will not impact the runtime execution).
Create a template for one of the expressions in this table
6. The conditions area

o The conditions area appears in light grey. Use this area of the decision table to define the
multiple conditions that will evaluate the incoming inputs in order to fire a corresponding action.
7. The actions area
o The actions area appears to the right and below the conditions area (in this particular
configuration of the decision table layout). Use this area of the decision table to define the
actions that will fire when the conditions intersect.
o The contents of the page will differ on the activity or object chosen. In all cases, you can type F1
Working with the decision table editor

This editor gives you complete control over the configuration of your decision table. Follow the links in the
Related tasks section below to learn how to do any of the following:
• Add a condition or a condition value
• Add an action
• Add an initialization action rule
• Using an otherwise condition
• Change the layout of your decision table
• Work with templates
Working with conditions in a decision table
A condition is an evaluation of the incoming message that looks for a specific value.
By default, a basic decision table is created with two rows and three columns. The top row represents the
conditions, and there is one cell for a term to reference an input for the condition, and two cells for the condition
values that the input will be evaluated against. This default decision table is shown in this image:
In this layout, any incoming term that matches one of the condition values in the top row fires a corresponding
action as defined in the second row.
Configure the existing conditions, and add new ones to your decision table as follows:
1. Specify the incoming variable for this condition by clicking Enter Term in the top row. You can either
enter a value directly in the cell, or make your choice from the popup window that appears. If necessary,
you can further configure the terms with the inline condition builder. The new condition term will appear
in the cell as shown in this image:
2. Configure the values for each of the existing conditions by clicking Enter Value, and choosing and/or
composing an appropriate expression from the popup window.
3. To add a new value, click on any cell in the conditions row, and click the Add a new condition value
icon ( ). A new column will appear as shown in this image:
4. If you want to further refine the potential values for each condition, you can add a new condition by
clicking the Add a new condition icon. A new row will appear below the current one, and each
column in it will have additional cells as shown in this image:
. Configure this condition as you did the previous ones.

Configuring actions in a decision table
An action is an operation that is executed when the appropriate conditions are met.
By default, a basic decision table is created with two rows and three columns. The bottom row represents the
actions, and there is one cell for a term to reference an output for the action, and two cells for the action values.
This default decision table is shown in this image:
In this layout, any incoming term that matches one of the condition values in the top row fires a corresponding
action as defined in the second row.
Configure the existing actions, and add new ones to your decision table as follows:
1. Specify the outgoing variable for this action by clicking Enter Term in the bottom row. You can either
enter a value directly in the cell, or make your choice from the popup window that appears. If necessary,
you can further configure the terms with the inline condition builder. The new condition term will appear
in the cell as shown in this image (note that the condition values have already been defined in this
example):
2. Configure the values for each of the existing actions by clicking Enter Value, and choosing and/or
composing an appropriate expression from the popup window. The finished table will look something like
this image:
3. To further qualify the actions, you can add a new action row. To do this, click on any cell in the actions
row, and click the Add a new action icon ( ). A new column will appear as shown in this image:
. Configure this action as you did the previous ones.

Working with initialization action rules
An initialization action rule automatically performs an operation of some kind when data is first being passed to a
decision table.
Typically, an initialization action rule is used for the following reasons:

• To set an initial value. For example, to copy one or more input business object(s) to one or more output
business object(s)."
• To initialize an output business object. For instance, to set the initial value of the business objects
attribute. More importantly, if the business object has attributes that are also business objects, then you
can create those business objects (and this can be recursive if they in turn contain even more business
objects).
Initialization action rules can also be made into templates so that they can be modified in the runtime
environment.
1. To create an initialization action rule, proceed as follows:
a. In the decision table editor, click the Add an initialization action rule ( ) icon.
b. Assign a name to your new initialization action rule in the name field.
c. In the Presentation field, enter a sentence that will describe what this initialization rule does to a
Web user.
d. In the Action field, use the inline condition builder to define the operation that will take place.
2. To create a template for the initialization action rule, proceed as follows:
a. In the decision table editor, click one of the cells in the Initialize area.
b. Click the Convert Rule or Table cell to Template ( ) icon. The rule area changes slightly.
c. Click anywhere in the Initialize area, and the template editor will appear in the General tab of
the properties area.
d. Configure the template according to the instructions in Creating decision table templates.
Using an otherwise condition
An otherwise condition is used in a decision table for situations when the specified conditions will not be met. The
otherwise condition cause a rule to fire when no other evaluation can be resolved.
Configure an otherwise condition as follows:

1. Configure your decision table so that at least two of your conditions have been defined.
2. Right-click a conditions cell, and select Add Condition Otherwise from the list as shown in this screen
capture.
A new value appears on the condition called Otherwise as shown in this screen capture. It will always be the last
value shown, and only one otherwise is allowed per condition.
Note: You cannot make a template from the otherwise condition.
Using an otherwise condition
An otherwise condition is used in a decision table for situations when the specified conditions will not be met. The
otherwise condition cause a rule to fire when no other evaluation can be resolved.
Configure an otherwise condition as follows:

1. Configure your decision table so that at least two of your conditions have been defined.
2. Right-click a conditions cell, and select Add Condition Otherwise from the list as shown in this screen
capture.
A new value appears on the condition called Otherwise as shown in this screen capture. It will always be the last
value shown, and only one otherwise is allowed per condition.
Note: You cannot make a template from the otherwise condition.
Creating decision table templates
Use a template to define the implementation and parameters for either a condition or an action value in a decision
table. This template can then be used to create new cells with the same format, but with different parameter
values.
Decision tables, in which the conditions or actions are based on templates are dynamically modifiable in the
runtime environment. Base the conditions or actions of a decision table on a template if you want to give your
business analyst the ability to modify the runtime behavior of the decision table without involving the integration
developer.
To create a template for one of the values in your decision table, proceed as follows:
1. In the decision table editor, choose a cell and click the Converts an expression of a decision table
cell into a template ( ) icon . If you are working with an existing value in the table, then the system will
examine the expression and convert all literal values into parameters. The value appears in a small
square to indicate that it is a template, and a new template appears as in the General tab of the
properties area shown in this image:
2. In the Parameters row, you can create a new parameter as follows:
a. Click the icon. A new parameter will appear.

b. In the Type column, click Select Type, and select an appropriate choice from the list.
c. To add a restriction on how the parameter can be configured, click None under the Constraint
column. A list showing the available choices will appear.
d. To specify an upper and a lower limit for the constraint, click Range, and then use the choices in
the window to build your expression. You can either choose an existing template which will then
prompt you for a value, or you can compose it yourself by clicking the appropriate operators and
values in sequence.
e. Alternatively, to specify a list of choices, click Enumeration, and add an item to the
Enumeration Items table in the Constraint tab in the properties view. The Value is the actual
setting, and Presentation is how it is displayed in an actual rule.
3. In the Presentation row, write a sentence that will appear in the cell. To insert a parameter that the user
can make changes to, click the triangular icon to launch a menu, and then choose a parameter from the
list.
4. If you want to make changes to this value's implementation, click the first cell in the Expression row, and
use the choices in the pop up window to build a new expression.
Using templates in your decision table
The individual cells of your decision table can be populated with an existing template for the value. In this way,
you can create a similar expression without having to redefine the implementation, and by making changes to the
parameters within the constraints specified.
Decision tables, in which the conditions or actions are based on templates are dynamically modifiable in the
runtime environment. Base the conditions or actions of a decision table on a template if you want to give your
business analyst the ability to modify the runtime behavior of the decision table without involving the integration
developer.
To use an existing template in your decision table, proceed as follows:

1. In the decision table, click on a cell for either an action or a condition value.
2. Click on the General tab in the properties area.
3. In the first cell of the Active Template table, click None, and choose an existing template from the list.
The cell in the decision table will change and display the template's presentation sentence, and the template itself
will appear in the properties area.
Editing a decision table template

This topic provides instructions on how to make changes to an existing templates.
To make changes to an existing template, proceed as follows:

1. In the properties area of your decision table, click Templates.
2. From the Value Templates list, click the template you want to edit. The template will appear to the right of
the list.
3. Make your changes as needed.
Weak type support with business rules
Business object definitions can have XSD wildcards that can be used in business rules logic.
Such wildcards can represent a placeholder for any of the following:

• an arbitrary simple type (xs:anySimpleType)
• an arbitrary complexType (xs:anyComplexType)
• an arbitrary type (simple or complex, called 'xs:anyType')
• an arbitrary element (xs:any)
For more advanced mapping and expressions involving weak types or attributes use other components such as
interfaces or business objects maps.
Restrictions:
• No local variables in a rule set can be of weak type.

• You cannot use weak types in computations or comparisons.
Table 1. Business rules support of weak types for basic mapping
Input type Output type Supported
any any Yes. All existing open elements are deleted from the
source and the source open elements are added to the
end of the closed elements.
anyAttribute No
anyType No
anySimpleType No
Concrete complex No
type
Concrete simple type No
anyAttribute any No
anyAttribute Yes. All of the attributes are removed and replaced.
anyType No
anySimpleType No
Concrete complex No
type
anyType anyType Yes. Assignment allowed.
any No
anyAttribute No
anySimpleType Yes. Assignment allowed if data is a simple type, for

example a string.
Concrete complex Yes. Assignment allowed if data is of a compatible type.

type
Concrete simple type Yes. Assignment allowed if data is of a compatible type.
AnySimpleType anySimpleType Yes. Assignment allowed.
any No
anyAttribute No
anyType Yes. Assignment allowed.
Concrete complex Yes

type
Concrete simple any No

type
anyAttribute No
anySimpleType Yes. Assignment allowed.
Concrete complex any No

type
anyAttribute No
anySimpleType No
Business rule management programming guide

The Business rule management programming guide explains the programming model for business rules
management classes, and provides examples on how to use the different classes.
To download the programming guide, as well as Project Interface and EAR files that contain examples, follow this
link: Business rule management programming guide.
Note: For this link to work, you will need to have an active connection to the internet.
The programming guide is reproduced in the WebSphere® Process Server documentation if you prefer the
information center format. See Business rule management or Business rule management if you have WebSphere
Process Server installed.
Choosing the correct template parameter values
To make sure that you don't have any syntax inconsistencies with template parameters in the runtime
environment, please understand the following.
WebSphere® Integration Developer and WebSphere Process Server use a different syntax for template
parameter values. This inconsistency does not affect rule set or decision table processing, but will make it more
awkward to edit some business rules in the business rules manager.
In WebSphere Integration Developer, the value for a float template parameter must take the form '9.99f', where 9
is any number, and 'f' is a float delimiter. If the 'f' delimiter is not used in WebSphere Integration Developer, a
validation error is added to the rule set. If the float value is syntactically correct, the rule can be deployed to the
WebSphere Process Server server, and executed without error.
In the business rules manager, a value for a float template parameter must take the form '99.9'. If you view or edit
the rule set or decision table in the Web client, a validation error will be added for any float value which includes
the 'f' delimiter.
This inconsistency is only a problem if you want to modify the rules and save the new version to the WebSphere
Process Server server. In this case, you must manually remove the 'f' delimiter from all float values in the Web
client before you can save the new version.
Refactoring business rules

When you refactor parts of your business rules, dependencies on those parts are automatically and universally
To refactor parts of your business rules, proceed as follows:
1. In the Business Integration view, right-click the business rule.
2. From the drop-down menu, hover over Refactor and then choose from one of the following three
options:
Option Description
Rename Use this option to change the name assigned to the rule.
Move Use this option to move your rule to a new folder or module.
Change Namespace Use this option to assign a new namespace to your rule.
Generating documentation for your rules

If you need a high level synopsis of your business rules, including how they interact with other resources within
the same project, you can create a customized report using the documentation generator.
A generated document can very quickly provide you with the following:
• a quick understanding of a project or resource
• an overview report about a complex project
• the visualization of the relationships and cross references of resources within a project
• a detailed report that can be printed out for certifications
To create a report for your business rules, proceed as follows:
1. In the Business Integration view, right-click either your rule group, rule set, or decision table and select
Generate Documentation.
2. Configure the Documentation Generation wizard according to the instructions in the Generating
documentation topic.
Launching the Business Rules Manager
The Business Rules Manager is a Web client that allows dynamic control of parameter values in template based
rules that are deployed to the Websphere Process Server.
See the WebSphere® Process Server documentation for a more complete set of instructions on the business
rules manager or business rules manager if you have WebSphere Process Server installed.
Before you begin
Make sure that both the server and client are configured correctly. See Considerations for installing the business
rules manager for more information.
The default URLs for accessing the business rules manager are:
• https://hostname:9443/br (if security is enabled)
• http://hostname:9080/br (if security is not enabled)
where hostname is the name of the host.
Note: URLs may vary according to the environment.
Note: The Login page opens only when you have enabled global security on the server. See Configuring server
security for the business rules manager for more information. If the global security is not enabled, the Rule books
page opens when business rules manager is accessed.
If global security is enabled, follow these steps to login.
1. Switch to the server view.
2. Start your server.
3. Right-click the server and select Launch > Business Rules Manager.
4. At the Login page, type your User ID.
5. Type your Password
6. Click Login. The business rules manager Initial page opens.
The Initial page opens with the existing rule books listed in the Navigation Area. You can now make changes to
any business rule listed.
Working with business calendars

WID

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

WID

Încărcat de

Drepturi de autor:

Formate disponibile

WID

Human Task, Decision Table, Business Rules

An example of a human task

Presenting a task to a staff member

Collaborating with other staff members in a human task

A to-do task can be implemented either stand-alone or inline.

Changing a stand-alone task to an inline task

The user interface can be customized to your specific needs.

2. Expand Business Integration and expand Human Task Editor.

4. Optional: Add a new people directory.

a. Click Add. The Add people directory dialog opens.

5. Optional: Edit an existing people directory.

a. Click Edit. The Edit people directory dialog opens.

6. Click Apply when you are finished.

7. Click OK to save your preferences

Setting human task preferences

2. Expand Business Integration and expand Human Task Editor.

4. Optional: Add a new people directory.

a. Click Add. The Add people directory dialog opens.

5. Optional: Edit an existing people directory.

a. Click Edit. The Edit people directory dialog opens.

6. Click Apply when you are finished.

7. Click OK to save your preferences

Human Task editor

• Assign people tab: Human Task editor

• Description tab: Human Task editor

• Details tab: Human Task editor

• Duration tab: Human Task editor

• Environment tab: Human Task editor

• Interface tab: Human Task editor

• User interface settings tab: Human Task editor

Assign people tab: Human Task editor

Description tab: Human Task editor

Details tab: Human Task editor

In all cases, mandatory fields are marked with a "*".

Expected task state

You will have the three following options:

Increase task priority

You will have three options:

Business Process Choreographer Explorer

For task pages there are two available options:

When you are done, click Create Portlet.

Duration tab: Human Task editor

You have the three following options:

You can select either of the following:

You have the following options:

Use this field to enter a name for your custom calendar.

User calendar JNDI

Environment tab: Human Task editor

Custom properties table

Interface tab: Human Task editor

IBM® Lotus Forms client

The building blocks of the human task editor

• People assignment roles and criteria

People assignment roles and criteria

People assignment settings

Potential owners can claim, work on and complete tasks.

User interface settings

• IBM® Lotus® Forms client

• Business Process Choreographer Explorer

There are four possible activation states:

When a task is in the ready state, it is waiting to be claimed.

Invocation scenarios for invocation tasks