1

2
3
Interaction Framework is one of Temenos’ 6 enterprise frameworks that enable banks
to easily expose banking services to any user-interface(UI) or app, create innovative
combined services, and undertake highly efficient multi-device/channel UI
management. The framework separates user interface from banking capability.

4
The non-functional attributes that the frameworks improves for a bank are listed in
the table. For Interaction framework it is ‘Usability’. It enables banks to
• Remove rigid and complex code-based links between business systems and user-
interfaces (“UIs”)
• Build a highly flexible, internet-like, “many-to-many” network of back-end business
systems and UIs which can evolve at different paces
• Expose resources in a standard way, called “API”, so that UI designers both inside
and outside the bank can easily design UIs
• Build an open banking platform i.e. distribute resources from any business system
(owned by the bank or third-party) to any UI (in-house or third-party)

5
Before the era of digital banking, customers mostly interacted with their bank via
bank employees in the branch who used a PC-based interface. Bank employees
interacted with banking business systems (like Temenos Core Banking) via the
dedicated interfaces supplied with each system. For example, the interface supplied
with Temenos Core Banking (T24) was the Browser; the one supplied with Wealth
Front Office (Triple’A+) was the Web User Interface. Because each single business
system had a single user-interface tied to it, this kind of interaction was called “one-
to-one” interaction. (fig a)

But interaction has changed massively over the past decade. The omnipresence of
internet and the spread of virtual and mobile channels have turned even customers
into direct users of banking systems. The implication is that the bank has to deliver
data and functionality from multiple underlying systems through multiple interfaces,
channels and devices. Hence there is a shift from “one-to-one” interaction to “many-
to-many” interaction. (fig b)

6
The enterprise architecture of the modern bank consists of more than one underlying
product for e.g., Temenos banking capability, other banking capability and non
banking capability. Most banks implement separate agents for e.g., internet, mobile
and human adviser banking, executing across multiple platforms i.e., smart phones
and tablets apart from the web browser. Increasingly separate agents are being
created for roles like teller and portfolio manager.

This architecture would require a highly scalable user interaction architecture that
fully decouples the code that deals with user behaviour (i.e., User Agent UA) from the
code that deals with the business function (i.e., Resource Manager). As shown
interaction framework is a single framework across, that does this.

Interaction framework adheres to strict RESTful interaction patterns. REST

architecture makes it possible for a bank (or any enterprise) to build an internet-like
network of user-interfaces and business systems. By using URIs to identify resources,
HTTP to request resources and standard ways of delivering resources, any user-
interface can exploit resources from any business system without knowing anything
about how the underlying business systems are implemented. This enables the bank
to de-couple its interaction architecture i.e. get rid of rigid coded links between
business systems and user-interfaces, and evolve them at their respective paces.

7
Interaction vs integration

It is crucial to distinguish interaction from integration.

Interaction is about relations between systems and humans, via user-interfaces as a

request / response model, though the Interaction Framework supports asynchronous
calls.

Integration is about relations among systems as pairs of one way messages that are
always asynchronous.

Temenos’ Interaction Framework enables banks to build a highly flexible network

between multiple user-interfaces and business systems, while Temenos’ Integration
Framework enables banks to build highly agile working relationships between
multiple business systems.

Note: Many banks consider Open Banking/PSD2 to be an Interaction not an

Integration, hence Temenos is implementing the PSD2 solution via the Interaction
Framework.

8
• IRIS is a product that implements Temenos’ Interaction Framework. It makes the
bank’s Core Banking data and functionality (“resources”) readily available in a
standard way (called “API”) to any user-interface (“UI”) or app.

• The R18 release of IRIS is a lightweight, standalone edition of Temenos’ Interaction

Framework for T24(currently). It is highly decoupled from T24 and is T24 version
agnostic.

• IRIS R18 works with all currently supported releases of T24, reasons being
• communicates to T24 using OFS.
• has adapters and connectors to support all connection mechanisms to T24
– TCS, TOCF-EE, TAFJEE JMS interfaces

• It was designed originally to meet the API needs of Temenos PSD2 solution. Banks
within the EU / EEA countries must be able to accept account information and
payment initiation requests from regulated third parties provided they have the
customer’s consent to share the information. Temenos developed a set of APIs to
support PSD2 in IRIS R18.

9
IRIS APIs are RESTful and are developed in two variations – Provider APIs and
Published APIs.

Provider APIs are the building blocks, which orchestrates across and exposes
business capabilities from record keeping systems like Temenos Core banking (T24),
could also be other banking, non-banking capability, as a RESTful API using OpenAPI
specification (OAS) 2.0, fka Swagger. E.g., generic PSD2 API. IRIS R18 will only expose
core banking artefacts like version, enquiry or activity, that are specifically “designed
for APIs”. This ensures the provider APIs are strongly typed and consistently named.

Published APIs expose business capability to the outside world on the internet. They
are pre-defined, publicly exposed APIs that orchestrate across the provider API’s to
implement “standard” API definitions. E.g., OBA - Open Banking API as specified by
the UK’s CMA to meet PSD2 and beyond, BG – Berlin Group API to meet PSD2.

