TAFJ-Mi c r o E E

R20
 TAFJ-Mi c r o E E

Amendment History:

Revisio
Date Amended Name Description
n

9th September
1 JN. Charpin Initial version
2019

18th September
2 JN. Charpin Websphere MQ support
2019

3 24th March 2020 JN. Charpin R20 AMR Review

Page 2
TAFJ-Mi c r o E E

Copyri g h t
Copyright © Temenos Headquarters SA 2009-2020. All rights reserved.
This document contains proprietary information that is protected by copyright. No part of this document may
be reproduced, transmitted, or made available directly or indirectly to a third party without the express
written agreement of TEMENOS UK Limited. Receipt of this material directly TEMENOS UK Limited
constitutes its express permission to copy. Permission to use or copy this document expressly excludes
modifying it for any purpose, or using it to create a derivative therefrom.

Errat a and Com m e n t s

If you have any comments regarding this manual or wish to report any errors in the
documentation, please document them and send them to the address below:
Technology Department

Temenos Headquarters SA
2 Rue de l’Ecole-de-Chimie,
CH - 1205 Geneva,
Switzerland

Tel SB: +41 (0) 22 708 1150

Fax: +41 (0) 22 708 1160

Please include your name, company, address, and telephone and fax numbers, and email
address if applicable. TAFJdev@temenos.com

Page 3
TAFJ-Mi c r o E E

Table of Contents
Copyright................................................................................................................................................ 3
Errata and Comments............................................................................................................................ 3
1 Purpose.......................................................................................................................................... 5
2 Presentation................................................................................................................................... 5
2.1 TAFJEE_EAR architecture....................................................................................... 5
2.2 Micro EE architecture............................................................................................... 6
2.2.1 Single responsibility principle................................................................................ 6
2.2.2 Better scalability.................................................................................................... 7
2.2.3 Fastest deployment and startup............................................................................ 8
2.2.4 Lower resource consumption................................................................................ 9
2.2.5 Simplified and open configuration......................................................................... 9
3 User guide.................................................................................................................................... 10
3.1 Targeted architecture............................................................................................. 10
3.2 Differences with TAFJJEE_EAR deployment......................................................... 11
3.2.1 Separated artifacts.............................................................................................. 11
3.2.2 No deployment descriptors................................................................................. 11
3.2.3 JMS resources.................................................................................................... 12
3.2.4 Shared phantom queue...................................................................................... 12
3.2.5 Additional module................................................................................................ 13
3.3 Deployment............................................................................................................ 13
3.4 Configuration.......................................................................................................... 14
3.4.1 Deployment configuration................................................................................... 14
3.4.2 Application configuration..................................................................................... 19

Page 4
TAFJ-Mi c r o E E

1 Purp o s e
The purpose of this document is to describe the concept behind TAFJJEE Micro and the
step-by-step process to deploy it. Detailed information about TAFJEE services, which remain
unchanged, can be found within TAFJ-AS documentation.

2 Pre s e n t a t i o n
TAFJJEE_Micro is an alternative to the original TAFJ EE solution which is based on the
deployment of an EAR file regrouping multiple artifacts covering different needs: business
processing, management operations, technical and functional monitoring, configuration,
diagnostic, utilities etc…

2. 1 TAFJEE_EAR arc h i t e c t u r e
For some a drawback of this approach could be that all services are deployed and started at
application server startup, even if they are not necessarily needed.

For example, all online channels are present by default in the deployment, 18 OFS sources
are defined and must be bound to 18 pairs of JMS queues and a significant amount of
listeners are started and consuming resources.

The configuration can also be tedious since it is managed through deployment descriptors
within the ear file. In containerized environment, it means that the application image has to
be amended depending on the expected configuration.

Original architecture with TAFJJEE_EAR

Page 5
TAFJ-Mi c r o E E

2. 2 Micr o EE arc hi t e c t u r e
The goal with Micro EE is to offer same functionalities than TAFJ EE but with a new
deployment capability, simpler, scaling better, with a lower footprint and a faster startup.
It covers the micro-services architecture model, with single responsibility principle, and latest
deployment requirements in the cloud regarding dynamic provisioning and elastic scaling.

The base architecture is depicted below.

New Micro EE architecture

Page 6
TAFJ-Mi c r o E E

2. 2. 1 Sin g l e res p o n s i b i l i t y prin c i p l e

The Micro EE artifact, TAFJJEE_Micro.jar, supports the following features usually supported
with TAFJJEE_EJB.jar, TAFJJEE_MDB.jar and TAFJJEE.war.

The main change, simply considering the business services offered by TAFJ EE, is that the
Micro EE architecture is defining one and only one online channel per deployment.

Services parameters and enabled features are defined at runtime through

