| Bookmark Name | Actions |
|---|
Application Configuration
This section explains the formalism (application.config or applicationConfig) of application configuration properties.
The application.config property format is used:
- In TAFJ configuration,
- In deployment descriptors to configure MDBs or EJBs and
- To configure the application itself, services behavior and processing parameters
A TAFJ property defined as an environment variable will take precedence on the property that is defined in TAFJ configuration (database).
It is possible to add the MDBs or EJBs properties 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. This configuration file replicates the configuration present in the TAFJJEE_EAR deployment descriptors.
Service Name
To identify which property applies to which service in the configuration file, a service name is defined per service type and applied as a property prefix.
| Service Type | EJB | Default Service Name |
|---|---|---|
|
Online processing |
OFSProcessingBean or CallAtProcessingBean |
None – It can be left empty or set through the channel_name property For example, channel_name=tws |
|
Phantom processing |
PhantomListener |
phantom |
|
tRun processing |
TRunProcessingBean |
trun |
|
Management activities |
TAFJManagementBean |
management |
Example to configure a channel for CALLAT (CALLAT processing) with no service name:
channel_type=callat ofsSource=JAVA.FRAMEWORK ofsTimeout=30
Example to configure a channel for Browser Web (OFS processing) 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:
management.ejbWarmup=OFSProcessingBean=2 management.tsaStart=3 management.logoffBatchSessionOnDestroy=true management.logoffOnLineSessionOnDestroy=false
Differences in MDB and EJB Configuration
The MDB and EJB configuration is same and usually done through deployment descriptors. However, both the configuration has the following difference:
EJB warmup - Since there is only one channel per deployment, the EJB warmup pattern is simplified and applies for a single EJB type. When you run an OFS channel, the pattern is ejbWarmup=OFSProcessingBean=5 and when you run a CALLAT channel, the pattern is ejbWarmup=CallAtProcessingBean=5.
Online MDB Properties (TransactedMDB)
| Parameter | Description | Default Value |
|---|---|---|
|
defaultFormatter |
It is a message formatting and String parameter. The formatter should be applied on the message to transform it. To apply a specific formatter, you need to add the fully qualified class name of the formatter in the value field and make it available in the application server classpath.
|
None
|
|
defaultPrincipal |
It is a message formatting and String parameter. You can define a default principal for the associated message channel. |
None
|
|
responseDeliveryMode |
It is a response processing and integer parameter. It defines whether response message is delivered as a PERSISTENT or NON-PERSISTENT message. Closed set of values: 1: Means NON-PERSISTENT 2: Means PERSISTENT |
1 |
|
sendToJmsReplyTo |
It is a response processing and Boolean parameter. It defines whether response message is sent to the destination, which is defined through the getJMSReplyTo message property. Closed set of values: true: Use the getJMSReplyTo message property false: Use the jmsReplyQueue defined at MDB level |
false |
|
messageIdAsCorrelationID |
It is a response processing and Boolean parameter. It 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 |
false |
|
responseTimeToLive |
It is a response processing and integer parameter. It specifies the response time to live in milliseconds from its dispatch time before being removed from the destination queue, if not consumed.
|
0 means unlimited time to live. |
|
useRequestPriority |
It is a response processing and Boolean parameter. It makes use of same JMS message priority than the one set for the request when set to true.
|
false |
|
responsePriority |
It is a response processing and integer parameter. It defines the JMS message response priority. |
None means default priority (4) – Valid priority is between 0 and 9. 9 is the highest priority.
Not considered when useRequestPriority is true. |
|
skipResponse |
It is a response processing and boolean parameter. It does not send the EJB response to reply queue when set to true. It should be used when there is no consumer registered to reply queue and avoid response message piling up on reply queue. |
False |
|
ignoreRedeliveredMessage |
It is a error handling and boolean parameter. In case of message redelivery, this flag can be enabled to avoid message re-processing in Temenos Transact. MDB will receive the message but not pass it to EJB. Closed set of values: false: Redelivered message are sent to EJB or Temenos Transact true: Message are ignored and a response is sent to the client that this is a redelivered message. |
true |
|
maxJmsRedeliveryAttempt |
It is a error handling and integer parameter. In case of message redelivery, if this value is greater or equal than 0, the JMSXDeliveryCount message property is checked 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. |
-1 means disabled
To define no re-delivery set this value to 0.
To define one re-delivery set this value to 1. |
|
recoverFromJmsFailure |
It is a error handling and Boolean parameter. In case of JMS exception at MDB level, this flag when set to true will call setRollbackOnly or will throw an EJB exception to discard the MDB when set to false. |
true |
|
sendRedeliveredMessageResponse |
It is a error handling and Boolean parameter. In case of incoming JMS redelivered message, ignored and not processed, a response (JMS Message redelivered) is sent to the reply queue. Setting this property to false will not send any response to the reply queue. |
true |
|
overrideThreadName |
It overrides the default thread name which appears in application server in specific format to identify TAFJ online threads. TAFJ-%hostname%-%channelName%-thread-%thread number% |
false |
Online EJB Properties (OFSProcessingBean or CallAtProcessingBean)
| Parameter | Description | Default Value |
|---|---|---|
|
ofsSource |
It is a request processing and String parameter. It should match an existing Temenos Transact OFS source.
|
None – You need to setup.
|
|
ofsTimeout |
It is a request processing and integer parameter. It specifies the time in seconds before request expiration at Temenos Transact level. |
0 – means no timeout
|
|
resetThreshold |
It is a request processing and integer parameter. It defines after how many request the session can be reset. Disabled if <= 0 It impacts the performance and needs to be used for TWS channel.
|
0 – default, means no reset Possible values are: 1 – means resetting the session after each request TWS setup 100 – means resetting the session every 100 request
|
|
idleDetection |
It is a 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. |
True – means idle detection is enabled. Sessions are being shut down when detected as idle by the management bean periodic cleaner.
|
|
ofsTimeoutMessage |
It is an error handling and a String parameter. The value associated to this parameter will be used as a response in case of ofs timeout. |
Null – means the TAFJ runtime message related to the ofs timeout exception is sent.
|
|
ofsErrorMessage |
It is an error handling and String parameter. The value associated to this parameter will be used as a response in case of ofs error. |
Null – means the TAFJ runtime message related to generic ofs exception is sent.
|
|
overrideErrorMessage |
It is an error handling and 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”. This is also the case for the “SEAT” OFS source. |
false – means the response is sent as is. |
|
retryOnStop |
It is an error handling and integer parameter. It specifies the number of retries 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, etc). The time between each retry is nRetryCount * nRetryCount seconds, where nRetryCount is the current retry number. |
3 means 3 retry in case of STOP. |
|
rollbackContainerOnInitError |
It is an error handling parameter for CMT EJBs. It is also a 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. |
true |
|
jTA |
It is a boolean processing parameter. EB.TRANS local transaction management is disabled when set to true. It enables a global transaction support at EJB level when there is a need for 2PC. The OFS.BULK.MANAGER flag requestCommitted is considered to commit or rollback the transaction for OFS processing. A commit is issued for CALLAT processing. |
false – means a local transaction is managed by EB.TRANS.
Should be used to make DB and CALLJEE part of same unit of work in case of CALLJEE usage in online processing.
|
|
jtaEBManaged |
It is a boolean processing parameter and should be used in conjunction with JTA mode, which is enabled to manage the 2PC.
It 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. |
false – means the JTA transaction is managed at EJB level. |
|
rollbackRequestOnStop |
It is an error handling and boolean parameter.
When set to true a STOP will mark the request to be rollback at MDB level for redelivery. The corresponding MDB has to be configured to accept redelivered messages to allow a reprocessing. See MDB configuration section ignoreRedeliveredMessage=false. A duplicate check is advised for safe reprocessing.
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). |
false |
|
rollbackRequestOnCommitError |
It is an error handling and boolean parameter. When set to true, a commit error (OFS.BULK.MANAGER requestCommitted attribute not equal to 1) will mark the request to be rollback at MDB level for redelivery. 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 redelivered messages to allow a reprocessing. See MDB configuration section ignoreRedeliveredMessage=false. A duplicate check is advised for safe reprocessing. If the error causing the commit error is not solved by the time the request is reprocessed, 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). |
false |
Phantom MDB (PhantomListener)
| Parameter | Description | Default Value |
|---|---|---|
|
jTA |
It is a processing parameter. Flag whether EB.TRANS is part of a JTA transaction or not. |
true means EB.TRANS is managing a JTA global transaction through TRANSTART, TRANSEND or TRANSABORT. It should be used to make DB and CALLJEE part of same unit of work. When set to false, a local JDBC transaction is used. |
|
jTATimeout |
It is a processing parameter and specifies EB.TRANS transaction timeout in seconds. |
Default value is 3600 to do not timeout agents waiting for the main select to complete. 0 means use the default application server JTA timeout. |
|
maxJmsRedeliveryAttempt |
It is an error handling and integer parameter. In case of message redelivery, if this value is greater or equal than 0, then the message property JMSXDeliveryCount is checked 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 redelivered messages are ignored. |
-1 means disabled.
To define no redelivery set this value to 0.
To define one redelivery, set this value to 1. |
tRun EJB Properties (TRunProcessingBean)
| Parameter | Description | Default Value |
|---|---|---|
|
allowedCommand |
It is a request processing parameter, which defines the authorized programs that can be executed through tRun EJB invocation. It is a regular expression and takes precedence on the temn.tafj.appserver.trun.allowed.commands tafj property.
|
None To allow executing 'A.JBC.ROUTINE’ or ‘OTHER.JBC.ROUTINE’ only:
\bA.JBC.ROUTINE \b|\bOTHER.JBC.ROUTINE\b
To allow everything but 'A.JBC.ROUTINE’ or ‘OTHER.JBC.ROUTINE’: ((?!\A.JBC.ROUTINE\b)(?!\OTHER.JBC.ROUTINE\b).)*
|
|
trunTimeout |
It is a request processing parameter and specifies Temenos Transact processing timeout in seconds before throwing a session expiration. |
60 seconds |
|
jTA |
It is a processing parameter and specifies a flag whether EB.TRANS is part of a JTA transaction or not. |
true means EB.TRANS is managing a JTA global transaction through TRANSTART, TRANSEND or TRANSABORT. It should be used to make DB and CALLJEE part of same unit of work. When set to false, a local JDBC transaction is used. |
|
jTATimeout |
It is a processing parameter and specifies EB.TRANS transaction timeout in seconds. |
0 means use the default application server JTA timeout. |
Management EJB Properties (TAFJManagementBean)
| Parameter | Description | Default Value |
|---|---|---|
|
logoffBatchSessionOnDestroy |
It is a boolean configuration parameter, which is used on container stop. When set to true, management bean will trigger a logoff for all active batch sessions.
|
True – Batch sessions can be long running process and could prevent some container to stop until their completion.
|
|
logoffOnLineSessionOnDestroy |
It is a boolean configuration parameter, which is used on container stop. When set to true, management bean will trigger a logoff for all active online sessions.
|
False – Online sessions should be short living process that you want to complete before container goes down.
|
|
shutdownIdleOnLineSession |
It is a boolean configuration parameter, which is used to schedule a periodic idle online sessions detection when set to true. The execution is running periodically according to the idleOnLineSessionThreshold parameter and triggers a logoff on online sessions, which is seen as idle for same idleOnLineSessionThreshold period.
|
True
|
|
idleOnLineSessionThreshold |
It is an integer parameter, which is used for both periodic cleaner scheduling and session idle detection threshold. Unit is seconds. Minimal value is 10 minutes and non editable. A too short idle detection should be avoided since the cost of initializing a session is high and will impact the application response time.
|
3600 – Min value 600 A session is shutdown as soon as the idle threshold is reached and the periodic cleaner execution is triggered. It means a session could be living idle for almost two periodic cleaner execution cycle in worse case. |
|
serverRegistration |
It is a boolean configuration parameter, which is used to schedule a periodic server registration when set to true. The registration is a JMS message published to the t24ManagementTopic property periodically according to the registrationFrequency parameter. The JMS registration message is an object message containing a com.temenos.tafj.sb.T24Server object, which represents the server identity and its current background sessions. |
False – The server registration is not enabled by default. |
|
registrationFrequency |
It is an integer parameter, which is used to define the JMS notification frequency in seconds. It cannot be more than one notification per second. |
10s – Min value is 1s |
|
registrationExpiration |
It is an integer parameter, which is used to define a server registration validity in seconds. If no new registration notification for a specific server is received before the registration expiration threshold, then the server entry is removed from the server registry. |
12s - Must be higher than the registration frequency + 20% and at least 2s |
|
ejbWarmup |
It is a String parameter, which is used to define an EJB to be initialized at server startup. This parameter must follow the pattern EJBName=size Where, EJBName is the targeted 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. |
OFSProcessingBean=0 CallAtProcessingBean=0 This warmup pattern is an example and doesn’t trigger any initialization since size is set to 0. |
|
synchronousWarmup |
It is a boolean parameter, which is used in conjunction with ejbWarmup. When set to true, the management bean will wait for warmup completion before continuing the startup process. To avoid deadlock in case of warmup error, 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.
|
False – The EJB warmup is asynchronous and not blocking the application startup. When set to true, block until warmup is complete or warmupTimeout is reached.
|
|
warmupTimeout |
It is a Long parameter used in conjunction with synchronousWarmup=true to represent the maximum time to wait in seconds for warmup to complete before continuing the startup process. It is not used when synchronousWarmup=false. |
60 – Warmup operation 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 |
It is a boolean parameter. When set to true, warmup actions are triggered by a different thread rather than the startup thread. Synchronous mode is not available when set to true. |
False – Warmup actions are triggered by the startup thread. |
|
warmupDelay |
It is an integer parameter, which is used in conjunction with managedWarmup=true to 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. |
0 – There is no delay between startup and warmup actions trigger. |
|
synchronousTsaStartup |
It is a boolean parameter, which is used in conjunction with the temn.tafj.appserver.start.tsa=x system property When a number of tSA has been defined through the above property x, the same 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.
|
False – tSA messages action is asysnchronous by default. |
|
tsaStartupTimeout |
It is a Long parameter, which is used in conjunction with synchronousTsaStartup =true to represent the maximum time to wait in seconds to send tSA messages to the phantom queue before continuing the startup process. It is not used when synchronousTsaStartup =false. |
20 – tSA startup messaging will wait for 20s max before returning.
|
|
managedTsaStartup |
It is a boolean parameter. When set to true, tSA message actions are triggered by a different thread than the startup thread. Synchronous mode is not available when set to true. |
False – tSA message actions are triggered by the startup thread. |
|
tsaStartupDelay |
It is an integer parameter, which is used in conjunction with managed TsaStartup =true to 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. |
0 – There is no delay between startup and TSA message actions trigger. |
Add Bookmark
save your best linksView Bookmarks
Visit your best linksIn this topic
Are you sure you want to log-off?