CSD - Java Programming Standards (1) 1

T24 - Client Specific Development
Java Programming Standards
Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means,
for any purpose, without the express written permission of TEMENOS HEADQUARTERS SA.
© 2020 Temenos Headquarters SA - all rights reserved.
CSD Programming Standards
Version Date Author Status Description
Initial
V.01 06-Jul-2020 Yeshvanth
Updated
V.01 09-Jul-2020 Vignesh
Updated
V.01 09-Jul-2020 Aiswariya
Updated
V.01 09-Jul-2020 Devika
Updated
V.01 09-Jul-2020 Tamil
Review
V.02 14-Jul-2020 Sourabh
Updated
V.03 15-Jul-2020 Yeshvanth
Siva
Chandran Baselined
V.1.0 18-Jul-2020
2 V1.0 /Jul-20 Quality Assurance Internal Use

Contents
1) INTRODUCTION....................................................................................................................................................................... 6
2) BASIC CODING STANDARDS: ................................................................................................................................................... 6
3) CONFIGURATION and DEBUG PROCEDURES: ......................................................................................................................... 8
4) QUALITY, CONVENTIONS and PACKAGING: ............................................................................................................................ 8
4.1 Naming Conventions .......................................................................................................................................................... 8
4.2 Usage of Variables ............................................................................................................................................................ 10
4.3 Program Qualities............................................................................................................................................................. 10
4.3.1 Comments ............................................................................................................................................ 11

4.4 Basics of JAVA Programming ............................................................................................................................................ 14
4.4.1 Interfaces ............................................................................................................................................. 14

4.4.2 Methods .............................................................................................................................................. 17
4.4.3 Typical Input & Output ......................................................................................................................... 20
4.4.4 Java Considerations.............................................................................................................................. 20
4.4.5 API - Alias............................................................................................................................................. 23
4.5 Secure coding Guidelines .................................................................................................................................................. 24
4.6 Packaging ......................................................................................................................................................................... 24
5) JAVA PROGRAMMING: ......................................................................................................................................................... 24
5.1 Local Field values .............................................................................................................................................................. 24
5.1.1 Usage of Local Field Related API ........................................................................................................... 25

5.2 Usage of Control and Looping Statements: ...................................................................................................................... 26
5.2.1 If … else Statement ............................................................................................................................... 26

5.2.2 For Loop ............................................................................................................................................... 27
5.2.3 For Each Loop ....................................................................................................................................... 27
5.2.4 While Loop ........................................................................................................................................... 28
5.2.5 Do-while Loop ...................................................................................................................................... 29
5.2.6 Switch Case .......................................................................................................................................... 29
5.3 File Handling ..................................................................................................................................................................... 30

5.4 Exception Handling ........................................................................................................................................................... 34

5.5 COB & Multithread Routines ............................................................................................................................................ 36
5.6 AA Batch Processing ......................................................................................................................................................... 39
5.7 ActivityLifecycle Routines ................................................................................................................................................. 39
5.7.1 Local Commons in AA: .......................................................................................................................... 40

6) CORE API’S ............................................................................................................................................................................ 44
6.1 Amount API....................................................................................................................................................................... 45
6.1.1 getAvailableAmount ............................................................................................................................ 45

6.1.2 getBalance ........................................................................................................................................... 45
6.1.3 getTurnoverCredit ................................................................................................................................ 45
6.1.4 getTurnoverCredit ................................................................................................................................ 45
6.2 Date Manipulation ........................................................................................................................................................... 46
6.2.1 addWorkingDays.................................................................................................................................. 46
6.2.2 getWorkingDayDifference .................................................................................................................... 46
6.2.3 getMonthDifference ............................................................................................................................. 46
6.2.4 getgregorianToJulian ........................................................................................................................... 46
6.2.5 getgregorianToJulian ........................................................................................................................... 47
6.2.6 plusDays .............................................................................................................................................. 47
6.3 Exchange Rate .................................................................................................................................................................. 47
6.3.1 calculateRate ....................................................................................................................................... 47

6.3.2 calculateBuyExchangeRateAmount....................................................................................................... 48
6.3.3 calculateExchangeRate......................................................................................................................... 48
6.3.4 calculateBuyAmount ............................................................................................................................ 48
6.4 ST.Customer Api ............................................................................................................................................................... 48
6.5 LI.Limit Api ........................................................................................................................................................................ 50
6.6 EB.Session Api ................................................................................................................................................................... 50
6.7 AA Api ............................................................................................................................................................................... 51
6.7.1 AA.Contract Api ................................................................................................................................... 51

6.7.2 AA.PRODUCT Api .................................................................................................................................. 61
6.7.3 AA.PROPERTY Api................................................................................................................................. 61
6.7.4 AA.PROPERTY.CLASS.API ...................................................................................................................... 62
7) Other Important points to be noted: .................................................................................................................................... 62
7.1 Logging/Debugging .......................................................................................................................................................... 62
7.2 Mathematical Calculation ................................................................................................................................................ 62

7.3 OCRT using Sonarcube ...................................................................................................................................................... 62

7.4 Tackle Quality Issues ........................................................................................................................................................ 63
7.5 Navigating and Generating Javadocs ............................................................................................................................... 63
8) REFERENCE DOCUMENTS ..................................................................................................................................................... 70
DISCLAIMER:
This document is based on R20 release and subject to be reviewed based on the release.

1) INTRODUCTION
Programming Standards is a set of rules or guidelines used when coding programs in a particular language. It is often
claimed that following a particular programming style/Standard will help programmers to read and understand the
purpose for which the source code is developed, and help to avoid introducing errors while developing codes.
A particular Programming Standard which is applicable for one language may not be applicable for another. Hence,
Programming styles are often designed for a specific programming language style which may be derived from the
Coding Standards or Code conventions specific to company or other computing organization, as well as the preferences
of the author of the code.
This document defines the CSD Java coding standards. These standards should be used and adhered to by any person
that creates or modifies any code produced by the CSD product development team. This document shall be reviewed
on a periodic basis in order to ensure consistency with T24 release specific developer guides.
2) BASIC CODING STANDARDS:
This section aims at projecting the basic points that should be adhered while coding programs in JAVA.
1. All java codes must be followed the basic coding standards.
2. Usage of core interfaces, Methods, functions and extending the super classes should be appropriate.
3. Parameters for the any Java method should be captured with the valid specification usage as comments.
4. Every possible internal exceptions should be handled with proper with T24Core exception.
Example:

5. Add Comments, wherever the logic in not straight forward. Always question if a new coder can understand our
code? if not change logic or add comments.
6. Use meaningful variable Names and method Names.
7. Do code formatting, eclipse Shortcut Key Ctrl+Shift+F or enable automatic Formatting with below configuration.
8. For constants use uppercase variable names with underscores. E.g, static final string OFS_SOURCE = “TESTOFS”.
9. Avoid initialization of DataAccess & Session variables in every sub-method. Declare one instance variable, Initialize
that in Parent method(overriding hook method) and use the instance variable in sub-methods.
10. By default create all sub-methods as private. Create public methods only if we want to access them using an object
from different classes.

11. Use SonarLint plugin with eclipse, which will highlight the code review errors in blue as we type code. (we need to
install eclipse market place plugin first and then we can install sonarLint from market place)
3) CONFIGURATION and DEBUG PROCEDURES:
Following document provides an overview of Design Studio configuration in terms of Jar and debugging a java code
https://temenosgroup.sharepoint.com/:w:/r/temenosteams/CSD/_layouts/15/Doc.aspx?sourcedoc=%7B12DB0C3D-
A505-40CA-8FAB-B6B58730037C%7D&file=L3%20Java%20API-
%20Eclipse%20Configuration%20and%20Debug%20Procedures..doc&action=default&mobileredirect=true
4) QUALITY, CONVENTIONS and PACKAGING:

4.1 Naming Conventions
A naming convention is a set of guidelines recommended for choosing the sequence of characters to be used for
identifiers which denote variables, labels and functions etc. in source code.
Appropriate choices for variable names are the keystone for good style. Poorly named variables make code harder to
read and understand.
Reasons for using a naming convention is
1. To reduce the effort needed to read and understand source code.
2. To find out the value which the variable holds.
3. To understand the purpose for which the variable is defined
The naming conventions with respect to Java programming is sculptured below.

1) Java Classes
All java classes to follow the below naming conventions.
<Class name> can be meaningful name along with Dev Name / Interface Name / BRD Name
• Interface Name ( Example : Bacs, Chap )

• DEV Name ( Example : Apr, Irr ) Example:
CsdAncBacsIdUpdate.java
CsdInpAprCalcUpdate.java
2) Data Records
All Data records to follow the below naming conventions
Data Record Type Sample Name
TEMPLATE CSD.<TEMPLATENAME>
VERSION <APPLICATION>,CSD.<VERSIONNAME>
ENQUIRY CSD.<ENQUIRYNAME>
EB.ERROR EB-CSD.<ERRORMSGNAME>
EB.COMPOSITE.SCREEN CSD.<COSNAME>
EB.TABBED.SCREEN CSD.<TABNAME>
BATCH / TSA.SERVICE <COMP.MNE>/CSD.<BATCHNAME>
OVERRIDE CSD.<OVRMSGNAME>
DEAL.SLIP.FORMAT CSD.<DEALSLIPNAME>
OFS.SOURCE CSD.<RTNNAME>
STANDARD.SELECTION CSD.<TEMPLATENAME>
LOCAL.TABLE CSD.<LOCALTABLENAME>
HELPTEXT.MENU CSD.<MENUNAME>
BATCH.NEW.COMPANY CSD.<BATCHNAME>
AA.PRD.DES.<PROPERTYCLASS> CSD.<ProductConditionName>
AA.PRD.DES.ACTIVITY.PRESENTATION CSD.<ActivityPresentationName>
AA.PRD.DES.ACTIVITY.CHARGES CSD.<ActivityChargeName>
REPORT.CONTROL CSD.RC.<ENQ.NAME>

