v3.3.0

What's Changed

• Tb 181 fix error handling by @bradsawadye in #209
• Tb 181 make endpoints unique by pattern and method by @bradsawadye in #210

Full Changelog: v3.2.1...v3.3.0

v3.2.1

What's Changed

• Support 'fhir+json' and 'openhim+json' content types for input and output by @bradsawadye in #206
• Tb 183 fix bug in reading lookup requests' responses by @bradsawadye in #208

Full Changelog: v3.1.0...v3.2.1

v3.1.0

What's Changed

• Update the README.md file to include special setup steps when setting… by @michaelloosen in #167
• Update node dependencies to latest by @MattyJ007 in #171
• OHIE-384 Reconnect Mongo by @michaelloosen in #173
• Bump nanoid from 3.1.25 to 3.2.0 in /docs by @dependabot in #179
• Bump follow-redirects from 1.14.4 to 1.14.7 in /docs by @dependabot in #176
• Bump shelljs from 0.8.4 to 0.8.5 in /docs by @dependabot in #178
• Add github actions for pushing and scanning docker images by @bradsawadye in #204
• Plat 718 add kafka input output by @bradsawadye in #205

New Contributors

• @michaelloosen made their first contribution in #167

Full Changelog: v3.0.0...v3.1.0

v3.0.0

New Features

Data to be mapped can now be extracted from the request headers and the response headers of look up requests. The response body of a look up request is now nested. Its now accessible through the data property. The lookupRequests structure has changed as shown below

// Before
{
  "lookupRequests": {
     "<id>": "<response body>"
  }
}

// Now
{
  "lookupRequests": {
     "<id>": {
         "data": "<response body>",
         "headers": "<response headers>"
     }
  }
}

The request headers are available under the property requestHeaders for mapping

v2.3.1

Fix Multiple Response Request Bug 🐛

• Ensure each response request sends through a copy of the data

v2.3.0

Dependency Updates

• Node Mapper module has been updated to include a new transform - passthrough

v2.2.2

Feature

This patch adds logic for parsing the lookup requests responses. This enables easy manipulation of the data in the mediator.

v2.2.0

Additional Feature (State management status code filtering)

Feature added was to cater for HTTP status codes in the states collection, and the user configuration to determine the range of status codes to do the lookup on for the last valid state record.
This is very useful if you require a state value to be used within the next request, but only values from the last successful state should be used. This can then be configured to ignore any failure requests and only make use of the last successful request (as defined by the implementer for the endpoint state management)

v2.1.1

Missing feature addition

This patch includes the missing feature added in 2.1.0
This includes the feature to allow externalRequests for responses to make use of an Array of data items and individually send them to the downstream destination

v2.1.0

New features

• Support for interpretation of an incoming array within a payload, and the sending of each individual array item as an individual request via the externalRequest feature.
• Storing of empty objects in the database to enable the endpoint state functionality to work.