PlatformApplicable to all products in Temenos Journey Manager. | All Personas | All versions This feature is related to all versions.
The Temenos Journey Manager enables digital interaction between an organization and its customers. Because of the importance of this interaction, there is often a need to integrate between the Temenos Journey Manager platform and other systems. In some cases, the integration required can be minimal, but integration can be quite extensive.
There are several key integration areas or stages in which integrations generally occur during transactions:
This is illustrated in the diagram below.
These integration stages are detailed described below.
Your users need to be able to discover the transactions that you provide. There are a number of ways to do this. The simplest is to have a link on your web site which launches the transaction.
Things can get more sophisticated than this. For example:
We want to make it as easy for your users to complete a transaction as possible. Transact is specifically designed to make the entire experience as intuitive and simple and engaging as possible.
You can make the data entry process even simpler by pre-populating (or pre-filling) information into the form that you already know about them, which means that they won't have to type the information themselves. Depending on what information is available, this can dramatically
We can generally provide the pre-fill data in one of the following ways:
Pre-population is also sometimes provided by using a previous submission's data to populate a new submission. This is useful when a transaction has to be repeated every year (or periodically). and the data doesn't change much from submission to submission.
During the data entry process, we want to make it as easy as possible for users to complete the form, and get the product or service they are requesting.
There are a number of ways we can do this. For example:
Data entry optimization is usually done using one of two techniques:
Execution is the process of adding additional value to the transaction after the data entry step. It can consist of a number of added-value steps, some of which require may integration with back-office or third party systems.
Some examples of added value integrations include:
Saving a form and returning to it to resume editing is an important capability. This is shown on the diagram for completeness, but is in fact implemented purely inside of Transaction Manager. There are no user-modifiable extension points.
Delivery is the process of delivering the results of the transaction, in both human-readable and machine-readable format, to the organization.
Of all the different points of integration, delivery is the most important. The reason is obvious - unless we deliver the data that was collected (in some way) to the organization, there is no value achieved for the organization.
The range of different delivery options is highly varied. It can be as simple as an email containing a PDF as an attachment which is processed manually, or as complicated as direct integration of different parts of the data into a number of different back-end business systems. Delivery can even be performed for transactions that haven't been completed by the end user, as this abandonment information can itself be useful.
Manager supports the use of both authenticated or unauthenticated transactions. Authentication is usually the process of identifying a user using a user-name and password, or sometimes more sophisticated methods. An unauthenticated user is a user who hasn't logged into Transaction Manager, and doesn't have an identity in Transaction Manager. This does not necessarily mean that they are unknown, and usually some information will be known about them, often including their email address.
Similar capabilities are available for authenticated and unauthenticated users, but are implemented in slightly different ways:
|Pre-population||A user's identity can be used to pre-fill forms with information that is already known about that particular person. This assumes that the user's identity already exists in an existing system.||Pre-population can still be achieved, but is implemented without the user actually logging in. For example, pre-fill data can be passed to the transaction using URL parameters.|
|Save and Resume||An authenticated user can save a partially completed transaction. By logging in again later, the user can view their partially completed transactions (known as drafts), and resume editing. The user can also log in from a different device.||Save and resume is implemented via a simple reference code and challenge question (similar to an airline booking code).|
|Transaction History||When an authenticated user logs into Transaction Manager, they can see the history of their submissions. (Note that they will usually only be able to see a summary of the transaction, not the content, because generally data retention policies will result in the details being purged.)||Transaction history can be provided to in a number of different ways, such as a confirmation email. Historical information is often maintained in other systems that maintain a more complete history of the customer's interactions with the organization, such as CRM systems.|
|Tasks||A task can be assigned to a user who is authenticated in Transaction Manager, and appears in their task list.||A task can be assigned to an unauthenticated user via email or any other system that can display a URL. The user will simply click on the link in order to perform the task.|
A question that is often asked is whether to use authenticated or unauthenticated access. Transaction Manager supports both types extremely well. However, it is important to note the following regarding authenticated transactions.
Because of the above, we generally recommend the following:
In some cases authenticated end users may be required for business reasons, and Transact does support this extremely well - but bear in mind that it may affect your time and cost of implementation.
Integration is performed in various areas of the transaction life-cycle though the use of defined extension points. Developers can inject code or other invocations at these defined extension points. The main points are shown in the interaction or sequence diagram below, although some extension points have been omitted for simplicity.
There are many different points in the life-cycle of a user interacting with a form, between the time that the user first clicks on a link to open the form, and the time that the transaction is complete. We won't go into all the details, since there are over 20 different life-cycle events, but some of the key events are shown in the diagram below.
Some of these points are handled by built-in capabilities within the Temenos Journey Manager platform, but others require integration with third-party or organization systems.
Manager provides extension points at many of these life-cycle events to allow integration between Manager and these other systems. The example of these extension points is shown below.
Each of the drop-down lists specifies a service that may be invoked at that particular point in the transaction life-cycle. You may select an existing extension point (as is shown in the Receipt Render Service in the screenshot), or you may create a new extension point by clicking the "New" button.
In order to build a new extension point, you author the extension point in a language called Groovy. Groovy is a simple yet powerful scripting environment that most developers find intuitive and productive.
When you create a new service, you are not simply presented with an empty screen and begin typing. Over the years, we have collected a series of templates from real projects that can be used as starting points for development of different types of services. A subset of the available templates is shown in the screenshot below:
The template will create a starter script which allows a programmer to simply "fill in the blanks" for their particular service.
Once you start building a service, you will often need to invoke external services to actually perform the work. These services will usually be exposed as either SOAP or REST web services. These services may already exist, or they may be built as part of the Manager project. They can be built in a number of different ways, including hand-built using coding languages, or the use of specialized integration system or an Enterprise Service Bus.
Libraries for calling these external services are built into the Temenos Journey Manager platform as shown in the example below.
This illustrates how easy it is to invoke these external services. Of course, more sophisticated services can be developed.
It is often also necessary to invoke Transact Manager itself in order to get more information from the system, or to update the transaction. This is also available through a set of comprehensive Transact API's.
It is almost always required to integrate a form into an existing web site. Usually this is achieve through a simple link or button. In the past, more complex integrations were performed, such as embedding forms within existing html pages, although in modern sites this is rare, largely due to the needs of smaller screens and mobile devices.
It is also sometimes necessary to provide single-sign-on integration with existing systems. This is provided by an extensible single-sign-on mechanism that is part of the security management sub-system within Transact. SAML, oAuth and two-factor authentication are supported. A screenshot is shown below:
Sometimes it is useful to perform integration directly between a form and another service. This can be performed in two ways:
Next, learn about the five Temenos Journey Manager platform integration areas.