Note: This document uses the terms OpenAPI and Swagger, interchangeably.

10
When an interaction model is developed for Temenos Core banking record keeping
system and exposed as a Provider API, then the service,
1. can be consumed directly by Temenos product UA’s like TCIB, UXP browser which
understands our signature
2. can also be consumed by external APIs of Open UA’s that has its own interaction
model which is ready to receive our schema just as it is

Besides these two use cases, when Open UA’s publish a pre-defined or industry-
standard schema for e.g., PSD2 for OBA, BG, STET, then a Published API is developed
that maps and orchestrates the Provider API against the schema expected by the
open UA’s

Note : Event Engine is planned for development in later release and is useful for long
running queries. It registers call backs from API requests and instigates call backs
when events are received from the ESB. May be http call backs, web sockets, JMS,
etc. ESB subscribes to events published by the Integration Framework.

11
Under the hood, IRIS R18 relies on open standards like Apache Camel, Open API
specification and Spring to expedite development of RESTful APIs for Temenos core
banking (T24) resources.
Apache camel is an open source project from Apache. It’s an embedded runtime and
a light weight ESB. It implements all enterprise integration patterns (EIPs) and offers
a standardized internal domain-specific language (DSL) to integrate applications. The
core functionality of Apache Camel is its rule based routing & mediation engine. A
camel route contains flow and integration logic.
IRIS R18 uses camel to define REST endpoints and implements the required routing
logic using camel routes. Camel routes contains IRIS camel processors and beans to
transform the JSON request message into appropriate OFS message and vice versa. A
connector establishes a connection to transmit the constructed OFS request to T24.
OFS response from T24 is parsed by IRIS and returns a JSON response to the UA.
Thus camel has 3 tasks to do - mapping, orchestration and transformation.
• Map – map T24 field names with interaction field names
• Orchestrate – identify downstream systems, execute parallel requests, aggregate
responses etc.
• Transform – transform JSON to OFS and vice-versa

12
OpenAPI specification (OAS) 2.0 is used for documenting our REST API developed
using IRIS R18, i.e., It specifies the format (URL, method, and representation) to
describe the services in a schema document. Service catalog hosts this API
documentation and facilitates discovery by developers.

Mocking provides a way for our APIs to return sample responses even when T24 isn’t
capable of providing one. For e.g., when the API façade is designed first, and the
backend implementation comes later or is worked upon in parallel or when the
backend is temporarily not operational. In such scenarios, static mock response files
generated at design-time by IRIS tooling from swagger definition of the API are useful
for API developers or UA developers to proceed with implementation and testing.

IRIS R18 uses Ehcache which is an open source java caching library for cache
implementation like caching of data during pagination, metadata etc.

Workbench is the design-time web tooling to simplify and manage API development.

13
On a TAFJ environment, IRIS uses JMS connectors to connect to T24. The incoming
message is put in a queue. The MDB listening on the queue picks the message,
forwards to the EJB which acts as an interface to T24. IRIS picks the T24 response
from the reply queue.

14
Interaction Framework allows a single Provider API to fulfil multiple Published APIs,
i.e. Temenos product teams create a single generic API that can be re-used. For e.g.,
Generic PSD2 implementation that doesn’t meet any specific standards.

Banks can then take the generic provider APIs and build published APIs on top of
them, meeting country specific standards. E.g., PSD2 for OBA, BG, STET.
Customisation can also include extending and modifying the provider API.

15
Before UA’s can start consuming resources from the Core Banking system (T24), the
bank needs to build an API to expose them. This is called “design time”.
1. Design API specific version, enquiry and AA resources in T24 following the design
rules for strong data typing and field names.
2. Browse T24 for functionality to expose through the interaction service using the
workbench and generate an inventory file for the resources
(version/enquiry/activity)
3. Generate IRIS resources like OpenAPI definition and camel routes. Import these
generated artefacts into design studio service project to design the REST business
API. Enhance artefacts for API orchestration as needed.
4. Build and package these resources along with its dependencies into a web
application. Deploy the web application to an Application Server. This Java web
application is the actual “API” that makes the banks resources readily available to
any UA.
5. Discover the industry standard API documentation for UI development for e.g.,
into Temenos user experience platform. Consume and test using a REST client
6. The interaction artefacts can be stored into a SCM tool

16
The workbench allows browsing T24 only for API specific resources and automates
generation of the API artefacts. The artefacts generated are
1. An inventory of the T24 version, enquiry and activity selected in the workbench to
be exposed in the service
2. OpenAPI (Swagger) definition for the T24 resources
3. Camel XML, also referred as service XML with routing and integration logic
The scheme (http/https), API service name and version of the API along with the
domain and resource path assigned for a T24 resource, becomes the resource URI
path. Domains are highest level of grouping for APIs. The workbench validates the
names assigned for domains, resource path etc against a vocabulary list during
service artefact generation.