configuration.

The available features are:

- Online processing (OFS or CALLAT)

- Background processing (Phantom)
- tRun processing
- Management activities (Sessions management, EJB warmup / tSA on startup,
management topic)

Page 7
TAFJ-Mi c r o E E

There is a minimal deployment descriptor (jboss-ejb3.xml) simply defining proprietary

Wildfly / Jboss configurations parameters to enable / disable and size services which doesn’t
need to be edited, unless a specific JMS broker is used, and can be ignored from end user
perspective.

2. 2. 2 Bet t e r sc al a b i l i ty
Each service is available as a separate artifact in the release package and could be
deployed and scaled independently.

Since Micro EE allows defining services parameters at runtime it is possible to scale

independently the online channels, per OFS source, based on the platform usage
(CPU / Memory etc..).

In addition, there is no need to deploy on each instance the COB monitor or the TAFJ
configuration web application.

The available artifacts are:

- TAFJJEE_Micro.jar
- TAFJCobMonitor.war
- TAFJConfiguration.war
- TAFJEE.war
- TAFJRestServices.war
- TAFJTECMonitor.war

Component Dependencies Services provided

Page 8
TAFJ-Mi c r o E E

TAFJJEE_Micro.jar None Channel processing

tRun processing

Management
processing

TAFJEE.war primefaces.war for JSF support COMO

TAFJJEE_Micro.jar DBTools

TAFJRestServices.war for webservices Execute phantom

support
Logging

Management

tDIAG

tSHOW

tRUN

Webservices

TAFJRestServices.war TAFJJEE_Micro.jar Channel entry point

Management entrypoint

tRun entrypoint

TAFJConfiguration.war primefaces.war for JSF support Configuration service

Configuration servlet

Configuration entry
point

TAFJTECMonitor.war primefaces.war for JSF support Monitoring service and

servlet
TAFJJEE_Micro.jar

TAFJCobMonitor.war primefaces.war for JSF support Monitoring service and

servlet
TAFJJEE_Micro.jar

Page 9
TAFJ-Mi c r o E E

2. 2. 3 Fas t e s t dep l o y m e n t and star t u p

By deploying services independently, we ensure that the platform services getting started are
the minimal ones. Micro EE is starting about two times faster than ear file deployment.

2. 2. 4 Low er res o u r c e con s u m p t i o n

Simply considering the business services, in TAFJ EE architecture the number of threads
running is proportional to the number of channels deployed. With the Micro EE architecture,
we run at max one online channel per deployment. We could also disable / size online and
phantom processing based on environment variables defined at runtime. The result is a
number of threads divided by 2.5 and a heap usage divided by 4 at startup.

2. 2. 5 Si m p l i fi e d and op e n co n fi g u r a t i o n
Micro EE is configurable through the platform itself with environment variables, system
properties, database configuration etc…

There is no need to amend the archive (deployment descriptors) at deployment time or

following an update

It allows controlling what are the running services, their dimensioning (pool size) and also the
business parameters.

The JMS resources to be defined at deployment level are also greatly simplified:

- 1 pair of OFS queue (request / reply) for online processing

- The phantom queue for background processing which can be common to all
deployments
- The management topic for management activities

For Phantom processing, in distributed environment, there is no need to define a local

“Exec queue” per environment. Dynamic message filtering allows using a common shared
queue for all deployments.
The detailed architecture and parameters are described in the user guide section.

Page 10
TAFJ-Mi c r o E E

3 Us er gui d e
This section describes the targeted platform requirements, and how to deploy and configure
the solution.

3. 1 Targ e t e d arc h i t e c t u r e
At first place, the targeted architecture for the application layer is a cloud / containerized
Wildfly / JBoss EAP deployment but it could also be deployed on a standard Wildfly / JBoss
EAP installation on premises.

It is important to note that Wildfly / JBoss EAP is required for the dynamic configuration
capabilities it offers at runtime by injecting environment variables and system properties
within application server and application configuration.

The main configuration is automated with scripts (JBoss - CLI) and at runtime environment
variables set at orchestrator level are resolved and injected to run the expected setup.

There are different categories of parameters which are used at different level to wire the
components altogether and to configure the application.

The default JMS broker is ActiveMQ deployed on a separate tier but it could be any other
JMS broker. Wildfly AMQ internal broker is not used since there is no need for a local Exec
queue.

To connect to a different broker the appropriate “activation config” parameters have to be

defined at jboss-ejb3.xml level.

A sample configuration file, jboss-ejb3-wmq.xm, is provided within the archive under META-
INF.

It can be used as a replacement for the default jboss-ejb3.xml when connecting to

Websphere MQ.

Page 11
TAFJ-Mi c r o E E

