Справочник Пользователя для IBM WebSphere Adapters

Your adapter may or may not be dependant on

″live″ data inside the EIS. If so,

you must either return the data to a known state after every test, or create a mock
implementation of the EIS API so that EIS data remains untouched.

In the setup method for outbound, perform the following step:
1.

Load any schemas (if necessary)

When you have completed the steps for setting up the test, you are ready to call
the CCI interaction and validate the result. The procedure below creates an object,
retrieves it, and validates its content.

In the test method, you will need to do the following things:

These tasks can be delegated to helper methods

1.

Create the data and metadata you will be working with (JavaBean, SDO, or
other format).

2.

Create a DataExchangeFactory for this data type, set the data as the bound
object

3.

Create a StructuredRecord and initialize it, with the Data Exchange Factory and
the metadata

4.

Invoke the adapter’s interaction.execute() using JCA CCI semantics

5.

Inspect the result of the output, by getting the bound object of the data
exchange factory of the output record.

1.

Create a new WBIRecord.

2.

Create a business object, populate it with data, and place it in WBIRecord.

3.

Set the appropriate verb in the business object.

4.

Call the interaction, capturing the output.

5.

Perform the assertions, which include the following:

v

Retrieving the object

v

Validating the retrieved object against the original data

For a detailed and coded example of this procedure, see
TwineBallInteractionTest.

In contrast to the outbound direction, inbound communication is not defined for
unmanaged operation. To test the adapter’s inbound capability outside of a JCA
container, you must implement some of the JCA container contracts. These include
the following:

v

BootstrapContext

– To obtain a reference to a work manager and a timer

v

InboundListener

and MessageEndpoint – For the listener client

v

MessageEndpointFactory

– To create endpoints

v

WorkManager

– To create work instances

v

Work

– To map to threads

For a detailed and coded example of these contracts, see the TwineBall sample.

WebSphere Adapters: WebSphere Adapter Toolkit User Guide