WebSphere Integration Developer Version 6.0.

2
Lecture 1,2

Lecture 1 - Interface mapping, business object mapping, and human

tasks

Introduction
In this article, we’ll look at more of the supporting features in WebSphere Integration Developer.

One challenge is sure to arise in a service-oriented application: what happens when two services need to work
well together, but they don’t understand how to communicate? Early on in this series, we explained that a
component implementation calls another component using a reference. We pointed out that the interface of a
reference must match the interface of the component to which it is wired. However, what if the interfaces don’t
match?

For example, suppose a reference’s interface has a retrieveCustomerData operation and the component to
which you want to wire that reference has an interface with a getCustomerData operation. Looking a bit deeper,
the problem compounds if one of the business objects that the getCustomerData operation returns has a field
called custId, but the retrieveCustomerData operation expects the return parameter name to be just id.

In a small, localized application, the solution is quick: just change the interfaces so that everything matches.
In practice though, your business partners often provide interfaces for services that you use, for example Web
Service Definition Language (WSDL) files, so changing them is out of your control. Even if you could change
the interface, it might break existing consumers of the service. On the client side, changing the interface of the
reference might also be out of the question because you would have to change the implementation to use
different names. WebSphere Integration Developer makes it very easy to get around this obstacle: it lets you
create interface and business object maps.

If you’ve ever tried to wire a reference to a component where there was a mismatch between the interfaces, a
dialog box would have opened asking if you wish to create an interface map. This article will show you how
easy it is to create different types of maps.

In addition to mapping, we will also explore human tasks. Automating business processes is essential to a
company’s efficiency and effectiveness. However, quite often, a business process still requires human
intervention. For example, a bank loan approval process might require an experienced loan specialist to
evaluate borderline loan applications. A retail store process that automatically re-orders inventory when the
inventory level falls below a certain limit might require the store manager to approve all the orders with a large
dollar value. Human intervention might also be required in dealing with exceptional cases during a business
process. In situations similar to these, you can use a human task component when designing integration
applications

A human task, as the name suggests, is a task that involves a human. It is a component in a module just like
the others we have seen, such as a business process, business state machine or business rules. You might
wonder what the difference is between the staff activity in WebSphere Studio Application Developer Integration
Edition, Version 5.1 and a human task component. You could only use a staff activity from within a business
process, and its functionality was limited. For example, a staff activity did not allow escalations (an automatic
reassigning of a task that has not been claimed or completed). In Version 6, a human task is a first-class
component and is no longer restricted to being an internal activity in a business process. Furthermore, a
human task component not only allows the computer to interact with a human, but it also allows human-to-
computer and human-to-human interactions.

After we explain human tasks, interface maps, and business object maps, we will let you get your hands dirty
again, this time by creating a human task with a mapping that enables two components with different
interfaces to communicate with each other.

Page 1 of 22
 In the following sections, you will learn how to perform more tasks using WebSphere Integration Developer:

• Mapping interfaces and parameters

• Mapping business objects

• Implementing components as human tasks

• Creating your own human tasks

• Creating your own interface and business object maps

Interface maps
An interface map sits between two components with different interfaces and lets you say, "When I call
OperationX of InterfaceA, send the request to OperationY of InterfaceB." Of course, the parameters of both
operations might not match either. So, an interface map also lets you say, "Pass the value of Parameter1 of
OperationX to Parameter2 of OperationY." If the parameters of both operations are of the same type, then
that’s all there is to an interface map. Often, however, the parameter types are different. In the Parameter
Mapping section, we'll show you the various mapping tools that help you when parameter types are different.

For example, suppose an order-processing component needs to call the shipOrder operation of a shipping
component. However, the interface for the shipping component has an operation called ship, and both
operations have different names for their parameters. Figure 1 shows two interfaces: one containing the
shipOrder operation and the other containing the ship operation. Notice that the parameter names of each
operation are different. Figure 2 shows you an interface map that resolves these differences.

Figure 1. Two operations that require a map

Page 2 of 22
 Figure 2. An interface map

At the top of the interface mapping editor, you connect operations of the interface on the left to operations of
the interface on the right. For the operation parameters, the bottom of the editor shows mappings that you
create by connecting the respective parameters (inputs and outputs) of each operation. A move mapping type
is created by default when you connect parameters. We'll discuss the different types of parameter mappings
shortly.

