This item is scheduled for review.   Received comments are at the end of this page.

Please send any comments you have on the example using the Feedback Form.

Introduction

As no draft techniques appear to be available, various local definitions have been included in this document.

Definitions

What is Interoperability?

Within the SIGIST Interoperability is defined as: “the ability of 2 systems or components to pass information in one or more directions and to use the information that has been received.”

What is e-business?

E-business is shorthand for electronic business. Technology is a significant and necessary element in the execution of the business transaction[1]. E-business is often between two organisations, rather than from a consumer. Currently e-business is assumed to use web-based protocols.

Roles

For a given business transaction the two systems or components will have distinct roles. The roles can be simplified to two: the requestor[2] and the fulfiller[3]. The requestor makes a request of the fulfiller, which may send a response, if appropriate.

We will limit our view to considering the role presented to us e.g. from the pure requestor, the central system / component appears to be a fulfiller. In a similar fashion, the pure fulfiller views the central system / component as a requestor. The intricacies of the interaction within the combined requestor and fulfiller are outside the scope of this example.

Objectives of e-business/interoperability

To determine whether 2 systems or components will interoperate when in use for the expected range of requests and responses, in a variety of operational conditions.

Interoperability testing techniques

Most interoperability testing techniques are derived from functional testing techniques. The differences and variations are described within each technique.

Static techniques

Data-flow analysis

The key variation is that data is being passed between systems or components as either messages or other structured requests and responses. There are two types of data:

1. Content - relevant to the business transaction
2. Control  - information relevant to the request or response

The data may include optional elements, repeating groups, etc.

State-transitions

Are the message-protocols orthogonal and complete? I.e. for every combination of request and condition has an appropriate response been defined?

A formal process, similar to Inspections, is likely to be most suitable to analysing the message-protocols.

Dynamic techniques

Timing

The request/response process may be synchronous or asynchronous. Create test cases where the timing of the request/response process can be altered and see whether the systems behave correctly. Systems should recover gracefully from timeouts.

Interpretation of requests and responses

Interoperability assumes there is an interface between the two systems or components. Often interfaces are implemented with multiple layers, similar to the ISO 7 layer network protocol stack. Heterogeneous systems may interpret information differently, sometimes unintentionally. Some requests may be interpreted correctly, and others not, between the same pair of heterogeneous systems, other pairs may not interoperate at all.

Potential issues include:

Test example

Two e-business e-procurement software applications need to communicate a large corporation with an external supplier of stationery products. While the two systems both use XML formatted messages and claim to comply with the open ebXML[4] specifications this is the first time the two products have been linked together. All communication will be transmitted over a secure link. The applications will use and expect unencrypted messages.

Define the Operational Profile

Which messages will the two systems use? Are there any restrictions on the types or content of the messages e.g. for compatibility reasons? What is the frequency of likely requests and responses and what are the business rules that will be implemented in both systems e.g. how would a request for an out-of-stock item be handled?

Plan and execute tests

The key line-of-business transactions were identified as being most crucial and test cases will be required to exercise these under various conditions.

Data-flow analysis was used to determine that the two systems supported a common protocol for all of the key line-of-business transactions.

The conditions for a purchase order include:

The systems will be closely coupled and both will assume the other is online and available, however either system could queue requests or responses for up to 60 seconds. After 60 seconds requests that require a response should be rejected, as either the request or response may be invalid. For example another supplier may have received and accepted the order, or the supplier may have sold the same goods to another customer.

A test harness was created to allow delays to be interjected during the transmission of requests and the responses returned by the fulfiller.

Before the tests were executed both systems were configured to record all requests and responses in log-files. This would enable the test results to be captured more easily so they can be analysed to check for correctness and for any un-trapped errors.

Use test results to drive decisions

After executing the tests a number of important issues were found:

1. Higher than expected network latency meant that transmissions were sometimes taking up to 10 seconds longer than expected, therefore the responder was reconfigured to ‘time-out’ and request that had been waiting for more than 50 seconds.
2. The vendor of the buyer’s application used by the corporation needed to fix several errors related to the interpretation of ‘product not available’ and ‘account on stop’ responses from the supplier.
3. The vendor of the supplier’s application had to implement a ‘priority order’ indicator.

After retesting the system both the corporation and the supplier accepted the implementation and started using it fully.