PRG8.Introduction To Web Application Development-R15 PDF

Building Web Applications in T24
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, extracted into or included in part, or in 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.
Also ensure that all the materials are marked as follows at least on the front page: Copyright © 2010 Temenos Headquarters SA (and change
each year like 2009-2011 as time passes)
Objectives
The objectives of this session are the following
 Introduction to Web Application Development

 Case Scenario – Debit card Application
 Walk through creation of a custom web page
 Describe the steps to create a web page in T24
Slide 2
Web Application Development
Web applications are “Dynamic” applications

that clients “across the globe” can access.
Slide 3
Click on the hyperlink above for the detailed functional specification for DEBIT CARD Application
Slide 4
What you need to do to create a custom web page.
 Design the Debit Card User Interface Web Page
 Create the database tables to store the information.
 Code the business logic and validations.
 Code the allowed operations for this module.
 Create the database table artifacts for the web page
 Code for authorisation to enable authorized access
 Enumerate the module in the existing T24 Catalog.
Slide 5
1. Develop the User Interface
Create a web form with the required form controls i.e., labels, text boxes, radio
buttons, combo boxes, drop down lists etc. to accept input of the required information
which has to be stored in the tables.
Slide 6
 Code for authorisation.to enable authorised access
Slide 7
2. We need a database table to store our information.
Dictionary File – Contains the table structure A multi-dimensional database

i.e., the field names and their attributes provided with a development
language jBC
DEBIT.CARD]D
DEBIT.CARD.ID 0 13R
SHORT.DESC 1 30R
ACCOUNT 2 10R
NO.OF.CARDS 3 1R
DISPLAY.NAME 4 30R jBASE
DEBIT.CARD.NO 5 16R Database
START.DATE 6 10R
END.DATE 7 10R
STATUS 8 7R
Data File – Stores the data records separated by FM,VM,SM
DEBIT.CARD
DBC1121300001 FM GOLD FM 23016 FM 1 FM JOHN FM 1121300001123456 FM 20111018 FM 20130901 FM CURRENT FM
DBC11013D2YUZ FM SILVER FM 45689 FM 1 FM JASON FM 1101324376549999 FM 20111018 FM 20130901 FM CURRENT FM
DBC11224d689H FM GOLD FM 23016 FM 1 FM DAVID FM 1122665578659090 FM 20110416 FM 20130301 FM CURRENT FM
Slide 8
 Code the Business logic and validations
Slide 9
3. Code the Business logic and validations
 The Debit Card ID has to start with a prefix – DBC, followed by Julian
Date and a 5 character Sequence number
 The Debit Account must be a Valid T24 Account and it should be a
mandatory field
 The Display name and Debit Card No is a multi-value field. The no of
multi-values should be equal to the no of debit cards specified
Slide 10
3. Code the Business logic and validations
 Debit Card No should be a 16 Digit no. The last 4 digits must be the
current year. This should be a no-input field
 Start Date must default to TODAY
 End Date must default to TODAY + 2 yrs.
 Raise an override if the End Date is > 5 years from start date
Slide 11
 Code the Business logic and validations
Slide 12
4. Identify the allowed operations for the module.
Pre-coded functions in T24
Allow, Input a Debit Card Issue I – Input a record,
Allow, View the Debit Card details S – View the record,
Allow, Authorise the Debit Card record A – Authorise,
Block, Reverse the Debit Card record R – Reverse an authorized record
Block, Delete a Debit Card D – Delete an unauthorized record,
Slide 13
Tables in a Transaction
Input New
User - A
Record
Save /
1 Commit
$NAU
Unauthorized
Slide 14
User B
2 Authorize
$NAU LIVE
Unauthorized Live / Authorized
Slide 15
User - A
Amend a
3 Live Record
Live
Record
$NAU LIVE
Slide 16
User B
Authorise
4 again
$HIS
$NAU LIVE
Slide 17
User B
Delete an
4 Unauthorised
record
$DEL
$NAU LIVE
Slide 18
Database Table Model
DATABASE
Live Unauthorised History Delete History Dictionary file

table table($NAU) table ($HIS) table ($DEL)
$HIS $DEL
LIVE $NAU
DEBIT.CARD DEBIT.CARD$NAU DEBIT.CARD$HIS DEBIT.CARD$DEL DEBIT.CARD]D
Slide 19
Identifying underlying tables for a page
One – to – one relationship between the data-controls on the T24 web-page and the
fields in associated table
DEBIT.CARD]D
DEBIT.CARD.ID 0 13R
SHORT.DESC 1 30R
ACCOUNT 2 10R
NO.OF.CARDS 3 1R
DISPLAY.NAME 4 30R
DEBIT.CARD.NO 5 16R
START.DATE 6 10R
END.DATE 7 10R
STATUS 8 7R
How does T24 understand how many tables are available for a page at the database level.
Let us understand application Stereotype and Classification
Slide 20
Application Stereotypes
Application Display Utility
Based on the above, applications can be classified into
Application – H and U type
Display – L and T type ( alias Live or Concat - File application )
Utility – W types ( alias Work file application ).
Slide 21
Application
H $NAU LIVE
$HIS $DEL
Contract
Application
U $NAU LIVE
$DEL
Display Utility
Live/Concat file
L LIVE
Work-file
Application Application W
T
LIVE
LIVE
Slide 22
Application Classification
SHARED NOT SHARED
Naming convention and number of database tables
Slide 23
Possible configurations for the system
Can be
Shared or Not
Shared
Customer files Customer files

Branch1 Branch3 Shared
Branch1 Branch2 Branch3

Installation
files
Not
Financial files Financial files Financial files Shared
Branch1 Branch2 Branch3
Naming convention & number of database tables
F. DEBIT.CARD$HIS
F. DEBIT.CARD$NAU
SHARED F. DEBIT.CARD
F. DEBIT.CARD]D
->Shared by all branches

-> $HIS, $NAU & Live File
are created for H type
Slide 25
Naming convention & number of database tables

Separate set of
tables for each
Branch. File names
are distinguished
using the Company
FBNK. DEBIT.CARD$NAU mnemonic
FBNK. DEBIT.CARD
F. DEBIT.CARD]D
NOT
SHARED FBRANCH1. DEBIT.CARD$NAU
FBRANCH1. DEBIT.CARD
F. DEBIT.CARD]D
FBRANCH2. DEBIT.CARD$NAU
FBRANCH2. DEBIT.CARD
F. DEBIT.CARD]D
Slide 26
 Code for authorisation to enable authorised access
Slide 27
How does a user determine the fields available on a form.
The STANDARD.SELECTION acts as a field catalogue in T24 – i.e. exposes

the fields that are available in an application to the user
DEBIT.CARD]D
T24
DEBIT.CARD.ID 0 13R
SHORT.DESC 1 30R
ACCOUNT 2 10R
NO.OF.CARDS 3 1R
DISPLAY.NAME 4 30R
DEBIT.CARD.NO 5 16R
START.DATE 6 10R
END.DATE 7 10R
STATUS 8 7R
Slide 28
STANDARD.SELECTION - A STANDARD.SELECTION record describes the table

structure i.e., the field names and its attributes. Used primarily by ENQUIRIES and
VERSIONS
Holds the
Field name
Core validation routine invoked to

validate data entered in this field.
Single / Multi Value status of the field

Type of field
D – Data Field
Slide 29
Assume you have written the following line of DEBIT.CARD]D

DEBIT.CARD.ID 0 13R
code in your web-page to retrieve the debit card DEBIT.CARD]D
SHORT.DESC 1 30R
no from the table. It works fine and you have DEBIT.CARD.ID
ACCOUNT 2 0 10R 13R
SHORT.DESC
NO.OF.CARDS 3 1 1R 30R
replicated the same code in 50 other pages.
ACCOUNT
DISPLAY.NAME 4 2 30R 10R
To your surprise there is a change in the NO.OF.CARDS
DEBIT.CARD.NO 5 3 16R 1R
specification. And a new field has been inserted DESC.TYPE
START.DATE 6 4 10R10R
DISPLAY.NAME
END.DATE 7 5 10R 30R
in the table as shown. What about your code?
DEBIT.CARD.NO
STATUS 8 7R 16R
6
E.g.- FN.DEBITCARD = ‘F.DEBIT.CARD’ START.DATE 7 10R
END.DATE 8 10R
F.DEBITCARD = ‘’
STATUS 9 7R
CALL OPF(FN.DEBITCARD,F.DEBITCARD)
CALL F.READ(FN.DEBITCARD,R.DEBITCARD,DEBIT.CARD.NO,F.DEBITCARD,ERR.DEBITCARD)
DC.NO = R.DEBITCARD<5> Will Malfunction !!
HARD-CODING field positions can result in enormous re-work when there is a change in the table design
Slide 30
Alias Names
Simple Solution
 Store 5 in a variable DC.DEBIT.CARD.NUMBER
 Use DC.DEBIT.CARD.NUMBER instead of 5 in the code
What is the change required when a new field is introduced in

the table and the field position of debit card number changes ?
Slide 31
INSERT File
An insert file is a file which provides an alias name for the field positions. This helps
programmers avoid the pitfalls of referring to a field in the table using their positions
E.g.:- DC.NO = R.DEBITCARD <DC.DEBIT.CARD.NO>
A change in the table design in the future, entails reflecting the change in a single
location i.e., the insert file, rather than all of the 50 pages as in the previous scenario
An Insert file needs to be created for your web page for the same reason.
Slide 32
INSERT File
Insert files for your web-pages has to be named as I_F.<web page name> in the BP directory.
‘EB.CUS.’ is a unique
prefix attached to the
field names to avoid
name collisions.
The insert file for CUSTOMER is I_F.CUSTOMER in the T24.BP directory.
Slide 33
INSERT File
Field names of the database table must ideally be pre-fixed uniquely in the Insert file
mappings. This is to avoid field name ambiguity, when multiple insert files are used in the
same program.
Consider the following scenario.
Slide 34
INSERT File
A simple unique prefix can resolve this name collision
Caution must be exercised when using Field positions instead of Field names,
since field positions can be altered in later releases of T24 and your code is likely
to malfunction.
Slide 35
 Code for authorisation to enable authorised access
Slide 36
6. Who is authorized to access the web-page?
SECURITY
AUTHENTICATION AUTHORIZATION
T24 has a robust security mechanism already in place.

Your web page requires no special code therefore to achieve this functionality.
Slide 37
6. Authentication - Options
Authentication handled by T24
Authentication handled by web/application

server functionality
Authentication using proprietary mechanisms

(Authentication Servers)
Slide 38
6. Authorisation – 5 Security Levels
Entity T24 Multi-Company

Entity
Separation by logical entity
Function T24 Application

Function Funds Transfer, Money Market etc.
Service
Service T24 Version / Enquiry
Defined versions of T24 Applications
Operation
Operation T24 Function
Input, Authorize, See, Reverse etc.
Attribute
Attribute T24 Field
T24 field-level filtering
Slide 39
Slide 40
7. Integrate the newly developed module with the existing web application
How does the server process a client request for a web-page, identify and execute your page
and respond to the client.
DEBIT CARD
???
HTTP Request
I want to issue a
Debit Card for Tom
T24
Server
Client
Configure your web page in PGM.FILE and FILE.CONTROL.
Slide 41
7. Integrate the newly developed module with the existing web application
PGM.FILE
I want to issue a
Debit Card for Tom
Http Request Verifies
Http Response Registered? Yes
T24
Server
Here’s the page
Client you asked for. Register
DEBIT CARD
Application
PGM.FILE is a catalog of all the valid web pages that can be executed from T24, both browser
and classic. It is analogous to a Telephone directory with a list of valid telephone no's
Slide 42
PGM.FILE
View the registry entry for the T24 CUSTOMER application in PGM.FILE
When the user enters a

request for the DEBIT
CARD web page in the
browser, PGM.FILE is
verified for a registered
CUSTOMER application is entry as shown. If found,

configured in PGM.FILE to be the application is sent in
of ‘H’ Type.
the response to the client,
Screen Title – displays
header in the browser title else the user receives a
bar. Configured in 4 “Missing Application”
languages.
message.
Product – The T24 product
for which the page is created
Slide 43
FILE.CONTROL
Is a catalog which T24 looks up for information regarding the database tables. The naming
convention and the number of database files are configured here
File Type and

Modulo is used
to specify the
size of the jBASE
database files.
The CUSTOMER web

page configured in the
visual, manipulates data
in 4 tables, $HIS, $DEL,
$NAU & LIVE.
The classification
is CUS, so separate
tables are created
for each company
and data in tables
is shared across
companies
Slide 44
SUMMARY
To re-iterate, to create a new web page in T24, the work of a web-developer is to
 Design the user interface to accept user input.

 Create the database tables for persistent storage of data.
 Write the business logic and validations in methods.
 Make provision for the allowed/restricted functions for your page
 Identify the authorised users of your web-page and code for authorisation.
 Create the database table artifacts for the web page - STANDARD.SELECTION
and Insert files
 Catalog the web page in T24 by making a PGM.FILE entry.
 Catalog the associated table in T24 by making a FILE.CONTROL entry.
Slide 45
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, extracted into or included in part, or in 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.
Also ensure that all the materials are marked as follows at least on the front page: Copyright © 2010 Temenos Headquarters SA (and change
each year like 2009-2011 as time passes)

PRG8.Introduction To Web Application Development-R15 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PRG8.Introduction To Web Application Development-R15 PDF

Загружено:

Авторское право:

Доступные форматы

Building Web Applications in T24

TEMENOS EDUCATION CENTRE

The objectives of this session are the following

 Introduction to Web Application Development

Web applications are “Dynamic” applications

 Design the Debit Card User Interface Web Page

 Create the database tables to store the information.

 Code the business logic and validations.

 Code the allowed operations for this module.

 Create the database table artifacts for the web page

 Code for authorisation to enable authorized access

 Enumerate the module in the existing T24 Catalog.

 Design the Debit Card User Interface Web Page

 Create the database tables to store the information.

 Code the business logic and validations.

 Code the allowed operations for this module.

 Create the database table artifacts for the web page

 Code for authorisation.to enable authorised access

 Enumerate the module in the existing T24 Catalog.

Dictionary File – Contains the table structure A multi-dimensional database

Data File – Stores the data records separated by FM,VM,SM

 Design the Debit Card User Interface Web Page

 Create the database tables to store the information.

 Code the Business logic and validations

 Code the allowed operations for this module.

 Create the database table artifacts for the web page

 Code for authorisation.to enable authorised access

 Enumerate the module in the existing T24 Catalog.

Date and a 5 character Sequence number

 The Debit Account must be a Valid T24 Account and it should be a

 The Display name and Debit Card No is a multi-value field. The no of

multi-values should be equal to the no of debit cards specified

current year. This should be a no-input field

 Start Date must default to TODAY

 End Date must default to TODAY + 2 yrs.

 Design the Debit Card User Interface Web Page

 Create the database tables to store the information.

 Code the Business logic and validations

 Code the allowed operations for this module.

 Create the database table artifacts for the web page

 Code for authorisation.to enable authorised access

 Enumerate the module in the existing T24 Catalog.

Pre-coded functions in T24

Allow, Input a Debit Card Issue I – Input a record,

Allow, View the Debit Card details S – View the record,

Allow, Authorise the Debit Card record A – Authorise,

Block, Reverse the Debit Card record R – Reverse an authorized record

Block, Delete a Debit Card D – Delete an unauthorized record,

Live Unauthorised History Delete History Dictionary file

DEBIT.CARD DEBIT.CARD$NAU DEBIT.CARD$HIS DEBIT.CARD$DEL DEBIT.CARD]D

Application Display Utility

Based on the above, applications can be classified into

Application – H and U type

Display – L and T type ( alias Live or Concat - File application )

Utility – W types ( alias Work file application ).

SHARED NOT SHARED

Naming convention and number of database tables

Customer files Customer files

Branch1 Branch2 Branch3

Naming convention & number of database tables

->Shared by all branches

Naming convention & number of database tables

What you need to do to create a custom web page.