Skip to main content

Exchange Framework 1.4.0 upgrade guide

Automated response processing

This release introduces a huge step towards automated response processing. Instead of manually coding the response processor to parse and set individual fields in the Server VO, you can now use the @ResponsePath annotation in your Server VO to define where the data is and the response processor will automatically inject values from the raw response into the Server VO.

For example, say you have the raw response shown below:

{
"id": "a2970744-a97a-44f3-829c-95a8e6cd76c8",
"statedIp": "1.1.1.1",
"details": {
"ruleResults": {
"score": 80,
"rulesMatched": 1
},
"machineLearning": {
"mlValue1": {
"value": 640
}
}
}
}

You can define @ResponsePath as shown below to let the response processor inject values from the response into its properties.

public class MyServerVO extends TifServerVO {

@ResponsePath('details.machineLearning.mlValue1.value')
public String machineLearningValue

@ResponsePath('details.ruleResults.score')
public String score

public String id
public String statedIp

}

If the property name you defined matches the first level JSON field name in the raw response (such as id and statedIp), you don't even need to define @ResponsePath; the response processor will inject the value automatically by naming convention.

This feature supports both XML and JSON responses. In case of an XML response, you just need to define the correct xpath in @ResponsePath.

Better Server VO and Client VO definition

This release intrduces a much more elegant way to define your Server VO and Client VO. Use the @XPath annotation to simplify the definition of Server VO and Client VO.

Prior to this release, you needed to implement the abstract xpath() method to provide the xpath of your VO as shown below.

class MyServerVO extends TifServerVO {
static final private String XPATH = 'Provider/Product/Result'

@Override
public String xpath() {
return XPATH
}
}

Starting from this release, you can simply define your xpath value using @XPath.

@XPath('Provider/Product/Result')
class MyServerVO extends TifServerVO {
}

This works the same way for both Server VO and Client VO definition. We've also used the same pattern for the TifServerVO and TifClientVO base classes to define their root xpath using @RootXPath.

Support for Http Audit

In this release, the framework now supports the Http Audit feature. This gives you the ability to record your entire history of requests and responses as txn httpAudit properties for auditing purpose.

For example:

HttpResponse response = new HttpEvent(txn, "ServiceName", logger).execute(request)

To use this feature in your service, typically you define a service parameter as enableHttpAudit, create a HttpEvent object and inject into your TifService if enableHttpAudit is true, as shown below.

boolean httpAuditFlag = svcDef.paramsMap.get("enableHttpAudit")?.toBoolean()
// Create http audit event
HttpEvent httpEvent = httpAuditFlag ? new HttpEvent(txn, PRODUCT, logger) : null
YourService serviceSession = (YourService) new YourService()
.httpEvent(httpEvent)

We've also enhanced the standard http and SOAP calls, Utils.callHttpPost() and Utils.callSoapService(), to accept and use the HttpEvent object if available.

Here is an example in your API layer to trigger a Http Post call with Http Audit logged.

HttpResponse response = Utils.callHttpPost(endPoint, requestMessage, contextType, logger, true, username, password, httpEvent)
info

We've included the Http Audit feature in Iovation TAF project 1.1 so you can check out how it works in action.

The entire Http Audit implementation will be included in the TPac archetype (v1.3.0), from service definition, getting service parameter, injecting HttpEvent object into the service, passing it through API layer, and making the Http call using the HttpEvent object. So, when your next new TPac project is generated, it will already have this feature available out of the box (building and running correctly from day one).