ENQUIRY.REPORT CSD.ER.<ENQ.NAME>
Note: All L3 specific data should have the keyword “CSD” irrespective of the above table. The
sections given in Angular brackets (* <> *) should be meaningful and short name Example: For a
BATCH record <COMP.MNE>/CSD.<BATCHNAME> the name could be BNK/CSD.APR.CALC
Where <COMP.MNE> BNK
<BATCHNAME> APR.CALC
4.2 Usage of Variables
1. Any local variables required by the method should be declared as late as possible (i.e. immediately before
their first usage) and with the most restricted scope possible.
2. Variables used within loops however must be defined outside and prior to the loop.
3. Local variables should be given meaningful names with single character names only used for very short-term
technical reasons (i.e. looping within “for” statements etc.).
4. Variable names must be spelt using firstWordLowerCase ButInternalWordsCapitalized style and negated
Boolean variable names must be avoided (e.g. use isError rather than isNotError).
5. At the end of each method, a code section should be inserted to nullify any reference variables that are no
longer being used (this is especially required for elements of arrays).
4.3 Program Qualities
The quality of a program is not only measured by the online / manual review points but also on the level “Simplicity of
the program “.
If so, what does the term “Simplicity” means?
Simplicity of program can be measured from the level of understanding by another personal on his/her first look over
the routine irrespective to whether the person knows the programming or not.

It is easy to make a programmer understand but how come the other personnel’s?
This can be achieved by giving proper comments and using meaningful variables in the program.
4.3.1 Comments
Comments in programming language is simply the programmer’s annotation about the flow of the routine as well as
purpose of the usage of variables and methods and functions defined in the class. Those annotations are potentially
significate to programmers but typically ignorable to compilers and interpreters
Comments are usually added with the purpose of making the source code easier to understand. The syntax and rules
for comments vary and are usually defined in a programming language specification
With respect to java classes, we have got some standard formats of commenting a program. We divide
the commenting as 2 parts.
They are:-
• Generic Comments
• Functional Comments
1) GENERIC COMMENTS
Each class file should have the following information at the start of the file:
• Standard title information showing:
▪ Title of class
▪ Author (original)
▪ Date Created
e.g.
*
* Title : VersionInfo.java
* Author : Tony Hall
* Date Created : 03/01/2001
*
*/

• A Javadoc section (i.e. contained within /** ... **/) detailing:
▪ Purpose of class
▪ Usage Instructions
▪ Examples of where the class is called/used
If there is a change in the code then it has to be a CR or defects from client (PACS tickets). Internal defect is not
necessary as we consider it as internal.
If a fix is developed for the routine, then the fix should contain proper “MODIFICATION DETAILS” like
modification date, defect number.
The modification history should be defined in the format as specified below,
* Modification Details:
* -----------------------------
* 04/05/15 - 1666397
Enquiry crashes and times out if date input is other than 8 digits,
since fatal error is called while call to CDT. Before processing
validation of dates carried out and proper error message thrown to
Overcome fatal out.
2. FUNCTIONAL COMMENTS
The functional comments are nothing but the comments that will project the functionality of set of codes or a line of

code where the programmer wish to explain to the program views.
With respect to L3 Java, it is advisable for a programmer to provide a brief introduction about each and every
method, function and every possible set of code section in the beginning before start coding it.
The below given example will illustrate a sample of Functional Commenting.
// Raise error if any duplicate Channel and Currency found

int mvcount = 0;
for (String ChannelCcy : channelCcyList) {
if (channelCcySet.contains(ChannelCcy)) {
errMsg.clear();
errMsg.add("EB-DUPLICATE");
channelList.get(mvcount).getLocalRefField(csdChannelField).setError(errMsg.to
String());
break;
} else {
channelCcySet.add(ChannelCcy);
mvcount++;
}
}

4.4 Basics of JAVA Programming
4.4.1 Interfaces
Interfaces created for the CSD product should adhere to the following standards:
I. Interface Names & Files
Each interface should be placed in a separate physical file within the appropriate package directory. The file
name for each interface must be the same as the interface name itself. This name should reflect the nature and
purpose of the interface within the package and be spelt using the
INameStartsWithIWithInternalWordsAlsoCapitalized style.
e.g. IEditor.java
IVerifyValidation.java
Interfaces should be placed in the parent package when implementations are in their own packages. If there is a
base implementation or all implementations are in the same package, the interface should be placed with its
implementations.
II. Header information, Member Constants, Methods
The format and position of declarations in an Interface is identical to their equivalent in a class. Please see below
for guidelines on class definitions and content. If there is a base implementation, then the specific class should be
referenced in the Header information.
1) Classes
Classes created for the CSD product should adhere to the following standards:
I. Class Names & Files

Each class should be placed in a separate physical file within the appropriate package directory. The only
exception to this is for small private classes which can be defined as inner classes within the main class.
The file name for each class must be the same as the class name itself. This name should reflect the nature and
purpose of the class within the package and be spelt using the CapitalizedWithInternal WordsAlsoCapitalized
style.
e.g. GenerateInstallKey.java
FormContext.java
II. Class Structure & Limits

All classes must conform to the following structure and limits:
o Class elements must be defined in the following order:
Static final constants

Static blocks (for initialization only)
Inner Classes
Member variables
Constructor
Methods
o The class file must not contain any tab characters

o No line may end with space character.
o Each block of code within curly braces must be indented by 4 spaces.
o Lines must be no longer than 160 characters
o Files must not be longer than 2000 lines
III. Static Final Constants
All static final constants must be defined first at the top of the class immediately following the heading
information and must be defined as follows:
• Names must reflect the nature and purpose of the constant and must be spelt using the
UPPER_CASE_WITH_UNDERSCORES style.
• Associated constants should be prefixed by a common name (e.g. final int COLOR_RED = 1,
COLOR_GREEN = 2, COLOR_BLUE = 3;)
• If the name of a constant does not clearly indicate its purpose and usage, an additional Javadoc
comment must be included above, as follows.
/** <description of usage and purpose> */

public static final ATT_IS_DYNAMIC = “IsDynamic”;

All references to constants, whether defined within the same class or externally, must be referenced as
“Class.CONSTANT”.
Constants should be used in the following circumstances:
• In place of magic numbers.
e.g. use “if (action == Class.ACTION_EDIT)”

instead of “if (action == 3)”
Whenever a constant value needs to be passed as a parameter value.

Whenever a value is used more than once in the same class.
Whenever a value is used in an equals condition.
e.g use “if (Class.CLOSE_CMD.equals(p_command) )”

instead of “if ( “close”.equals(p_command))”
IV. Static variables
Static variables should be used when initializing static information. Few declarations needs to be static and should not be
overwritten in the code.
Eg:
public static String youtdir;

public static List<String> checkDays;
public static String yToday;
public static String yCompanyid = "";
public static String yCompMnem = "";
V. Inner and Anonymous classes
These classes should contain no more than 20 lines of code and should only be used when referenced internally by the outer
class. Format and naming conventions are identical to the main class.
Inner classes are generally only to be used for encapsulation of related variables.
VI. Member Variables
All class variables must be defined at the top of the class, immediately following the Header Information. Names
must reflect the nature and purpose of the variable and be spelt using the m_firstWordLowerCaseButInternal
WordsCapitalized style.

If the name of a member variable does not clearly indicate its purpose and usage or the member variable is a
complex type (e.g. Hash map), an additional Javadoc comment must be included above to describe the variable’s
usage and purpose.
e.g.
/** Stores phase objects against full name of phase */
private HashMap m_phaseLookup = null;
All variables must be initialised when they are declared, with null or a relevant value.
VII. Constructor
Constructors should generally be kept simple and used to initialize member variables. If members require
resetting following initialization, the initializations should be placed in a specific method and called from the
constructor.
4.4.2 Methods
Methods defined within CSD classes should adhere to the following standards:
I. Method Names
Each method should be designed to only perform a single task and their name must reflect the nature and
purpose of that method within the class. Method names should be spelt using the
firstWordLowerCaseButInternalWordsCapitalized() style.
e.g. startSplashFrame()
setStatusBarMessage()
Methods that are designed to manipulate attributes should be named according to the action they perform and
the attribute they act upon:
e.g. int getDebugLevel()

int setPresentationType()
Methods that return boolean values should be named according to the condition the Boolean value refers to:

e.g. boolean isLicenseValid()

boolean canServerBeStarted()
Methods that return collections should be named to highlight that a collection is involved:
e.g. ArrayList getListOfPhases()