3. 2 Diff e r e n c e s with TAFJJEE_EAR dep l o y m e n t

Micro EE is similar to TAFJ EE except the following differences.

3. 2. 1 Se p ar a t e d artifa c t s
The deployable artifacts are available within the release under the $TAFJ_HOME/appserver
path within the “micro” subfolder.

The minimal artifact to deploy in replacement of TAFJJEE_EAR.ear is TAFJJEE_Micro.jar

(less than 100kb jar file).

3. 2. 2 No depl o y m e n t de s c r i p t o r s
The application configuration is achieved through environment variables. There is no
deployment descriptor anymore to edit in order to setup the appropriate OFS source and
other parameters.

The minimal jboss-ejb3.xml is simply used to define specific “activation config” parameters to
connect to a different broker than ActiveMQ.

As described in the configuration section, all MDBs / EJBs parameters available in

TAFJJEE_EAR and documented in TAFJ-AS documentation are available either through:

Page 12
TAFJ-Mi c r o E E

- Environment variables
- System properties
- TAFJ configuration (database)

3. 2. 3 JMS res o u r c e s
In comparison with TAFJJEE_EAR there is little JMS configuration to do to have the Micro
EE application deployed.

Each deployment defines the following generic JMS resources, which are bound at runtime
to common / specific ActiveMQ resources.

- java:/queue/t24OnlineQueue -> is bound to specific Queue

- java:/queue/t24OnlineReplyQueue -> is bound to specific Queue
- java:/queue/t24EXECQueue -> is bound to common Queue
- java:/topic/t24ManagementTopic -> is bound to common Topic
In case of additional resources needed (CALLJEE etc…) resources can be added to the CLI
script.

3. 2. 4 Sh ar e d ph a n t o m qu e u e
A local “Exec queue” per deployment for Phantom processing is no longer required. The
phantom queue could be shared across all instances by defining a message selector.

A unique ID per server can be assigned to the environment variable phantom_selector.

This variable will be used at server startup to define a unique message selector for the
PhantomListener (MDB).

When sending a message to the shared ExecQueue containing a JMS property

PhantomSelector, the listener with the corresponding phantom_selector message filter
will treat the message.

In case of message with no PhantomSelector, any of the registered PhantomListener will

consume the message.

When the environment defines a phantom_selector environment variable, any services

targeting the Exec queue will set it as a JMS message property to ensure processing on
same server instance.

Page 13
TAFJ-Mi c r o E E

3. 2. 5 Additi o n a l mo d u l e
Besides the usual global modules for T24 and TAFJ libraries an additional module
“org.primefaces” needs to be defined in case of JSF support is required when deploying the
following artifacts:

- TAFJEE.war
- TAFJConfiguration.war
- TAFJTECMonitor.war
- TAFJCobMonitor.war
This module definition is part of the CLI scripts and the primefaces library is sahred with the
TAFJ_HOME/appserver/micro folder.

3. 3 De pl o y m e n t
Same deployment process than the one used for T24 / TAFJ EE deployment can be used,
be it on premises or in a containerized environment.

This process is described within usual Temenos – Runbooks and TAFJ documentation.

Differences are :

- The artifact to be deployed as described in the “Differences with TAFJJEE_EAR”

section.
- The CLI script content which is greatly simplified.

Page 14
TAFJ-Mi c r o E E

CLI scripts and a docker build example to get started can be found in the release package
under $TAFJ_HOME/appserver/micro/deployment.

This docker build example is making use of Temenos internal maven repository to install T24
and TAFJ aplications, and should be used as a model when an access to this repository is
not possible (by replacing curl commands with copy commands).

3. 4 Confi g u r a t i o n
There is two different property types to configure the deployment and the application.

Properties used to configure the application server / deployment must be provided as

environment variables.

The one used to configure the application can be part of TAFJ configuration. It means they
can be provided as environment variables, system properties and be part of the TAFJ
configuration.

To distinguish between these two types a different formalism is used.

A configuration sample can be found in the release under:

$TAFJ_HOME/appserver/micro/deployment/docker/env-file

3. 4. 1 Dep l oy m e n t co n fi g u r a t i o n
Deployment configuration properties respect the following formalism:
DEPLOYMENT_CONFIG / deployment_config.

They are used to configure links between application tiers (server / DB / broker) and also to
enable and configure the application services.

3.4.1.1 Database wiring

The connection with the database is fully configurable through environment variables.

Property Description Default value

DB_URL DB connection URL None

DB_USERNAME DB user None

Page 15
TAFJ-Mi c r o E E

DB_PASSWORD DB password None

DB_DRIVER DB provider – needs to match the jboss None

jdbc-driver name defined in CLI script.
Possible values by
default:

h2 / sqljdbc / ora12c

DB_POOL_SIZE Datasource maximum concurrent None

connection number

H2 example

DB_URL=jdbc:h2:tcp://host.docker.internal:2234/TESTDB;DB_CLOSE_ON_EXIT=FALSE;M
ODE=Oracle;TRACE_LEVEL_FILE=0;TRACE_LEVEL_SYSTEM_OUT=0;FILE_LOCK=NO;I
FEXISTS=TRUE;CACHE_SIZE=8192;MVCC=TRUE;LOCK_TIMEOUT=60000

DB_USERNAME=tafj

DB_PASSWORD=tafj

DB_DRIVER=h2

MSSQL example

DB_URL=jdbc:sqlserver://host.docker.internal:1433;databaseName=TESTDB

DB_USERNAME=tafjuser

DB_PASSWORD=tafjuser1

DB_DRIVER=sqljdbc

ORACLE example

DB_URL=jdbc:oracle:thin:@host.docker.internal:1521/TESTDB

DB_USERNAME=tafj

DB_PASSWORD=secret

DB_DRIVER=ora12c

Page 16
TAFJ-Mi c r o E E

3.4.1.2 JMS broker wiring

The connection with the external ActiveMQ broker is fully configurable through environment
variables.

Property Description Default value

AMQ_URL Broker connection URL None

AMQ_USERNAME Broker user None

AMQ_PASSWORD Broker password None

Example:

AMQ_URL=failover:(tcp://host.docker.internal:61616?soLinger=0)

AMQ_USERNAME=admin

AMQ_PASSWORD=admin

It is also possible to connect to Websphere MQ with following environment variables.

Property Description Default value

MQ_HOSTNAME Broker connection URL None

MQ_PORT Broker user None

MQ_QUEUE_MANAGER Broker password None

MQ_CHANNEL None

Example:

MQ_HOSTNAME= host.docker.internal

MQ_PORT=1414

MQ_QUEUE_MANAGER=MQ_T24

MQ_CHANNEL=T24_CHANNEL

3.4.1.3 JMS queue wiring

The following environment variables are used to define the physical queue mapping at broker
level with the fixed JNDI names defined at MicroEE level.

Page 17
TAFJ-Mi c r o E E

To define the queues for online processing:

ONLINE_QUEUE=t24OFSQueue

ONLINE_REPLY_QUEUE=t24OFSReplyQueue

This mapping should be different per environment / channel definition.

The Phantom queue and management topic are shared and should be the same on each
environment.

EXEC_QUEUE=t24EXECQueue

MANAGEMENT_TOPIC=t24ManagementTopic

Property Description Default value

ONLINE_QUEUE Online channel request queue None

physical name

ONLINE_REPLY_QUEUE Online channel reply queue None

physical name

EXEC_QUEUE Phantom channel queue None

physical name

MANAGEMENT_TOPIC Management topic physical None

name

3.4.1.4 Application wiring

These properties define what are the services available and how they are configured.

Property Description Default value

channel_type For online processing defines ofs

whether it is OFS processing or
CALLAT processing. (Link between Possible values: ofs /
TransactedMDB and callat
OFSProcessingBean or
CallAtProcessingBean).

online_active Defines whether the online MDB None

(TransactedMDB) is enabled and
listening to AMQ_ONLINE_QUEUE Possible values: true /

Page 18
TAFJ-Mi c r o E E

false

max_online_session Defines the online MDB thread pool None

(maximum concurrent messages)
Integer value.

phantom_active Defines whether the phantom MDB None

(PhantomListener) is enabled and
listening to AMQ_EXEC_QUEUE Possible values: true /
fals

max_phantom_session Defines the phantom MDB thread None

pool (maximum concurrent
messages) Integer value.

phantom_selector Defines the message selector None

which applies to the Phantom
MDB. If a JMS message contains a String value.
JMS property “PhantomSelector” it
will be treated in case of
phantom_selector=PhantomSelect
or.

This value is also set as

‘PhantomSelector” when posting
message to AMQ_EXEC_QUEUE.

Should be unique per environment.

Example for OFS processing:

channel_type=ofs

online_active=true

max_online_session=10

channel_type is optional since the default value is ‘ofs’

Example for CALLAT processing:

channel_type=callat

online_active=true

max_online_session=5

Page 19
TAFJ-Mi c r o E E

channel_type is mandatory to infer CALLAT processing instead of OFS.

Example for phantom processing:

phantom_active=true

max_phantom_session=20

phantom_selector=server1

3. 4. 2 Appli c a t i o n con f i g u r a t i o n
Application configuration properties follows the formalism: application.config /
applicationConfig.

‘application.config’ is the property format used in TAFJ configuration.

‘applicationConfig’ is the property format formerly used in deployment descriptors to

configure MDBs / EJBs.

They are used to configure the application itself, services behaviour and processing
parameters.

A TAFJ property defined as an environment variable will take precedence on property

defined in TAFJ configuration (database).

MDBs / EJBs properties can also be added to the TAFJ configuration to avoid duplicating
them in all environment.

A sample configuration file can be found in the release pack under

$TAFJ_HOME/appserver/micro/deployment/example/channel-configuration, replicating
the configuration present in TAFJJEE_EAR deployment descriptors.

3.4.2.1 Service name

To distinguish in the configuration which property applies to which service, a “service name”
is defined per service type and applied as a property prefix.

Service type EJB Default service name

Online processing OFSProcessingBean None – could be left empty or set

/ through property ‘channel_name’
CallAtProcessingBe
an e.g.

channel_name=tws

Page 20
TAFJ-Mi c r o E E

Phantom processing PhantomListener phantom

tRun processing TRunProcessingBea trun

n

Management activities TAFJManagementB management

ean

Example to configure a channel for CALLAT (CALLAT processing) – no service name

channel_type=callat

ofsSource=JAVA.FRAMEWORK

ofsTimeout=30

Example to configure a channel for BrowserWeb (OFSProcessing) with service name

channel_name=browserweb

browserweb.ofsSource=BROWSERTC

browserweb.ofsTimeout=300

browserweb.maxJmsRedeliveryAttempt=0

Example to configure phantom channel

phantom.isJTA=true

phantom.jtaTimeout=600

Example to configure tRun channel

trun.trunTimeout=60

trun.allowedCommand=\bA.JBC.ROUTINE\b|\bANOTHER.JBC.ROUTINE\b

Example to configure the Management EJB

Page 21
TAFJ-Mi c r o E E

management.ejbWarmup=OFSProcessingBean=2

management.tsaStart=3

management.logoffBatchSessionOnDestroy=true

management.logoffOnLineSessionOnDestroy=false

3.4.2.2 Differences
The MDB / EJB configuration is the same than the one described in TAFJ-AS-TAFJ
documentation and usually done through deployment descriptors.

However there are some differences.

EJB warmup:

Since there is only one channel per deployment the EJB warmup pattern is simplified and
applies for a single EJB type.

When running an OFS channel, the pattern is ‘ejbWarmup=OFSProcessingBean=5’.

When running a CALLAT channel, the pattern is ‘ejbWarmup=CallAtProcessingBean=5’.

3.4.2.3 Online MDB properties (TransactedMDB)

Parameter Description Default value

defaultFormatter Message formatting parameter. None
String parameter.
Formatter to be applied on the
message to transform it.
To apply a specific formatter,
simply add in the value field the
fully qualified class name of the
formatter and make it available in
the application server classpath.

defaultPrincipal Message processing parameter. None

String parameter.
You can define a default principal
for the associated message
channel.
responseDeliveryMode Response processing parameter. 1

Page 22
TAFJ-Mi c r o E E

Integer parameter.
Defines whether response
message is delivered as a
PERSISTENT or NON-
PERSISTENT message.

Closed set of values :

1- Means NON-
PERSISTENT
2- Means PERSISTENT
sendToJmsReplyTo Response processing parameter. false
Boolean parameter.
Defines whether response
message is sent to the destination
defined through message property
getJMSReplyTo

Closed set of values :

true : use the message property
false : use the jmsReplyQueue
defined at MDB level
messageIdAsCorrelati Response processing parameter. false
onID Boolean parameter.

Defines whether response

message correlation ID is set with
the original message ID.
Closed set of values :
true : use the message ID
false: use the message correlation
ID
responseTimeToLive Response processing parameter. 0 means unlimited time to
Integer parameter. live.

The response time to live in

milliseconds from its dispatch time
before being removed from the
destination queue if not
consumed.

useRequestPriority Response processing parameter. false

Boolean parameter.

Page 23
TAFJ-Mi c r o E E

Make use of same JMS message

priority than the one set for the
request when set to true.

responsePriority Response processing parameter. None means default

Integer parameter. priority (4) – Valid priority
is between 0 and 9. 9
Defines the JMS message being the highest priority.
response priority.
Not considered when
useRequestPriority
is true.
skipResponse Response processing parameter. false
Boolean parameter.

Do not send the EJB response to

reply queue when set to true. To
be used when there is no
consumer registered to reply
queue and avoid response
message piling up on reply queue.
ignoreRedeliveredMes Error handling parameter. true
sage Boolean parameter.
In case of message redelivery this
flag could be enabled to avoid
message re-processing in T24.
MDB will receive the message but
not pass it to EJB.

Closed set of values :

false: redelivered message are
sent to EJB/T24
true: message are ignored and a
response is sent to the client that
this is a redelivered message.
maxJmsRedeliveryAtte Error handling parameter. -1 means disabled
mpt Integer parameter.
To define no re-delivery
In case of message redelivery, if set this value to 0.
this value is greater or equal than
0, the message property To define 1 re-delivery
JMSXDeliveryCount is checked only set this value to 1.

Page 24
TAFJ-Mi c r o E E

against this value to protect

against poison message.
This feature is disabled by default
as it must be already covered by
the JMS provider.
When using this feature, message
is simply ignored and information
is logged but there is no dead
letter queue associated.
recoverFromJmsFailur Error handling parameter. true
e Boolean parameter.

In case of JMS exception at MDB

level this flag when set to true will
call setRollbackOnly or throw an
EJB exception to discard the MDB
when set to false.
sendRedeliveredMessa Error handling parameter. true
geResponse Boolean parameter.

In case of incoming JMS

redelivered message, ignored and
not processed, a response is sent
to the reply queue “JMS Message
redelivered:”
Setting this property to false will
not send any response to the reply
queue.
overrideThreadName Override the default thread name false
which appears in application
server in specific format to identify
TAFJ online threads.
TAFJ-%hostname%-
%channelName%-thread-%thread
number%

3.4.2.4 Online EJB properties (OFSProcessingBean / CallAtProcessingBean)

Parameter Description Default value

ofsSource Request processing parameter. None – needs to be setup

Page 25
TAFJ-Mi c r o E E
String parameter.
Has to match an existing T24 OFS
source.
ofsTimeout Request processing parameter.
Integer parameter.
Time in seconds before request
expiration at T24 level.
resetThreshold Request processing parameter.
Integer parameter.
Define after how many request the
session can be reset. Disabled if
<= 0
Impact the performance, needs to
be used for TWS channel.
idleDetection Session management parameter.
Disable idle session detection
when set to false. In that case the
management bean periodic
cleaner will ignore sessions
associated to this channel.
ofsTimeoutMessage Error handling parameter.
String parameter.
The value associated to this
parameter will be used as a
response in case of ofs timeout.
e.g. OFSERROR_TIMEOUT
ofsErrorMessage Error handling parameter.
String parameter.
The value associated to this
parameter will be used as a
response in case of ofs error.
e.g. OFSERROR
overrideErrorMessage Error handling parameter.
Boolean parameter.
When set to true, in case of
exception during the request
processing, the response sent to
client will be suffixed with “-1/NO”.
0 – means no timeout
0 - default, means no
reset
Possible values e.g.
1 - means resetting the
session after each request
TWS setup
100 – means resetting the
session every 100 request
True – means idle
detection is enabled.
Sessions are being shut
down when detected as
idle by the management
bean periodic cleaner.
Null - means the TAFJ
runtime message related
to the ofs timeout
exception is sent.
Null - means the TAFJ
runtime message related
to generic ofs exception is
sent.
false - means the
response is sent as is.
Page 26
TAFJ-Mi c r o E E

This is also the case for the

“SEAT” OFS source.
retryOnStop Error handling parameter. 3 means 3 retry in case of
Integer parameter. STOP.
Numbers of retry in case of STOP.
When higher than 0, n retry are
going to be made, which could let
time to the system to recover from
an error (lock, connection lost…).
The time between each retry is
nRetryCount * nRetryCount
second, where nRetryCount is
the current retry number.
rollbackContainerOnI Error handling parameter for CMT true
nitError EJBs.
Boolean parameter.
When set to true the container
transaction is marked for rollback
in case of
JF.INITIALISE.CONNECTION
error. When set to false the EJB
sends a response reporting
initialization error to client.
jTA Boolean processing parameter. false – means a local
transaction is managed by
EB.TRANS local transaction EB.TRANS.
management is disabled when set
to true. Should be used to make
DB and CALLJEE part of
Enables a global transaction same unit of work in case
support at EJB level when there is of CALLJEE usage in
a need for 2PC. online processing.
The OFS.BULK.MANAGER flag
requestCommitted is
considered to commit or rollback
the transaction for OFS
processing.
A commit is issued for CallAT
processing.
jtaEBManaged Boolean processing parameter. To false – means the JTA
be used in conjunction with JTA transaction is managed at
mode enabled to manage the EJB level.

Page 27
TAFJ-Mi c r o E E

2PC.

Enables global transaction

management from EB.TRANS
when set to true.

The transaction boundary is

delegated to EB.TRANS rather
than default
OFS.BULK.MANAGER flag
requestCommitted for OFS
processing or default commit for
CallAT processing.
rollbackRequestOnSto Error handling parameter. false
p Boolean parameter.

When set to true a STOP will mark

the request to be rollback at MDB
level for re-delivery.

The corresponding MDB has to be

configured to accept re-delivered
messages to allow a re-
processing. See MDB
configuration section
ignoreRedeliveredMessage=
false.
A duplicate check is advised for
safe re-processing.

If the error causing the STOP is

not solved by the time the request
is re-processed, the maximum
delivery attempts could be
reached at JMS broker level and
the message will have to be
directed to a dead letter queue
(poison message).
rollbackRequestOnCom Error handling parameter. false
mitError Boolean parameter.

When set to true a commit error

Page 28
TAFJ-Mi c r o E E

(OFS.BULK.MANAGER
requestCommitted attribute not
equal to 1) will mark the request to
be rollback at MDB level for re-
delivery. In JTA mode OBM
requestCommitted flag could be
valid but the JTA commit can fail
and trigger the rollback.

The corresponding MDB has to be

configured to accept re-delivered
messages to allow a re-
processing. See MDB
configuration section
ignoreRedeliveredMessage=
false.
A duplicate check is advised for
safe re-processing.

If the error causing the commit

error is not solved by the time the
request is re-processed, the
maximum delivery attempts could
be reached at JMS broker level
and the message will have to be
directed to a dead letter queue
(poison message).

3.4.2.5 Phantom MDB (PhantomListener)

Parameter Description Default value
jTA Processing parameter. Flag true means EB.TRANS is
whether EB.TRANS is part of a managing a JTA global
JTA transaction or not. transaction through
TRANSTART /
TRANSEND /
TRANSABORT.
Should be used to make
DB and CALLJEE part of
same unit of work.

When set to false, a local

Page 29
TAFJ-Mi c r o E E

JDBC transaction is used.

jTATimeout Processing parameter. EB.TRANS Default value is 3600 to do
transaction timeout in seconds. not timeout agents waiting
for the main select to
complete.

0 means use the default

application server JTA
timeout.
maxJmsRedeliveryAtte Error handling parameter. -1 means disabled
mpt Integer parameter.
To define no re-delivery
In case of message redelivery, if set this value to 0.
this value is greater or equal than
0, the message property To define 1 re-delivery
JMSXDeliveryCount is checked only set this value to 1.
against this value to protect
against poison message.
This feature is disabled by default
as it must be already covered by
the JMS provider.
By default re-delivered messages
are ignored

3.4.2.6 tRun EJB properties (TRunProcessingBean)

Parameter Description Default value

allowedCommand Request processing parameter None
defining what are the authorized
programs that can be executed To allow executing
through tRun EJB invocation. 'A.JBC.ROUTINE’ or
‘OTHER.JBC.ROUTINE’
Regular expression, takes only:
precedence on tafj property
temn.tafj.appserver.trun.allowed.c
ommands. \bA.JBC.ROUTINE
\b|\bOTHER.JBC.ROUTIN
E\b

To allow everything but

Page 30
TAFJ-Mi c r o E E
trunTimeout Request processing parameter.
T24 processing timeout in
seconds before throwing a
session expiration.
jTA Processing parameter. Flag
whether EB.TRANS is part of a
JTA transaction or not.
jTATimeout Processing parameter. EB.TRANS
transaction timeout in seconds.
3.4.2.7 Management EJB properties (TAFJManagementBean)
Parameter Description
logoffBatchSessionOn Boolean configuration parameter
Destroy used on container stop. When set
to true, management bean will
trigger a logoff for all active batch
sessions.
logoffOnLineSessionO Boolean configuration parameter
nDestroy used on container stop. When set
'A.JBC.ROUTINE’ or
‘OTHER.JBC.ROUTINE’:
((?!\A.JBC.ROUTINE\b)
(?!\OTHER.JBC.ROUTIN
E\b).)*
60s
true means EB.TRANS is
managing a JTA global
transaction through
TRANSTART /
TRANSEND /
TRANSABORT.
Should be used to make
DB and CALLJEE part of
same unit of work.
When set to false, a local
JDBC transaction is used.
0 means use the default
application server JTA
timeout.
Default value
True – batch sessions can
be long running process
and could prevent some
container to stop until their
completion.
False – online sessions
should be short living
Page 31
TAFJ-Mi c r o E E

to true, management bean will process that we want to

trigger a logoff for all active online complete before container
sessions. goes down.

shutdownIdleOnLineSe Boolean configuration parameter True

ssion used to schedule a periodic idle
online sessions detection when
set to true.
The execution is running
periodically according
idleOnLineSessionThreshol
d parameter and triggers a logoff
on online sessions seen as idle for
same
idleOnLineSessionThreshol
d period.

idleOnLineSessionThr Integer parameter used for both 3600 – Min value 600
eshold periodic cleaner scheduling and
session idle detection threshold. A session is shutdown as
soon as the idle threshold
Unit is seconds. is reached and the
Minimal value is 10min non periodic cleaner execution
modifiable. A too short idle is triggered. It means a
detection should be avoided since session could be living idle
the cost of initializing a session is for almost two periodic
high and will impact the cleaner execution cycle in
worse case.
application response time.

serverRegistration Boolean configuration parameter False – the server

used to schedule a periodic server registration is not enabled
registration when set to true. by default.

The registration is a JMS

message published to the
t24ManagementTopic periodically
according
registrationFrequency
parameter.

Page 32
TAFJ-Mi c r o E E

The JMS registration message is

an object message containing a
com.temenos.tafj.sb.T24Se
rver object, representing the
server identity and its current
background sessions.

registrationFrequenc Integer parameter used to define 10s – Min value is 1s

y the JMS notification frequency in
seconds. It cannot be more than 1
notification per second.

registrationExpirati Integer parameter used to define a 12s - Must be higher than

on server registration validity in the registration frequency
seconds. If no new registration + 20% and at least 2s
notification for a specific server is
received before the registration
expiration threshold, the server
entry is removed from the server
registry.

ejbWarmup String parameter used to define OFSProcessingBean=0

an EJB to be initialized at server CallAtProcessingBean=0
startup.
This warmup pattern is an
This parameter must follow the example and doesn’t
pattern “EJBName=size” trigger any initialization
Where EJBName is the targeted since size is set to 0.
ejb OFSProcesingBean when
processing OFS or
CallAtProcessingBean when
processing CALLAT.

Size is an integer value

representing the number of
sessions for the channel to be
created.
synchronousWarmup Boolean parameter used in False – the ejb warmup is
conjunction with ejbWarmup. asynchronous and not
blocking the application
When set to true the management startup.
bean will wait for warmup When set to true block

Page 33
TAFJ-Mi c r o E E

completion before continuing the until warmup is complete

startup process. To avoid or warmupTimeout is
deadlock in case of warmup error, reached.
a timeout can be set through
warmupTimeout property.

Warmup operation will return

immediately when this parameter
is set to false.

Synchronous mode might not be

supported by all EE containers.

warmupTimeout Long parameter used in 60 – warmup operation

conjunction with
synchronousWarmup=true to
represent the maximum time to
wait in seconds for warmup to
complete before continuing the
startup process.
Not used when
synchronousWarmup=false.
will wait for 60s max
before returning.
This parameter should be
set accordingly with the
highest session
initialization time.
Considering warmup
pattern EJB1=1;EJB2=10
and initialization time of 5s
for EJB1 and 12s for
EJB2.

Since initialization is
triggered concurrently for
all EJBs,
warmupTimeout should
be higher than the longest
initialization duration
which is 12s in this
particular case.

managedWarmup Boolean parameter. When set to False – warmup actions

true, warmup actions are triggered are triggered by the
by a different thread than the startup thread.

Page 34
TAFJ-Mi c r o E E

startup thread.

Synchronous mode is not

available when set to true.

warmupDelay Integer parameter used in 0 – There is no delay

conjunction with between startup and
managedWarmup=true to warmup actions trigger.
introduce a delay between startup
and warmup invocation.

Introducing a delay could be

required by the platform to allow
resources startup completion
before EJB invocation.

synchronousTsaStartu Boolean parameter used in False – tSA messages

p conjunction with system property action is asysnchronous
temn.tafj.appserver.start by default.
.tsa=x

When a number of tSA has been

defined through the above
property x number of tSA
messages are sent to the
phantom queue.

tSA messages action will return

immediately when this parameter
is set to false.

Synchronous mode might not be

supported by all EE containers.

tsaStartupTimeout Long parameter used in 20 – tSA startup

conjunction with messaging will wait for
synchronousTsaStartup 20s max before returning.
=true to represent the maximum
time to wait in seconds to send
tSA messages to the phantom
queue before continuing the
startup process.

Page 35
TAFJ-Mi c r o E E

Not used when

synchronousTsaStartup
=false.

managedTsaStartup Boolean parameter. When set to False – tSA message

true, tSA message actions are actions are triggered by
triggered by a different thread than the startup thread.
the startup thread.

Synchronous mode is not

available when set to true.

tsaStartupDelay Integer parameter used in 0 – There is no delay

conjunction with between startup and TSA
managedTsaStartup =true to message actions trigger.
introduce a delay between startup
and tSA message invocation.

Introducing a delay could be

required by the platform to allow
resources startup completion
before JMS invocation.

Page 36