What are you looking for?

    Didn't find what you were looking for?

    Extend your Search in Community

    Got any questions?

    We're always happy to help with questions you might have. Contact Us

    Didn't find what you were looking for?

    Extend your Search in Community

    Got any questions?

    We're always happy to help with questions you might have. Contact Us

Journey Platform Topics

Transact Integration Gateway Overview

   Journey Manager  (JM) Previously known as Transact Manager (TM) |   System Manager / DevOps |  v4.3 & Higher   This feature is related to v4.3 and higher.

Note

Although Transact Integration Gateway (TIG) continues to receive support, it is recommended that Journey Platform solution builders move away from using TIG and instead use Journey Manager REST APIs to build Journey Platform solutions. Continuing to use TIG may complicate an upgrade path when TIG is eventually deprecated in a future release.

Overview

Transact Integration Gateway (TIG) is a lightweight gateway for performing on premise business integration. Customers using a cloud environment often have integration requirements for:

  • Dynamic data lookups or data validations to internal systems.
  • Straight through processing, when customers submit applications.
  • Background transaction delivery integration in internal systems.
  • Uploading form prefill reference data to the cloud servers.

Using the Transact Integration Gateway, customers can implement integrations like these quickly without additional software licenses.

If you already have integration gateway capabilities with solutions such as IBM Power Gateway or Mulesoft API Gateway, you may choose to use these. However, if you don't need the complexity of these solutions, the simpler Transact Integration Gateway may be suitable, and is an excellent option for performing delivery integration.

The Journey SDK for Java provides a Java API for Manager services, so you can build applications that integrate directly with them. Journey SDK documentation is included in the Journey SDK download package (authentication required) available on the Community web site.

Note

TIG is largely unchanged since TIG v4.3, so it is compatible with current Transact and Journey platform releases.

Usage and Deployment Models

The deployment model for TIG is to install the application on premise inside a DMZ or a secure location. The application is designed to be very easy to install and configure. You can literally install the application and perform transaction data delivery within minutes.

For High Availability (HA) deployment models you would typically install the two TIG applications on separate servers in different availability zones. TIG uses a stateless architecture, with configuration maintained in local JSONJSON (JavaScript Object Notation) is a syntax for storing and exchanging data and is used in Maestro to store forms. If a Form Builder wants to transfer their form to another system, they can do so by using the Download JSON file button. configuration files. There is no requirement for a shared database to support HA usage.

Delivery Integration

A typical use of TIG is to perform transaction delivery integration. In this deployment model, TIG is used to pull down completed transactions from the Cloud Hosted Journey Manager servers, and deliver this data into internal systems.

This usage model is illustrated in the diagram below.

For straight delivery integration, there is no requirement for TIG to be externally accessible. All network calls are outgoing from TIG to Manager servers. To complete transaction delivery, TIG needs to be able to write transaction data files to a secure and high availability file store such as a SAN, or it should be able to call other internal systems to complete delivery.

When internal transaction delivery has been completed, TIG will send a positive delivery confirmation message to the Manager server. Once this has been done, the transaction data on the server can either be deleted immediately or made available for scheduled data purging.

Service API Gateway

TIG can be used as a Service API Gateway to enable Cloud Manager servers to make real-time (synchronous) API calls to internal business systems. These calls are typically to perform operations like:

  • perform a security check before the user opens a saved form
  • prefill a form with the customer's profile data
  • make a form dynamic data call to perform data verification, such as Identity Verification (IDV)
  • straight through processing, when a customer submits an application resulting in an account being opened and the details returned to the user

This usage model is illustrated in the diagram below.

Operating as a Service API Gateway, TIG supports two modes of operation:

By using TIG as a Service API Gateway, access to internal systems can be strictly controlled and no internal network information is exposed externally.

Gateway Security

To provide security access control policies to protect internal Service APIs, we recommend a combination of the following security controls:

  • Transport Layer Security (TLS) protection for all network calls
  • IP address white list with TIG only accepting calls from configured Manager servers (configured on switch and TIG)
  • BASIC authentication over TLS, with TIG only allowing authenticated requests
  • Virtual Private Network (VPN) between business data center and AWS Virtual Private Cloud (VPC)
  • Mutual SSL authentication between Manager calls and TIG

TIG utilizes Apache for TLS termination and uses ModSecurity as an Web Application Firewall (WAF) to provided additional protection to the Service API Gateway.

Reference Data Integration

Another use for TIG is to upload reference data from business systems into Cloud Hosted Manager servers where it can be used for form prefill or form dynamic data.

This usage model is illustrated in the diagram below.

For uploading reference data, there is no requirement for TIG to be externally accessible. All network calls outgoing from TIG are to Manager servers.

TIG provides a Quartz Job scheduler facility which is used for performing background jobs. The job scheduler supports sophisticated CRONCron is a time-based job scheduler in Unix-like computer operating systems. People who set up and maintain software environments use cron to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals. expressions and simple interval based scheduling to invoke GroovyGroovy is a powerful scripting language which runs on the Java Virtual Machine. Across theJourney platform, Groovy is used to create services in Manager. These services are primarily used to create plug-in style systems that interact with Manager. scripts to perform integration tasks.

Next, learn about installing and configuring Transact Integration Gateway.

Feedback

Did this topic provide the information you need or leave you wanting to know more? Is there some way we can make this topic better? Let us know how we can improve this documentation.

Contact Us

Community

Our Community is a dynamic, user-driven source of information that provides a home for sharing Journey platform knowledge where you can ask questions and get answers quickly.

Explore Community

Support

Temenos is committed to supporting our customers with Journey platform solutions installed in the cloud or on premise. Learn more about our Customer Care Team, and its policies, procedures, and processes.

Learn More