Class[] getSelectableClasses()
The following complementary names should be used when implementing these types of action via methods:
get/set, add/remove, create/destroy, start/stop, insert/delete, increment/decrement, old/new, begin/end,

first/last, up/down, min/max, next/previous, old/new, open/close, show/hide
II. Parameters
Parameters must be meaningfully named and spelt using the p_firstWordLowerCase

ButInternalWordsCapitalized style.
Methods should have no more than 10 parameters. Also, a method must not return a collection or object defined
as private, otherwise the object may be incorrectly modified by the caller. Instead, a copy of the object should be
passed or the object should be defined as unmodifiable.
III. Header Information and Comments
Where a method performs more than just the getting or setting of attributes (i.e. some level of processing is
involved), a description of the method must be placed immediately following the method name using a Javadoc
section (i.e. contained within /** ... **/). The section must detail the following information:
• A description of the method, including any significant conditional processing that the method performs.
• Instructions on how to call and use the method, including any considerations for the passing of
parameters (e.g. parameters cannot be passed as null).
Following the Javadoc section, comment sections must be added before each logical group of code which
describes the purpose of the code group. These comment sections should be inserted at least every 15 lines of
code although this should be more regular for complex areas.
Finally, any conditional statements which are not obvious to understand within the context of the described
logical group must have preceding comment line(s) describing the reason and nature of the test.

IV. Variables
Any local variables required by the method should be declared as late as possible (i.e. immediately before their
first usage) and with the most restricted scope possible. Variables used within loops however must be defined
outside and prior to the loop.
Local variables should be given meaningful names with single character names only used for very short-term
technical reasons (i.e. looping within “for” statements etc.). Variable names must be spelt using
firstWordLowerCase ButInternalWordsCapitalized style and negated boolean variable names must be avoided
(e.g. use isError rather than isNotError).
At the end of each method, a code section should be inserted to nullify any reference variables that are no longer
being used (this is especially required for elements of arrays).
V. Exception Handling
Whenever a method is added/changed, we must consider what exception handling is necessary. When adding exception
handling, the following rules must be adhered to:
▪ All interactions with external devices must have exception handling with specific actions defined for all possible causes.
External devices include files, directories, web servers etc.
▪ All caught exceptions must have comments explaining how the exception has occurred and what action will be taken.
▪ If we are forced to catch the exception of another method and we do not want to do anything with the exception, we
must add comments into the catch section detailing what exceptions could occur and why we have decided to swallow
them on purpose.
▪ All caught and swallowed exceptions must be reported in the appropriate product logs. This should be done by using the
standard ExceptionUtility class.
▪ Where possible, specific exceptions should be caught individually and appropriate action taken.
VI. Structure and limits
All methods must conform to the following structure and limits:
o Methods must be a maximum of 100 lines and typically no more than 50 lines.
o One line of code should not call more than 2 functions.
o An indentation of 4 spaces must be used for coding lines.
o There should be no spacing between the method name and the following open parenthesis.
o There should be 1 space between conditional statements and their following parenthesis and 1 space between the
operands and the variables etc.
(e.g. “if (x == y)”)
o Left and right braces (i.e. “{}”) must be placed on separate lines, at the beginning and matching braces must be
indented the same amount.

o Spill-over lines must be indented when breaking up long lines and positioned to maximise readability and group
related items. For example, a spill-over of parameters should be continued on the next line directly below the 1st set
of parameters.
4.4.3 Typical Input & Output
Input
462 private void loadEnvironmentVariables()
463 {
464 Process p = null;
465 Properties envVars = new Properties();
466 Runtime r = Runtime.getRuntime();
467 String OS = System.getProperty("os.name").toLowerCase();
468 // System.out.println(OS);
469 try
470 {
471 if (OS.indexOf("windows 9") > -1)
472 {
473 p = r.exec( "command.com /c set" );
474 }
475 else if ( (OS.indexOf("nt") > -1) || (OS.indexOf("windows 2000") > -1 ) || (OS.indexOf("windows xp") > -1) )
476 {
477 p = r.exec( "cmd.exe /c set" );
478 }
Output
com\acquire\intelligentforms\FormContext.java:467:16: warning: Name 'OS' must match pattern '^[a-z][a-zA-Z0-9]*$'.

com\acquire\intelligentforms\FormContext.java:471: Line has trailing spaces.
com\acquire\intelligentforms\FormContext.java:471:1: Line contains a tab character.
com\acquire\intelligentforms\FormContext.java:473:29: warning: '(' is followed by whitespace.
com\acquire\intelligentforms\FormContext.java:473:50: warning: ')' is preceded with whitespace.
com\acquire\intelligentforms\FormContext.java:475: Line has trailing spaces.
4.4.4 Java Considerations
1) Naming Conventions
• Constant Names ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$
• Local Final variable Names ^[a-z][a-zA-Z0-9]*$
• Local variable Names ^[a-z][a-zA-Z0-9]*$
• Member Names ^m_[a-z][a-zA-Z0-9]*$

• Method Names ^[a-z][a-zA-Z0-9]*$

• Package Names ^[a-z]+(\.[a-zA-Z_][a-zA-Z0-9_]*)*$
• Parameter Names ^p_[a-z][a-zA-Z0-9]*$
• Static variable Names ^[a-z][a-zA-Z0-9]*$
• Constant Names ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$
• Type Names ^[A-Z][a-zA-Z0-9]*$
2) Headers
• Checks file contains some text such as copyright statement. Disabled
3) Imports
• Import statements should be considered as per the below points.
• Avoid star. Disabled
• Illegal imports
• Redundant imports
• Unused imports
4) Size violation
Size limitation should be maintained as per the below considerations.
• Maximum file length 2000

• Maximum line length 160
• Maximum method length 200
• Maximum parameters 10
• Annoyminous inner class length 20
5) Whitespace
Whitespaces should be configured as per the below considerations
• Empty for iterator Pad = nospace

• Method parameter Pad = nospace
• No whitespace after = {Array initialization, ~, --, ., ++, !, -, +)
• No whitespace before = (:, --, ++)
• Operator wrap = lost of conditional operators and bit operators
• Paren Pad = nospace (Constructor calls, (, method calls, ), super constructor calls)
• Typecast Paren Pad = nospace (typecast, ) )
• Tab character = check no tab char exists
• Whitespace after = (comma, semicolon)
• whitespace around = Lots of conditional operators and bit operators
6) Modifiers
Modifiers should be processed as per the below order
➢ public,
➢ protected,
➢ private,
➢ abstract,
➢ static,

➢ final,
➢ transient,
➢ volatile,
➢ synchronized,
➢ native,
➢ strictfp
Avoid using Redundant Modifiers
7) Blocks
Any blocks created with the below considerations
• Avoid using nested Blocks

• Empty Blocks should not be imported
• left curly placement = nl
• Need braces
• Right curly placement = alone
8) Coding problems
Below should be taken care of while doing the java coding.
• Avoid inline conditionals

• Double check locking
• Empty statemant
• Equals and hashCode
• Hidden Field
• Illegal Instantion
• Inner argument
• Magic Number
• Missing switch default
• Redundant throws
• Simplify boolean Expression
• Simplify boolean return
• Parameter assignment
• String literal equals
• Multiple String Literals
9) Size violation
Size related configurations are to be followed as below.
• Design for extension. Disabled

• Final class
• Hide utility Class Constructor
• Interface is Type
• Visibility Modifier. Only static final members may be public
10) Duplicates

• Strict duplicate code. Disabled
11) Metrics
• Below metrics need to be configured.
• Boolean expression complexity. disabled
• Class Data Abstraction Coupling. disabled
• Class Fan Out Complexity. disabled
• Cyclomatic Complexity
• Non Commenting Source statements. disabled
• NPath complexity. Disabled
12) Miscellaneous
• Array type style = JavaStyle
• Descendent Token check. Disabled
• Final Parameters
• Generic Illegal Regexp. Lines cant end with a space = [^\s]\s+$
• Identation. disabled
• New line at end of file. disabled
• Required regular expression. disabled
• Todo comment
• Translation. Check consistency of keys in resource files.
• Trailing comment
• Uncommented main
• Upper Ell
4.4.5 API - Alias
Component Alias
AA.ActivityHook - Retail hook.arrangement.ActivityLifecycle
AA.CalculationHook -Retail hook.arrangement.Calculation
AA.RuleComparisonHook -Retail hook.arrangement.RuleComparison
EB.DataFormattingEngineHook -AF hook.system.DataFormattingEngine
EB.EnquiryHook -AF hook.system.Enquiry
EB.ServiceHook -AF hook.system.ServiceLifecycle
EB.TemplateHook-AF hook.system.RecordLifecycle
AC.AccountHook -BF hook.accounting.AccountingEntry
AC.ContractHook - BF hook.contract.StandingOrder
DE.DeliveryHook - BF hook.system.Delivery
FT.ContractHook - BF hook.contract.FundsTransfer
RC.ContractHook -BF hook.accounting.TransactionRecycler
ST.CalculationHook- BF hook.contract.Calculation
ST.EnquiryHook -BF hook.party.CustomerPosition

ST.StatementHook –BF hook.accounting.Statement

IA.AccountingHook –BF hook.accounting.InternationalAccountingStandards
IA.AccountingHook –BF hook.accounting.InternationalAccountingStandards
PP.PaymentLifecycleHook-Payments hook.payments.PaymentLifecycle
4.5 Secure coding Guidelines