The map type is pointed at one end to indicate the direction of the mapping. For example, the upper move
indicates that the orderInfo input value gets passed to the order parameter, while the lower move indicates
that the value of the output parameter ok gets passed to the shipped parameter.

There are two ways to create an interface map. The first way is to use the interface map wizard (File -
NewInterfaceMap), as Figure 3 shows. With this method, you select or create the source and target
interfaces. The source interface is the interface that belongs to a reference of a component and the target
interface belongs to the component being called from the reference.

Figure 3. New Interface Map wizard

The other way to create an interface map is to wire a reference of one component to another component. You
use this method when the reference and component have different interfaces. The assembly editor asks you if
you want to create an interface mapping between the source and target nodes (the nodes being the reference
and the component, respectively).

Page 3 of 22
Operation mapping
After you have created an interface map, you need to define the mapping between the interface operations, as
you can see at the top of Figure 4. You create a mapping by clicking next to an operation on the left and
dragging the end of the connection to the corresponding interface on the right. When you select the connection
between two operations, the parameter mappings display in the lower half of the editor. The next step is to
draw connections between equivalent parameters.

Figure 4. Creating an interface map

Parameter mapping
After you have specified which operation of one interface corresponds to which operation of another interface,
you need to map the operation parameters. As with an operation map, you connect inputs and outputs of one
operation to the corresponding inputs and outputs of another operation. However, mapping corresponding
operations requires only a line between them, while mapping data can be more complex. If the parameter
types match, then you just connect the corresponding inputs or outputs as Figure 4 shows. Often, the types
will not match, but the business object map editor helps you to map the data as we'll show you in the Business
object maps section.

First, let's look at how you create a parameter mapping. For input parameter mappings, you drag a connection
from an input parameter on the left to the corresponding input parameter on the right. For output parameter
mappings, you drag the connection from right to left. After creating the mapping, the next step is to specify
the type of map. You can select from a list of mapping types in the Description tab of the Properties view. In
the sections that follow, we will explain the five types of mappings:

• Move

• Extract

• Map

• Assign

• Java

Page 4 of 22
Move

By default, when you connect two parameters, the type of map that is created is called a move parameter
mapping. In the earlier example, we showed a move parameter mapping. With a move parameter mapping,
the exact value of a source parameter will pass as-is to a target parameter. The type of each parameter,
whether it is a string or a business object, must be the same. Move mapping types are 1-to-many, which
means you can map a source parameter to one or more target parameters.

Extract

Sometimes, a target parameter requires only some of the data from the source parameter. In this case, you
can use an extract. An extract parameter mapping takes the value of a business object's attribute, which could
be a simple type or a nested business object, and puts it into the target. Figure 5 shows a variation on the
earlier example where the ship operation has two input parameters whose types are Item and Address. The
Order business object used in the shipOrder operation contains attributes with the same Item and Address types
as you see in the XPath tree in the bottom of the figure. The Properties view shows an XPath expression that
selects the item attribute from orderInfo. When you use the mapping, the values for orderInfo.item are passed
to the item parameter. We use a second extract with orderInfo as the source to transfer the orderInfo.address
value to the address parameter.

Figure 5. An extract parameter mapping

Map

If the parameter types don't match, you use a map instead of a move. A map parameter mapping lets you
reconcile different business object parameters. There are numerous mismatches that can exist between two
business objects, even though each one contains information that the other needs. A mismatch could occur
because the attributes of one business object are in a different order and have different names than the
attributes of the other business object. Or a mismatch could get quite complex: one business object might
represent a name with three attributes (salutation, firstName, and lastName), while another might represent a
name using just one attribute that is meant to hold a comma delimited string. You might even have multiple
business objects whose individual parts need to be mapped to or from one business object. When you use a
map, you specify a business object map that maps the attributes of one business object to another. The
section on business object maps describes this mapping type in detail.

Page 5 of 22
Assign