17
After the web application is deployed in the banks application server, the RESTful
service can receive requests from UA’s.
Consider a customer using an interface e.g. a mobile banking app on an iPhone.
When this customer requires, for example, her account balance from the Core
banking system, the iPhone app will send a simple industry-standard HTTP request to
the API in the bank’s application server. The HTTP request contains three things:
1. the URI of the resource that is needed
2. a standard HTTP request about what to do with this resource e.g. “GET” to simply
fetch the resource and present it to the customer
3. an indication of industry-standard format in which the mobile app sends the
actual data e.g. application/json
As soon as the API receives the HTTP request, the request payload, if present, is
transformed to OFS and the request is routed to the downstream Core banking
system. It sends in return the requested data to the interface in a simple industry
standard JSON message format. The response message contains the data required
i.e. the account balance amount in this example

18
Key differences between Provider and Published APIs

Provider API is a layer above T24 and talks directly to T24. It creates OAS definition
for T24 artefacts that are to be exposed through the service. Whereas, Published
APIs consume OAS definitions of the end consumer and orchestrates to suit the
requirement of the internet.

In the Provider API, query URL parameters are mapped to Core banking (T24) enquiry
selection criteria. The published API, maps URL parameters to Provider API
parameters and response to OAS of UA.

Mock responses are generated from inventory of T24 artefacts in a Provider API. For
a Publisher API, mock responses are based on the OAS examples of UA.

Service catalog hosts API documentation for discovery of both Provider and Published
APIs

19
Versioning is a crucial part of API design, since APIs will be improved over time and
updates to the API contract will be made. Clients may not want to update their
applications as the API changes. A versioning strategy allows clients to continue using
the existing REST API.
• IRIS follows the SemVer specification for its APIs – vMajor.Minor.Patch. Major
version is incremented when a breaking change is introduced. Minor and Patch
versions are incremented for backward compatible functionality updates and bug
fixes respectively.
• Provider APIs and Core Banking (T24) API artefacts like versions and enquiries are
implicitly versioned and move through the SDLC together
• Adopt one of the following versioning strategies for APIs, when there is a change
• By URL path - /api/v1.0.0-1/
• By query parameter - api/v1.0.0/products?version=1
• By custom headers - curl -H “Accepts-version: 1.0”
• Based on the version in the request, the request can be routed to the correct host
in infrastructure components like API gateways, reverse proxies or even in the
interaction framework (not recommended).

20
Before you proceed, recollect the terminologies introduced and their meaning w.r.t
interaction framework.

21
A quick introduction to the technologies and tools used by IRIS is given in this
document. A comprehensive study on these is not in the scope of this learning
material.

An API is an interface that makes it easy for one application to 'consume' capabilities
or data from another application insulating the consumer from all of the complexities
of the back end system.

REST is now the most prominent architectural style used to expose web services to
third parties over the internet. It uses the HTTP standard.

22
REST stands for representational state transfer. The term was introduced and defined
in 2000 by Roy Fielding in his doctoral dissertation. REST is an architectural style for
networked hypermedia systems. The REST architectural style is applied to the
development of web services referred to as RESTful services. Services can be
characterized as "RESTful" if they conform to the architectural constraints of REST
listed in the slide.

Interaction framework follows REST interactions because the stateless nature of the
RESTful interactions are essential for T24 to achieve Enterprise or Web scale.

23
The REST constraint ‘Uniform Interface’, is a primary differentiator of RESTful web
services from others. It states that all services and service consumers within a REST-
compliant architecture must share a single, overarching technical interface.
Consumers access service capabilities via methods, media types, and a common
resource identifier syntax
Resource Identifier Syntax (URI)
In REST, primary data representation is called a resource. A resource can be a
singleton or a collection. Resource identifiers represent the actual resources that a
service exposes. REST APIs use URIs to address resources.
Methods
A method is a type of function provided by a uniform contract to process resource
identifiers. The most common type of protocol technology used in REST architecture
is HTTP. HTTP provides us with a set of generic methods, such as GET, PUT etc. that
are pre-defined in the HTTP specification.
Media Types
When defining methods for REST services, we can further specify the types of data a
given method can process. IRIS uses application/json as the media type for the
representation

24
Camel documentation reference - http://camel.apache.org/

25
Swagger provides tools to generate/compute the documentation from application
code. It scans the code and exposes the documentation on a unique URL. Any client
can consume this URL and learn how to use the REST web services: which HTTP
methods to call on which URL, which input documents to send, which status code to
expect, etc.

Swagger documentation reference - https://swagger.io/

26
Maven is a project management and comprehension tool. Maven provides
developers a complete build lifecycle framework.

Maven uses the concept of a repository which is used to hold build artifacts and
dependencies of varying types. Repositories come in two flavours: local and remote.
Remote repository is a place where all the standard jars are available. The local
repository is a cache of the parts from the remote repository that are needed to build
the source. It also contains temporary build artefacts that are not yet released.

Downloading in Maven is triggered by a project declaring a dependency that is not

present in the local repository (or for a SNAPSHOT, when the remote repository
contains one that is newer). By default, Maven will download from the central
repository.

Repository details are configured in the configuration file settings.xml in configuration

folder.

27
Postman is an HTTP client that runs inside Google Chrome. Another example is ARC.
They are an efficient way to test RESTful web services.

28
29