Reference document about Secure coding
guidelines in Java is available under the below link.
https://temenosgroup.sharepoint.com/:w:/r/temenosteams/CSD/_layouts/15/Doc.aspx?source
doc=%7BA9FEAF37-58E9-4A0E-AB56-
3C3F9E4E528A%7D&file=Java%20Secure%20Coding%20Guidelines.docx&action=default&mobilere
direct=true
4.6 Packaging
• Source Jar Naming Convention:
<CSD or BRD/FSD Reference>_DevRef_Api.jar API

jar Example:
❖ CSD_TansactionLimit_Api.jar
<CSD or BRD/FSD Reference>_DevRef.jar

Template Jar Example:
❖ CSD_TansactionLimit.jar
• Packaging Procedure:
https://temenosgroup.sharepoint.com/:w:/r/temenosteams/CSD/_layouts/15/Doc.aspx?sourcedoc=%7B12DB0C3D-A505-
40CA-8FAB-B6B58730037C%7D&file=L3%20Java%20API-
%20Eclipse%20Configuration%20and%20Debug%20Procedures..doc&action=default&mobileredirect=true
5) JAVA PROGRAMMING:
5.1 Local Field values
Local reference – on core templates should be below 10. If there are more fields to be added proper explanation

has to be provided as to why additional fields have to be included.
Local variables should be under check and usage of Array has to be promoted.
5.1.1 Usage of Local Field Related API
I. getLocalRefField:
We can get the value for the respective local field from the particular application by using the method
getLocalRefField.
Eg:
By Creating an object for the CustomerRecord class with the help of new operator, we can get the value of the
Local field(L.CMNEMONIC.DEF) from the customer application using the method getLocalRefField
CustomerRecord – Application related Class
yCustRec – Object for the respective class
L.CMNEMONIC.DEF – Local Ref Field
Invoke the method getLocalRefField by passing the respective local field name
It has to be saved in the type of TField
II. getLocalRefGroups :
To fetch the value from multivalued local field we can use the method getLocalRefGroups, appropriate
value can be fetched by looping.
Highlighted packages need to be imported

Eg:
There is an multi value field exists in the AA.PRD.DES.TERM.AMOUNT, we can get the value of the local field by
using the method getLocalRefGroups
AaPrdDesTermAmountRecord – Class
termAmtRec – Object
CSD.BRD.APP.DET – Multi-value local ref field
Invoke the method getLocalRefGroups by passing the respective multivalued local field name
And it has to be saved in the type of LocalRefList
5.2 Usage of Control and Looping Statements:
5.2.1 If … else Statement

It's often desirable to execute a certain section of code based upon whether the specified condition
is true or false.
Syntax:
if (cond) {
-------- statement 1----------
} else {
-------- statement 2----------
Example:

5.2.2 For Loop

Case 1 :
If the number of iteration is fixed, it is recommended to use for loop.
Syntax:
for(init;cond;incr/decr)
Code to be executed
Init – Define the variable with Int type and condition to be initialized.
Cond – Defined the condition for the iteration
Incr/decr – Definition of Increment/Decrement operator
Example:
5.2.3 For Each Loop
It provides an alternative approach to traverse the array or collection in Java.
Syntax:
for(data_type variable : array | collection){

//body of for-each loop
Example:
CustomerClass – Class/Type
CustId – Variable
CustList – Collection Based Object
5.2.4 While Loop
If the number of iteration is not fixed, it is recommended to use while loop
Syntax:
while(condition){
//code to be executed
Example:
Looping will be executed as long as condition is getting satisfied

5.2.5 Do-while Loop
If the number of iteration is not fixed and we must have to execute the loop at least once, it is recommended to
use the do-while loop
Syntax:
do{
//code to be executed
}while(condition);
Example:
It will execute the loop at least once irrespective of the condition specified in the while.
5.2.6 Switch Case

Switch statement tests the equality of a variable against multiple values.
Syntax:
switch(expression){
case value1:
//code to be executed;
break; //optional
case value2:
//code to be executed;
break; //optional
......
default:

code to be executed if all cases are not matched;
Example:
We can check the multiple cases in the switch statement with equality.
Break statement is optional.
If at all, none of the cases is getting satisfied then default case will be executed.
5.3 File Handling
File handling defines the way to handle files and make call to files using F.READ, F.WRITE and other available
commands which are defined in the core API.
In java, we have DataAccess Class. In which we can read, select and access data.

• yDataAccessRec.getRecord(tableName, recordId)
It returns record from live table of the user is logged in company.
tableName – name of the file to be read (like-CUSTOMER,ACCOUNT)
recordId -- ID of the required record to be fetched.
DataAccess yDataAccessRec= new DataAccess(this);
• yDataAccessRec.getRecord(companyMnemonic, tableName, fileSuffix, recordId)
It returns the record from the given table, allowing access to any record in the database.
companyMnemonic- The MNEMONIC of the COMPANY record( 'BNK',’GBP’)
tableName- name of the file to be read (CUSTOMER,ACCOUNT)
fileSuffix- The file suffix. Use empty string for the live table, otherwise use '$NAU', '$HIS', '$SIM', '$DEL' for
respective table.
recordId- ID of the required record to be fetched
Here we are giving company mnemonic, File name, file suffix is left blank- so record from live table will be fetched
and followed by ID in fourth parameter.
• yDataAccessRec.getHistoryRecord(tableName, recordId)
It returns the most recent record from the history table of the company the user is currently logged in.

• yDataAccessRec.getRequestResponse(requestDetailId, exists)
To get response details from OFS.REQUEST.DETAILS table.
requestDetailId --The id of the OFS.REQUEST.DETAIL record.
exists -- boolean value indicating whether the record exists or not.
Below is the sample code.
We are passing ORD id. ORD record will be fetched if ID is available. We can get table details from ORD record
variable.
• delete and write function in java.
In delete (recordId)—We have to pass record ID of the table to be deleted.
In write (RecordId, record data)—We need to pass record id. And in record data we need to pass data of the record
which need to be written,
Release of Lock on Data file should be done using release function in java. pain12ResTabRes.release
(ynewPain12Id); --- we need to pass the id which need to be released.
To Cycle the dates we can use addFrequency function just like CFQ in JBC.

• date.getDayType(dateVal) – This function returns if it is ‘HOLIDAY’ or ‘WORKING.DAY ‘ for the given date. It calls
core routine AWD.
• We can format the date to different format as needed in java.
We can also use SimpleDateFormat, define the pattern to be displayed as required
ccy.getRoundAmount(reqAmtDoub, "")
Returns the Currency's formatted amount based on the given roundingRuleId.
If the roundingRuleId is not provided then the amount will be formatted according to the currencyId member
variable.
For getting interest rate for BASIC.INTEREST rate setup, getBasicRate API can be used.
interest.getBasicRate(currencyId, interestDate)
currencyId--- The Currency to get the rate for.
interestDate--- Date on which the rate is queried

interest.calculateAccrualDays(startDate,endDate,interestDayBasisId)
Calculates the number of interest accrual days between two given dates using the interest day basis. This invokes
the T24 routine BD.CALC.DAYS
startDate--Start date of the interest accrual period. The start date is always included in the calculation.
endDate --End date of the interest accrual period. The endDate is always excluded from the calculation.
interestDayBasisId--Type of interest calculation(A1, A4, H,)
5.4 Exception Handling
Exception handling is a programming language construct or computer hardware mechanism designed to handle
the occurrence of exceptions, special conditions that change the normal flow of program or subroutine execution.
1) Throwing Error message is one method of Exception Handling. Below is sample snippet how error can be raised
in Java.
We must create record in EB.ERROR. Pass EB.ERROR id as argument and raise error. It is not advisable to hardcode
error message.

2) We can raise Override Messages.
We must create record in OVERRIDE. OVERRIDE id must be passed as argument. It is not advisable to hardcode
message.
3) The other way of handling exception is through try & Catch
The try statement allows we to define a block of code to be tested.
The catch statement allows we to define a block of code to be executed, if an error occurs in the try block.
In below code, if condition fails in try block, then code in Catch block will be executed.
We can also throw just exception message in catch block.

We can use try and catch block inside catch block.
Below is sample snippet
Here we are reading record from FUNDS.TRANSAFER application.
If record is null then catch statement will be executed.
In Catch Block we are trying to read record from FT history table.
If condition fails we are logging the events in log file.
5.5 COB & Multithread Routines
Multithreading in T24 is sharing the load or in other words sharing the task to be executed. One process at system
operating level processing at list of id’s will be slower than multiple copies of same process processing on
the list of id’s.
In java, for COB and Multithread routines we need to extend ServiceLifecycle.
• Initialize method in ServiceLifecycle act as .LOAD.
We can initialise member variables. It is optional and it will not be invoked if not specified.
This interface is invoked before invoking the getTableName/getIds (SELECT) and process/inputRecord (RECORD)
methods.

serviceData – From serviceData (jobName, companyId, processId, sessionId and jobData) can be fetched.
• getIds -- This interface is invoked from BATCH.JOB.CONTROL in place of the SELECT routine. This invoker returns list
of id’s to be processed in job routine.
public List<String> getIds(ServiceData serviceData, List<String> controlList)
ServiceData—service like jobName, companyId, processId, sessionId and jobData can be obtained in serviceData
argument.
controlList-- The control list to be set.
1) CONTROL.LIST common variable can be used to perform different operations in sequence with the ability
to run the job in parallel. It invokes the select routine for n number of times thus sequencing the different
jobs within which every job can have parallel processing.
2) The getIds contain only the CONTROL.LIST common variable and the SELECT statement to be executed.
We cannot define the process of the routine. This is because getIds executed only with one agent and
hence defining the entire process of the routine may cause performance issue.
• updateRecord-- This interface is invoked from BATCH.JOB.CONTROL in place of the RECORD/JOB routine.

