Exchange Framework

Exchange This topic is related to the Avoka Exchange. | Platform Developer | v5.1 & Higher This feature is related to v5.1 and higher.

Exchange Framework (TIF) v1.5.0 release

The Exchange Framework (TIF) makes it easier for developers to build integrations on Journey products in a more efficient, standardised and scalable manner to reduce the ongoing costs of upgrades and maintenance. Everyone is encouraged to use the framework to build their next integration.

The Exchange Framework v1.5.0 is a significant release with two major features:

A standard fluent function base class for integration purposes that provides the most commonly used code for a typical integration fluent function. The code pattern in this class has passed hundreds of regression test cases that provide you with a reliable foundation so you can save time and concentrate on your specific project code.
A powerful standard response processor out of the box that dramatically reduces the code required in your main fluent function and the code required to manually parse the raw responses.

A standard fluent function base class

This base class provides the most commonly used code for a typical integration fluent function below:

All initialized variables like logger, svcDef, txn, inputParams, user, appDoc, applicantRole, and fluent function results
Setup service module
Standard input parameters injected (recordResponseInTxnProperties, recordResponseInTxnXML)
Standard milestone events on start and complete
Standard exception handling and update of server VO and client VO when required

The code pattern in this class has passed hundreds of regression test cases that provide you with a reliable foundation so you can save time and concentrate on your specific project code.

A powerful standard response processor out of the box

Previously, you needed to create a response processor subclass and write code to process the raw response field by field and generate the Server VO and Client VO manually.

From 1.4.0, we started to provide simple annotations, that lets the response processor inject certain values from the raw response into the Server VO automatically. We go much deeper in 1.5.0, with a lot more auto response processing capabilities, as shown below, to finally provide a fully working response procesor out of the box, that saves you time parsing the response manually.

Client VO auto-processing by annotation
Properties auto-matching between Client VO and Server VO
Auto data value mapping
Turn response directly into Map object in VO and filtering on the result
JSON string as a single property
Clear VO properties when Errors Happen
Default error handling in response processor

With this release, the framework dramatically reduces the code required in your main fluent function and the code required to manually parse the raw responses. We strongly encourage everyone to upgrade and start using the framework to build your next integration.

Exchange Framework (TIF) v1.6.1 release

We are pleased to add the built-in configuration service support in this release so that your fluent function using TIF will automatically be compatible with the configuration service with the following features without any extra code:

Triggers the specified configuration service on demand.
Uses the config data from the configuration service if available, otherwise fall back to the original service connection and service parameters from the service definition and make those up-to-date config data available to your fluent function.

Other updates to the Exchange Framework in this release include:

Provide the capability to disable the Journey Analytics milestones in the Fluent function base class.
Add capitalized Key annotation to match the capitalized tag name convention in Txn XML that generated by Server VO/Client VO (default is true)
Add get and create form/organisation property in Utils class
Add request object access in the base fluent function
Support mocking a Groovy service or fluent function in MockUtils
Support mocking a GET request in MockUtils
Fix a minor issue in Utils.exceptionToString() method