Configuring Journal Indexing

This provides the useful illusion of a persistent back-end.

Configuring Journal Indexing on a Service (for Enterprise accounts)

This feature gives the user the ability to retrieve any part of a previously received request, or served response on the same service, and render it.

This provides the useful illusion of a persistent back-end. It uses it's in-memory journal which is a history of previous requests/responses processed, to achieve this illusion, hence this templating function's name {{ journal }}

As an example, this will give you the ability to have a POST or PUT endpoint which takes a product with a specific ID and then for example a GET endpoint on the same service which will retrieve the previously stored product based on it's ID and respond with it.

In the above example the service is told to index the journal based on the productId in the request body’s json.

When the first PUT request is made containing a productid and productDescription, Hoverfly stores the Request/Response pair in the journal and gives it an index key of 1.

Later on the client makes a GET to a different endpoint with the number 1 stored in the path at zero based index position 2. The template responds by calling the journal templating function, and telling it to use the index on the productId, and to retrieve the Request/Response pair using the index value that was passed in.

Once retrieved it renders the productDescription from the Response, using a jsonPath query.

Selecting the Edit Journal Indexing menu item from the ellipse to the right of the service on the Dashboard brings up the Configure Journal Indexing modal:

This capability is achieved through Hoverfly Cloud indexing all previous requests and responses according to a key that you provide, which identifies a part of a request. In the above example it is a query parameter called productId. Other valid examples might be:

Request.Body 'jsonpath' '$.productId' (If your request has a json element called productId in the body)

Request.Body 'xpath' '//root/productId' (If your request has an xml element called productId in the body)

A templating function is provided which then allows you to render any part of a previous request or response according to that key. The function is structured as follows:

{{ journal <request-index> <key-value-to-search-for> <request-or-response?> <query-type> <query-to-execute> }}                    

Here are a couple of examples of using the {{ journal }} function:

Example 1: Note the use of single quotes and brackets as required:

• <request-index> 'Request.Body jsonpath $.productId' - the literal string is passed in

• <key-value-to-search-for> (Request.Path.[1]) - this is a function therefore enclosed in ( )

• <request-or-response> 'Response' - the literal string is passed in

• <query-type> 'jsonpath' - the literal string is passed in

• <query-to-execute> '$.productDescription' - the literal string is passed in

{
  "productDescription": "{{ journal 'Request.Body jsonpath $.productId' (Request.Path.[1]) 'Response' 'jsonpath' '$.productDescription' }}"
}

Example 2: Similarly, note that strings are enclosed in quotes and functions in ( )

<?xml version="1.0" encoding="UTF-8"?>
<productDescription>{{ journal 'Request.Body xpath //productId' (Body.Request 'xpath' '//productId') 'Response' 'xpath' '//productDescription' }}</productDescription>

Important Considerations

The journal templating feature uses an in-memory history of the previous 1000 requests and corresponding responses processed by the API. The oldest requests are purged from memory once more than 1000 requests are processed. Thus to work correctly, your dataset must not exceed a maximum of 1000 unique items when using journal templating.