public void updateRecord(String id, ServiceData serviceData, String controlItem,
TransactionControl transactionControl, List<SynchronousTransactionData> transactionData,
List<TStructure> records)
id—List of id’s that is passed from getId’s invoker.
serviceData -- Details about this service such as jobName, companyId, processId, sessionId, jobData and
batchStartDate can be obtained.
controlItem -- The item of the control list being processed for multi stage jobs.
transactionControl -- Items that control how the request is processed such as how to group transactions and handle
errors.
transactionData -- List of transaction data each for a single update request including function, transactionId and
versionId.
records List : List of records for the corresponding request index in transactionData.
Sample Snippet of updateRecord invoker.
OFS can be posted in updateRecord by using List<SynchronousTransactionData>.

We can set Version, function, ofs source and add it to a record variable as shown in the sample code.
5.6 AA Batch Processing
There is a single major difference between AA batch execution and other T24 batch processing. Even whilst
executing the scheduled activity, system would always pass through normal Template route i.e. process activities
via AA.ARRANGEMENT.ACTIVITY. All activities performed either - online or COB - share the same code since they
are all executed through templates. So the way a scheduled Rate change is executed in COB would be no different
from a rate change triggered by the user online. In COB, the AA.ARRANGEMENT.ACTIVITY would be triggered
through an OFS message (since that is the standard T24 methodology by which a template is accessed if it is not
user initiated).
Please be noted that currently ALL AA COB jobs are .NTX which means they do not use the Transaction management
initiated by BATCH.JOB.CONTROL. Since AA uses the new Transaction boundary and there is no difference between
Online and COB transactions, it deviates from the BJC‟s transaction management.
Users performing local development should keep this in mind. So, if there is a local API which gets triggered during
–say rate change- the same would be triggered during COB process as well. If an update is not supposed to happen
during COB process, then it is the developer’s responsibility to add isService() (Returns the current value of the
RUNNING.UNDER.BATCH common variable. This is set to true if the current process is a SERVICE -TSA.SERVICE
application) condition and stop the execution.
5.7 ActivityLifecycle Routines
To implement any AA APIs, we need to import ActivityLifecycle class.
The ActivityLifecycle class allows an implementer to attach behavior to the events in the Contract's activity lifecycle.

The Contract class allows access to balance movements, payments, property conditions, payment schedules and
all information related to Contract details record. Contract class supports several methods.
setContractId(String value) : This method is used to set the Arrangement Contract ID,
Eg 'AA16082SXNN3'. Only once the arrangement Id is set, this object can be used to get other Arrangement
Conditions.
5.7.1 Local Commons in AA:

In JAVA I_AA.LOCAL.COMMON variables will be fetched and passed to the arguments exposed in each method.
AA.COMMON.CONTEXT.VALUE: This subroutine will fetch values from I_AA.LOCAL.COMMON insert file and
passed as parameter to L3 interface. It is called by the Invokers mentioned below to initialize the common variables.
METHODS implemented by ActivityLifecycle class (APIs exposed):
I. defaultFieldValues
This interface is invoked when implementer want to change value of core fields before the application page loads.
In T24, this is the interface method for RECORD.ROUTINE , PRE.VALIDATION.RTN in the AA.PRD.DES.ACTIVITY.API
table. If an exception is thrown, error is raised and transaction will not be commited.
Invoker for this methods is: AA.DEFAULT.FIELD.VALUES.INVOKER
Local/Core field values can be updated in this method.
To whichever PropertyClass the API is attached, record parameter is assigned to that Property class record, eg:

Here, using termRec we can access all the fields of TERM.AMOUNT property class and set the value back to any
field.
II. validateRecord
This interface enables the implementer to validate the application. This interface is invoked post execution of
action routine and used to validate the application by raise errors and overrides.
In T24, this is the interface method for POST.ROUTINE and VALIDATE.RTN in the AA.PRD.DES.ACTIVITY.API table.
Invoker for this method is : AA.VALIDATE.RECORD.INVOKER
Returns back the validation response:
This method cannot be used to update core field values. But can be used to update local field values at
VALIDATION.RTN stage.
This is also used to set Overrides using method:

III. updateLookupTable
This interface enables the implementer to return true if there are any updates required for concat files. This
interface is invoked post execution of action routine
In T24, this is Interface method for the POST.ROUTINE field in the AA.PRD.DES.ACTIVITY.API table.
Invoker for this method is : AA.UPDATE.LOOKUP.TABLE.INVOKER
Returns a Boolean flag which indicates whether update is required or not. If flag and lookupDataList is present,
then concat table is updated. LookupDataList contains index and element list where the table name, key , sorting
order, entry to add/delete is specified.
lookupDataList.set(0, element);
Here element is of type LookupData : Represents the objects required to update the concat file
IV. postCoreTableUpdate
This interface enables the implementer to update core system tables. This interface is invoked post execution of
action routine and core applications is updated through OFS post message.
Invoker for this method is: AA.POST.CORE.TABLE.UPDATE.INVOKER

OFS request data:
transactionData : List of the transaction data to post the request
transactionRecord : A list of records for the data at the corresponding index in transactionData.
Eg with code snippet:
V. generateSecondaryActivity
This interface enables the implementer to generate secondary activity.
Invoker for this method is: AA.GENERATE.SECONDARY.ACTIVITY.INVOKER
Properties are separated by VM marker
Property and Field Name are separated by SM marker
FieldName and FieldValues are separated by markers lower than SM

Only if all values are set in java, secondary activity will be generated .
Calls the core AA API to generate secondary activity.
secondaryActivity : used to set all the values to generate secondary activity.
Eg with code snippet:
6) CORE API’S
Core routines are the routines that are developed inside T24 which cannot be modified but can be used in the in
the program by calling the routine.
Core routine reduces redundant set of statements called repeatedly and reduces the complexity of the routine.
Hence, there is no need to code the statements instead simply make a call to the routine and pass the arguments.

For example, we have api that returns available balance when the currency id is passed as argument.
6.1 Amount API
6.1.1 getAvailableAmount
This API returns available balance in account considering locked events and available limit in account.
API:
• getAvailableAmount (currency)
Currency—We can pass the Currency ID.
6.1.2 getBalance
• getBalance(balanceType, balanceDate)
This API returns Opening balance of account on given date.
balanceType—can be BOOKING/VALUE/TRADE
balanceDate—Pass the date value on which balance is required.
6.1.3 getTurnoverCredit
• getTurnoverCredit(balanceType, balanceDate)
This API gives net amount of credit movement for account on given date.
6.1.4 getTurnoverCredit
• getTurnoverDebit(balanceType, balanceDate)
This API gives net amount of debit movement for account on given date.

6.2 Date Manipulation
6.2.1 addWorkingDays
This API is similar to CDT in JBC. This API returns date after adding the offset in working days.
date.addWorkingDays(inDate, inOffsetDays)
inDate—Pass the date value from which we need to find the difference
inOffsetDays-No of working days offset. It can be positive or negative.
6.2.2 getWorkingDayDifference
This API is similar to CDD in JBC. This API returns calculated number of working days between given two dates.
getWorkingDayDifference(yStartDate, yEndDate);
6.2.3 getMonthDifference
• date.getMonthDifference(startDate, endDate)
This API returns calculated number of completed months between given start date and end date.
6.2.4 getgregorianToJulian
• date.gregorianToJulian(gregorianDate)
This API converts a date from Gregorian format (YYYYMMDD) into Julian format (YYYYDDD, where DDD is the
number of days since the beginning of the year).

6.2.5 getgregorianToJulian
• date.julianToGregorian(julianDate)
This API Converts a date from Julian format (YYYYDDD, where DDD is the number of days since the beginning of
the year) into Gregorian format (YYYYMMDD).
6.2.6 plusDays
This method adds number of days to be incremented.
Similarly, we have few more API like,
localDate.plusMonths(monthsToAdd)
localDate.plusYears(yearsToAdd)
6.3 Exchange Rate
This section explains the available core routines that can be used for calculating the exchange rates
6.3.1 calculateRate
This API calculates exchange rates between two currencies. This internally calls EXCHRATE routine.
ccyRec.calculateRate(buyCurrency, sellCurrency, currencyMarket, outputCurrency, historyDate)

