When Traffic Parrot receives a request via any protocol or technology like HTTP, JMS, gRPC and others, it will try to simulate the system it is replacing by sending back a response to the client that sent the request.
To decide which response to send, it will go through all the request to response mappings it has available to find the response to be returned.
A request to response mapping defines which response to return given a request.
For example, in HTTP, you could say:
For any request to URL '/hello' that is a GET request return a response with body 'Hello World!'
The way you do that in Traffic Parrot is by using the user interface to record mappings, import them or add them manually.
Traffic Parrot support matching attributes of requests using the following matchers.
|HTTP(S)||list of HTTP(S) matchers|
|JMS||list of JMS matchers|
|Native IBM MQ||list of MQ matchers|
|gRPC||list of gRPC matchers|
|Files||list of files matchers|
Traffic Parrot stores request to response mappings on the filesystem.
|HTTP(S)||mappings and __files (where it stores bodies of responses during a recording)|
|Native IBM MQ||ibm-mq-mappings|
You can change the root directory by changing the value of the trafficparrot.virtualservice.trafficFilesRootUrl property.
XPath (XML Path Language) is a query language for finding and selecting elements in an XML document. Traffic Parrot allows to match requests using XPath.
We recommend the following reading to users who would like to take their XPaths skills to an advanced level:
This documentation is for an old version of Traffic Parrot. There is a more recent Traffic Parrot version available for download at trafficparrot.com