Message-based stubs overview

A message-based stub is essentially an HCL DevOps Test Integrations and APIs (Test Integrations and APIs) resource that listens for incoming messages on a particular transport. A stub can reply to specific messages or message-types, matched according to incoming filters, by using message case actions.

Benefits of stubs

Message-based stubs enable you to simulate services that you are unable to use or that may otherwise be unavailable.

For example, if you are testing a TIBCO BusinessWorks process but you do not always have access to TIBCO Designer, you can record the process events, create a stub from them, and then run the stub in place of TIBCO Designer.

Stubs can use most Test Integrations and APIs transports and schemas, including CHIPS, COBOL Copybook, Fedwire, FIX, SWIFT, and XML.

For example, a stub may be subscribed to an IBM® WebSphere® MQ message queue waiting for messages to arrive or it could be a web service waiting for a SOAP message to arrive over an HTTP connection.

Note: Some Test Integrations and APIs transports cannot be used in stubs.
Note: If you are using Test Integrations and APIs 8.0.1 or later, you can create REST-based stubs. Specifically, you can extract information from URLs and make the information available as tags in stubs, and Test Integrations and APIs will generate a Web URL schema.

Levels of richness

A message-based stub can be simple or rich. For example, you might want to simulate a single service that uses a single message case and the default case. Alternatively, you might want to simulate a web service or some other point-to-point operation that includes multiple message-types or operations.

The basic principles for simple and rich message-based stubs are the same because a specific reply is sent when a specific message-type is received, but there are some important differences:
  • A simple message-based stub will receive a message and (optionally) validate its contents. Based on the validation results or the fact that the message was received, the stub can return some static response, for example, a simple log action, a reply message, and so on.
  • In contrast, a rich message-based stub can receive incoming messages and, based on the specific contents of those messages, execute out a more extensive set of actions. For example, it might look up data in a database or spreadsheet, update one or more records in a database, use failure paths, and so on. Through the use of message cases and other actions, a stub can be configured to generate responses in an intelligent manner.