6.3.2 calculateBuyExchangeRateAmount
This API calculates the buy ExchangeRateAmount for the given currencyMarkets, currency pair, and sellAmount.
This internally calls CUSTRATE routine.
ccyRec.calculateBuyExchangeRateAmount(buyCurrencyMarket, sellCurrencyMarket, buyCurrency, sellCurrency,

sellAmount, spreadPercentage)
6.3.3 calculateExchangeRate
This API calculates the exchange rate from local currency to deal currency. This internally calls CALC.ERATE.LOCAL
routine.
ccyRec.calculateExchangeRate(localAmount, dealCurrency, dealAmount)
6.3.4 calculateBuyAmount
This API calculates the buy amount for a currency pair, sellAmount, exchangeRate, historyDate and
currencyMarket. This internally calls EXCHRATE routine.
ccyRec.calculateBuyAmount(buyCurrency, sellCurrency, sellAmount, currencyMarket, exchangeRate, historyDate)
6.4 ST.Customer Api

• customerExists(): Checks whether Customer exists (returns true/false).
• getAccountNumber(): Returns the list of the Customer's account IDs.
• getAgency(): Returns the Customer's Agency including company and clearing codes, swift address, national and
universal ids and ABA number.
• getContractInfo() : Returns the Customer's contact information including name, phone number, sms number, fax
number and email address.
• getDeliverySecureMessageAddress(companyCode, sequenceNo, preferredLanguage) : Returns the

Customer's secure message address for the given company code, sequence number and preferred language.
If the customerId member variable is not set then the current companies generic secure message address will be
returned.
• getEmailAddress(companyCode, sequenceNo, preferredLanguage): Returns the Customer's email address

for the given company code, sequence number and preferred language.
If the customerId member variable is not set then the current companies generic email address will be returned.
• getIdForMnemonic(customerMnemonic) :Returns the customer Id given the customer Mnemonic. The ID is

obtained from the CUSTOMER field in MNEMONIC.CUSTOMER.
• getLiableLimit(limitReferenceId, currencyId, isUnavailableLimit, isOverUtilisedAmount) : Returns the

liable Customer's allocated and available limit amounts for the given limit reference and currency.
The caller has the option of activating the available marker and disabling the overutilised amount for the limit.
• getLimit(limitReferenceId, currencyId, isUnavailableLimit, isOverUtilisedAmount): Returns the Customer's

