Messaging transports, formatters, and dynamic formatters

Test Integrations and APIs 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 Test Integrations and APIs, known as A3 (Accelerated Adaptor Architecture).

Transports

A messaging transport provides the information the Test Integrations and APIs 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 Test Integrations and APIs "plug-ins" directory. Any libraries upon which these plug-ins depend must be accessible to Test Integrations and APIs. For example, if Test Integrations and APIs needs to work with TIBCO EMS messages, the EMS JAR files must be installed on the same computer as Test Integrations and APIs. 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.

Note: Starting in 9.2.0 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 Test Integrations and APIs, 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 Test Integrations and APIs to select the appropriate message type (for example, in Recording Studio) based on the content of the incoming message.