PlatformApplicable to all products in Temenos Journey Manager. | System Manager / DevOps | v4.3 & Higher This feature is related to v4.3 and higher.
Although Transact Integration Gateway (TIG) continues to receive support, it is recommended that Temenos Journey Manager solution builders move away from using TIG and instead use Journey Manager REST APIs to build Temenos Journey Manager solutions. Continuing to use TIG may complicate an upgrade path when TIG is eventually deprecated in a future release.
You need a JDK installed on the system where you are installing Transact Integration Gateway (TIG). The JDK version you need is dependent upon the version of TIG you are installing, and can be identified as follows.
tig-version
) that you want to install. For example, if you want to install TIG v18.11 (tig-version
will be v18.11).jdk-version
) that is required when installing the tig-version
version of Journey Manager. For example, if you use Journey Manager 18.11, the JDK will be JDK 11 (jdk-version
= JDK 11).jdk-version
is the JDK version required when installing the TIG version identified in the first step. In this example, we need JDK 11 installed on our system in order to install TIG v18.11TIG and Journey Manager have been designed so that any version of TIG can communicate with any Journey Manager version. That is, you do not need to install the same version of TIG and Journey Manager.
If you're using TIG in your Temenos Journey Manager solution, you may also want to use Transact Client SDK when building that solution. While Transact Client SDK is no longer under active development, it is compatible with later Temenos Journey Manager versions, just like TIG. You can download the latest Transact Client SDK release which includes reference documentation.
A TIG Setup Wizard application is provided to enable fast and easy installation.
On a Windows server with a JRE available, TIG can be installed and running as a Windows Service within a few minutes.
TIG is configured through a series of JSON configuration files. These files are located in the configuration directory: C:\avoka\transact\tig\config\
Config File | Description |
---|---|
delivery-config.json |
Transaction delivery channel configurations |
proxy-config.json |
Service API Gateway proxy configurations |
services-config.json |
Groovy Services configurations |
scheduler-config.json |
Scheduled Grooovy script job configurations |
storage-config.json |
Submission data storage configuration |
The Groovy scripts directory is also under the configuration directory: C:\avoka\transact\tig\config\groovy\
This directory contains a number of sample Groovy scripts which are referenced in the groovy-config.json
file including:
delivery-email.groovy
delivery-example.groovy
google-search.groovy
job-example.groovy
template-example.groovy
The delivery configuration file defines transaction delivery channels to retrieve completed form transactions using the Manager REST Delivery APIs.
The sample delivery-config.json
installed with TIG is shown below.
{
"pollingIntervalMins": 1,
"deliveryChannels": [
{
"deliveryUrl": "http://localhost:9080/manager/secure/rest/delivery/v1/maguire/rest-service/",
"user": "administrator",
"password": "password",
"dataDir": "C:/tig/delivery/",
"subDir": "${submissionId}",
"processingStatus": "Thank you your application is being processed",
"serviceName": "delivery-example"
}
]
}
This configuration specifies a 1 minute polling interval to call the Manager REST Delivery API to see whether any new transactions are available.
The next element is a collection of delivery channels. A single TIG service can perform deliveries against many Manager Delivery Channels. For more information on how to configure a delivery channel, see the Transact Services Guide > REST API > Delivery API.
The JSON delivery channel attributes include:
Name | Description |
---|---|
deliveryUrl |
Delivery channel URL as defined for the Manager organization delivery channel's REST Service URL |
user |
Manager user login name. Users must have the REST Delivery role assigned to them, be assigned to Manager console access, and organization access. |
password |
Manager user password It is recommended that you configure specific REST delivery users, with only the REST Delivery role and no other permissions. |
dataDir |
Base data directory where form transaction data will be written |
subDir |
A pattern sub directory under the base This folder is used to separate different transactions. There are a large number of patterns which can be used to create sub directories for data delivery (see below). |
processingStatus |
A processing status message which is returned to the Manager server when delivery is confirmed and may be displayed to the end user who submitted the form. This is typically use to provided a message informing them that their application is being processed. This message has a maximum length of 100 characters; longer values will be truncated. |
deleteData |
A flag informing the Manager server to delete the transaction data immediately when it receives the delivery confirmation message. Use this option only if you have delivered data into a high available storage system, and you have very strict data retention policies. |
completedMarker |
A flag to specify whether to create a zero length This option is useful for folder watch deliver integration systems which will perform ELT operations when a marker signal file appears in a directory. |
serviceName |
The name of a Groovy script service to call when all the transaction data has been written into the delivery directory. Only delivery type services can be used for delivery integration. |
The subDir
pattern options include:
Pattern Variable | Description |
---|---|
clientCode |
Form's organization client code identifier |
formCode |
Unique form code identifier |
formVersion |
Form version number |
formStatus |
Transaction form status: [ |
portal |
Name of the portal or form space |
submissionId |
Transaction submission identifier |
receiptNumber |
Transaction receipt number |
submitKey |
Transaction submit key GUID |
trackingCode |
Transaction tracking code |
transRefNumber |
Transaction Trn Ref Number |
yyyy |
Year; for example, 2015 |
mm |
Month of year; for example, 08 |
dd |
Day of month; for example, 01 |
Note that TIG will monitor any changes to the delivery configuration file and make these available immediately. However if you change the polling internal configuration, you will need to restart the TIG service for this change to take effect.
The proxy configuration file defines internal services which may be called via Gateway Proxy calls.
The sample proxy-config.json
installed with TIG is shown below.
[
{
"route": "google-search",
"serviceUrl": "https://ajax.googleapis.com/ajax/services/search/web",
"connectionTimeout": 10000,
"returnErrors": true,
"parameters": [
{ "name": "v", "value": "1.0" }
]
}
]
This configuration specifies a collection of proxy services routes. The proxy attributes include:
Name | Description |
---|---|
route |
Proxy service route URL path |
serviceUrl |
Internal service API URL to call |
headers |
HTTP headers to add to the internal Service API call |
parameters |
HTTP request parameters to add to the internal Service API call |
basicAuth |
The HTTP Basic authentication header required to execute the call when performing a Service API Gateway call. The basic auth header is a Base64 encode username:password value. |
connectionTimeout |
The connection and socket transfer timeout in milliseconds for the internal Service API call. The default timeout is 10 seconds. |
returnErrors |
Return Groovy script errors to the caller when performing a Service API Gateway call. Use this option when developing scripts, but not in production. Default value is |
An example of the proxy routing configuration is shown below:
URL request from Manager to TIG:
GET https://service.mycorp.com/tig/proxy/google-search/?q=Avoka
TIG extracts gateway route path:
address-lookup
TIG looks up proxy route and makes internal call using the serviceUrl
, for example:
GET https://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=Avoka
The services configuration file defines Groovy script services which may be invoked via Gateway Service calls, via Deliveries or via Scheduled Jobs.
The sample services-config.json
installed with TIG is shown below.
[
{
"serviceName": "delivery-email",
"serviceType": "delivery",
"groovyScript": "$tig/config/groovy/delivery-email.groovy",
"parameters": [
{ "name": "emailUrl", "value": "https://outlook.office365.com/EWS/Exchange.asmx" },
{ "name": "emailUser", "value": "[email protected]" },
{ "name": "emailPassword", "value": "password" }
]
},
{
"serviceName": "delivery-example",
"serviceType": "delivery",
"groovyScript": "$tig/config/groovy/delivery-example.groovy"
},
{
"serviceName": "job-example",
"serviceType": "scheduled",
"groovyScript": "$tig/config/groovy/job-example.groovy"
},
{
"serviceName": "google-search",
"serviceType": "gateway",
"groovyScript": "$tig/config/groovy/google-search.groovy",
"groovyTypeChecked": false,
"executionTimeout": 10000,
"returnErrors": true,
"parameters": [
{ "name": "urlBase", "value": "http://ajax.googleapis.com/" }
]
},
{
"serviceName": "template-example",
"serviceType": "gateway",
"groovyScript": "$tig/config/groovy/template-example.groovy",
"parameters": [
{ "name": "Test Mode", "value": "false" }
]
}
]
This configuration specifies a collection of Groovy services. The service attributes include:
Name | Description |
---|---|
serviceName |
Groovy service name, should be unique |
serviceType |
The type of Groovy service: [
|
groovyScript |
A Groovy script file path The |
groovyTypeChecked |
Perform strict Java style Groovy type checking before executing the script. Default value is |
executionTimeout |
End execution of the Groovy script if it takes longer than the specified number of milliseconds. Default value is |
returnErrors |
Return any Groovy script errors to the caller when performing a Service API Gateway call. Use this option when developing scripts, but not in production. Default value is |
basicAuth |
The HTTP Basic authentication header required to execute the call when performing a Service API Gateway call The basic auth header is a Base64 encode username:password value. |
parameters |
Collection of parameters to pass to the Groovy script as a parameters map. This is useful for externalizing configuration values. |
TIG will monitor any changes to the Groovy configuration file and Groovy script files and make these available immediately.
Groovy services with the type gateway
can be called externally from Manager using the gateway service URL. The URL path is used to resolve the name of the service to execute.
An example of the gateway service configuration is illustrated below:
URL request from Manager to TIG:
GET https://service.mycorp.com/tig/service/google-search/?q=Avoka
TIG extracts service name path:
google-search
gateway
service type.Only services with the type gateway
can be called externally. Attempting to call a delivery
or scheduled
type service will result in a HTTP 404 Not Found
status code being returned.
The scheduler configuration file defines Quartz job schedules for invoking Groovy services. Only services with the scheduled
service type can be called by Quartz scheduled jobs.
The sample scheduler-config.json
installed with TIG is shown below.
[
{
"jobName": "Cron Job",
"jobType": "cron",
"cronExpression": "0 30 1 * * ?",
"serviceName": "job-example"
},
{
"jobName": "Simple Job",
"jobType": "simple",
"repeatIntervalMins": 10,
"serviceName": "job-example"
}
]
This configuration specifies a collection of Groovy service job schedules. The job schedule attributes include:
Name | Description |
---|---|
jobName |
Name of the job |
jobType |
Job type: [ |
cronExpression |
A cron scheduling expression, for |
repeatIntervalMins |
Repeat interval in minutes, for |
serviceName |
Name of the Groovy service to call when the job is triggered |
If you make changes to scheduler-config.json
, you must restart the TIG server for these changes to take effect.
The storage configuration file defines customer transaction data storage options.
The sample storage-config.json
installed with TIG is shown below.
{
"user": "administrator",
"password": "tuart!23",
"dataDir": "C:/tig/storage/"
}
The storage attributes include:
Name | Description |
---|---|
user |
The BASIC authentication login user This value should match the Manager TIG Service Connection Username. |
password |
The BASIC authentication login password This value should match the Manager TIG Service Connection Username. |
dataDir |
The customer transaction data storage area |
If you make changes to storage-config.json
, you must restart the TIG server for these changes to take effect.
The image below shows the Manager configurations for a Transact Integration Gateway Service Connection.
The image below shows a Manager configuration for the Hybrid Cloud Submission Data Storage service using Transact Integration Gateway.
Next, learn about developing with Transact Integration Gateway.