allocated and available limit amounts for the given limit reference and currency.
The caller has the option of activating the available marker and disabling the overutilised amount for the limit.
If no limit is available for the customer, it will check for the liability limit (parent customer's limit).
• getMandateItems() : Returns the Customer's list of application names for which mandates need to be checked.
• getParentId(): Returns the customer id of the Customer's parent or Group Head.

The parent is the customer that has liablilty for this Customer. The ID is obtained from the CUSTOMER.LIABILITY field
in CUSTOMER.
• getPostingRestrictions(): Returns the Customer's restriction for posting entries and indicates whether it is subject
to Dispo processing.

• getSwiftAddress(companyCode, sequenceNo, preferredLanguage): Returns the Customer's SWIFT

communication address for the given company code, sequence number and preferred language.
The data is obtained from DE.ADDRESS and the critera are applied progressively to obtain the most appropriate
match.
An exception is raised if no matching address can be found.
• getSettlementAccountId(currencyId, currencyMarket, table, portfolioNo, accountType): Returns the

Customer's settlement account including account type and id.
This is based on the defaulting mechanism Customer Standard Settlement Instruction, Portfolio, Vostro, Nostro, First
current account of customer. This invokes the T24 routine GET.SETTLEMENT.DEFAULTS.
• getProfile(): Returns the Customer's high level Profile including their asset class, rating, industry and sector.
6.5 LI.Limit Api
• getCurrencyAmount(TBoolean checkValueDate, TDate transactionDate): Returns a list of amounts

calculated for the accounts from the LIMIT table for the given limitId, and also calculates a consolidated LimitAmount
in the LIMIT.CURRENCY of the given limit. This invokes the T24 routine LIMIT.GET.ACC.BALS.
6.6 EB.Session Api
• deleteCurrentVariable(name) : Deletes the given current variable and it's value. Returns true if successful,
otherwise false. Note that EXT and INT.SMS variables cannot be deleted with this method. Uses the
System.setVariable routine in T24 to delete the given CURRENT variable name when the variable value is null.
• getCompanyId(): Returns the ID of the COMPANY the user is currently logged in to. Returns the ID.COMPANY
common variable.
• getCompanyRecord() : Returns the complete record for the COMPANY the user is currently logged in to.
Returns the R.COMPANY common variable.
• getCurrentVariable() : Returns the complete record for the COMPANY the user is currently logged in to.
Returns the R.COMPANY common variable.
• getLocalCurrency() : Returns the currency of the company the user is currently logged in to.
Returns the LCCY common variable.
• getMainMenu() : Returns the id of the users main menu - the menu that gets loaded by default when they log in.
This is defined in the USER application in field INIT.APPLICATION and is a key to HELPTEXT.MAINMENU or
HELPTEXT.MENU.

• getOnlineStatus() : Returns a value indicating whether the system is running end of day processing.
This returns a value based on the OP.MODE field in SPF. The possible values are
'ONLINE' - normal operation, users may INPUT transactions.
'BATCH' - end of day processing. Most applications will not allow input during the close of business processing, but
a few (eg FUNDS.TRANSFER) can.
'RECOVERY' - database restoration.
• getUserDispoOfficer() : The value returned is a key to the DISPO.OFFICER table in T24.
• getUserId() : Returns the OPERATOR common variable. Note this is the ID to the F.USER table, not the
SIGN.ON.NAME.
• getUserLanguage() : Returns the LNGG common variable. This is an integer representing the ID from the
LANGUAGE table in T24.
• getUserRecord() : Returns the R.USER common variable.
• getUserOverrideClass(): Returns the list of override classes defined for the current user, or an empty list if no
override class is defined. This list specifies which override classes the user is allowed to approve.
• getUserRoles() : The values from ROLE.COMPANY.RESTR and USER.ROLES fields for the USER table.
• isProductInstalled(productID): Returns true if the given product code is installed in the company the user is
currently logged in to, false otherwise.
• publishMessage(interfaceId, record, response): Uses DFE.ONLINE.TRANSACTION to transform the record into

expected format.
6.7 AA Api
6.7.1 AA.Contract Api

• buildPaymentSchedule: public List buildPaymentSchedule (TDate startDate, TDate endDate, TNumber
noOfCycles, List paymentType)
Used build the payment schedule for the given details. Arrangement is mandatory input. @return
Contract:PaymentSchedule
• buildPaymentSchedule ForProperty: public List buildPaymentSchedule ForProperty(TDate startDate, TDate

endDate, TNumber noOfCycles, List paymentType, CharSequence propertyId)

• getAccountCondition:
public com.temenos.t24.api.records.aaarraccount.AaArrAccountRecord getAccountCondition(CharSequence
propertyId)
Returns the current account condition record of the arrangement. @return Account Condition Record @throws
T24CoreException if contractId is invalid
• getAccountConditionForEffectiveDate:
public com.temenos.t24.api.records.aaarraccount.AaArrAccountRecord getAccountConditionForEffectiveDate(Ch
arSequence propertyId, TDate effectiveDate)
Returns the account condition record of the arrangement matching the date. @return Account Condition Record
@throws T24CoreException if contractId is invalid, or if the effective date is less than the arrangement start date
• getAccountDetails:
public com.temenos.t24.api.records.aaaccountdetails.AaAccountDetailsRecord getAccountDetails()
Returns the account details record for the given contractId. @returns account details record for the given contract.
@throws an exception on NULL or invalid contractId.
• getArrangementBenficialOwner: public String getArrangementBenficialOwner()
Used to fetch the benificial customer(Owner) for the given arrangement. @return Contract:customer ID
• getBalanceMovements: public List getBalanceMovements(CharSequence balanceType, CharSequence

requestType)
Returns the balance and authorised balance movements of the arrangement. @returns the BalanceMovement
@throws T24CoreException if contractId is invalid
• getBillIds: public List getBillIds(TDate billDate, TDate paymentDate, CharSequence billType, CharSequence
paymentMethod, CharSequence billStatus, CharSequence settlementStatus, CharSequence agingStatus, TDate
nextAgeDate, CharSequence repaymentReference)
Returns the list of billIds (references) matching the inputs of an arrangement @return list List of matching billIds

• getBillIdsForAgingStatus: public List getBillIdsForAgingStatus(CharSequence agingStatus)
Returns the list of billIds (references) matching the Aging Status of Bill of an arrangement @return list List of
matching billIds @throws T24CoreException if contractId is invalid
• getBillIdsForDate: public List getBillIdsForDate(TDate billDate)
Returns the list of billIds (references) matching the bill dates of an arrangement @return list List of matching billIds
• getBillIdsForNextAgeDate: public List getBillIdsForNextAgeDate(TDate nextAgeDate)
Returns the list of billIds (references) matching the Next Age Date for bill of an arrangement @return list List of
• getBillIdsForPayMethod: public List getBillIdsForPayMethod(CharSequence paymentMethod)
Returns the list of billIds (references) matching the Payment method of an arrangement @return list List of
• getBillIdsForPaymentDate: public List getBillIdsForPaymentDate(TDate paymentDate, CharSequence

selectionIndicator)
Returns the list of billIds (references) matching the payment dates of an arrangement Selection indicator can be
set to "FROM" or "TO". If set to FROM, then Bills from the passed date will be selected and not beyond. If set to
TO, then Bills up to and including the passed date will be selected. @return list List of matching billIds @throws
• getBillIdsForRepaymentReference: public List getBillIdsForRepaymentReference(CharSequence

repaymentReference)
Returns the list of billIds (references) matching the RepaymentReference of an arrangement @return list. List of

• getBillIdsForSettlementStatus: public List getBillIdsForSettlementStatus(CharSequence settlementStatus)
Returns the list of billIds (references) matching the Settlement Status of an arrangement @return list List of
• getBillIdsForStatus: public List getBillIdsForStatus(CharSequence billStatus)
Returns the list of billIds (references) matching the Bill Status of an arrangement @return list List of matching billIds
• getBillIdsForType: public List getBillIdsForType(CharSequence billType)
Returns the list of billIds (references) matching the bill type of an arrangement @return list List of matching billIds
• getChargeCondition: public List getChargeCondition(CharSequence propertyId)
Returns the charge condition record for the given contractId. @returns charge record for the given contract.
@throws an exception on NULL or invalid contractId.
• getChargeConditionForEffectiveDate: public List getChargeConditionForEffectiveDate(CharSequence

propertyId, TDate effectiveDate)
Returns the charge condition record for the given contractId. @returns charge record for the given contract.
@throws an exception on NULL or invalid contractId or invalid effective date.
• getCommitmentCondition:
public com.temenos.t24.api.records.aaarrtermamount.AaArrTermAmountRecord getCommitmentCondition(Char
Sequence propertyId)
Returns the term amount condition record for the given contractId. @returns term amount record for the given
contract. @throws an exception on NULL or invalid contractId or effective date.
• getCommitmentConditionForEffectiveDate:
public com.temenos.t24.api.records.aaarrtermamount.AaArrTermAmountRecord getCommitmentConditionForEf

fectiveDate(CharSequence propertyId, TDate effectiveDate)
Returns the term amount condition record for the given contractId. @returns term amount record for the given
contract. @throws an exception on NULL or invalid contractId or effective date.
• getConditionForProperty: public TStructure getConditionForProperty(CharSequence propertyId)
Returns the condition record for given property. @returns property record for the given contract. @throws an
exception on NULL or invalid contractId and property.
• getContract: public com.temenos.t24.api.records.aaarrangement.AaArrangementRecord getContract()
Returns the arrangement record of the arrangementId. @return Arrangement Record for the arrangementId
• getContractAgeStatus: public String getContractAgeStatus()
Returns the current aging status of the arrangement @return string aging status of the arrangement @throws
• getContractId: public String getContractId()
Getter. contractId member eg 'AA16082SXNN3'. Must begin with 'AA'.
• getCustomerCondition:
public com.temenos.t24.api.records.aaarrcustomer.AaArrCustomerRecord getCustomerCondition(CharSequence
propertyId)
Returns the current customer condition record of the arrangement. @return Customer Condition Record @throws
• getCustomerConditionForEffectiveDate:
public com.temenos.t24.api.records.aaarrcustomer.AaArrCustomerRecord getCustomerConditionForEffectiveDat
e(CharSequence propertyId, TDate effectiveDate)
Returns the customer condition record of the arrangement matching the date. @return Customer Condition
Record @throws T24CoreException if contractId is invalid, or if the effective date is less than the arrangement start

date
• getCustomerRole: public com.temenos.t24.api.complex.aa.contractapi.CustomerRole getCustomerRole()
Returns the CustomerId and Customer Role for an arrangement. @return CustomerRole @throws
• getFirstOverDueDate: public TDate getFirstOverDueDate()
Returns the First Overdue date for AA Loan contracts. @return First Date Over Due Date for an arrangement
• getFirstVersionOfProperty: public TStructure getFirstVersionOfProperty(CharSequence propertyId, TDate

effectiveDate)
Returns the first version condition record for given property for the given date. @returns property condition record
for the given contract. @throws an exception on NULL or invalid contractId and property.
• getForwardCreditBalanceMovements: public List getForwardCreditBalanceMovements(CharSequence

balanceType, CharSequence requestType, TDate startDate, TDate endDate)
Returns the forward dated balance movements between two dates. @return BalanceMovement @throws
T24CoreException if contractId or if request type is invalid
• getForwardDebitBalanceMovements: public List getForwardDebitBalanceMovements(CharSequence

balanceType, CharSequence requestType, TDate startDate, TDate endDate)
Returns the forward dated debit balance movements between two dates. @return BalanceMovement @throws
• getInterestAccrualsRecord:
public com.temenos.t24.api.records.aainterestaccruals.AaInterestAccrualsRecord getInterestAccrualsRecord(Cha
rSequence property, TDate startDate)
Returns the interest accrual record for the given contractId and property from given startDate. @returns interest
accrual record for the given contract. @throws an exception on NULL or invalid inputs.

• getInterestAmounts:
public com.temenos.t24.api.complex.aa.contractapi.InterestAmount getInterestAmounts(CharSequence
propertyId, TDate startDate, TDate endDate)
Returns the interest accrual amount of an arrangement for a period for given interest property. @ return
InterestAmount of the arrangement @throws T24CoreException if contractId is invalid
• getInterestCondition: public List getInterestCondition(CharSequence propertyId)
Returns the current interest condition record of the arrangement. @return Interest Condition Record @throws
• getInterestConditionForEffectiveDate: public List getInterestConditionForEffectiveDate(CharSequence

propertyId, TDate effectiveDate)
Returns the interest condition record of the arrangement matching the date. @return Interest Condition Record
• getLastOverDueDate: public TDate getLastOverDueDate()
Returns the Last Overdue date for AA Loan contracts. @return Date Last Over Due Date for an arrangement
• getLastRepayment:
public com.temenos.t24.api.complex.aa.contractapi.Payment getLastRepayment(CharSequence propertyId)
Returns the last repayment amount and last repayment date for a given arrangement. @return Payment last
Repayment of the arrangement @throws T24CoreException if contractId is invalid
• getLimitCondition:
public com.temenos.t24.api.records.aaarrlimit.AaArrLimitRecord getLimitCondition(CharSequence propertyId)
Returns the current limit condition record of the arrangement. @return Limit Condition Record @throws

• getLimitConditionForEffectiveDate:
public com.temenos.t24.api.records.aaarrlimit.AaArrLimitRecord getLimitConditionForEffectiveDate(CharSequen
ce propertyId, TDate effectiveDate)
Returns the limit condition record of the arrangement matching the date. @return Limit Condition Record @throws
T24CoreException if contractId is invalid, or if the effective date is less than the arrangement start date
• getMaturityDate: public TDate getMaturityDate()
Returns the maturity date of given arrangement. @return Date Maturity Date for an arrangement @throws
T24CoreException if contractId is invalid or if the product line of the arrangement is not 'DEPOSITS' or 'LENDING'
• getNextDueDate: public TDate getNextDueDate()
Returns the next due date for the given arrangement. If the arrangement is in aging state, payment date of the
oldest aged bill would be the next due date. If the advance payment has been made towards the arrangement,
next due date would be the payment date where advance payment becomes zero.
If there is an advance payment, the next due date would be the payment date of the bill issued @return Date Next
Due Date for an arrangement @throws T24CoreException if contractId is invalid
• getNextPayment:
public com.temenos.t24.api.complex.aa.contractapi.Payment getNextPayment(CharSequence propertyId)
Returns the Next repayment amount and next repayment date of an arrangement. @return Payment next
• getNumberOfOverDueBills: public TNumber getNumberOfOverDueBills()
Returns the Number Of Over Due Bills for AA Loan contracts. @return number Number Of Over Due Bills for an
arrangement @throws T24CoreException if contractId is invalid
• getOfficersCondition:
public com.temenos.t24.api.records.aaarrofficers.AaArrOfficersRecord getOfficersCondition(CharSequence
propertyId)
Returns the current officers condition record of the arrangement. @return Officers Condition Record @throws

• getOfficersConditionForEffectiveDate:
public com.temenos.t24.api.records.aaarrofficers.AaArrOfficersRecord getOfficersConditionForEffectiveDate(Cha
rSequence propertyId, TDate effectiveDate)
Returns the officers condition record of the arrangement matching the date. @return Officers Condition Record
• getPreviousDatedProperty: public TStructure getPreviousDatedProperty(CharSequence propertyId)
Returns the previous dated condition record for given property for the given date. @returns previous dated
property condition record for the given contract. @throws an exception on NULL or invalid contractId and property.
• getPreviousProperty: public TStructure getPreviousProperty(CharSequence propertyId)
Returns the previous property record for given property for the given date. @returns previous property condition
record for the given contract. @throws an exception on NULL or invalid contractId and property.
• getProductId: public String getProductId()
Returns the current ProductId for a given arrangement. @return String ProductId of the arrangement @throws
• getProductIdForEffectiveDate: public String getProductIdForEffectiveDate(TDate effectiveDate)
Returns the ProductId of the arrangement active at the given date. @return String ProductId of the arrangement
• getPropertyIds: public List getPropertyIds()
Returns the PropertyIds of the arrangement. @return list PropertyIds of the arrangement @throws
• getPropertyIdsForPropertyClass: public List getPropertyIdsForPropertyClass(CharSequence propertyClassId)

Returns the PropertyIds for a property class of the arrangement. @return list PropertyIds of the arrangement
• getRepaymentCondition: public List getRepaymentCondition(CharSequence propertyId)
Returns the repayment rule condition record for the given contractId. @returns repayment rule record for the
given contract. @throws an exception on NULL or invalid contractId.
• getRepaymentConditionForEffectiveDate:
public List getRepaymentConditionForEffectiveDate(CharSequence propertyId, TDate effectiveDate)
Returns the repayment rule condition record for the given contractId. @returns repayment rule record for the
given contract. @throws an exception on NULL or invalid contractId and invalid effective date.
• getRepaymentSchedule: public List getRepaymentSchedule (TDate fromDate, TDate toDate)
• getSimulationId: public String getSimulationId()
Returns the ProductId of the simulated arrangement. @return String ProductId of the simulated arrangement.
• getTerm: public String getTerm()
Returns the Term of an arrangement @return string Term of an arrangement @throws T24CoreException if
contractId is invalid
• getTermAmount: public TNumber getTermAmount()
Returns the Term Amount of an arrangement @return number Term Amount of an arrangement @throws
• getTotalReceivedRepayment: public TNumber getTotalReceivedRepayment()
Returns the total repayment of an arrangement received to date. @return number Total Received Repayment of
the arrangement @throws T24CoreException if contractId is invalid
• getTotalReceivedRepaymentForProperty:
public TNumber getTotalReceivedRepaymentForProperty(CharSequence property)
Returns the total repayment of an given property received to date. @return number Total Received Repayment of
the arrangement @throws T24CoreException if contractId is invalid

• getTotalRepaymentBetweenDates:
public TNumber getTotalRepaymentBetweenDates(TDate startDate, TDate endDate)
Returns the total received repayment amount of an arrangement for period . @return number Total Received
• getTotalRepaymentForMonth: public TNumber getTotalRepaymentForMonth()
Returns the total Received Repayment of an arrangement for the current month . @return number Total Received
• getUnauthorisedBalanceMovements:
public List getUnauthorisedBalanceMovements(CharSequence balanceType, CharSequence requestType, TDate

startDate, TDate endDate)
Returns the period balance between two dates and required authorised and unauthorised balance movement.
@return BalanceMovement @throws T24CoreException if contractId is invalid or if the entryType is invalid
• getsimulationconditionForProperty: public TStructure getsimulationconditionForProperty(CharSequence

propertyId)
Returns the simulation condition record for given property. @returns property record for the given contract.
@throws an exception on NULL or invalid contractId and property.
6.7.2 AA.PRODUCT Api

• getProduct: public com.temenos.t24.api.records.aaproductcatalog.AaProductCatalogRecord getProduct()
Returns the Published Product Record for the productId @ return Product Catalog Record
• getProductId: public String getProductId()
Getter. productId member eg 'MORTGAGE'.
6.7.3 AA.PROPERTY Api

• getPropertiesForProduct: public TStructure getPropertiesForProduct(CharSequence productId, CharSequence
stage, CharSequence currency, TDate startDate, TDate effectiveDate)
Returns the property records corresponding to product from any stage. @return structure PropertyRecord
• getPropertyClassId: public String getPropertyClassId()
Returns the Property Class for a PropertyId. @return String PropertyClassId

• getPropertyId: public String getPropertyId()
Getter. propertyId member eg 'DEPSOITINT'
6.7.4 AA.PROPERTY.CLASS.API
• getPropertyClassId: public String getPropertyClassId()
Getter. propertyClassId member, eg 'INTEREST'
• getPropertyIdsForProduct: public List getPropertyIdsForProduct(AaProductCatalogRecord productRecord)
Returns the list of Property Ids for Property class of the product. Product record is one of the input. System will
fetch Property ids from product record having key as Property class. @ return list List of Property Ids. @throws
T24CoreException if propertyClassId is invalid.
7) Other Important points to be noted:
7.1 Logging/Debugging
Logger functionality in java is used to detect the potential code breaks and helps in debugging. Example:
7.2 Mathematical Calculation
Always use BigDecimal for monetary calculations and don’t use double or float. Because double/float doesn’t
handle the decimal part well.
7.3 OCRT using Sonarcube
Follow the document for code review process:
https://temenosgroup.sharepoint.com/:w:/r/temenosteams/CSD/_layouts/15/Doc.aspx?sourcedoc=%7B8B045
019-4210-466D-B4CE-B9C715D03493%7D&file=sonarqube.docx&action=default&mobileredirect=true