You can also map a constant value to a target parameter. An assign parameter mapping lets you specify a
constant value to put in a target parameter. This type of mapping has only a target. Therefore, to create an
assign mapping, you can't create a connection between two parameters and change the type to assign
(because a double-ended connection can't be an assign mapping). So, to create an assign mapping, right-click
a target parameter (an input on the right or an output on the left) and select Create Transform - Assign. In
the Properties view, you can enter the constant value.

You should use an assign mapping when a target operation contains a parameter that is not present in the
source operation. The extra parameter might no longer be in use. Because a map requires all targets to have a
mapping, you can assign some default value to the extra parameter. The extra parameter could also always
have the same value when called from your module. For example, Figure 6 shows a ship operation with an
orderType parameter that is not present in the shipOrder operation. The assign mapping passes a value of
express each time the map is used.

Figure 6. An assign parameter mapping

Java parameter mapping

For maps that require custom logic, you can use a Java parameter mapping. A Java parameter mapping lets
you write arbitrary Java code to transform one object to another. In the Details section of the Properties view,
you specify the name of the class, which must extend the Java class
com.ibm.wbiserverspi.mediation.JavaMediation. The JavaMediation class contains a mediate method that takes
an object as input, which is the value that is to be mapped, and returns an object that is the transformed
value.

Business object maps

In the parameter mapping examples, you saw how to map the parameters between operations using mapping
types such as move and extract. In this section, we'll look at what happens when the parameter types are not
the same and you can't use a parameter map. As we noted earlier, the map parameter mapping type requires
you to specify a business object map that handles the mapping between the attributes of two business objects.
In this section, we show you what business object maps are and how to use them.

Page 6 of 22
Transform types
Mapping business object attributes is similar to mapping parameters: you connect source attributes to target
attributes. Mapping attributes is also called transforming attributes. Because transforming attributes generally
requires more flexibility than mapping parameters, there are more transform types. The next sections will
cover the following transform types:

• Move

• Submap

• Extract

• Assign

• Custom

• Join

• Relationship

Move

A move transform is analogous to the move parameter mapping type. It assigns the value of a primitive-type
attribute in the source business object to a primitive-type attribute in a target business object. You can map
one primitive-type attribute, such as a string, to another, such as an integer. Keep in mind that if the data
cannot be converted at runtime, you get an exception. For example, if the string "123a" is mapped to an
integer, you will see a NumberFormatException in the server log. Furthermore, unlike a move parameter
mapping, you cannot map complex types using a move transform. For mapping between business objects, you
need a submap, as we will describe shortly.

Figure 7. A move transform

Submap

A submap is another business object map that you use to transform one business object to another. For
example, in Figure 8, the PO business object contains an Address business object. On the right, in Order, there
is also an Address in the Customer business object. The Details tab shows that the Address business object map
maps Order/customer/address to PO/shipTo. Because the source and target have the same type, Address, the
submap consists only of move transforms between parameters with Address attributes. This might remind you
of the extract parameter mapping earlier. If the interface containing PO had two parameters, invoiceNum and
shipTo, instead of just one PO parameter, we could have used an extract parameter mapping here.

Page 7 of 22
 Figure 8. A submap transform

Extract

An extract transform is a bit different than its parameter mapping counterpart because its source attribute
must be a string. You use the extract transform to extract parts of a string and assign those parts to another
string, or to any other primitive type, with the caveat we mentioned in the move transform section.

For example, Figure 9 shows two extracts that separate the first name and last name from a string with the
format lastname, firstname. The details for the second extract show that the part of the name string up to the
first comma gets copied to the lastName attribute of the Person object. The substring index determines which
section of the string, starting from 0, to use. Therefore, the firstName extract contains the same details as the
lastName extract, except that the substring index is 1 (It uses the second part of the string: the characters
between the first comma and the second). If the value of the name attribute is "Smith, Joe", then firstName will
get a value of "Joe" and lastName will get "Smith".

Page 8 of 22
 Figure 9: An extract transform

Join

A join transform combines the values of two or more source attributes and copies them to a target attribute.
The target of a join transform must be a string. You can think of a join transform as the inverse of the extract
transform because it takes a set of string inputs (or any other primitive type, which will be converted to a
string), and joins them into one string, optionally separated by delimiter.

In the extract transform example, we showed mapping a comma-delimited string to separate first and last
name attributes. Often you need to map both ways. Figure 10 shows you how to map back from the Person
business object to the emp business object. If firstName contains the value "Joe" and lastName contains "Smith",
then the name attribute gets the value "Joe,Smith" because firstName has a delimiter set to a comma.

You can check how the join concatenates the values by looking at the example at the bottom of the Details
tab. Keep in mind that the delimeter can consist of multiple characters. The Prefix and Postfix fields let you
add strings to add a prefix to and append the resulting joined string. You can also use the Reorder icons to
change the order in which the attributes are concatenated.

Page 9 of 22
 Figure 10: A join transform

Assign

An assign transform sets a constant value to a target attribute. Figure 11 shows an assign transform that sets
the prefix attribute of Person to null.

Figure 11: An assign transform

Custom, custom assign, and custom callout

To write Java code to specify the mapping logic between a source and a target attribute, you use a custom
transform. If there is no source attribute, then you use a custom assign transform, which is similar to an

Page 10 of 22
assign transform, except that you use Java code to compute the assigned value. If there is no target attribute,
then you use a custom callout transform, to initialize values.

Relationship

You use a relationship transform when the same data has different names or different identities. The
relationship transform is different than other mappings because with other mappings we are interested in
connecting different attribute names or business objects that refer to the same data. A relationship transform
goes one step further by also handling cases where the data is different but has the same meaning or refers to
the same thing.

There are two types of relationship transforms: dynamic and static. A static relationship correlates different
values that refer to the same thing. These types of values never, or rarely, change. A typical example is a
state or province name: one system might use 2-letter designations such as ON, while another might use
longer abbreviations such as Ont., and still another, full names such as Ontario.

When you map data from one attribute to another with a static relationship, you can also transform the data
according to the table you create with the relationship editor. For example when the province attribute of one
business object that has a value of "ON" is mapped to another business object attribute, the value assigned
could be "Ontario."

You use a dynamic relationship to correlate data based on primary keys. For example, a product in a store
might have one identifier on the inventory tracking system and another on the suppliers system. Your system
might have an identifier in a generic business object that not only contains the same data as identifiers in
other business objects, but something needs to keep track of which data is actually the same. For example,
when itemNumber, which has a value of "123", is mapped to productCode (in a business object used in the
supplier's interface), the value of "a234" might need to be inserted so that the correct item will be ordered
from the suppliers system. The relationship manager on WebSphere Process Server takes care of this.

The two relationship articles, WebSphere Process Server relationship service, Parts 1 and 2, listed in the
references section, take you through exercises that clarify how you would use both types of relationship
transforms.

Variables
To store data that you want to reuse, you create variables. A variable can be a source and a target for each of
the transform types described earlier. For example, if you have a value that you want to assign to many
targets, you can use an assign to set a value to the variable, then use a move transform from that variable to
multiple attributes.

As an example, Figure 12 shows a map with a variable named code that is populated with the value of
orderInfo.code. This value is used in orderItems.code and shipTo.code. Note that for this to work, the execution
order (indicated by the number on the left of the transform type) of the assign to the variable must be lower
than the targets to which the variable is mapped. Otherwise, the variable will be uninitialized when it is used.

Page 11 of 22
 Figure 12: Using variables

Human tasks
WebSphere Integration Developer helps you develop solutions that allow different computer applications to
work with each other. However, developing an integrated information system often involves supporting
interactions with humans.

Human involvement takes several forms. For example, a person might be required to initiate a process
instance that can then proceed on its own. A person might be required to deal with exceptional cases that the
logic built into the application cannot handle, perhaps because the case is considered too complex or special. A
case might also require human intervention because the normal processing has failed for some reason.

Having decided that a process should involve a human, developers are faced with the decision of how to
implement this functionality. WebSphere Integration Developer provides a human task component, which
greatly simplifies the work required to support human interaction with an SCA application.

A scenario for the involvement of a human in a service-oriented application is a process that requires a
decision from a person to approve an order before proceeding, as shown in Figure 13.

Figure 13: A decision made by a human within a process

Consider some of the requirements for the scenario:

• A mechanism to get data to and from the user

Page 12 of 22
• To be asynchronous and long running (because the human might not be able to respond immediately)

• An interface to enable the interaction. Since more than one process instance might require human
involvement at any one time, the user interface needs to show the processes waiting for input and it needs
to provide the details of a selected task

• A way to verify that the user has the right to perform the task

A human task satisfies these requirements, and provides a stand-alone component just like business processes
and business state machines. It communicates with other components using interfaces and business objects.
Figure 14 shows a human task component called ApprovalHumanTask, that the process shown in Figure 13 calls.

Figure 14: A human task component

However, human task components are unique because they support only a single interface that might have
only a single operation. This reflects the fact that a human task defines only a single interaction, multiple
interactions require multiple human tasks. Let's consider a file folder analogy. The folder contains information
required to identify and complete the task. The user adds any required comments or data to the contents of
the folder and returns it.

Human tasks are inherently asynchronous and long running. It would not be realistic to assume that a human
can process all requests immediately. Rather, tasks requiring human intervention must be managed on a
queue for completion when a human is available. Using our file folder analogy, imagine an inbox with a stack
of file folders waiting to be processed. Each will remain in the inbox until it can be processed and re-filed.

Types of human tasks

There are three types of human tasks, which we will look at in the next sections:

• Participating

• Originating

• Pure

Participating human tasks

In a participating human task, a component, such as the OrderProcessing component in Figure 14, calls a
human task component. In other words, the human task participates in getting work done.

Figure 15: A participating human task

Originating human tasks

An originating human task calls another component. Instead of being assigned work, it begins the process of
getting work done. An originating human task represents a human requesting something rather than fulfilling a
request.

Page 13 of 22
 Figure 16: An originating human task

Pure human tasks

A pure human task is similar to an originating human task because a human requests it. However, with a pure
human task, another human rather than a computer application fulfills the service request. In this case, the
application mediates interaction between humans.

Figure 17: A pure human task

Creating a human task

To add a human task to a module, select File - New - Human Task. The New Human Task wizard lets you
specify a name and container for the task. The second and third pages of the wizard let you indicate the kind
of task you want to create and specify its interface. The human task editor then opens for the newly created
task.

Now let's look at how you can configure human tasks.

Staff settings – roles

As you can imagine, you need a way to associate a human task with a specific person or any member of a
group of people who is qualified and permitted to complete the task. You can also assign roles (for example,
Potential Owner, Reader) to a human task so that specific access rights can be granted.

Page 14 of 22
 Figure 18: Staff settings

Client settings

WebSphere Process Server includes a built-in Web-based user interface, the Business Process Choreographer
(BPC) Explorer, for human tasks. This interface is suitable for testing and administration purposes, but it is not
meant to be used as a user interface for human tasks in a real-world application. The developer should develop
a custom user interface to display the contents of the task and allow the user to work on it.

WebSphere Integration Developer includes built-in support for two kinds of user interface implementations, but
you can add others via extensions. The supported user interface types are JSPs and portlets. In the client
settings area of the editor, you can select the kind of interface to supply and, in the details area, specify where
the interface implementation is located. References at the end of the article offer specific details about
implementing a custom interface.

Figure 19: Client settings

Escalation settings

When a user claims a task, the intention is to complete it within a reasonable period of time. However, there
are often circumstances that prevent timely completion. For example, the user might be waiting for additional
material before making a decision. What happens if the process that is calling the task might require a
response within a certain period? In response to such cases, a human task allows the developer to specify an
escalation to occur if a task is not claimed or completed within a certain period.

When a human task is invoked, it is either in the ready (not yet claimed) or the claimed state. Escalations are
like timers in a business state machine. When a task has entered a state, the escalation will trigger and carry

Page 15 of 22
out its specified action if the task does not leave the state by the time specified in the escalation. You can
specify a series of escalations where each one is triggered as soon as a duration expires and while the task
remains in the particular state.

Another state for a human task is the subtask state. When a user claims a task, the user can delegate a
portion of task to another user, which puts the human task in the subtask state. You can add escalations to the
subtask state to ensure that this portion of the task is completed so that the overall task can proceed.

Figure 20 shows a human task that will send a notification if the task is not finished within two hours. The
Verb tab contains the name of the person who will be notified if the escalation occurs. In the following sections
we will explore escalations in the application you will build. The references at the end of the article also offer
more information on using the Human Task manager and developing your own client to assign subtasks and
respond to escalations.

Figure 20: Escalation settings

Inline human tasks

Rather than existing as an individual component, an inline human task, which is another form of a participating
human task, is defined inside a business process. It is only accessible from within the process. One advantage
of this human task is that it can access the context of the process (for example, processes variables), allowing
multiple human tasks within the process to share information.

Figure 21: An inline human task

Page 16 of 22
Lecture 2 - Selector

Introduction
In the previous articles we looked at each of the service-oriented component types that you can build with
WebSphere Integration Developer, including business state machines, business processes, and human tasks.
We toured the overall programming model and various supporting tools, such as visual snippets and mapping.
We also explored the on-demand capabilities that WebSphere Integration Developer provides, such as how
using business rules helps you make your running application dynamic and flexible so that you can handle
changing business conditions without having to redeploy the application.

Simply put, you identify your key business decisions, create a business rule for the decision, and ultimately
make it configurable at runtime. For example, if the client is one of your best, perhaps you want to give him or
her a 20% discount. Maybe, on a particularly grumpy day, you want to lower that discount to 10%. Business
rules in WebSphere Integration Developer make it easy to be grumpy, or adjust other, more pressing business
needs.

The next piece of the on-demand puzzle is the selector.

What is a selector?
A selector is a dispatch pattern you use to dynamically determine which implementation of a component to
invoke at runtime. Like a rule group, a selector has date range entries, selection criteria, and a default
destination. You select a destination in a selector the same as your would for a rule group. That is, when a
selector is invoked, it selects a destination using the selection criteria and date range entries. A destination
could be any service-oriented component.

One major difference between a selector and a rule group is that the destination of a selector can be any
service component, while a destination in a rule group can be only a rule set or decision table. In other words,
a selector can dynamically re-route a service call to any other component at runtime.

You can call a selector from any of your service-oriented components. The selector’s job is to use dynamic
information to determine which component should be called to do the work. The set of destination components
is also configurable, allowing you to provide additional destinations at runtime. For example, imagine that at
the start of the new year (after all the confetti has been cleaned up) you want to switch your application over
to a new subsystem for inventory management. A selector allows you to provide two destinations and indicate
that the new one takes effect on January 1.

Let’s take the following business process shown in Figure 1 as an example. This business process is for
approving a loan application and has only two steps:

Step 1: Invoke a service to check for the credit rating.

Step 2: Invoke another service to determine if the loan should be approved.

Page 17 of 22
 Figure 1: Business process calling a partner service

The two invoke activities are hard-wired to target implementations in the assembly diagram. Let’s say the
business process invokes the low cost credit-checking service that Company A provides. What happens if the
service that Company A provides becomes unavailable during a certain period?

Such a situation is where selectors can help. As mentioned, selectors can decide which implementation to
invoke. In the next section, you will see how using selectors can let you change the destination of the service
call from Company A to another company's service which costs more, but is available 24x7.

Using a selector for simple dispatch

A basic use of a selector is for simple dispatch, which means you can dynamically reroute the destination of a
service call from one component or import to another. Let’s make the Invoke Credit Checking Service activity
in the business process now call a selector instead of being statically wired to the Company A service. It would
look like the following:

Figure 2: Using a selector for simple dispatch

The Invoke Credit Checking Service activity calls a selector that will decide at runtime which implementation
to invoke. The selector uses a selection criterion to choose a destination that is the desired service
implementation to invoke. The selection criterion could either be a current date, an XPath expression that gets
a date from a business object, or a Java snippet that returns a date. Just like rule groups, each destination has
an entry that specifies a range of dates in which this destination would be applicable. If the date returned from
the selection criterion is within the boundary of the date range entry, then the selector will use the
corresponding destination.

The date range entries are optional. If, in fact, no date range entry is supplied or if no date matches the
selection criterion, the default destination will be invoked. Keep in mind that if you do not specify a default
destination and no date range entry matches the selection criterion, then an exception will be thrown.
Therefore, it is best to provide a default destination.

Page 18 of 22
In Figure 2, the selector chooses the service implementation that Company B provides if the selection criterion
is a date in October 2006. The selector will run the service that Company C provides if the selection criterion is
a date in November 2006. For all other situations, the selector runs the service that Company A provides.

Figure 3: Using a selector to call a component in the same module or an export in a different
module

The destination of a selector can be a component inside the assembly diagram of the same module or an
export of another module. For example, Figure 3 shows the LoanProcess component wired to the
CreditCheckSelector. The selector can route service calls to either the CreditCheck component in Module A or
the Module_B_Export in Module B.

Keep in mind that the interface operations of the selector must match all of the interface operations of the
destinations. In other words, you may not select a destination that has an interface with a different operation
name, input, or output than the selector itself. If you try to use a selector where the operation name does not
match, then you get a ServiceRuntimeException saying the operation name cannot be resolved. If the input or
output does not match (for example, if the destination interface has a different input name or a different input
type), then you get a SelectorException saying the component does not support the operation.

If you cannot match the interface of the selector with the interfaces of the destinations, you can use a selector
with an interface map, which we described in the seventh article in this series, to convert from one interface to
another by using the interface map as a destination in the selector. Then the selector can invoke the interface
map that, in turn, calls the actual service implementation.

For example, Figure 4 shows a selector that can choose from two Web service imports, each having a different
interface. To reconcile the differences between each interface, the selector sets the corresponding interface
maps as destinations, rather than setting the imports as destinations. Then the LoanApplicationProcess
component can make credit-check service calls using the CreditCheck interface without worrying about which
import will be used, or the interface of the import.

Figure 4: Using interface maps with selectors

We have covered how you can use a selector in a simple dispatch scenario. What if your company were to
terminate the contract with Company A and replace it with a contract with Company B? Selectors can also help
in this situation.

Page 19 of 22
Altering existing destinations or adding new destinations
You can update or modify the destinations of a selector and their corresponding date ranges at runtime without
redeploying the original application. This means that in the previous example, you would not have to redeploy
the business process to modify the components you want to dispatch to through the selector.

Using the WebSphere Process Server administrative console, you can replace an existing service
implementation with another one, add a new destination with complete date range information, or remove a
destination.

Figure 5 shows an example of the actions that you can perform through the administrative console at runtime,
including

• Replace an existing component (Company Z as the new default)

• Change the date range (Company B moves to December)

• Add a new component (Company X in October)

Figure 5: Using a selector to dynamically alter destinations

After updating the selector in the runtime, you can optionally export the changes back to the development
workbench using the export function in the administrative console. The export function exports the module
project that contains the selector into a project interchange file, which you can then import into the
WebSphere Integration Developer workbench.

Later in the article, you will try this out by creating a selector that performs a simple dispatch. Then you will
update the destination of the selector using the administrative console. After that, you will deploy a new
module project and use the selector to invoke a service in the new module.

Creating a selector
This section describes the high-level steps involved in creating a selector. In the next section, you will get a
chance to actually build one yourself.

Creating a selector is similar to creating any other component in WebSphere Integration Developer. You start
by choosing the interface that your selector will support. Often, you choose the interface based on the
destinations that the selector dispatches to. Remember, the interface operations of your selector must match
exactly the interface operations of the destinations. This includes the parameters, whose types must match
exactly.

Page 20 of 22
When you first create a selector, it opens in a graphical editor, as Figure 6 shows, in which you can specify
more information.

Figure 6: Creating a selector

The first thing that you do is decide which of the following three selection criteria to use:

• Current date

• XPath expression

• Visual snippet or Java expression.

If you choose the current date criteria, then the selector
within the start date and end date of the destination. If you
specify the XPath expression that returns a date from the
criteria, you need to provide the Java code, which can be a
input variable.
selects a destination when the current date falls
choose the XPath criteria, then you need to further
input variable. If you choose the Java expression
visual snippet, that returns a Date object from the

After you decide which selection criteria to use, you can add destinations. Figure 7 shows the selection of a
default destination. As previously mentioned, it is a good practice to always supply a default destination. When
you click the default destination cell, it displays a list of available destinations to choose from. The list includes
the components in the same module or exports from other modules.

Figure 7: Selecting a default destination

The last step is to provide destinations that apply only to a specific date range. Optionally, you can leave this
section empty during development and modify it in the administrative console after deployment. You can also
alter the default destination at runtime.

After adding a date selection entry, you can select the destination from the list of available destinations, as
Figure 8 shows. There is no limit to how many rows you can add to the date selection table.

Page 21 of 22
 Figure 8: Adding additional destinations

Unlike other components on the assembly diagram, you don’t wire selectors to other components or imports.
Because the destinations in the selector are not statically bound, and because they might have destinations in
other modules, there is no need to wire the selector to any component.

Page 22 of 22