A tester or developer uses a web browser to access the console. The console manages the virtual service. The system under test (application under test) connects directly to the virtual service on different ports.
Here is an example of how that could look like for a scenario where the virtual service is replaying messages to an external queue.
Virtual service replaying IBM® MQ messages to and from a queueTo record from or replay to brokers you will need to tell Traffic Parrot how to connect to them.
Those connections are displayed in the dropdown menus on the record and replay panels, for example:
The "Internal broker" connection is available in the dropdown by default when you choose to use an internal broker in the Broker panel.
To define a new connection that will be available in the dropdown in the record and replay panels:[
{
"connectionId": "1",
"connectionName": "Test Payments Broker",
"connectionData": {
"ibmMqVersion": "IBM_MQ_7_5",
"hostname": "mqserver.example.com",
"port": 1415,
"queueManager": "PAYMENT.QM",
"channel": "PAYMENT.SVRCONN",
"username": "payuser",
"password": "paypassword222",
"useMQCSPAuthenticationMode": false
}
},
{
"connectionId": "2",
"connectionName": "Local docker MQ 9",
"connectionData": {
"ibmMqVersion": "IBM_MQ_9",
"hostname": "localhost",
"port": 1414,
"queueManager": "QM1",
"channel": "DEV.APP.SVRCONN",
"username": "app",
"password": "",
"useMQCSPAuthenticationMode": false
}
}
]
In the current Traffic Parrot version you edit connections directly in the ibm-mq-connections.json file. In near future you will be able to do it via the Web UI as well.
trafficparrot.virtualservice.ibmMqConnectionsUrl=classpath:ibm-mq-connections.jsonto for example
trafficparrot.virtualservice.ibmMqConnectionsUrl=file:/home/john/git/project/trafficparrot-ibm-mq-connections.jsonThis can be useful if you would like to version control it with your application source code.
To connect to IBM® MQ you need jar files provided by IBM that will allow Traffic Parrot to establish connections with MQ.
Before you proceed please read these instructions to double check your actions are inline with the supported way to install WebSphere MQ Java jar files.
If you do not have the required JAR files yet, follow the instructions to obtain them. These are typically found in /opt/mqm/java/lib on a UNIX system, but may be found in a different location depending on your environment. If you are using IBM MQ version 8.0.0.4 or later, you can also download the redistributable client images. If you have any issues with obtaining the jar files please contact us.
Copy those files to trafficparrot-enterprise-release-x.y.z/lib/external and restart Traffic Parrot.
As with HTTP recording Traffic Parrot, during recording incoming and outgoing messages are matched up to provide mappings. Then upon playback receipt of a matching incoming message will trigger generation of an outgoing message.
Before you proceed to recording or replaying messages make sure you have installed the required libraries (required JARs) so that Traffic Parrot can connect to the broker.
Traffic Parrot can form mappings in a number of ways.
The default is to use time based matching. This can be changed in the advanced parameter section of the record page.
Traffic Parrot does not support running IBM® MQ internally. You will need to use an external broker.
You can use one of the following:
One system generates messages onto a queue; another system consumes these messages and puts responses onto a second queue, which the first system consumes. If our goal is to test the system-under-test in isolation, we must record these interactions in order to replay them.
We will create extra queues on the existing broker that will be used by the virtual service. Then we will reconfigure the system-under-test to connect to these queues instead of the original ones. Traffic Parrot will move messages between these queues and the original queues, recording and creating mappings as it does so.
As the system-under-test generates messages they are listed in the bottom table 'Current recording session'. As the second system generates responses to these messages, they are also listed at the bottom, but in addition mappings are generated in the 'Mappings' table showing incoming and outgoing messages that Traffic Parrot has paired up.
To replay the recorded mappings we will need the same virtual service queues in place as shown on the image below.
Traffic Parrot does not support running IBM® MQ internally. You will need to use an external broker.
You can use one of the following:
One system obtains a temporary queue based on a model queue. It puts messages onto a request queue with the ReplyToQ set to the temporary queue. Another system consumes these messages and puts responses onto the temporary queue that was in the ReplyToQ field, which the first system consumes. If our goal is to test the system-under-test in isolation, we must record these interactions in order to replay them.
We will create an extra request queue on the existing broker that will be used by the virtual service. Then we will reconfigure the system-under-test to connect to this request queue instead of the original one. Traffic Parrot will move messages between the virtual and original request queue, recording and creating mappings as it does so.
Both the system-under-test and the virtual service will use a model queue that exists on the existing broker. This model queue will be used to create a dynamic response queue. Traffic Parrot will move messages between the virtual and original dynamic queue, recording and creating mappings as it does so.
Steps to record are similar to the usual recording steps but the response queues selected should be the same model queue name that exists in the external broker. In addition, the advanced parameter "Model response queues" should be set to "Yes":
To replay the recorded mappings we will need the same virtual service queues in place as shown on the image below.
Steps to replay are the same as the usual replay steps. Response messages will be sent to the queue mentioned in th ReplyToQ field of the request message.
Recording and playback of topics using an external broker is less intrusive than queues because Traffic Parrot can subscribe to a topic just like any other application and receive messages, without affecting the delivery of those messages to other applications.
This diagram shows how the production systems connect:
The system-under-test generates messages onto a topic which are received by a number of other systems. One of these systems generates responses onto a different topic (which are received by a number of systems, one of which is the system-under-test).
We will configure Traffic Parrot to connect to the request and response topics and record the messages appearing on both, generating mappings as it goes, as shown on diagram Recording topics using an external broker
will allow you to edit an existing mapping:
The request priority can be set in order to set up a preference order for matching mappings.
The highest priority value is 1. If two or more mappings both match a request, the mapping with the higher priority will be used to provide the response. The default priority is 5.
This can be useful, if you want a "catch-all" mapping that returns a general response for most requests and specific mappings on top that return more specific responses.
Traffic Parrot is able to record and replay messages that could contain text in a variety of formats e.g. JSON, XML or plain text.
This documentation is for an old version of Traffic Parrot. There is a more recent Traffic Parrot version available for download at trafficparrot.com