7.4 Tackle Quality Issues
Technical Monitor : Can be found in TAFJEE.
• Enable TAFJ Session monitor and Technical Monitor to see any errors are reported over there while doing
the testing
TAFJ Session Monitor :
• Run the bat file under TAFJ > TAFJSessionMonitor after changing the port no. in SessionMonitor.properties
• Loggin : http://localhost:<portno>/SessionMonitor
Here, corresponding to current transaction and user, logs can be found and analyzed.
• Enable the TAFJ logs and T24 logs and check it thoroughly once to understand if anything reported as fizzy
before we promote the development to code review.
7.5 Navigating and Generating Javadocs
Execute the below BuildJavaDocFromSource script inorder to generate Javadoc for hook and api according to
module wise.
BuildJavaDocFromSource.ps1
Right click the same -> Select Run with PowerShell
In the PowerShell, Enter the T24libs path

Enter the output path where we need to generate the docs

Kindly ignore if any errors or warnings are raising.
Check the Javadoc path.
If we cannot able to run the script, Make sure that below settings has defined or not.
Open Setting app

Check the below mentioned option is enabled.

Once the above configurations are done, javadocs will be created in the given output path.
Javadocs can be navigated from index as below

We can further navigate through each class of particular module. Charge belongs to account module.
Corresponding methods will be explained in detail as given below.

IN DS, click on the class file and press F3, corresponding methods will be explained.

8) REFERENCE DOCUMENTS
Procedure / Process Name
http://uni-t.temenos.com/dms/QMS/L2L3/Documentation/Coding_Procedure.doc?Web=1
http://gva2flare.temenosgroup.com/doc/ Developer Guides available in each T24 Release
End of the Document

© 2020 CSD Team, Temenos

CSD - Java Programming Standards (1) 1

Uploaded by

Document Information

Original Title

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

CSD - Java Programming Standards (1) 1

Uploaded by

Copyright:

Available Formats

T24 - Client Specific Development

Java Programming Standards

Information in this document is subject to change without notice.

Version Date Author Status Description

2 V1.0 /Jul-20 Quality Assurance Internal Use

4.3.1 Comments ............................................................................................................................................ 11

4.4.1 Interfaces ............................................................................................................................................. 14

5.1.1 Usage of Local Field Related API ........................................................................................................... 25

5.2.1 If … else Statement ............................................................................................................................... 26

3 V1.0 /Jul-20 Quality Assurance Internal Use

5.4 Exception Handling ........................................................................................................................................................... 34

5.7.1 Local Commons in AA: .......................................................................................................................... 40

6.1.1 getAvailableAmount ............................................................................................................................ 45

6.3.1 calculateRate ....................................................................................................................................... 47

6.7.1 AA.Contract Api ................................................................................................................................... 51

4 V1.0 /Jul-20 Quality Assurance Internal Use

7.3 OCRT using Sonarcube ...................................................................................................................................................... 62

5 V1.0 /Jul-20 Quality Assurance Internal Use

2) BASIC CODING STANDARDS:

1. All java codes must be followed the basic coding standards.

6 V1.0 /Jul-20 Quality Assurance Internal Use

6. Use meaningful variable Names and method Names.

7 V1.0 /Jul-20 Quality Assurance Internal Use

3) CONFIGURATION and DEBUG PROCEDURES:

4) QUALITY, CONVENTIONS and PACKAGING:

Reasons for using a naming convention is

1. To reduce the effort needed to read and understand source code.

2. To find out the value which the variable holds.

3. To understand the purpose for which the variable is defined

The naming conventions with respect to Java programming is sculptured below.

8 V1.0 /Jul-20 Quality Assurance Internal Use

All java classes to follow the below naming conventions.

• Interface Name ( Example : Bacs, Chap )

All Data records to follow the below naming conventions

Data Record Type Sample Name

9 V1.0 /Jul-20 Quality Assurance Internal Use

4.2 Usage of Variables

4.3 Program Qualities

If so, what does the term “Simplicity” means?

10 V1.0 /Jul-20 Quality Assurance Internal Use

the commenting as 2 parts.

• Standard title information showing:

11 V1.0 /Jul-20 Quality Assurance Internal Use

• A Javadoc section (i.e. contained within /** ... **/) detailing:

The modification history should be defined in the format as specified below,

12 V1.0 /Jul-20 Quality Assurance Internal Use

code where the programmer wish to explain to the program views.

The below given example will illustrate a sample of Functional Commenting.

// Raise error if any duplicate Channel and Currency found

13 V1.0 /Jul-20 Quality Assurance Internal Use

4.4 Basics of JAVA Programming

I. Interface Names & Files

II. Header information, Member Constants, Methods

I. Class Names & Files

II. Class Structure & Limits

o Class elements must be defined in the following order:

Static final constants

o The class file must not contain any tab characters

III. Static Final Constants

/** <description of usage and purpose> */

15 V1.0 /Jul-20 Quality Assurance Internal Use

Constants should be used in the following circumstances:

• In place of magic numbers.

• A Javadoc section (i.e. contained within / ... /) detailing: