Messaging transports, formatters, and dynamic formatters

HCL OneTest™ API uses a decoupled, plug-in architecture to provide maximum flexibility in regards to the messaging transport software in use by a system under test. A formatter translates messages from the native transport format (for example, TIBCO Rendezvous) to the internal format understood by HCL OneTest™ API, known as A3 (Accelerated Adaptor Architecture).

Transports

A messaging transport provides the information the HCL OneTest™ API needs to communicate with specific third-party systems (for example, TIBCO EMS and IBM® Integration Bus.)

The program code for each transport is contained in one or more JAR files (libraries), which are stored in HCL OneTest™ API "plug-ins" directory. Any libraries upon which these plug-ins depend must be accessible to HCL OneTest™ API. For example, if HCL OneTest™ API needs to work with TIBCO EMS messages, the EMS JAR files must be installed on the same computer as HCL OneTest™ API. The Library Manager is used to configure these third-party libraries. For more information, see Working with the Library Manager.

Transports are created when the corresponding logical resources (for example, an HTTP connection, a TIBCO EMS Domain) are created in Architecture School’s Logical View. The logical resources are then bound to testable, physical resources (created in Architecture School’s Physical View) that use one or more environments.

Transports are configured in the physical resources that represent them. For example, the properties of an HTTP transport are determined by the web server configuration to which the transport’s logical resource is bound.

Note: Starting in 9.2 you can also bind a File transport to a remote host so you can connect to and consume files from or publish new files to that host. See Adding a host to the Physical view.

Formatters

A formatter translates messages from the native transport format (for example, TIBCO Rendezvous) to the internal format understood by HCL OneTest™ API, known as A3 (Accelerated Adaptor Architecture).

For some formats, the specific message type (for example, Text, Map, Bytes) is selected within the message body. In these cases, it is the Message Type field – with the formatter – that determines the content/structure of the message body.

The following table lists the formatters that are available for each messaging transport.

Transport Formatters
File Byte Array, IATA, Text
HTTP Connection HTTP Message, Text, IATA
JMS JMS (message type that is configured in body)
TCP/UDP Byte Array
TIBCO EMS Domain EMS (message type that is configured in body)
TIBCO Rendezvous Bus TIBCO Rendezvous, TIBCO BusinessWorks Log
IBM WebSphere® MQ Broker Text, Byte Array, XML Text, IATA
webMethods Broker Domain webMethods Broker

Dynamic formatters

JMS-based and HTTP transports use dynamic formatters. For JMS-based transports, only one formatter is available at the top level, but the specific message type can be set within the message body. For HTTP transports, the HTTP Message formatter enables the use of Byte Array or Text message types to be selected within the body.
For both types, the selection of these top-level formatters enables HCL OneTest™ API to select the appropriate message type (for example, in Recording Studio) based on the content of the incoming message.

Feedback