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 Library Manager.
Transports are created when the corresponding logical resources (for example, an HTTP connection, a TIBCO EMS Domain) are created in the Architecture School Logical View. The logical resources are then bound to testable, physical resources (created in the Architecture School 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 transports logical resource is bound.
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, Text |
| HTTP Connection | HTTP Message, Text |
| 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 |
| 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.