Temenos Journey Manager Integration

   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.

• Integration areas occur at different stages within the interaction between a user and the organization.
• Within each integration area, there are different integration implementations, to support different technologies used by different organizations.

Integration Areas

There are several key integration areas or stages in which integrations generally occur during transactions:

• Transactions Discovery
• Data Pre-population
• Data Entry Streamlining
• Execution
• Save and Resume
• Delivery

This is illustrated in the diagram below.

These integration stages are detailed described below.

Transactions Discovery

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:

• You may want to have customized links, which are different for different users. Generally this is so that you can provide custom pieces of data in the link URL, generally so that you can pre-populate some of the fields in the form from this data. This helps to make it easier for users to fill out forms (see Pre-population below).
• If your users are logged into your web site, you may want to pass their identity to the transaction. This again allows the form to pre-populate some of the fields.
• You may want to embed the form into your existing web site, rather than linking to it. This is generally not recommended in modern responsive and task-oriented designs, although it is possible to implement with Transact.
• Another option is to send the user a link to the transaction using some other mechanism, such as via an email. You can send them a link to a blank form, alternately you can also use Transaction Manager to create a custom link that contains a partially pre-filled form to make their lives easier.
• Users can also save a transaction that they have partially completed. This will generate a custom link for them, that will enable them to return to the transaction at a later date. There are also other ways for them to get back to the transaction if they lose the link. You can configure a challenge question to ensure that only the original author can access their saved transaction.

Data Pre-population

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:

• Front-end data passing. If your existing web site knows who the user is, you can pass specific pieces of data about that user directly to the transaction. This can be done via URL parameters, cookies, lookup tokens, and a variety of other techniques.
• Back-end look-ups. If the user has been authenticated by your web site, you can pass their identity to the Transaction Manager server. We can then use this identity to look up information in back-end business systems, or Transaction Manager's own profile database, to pre-fill the form.

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.

Data Entry Streamlining

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:

• We can populate fields in the form from third party services, such as LinkedIn or Facebook. (This is similar to pre-population, but occurs once the form has already loaded, rather than prior to loading.)
• We can do calculations and lookups to provide them more information, or to validate their data entry. For example, we might verify the name of the account holder that they are trying to transfer funds to, or calculate the approximate repayments for their loan.
• We can provide them ways of speeding up their data entry. For example, instead of forcing them to type in an address laboriously, field by field, we can allow them to just start typing an address, and provide a matching set of possible candidate addresses, and then auto-complete the individual fields. (Like the address picker in Google Maps.)
• We can ask the user to upload a document, such as a photo of their license. We could use OCR technology to recognize the text on the document, and used to populate fields on the form.
• We can give the user real-time validation of their eligibility. For example, we could integrate with a credit scoring service to provide an indication about whether their loan is likely to be approved or not.

Data entry optimization is usually done using one of two techniques:

• Client-side integration. This occurs directly between the form (executing in the client's browser), and the information system. The LinkedIn pre-population widget is this type - no server-side installation or configuration is required.
• Dynamic Data. In this case, the form will invoke Transaction Manager, which will in turn invoke the actual service. Several Composer widgets are designed to work with Dynamic Data Services. Transaction Manager can provide added value, such as data and protocol transformation and security.

Execution

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:

• Adding electronic signatures using third-party eSignature solutions.
• Processing payments using third-party payment gateways.
• Retrieving credit scores or identity verification results using third-party services.
• Using Enterprise Document Management systems to generate documents or welcome kits to provide to the customer.
• Providing a review-and-approval step prior to delivery.

Save and Resume

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

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.

Authenticated and Unauthenticated Transactions

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:

Capability	Authenticated	Unauthenticated (Anonymous)
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.

1. Many organizations already have the concept of identity and usernames/passwords. Usually the organization will not want to introduce a new and different username and password, but rather re-use the existing mechanism.
2. Users are often reluctant to sign up with a username and password just in order to be able to save and resume a transaction later. (We have data that supports this assumption.) This can increase transaction abandonment, because users simply don't want to register. It's usually wise to allow users to complete a transaction without requiring them to register.
3. Identity can also be complicated to implement, especially the identity of your customers outside the firewall. Transaction Manager does support both common signon using LDAP, and Single Sign On (using SAML), but these can add complexity to the implementation.

Because of the above, we generally recommend the following:

• External customers be treated as "anonymous" users, without trying to establish or confirm their identity online. This may have a minor impact on their ability to pre-fill their forms (although there are ways to achieve this), but in general, treating them as anonymous dramatically simplifies the integration requirements, the security implications, and the time to market. As outlined above, most features in Transact such as save and resume, task assignment and pre-fill have been designed to work with either anonymous or authenticated users.
• Internal users (such as help desk and call center staff) be treated as authenticated users. This is usually much simpler to implement, since all internal users are already authenticated on the network, and both LDAP and SSO are relatively simple to implement.

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.

Extension Points

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.

Calling External Services and API

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.

Web Site Integration and Single Signon

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:

Form Level Integration

Sometimes it is useful to perform integration directly between a form and another service. This can be performed in two ways:

• Directly between the form and the service. This can be implemented directly using JavaScript in the usual way. Generally the integration will be packaged up into re-usable component that can be simply dropped into any form that needs it.
• Using Transact Manager as a proxy service. This mechanism is known as Transact Dynamic Data services. The form uses a standard mechanism for passing data in and out, which both programmers and non-programmers can easily use and configure. This invokes a service on Transact Manager (written in Groovy). The Groovy service has all the power of the Groovy programming language and supplied libraries, and so arbitrary complexity can be simplified to ensure that the service exposed to the form is easy to use. There are several advantages to implementing the system this way, including ease of use, centralized configuration, integration with Transact licensing audit logs, and more. This is the technique usually used.

Next, learn about the five Temenos Journey Manager platform integration areas.