What is TruService?
TruService is a standalone application or service that is responsible for:
- Encapsulating all TruRating business logic associated with the TruRating Application
- Providing questions to TruModule
- Storing Ratings, Transaction Data and Basket Data
- Communicating securely via HTTPS with the TruRating Host (TruHost)
- Supporting initial activation andongoing activation management
- Providing a wide variety of functionality enabling many other value added features for current and future releases.
TruService works in tandem with TruModule, our name for the component that natively interfaces with the existing Payment and POS Application.
Where can TruService run?
TruRating offers a fully managed cloud TruService SaaS solution hosted in Microsoft Azure. Service instances are load balanced, geo-replicated and redundant across 3 continents for optimum reliability and scalability.
Connectivity is secured by TLS and authenticated via a MAC header.
TruService can run on a back-office server either within a partner’s network or merchant’s network.
TruService can run as a Microsoft Windows service or a Linux daemon on Point of Sale hardware.
Communicating with TruService
The choice of where TruService is deployed and the method of communications selected (HTTP, HTTPS) will have a small impact on the performance of the interface. However, please consider the following guidelines:
Generally we recommend that TruModule waits a maximum of 250ms for TruService to respond to request once it’s been delivered. If TruService has not responded to a request within this time then the application should continue without TruRating for the current transaction (see section below on network performance)
TruModule is not required to retry any exchanges with TruService that fail, either due to a timeout or error response. If TruModule cannot complete an exchange with TruService on the first attempt then the application should continue without TruRating for the current transaction
If TruService returns an error response to TruModule then the message that TruModule was attempting to deliver should be discarded and the application should continue without TruRating for the current transaction
TruModule should not disable the TruRating feature following a failure of communications with TruService, unless the reason for the failure is determined to be something that cannot be rectified without intervention
It is strongly recomended that TruModule support the TruService RequestQuery command and in particular the ‘timetolive’ setting in order to minimise intreractions between TruModule and TruService for merchants whoose accounts are not active or have been temporarily suspended
When communicating with TruService and configuring the timeouts for exchanges the potential performance of the network over which the communications are routed must be taken into consideration. Having TruService deployed locally within a store versus in the cloud will naturally make a difference in performance. Network traffic during peak periods is also a consideration when communication with TruService is being done on a network that experiences peak periods where performance can decrease.
Load Balancing and Traffic Management
Where the Cloud SaaS deployment is used multiple TruService instances are avaialble and can accept incoming connections from TruModule. Instances are geographically located to maximise performance and response times.
An important facet of the traffic routing method is described below:
- Traffic Manager reads the source IP address of the DNS query and decides which geographic region it is originating from. It then looks to see if there is an endpoint that has this geographic region mapped to it. This lookup starts at the lowest granularity level (State/Province where it is supported, else at the Country/Region level) and goes all the way up to the highest level, which is World. The first match found using this traversal is designated as the endpoint to return in the query response. When matching with a Nested type endpoint, an endpoint within that child profile is returned, based on its routing method
- Traffic Manager does not receive DNS queries directly from clients. Rather, DNS queries come from the recursive DNS service that the clients are configured to use. Therefore, the IP address used to determine the region is not the client’s IP address, but it is the IP address of the recursive DNS service. In practice, this IP address is a good proxy for the client.
Generally speaking once a TruModule instance has resolved to an instance of TruService, it will remain communicating with this TruService instance. However, if local DNS servers are based in different geo-regions then it is possible for traffic to alternate between TruService instances and between regions. If you anticipate that in your environment or your merchant environments that this could occur then raise this with your TruRating technical contact to discuss options.
This is because each regional TruService instance has a local Redis instance configured as a local database. Redis databases are not currently synchronised. Therefore data loss will occur if TruModule connects to different instances of TruService during a session (i.e. a POS transation or Payment).