TAFJ R18 Release Notes
TAFJ R18 Release Notes
TAFJ R18 Release Notes
Page 1
Table of Contents
Page 2
IMPORTANT RELEASE INFORMATION
This section outlines new features in TAFJ R18 and contains important
information for upgrading clients. If you are upgrading from an earlier
release of TAFJ, please read and understand all the release information
details for each release before starting the installation.
Release Highlights
This section provides an overview of any new TAFJ components or features and advice
regarding any components which have been replaced, deprecated or modified.
Configuration Enhancement
Properties, usually stored in the TAFJ properties file, can now be stored at database level in
a technical table named “TAFJ_CONFIGURATION”. This table is automatically created on
first use if it doesn’t already exist.
The configuration service is making use of the same datasource than the one use for T24.
No additional setup is required from end user perspective. This mode is not available for
standalone application.
To switch from a configuration stored on disk in the properties file, to a database
configuration, the system property ‘tafj.configuration’ has to be set at application start up.
‘tafj.configuration’ value represents the configuration name (or configuration ID).
e.g.
-Dtafj.configuration=production
Database Enhancements
Multi-column support
For tables needing super-fast indexing, a table can be turned into a pseudo-relational table
where multi-values are stored in NVARCHAR columns. While this approach provides worse
performance in terms of reads due to the fact a dynamic array needs to be constructed out of
all of the columns, it will provide better indexing speed for single-value columns.
Locking
Now there is a hybrid locking mechanism implemented such that some locks can be taken at
the database by row locking. Non-existant locks (locks on records that do not exist yet) are
still locked by a secondary lock manager. For example, to set up database row level locking
with ORCL locking handling the non-existant records, the following properties would be set.
Page 3
temn.tafj.locking.mode= DATABASE
temn.tafj.jdbc.db.locking.secondary.lockmanager = ORCL
DBTools
DBTools is now secured, you need to define user and password to be able to login into
DBTools. Refer to DBTools documentation for more details.
All DBTools actions are also being logged to keep trace of command used and user.
Dictionary Cache
Dictionary entries can now be cached by setting the key
temn.tafj.runtime.use.cache.dict.item=true
Note that this should be used in single server mode only. Cluster configurations and multi-
node server configurations coming next year.
Documentation
A run book is now available covering T24 java configuration for all supported stack.
TAFJEE
TAFJConfigurationWeb
TAFJRestServices
Page 4
Sanity check
A sanity check is available through TAFJEE servlet, this tool runs a validation of the
application server configuration by comparing what is expected at application level (TAFJEE)
and what is effectively configured at application server level in terms of resources and
parameters. Refer to TAFJ AS documentation for more details.
Execute servlet
Messages / actions posted to the EXEC queue for processing are being logged and reported
to the Execute servlet page. A notification is also reported on action completion.
It allows following tSA / command history and status.
T24 Features
LOGOFF has been fixed to time out tSA exceeding T24 time out value.
Breaking change
201072
A new property is available at MDB level to configure the time to live for the responses sent.
Default behaviour is unchanged, time to live is unlimited, and doesn’t require any change.
To have a response expiration the following property has to be added at ejb-jar.xml level for
the related MDB.
<env-entry>
<description>the response time to live in milliseconds from its dispatch timdefault is zero is
unlimited</description>
<env-entry-name>com.temenos.tafj.mdb.TransactedMDB/responseTimeToLive</env-entry-name>
<env-entry-type>java.lang.Long</env-entry-type>
<env-entry-value>10000</env-entry-value>
</env-entry>
201612
Webservices components:
TAFJServices.war, axis2 based webservices component is deprecated.
TAFJRestServices.war, JAX-RS based webservices component is replacing it.
For back compatibility reason, both archives are packaged in TAFJJEE_EAR until R17-AMR
and TAFJServices.war removal.
Refer to TAFJ-AS documentation for more details.
TAFJEE client:
TAFJJEE client classes, e.g. TAFJJEEClientFactory, part of TAFJClient.jar have been re-
factored to match the new JEE services available, JAX-RS webservices, Websocket
endpoint etc…
Client applications should migrate to make only use of classes which are part of
Page 5
package com.temenos.tafj.jee.client;
instead of formerly
package com.temenos.tafj.j2ee.client.impl;
package com.temenos.tafj.j2ee.client.impl;
201606
TAFJ is using SLF4J as logging API and is shipped with a default logger configuration for
log4j (TAFJTrace.properties).
This won’t make any difference from end user perspective since SLF4J-API and SLF4J-
LOG4J12 are part of the application classpath.
These libraries are part of standard TAFJ_HOME/lib distribution.
For application server setup, please refer to the related TAFJ documentation.
201607
Following above mentioned 201606 migration to SLF4J logging API, the class loading setup
required in weblogic stack might be a concern for some.
Hence 201607 gives the ability to use either SLF4J or log4j2 as the main logging API.
The default API being used is now log4j2 with a provided default logger configuration,
TAFJTrace.properties. Log4j 2 properties format is not compatible with former log4j 1.2
configuration.
When upgrading to 201607, existing TAFJTrace.properties will be overridden to match log4j2
requirement.
Log4j2 libraries are part of standard TAFJ_HOME/lib distribution, SLF4J libraries introduced
in 201606 have been removed of the default lib directory.
For application server setup, please refer to the related TAFJ documentation.
To preserve backward compatibility please note this is still well possible to keep using former
log4j 1.2 setup but this is not recommended as further logging enhancements are not going
to be supported when using log4j 1.2.
It could be either behind SLF4J as in 201606 or natively with little configuration change.
See TAFJ standalone documentation for more details.
201708
The functions should be properly reloaded for the changes to get reflected.
Refer to the documents TAFJ-H2Install.pdf, TAFJ-MSSQLInstall.pdf, TAFJ-Oracle Install
12c.pdf, TAFJ-DB2 Install.pdf to reload the functions in the respective database.
Page 6
201710
201712
Adding Stored Functions tafjsplice, tafjupcase and tafjlowcase. These functions are now
supported
201801
Database stored configuration. Properties file is still available but properties can be stored in
database (does not apply to standalone mode).
Page 7
System Component Requirements
The following table shows the minimum recommended Temenos components and release
numbers which are designed to run with TAFJ.
WebSphere 9.x.x
WebLogic 12c (12.2.x)
jBoss 7.x EAP
WebSphere MQ 8.x
Page 8
INSTALLATION OF THE SOFTWARE
Transfer the archive to the target machine and unzip the archive to a
suitable directory.
Execute the scripts Setup_TAFJ.Rxx_Y.
Upgrading TAFJ
If you have an earlier version of TAFJ installed you should stop all TAFJ processes, services,
and save any system configuration files before proceeding with the installation of TAFJ.
Upgrade Summary
Transfer the archive to the target machine and unzip the archive to a
suitable directory.
Setup environment variable JAVA_HOME to path where java is installed.
Setup environment variable TAFJ_HOME to path where TAFJ is already installed.
Setup environment variable ECLIPSE_HOME to the folder %TAFJ_HOME
%\eclipse
Execute Patch_TAFJ.Rxx_Y.
You are now ready to follow any pre-release procedures described below:
Respond to the Model Bank question appropriately.
Provide a USER id as requested.
Once this is complete you are ready to sign on to T24 to initiate the upgrade service.
Start the TSA.SERVICE record BNK/T24.UPGRADE.
Authorise any CONVERSION.PGMS records.
Initiate the service RUN.CONVERSION (TSM must also be run)
Recompile any local code (New inserts provided by the release and
or TAFJ upgrades require this)
Page 9
Once this is finished the record review and authorisation process can
start.
Page 10