Architecture Overview 4

5/21/2019 Architecture Overview
You are here: Home > Front Office - PM > Front Office > Architecture Overview
https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 1/26

Architecture Overview
Introduc on
This product guide presents an architectural overview of the Front Office - Por olio Management (PM) solu on and its different modules. It is intended for
architects, developers and technical consultants wishing to familiarise themselves with the architectural concepts.
You may wish to complement the reading of this architectural overview by learning more about Front Office - PM features. Finer details may be found in the
following suggested documents:
WealthSuite Front Office - Por olio Management - Gateway Reference Guide

WealthSuite Front Office - Por olio Management - System Management Guide
WealthSuite Front Office - Por olio Management Web - Design Studio User Guide
WealthSuite Front Office - Por olio Management Repor ng - Technical Guide
WealthSuite Front Office - Por olio Management Web - CDM Configura on Guide
WealthSuite Front Office - Por olio Management Web - CDM User Guide
WealthSuite Front Office - Por olio Management Web - Design Studio–based Installa on Guide
WealthSuite Front Office - Por olio Management Web - TSL Opera ng Guide
Prerequisites
The Front Office – PM architecture is centred on its financial servers. Financial servers act as specialised calculators providing computed por olio-related data to
requesters. In order to perform load balancing and avoid performance bo lenecks, several instances of financial servers may coexist.
User data (i.e., por olios, instruments, prices, clients, contacts, and other types of data) is centrally stored and secured in a set of databases managed by a single
instance of Sybase Adap ve Server Enterprise (ASE). Apart from financial servers, data from the databases is handled by many requesters, be it in read-only mode or
in read-and-write mode.
The following image shows the overall architecture of the Front Office – PM solu on:
The main components of the above image are:
GUI: A graphical user interface developed with a ‘client-server’ technology. It offers func ons such as data administra on, system
configura on, security administra on, and financial data display (text or graphics).

WUI: A web user interface that presents raw data and financial calcula ons data to end-users.
Design Studio: An Eclipse-based applica on generator used to design the WUI pages and page transi ons.
IMP: A command line u lity that performs bulk data loading as well as data extrac on.
Gateway: Based on IBM WebSphere TX, the Gateway offers a flexible way to transfer data to and from Front Office - PM.
Interfacing with a back-office system is typically done using the Gateway.
Repor ng: Actuate-based repor ng system. Reports may be launched from the GUI, the WUI, or in batch mode. Produced reports
may be fed to a document repository.
Main concepts
This chapter describes the following main concepts of the Front Office – PM architecture:
Financial server
Data layer access
Triple’A Plus Service Layer
Front Office – PM Web architecture
Task management
Security
Subscrip on mechanism
Financial server
The financial server process is at the heart of the Front Office – PM architecture. The financial server is a mul -purpose program that executes func ons upon
request from other programs. For load balancing purposes, several instances of this program may run simultaneously.
The following image illustrates the Front Office – PM financial server:
The financial server rests on the following key concepts that provide a high configurability and enable the financial servers to adapt to the needs of many
ins tu ons:
Meta-dic onary
User-defined (UD) a ributes
Script language

Formats
Meta-dic onary
The meta-dic onary is a set of database en es that describe, in an enhanced manner, the Front Office – PM data model. Among other features, it has the following
capabili es:
Dynamic screens (GUI mode only).

Import and script languages parsing.
Enumerated values control.
Secure objects genera on.
Transparency of user-defined a ributes.
Ease of label transla on.
User-defined a ributes
It is not possible to produce a data model that caters to each and every need. As a result, Front Office – PM delivers a set of a ributes that describes its domain in a
standard manner. To allow the tailoring of the product to specific needs, the Front Office – PM data model, and therefore its databases, can be enriched with user-
defined a ributes.
Once defined, thanks to the meta-dic onary, these new descriptors become an integral part of the data model and inherit all the characteris cs of standard fields.
User-defined en es
Since Release 12, following the same ra onale as for user-defined a ributes, the standard data model can be augmented by user-defined en es. As described in
the meta-dic onary, these en es inherit the full set of features of a standard table such as wide choice of data types, foreign keys, labels, check constraints, and
many more.
User-defined en es are defined using Design Studio (see chapter Design Studio).
When you extend a Front Office – PM data model with user-defined en es, you are able to:
Administrate these en es with the Front Office – PM

Import data using the interface process
Build a web front-end based on these en es to read, create, update, and delete these en es.
Script language
The Front Office – PM script language is a domain-specific language (DSL) developed alongside Front Office – PM from the onset. It is a collec on of statements such
as:
Business func ons

Data access func ons
Condi onal statement
Logical, comparison, and arithme c operators
Comments
The script language is used to declare many defini ons such as format elements (see sec on Formats), default values, input controls, or business constraints. The
financial server performs all parsing and valida on of Front Office - PM script code through the script engine and with the help of the meta-dic onary defini ons.
Formats
Besides pre-defined unalterable financial calcula ons, such as the integra on of new opera ons in por olio posi ons (fusion mechanism), an extremely powerful
feature offers the ability to define what data is computed and displayed for each business func on and the manner in which the data is displayed. The configura on
capability is about the number of result sets presented to the users as well as their elements. In Front Office - PM terminology, the former is named a format and the
la er are format elements. Formats may be displayed under many forms, such as detailed or summary lists, matrices, tables, or even graphics.
Format elements are defined either using a Sybase Transact-SQL syntax or the na ve Front Office - PM script language, the la er being the preferred language.
Other mechanisms
Default value
A default value is used to complete a data field with a predefined value. This value is expressed in script language syntax. This means that it is a constant, a computed
value, the content of another field, a mathema cal, or a financial func on.
Input control
The input control func on is designed to validate the data entered in Front Office - PM. It is expressed in script language syntax.
Filter

Filters let you define which data is available in a field. Use a script defini on to apply the filter to an a ribute in an en ty. The filter restricts the list of available
op ons in a list of enumerated a ributes and dates or sets the foreign key. An example of this is restric ng dates to display working days only.
CRUD (Create Read Update Delete)

The financial server provides a single and unique interface for handling all write opera ons on the data. The advantage of using an RPC (remote procedure call)
mechanism is that all the business logic described above is always applied on data modifica on opera ons.
Data layer access

The Front Office - PM databases are fed either by means of bulk import u li es (Gateway, Import) or by users through the GUI or the WUI (applica on server not
illustrated below).
The databases may be divided into the following groups:
3 Front Office - PM databases

2 Triple’A Plus Service Layer (TSL) databases
1 Front Office - PM Web database
Data is split across several databases for two reasons. The first one is to allow the set-up of different backup strategies. Typically, the TSL group of databases contains
a database that holds temporary computed data stored in private transient tables and a second database that holds data refreshed periodically (i.e., recomputable).
The former does not require back-ups at all and the la er, should the men oned periodicity be daily, would logically require daily back-ups. To compare, the main
database of Front Office - PM would probably require an incremental back-up strategy in many cases.
The second reason for having mul ple databases is legal. Indeed, depending on na onal regula ons, customer related data may have to reside physically in the
country of opera on of the bank or bank subsidiary. Yet, for opera onal reasons, it may be more prac cal to have the other databases in another geographical
loca on.
The following image illustrates the Front Office - PM data layer access concept:
Client Data Management (CDM)-related data is secured via an internal mechanism based on a hierarchy of privileges that can reflect the most complex organisa on.
Furthermore, it can be encrypted to further protect it. Encrypted data can only be accessed using the Front Office - PM dedicated CDM user interface.
En es of Front Office - PM and TSL are applied a security scheme that forbids regular database users to view or modify their data. Such users are granted rights only
on specific secure objects. For further details, see sec on Security.
The following image illustrates the Front Office - PM data access concept:

These secure objects offer a transparent unified logical view on up to three en es, as illustrated in the image above. A short explana on of these en es follows:
En ty: Regular rela onal table holding the standard a ributes

UD: Rela onal table with a 1:1 rela onship with the en ty offering the ability to customise Front Office - PM by adding a ributes.
Once defined, these user-defined a ributes are seen as part of the system. Like standard a ributes, they are fed either by means
of bulk import u li es or manually.
Ext: Rela onal table with a 1:1 rela onship with the en ty offering the ability to store values pre-calculated by the financial
server. This typically allows a fast retrieval of data for dashboard purposes.
Triple’A Plus Service Layer

For readers already familiar with previous releases of the product, Triple’A Plus Service Layer (TSL) can be seen as the new flavour of Triple’A Plus Smart Component
(TASC).
TSL brings much more to Front Office - PM than what TASC did. Not only does it offer the compa bility for TASC calls, it also brings many new features and
contributes to a be er integra on between the WUI and the financial server. As well, TSL offers a dynamic interface to CRUD opera ons, described in sec on CRUD
(Create Read Update Delete).
The main new features of TSL are:
Extended a ributes
Search enhancements
Local caching
Global caching
DBResultSet versus InMemoryResultSet mode
Rule-based engine
Extended a ributes
As already men oned in sec on Data layer access, Front Office - PM secure objects may offer a view over several en es. From the onset, each major en ty has
been associated with a second en ty (1:1 rela onship) that is a container for user-defined a ributes (see sec on User-defined a ributes). Since Release 11, Front
Office - PM, through TSL, brings the no on of calculated fields. These fields (or a ributes in rela onal terms) belong to a table stored in a separate database to that
of the base en ty or UD en ty, the TSL permanent database (see sec on Data layer access for reasons of the split).
Whereas the base and UD en es are fed either manually or through the batch import u li es, the extended en ty holds data computed by the financial server
upon request by TSL. The rule-based engine (see sec on Rule-based engine) provides a mechanism that guarantees a certain level of synchronisa on of the
extensions with the base data. However, the overall computa on process has to be scheduled at the desired me intervals using an external scheduling u lity (e.g.,
crontab).

The Front Office - PM formats (see sec on Formats) are used as the central mechanism to compute the value of each extended a ribute. A master format composed
of empty format elements provides the defini on to the system for the ini al crea on of the extended en ty, hence providing a one-to-one mapping between the
master format and the extended en ty.
Child formats linked to the master format are used for compu ng the values of each a ribute; there must be at least one child format, but there may be several.
Child formats must be returning one and only one row. Formats of SQL nature may also be used as child formats. They will be processed last and therefore may not
reference previously computed values. Not all format elements need to be mapped to an a ribute.
The Front Office - PM secure objects may also contain non-materialised calculated a ributes. This is currently an advanced feature configured by means of meta-
dic onary (see sec on Meta-dic onary) mappings.
The following image presents a schema c view of the no on of TSL extended a ributes:
Formats used for the defini on of extended a ributes do not have to be dedicated to that purpose. They may also par cipate in other computa ons for display
purposes, for example. This means their defini on may use the full set of features reserved to formats (e.g., foreign key resolu on).
Search enhancements
Ajax auto-complete fields have become standard features in modern user interfaces. Such mechanisms are generally widely agnos c in the sense that the end-user
expects case and accent insensi ve searches performed against mul ple transla ons of several a ributes (e.g., code and denomina on in French, English, and
German). The SQL language is of course able to handle such complex queries against normalised database schemas; however, response mes do not match the user
expecta on.
To fully enable Ajax auto-complete fields, the TSL permanent database holds a set of tables prefixed with “vs_” standing for ver cal search. There exists one vs_ table
per queryable Front Office - PM en ty.
Taking the Front Office - PM table “instrument” as an example, the image below summarises the mechanism of the search ver calisa on. A stored procedure
launched by the rule-based engine (see sec on Rule-based engine) reads the meta-dic onary tables to discover the tables, a ributes, and languages to ver calise.
A er capitalising all a ributes and conver ng accented characters according to conversion rules stored in a table, it populates a set of tables composed of four
a ributes that are used in turn by the WUI processes to perform fast data searches.

The system will apply the data security so as to present the user with a result set that complies with the user’s level of privileges. The size of the result set for Ajax
auto-complete fields is defined at design me per en ty (with Design Studio).
The data retrieved corresponds to a match with a criteria expressed in SQL with a like statement of type "begin with" for the auto-complete and of any type for the
search pa ern. For example, if the user typed into an auto-complete field with the characters ACM, the underlying database query will be expressed using the search
argument like 'ACM%'.
With regards to the accent insensi vity of the mechanism, it must be noted that the desensi sing offers only one transla on. It means that, for example, the string
"Kür" could be converted to "KUER" or "KUR" but not both. Consequently, the table tasc_accent_conv should be populated with care and in compliance with the
current standards of the bank.
Local caching
Since Release 11, Front Office - PM brings a major change in the way the applica on server behind the WUI requests data from the financial server, which helps
reduce the memory footprint of financial computa on requests in the applica on server.
The following image illustrates the TSL local caching feature:

As shown above, the major change lies in the use of the TSL temporary database that now acts as a cache to store the results of a financial server computa on. The
major benefit is that, instead of returning the full result set(s) related to a computa on to the applica on server, only one page of WUI display is returned at a me.
The no on of “local” stems from the fact that the transient tables created in the TSL temporary database are not shared between WUI processes, hence avoiding
security breaches. A clean-up process is run periodically to remove all deprecated computa on-related tables.
Global caching
Keeping performance op misa on as the main focus, a logical mechanism to implement beside the local cache was one to minimise requests for online
computa ons from the financial server. Indeed, not every implementa on needs online computa on. In that case, pre-compu ng some financial results may offer
drama c response me improvements.
To readers familiar with TASC, global caching is a refactoring of the no on of TASC pre-computa ons. Since Release 11, Front Office - PM offers integra on with local
caching as shown in the image below:

Two main paths are shown in the image: the periodic computa ons (e.g., during night- me batches) in do ed lines, and fetching and complemen ng global cache
data in plain lines.
DBResultSet versus InMemoryResultSet mode

The DBResultSet mode uses the TSL database infrastructure to store (local cache) the output of financial func ons and to allow for pagina on at the database level.
The TSL database infrastructure is mainly intended for the processing of large sets of data (e.g., large lists of por olio, large results).
For small queries requiring few computa on resources, consider using the InMemoryResultSet mode, which disables the use of TSL local and global cache. This will
lower the burden of crea ng the cache infrastructure (stored in database) and assist with obtaining faster response me. The data is fetched directly from the
financial server and stored in memory.
The InMemoryResultSet mode is currently enabled by default for the OData Applica on Programming Interface (API) and can be ac vated/deac vated by
customisa on at the Front Office – PM Web level for any requests. In this mode, if valid data is present in the TSL global cache, it is automa cally fetched from the
global cache instead of being computed.
Rule-based engine
Having pre-computed data can offer drama c response me improvements over online calcula ons. However, as updates occur on the data, applying relevant
changes to the caches can become challenging.
To offer a configurable change propaga on mechanism, the Front Office – PM financial server instance that plays the role of dispatch server is also performing, in a
separate thread, another task as illustrated below:
https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 10/26

Triggers created on Front Office – PM main en es populate, during each insert, update or delete, the table object_modif_stat with the primary keys impacted by a
given transac on. Based on a set of rules stored in the table data_dependency, the rule-based engine reads object_modif_stat and cascades the impact down along
with its dependencies to a minimum set of three tables that are in turn be processed for periodic recalcula ons of the different caches.
The la er recalcula ons are tasks launched by the Front Office – PM internal scheduler. See sec on Scheduler for details on the scheduler.
The mechanism may also be extended either at the object_modif_stat level, or at the rule-based engine level, or both. Indeed, as all en es of the concept are
meta-described, they inherit all the related inherent features (e.g., default values). Data import files may be loaded into object_modif_stat using the standard Front
Office – PM import u lity.
Note that the objects change no fica ons sent to the table object_modif_stat by the triggers defined on all Front Office – PM en es may be deac vated during the
import process by launching it in op mised mode.
For more informa on about the TSL rule-based engine, refer to the WealthSuite Front Office - Por olio Management Web - TSL Opera ng Guide.
Front Office – PM Web architecture

The WUI is a J2EE-compliant Web applica on (refer to sec on Prerequisites for a schema c view). It uses general J2EE technology such as servlets, XML, and XSL and
relies on XML parsing and transforma on provided by Xerces and Xalan.
Based on the Apache Cocoon framework, the WUI is a dynamic Web applica on based on XML content that is transformed dynamically into HTML or other output
channels (e.g., PDF). For chart genera on, the WUI relies on Domo PopChart.
An overview of the WUI is provided in the following sec ons:
Technical framework
Presenta on framework
Apache Cocoon
PopChart
Installa on and migra on framework
Technical framework
Among the many general func onali es provided by the technical framework, the WUI, as a presenta on layer, uses excep on handling, logging, configura on file
loading, and security.
The logging framework outputs useful logs in the configured folder of Front Office – PM Web. The debug verbosity levels can be changed at run me.
A security layer provides Front Office – PM (and non-Temenos) components with a way to grant secured access to the applica on’s func onali es and data.
The technical framework integrates the well-known Spring framework such as the dependency injec on and Spring remo ng.

Presenta on framework
The presenta on framework contains general user interface components.
A generic presenta on layer called Uniform Data Presenta on (UDP) is carries out all the processing necessary to display data correctly. These func ons include
grouping, sor ng, paging data, displaying columns in the correct order, compu ng new columns on the fly, compu ng aggregated group values, and forma ng
numbers and dates.
The menu component allows the crea on of a mul -language, secured menu that highlights the currently selected menu item and temporarily disables parts of that
menu.
The mul -profile component handles the different WUI user profiles. It decides at run me which menu and pages to display according to the user's currently
selected profile.
To ensure consistent variable management across the whole applica on, the framework contains a context management facility called Scope, which is in charge of
storing informa on during specified life mes.
User preferences can be remembered for later connec ons, including the chosen language, me zone, or user profile, as well as column choice in tables or sor ng
op ons.
The presenta on framework includes a pageflow engine, which allows for crea ng wizards (i.e., sequence of pages and ac ons that corresponds to a business task).
To do this, the pageflow engine controls the flow, executes the transi ons between the different states, and calls the business processes associated with the
transi ons. Since Release12, the pageflow has been replaced with a new stateless and lightweight engine that enables new naviga on concepts like module flows
(i.e., flows anima ng modules and not only whole pages).
Apache Cocoon
Apache Cocoon (h p://cocoon.apache.org/2.1) is an XML publishing framework that raises the usage of XML and XSLT technologies for server applica ons to a new
level. Designed for performance and scalability around pipelined SAX processing, Cocoon offers a flexible environment based on a separa on of content, logic, and
style. In addi on, Cocoon's centralised configura on system and sophis cated caching help you to create, deploy, and maintain robust XML server applica ons.
Cocoon interacts with most data sources, including file systems, RDBMS, LDAP servers, na ve XML databases, and network-based data sources. It adapts content
delivery to the capabili es of different channels such as HTML, WML, PDF, SVG, and RTF. Cocoon also offers mul -language func onali es and is integrated with the
pageflow.
The Cocoon framework is completely integrated into the WUI and is hidden from end-users. However, a developer must have an understanding of how the Cocoon
framework works and how to use it.
PopChart
PopChart is a server that provides interac ve image renderings of business graphs and charts. With PopChart, these dynamic images can be of different formats
including Flash, SVG, PNG, and JPEG. Refer to the WealthSuite Front Office - Por olio Management - Product Compa bility document for ways to ensure
compa bility between products.
Installa on and migra on framework
Deployment Package Installer (DPI)

The Deployment Package Installer (DPI) is a distribu on file that contains the necessary features to deploy a given Front Office – PM Web implementa on (i.e., a
par cular version of Front Office – PM Web with a par cular implementa on type for a par cular applica on server and database combina on). It is a self-
contained, self-executable installer jar file. Combined with an installa on proper es file and a distribu on package, the DPI can be executed to fully deploy Front
Office – PM Web.
The Update Installer is designed to automate and guide you through the Front Office – PM Web installa on process. It supports all applica on servers and systems
listed in the WealthSuite Front Office - Por olio Management - Product Compa bility document. The installer is an executable jar file, which provides a pageflow to
help users define installa on proper es and orchestrates the deployment of Front Office – PM Web using repositories in a one-step process.
A customisa on package can be produced with Design Studio and integrated into the installa on process. It enables you to industrialise the installa on of your
different environment such as development, test, and produc on environment.
Hence, the installa on is fully, automa cally done without manual interven on. The installa on package is based on maven framework.
Smart Migra on tool (SMIT)

Based on an XML defini on of the target database structure for a given release, SMIT will align any exis ng Front Office – PM Web database. A post-upgrade check is
performed against the theore cal image. SMIT is embedded in the DPI.
Mul -instance installa on

Mul ple Front Office – PM Web instances can be deployed side by side using the same Front Office – PM instance. This may be required for many reasons such as:
Load balancing / Failover

Different usages (e.g., WUI, OData server for Wealth Channels, batch, etc.)
Different versions (e.g., older versions of Front Office – PM Web that is in line with Front Office – PM as well as more recent
versions of Front Office – PM Web used as OData server that is in line with Wealth Channels versions)
Different geographic loca ons (e.g., Front Office – PM Web instance in Switzerland, Front Office – PM Web instance in
Luxembourg, etc.)
For more informa on, refer to the WealthSuite Front Office - Por olio Management Web - Installa on Guide.

Task management
Managing the tasks involve the following components:
Job Launcher
Scheduler
Job Launcher
Job Launcher provides a distributed and asynchronous infrastructure to either process pre-defined TSL jobs or site-specific Java services implemen ng mandatory
interfaces. A job will generally be given a scope to work on; either a single object or a list of objects. In the la er case, the list gets "sliced" into chunks executed in
parallel.
The general architecture is illustrated in the image below:
The main parts are:
The JobLauncherBatchManager, which handles the loading of the batch defini on and its execu on. First, a
BatchDefini onLoader is used to retrieve the batch defini on. Then a JobConfigura onMapper does the mapping to a job
configura on, which is passed to a JobTypeSelector to determine the correct job type. Finally, it uses a
JobLauncherControlService configured for the job type to execute the batch.
The JobLauncherControlService, which usually runs on a remote applica on server (for scalability reasons, this enables the usage
of clustered environments and let the cluster decide on what instance the job instance will be run). It posts the job instance in a
queue. Then a JobInstanceExecutor first executes a pre-job (in our case, this consist of the DomainLoader which loads the domain
for the batch and the DataSlicer, which cuts the data into chunks). Then it executes the sub-jobs defined for the batch on the
sliced chunks.
The monitoring infrastructure, which provides exact status of a job instance at any me. It is used by the
JobLauncherControlServer and each JobInstanceExecutor and by the subjobs to monitor each step of a job execu on. The
implementa on stores each piece of informa on in a database, which can be consulted in the Monitoring and Administra on
Console in the WUI.
The Job Launcher is technically configured using the file o -services.xml and uses a JobConfigura on to describe what the job actually performs. Its principal features
are:
Two distributed implementa ons: using java.u l.Concurrent or using CommonJ, a joint approach from BEA and IBM for
concurrent threads managed by applica on servers.
Fully configurable queues and thread management.
Queue and thread monitoring and sta s cs through JMX.
Job monitoring is in the database and viewed from the Monitoring and Administra on Console in the WUI.
Cancella on and retry of jobs.
Split and retry

Should the execu on of a chunk fail, Job Launcher is able in certain cases to split the original chunk into single objects and then retry. This offers the double
advantage of maximising the number of objects processed successfully and allowing the easy iden fica on of the culprit object.
Scheduler
The Scheduler component provides other components of Front Office – PM a way to schedule any kind of programma c ac ons for different implementa ons of
Scheduler, at different given me intervals.
Currently, the following is implemented:
Mul ple scheduler defini ons in configura on.

Local schedulers, running in the same VM as the caller.
Remote schedulers (RMI, with op onal JNDI look-up).
Custom scheduler capability.
Programma c login for secured ac ons.
In-memory scheduler.
Database persistent scheduler.
Security
Where security is concerned, we must first split Front Office – PM into the following main blocks:
PMS security
Channels and Channel Profiles
CDM GCL
Both Client Data Management (CDM) and Por olio Management System (PMS) func onali es may be fully autonomous, hence the do ed line below between the
CDM User and the WUI manager. What this means is that as soon as CDM needs to have access to PMS-related data, a mapping must exist.
PMS security
GUI mode only

Whenever the WUI is not implemented, a GUI user corresponds to an actual physical person. This person is primarily granted a set of rights to use the different
business func ons (func on security profile) as well as rights to access the secured data (data profile).
Each secured data such as an instrument or a por olio is assigned a security label (data security profile). The data security profiles are then grouped into data
profiles and a GUI user is assigned a data profile.
For traceability purposes, it may be a good prac ce to map one physical user to one GUI user.
WUI mode
For implementa ons that also contain the WUI, a WUI manager must be linked to a user or a GUI user. The GUI user has a Sybase login to access the GUI to inherit all
required business profiles (e.g., func on security profile, screen profile, report profile, printer profile, and data profile).

Third-party access
Front Office – PM Web supports third-party access, which means that you can log into Front Office – PM Web as a third-party.
Furthermore, third-party en es can represent clients of the bank in Front Office – PM, which means that you can also configure and customise Front Office – PM
Web to create a web applica on accessible by clients of the bank.

For implementa ons that contain third party access, a third-party must be linked to a user to inherit all required business profiles (e.g., func on security profile,
screen profile, report profile, printer profile, and data profile). As well, you will have an addi onal data profile mechanism that allows you to define a fine-grain
security that is necessary in this type of implementa on.
Channels and Channel Profiles

Different channels (e.g., WUI, GUI, OData, Import, etc.) require different profiles (e.g., Func on Security Profile, Screen Profile, Report Profile, etc.). Previously, to be
able to run correctly or to give specific accesses, it was mandatory to create separate users for each channel, even if the final user is only one single person.
To allow one single person to use the same user to connect to different channels and to apply a specific configura on to each channel, the concept of Channel
Profiles was introduced.
This configura on is op onal and replaces, whenever it is defined for a specific channel, the configura on set at the user level. A Channel Profile can be specified on
top of other profiles of the user.
In the standard packaging, several basic channels are delivered that can be used in Channel Profiles to redefine the users' access rights. The rules are:
If no Channel Profile is defined, the original behaviour is kept and all profiles defined in the user table are applied.
If a Channel Profile is defined, for each channel exis ng in its composi on, the system will apply the Channel Profile
configura on.
If a Channel Profile is defined, access is prohibited to channels that are not defined in the Channel Profile of the user even if
allowed by the original behaviour.
The Data Profile cannot be overloaded for a specific channel.
Informa on about the different profiles used by a user for a session shows up in table appl_session and the historisa on of the
sessions is also maintained.
Example
Channel Profile PM_CHANNEL_PROF is created and contains the default channel "WUI" with the following profiles configured (among other profiles):
Func on Security Profile = PCK_DS_WUI_GUI_FSP

Report Profile = REP_DEFAULT_PROF
User A has profiles defined in the user table as follows (among other profiles):
Func on Security Profile = DEF_FUNC_SECU_PROF

Report Profile is le blank
Channel Profile = PM_CHANNEL_PROF
When connec ng to the WUI, user A will have access to all func ons and menus corresponding to Func on Security Profile PCK_DS_WUI_GUI_FSP and will see all
reports included in Report Profile REP_DEFAULT_PROF.
The user has no access to the GUI as no Channel Profile was defined for the GUI in PM_CHANNEL_PROF.
CDM GCL
The Generic Cryptographic Layer (GCL) enforces security and manages the encryp on of all CDM data.
Defining the CDM security requires reproducing the hierarchical security organisa on of the bank star ng from the uppermost level.
An unlimited number of bank authori es can each enter a secret password that is then used to create a root dataset. All
confiden al client data of the bank will depend on this.
Each bank authority can then appoint (or revoke) one or more Chief Security Officers in charge of the security at the bank.
Each chief security officer can appoint assistants who manage end-users / groups / end-user security profiles and access to client
data.
The image below illustrates the mul -dimensional security as well as the CDM security hierarchical steps to take when defining the security from the onset:

Through its GCL, not only is CDM able to secure access to data rows (quan ta ve security) but also to a ributes (qualita ve security).
For further details about CDM GCL, refer to the WealthSuite Front Office - Por olio Management Web - GCL Security Context Configura on Guide and the
WealthSuite Front Office - Por olio Management Web - GCL/CDM/TCM Interface Guide.
Subscrip on mechanism
Front Office – PM has a built-in mechanism that can trap data changes (e.g., inserts, updates, deletes) for audit or data replica on (e.g., named events) purposes. It is
called the subscrip on and it can currently be configured through the GUI.
Both event and audit subscrip ons are defined using the following informa on:
Iden fica on code.

Begin date and me.
Op onally, an end date and me.
En ty and ac on on en ty to be observed (e.g., delete on por olio).
Module through which the ac on on the en ty has to be observed (e.g., GUI only).
Op onally, the name of a WebSphere TX map for transforma on purposes.
In addi on, specifically associated to an event subscrip on, the following are available:
Opera on status range to observe if en ty is related to an opera on.

A valid Front Office – PM script used to update an opera on status a er processing the event.
The following image illustrates the subscrip on mechanism:

Upon detec on of a write opera on on a given en ty, the involved Front Office – PM module (e.g., GUI, financial server, import) first checks if an ac ve subscrip on
exists for the current context. It then opens a transac on comprising of up to three write opera ons as illustrated above and commits the transac on if and only if
no error has been reported.
Repor ng
Front Office – PM report genera on concepts are similar for the GUI and WUI. An Actuate server sits at the heart of all implementa ons and generates all reports
from data retrieved from the Front Office – PM main databases either directly or through calls to the financial server.
In the following sec ons, you will learn more about the repor ng genera on concepts in the:
GUI mode
WUI mode
GUI mode
To communicate with the Actuate report server (Actuate BIRT iServer), the GUI requires the installa on of the aaa_rs applica on and the Odyssey Founda on Class
(OFC) part of Front Office – PM Repor ng. In this mode, reports are produced in synchronous mode and presented to the requester in a configurable format (e.g.,
hard-copy, PDF, Excel, etc.).
The following image illustrates the Front Office – Por olio Management report genera on using the GUI:

Any report can be produced using the following sequence:
1. The parameters needed for the report genera on are gathered.

There are two types of parameter: the one used by actuate for the report genera on and those used to perform financial
calcula ons. Those parameters are either set by the user at run me through one of the user interfaces (i.e., GUI, WUI, RLS) or set
by the system based on default value scripts.
2. Actuate is called using Web services to start the report genera on.
3. The OFC calls the financial server to compute financial data.
4. The financial server writes the result of the financial calcula on in the reports database (aaarepdb).
5. Actuate produces the report based on the data read in the reports database.
6. The report document is retrieved from the Actuate server using Web services.
7. Once the report document is retrieved, it is either stored or displayed.
WUI mode
The repor ng architectural concept is shared between all components of Front Office – PM. The high-level overview of the report genera on that is described in
sec on GUI mode also applies to the image shown below.
However, Front Office – PM Web offers an addi onal func onality: the integra on with a content repository system. Once the report is retrieved from Actuate, the
WUI stores the resul ng report document in a content repository. The WUI accesses the content repository through an Applica on Programming Interface (API)
based on JCR (JCR is the standard Java Content Repository API). Therefore, the WUI can be integrated with a third-party content repository available in the bank.
By default, Front Office – PM Web includes an internal content repository called Jackrabbit. This internal repository has limited func onali es and is not accessible
by third-party applica ons.
The following image illustrates the Front Office – PM Web report genera on:

Integra on with external systems

The integra on layer facilitates the interac on between Front Office – PM Web and other systems (e.g., order management or back office). The technology is based
on IBM WebSphere TX toolset.
The following image illustrates the architecture of the Front Office – PM integra on layer:

The different components shown in the above image are:
Import/Export Gateway: facilitates real- me and command-driven interac on with the Front Office – PM logical schema via
standardised file-based messaging in online or batch modes.
Gateway Pack: provides business-driven XML schemas for standardised messaging to/from Front Office – PM. It also facilitates
non-func onal requirements such as error management, recycling, sta s cs, logging, and archiving.
Extract Transform: provides the mapping between the external systems data representa on and the data presenta on accepted
by the Gateway Pack or directly by the Front Office – PM import format.
Transport: provides a data transfer facility between the different systems, generally relying on adapters provided by WebSphere
TX.
This pla orm enables integra on within our client’s infrastructure for bi-direc onal data exchanges (import and export). The integra on pla orm provides:
Pre-defined development/opera ng environment for interfaces with third-party applica ons based on XML (or tradi onal
formats), configurable for file transfer and messaging (configurable for batch, event-based and on-demand modes).
A comprehensive and powerful Data mapping tool coupled to our solu on.
Development func ons, debugging, monitoring, and tuning facili es to handle simple to complex transforma on schemes, logical
rou ng.
Connec vity via +/- 60 adapters such as RDBMS (Oracle, Sybase, DB2, SQLServer, ODBC), Message Queuing and JMS, FTP/SFTP or
Mail (Lotus Notes, MS Exchange), etc.
Scheduler to trigger batch processes. An external scheduler (e.g., Tivoli, Control-M, Autosys, etc.) can be used instead.
Event and subscrip on daemon for event-based and on-demand processing.
Integra on with data transport middleware including Tuxedo, Candle Roma, Oracle AQ, IBM MQSeries and TIBCO Rendez-vous.
Due to the high level of customisa on generally applied to the integra on layer, there is a rather loose coupling with Front Office – PM. As shown in the image
above, the hook is done at the gateway level mostly toward the data layer. This coupling, illustrated in the image below, is composed of two daemons, subd and ga t,
and one executable, aaa_imp.
subd is in charge of handling all data modifica on events published in the table event. For each published event, this daemon will
launch the execu on of the associated WebSphere TX map. See sec on Subscrip on mechanism for further explana on on the
subscrip on mechanism.
aaa_imp is a command line import/export u lity. In import mode, it is given a file containing data and the meta-descrip on of the
file that will be parsed and validated against the Front Office – PM meta-dic onary.
ga t is in fact a daemon version of aaa_imp. The difference is that all ini alisa ons (e.g., loading of meta-dic onary) is done only
once at instan a on me. A library (lib_ga t) may be loaded in WebSphere TX to allow communica on with ga t.

Generic interfaces
iMDI: Temenos Intelligent Market Data Interface (iMDI) is made of pre-packaged market data vendor adapters (e.g., Reuters,
TELEKURS, Bloomberg, WM, etc.) to collect instrument informa on. Not only is it used to collect data but also to prepare it (e.g.,
cleanse, merge, aggregate) before integra on into the solu on.
Other packages: Temenos also built some specific integra on packages for various back-to-front interfaces, as well as front-to-
back ones. Other than the one for Core Banking, there is also something for Avaloq and Olympic. Packaged interfaces with other
vendors' products might be later available.
Interac on with external systems or E-banking

Front Office – PM provides several interac on methods. By interac on, we mean, for instance:
Calling online a financial func on to get and show the results in another system.
Crea ng, reading, upda ng, and dele ng Por olio Management System (PMS) data stored in Front Office – PM.
Ge ng a financial report.
By using this interac on, you can build your own front-end on top of Front Office – PM (e.g., portal, e-banking) or supply another system with Front Office – PM
financial calcula ons. This interac on can be done remotely from another server.
The following Applica on Programming Interfaces (APIs) are recommended to interact with Front Office – PM:
TASC Java API

OData API (most recommended API to use)

TASC Java API

TASC Java API was available in Front Office – PM Release 1.30.X but was no longer supported in Release 11 and Release 12. However, since Release 13, TASC Java API
was re-implemented and enhanced based on the TSL architecture.
TASC API is a Java API, which means that it can be called only from Java technology so ware. The advantage of the enhanced TASC Java API of Release 13 is the
remote capability. You can call it from an applica on installed on another server, which simplified the packaging. This API has been extended to support order session
management.
You can easily migrate from TASC Java API of Release 1.30.X to Release 13 version by using the Front Office – PM TASC Migra on Kit.
OData API
The OData (Open Data) is an open protocol to query and update data based on HTTP and it has been chosen by Temenos at the enterprise architecture level to put
into place the interac on between all Temenos products.
An OData API is RESTful and metamodel oriented. The key goals of REST include:
Scalability of component interac ons.

Generality of interfaces.
Independent deployment of components.
Intermediary components to reduce latency, enforce security, and encapsulate legacy systems.
User-defined en es can be available in the OData API and since Release 13, Front Office – PM provides an OData API for all back-to-front financial func ons for
crea ng, reading, upda ng, and dele ng PMS en es of Front Office – PM. Design Studio is used to design and customise the OData API of Front Office – PM.
Design Studio
Front Office – PM Design Studio is an integrated development environment (IDE) workbench with a number of features specifically designed to support building and
maintaining the Web front-end of Front Office – PM. Based on Eclipse, this tool follows the OMG Model-Driven Architecture (MDA) approach, and generates
technical artefacts such as XSP pages, Java code, and some XML configura on files from graphical and textual models.
Design Studio is used both by Temenos to build the standard Front Office – PM Web, as well as in implementa on projects to adapt standard models and create
addi onal customer specific ones. Customers can configure the solu on without the need for specific technical framework development skills. Maintenance is also
facilitated as the models are decoupled from the technical paradigms used in the solu on and can, for example, be migrated to new versions of technical
frameworks used.
Design Studio enables business consultants to implement all of the front-end, using the workbench and Front Office – PM scrip ng. (Certain more technical ac vi es
will be performed by Web consultants, using the same tool.)
The Design Studio includes the following graphical designers:
Business model to represent the business objects manipulated by the other designers.
Page, module, and page fragment designers to graphically configure the Web User Interface, and create reusable page building
blocks, as shown in the following image:

Pageflow designer to assemble pages in a logical and guided flow, as shown in the following image:
Workflow designer (BPMN-compliant), assembling page flows in a collabora ve business process, as shown in the following
image:

Transla on editor, to facilitate the edi on of mul -lingual transla ons for page labels or object models (including expor ng and
re-impor ng of transla ons to and from Microso Office Excel).
Front Office – PM integra on

Front Office – PM Design Studio is well integrated with Front Office – PM. In par cular, the import meta-dic onary and import formats features synchronise the data
model used by Design Studio with the user-defined fields (UDF) and formats used in Front Office – PM.
This is achieved by connec ng to the Front Office – PM database from the workbench, reading from the respec ve database views, and building a respec ve
“model” which is then usable in other models (e.g., Page Designer).
The Front Office – PM meta-dic onary and formats are s ll managed in Front Office – PM and imported read-only in Design Studio. Formats con nue to be created
and maintained in the GUI, and "synchronised" into Design Studio for the WUI design. The Design Studio data model integrates the Front Office – PM business types.
User-defined en es
User-defined en es are defined using Design Studio:

Then, you can generate a Front Office – PM import file from Design Studio to create the corresponding tables in the Front Office – PM database. Furthermore, you
can use the Pageflow Designer and Page Designer to build a web front-end on top of the user-defined en es created.
Embedded server
To simplify a business consultant’s workspace set-up, Design Studio comes with an embedded server. This is a fully-fledged Front Office – PM Web and TSL Java layer
running inside Design Studio, which connects (via shared installa on proper es) to the Front Office – PM databases and financial server back-ends installed centrally.
No external applica on server and Front Office – PM Web installa on, Java Run me (JRE) or Development Kit (JDK) or other addi onal dependency is required for
business consultants to work locally with Design Studio.
The Front Office – PM code running embedded in Design Studio is iden cal to that of a later produc on environment, thanks to the original Front Office – PM Web
binaries (JARs) shipped in a repository inside Design Studio. This run me binaries repository can be refreshed with delivered hot fixes through a built-in feature.
Packaging
Design Studio models reside simply as text files on local file system (not in a central database). Mul -user collabora on is achieved by using a version control
system’s check-in and check-out features (such as SVN). This also covers use cases such as “compare to standard”, “revert to standard”, “merge with service pack”,
etc.
Custom model configura ons can be packaged in deployable installa on units (DPI ZIP files) by Design Studio. Such packages can be built either using Design Studio's
packaging project launcher locally, to build a deployment package on a worksta on, or on a central integra on server which checks out the configura on and
customisa on project structure from, for example, an SVN repository to build a deployment packages. Such packages are then transferred to and installed on, for
example, test and produc on Front Office – PM Web applica on servers.
Published on: 22/04/2019

Architecture Overview 4

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Architecture Overview 4

Uploaded by

Copyright:

Available Formats

5/21/2019 Architecture Overview

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 1/26

WealthSuite Front Oﬃce - Por olio Management - Gateway Reference Guide

The main components of the above image are:

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 2/26

The following image illustrates the Front Oﬃce – PM ﬁnancial server:

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 3/26

Dynamic screens (GUI mode only).

Administrate these en es with the Front Oﬃce – PM

Business func ons

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 4/26

CRUD (Create Read Update Delete)

Data layer access

The databases may be divided into the following groups:

3 Front Oﬃce - PM databases

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 5/26

En ty: Regular rela onal table holding the standard a ributes

Triple’A Plus Service Layer

The main new features of TSL are:

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 6/26

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 7/26

The following image illustrates the TSL local caching feature:

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 8/26

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 9/26

DBResultSet versus InMemoryResultSet mode

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 10/26

Front Oﬃce – PM Web architecture

An overview of the WUI is provided in the following sec ons:

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389%… 11/26

Installa on and migra on framework

Deployment Package Installer (DPI)

Smart Migra on tool (SMIT)

Mul -instance installa on

Load balancing / Failover

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 12/26

The general architecture is illustrated in the image below:

The main parts are:

Split and retry

Currently, the following is implemented:

Mul ple scheduler deﬁni ons in conﬁgura on.

GUI mode only

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 14/26

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 15/26

Channels and Channel Proﬁles

Func on Security Proﬁle = PCK_DS_WUI_GUI_FSP

Func on Security Proﬁle = DEF_FUNC_SECU_PROF

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 16/26

Iden ﬁca on code.

Opera on status range to observe if en ty is related to an opera on.

The following image illustrates the subscrip on mechanism:

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 17/26

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 18/26

Any report can be produced using the following sequence:

1. The parameters needed for the report genera on are gathered.

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 19/26

Integra on with external systems

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 20/26

The diﬀerent components shown in the above image are:

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 21/26

Interac on with external systems or E-banking

TASC Java API

https://tcsp.temenos.com/TAP1811/#UserGuides/1806/Front Office - PM/Front Office/FrontOffice_ArchitecturalOverview.htm#_Toc528682389… 22/26

TASC Java API