T24 Template Programming

TEMENOS EDUCATION CENTRE

NOTICE
These training materials are the copyrighted work of Temenos Headquarters SA and other companies in the TEMENOS group of companies
(The Copyright Owner). The training materials contain protected logos, graphics and images. Use of the training materials is restricted solely for
use by licensed end users, partners and employees. Any un-licensed reproduction by any means, redistribution, editing, transformation,
publishing, distribution, or public demonstration of the training materials whether for commercial or personal gain is expressly prohibited by law,
and may result in severe civil and criminal penalties. Violators will be prosecuted to the maximum extent possible. Such training materials shall
not be represented
represented, extracted into or included in part
part, or in whole
whole, as part of any other training documentation without the express permission of
the Copyright Owner, which must given in writing by an authorised agent of the Copyright Owner to be valid. Where such permission is given a
clear and prominent notice must be displayed on any and all documentation accrediting the Copyright Owner with having copyright over the
materials. End-user licenses will in no event contain permissions extending the use of these training materials to third parties for commercial
training purposes.
Without limiting the foregoing, copying or reproduction of the training materials in part or in whole to any other sever or location for further
reproduction or redistribution is expressly prohibited, unless such reproduction is expressly licensed by the Copyright Owner.
Copyright © 2010 Temenos Headquarters SA
Version History

Version Date Author Reviewer

1.0 1st March 2009 Alamelu SenthilNathan

2.0 1st February 2010 Alamelu SenthilNathan

Slide 2
Objectives

At the end of the session you will have

 Adequate knowledge to understand

 How applications work in T24

 Adequate knowledge to create

 Applications in T24 version R7 and above
 Applications in T24 version R5 and below

 Adequate knowledge to
 Write code to raise accounting entries, overrides, errors, validations
 Create Multi threaded subroutines

Slide 3
Day wise Agenda

 Day 1
 An introduction to TEMPLATE programming
 Understanding the TEMPLATE subroutine

 Day 2
 Understanding [Link] flow

 Day 3
 Discuss the DEBIT CARD example
 Creating Fields in an Application

 Day 4
 Creating required applications

Slide 4
Day wise Agenda

 Day 5
 Validations and Workshops

 Day 6
 Overrides & DAS
 Workshops

 Day 7
 Multithreading
M ltith di
 Running as COB and Service
 Workshop

Slide 5
Day wise Agenda

 Day 8 & 9
 Accounting
 Workshop
 Writing better code workshop

 D 10
Day 10, 11 & 12
 Extra Information
 Templates in R5
 Workshop
 Comparison between R5, R7 and R9 templates

Slide 6
Day 1

Day 1
 An introduction to TEMPLATE programming
 Understanding g the TEMPLATE subroutine

Slide 7
g1
What Is An Application In T24?
n1

 T24 Applications
 Allows input of data
 Stores data in database
 Performs a business functionality
 Example: Funds Transfer, Money Market

 T24 Tables
 Allows input of data
 Stores data in database
 Holds static data used by other applications
 Performs no business functionality on its own
 Example:
p Category,
g y Currency y

Slide 8
Slide 8

n1 Read the document for Template Programming in R10 for a detailed understanding of the course
nausheen, 2/17/2010

g1 Since this is elearning course instead of giving numbers 1 & 2 in the notes page please mention that explanantion for no. 1 is for What
is an application. and explanation for no. 2 is for What is a Table.

e.g. start the notes page like What is an application?

then explanin what it is, explain each point in brief as writeen on the slide. give examples of an applications in T24

Follow the same for What is a Table? Since no. 2 has started directly with it is similar to applications will lead to confusion for
elearning team. Explain each point in brief for T24 Tables and give examples of Tables in T24
gshital, 4/5/2010
g2
Applications in T24

 There are different kinds of applications in T24

 H type
 U type
 L type
 T type
 W type

 At database level depending on the kind above, there can be

 A $HIS file (Data)
 A $NAU file (Data)
 A Live file (Data)
 A ]D file (Dict)

Slide 9
Slide 9

g2 Since L T & W type application contains only live file explain the difference among these 3 types with example.
gshital, 4/5/2010
Functions in T24

 There are different functions that can be used with these applications
 I Input
 A Authorise
 S See
 L List
 V Verify
 C Copy
 D Delete
 R Reverse
 H History Restore
 2 Second Authoriser
 P Print
 Q Audit

Slide 10
Application Classification

 Applications can be broadly classified in any of the three categories

 CUS
 FIN
 INT

 Other classifications
Oth l ifi ti available
il bl ttoo, b
butt h
have properties
ti off one off th
the
above

 Naming conventions for database files

 CUS – F<MNE>.<APPLICATION>{$<SUFFIX}

 FIN – F<MNE>. <APPLICATION>{$<SUFFIX}

 INT – F. <APPLICATION>{$<SUFFIX}

Slide 11
Definitions from T24

 What is an Application in T24?

 An application in T24 allows input of data and performs some business
processing too.

 What is a Table in T24

 A table
t bl ttoo stores
t data,
d t static
t ti data
d t that
th t can be
b used
d by
b one or more
applications

 What is a Product?
 One or more applications and tables that work together to perform a
business functionality

Slide 12
Before Creating An Application

 W mustt decide
We d id a name ffor our application
li ti

 What type of application (H, U, L, T, W)

 What classification (CUS, FIN, INT)

 W mustt decide
We d id what
h t ffunctions
ti are going
i tto be
b permitted
itt d

 We must decide fields

 Data
D t types
t
 Max, Min Characters
 Field Names
 Extra validations of data

 Other related file updates

 What is the business functionality to be built in

Slide 13
s2
g3
Application flow in T24 – Always the same

1. Enter Application
pp Name

T24 checks if a VALID Application is entered.

2. Enter Function and ID

When data is entered and we hit enter, T24 validates it as a function.

When we enter data and hit the edit button, the function is taken as I and the
data is validated as an ID of the application

3. Open record

Checks if record exists with same ID, if yes read from file and load into cache

If record does not exist, open new record for user.

user

Slide 14
Slide 14

s2 When explaining this slide you must demo to them so that they will actually accept this flow. First you can launch an invalid
application, and then you can use a correct application name but with an invalid function etc. If your batch of trainees is not freshers,
then you can ask them to try this out instead of a demo by you. This too is a really important slide and a demo by you will make the
‘flow of an application’ in T24 crystal clear.
sara, 4/28/2009

g3 Instead of using 'we' in the notes page make usage of 'you' or 'user' explain each step in the flow in brief not all steps are explained
here in the notes page
gshital, 4/5/2010
s5
g12
Application flow in T24 – Always the same

4. Enter Data and Commit

Validates data, raises errors or overrides and saves record in database

5. Authorise Record

If everything is OK, save changes in the database, update other applications if

required

S d advices
Send d i t
to customer
t (if any)
)

Slide 15
Slide 15

s5 When explaining this slide you must demo to them so that they will actually accept this flow. First you can launch an invalid
application, and then you can use a correct application name but with an invalid function etc. If your batch of trainees is not freshers,
then you can ask them to try this out instead of a demo by you. This too is a really important slide and a demo by you will make the
‘flow of an application’ in T24 crystal clear.
sara, 4/28/2009

g12 Instead of using 'we' in the notes page make usage of 'you' or 'user' explain each step in the flow in brief not all steps are explained
here in the notes page
gshital, 4/5/2010
g4
We have decided

Business Functionality
When and What we must do

Other Features
-Functions
F ti My new
-Product Information Application
-Type of Application H, U. L etc.,
-Classification FIN, CUS, INT etc.,

T24 Application Flow

Slide 16
Slide 16

g4 Remove 'we' as explained before

Explain each box in brief that to create an application these many steps required to take.
gshital, 4/5/2010
Code…

 If we want to develop an application in T24, do we have to start writing

code from scratch?
 NO NO NO

 There are two core subroutines called TEMPLATE and

[Link] that we must use to create an application

 That’s why this course is called TEMPLATE PROGRAMMING 

Slide 17
What now…

Business Functionality
When and What we must do
METHODS

Other Features
-Functions
F ti My new
-Product Information Application
-Type of Application H, U. L etc.,
-Classification FIN, CUS, INT etc.,
Properties defined in TEMPLATE

T24 Application Flow

THE TEMPLATE
[Link]

Slide 18
s3
Common Variables

 Variables in T24
 Global
 Local

 Most variables used in TEMPLATE programming can be found in

I_COMMON

 Application / Product specific common variables also available

 I_ENQUIRY.COMMON
 I_GTS.COMMON etc

 Must include I_ file in all code

 $
$INSERT I_File - will look for I_ file in current directory,
y, [Link] and
[Link]

 $INCLUDE <Dir> I_File– must specify the directory in which file is

present . Better to not use $INCLUDE.
$INCLUDE

Slide 19
Slide 19

s3 Many trainees are confused with the contents of COMMON insert files and Application insert files. Clear the air at this point in time.
This is because the INSERT statment is used for both
sara, 4/28/2009
A Must Know

 Following common variables need to be understood before we attempt to

create version routines

 [Link]
 [Link]
 [Link]
 [Link]()
 [Link]()
 [Link]()

 All the above mentioned variables are common variables defined in

I COMMON
I_COMMON.

Slide 20
What Happens When A New Record Is Created In T24?

 User creates new CUSTOMER record using CUSTOMER I F3

 When record is committed…

[Link] : 123456 [Link] - NOT USED [Link] - NOT USED

[Link] [Link] [Link]

Mnemonic : TRG
Name.1 : TRG
Street : RANGA ROAD
Sector : 1100 NOT USED NOT USED
Target : 999
Customer Status : 1
Nationality : IN
Residence : IN
Language : 1
Record Status :

Slide 21
[Link]

 Common variable defined in I_COMMON

 Contains the ID of the currently opened record in any application

 When the record is closed or committed or authorised the value in this

variable gets flushed.

Slide 22
[Link]

 Common variable defined in I_COMMON

 Dimensioned array which comprises of 500 dynamic arrays

 Holds the currently opened record in any application

 [Link] holds the ID of the currently opened record, while [Link] holds the
actual record. ‘R’ in the variable name stands for ‘Record’

Definition as seen in II_COMMON

COMMON : DIM R
[Link](C$SYSDIM)
NEW(C$SYSDIM)
Where C$SYSDIM = 500

 Inference : Since the size of [Link] is now restricted to 500 it implies that
no application in T24 has more than 500 fields. The day it exceeds 500,
C$SYSDIM’s value will be increased

Slide 23
When Happens When A Record Is Authorized?

 User opens INAU record to authorise it

[Link] : 123456 [Link] – 123456 [Link] – Not Used

[Link] [Link] [Link]

Mnemonic : TRG Mnemonic : TRG
Name.1 : TRG Name.1 : TRG
Street : RANGA ROAD Street : RANGA ROAD
Sector : 1100 Sector : 1100 Not Used
Target : 999 Target : 999
Customer Status : 1 Customer Status : 1
Nationality : IN Nationality : IN
Residence : IN Residence : IN
Language : 1 Language : 1
Record Status : INAU Record Status :INAU

Values from [Link] only are written into the database when record is COMMITTED/AUTHORISED

Slide 24
[Link]

 Common variable defined in I_COMMON

 If an unauthorized record exists for the currently opened record in any

application, this variable will hold the ID of the unauthorized record

 You may ask, ‘Will the ID of a live record and a unauthorized record
ever be different?”
 No. This variable enables us to know, programmatically whether an
unuathorised record exists for the currently opened record

Slide 25
[Link]

 Common variable defined in I_COMMON

 Dimensioned array which comprises of 500 dynamic arrays

 Holds the currentlyy opened

p record in any
y application
pp

 [Link] holds the ID of the currently opened record’s unuathorised

record (if it exists), while [Link] holds the actual unauthorized record
(If it exists). ‘R’ in the variable name stands for ‘Record’

Definition as seen in I_COMMON : DIM [Link](C$SYSDIM)

Where C$SYSDIM = 500

Slide 26
What Happens When An Authorized Record Is Amended?

[Link] : 123456 [Link] – NOT USED [Link] - 123456

[Link] [Link] [Link]

Mnemonic : TRG Mnemonic : TRG
Name.1 : TRG Name.1 : TRG
Street : RANGA ROAD Street : RANGA ROAD
Sector : 1100 1200 NOT USED Sector : 1100
Target : 999 Target : 999
Customer Status : 1 Customer Status : 1
Nationality : IN Nationality : IN
Residence : IN Residence : IN
Language : 1 Language : 1
Record Status : Record Status :

Values from [Link] only are written into the database when record is COMMITTED/AUTHORISED

Slide 27
[Link]

 Common variable defined in I_COMMON

 If an authorized record exists for the currently opened record in any

application, this variable will hold the ID of the authorized record

 This variable enables us to check programmatically whether the

currently opened record has a previously authorized record

Slide 28
[Link]

 Common variable defined in I_COMMON

 Dimensioned array which comprises of 500 dynamic arrays

 Holds the currently opened record’s previously authorized record (if

any) in any application

 [Link] holds the ID of the currently opened record’s authorised record

(if it exists), while [Link] holds the actual live record (If it exists). ‘R’ in
the variable name stands for ‘Record’

Definition as seen in I_COMMON : DIM [Link](C$SYSDIM)

Where C$SYSDIM = 500

Slide 29
g5
What Happens When A Change On An Authorized Record Is Authorized?

The
The old authorized record (With Sector 1100) goes to history ([Link]$HIS)

ID of the record in the history file will be 123456;1

Contents
C t t off [Link]
R NEW is
i written
itt tot the
th LIVE file
fil

[Link] : 123456 [Link] - 123456 [Link] - 123456

[Link] [Link] [Link]

Mnemonic : TRG Mnemonic : TRG Mnemonic : TRG
Name.1 : TRG Name.1 : TRG Name.1 : TRG
Street : RANGA ROAD Street : RANGA ROAD Street : RANGA ROAD
Sector : 1200 Sector : 1200 Sector : 1100
Target : 999 Target : 999 Target : 999
Customer Status : 1 Customer Status : 1 Customer Status : 1
Nationality : IN Nationality : IN Nationality : IN
Residence : IN Residence : IN Residence : IN
Language : 1 Language : 1 Language : 1
Record Status : INAU Record Status : INAU Record Status :

Slide 30
Slide 30

g5 Please mention that this record is opened for authorisation that's why [Link] and [Link] hold the same copy in this case record
is committed and opened for authorization

Need to verify following point

If the record we have requested is in INAU status, the record from file is loaded into [Link] and the record is displayed to the
user for further modification, the copy that the user is looking at is [Link]. In this case record is not committed it's in INAU status

Mention both cases in the notes page the explanation given in the notes page is not enough [Link] is not at all explained in the
notes page
gshital, 4/6/2010
Common Variables – I_COMMON

We must learn the use of these common variables before we continue

 V$FUNCTION – Holds the T24 function entered by the user

 MESSAGE – Allows inter routine or inter para communication by

setting process ‘state’ in this variable

 AF, AV, AS – Holds the field position, multi value position and sub
value position respectively

 E and ETEXT – Variables used to store error message to be displayed.

E is used by [Link] itself to display errors if any

 [Link] and [Link] – Variable that holds the ID of the

company we are currently logged into and the COMPANY record is
loaded into R
[Link]
COMPANY

Slide 31
Some more Common Variables

 [Link] - Loaded as soon as the user logs in, holds the USER profile

 OPERATOR – ID of the User currently logged in

 APPLICATION - Holds the name of the application currently in use. In

T24 only one application can be active at a given point in time

 LCCY, LNGG
 Holds Local Currency as defined in company
 Holds the language from the USER profile

 TODAY - Holds T24’s today (date)

 C$SYSDIM – Common variable equated to 500 in II_COMMON,

COMMON, used to
define the size of all dimensioned array common variables

Slide 32
The TEMPLATE Subroutine

Static Information or Properties of our application

 Use core subroutine TEMPLATE ([Link])

 We must decide a name for our application

 What type of application (H, U, L, T, W)

 What classification (CUS, FIN, INT)

 We must decide what functions are g

going
g to be p
permitted

 Why do we need to mention all this?

 To create additional components of an application

Slide 33
 Other Component of an Application
s19

 What does T24 do with all the properties of the application we define in
the TEMPLATE subroutine?

 There are other components of an application other than code

 [Link] Entry
 Type of application
 Special properties (additional info)

 [Link] Entry
 File suffixes available
 Classification

Slide 34
Slide 34

s19 Do not discuss how to create these right now, but discuss the use of each
salamelu, 2/20/2009
 Other Component of an Application
s21

 [Link] Entry
 Actual field names
 Field properties

Slide 35
Slide 35

s21 Do not discuss how to create these right now, but discuss the use of each
salamelu, 2/20/2009
 Other Component of an Application
s48

 Insert File - I_ File

 For programming

Slide 36
Slide 36

s48 Do not discuss how to create these right now, but discuss the use of each
salamelu, 2/20/2009
 Other Component of an Application
s49

 Files at database level to store data

 To store data 

Slide 37
Slide 37

s49 Do not discuss how to create these right now, but discuss the use of each
salamelu, 2/20/2009
Getting Started

 DO NOT MODIFY the TEMPLATE subroutine in [Link]

 Each application that we create, must have its own copy of the
TEMPLATE

jsh-->COPY FROM [Link] TEMPLATE TO [Link]

jsh-->COPY FROM [Link] TEMPLATE, <NEW APPNAME>

 The above line must be modified to reflect <NEW APPNAME> as the

name of the subroutine

 Properties of an application are defined here

Slide 38
g6
Table Objects

[Link] = '[Link]' ;* Full application name

[Link] = 'XX [Link]' ;* Screen title
[Link] = 'H' ;* H, U, L, W or T
[Link] = 'XX' ;* Must be on [Link]
[Link] = ‘ ' ;* Must be on [Link]
[Link] = 'INT' ;* As per [Link]
Table systemClearFile = 'Y'
[Link] ;* As per FILE
[Link]
CONTROL
[Link] = '' ;* As per [Link]
[Link] = '' ;* As per [Link]
[Link] = '[Link]' ;* Use to create I_F.[Link]
[Link] = '' ;* Used by [Link] if set
[Link] = '' ;* Space delimited list of blocked
functions
[Link] = '' ;* Trigger field used for OPERATION style

Slide 39
Slide 39

g6 Need to specify from where this screen shot has been taken. In this case it is taken from TEMPLATE
please mention that
gshital, 4/5/2010
g7
How are the properties used?

 The ID of the [Link] ,[Link] and SS entry - [Link]

 The TYPE for the [Link] record – [Link]

 The [Link] in [Link] record(Description) – [Link]

 The PRODUCT field in [Link] and [Link] –

[Link]

 The CLASSIFICATION field in [Link] – [Link]

 The prefix for all fields in the I_ files – [Link]

 Functions that are not allowed for the application –

[Link]

Slide 40
Slide 40

g7 Mention that from the given list we can see that T24 gets information for the additional components of an application from the
information provided in TEMPLATE subroutine..
gshital, 4/5/2010
 I_Table
s43

 Contains all common variables used in table object

COMMON/[Link]/[Link](C$SYSDIM),[Link],
[Link],
[Link],
[Link],
[Link],
[Link],
[Link],
[Link],
[Link],
[Link],
[Link],
bl fi
[Link],
[Link],
[Link],
[Link],
Table lastApplication
[Link],
[Link],
[Link],
[Link],
[Link],
[Link],
[Link],
[Link],
[Link],

Slide 41
Slide 41

s43 Open I_Table and show the various common variables in that insert file, to get the trainees familiar about them
salamelu, 2/22/2010
 How is TEMPLATE and [Link] related?
s22

 To launch an application, we type its name in the command prompt

 It is validated – [Link] subroutine (after the browser
level checks)
• Checks [Link]

 Calls [Link] which in turn calls

[Link]
 Calls subroutine with <APPLICATIONNAME>

 Subroutine APPLICATION name is nothing but a copy of TEMPLATE

with static properties, and the list of methods to be called

 [Link] also invokes [Link]

Slide 42
Slide 42

s22 Tell trainees to read the word document also, many points are left out on the slide
salamelu, 2/20/2009
[Link]

SUBROUTINE [Link]([Link])
.
.
.

[Link] = ''
CALL @[Link]
IF Table
[Link]
name THEN
CALL [Link] ;* We need to call the central template routine
END ELSE
[Link] = "" ;* We've called a non central template
END
.
.
.
.
.

Note: In releases before R9, [Link] called the <Application>

Subroutine which in turn called [Link]

Slide 43
 [Link] Subroutine
s6

 The core subroutine used by every application in T24 since it contains

the execution flow

 An application’s business logic is broken up into individual subroutines,

called method.

 [Link] contains code to call or invoke these methods at the

right time

Slide 44
Slide 44

s6 Explain about the flow in [Link] in general terms, before going into the actual methods. Refer the document.
salamelu, 2/20/2009
 Methods in Template Programming
s7

 The business logic of an application is not part of TEMPLATE or

[Link]

 It is split up into methods

 There are 11 methods available for use

 [Link] determines the order of execution

 Methods are nothing but individual subroutines called from

[Link]

 M t follow
Must f ll naming
i convention
ti [Link]
APPNAME METHODNAME

Slide 45
Slide 45

s7 Though [Link] does not enforce any method as mandatory, Every application must have atleast one field, hence defining
.FIELDS method is essential.
salamelu, 2/20/2009
Methods

 Where are method names defined?

 Are they hard coded?

Slide 46
I_METHODS.[Link]

 Common variable to define method names

 Methods with different names ignored

Slide 47
I_METHODS.[Link]

 T24’s convention is to represent each position C_ROUTINES array by

a name not a number

Slide 48
 Methods in Template Programming
s23

 INITIALISE
 FIELDS
 FUNCTION
 ID
 RECORD
 VALIDATE
 PREVIEW
 OVERRIDES
 PROCESS
 AUTHORISE
 RUN

 This is also the order in which they are executed by [Link]

Slide 49
Slide 49

s23 Dont discuss each method in detail now.. Ask the class what they think will be part of the methods
salamelu, 2/20/2009
Day 2
 Understanding [Link] flow

Slide 50
[Link]

 Pattern of Execution of an application

 MUST NOT BE MODIFIED

 Advantage of having [Link]

 We can maintain code consistency and code standard
 Enables rapid code development, no need to start from scratch

Slide 51
Behind the Scenes – [Link]
s9

Launch Application from Command Prompt

 Initialise
 The first method to be executed when an application is launched

 Fields
 The next method to be executed

Input Record ID and press Enter (Function defaulted to I)

 Function
 This is executed after a function is entered by the user. If no function is
entered the default is Input
entered, Input.

 ID
 Executed after the function entered is validated. Validated ID, can modify ID
if required

Slide 52
Slide 52

s9 Explain what methods will get called at what stage of exection. When you click on validate, all methods from .DEFAULT to .PROCESS
gets executed. Again when you click on commit button, all these methods get executed. Clicking on validate button, gives an overall
picture of what happens when the record gets committed, except that it does not call [Link].
salamelu, 2/20/2009
Behind the Scenes – [Link]

 Record
 Executed before the record requested (existing or new) is displayed to the
user

Record requested is displayed (existing or new)

Data is input / modified, then Commit

 Validate
 After values are defaulted (if any) all data is validated

 Preview
 After data is validated, a delivery preview is available

 Overrides
 Overrides if any are generated now

Slide 53
Behind the Scenes – [Link]

 Process
 If all overrides are accepted, then this method is called before the record is
written to the $NAU file

Record is written to $NAU NOW

Authorise button is clicked

 Validate
 All data is validated twice,
twice once during commit and once during authorise

 Authorise
 This is executed after the Authorise button is clicked

Record is written to LIVE NOW

Run
 This is executed if the function used is Verify

Slide 54
 Using the Template Methods – Common Variables Available
s24

 INITIALISE
 Anything that needs to be done as soon as an application is launched can
be done here. It is not a mandatory method

 FIELDS
 This is the method in which an applications fields are defined. This is a
mandatory method as an application must have at least one field

 FUNCTION
 Code that need to be executed depending on the function entered,
manipulation of the function itself can be done here (V$FUNCTION)

Slide 55
Slide 55

s24 Disucss the use of the methods in detail and also make sure you mention from which method onwards, what common variables are
available for manipulation....
salamelu, 2/20/2009
 Using the Template Methods – Common Variables Available
s50

 ID
 Special editing to the ID entered, special validations to the ID ([Link])

Slide 56
Slide 56

s50 Disucss the use of the methods in detail and also make sure you mention from which method onwards, what common variables are
available for manipulation....
salamelu, 2/20/2009
 Using the Template Methods – Common Variables Available
s51

 RECORD
 Editing of the requested record before display to the user ([Link],
[Link],[Link])

Slide 57
Slide 57

s51 Disucss the use of the methods in detail and also make sure you mention from which method onwards, what common variables are
available for manipulation....
salamelu, 2/20/2009
Using the Template Methods

The methods listed here are executed after Commit is clicked

 VALIDATE
 Special validation of data
 [Link], [Link], [Link], E, Subroutine ERR

 OVERRIDES
 Overrides if any, must be raised here
 [Link], [Link], [Link], ETEXT, Subroutine [Link]

Slide 58
Using the Template Methods

The method listed here are executed after Commit is clicked

 PROCESS
 Processing that has to be done before the record is written to the $NAU file
Limits
Accounting
Charges

Slide 59
Using the Template Methods

The methods listed here are executed after Authorise is clicked

 AUTHORISE
 Processing to be done before record is written into LIVE file
Accounting
Delivery
Updating associated applications

 RUN
 This method is called only for W type applications that use the Verify
function

Slide 60
What Can Applications In T24 Do?

 The ability to have custom validations for data entered

 The ability to be customised (add extra functionality) by clients if

required

 The ability to raise overrides and errors

 The ability to generate delivery advices (1 or more)

 The ability to raise accounting entries

 The ability to raise charges

 The ability
abilit to add / remo
remove
e fields

 Associated COB processing if required

Slide 61
Digging Deep - [Link]

 Launch an application from the prompt

 Core subroutine [Link] called

 Checks [Link] Entry
 Checks if application can be used in GUI
 Checks User SMS
 Checks valid token for browser

Slide 62
Digging Deep - [Link]

 [Link] is now called which in turn calls

[Link]

 This calls
Thi ll a subroutine
b ti with ith th
the application
li ti name – nothing
thi b butt th
the
subroutine which a copy of TEMPLATE

 EB EXECUTE APPLICATION also calls THE

[Link] [Link]
TEMPLATE

 INITIALISE Method invoked first

 Application ready to receive input of function or ID

Slide 63
Digging Deep - [Link]

 On hitting enter, the application thinks we have entered a function and

validates that – FUNCTION method

 With any input, if we click the Edit button, it validates the data against
the ID of the application – ID method

Slide 64
Digging Deep - [Link]

 Core routine [Link] called to fetch the requested record

 Searches in
 Search in the $NAU File for the application
 Search in the Live File for the application
 Search in the $HIS File for the application
 El di
Else displays
l new record d

 Before displaying record, RECORD method executed

 [Link] and [Link] are two core routines that take care
of displaying the application screen

 [Link], [Link] routines available to

deal with multiple fields per line if using version

Slide 65
Digging Deep - [Link]

 Click
Cli kCCommit
it or V
Validate
lid t andd th
then…
 Can move on only after correcting errors
 VALIDATE method

Slide 66
s42
Digging Deep - [Link]

 Can view
C i preview
i off d
delivery
li message after
ft validation
lid ti
 .PREVIEW has to be set in ‘Additional Info’ field in [Link]
 PREVIEW method
 P i
Preview generated
t d using
i core routine,
ti EB
[Link]
HANDOFF

Slide 67
Slide 67

s42 Make the trainees input an FT. After validation, view the' delievery outref' and 'delivery inref' id's updated in the FT record. Click the
preview icon. Note the delivery preview pop up window.

Note: Ensure 'Dr Advice Reqd' and 'Cr Advice Reqd' fields in [Link] is set to 'Y'.
For any application to generate preview of delivery advices, supporting code has to be provided in .PREVIEW method.
salamelu, 2/12/2010
Digging Deep - [Link]

 Overrides
O id come nextt
 No option to reject overrides, just change data and Commit again
 OVERRIDES method

Slide 68
Digging Deep - [Link]

 PROCESS method executed

 [Link] called to update $NAU file in database
 Constraint processing invoked if any – Used to set user defined conditions
and overrides
 STP processing done here if set – Used for automatic authorization
versions based on conditions
 Version routines invoked if using version
 Audit fields updated
 Existing INAU record over written if any
 Deals slips triggered if any

 Everything is going to be ok…

Slide 69
Digging Deep - [Link]

 Record opened for authorisation

 VALIDATE method

 AUTHORISE method

 [Link] called to update Live file

 Call version routines if any
 Update CONCAT files if any
 Update AUDIT fields
 Update JOURNAL

Slide 70
JOURNAL ???

 [Link]

 Used for recovery purposes before

 [Link] at any given time will only hold the last 20 transactions per user

 Replaced with jBASE Transaction Journaling

 F WRITE writes
[Link] it tot cache
h
 FWC, FWT, FWF

 [Link] flushes data to disk from cache

Note: [Link] will hold the transaction details only if the field [Link] in SPF is
set to YES.
Slide 71
Day 3 & 4
 Discuss the DEBIT CARD example
 Creating
g Fields in an Application
pp
 Creating required applications

Slide 72
DEBIT CARD EXAMPLE

DEBIT CARD EXAMPLE

Slide 73
Debit Card Example

 Let us now create an application on our own - Read the Business

Specification now

 To provide the Debit Card feature in T24 we need to

 Create an application that will store all debit cards issued
 Create an application that will store parameter values
 Create an application that will store different types of debit cards available
 Create an application that will store all debit card transactions

 We must make sure to create a directory to keep the code that we are
going to write

jsh-->[Link] [Link] TYPE=UD

jsh-->COPY FROM [Link] TO [Link] TEMPLATE

Slide 74
 Debit Card Example
s25

 To create any type of application, we must make a copy of the

TEMPLATE subroutine from [Link]

jsh-->COPY FROM [Link] TEMPLATE,APPLICATIONNAME

 To create the fields for an application, we must make a copy of the

[Link] subroutine from [Link]

jsh-->COPY FROM [Link] TO [Link] [Link]

jsh-->COPY FROM [Link] [Link],[Link]

Slide 75
Slide 75

s25 Discuss the copy command

Discuss the use of I_COMMON and I_EQUATE

Discuss that the 2 variables shown are dynamic variables and they are discussed on the next slide
salamelu, 2/20/2009
 What we want to achieve…
s10

Slide 76
Slide 76

s10 Ask trainees to go through the functional and technical spec for Debit Card and make sure they are clear about the requirements.
salamelu, 2/20/2009
What we want to achieve…

Slide 77
Defining Fields

 Fields of an application are defined in the .FIELDS methods

 Though not made mandatory, this method must exist, since an

application must contain at least one field

 This method is called after the .INITIALISE method

 Uses the common variables from I_COMMON

 F
 N
 T
 ID.F
 ID.N
 ID.T
 CONCATFILE
 CHECKFILE
 [Link]
 V

Slide 78
F Array

 Dimensioned array used to specify field name, multi-value status

 Used only for fields in an application, not the ID

 Normal Field
F(Field position) = ‘FIELDNAME1’

 Simple Multi value

F(Field position) = ‘XX.FIELDNAME2’

Slide 79
F Array

 Associated Multi value (with sub value)

F(Field position) = ‘XX<FIELDNAME1’
XX<FIELDNAME1
F(Field position) = ‘[Link]<FIELDNAME2’
F(Field position) = ‘[Link]>FIELDNAME3’
F(Field position) = ‘XX>FIELDNAME4’

Slide 80
F Array

 Language Multi value

F(Field position) = ‘[Link].FIELDNAME1’

 F Array equivalent used ONLY for ID of an application

ID.F = ‘[Link]’

Slide 81
N Array

 Dimensioned array used to specify

 Maximum Characters
 Minimum Characters
 Field validations attached

Syntax Used Description

’10’ Up to 10 characters allowed, no special editing will be done.

’35.2’ A maximum of 35 characters, but at least 2 must be entered (Mandatory Field)

'006.6' Input must be 6 characters. Leading zeros will not be removed and the field
data will be validated at commit time.

Slide 82
ID.N

 N Array equivalent used to define ID properties only

ID.N = ‘16’

ID.N = ’16.1’ ; * .1 makes the field mandatory

Slide 83
 T Array
s26

 Dimensioned array that holds information about

 Data type
 List of possible values
 NOINPUT / NOCHANGE characteristics
 Justification
 HOT FIELD HOT
[Link], [Link]
VALIDATE properties

 Has 10 sub fields to specify all field properties

 T(Field position)<1> - Data type to call IN2 routine

 T(FieldPosition)<1> = ‘A’ will call IN2A routine to validate the data entered

 T(Field position)<2> - List of input options if predefined

 T(FieldPosition)<2> = “Yes_No_Maybe”
 T(FieldPosition)<2>
T(FieldPosition) 2 = ‘1001…5000’
1001…5000 will display all numbers from 1001 to
5000

Slide 84
Slide 84

s26 For each sub field in the T array, we must give examples of use from existing applications. Please refer Template Programming
document
salamelu, 2/20/2009
T Array

 T(FieldPosition)<3> - NOINPUT/NOCHANGE/EXTERN
 NOINPUT – Field never available for input
 NOCHANGE – Field not inputtable after record is authorised
 EXTERN – Field is cleared if record is copied

Slide 85
T Array

 T(FieldPosition)<4> - Format Mask

 Data can be displayed differently, irrespective of how it is stored in the
database. The Mask character used is #

 T(FieldPosition)<5> - Justification
 Default
D f lt Left
L ft justified,
j tifi d no need
d to
t specify
if T(FieldPosition)<5>
T(Fi ldP iti )<5>
 Right justified (R) and center justified (C ) are the other 2 options

Slide 86
 T Array
s27

 T(FieldPosition)<6> - MACHINE to default to machine date instead of

T24 date
 U d iin th
Used the USER application
li ti

 T(FieldPosition)<7> - TEXT to display a text box in the browser

 T(FieldPosition)<8> - NOMODIFY/NODELETE/NOEXPAND
 No Modification or changes allowed to multi value set after first
authorisation
 Multi value set cannot be deleted after record is authorised
 Multi value set cannot be expanded further after authorisation

 T(FieldPosition)<9> - [Link]/[Link]/[Link]
 [Link] causes field to be validated immediately
 [Link] causes all fields to be validated
 [Link] triggers validation at web server level

Slide 87
Slide 87

s27 Mention that the T(Z)<8> is used for multi value sets and that T(Z)<3> is for a single value field
salamelu, 2/20/2009
Built-in Data Types

 T24 supports a lot of built-in standard data types

 Built-in data types are equated to standard names in an Insert file

called I_Datatypes

Slide 88
I_Datatypes

EQU T24_String TO '[Link]'

EQU T24_BigString TO '[Link]'
EQU T24_Text TO '[Link]'
EQU T24_TextWide TO '[Link]'
EQU T24_Numeric TO '[Link]'
EQU T24
T24_Date
Date TO 'T24
[Link]
DATE'
EQU T24_Portfolio TO '[Link]'
EQU T24_Account TO '[Link]'
EQU T24_InternalAccount TO '[Link]'
EQU T24_Customer TO '[Link]'
EQU T24_Frequency TO '[Link]‘

EQU Field_Mandatory TO ',mandatory'

EQU Field_NoInput TO ',NOINPUT'
EQU Field
Field_NoChange
NoChange TO '
',NOCHANGE'
NOCHANGE'
EQU Field_Unique TO ',UNIQUE'
EQU Field_NoNulls TO ',NONULLS'
EQU Field_AllowNegative TO ',[Link]'

COMMON/DataTypeCommon/[Link],
[Link],
[Link],
[Link]

Slide 89
 [Link]
s11

 [Link] invokes [Link] which loads the id,

length and type depending on the basic data types

IF NOT([Link]) THEN
CALL [Link]
END

 [Link] is a common variable in I_Datatypes, which holds the list

of data types

 The values populated by this subroutine are session specific

Slide 90
Slide 90

s11 Explain why the values populated for the datatypes by this subroutine, are session specific
salamelu, 2/20/2009
[Link]

 Loads each of the basic data types as given below

SUBROUTINE [Link]
id = "[Link]"
length = 35
type = "A"
file = ''
GOSUB addBasicType

addBasicType:
typePos +=1
[Link]<typePos> = id
[Link]<typePos> = length
[Link]<typePos> = LOWER(type)
[Link]<typePos> = file
RETURN

Slide 91
Field Definitions

Field Definitions

Slide 92
 Defining Fields – API’s
s4

 T24 supports a number of API’s are used to define fields.

 These API’s internally update the F, N and T arrays.

Slide 93
Slide 93

s4 Go through the word document for a detailed explanation of the API's. Use the examples provided in the word document to explain the
use of the API's to the trainees.
salamelu, 2/12/2009
g8
[Link]

 Defines the ID field

 ID.F, ID.N and ID.T are assigned

 [Link](idName, dataType)

 It takes 2 parameters,
parameters the id name (ID
(ID.F
F item) and the data type of the
key

 The data type

yp of the key
y can either be

 A standard data type defined in I_Datatypes in [Link]

 Populate data type with values corresponding to N and T arrays

Slide 94
Slide 94

g8 Notes page doesn't look in e-lerning format it should be more descriptive not the just the copy of slide points
gshital, 4/6/2010
s46
g9
[Link]

 Defines the ID field

 ID.F, ID.N and ID.T are assigned

 [Link](idName, dataType)

 Table defineId invokes this API to define the fields

[Link] fields.

SUBROUTINE [Link]

dataType = ''

dataType<2> = 16.1

dataType<3> = ''

dataType<3 2> = 'SYSTEM'

dataType<3,2> SYSTEM

CALL [Link]("[Link]",dataType)

Slide 95
Slide 95

s46 [Link] and [Link] works the same way

salamelu, 2/22/2010

g9 gshital 06/04/2010
Notes page doesn't look in e-lerning format it should be more descriptive not the just the copy of slide points
gshital, 4/6/2010
s44
[Link]

 Adds a field with standard data types

 Table addField(fieldName fieldType

[Link](fieldName, fieldType, args,
args neighbour)

 It takes 4 parameters, where,

• fieldName - The name of the field to add. The "F" arrayy item
• fieldType - The standard T24 data type of the field
• args - Any arguments (mandatory, no input, etc.)
• neighbour - Reserved for future use.

 The various arguments possible are : Field_NoChange, Field_NoInput,

Field_Mandatory, Field_AllowNegative, Field_unique, Field_NoNulls

CALL [Link]("[Link]",T24_String,‘‘,‘‘)

Slide 96
Slide 96

s44 This API is used for creating fields with teh standard data type specifications
salamelu, 2/22/2010
s45
[Link]
s47

 Adds a field using the F, N and T definitions

 [Link](fieldName, fieldLength, fieldType, neighbour)

 It takes 4 parameters, where,

• fieldName - The name of the field to add. The "F" array item
• fieldLength - The length of the field. “N” array item
• fieldType - The type of the field. “T” array item
• neighbour - Reserved for future use

CALL [Link]("[Link]",35,‘A‘,‘‘)

Slide 97
Slide 97

s45 This API is used when we want to specify our own values for N and T arrays, instead of using the standard data types.
salamelu, 2/22/2010

s47 The trainer could ask the trainees to start creating the debit card application at this point after explaining the basic API's to create the
id and fields. This will help becoming familiar with teh use of these API's rather than explainign all the API's and then starting the
template creation.
salamelu, 2/22/2010
[Link]
s41

 Processes the arguments passed to [Link] API

 Not invoked directly from .FIELDS method

 Assigns the N array and T array positions according to the arguments.

 [Link](args, nArrayItem, tArrayItem)

 It takes 3 parameters,
parameters where
where,
• args – the list of arguments passed to [Link].
• nArrayItem - The N array item to process
• tArrayItem - The T array item to process

Slide 98
Slide 98

s41 To pass multiple arguments to the args parameter, do it as follows:

ARGS = Field_Mandatory:",":Field_AllowNegative

CALL [Link]("[Link]",T24_Numeric,ARGS,'')
salamelu, 3/6/2009
[Link]

 Sets the N and T array

 Not invoked directly from .FIELDS

FIELDS method

 [Link](fieldLength, fieldType, neighbour)

 It takes 3 parameters, where,

• fieldLength : The N array item
• fieldType : The T array item
• neighbour : Reserved for future use

 [Link] and [Link] use this API to set the N

and
d T arrays b
based
d on th
the parameters
t passed d on tto th
them

Slide 99
[Link]

 T24 allows us to hard code drop down options for a field in the T array

 [Link] now allows us to define dynamic drop down values

Slide 100
[Link]

 Add a field with a virtual table

 Used to create a field with a finite set of predefined options

 [Link](fieldName, tableName, neighbour)

 It takes 3 parameters, where,

• fieldName - The name of the field to add. The "F" array item
• tableName – The virtual table name used to access values in [Link]
A li ti
Application.
• neighbour - Reserved for future use

Slide 101
[Link]

 Adds a field with a virtual table.

 Performs the same functionality as [Link],

Table addFieldWithebLookup
except that the list of options are configurable.

 [Link](fieldName,
( tableName, args,
g neighbour)
g )

 It takes 4 parameters, where,

• fieldName - The name of the field to add. The "F" array item
• tableName – The virtual table name used to access values in [Link]
Application.
• args - (optional) Any additional arguments (mandatory, no input, etc.)
• neighbour - Reserved for future use

Slide 102
[Link]

 Sets the default value for the current field

CALL [Link]("[Link]",T24_Date,Field_NoInput,'')
CALL [Link](TODAY) ;* Assign default value

Slide 103
CHECKFILES

 Variable used to store Application Vet details for a field

 Only ID of record from CHECKFILE Application is defaulted into field

 Enrichment can be any field from the CHECKFILE Application

CHECKFILE(currentFieldPosition) = tableName : FM : enrichmenentField

Slide 104
 [Link]
s39

 Adds a check file to a field

 Turns tableName(argument to Field

[Link])
setCheckFile) into a checkfile
argument using the default enrichment field ([Link] field)
set on standard selection or the 1st field.

CALL [Link]("CUSTOMER",T24_Customer,Field_Mandatory,'')
CALL [Link]("CUSTOMER")

 For the
F th field
fi ld C
Customer,
t whatever
h t iis entered
t d iin validated
lid t d against
i t th
the
CUSTOMER application.

Slide 105
Slide 105

s39 No specific API for defining checkfile for ID. WE have to use [Link]
salamelu, 3/3/2009
 [Link]
s52

 The setCheckFile routine internally assigns.

CHECKFILE(currentFieldPosition) = tableName : FM :
enrichmenentField

CALL [Link]("CUSTOMER",T24_Customer,Field_Mandatory,'')
CALL [Link]("CUSTOMER")

Slide 106
Slide 106

s52 No specific API for defining checkfile for ID. WE have to use [Link]
salamelu, 3/3/2009
[Link]

 Adds amount field to the application

 Table addAmountField(fieldName currencyFieldName,args,

[Link](fieldName, currencyFieldName args neighbour)

 It takes 4 parameters, where,

fifieldName
ldN - The
Th name off ththe fifield
ld tto add.
dd The
Th "F" array ititem
currencyFieldName – Name of the field that holds the currency the field is held
in.
args g – Anyy additional arguments
g ((mandatory,
y no input,
p etc.))
neighbour – Reserved for future use

CALL [Link]("[Link]",'CURRENCY','',' ')

Slide 107
[Link]

 Adds a field with pre-defined set of options

 Table addOptionsField(fieldName options,

[Link](fieldName, options args,
args neighbour)

 It takes 4 parameters, where,

fieldName - The name of the field to add. The "F" arrayy item
options – The list of options separated by an ‘_’. The T(fieldposition)<2> item.
args – Any additional arguments (mandatory, no input, etc.)
neighbour – Reserved for future use.

CALL [Link]("[Link]","S_W",'','')

Slide 108
[Link]

 Adds a simple field that holds the value YES or blank

 Table addYesNoField(fieldName args

[Link](fieldName, args, neighbour)

 It takes 3 parameters, where,

fieldName - The name of the field to add. The "F" array item
args – Any additional arguments (mandatory, no input, etc.)
neighbour – reserved for future use

Slide 109
[Link]

 API to set a number of fields to be NOINPUT, NOCHANGE or

inputtable

 [Link](attribute, fieldList)

 It takes 2 parameters, where,

attribute - The attribute to set. One of NOINPUT, NOCHANGE or “ “
fieldList - The list of fields to set the attribute on. These are field numbers

 Loops th
L throughh eachh fifield
ld iin fifieldList
ldLi t and
d sets
t th
the atribute
t ib t iin th
the thi
third
d
field of the T array. Loops through each field in fieldList and sets the
atribute in the third field of the T array

 More than one field can be set to one specified attribute.

Slide 110
[Link]
s37

 All new applications must define a set of reserved fields that can be
used to add extra fields to the application without the need to change
the layout of the data

 The name of the reserved fields must be of the form RESERVED.1

etc.,

 Reserved fields can be added in 2 ways

CALL [Link](“RESERVED.1”)

CALL [Link]("RESERVED.1", T24_String, Field_NoInput,"")

Slide 111
Slide 111

s37 When new fields sre added to an existing application, we must release a convertion routine to realign the existing values. But if we add
that new field on to the reserved field, we can prevent this realigning. That is the main purpose of reserved fields.
salamelu, 2/27/2009
[Link]

 Applications that raise delivery events must define a field to hold the
delivery references

 The name of this field should be [Link]

 Delivery Reference fields can be added in 2 ways

CALL [Link](neighbour)

CALL [Link](“[Link]", T24_String, Field_NoInput,"")

 It can be multi valued to hold delivery references for multiple parties

involved

Slide 112
[Link]

 Local reference fields allows T24 clients to add user definable fields to
the application.

 The name of this field should be [Link]

 Local reference fields can be added in 2 ways

CALL [Link](neighbour)

CALL [Link](“[Link]", T24_String, Field_NoInput,"")

Slide 113
[Link]

 Applications that raise accounting entries must define a field to hold the
entry ids that have been raised

 The name of this field should be [Link]

 Statement Numbers field can be added in 2 ways

CALL [Link](neighbour)

CALL [Link](“[Link]", T24_String, Field_NoInput,"")

Slide 114
[Link]

 All applications MUST have a field to store overrides

 Override fields can be added in 2 ways

CALL [Link]
Table addOverrideField

CALL [Link](“[Link]", T24_String, Field_NoInput,"")

Slide 115
[Link]

 Sets the position of the audit fields when defining the field definition for
a table.

 This API uses [Link] to create audit fields and set

their position.

Slide 116
Audit Fields

 [Link] – Holds status of record(INAU, IHLD, REVE etc.,).

A live record does not have any status

Slide 117
Audit Fields

 Two other audit fields [Link] and [Link] not

populated here – only when you use the Q function

Note: The order of definition of fields must be such that the overrides field is just before the
audit fields and the [Link] field must precede the overrides field.

Slide 118
CONCAT Files

 CONCAT files help eliminate unnecessary selects

 Example - [Link]

 When CONCAT file is specified for a field in the application, data from
field is ID to record in CONCAT file and [Link] is the data of the
record in CONCAT file

 Code to update CONCAT files is part of [Link]

CONCATFILE(FieldName) = ‘[Link]’:FM:’[Link]’

Slide 119
CONCAT Files

 ID Options are AL, AR, NEW

 The CONCAT application must be created separately since that too is

an application in T24, only updates are automatic

Slide 120
 Non Stop Compliance
s40

 C$[Link] - Common variable defined in I_COMMON.

 It controls the behaviour of an application when the NS (Non Stop)

module is installed.

 This variable can be set to -

 ALL – Non stop allowed if module is installed. Meaning application will

behave normally even when COB is executing

 NEW – Only New deals allowed if NS is installed when COB is running

 NOD – NS complaint only if .NOD is mentioned in the application’s

[Link]
G entry, where .NOD
O means No Dates record required for f its
processing.

Slide 121
Slide 121

s40 It is not mandatory that C$[Link] has to be set in .FIELDS method

salamelu, 3/3/2009
Workshop

 Copy the TEMPLATE subroutine for all DEBIT CARD related

applications

 Create the required fields for each of them using the API’s discussed

Slide 122
How to create additional components?

 We have created the fields for our application

 Do we have to manually create all the necessary additional

components to make our application work?

Slide 123
How to create additional components?

 No, [Link] will do it for us…..

Slide 124
 [Link]
s28

 Workfile Application to create

 [Link] entry
 [Link] entry
 I_ File(insert file in BP)
 [Link]
 Create files at Database level
 Create DAS routines – discussed later on…

 Record ID is Application Name

 Verify record

 Say Y to all questions asked

Slide 125
Slide 125

s28 Important thing to mention here is where [Link] gets information to create each component

Do not discuss DAS option now

salamelu, 2/20/2009
When to create which additional component?

 If static properties have changed

 Rebuild [Link], [Link], DATABASE FILES if required

 If the field name has been changed

 Update I_File and SS

 If the field properties have been changed

 Update SS

 If a new field has been added

 Update I_File and SS

 If the application name has to be changed

 Update all components

Slide 126
 Workshop
s12

 Run [Link] and create additional components for all the

applications created relating to DEBIT CARD

Slide 127
Slide 127

s12 Discuss about how to create all the additional components manually
salamelu, 2/20/2009
Day 5
 Validation and Workshops

Slide 128
Data Validations

Data Validations

Slide 129
Validating Data

 ID validation can be done in .ID method

 Data validation must be written in .VALIDATE

VALIDATE method

Slide 130
Validating Data

 Overrides to be raised are also part of validating data, but must be

written in the .OVERRIDES method

 Extra validations (Client customization) can be done via Version

Routines
 Validation Routines
 I
Inputt Routines
R ti
 Authorisation Routines
 ID Routine
 Check Record Routine
 After UNAU Routine
 Before AUTH Routine

Slide 131
 .RECORD Method – Debit Card Example – [Link]
s4
[Link]:
*Code to populate the value for security number
CALL [Link]([Link])
Y.TIME1 = FIELDS([Link],'.',1,1)
Y.TIME2 = FIELDS([Link],'.',2,1)
[Link] = Y.TIME1:Y.TIME2

*Get the value of the year from today's date

[Link] = LEFT(TODAY,4)

*Form the Card number by concatenating year and unique time

[Link] = [Link]:[Link]
IF [Link]([Link]) EQ '' THEN
[Link]([Link]) = [Link]
END
* Code to populate the value for End date
[Link].DAY1 = LEFT(TODAY,4) ;* Get the year portion
Y END DAY1 = Y
[Link].DAY1 [Link].DAY1
END DAY1 + 5 ;*
* Add fi
five years
[Link].DAY2 = RIGHT(TODAY,4)
[Link] = [Link].DAY1:[Link].DAY2 ;*Concatenate year, day & month

* Is RESULTING YEAR a leap year? No. How are we going to tell this in our code
* CDT is a T24 subroutine used to CALCULATE DATE, if we specify the *number
number of
calendar dates, it will give the date after so many *calendar days. So let’s do a
plus 1 day and a minus of one day to *get the actual day

CALL CDT("",[Link],"+1C");
CALL CDT("",[Link],"-1C")
IF [Link]([Link]) EQ '' THEN
[Link]([Link]) = [Link]
END

Slide 132
Slide 132

s4 Concentrate on the common variables being used in the code

Refer tech spec before discussing this screen shot

Defaulting a date is not exactly a very good example - defaulting must be done only if the field is blank and hence the condition.
sara, 5/20/2009
.RECORD Method – Debit Card Example – [Link]

 Fields are defaulted when a new record is opened

Slide 133
Error Messages

 Errors are generated before overrides

 Errors are generated when data is validated

 Code to raise errors can be written in the .VALIDATE method

 We use the common variable E to store error messages that must be

displayed or an ID to an existing record in [Link]

 ERR is the core subroutine to display

p y error messages
g

 When raising an error in for an ID in the .ID method, all we have to do

is set the error code or error message in the common variable E

 We do not have to call ERR as T24 calls it in [Link]

 If called,
called the error message is displayed after the record is opened

Slide 134
 .VALIDATE Method – Debit Card Example – [Link]
s30

 To access the data that is being input we will have to use

 [Link] in our .VALIDATE method

VALIDATE:
* TODO - Add the validation code here.
* Set AF, AV and AS to the field, multi value and sub value and
* invoke [Link]
* Set ETEXT to point to the [Link]

*Validation for customer's valid account

Y CUSTOMER = [Link]([Link])
[Link] R NEW(DBC CUSTOMER)
[Link] = [Link]([Link])
CALL [Link]([Link],[Link],[Link],[Link],[Link])
[Link] = [Link]<[Link]>
IF [Link] NE [Link] THEN
AF = [Link] ;* Name of the field
ETEXT = 'CUSTOMER ACCOUNT MISMATCH' ;* The error code
CALL [Link] ;* Needs to be invoked per error
END

Slide 135
Slide 135

s30 Refer to tech spec to see what validations must be done for the debit card applications
salamelu, 2/20/2009
.VALIDATE Method – Debit Card Example – [Link]

 Error Message displayed

Slide 136
Workshop

 Perform validations relating to – refer Tech Spec (all applications)

 .RECORD method
 .VALIDATE method

Slide 137
.AUTHORISE Method – Debit Card Example – [Link]

PROCESS:
CALL [Link]

[Link] = [Link]([Link])
[Link] = [Link]([Link])
CALL [Link]([Link],[Link],[Link],[Link],[Link])
Y CUS = R
[Link] [Link]<[Link]>
DBC<DBC CUSTOMER>
[Link] = [Link]<[Link]>
[Link] = [Link]:'-':[Link]:'-':[Link]

IF [Link]([Link]) = 'W' THEN

CALL [Link]([Link],[Link],[Link],[Link],[Link])
IF [Link] EQ '' THEN
[Link] = [Link]<[Link]>
END
CALL [Link]([Link],[Link],[Link],[Link],[Link])
IF [Link] EQ '' THEN
Y DRAWN AMT = 0
[Link]
END ELSE
[Link] = [Link]<[Link]>
END

[Link]
Y AMOUNT = [Link]([Link])
R NEW(DBT AMOUNT) + [Link]
Y DRAWN AMT
IF [Link] GT [Link] THEN
AF = [Link]
ETEXT = 'AMOUNT EXCEEDS MAX WITHDRAWAL AMOUNT'
CALL [Link]
END ELSE
CALL [Link]([Link],[Link],[Link])
END
END

Slide 138
.AUTHORISE Method – Debit Card Example – [Link]

 Live file updated, accounting entries raised

Slide 139
Workshop

 Refer to the Tech Spec and create

 .AUTHORISE method
for the applications that require it

Slide 140
Day 6
 Overrides
 Workshopp
 DAS & Workshop

Slide 141
Overrides

Overrides

Slide 142
Overrides Messages

 Generating overrides or errors at appropriate places increases the user

friendliness of an application

 .OVERRIDES method available to raise override messages. It is

executed after the data is validated but before it is return to the $NAU
file

 OVERRIDE Application used to define override messages

 TEXT - common variable to store the ID of the OVERRIDE record or

the actual text to be displayed

 [Link] is the core subroutine called to raise the override

 Overrides, if accepted are stored in the no input OVERRIDES field in

Overrides
an application

Slide 143
Overrides And Error Messages

 Overrides can be static in nature or dynamic (containing values from

the transaction)

 Values if any, must be passed in the TEXT variable itself before the call
to [Link]

 TEXT = ‘[Link]’:FM:VALUE1:VM:VALUE2 etc…

Slide 144
 .OVERRIDES Method – Debit Card Example – [Link]
s15
OVERRIDES:
* TODO Add your override here
* Set TEXT to be the key to the override you want to use form the OVERRIDE
table
* Set AF/AV/AS to be the field that is relevant to the override.
*

IF [Link]([Link]) NE [Link] THEN

AF = [Link]
TEXT = "[Link]"
GOSUB [Link]
END

[Link]:
CALL [Link]([Link])
IF TEXT = 'NO'
NO THEN
GOTO [Link]
END
RETURN

Note: [Link] is a record in OVERRIDE application. Before calling the core

subroutine [Link] for the first time, this code must be executed. These
statements initialise the override field in the application and clear existing overrides if
present [Link]
present. CURR NO is then incremented by 1 in the STORE [Link]
OVERRIDE subroutine so that
subsequent overrides are stored in the field and it is multi valued as required to store as
many overrides as required.

Slide 145
Slide 145

s15 Make the trainees raise the override as per the spec
salamelu, 2/20/2009
.OVERRIDES Method – Debit Card Example – [Link]

 When the Card Type is changed for an existing record…

Slide 146
DAS

DAS – Data Access Service

Slide 147
DAS

 SELECT statements are a part of almost every subroutine in T24

 SELECT statements not written efficiently is the killer when it comes to

the performance of any system

 If we needed data from the database, we would write an appropriate

SELECT statement and use the core subroutine [Link] to
execute it

 DAS is now the standard that must be followed when writing queries for
an application

Slide 148
DAS

 Data Access Service

 Single frame work for queries

 No requirement to write jQL or any other query language

 The subroutine [Link] which is the heart of DAS

generates the jQL or the SQL query depending on the database we are
using

 May be created by [Link] if required

Slide 149
Components of DAS

 If the application we are creating uses SELECT(s), we first have to

decide the list of queries that we want to allow

 We obviously can’t think of every possible combination, so it’s best to

build the list as we along

 In DAS each query defined has 2 parts – the user defined name for the
query and its description

 DAS components for each application

 I_DAS.APPLICATION – Names for queries to be used in application
 I_DAS.[Link] – Description
p for each q
query
y defined above
 [Link] – Routine to describe each query

Slide 150
I_DAS.APPLICATION

 Must list down all possible query option to be allowed for the application

 Each query must be given a meaningful name

 No need for any jQL yet

 Name must be equated to a number

 Naming convention must be DAS.<APPNAME>$<QUERYNAME>

EQU
QU [Link]$[Link]
S. . .C $CUS O .C TO
O 1
EQU [Link]$[Link] TO 2

Slide 151
I_DAS.[Link]

 This must contain an explanation for each of the queries used

 Notes must be stored in a variable called DAS$NOTES

 No actual query definition yet

COMMON/[Link]/DAS$CACHE(100),DAS$NOTES(100)

DAS$NOTES([Link]$[Link])
$ ( $ ) = 'List of cards p
per customer'
DAS$NOTES([Link]$[Link]) = 'Cards expiring before a date'

Slide 152
[Link]

 Definition of all queries take place here

 Queries are broken up into

 Fields
 Operands
 Sorts
 Joins

 For example, lets assume we need to define the two queries below

SELECT [Link] WITH CUSTOMER EQ ‘10001

SELECT [Link] WITH [Link] EQ TODAY AND [Link] LT

20200101

Slide 153
Defining the Queries

SUBROUTINE [Link]([Link],[Link],[Link])

$INSERT I_DAS.[Link]
$INSERT I_DAS.[Link]
$INSERT I_DAS
I DAS
[Link]:
[Link] = <[Link]>:[Link]
BEGIN CASE
CASE [Link] = [Link]$[Link]
[Link] = ‘CUSTOMER’
[Link] = ‘EQ’
[Link] = [Link]
CASE [Link] = [Link]$[Link]
[Link] = ‘[Link]’
[Link] = ‘EQ’
MY DATA = THE
[Link] [Link]<1>
ARGS<1> ;*
* Can
C use TODAY h
here t
too
[Link] = ‘AND’
[Link]<-1> = ‘[Link]’
[Link]<-1> = ‘LT’
[Link]<-1> = [Link]<2>
END CASE
RETURN

Note: [Link], [Link], [Link], [Link], [Link] are variable names that cannot be
changed The paragraph name has to be BUILD
changed. [Link].
DATA The ordering of insert files in the above code is very
important.

Slide 154
DAS

 Core DAS Components

 I_DAS – Insert file with code to execute and cache query results
 I DAS COMMON – Insert
I_DAS.COMMON I t file
fil with
ith DAS common variables
i bl
 DAS – Subroutine that is an equivalent of [Link]. Called when
execute of a query is needed

 Calling DAS is similar to [Link]

CALL DAS(‘ApplicationName’, QUERYNAME, LIST, [Link])

 DAS$CACHE – Common variable used to cache query results

Slide 155
DAS

 Advantages
 Caching
 D t b
Database specific
ifi query fformation
ti
 Predefined selects for an application

Slide 156
DAS

<ANY ROUTINE WHERE SELECT MUST BE EXECUTED>

$INSERT I_DAS.[Link]

[Link] = [Link]$[Link]
[Link] = ‘10001’
[Link] = ‘’ ;* Must mention $NAU or $HIS if required
CALL DAS(‘[Link]’,[Link],[Link],[Link])

 DAS is the core subroutine which internally invokes the subroutine of

the form DAS.<APPLICATION>

 This routine would not usuallyy be called byy code outside of a CALL DAS

Slide 157
More information

 DAS subroutine also invokes [Link] which

updates a live file called [Link] with the Table name, No of
records
d selected,
l t d Q Query name and
d th
the LIST returned.
t d

 dasMode is a COMMON variable defined in I_DAS.COMMON

 The results in [Link] file will be used if

dasMode = dasReturnResults

 The query string that DAS builds, can be returned by setting

dasMode=dasReturnDescription and the select statement is returned,
along with the description

Slide 158
Workshop

 Write a multi threaded routine to select

 All debit cards from the debit card master application
 All debit cards of a particular card type
 All debit cards that belong to a particular customer
 All debit cards that expire on a particular date
using
i DAS
DAS.

Slide 159
Day 7
 Multithreading
 Running as COB and Service
 Workshop

Slide 160
Day 8 & 9
 Accounting
 [Link]
 Workshop

Slide 161
Accounting

Accounting

Slide 162
Accounting files in T24

 [Link]

 [Link]

 [Link]

Slide 163
[Link]

 Account related entries are raised ONLINE and OFFLINE for all
movements in the customer and internal accounts.

 All entries in the CATEGORY range 1-19999 are held in this file.

Slide 164
[Link]

 In addition to [Link] record, an entry is also generated in the

[Link] file

 [Link] holds reference to transactions carried out since

the last COB and is cleared in the Start Of day processing. Similarly
[Link] holds reference to the forwarded dates transactions

 When the file is cleared during COB the contents is copied to a file by
name [Link] file

 In the file [Link], the actual account balance and other

related information for accounts are build using the [Link]
file

Slide 165
[Link]

 Profit and Loss entries are raised ON-LINE and OFF-LINE and are kept
in the [Link] file.

 All entries hitting the Category codes over 50000 are held in this file.

Slide 166
[Link]

 In addition to [Link] record, an entry is also generated in the

[Link] file.

 [Link] holds reference to transactions carried out since the

last COB and is cleared in the Start Of day processing. Similarly
CATEG ENT FWD holds reference to the forwarded dates transactions
[Link]

 When the file is cleared during COB the contents is copied to a file by name
CATEG ENT LWORK DAY file
[Link]

Slide 167
[Link]

 The [Link] file is updated only during COB.

Online spec entries are not raised

 Input of a fresh contract gives raise to a [Link] record,

which is converted to spec Entry during Close of Business

 The [Link] records are converted to SPEC entries in

[Link] in [Link].DAY5 and are cleared in
[Link] during Start Of day processing. Similarly
CONSOL ENT FWD holds reference to the forwarded dates
[Link]
transactions

 When the file is cleared during COB the contents are copied to a file by
name [Link] file

Slide 168
Accounting in T24

 When a record in any application is committed, the accounting entries

are raised and are stored in the [Link] directory.

 Once the record is authorized, the entries are then transferred from
[Link] directory to the appropriate accounting files.

 Any processing that has to happen before a record goes to INAU status
has to be done in the .PROCESS method

 Any processing that has to be done before a record is authorized has to

be done in the .AUTHORISE method

Slide 169
g10
[Link] Subroutine
s31

INITIALISATION

[Link]

[Link] [Link] [Link]

[Link] [Link] [Link]

[Link] [Link] [Link]

[Link] [Link]

[Link]
APPEND..[Link]

[Link]

Slide 170
Slide 170

s31 Refer to word document for detailed explanation of this flow

salamelu, 2/20/2009

g10 Brief the flow in notes page

gshital, 4/6/2010
Sample Code from [Link]

 Building Entries

 I_file of [Link] or [Link] could be used since name

only represents a position in the array called ENTRY

ENTRY<[Link]> = [Link]
ENTRY<[Link]> = ''
ENTRY<[Link]> = [Link]
ENTRY<[Link]> = [Link]
ENTRY<[Link]>
C.S .CU C = LCCY
CC ;
;* Set a value
a ue here
e e
ENTRY<[Link]> = 'TR'
ENTRY<[Link]> = [Link]
ENTRY<[Link]> = '1'
ENTRY<[Link]> = [Link]<[Link]>
ENTRY<[Link]> = "AC"
ENTRY<[Link]> = TODAY

Slide 171
[Link] Subroutine

 [Link] is the core routine that will actually raise the entries

 It is called from within [Link] available in [Link]

 Has 4 parameters
 Application Name
 Type of Accounting
 Entry Details
 F
Forwardd Entry
E t Flag
Fl

 [Link] can raise more than one entry at a time with just
one call to it

Slide 172
[Link] Parameters

 1st parameter – Application name / Product name

 2nd parameter – Type of Accounting

 VAL
 AUT
 CHG
 DEL
 REV
 SAO
 RSAO
 SNP

 3rd p
parameter – Arrayy containing
g entries,, separated
p by
y FM

 4th parameter – Variable that can contain 1 or 0 or “CONSOL” to raise

CRF entries

Slide 173
[Link] Parameters

 3rd parameter – Array containing entries, separated by FM

 4th parameter – Variable that can contain 1 or 0 or “CONSOL” to raise

CRF entries

Slide 174
Important Note

 DO NOT GOSUB [Link] when the function is A, R or D

 When we call [Link] with AUT, all that we need to do is

select the correct entries from [Link] and move it to
[Link] / [Link]

 Since the entries are already available, we do not have to populate the
[Link] variable again

 This holds good when we use Reverse or Delete functions as well

Slide 175
Take a look at [Link]

 Understand the different paragraphs and need for checking

V$FUNCTION before proceeding with processing

 Discuss under which circumstances must we pass values in ENTRY

array to [Link]

Slide 176
Code for Accounting

 Accounting subroutine must be called in the .PROCESS as well as

.AUTHORISE method

 ID of [Link] is [Link] and hence when we call

[Link] in the .AUTHORISE method, we don’t have to
populate ENTRY array again

Slide 177
[Link] Subroutine

 The core routine that actually raises accounting entries is

[Link]

 Refer to the [Link] subroutine to understand

the entries raised by the Debit Card example we are discussing

 [Link] is the no input field that gets updated with accounting entry
ids

Slide 178
Accounting in the Debit Card Example

 Accounting entries must be raised

 Accounting Entries
 Accounting entries must be raised when
 A customer withdraws from the ATM or swipes his card (POS)
If it is an ATM withdrawal
• STMT Entry – Debit the customer account
• S STMT Entry
ty–CCredit
ed t tthe
e ATM accou
accountt ((internal)
te a )
If it is a POS swipe
• STMT Entry – Debit the customer account
• STMT Entry – Credit the Vostro account

 Use enquiries [Link] and [Link] to view entries

raised

Slide 179
[Link]

 The reporting ('CRB') consolidation module maintains the 'CENTRAL

REPORTING BASE' from which financial reports (such as General
L d
Ledger, B
Balance
l Sh
Sheet,
t St
Statement
t t off conditions,
diti F
Foreign
i C Currency
Control Ledger, Central Bank reports etc.) are produced.

 The [Link]
EB CONTRACT BALANCES file provides a single place for CRB
reporting to take its information.

 It is possible to extract the balance at the close of the last working day
as well as the current balance.

 Balances are updated real-time

real time at the authorization stage of a
transaction. For certain balance types unauthorized movements are
held too.

Slide 180
[Link]

 The balances are updated from the core accounting processing based on
the Consol entries raised by the underlying application – there is no direct
update from the underlying application.

 The following applications currently update [Link]

 ACCOUNT
 ASSET & LIABILITY (AL)
 [Link]
 [Link]
 PD PAST DUE
[Link]
 [Link]
 [Link]
 [Link]
 [Link]
 FOREX
 LIMIT

Slide 181
Workshop

 Raise accounting entries as per the requirement for the DEBIT CARD
example

Slide 182
D 10
Day 10, 11 & 12
 Extra Information
 Templates in R5
 W k h
Workshop
 Comparison between R5, R7 and R9 templates

Slide 183
Important Tidbits

Important Tidbits

Slide 184
HOOK Routines

 In some applications, we require a valid subroutine to be input as data

in certain fields
 Versions
 Enquiries

 How does T24 check is the data entered is in fact a valid routine name?

 T(FieldPosition) = ‘HOOK’

 Calls IN2HOOK to validate subroutine name entered

 Looks for an [Link] record for the data entered hence validating it

 Code to call the routine when required must be added by us at

application level

Slide 185
Transaction Boundaries in T24

 Transaction Boundaries ensure total updates or no updates at all

 Core subroutine [Link] called to start / end / abort the boundary

 Transaction Blocks are handles in 2 ways

y depending
p g on the requests
q
 Bulk OFS requests
 Non Bulk OFS requests

 At application level, there are transaction boundaries in

[Link] and in [Link]

Slide 186
Non Bulk OFS Requests

Slide 187
 Bulk OFS Requests
s18

Slide 188
Slide 188

s18 Mention the use of the common variable cTxn_TransactionLevel that is set and which in turn causes the transaction block at
application level to be skipped
salamelu, 2/20/2009
[Link]

 [Link]
 First checks if requested record is in the cache (FWC, FWT, FWF)
 Else reads from disk and loads into cache
 Subsequent reads within subroutine execution is only from cache
 Cache cleared after process termination

Slide 189
[Link]

 [Link]
 Checks if record is in cache ([Link], [Link],
S
[Link])
C )
 Else reads from disk and loads into cache
 This cache is session specific
 Records that rarely change can be accessed using this – SPF,
SPF COMPANY
 DON’T use this to read from ACCOUNT, CUSTOMER etc

 Difference between [Link] and [Link]

Slide 190
 Backward Compatibility
s16

 Before R9, Older TEMPLATE used C_PROPERTIES array to define

the properties

 C_PROPERTIES is a common variable defined in

I_METHODS.[Link]

 If properties are defined using the old TEMPLATE, [Link]

invokes a subroutine called [Link]

 This subroutine populates the Table objects from C_PROPERTIES

array

 This is essentially used for backward compatibility

Slide 191
Slide 191

s16 Also explain about C_METHODS flag array in templates before R9 and how methods are being called now
salamelu, 2/20/2009
[Link]

Slide 192
Other Subroutines Used in [Link]

 MATRIX UPDATE
[Link]

 [Link]

 [Link] / [Link]

 FIELD INPUT / [Link]

[Link] FIELD MULTI INPUT

Slide 193
Interesting Core Subroutines Used So Far

 CDD

 CDT

 DUP

Slide 194
Interesting Core Subroutines Used So Far

 [Link]

Slide 195
Older Templates

Templates in older versions of T24 (R5)

Slide 196
Template Programming in R5 and lower

 No [Link]

 Different TEMPLATE subroutine available depending on the type of

application
 U, H – Copy the TEMPLATE subroutine from [Link]
 L – Copy the TEMPLATE.L subroutine from [Link]
 T – Copy the TEMPLATE.T subroutine from [Link]
 W – Copy the TEMPLATE.W subroutine from [Link]

 No properties and methods concept. Only paragraphs or calls to other

routines

 No [Link] to create other components, all done manually

using
 [Link] – To create the I_ file at the jBASE prompt
 [Link] and [Link] to create the respective records
 [Link] at the Awaiting Application prompt
 STANDARD SELECTION – to rebuild the SS record of an application
[Link]

Slide 197
The TEMPLATE in R5

 The flow of an application built into the subroutine

 Changes for different types of applications incorporated into different

TEMPLATE subroutines

 Code to be written in corresponding paragraphs or individual

subroutines and called when required

 No naming convention for these subroutines

 Validations executed as and when required, unlike when using the

browser

Slide 198
[Link]

 This is executed as soon as the function is entered

 Prohibit certain functions for a particular application

 Perform special checks if such functions are attempted.

 This is now the .FUNCTION method

Example :
IF INDEX(‘VH’,V$FUNCTION,1) THEN
E = ‘FUNCTION NOT ALLOWED FOR THIS APPLICATION’
CALL ERR
V$FUNCTION = ''
END

Slide 199
[Link]

 E
Executed
t d as soon as th
the ID iis entered
t d

 Any special editing of the record id should be coded here.

 The value entered will be in [Link].

 If an error is
i found
f d requiring
i i ththe id tto b
be re-input,
i t then
th ERROR mustt b
be
set so that T24 will ask for the record ID input again

 Error messages should be displayed using E and ERR

ERR.

 This is now the .ID method

Example :
IF (LEN([Link]) > 12) OR NOT(NUM([Link][8,5])) THEN
E = "INVALID ID"
CALL ERR
V$ERROR = 1
END

Slide 200
[Link]

 This is executed before the requested record is displayed to the user

 To perform additional processing / updating when an unauthorised

record is deleted

 This is now the .RECORD method

Slide 201
Major Difference in Validations

There are various stages where validation of data can be done.

 We could validate data as soon as a user types in data in a field and

presses return (Field Level Validation)

 When a user commits a record.

Validation of Data

Field Level Validation Input Level Validation

[Link] CROSSVAL

Slide 202
[Link]

There are 3 types of validations that can be done in check fields.

[Link]

[Link]
C C S XX DEFAULT FIELDS
[Link]

[Link]

Slide 203
Paragraphs in the [Link] Subroutine

 [Link] - Validate the value entered in a field and display error

messages (if any)

 [Link] - When data is not entered in a field, and if T24

must default a value into it, it is done in this paragraph which is
executed when the Enter key or Tab Key is used

 [Link] – Based on the value entered in a field

(COMI) if other fields need to be defaulted,
(COMI), defaulted that code goes here

Slide 204
[Link]

 The third subfield of the ’N’ arrayy should be set to ’C’. This is to enable the
checkfile property.
N(Z) = ’35..C’

 The value input will be in COMI and AF, AV and AS will be set.

 The value entered will NOT have been assigned to [Link] at this stage.

 This is now the .VALIDATE method

Slide 205
[Link]

 To perform additional processing / updating when a record is deleted

(i.e., V$FUNCTION = ‘D’)

Slide 206
[Link]

 To perform additional processing / updating when an authorised record

is reversed.

Slide 207
Cross Validation

 [Link] is the subroutine that will contain code to be executed

at cross validation

 This section will be performed only when the record has been
committed and FUNCTION is 'I' or 'C'.

 It should be split into three sections with calls to subroutines to process

Field cross validation

Overrides
Additional processing

Slide 208
Cross Validations

 [Link], [Link], [Link] can be used

 Fields in error can be flagged with a corresponding error message by

calling [Link] with AF, AV and AS set

 Check field validations also called again

 In the new way of coding, the .VALIDATE method is called again in

[Link] when a record is committed

Slide 209
[Link] Subroutine or Paragraph

 Subroutine that will contain code to generate overrides

 [Link] is used to access values in the fields and decide whether an

override must be generated or not

 [Link] must be a multi value field in the application

 Any override messages should be displayed by calling

[Link]([Link]) setting TEXT to the OVERRIDE
record ID or the text message to be displayed.

 If TEXT is returned as NO, then exit the subroutine immediately.

 The subroutine should initialise the override fields by calling

[Link] with [Link] set to zero at the start of the
subroutine.

 This is now the .OVERRIDE method

Slide 210
Additional Processing

 Invoked after all cross validation checks and overrides.

 To invoke other sub-systems e.g. [Link], Delivery etc

 In the new coding standard, this type of processing can be put in

the .PROCESS method or the .AUTHORISE method

Slide 211
[Link]

 To perform processing which is to be done before the record is written

to the unauthorised file.

 It will be executed when the FUNCTION used is D, R, C or I.

 After performing [Link], [Link] and

[Link].

 To make related updates to other files.

Slide 212
[Link]

 The purpose of this section is similar to that of [Link]

except that it will be performed after the write to the unauthorised file

 Not available in the new template programming

Slide 213
[Link]

 To do special processing before the live record is written.

 To invoke accounting in authorisation mode and to handle the

authorisation of a reversal.

 To distinguish between the authorisation of Input and the authorisation

of a reversal, the record status must be checked

Example :

BEGIN CASE
CASE [Link][1,3] = "INA"
CALL [Link]
CASE [Link][1,3]
RECORD STATUS[1 3] = "RNA"
CALL [Link]
END CASE

Slide 214
[Link]

 Similar to [Link] but performed after the write

 This is not available in the new template programming

Slide 215
What was defined where?

 Initialise method was INITIALISE paragraph in the TEMPLATE

subroutine in R5

 Fields method was the DEFINE

[Link]
FIELDS paragraph in the TEMPLATE
subroutine in R5

 Function method was the [Link] p

paragraph
g p in the
TEMPLATE subroutine in R5

 ID method was the [Link] paragraph in the TEMPLATE subroutine

in R5

 Record method was the [Link] paragraph in the

TEMPLATE subroutine in R5

 Default method was part of the [Link] subroutine available in

R5

Slide 216
What was defined where?

 Validate method was [Link] paragraph / subroutine in R5

 Preview method was [Link] paragraph in the TEMPLATE

subroutine in R5

 Overrides method was the OVERRIDES paragraph in the TEMPLATE

subroutine in R5

 Process method was the [Link] paragraph in the

TEMPLATE subroutine in R5

 Authorise
A th i method
th d was the
th [Link]
BEFORE AUTH WRITE paragraph
h iin th
the
TEMPLATE subroutine in R5

 Run method is the same as the $RUN routine in R5

Slide 217
Workshop

 Create the INSURANCE application according to the given

specification using the R5 template

 Perform the specified validations

Slide 218
Comparison of R5, R7 and R9 Templates

Comparison of R5, R7 and R9 Templates

Slide 219
TEMPLATE Subroutine

 In R5
 Both application flow and business logic built into TEMPLATE
 Different TEMPLATE subroutines for different application types
 No properties and methods
 All business functionality defines in paragraphs or call to routines
 No naming conventions for these routines

In R7
 Application flow in [Link]
 Same TEMPLATE subroutine for all types of application
 Business functionality in individual subroutines called methods
 C_PROPERTIES used to define properties
 C_METHODS flag array determines what methods to invoke

 In R9
 Table objects used to define properties
 Any method that exists will automatically be invoked

Slide 220
[Link] Subroutine

 In R5
 No concept of [Link]

 In R7
 [Link] holds execution flow
 .FIELDS method is made mandatory
 Other methods invoked based on C_METHODS
C METHODS flag array

 In R9
 Subroutine modified to be compatible with using Table definitions
 Any method that exists is automatically invoked

Slide 221
[Link]

 In R5
 This invokes the <Application> Subroutine

 In R7
 This invokes the <Application> Subroutine
 The <Application> Subroutine (a copy of [Link]) in turn invokes
THE TEMPLATE
[Link]

 In R9
 This invokes both the <Application>
Application Subroutine and [Link]

Slide 222
Field Definitions

 In R5
 [Link] paragraph in TEMPLATE contains the field
definitions
 ID F ID.N,
ID.F, ID N ID
ID.T,
T FF, N and T arrays are directly used to define the fields
fields.

 In R7
 In the .FIELDS method, ID.F, ID.N, ID.T, F, N and T arrays are directly used
to define the fields

 In R9
 In the .FIELDS method, there are a lot of API’s that can be used to define
fields which in turn populate values in the F, N and T arrays
 There are 2 new insert files
• I_Table
I Table to define common variables used in Table object
• I_Datatypes which equates basic data types to standard names

Slide 223
Validations

 In R5
 Validations can be done at 2 levels,
• Field level validations – [Link] paragraph
• Input
I t level
l l validations
lid ti ((when
h user commits
it th
the record)
d) – CROSSVAL
paragraph

 In R7
 Validations are written in the .VALIDATE method
• Executed on clicking validate, commit and authorise buttons
 For field level validations, field must be set as [Link] and code is
written in .VALIDATE method
• Executed on tab out of the field

 In R9
 Same as in R7

Slide 224
Creation of additional components

 In R5
 All components have to be created manually.
• [Link] at the jBASE prompt – to create the I_ file
• [Link]
PGM FILE and d [Link]
FILE CONTROL - to
t createt the
th respective
ti records
d
• [Link] at the Awaiting Application prompt – To create files at
database level
• [Link] – to rebuild the SS record of an application
pp

 In R7
 [Link] is a one stop shop to create all the additional
components

 In R9
 [Link]
EB DEV HELPER is
i a one stop
t shop
h to
t create
t allll the
th additional
dditi l
components

Slide 225
g11
Summary

 Adequate knowledge to understand

 How applications work in T24

 Adequate knowledge to create

 Applications in T24 version R7 and above
 A li ti
Applications iin T24 version
i R5 anddbbelow
l

 Adequate knowledge to
 Write code to raise accounting entries
entries, overrides
overrides, errors
errors, validations
 Create Multi threaded subroutines

Slide 226
Slide 226

g11 Objective and Summary doesn't match slides followed by summary are about you will now be able to should be a part of notes page
gshital, 4/6/2010
You will now be able to …

 Appreciate the way all applications in T24 work

 Create new applications in T24

 Modify functionality of existing ones (if required, otherwise it’s a bug!!)

 Decide which methods to split up the required functionality into

 Explain to others the TEMPLATE and THE

[Link]
TEMPLATE subroutine in
T24

 Be able to decide what properties to set for an application you are

about
b t tto create
t

 Create applications using the older Template in T24

Slide 227
You will now be able to …

 Decide when to use [Link] / [Link]

 Write validations, for an application as well as for a version

 Decide what type of accounting entries will be raised in a given

situation

 Write multi threaded routines for COB / Services

 Create additional components of an application and know their

relationship

 T debug
To d b iissues arising
i i ffrom iincorrectt code
d

 Explain to someone else about transaction management in T24

Slide 228
 Thank You
TEMENOS EDUCATION CENTRE
NOTICE
These training materials are the copyrighted work of Temenos Headquarters SA and other companies in the TEMENOS group of companies
(The Copyright Owner). The training materials contain protected logos, graphics and images. Use of the training materials is restricted solely for
use by licensed end users, partners and employees. Any un-licensed reproduction by any means, redistribution, editing, transformation,
publishing, distribution, or public demonstration of the training materials whether for commercial or personal gain is expressly prohibited by law,
and may result in severe civil and criminal penalties. Violators will be prosecuted to the maximum extent possible. Such training materials shall
not be represented
represented, extracted into or included in part
part, or in whole
whole, as part of any other training documentation without the express permission of
the Copyright Owner, which must given in writing by an authorised agent of the Copyright Owner to be valid. Where such permission is given a
clear and prominent notice must be displayed on any and all documentation accrediting the Copyright Owner with having copyright over the
materials. End-user licenses will in no event contain permissions extending the use of these training materials to third parties for commercial
training purposes.
Without limiting the foregoing, copying or reproduction of the training materials in part or in whole to any other sever or location for further
reproduction or redistribution is expressly prohibited, unless such reproduction is expressly licensed by the Copyright Owner.
Copyright © 2010 Temenos Headquarters SA