Slide 1

What Is An Application In T24?

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: Category, Currency
Slide 2
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 3
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


Slide 4
Application Classification
Applications can be either
CUS
FIN
INT
Other classifications available too, but have properties of one of the above

Naming conventions for database files

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

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

INT F. <APPLICATION>{$<SUFFIX}

Slide 5
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 too stores data, static data that can be used by one or more
applications

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


Slide 6
Before Creating An Application
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 going to be permitted

We must decide fields
Data types
Max, Min Characters
Field Names
Extra validations of data

Other related file updates

What is the business functionality to be built in



Slide 7
Application flow in T24 Always the same
1. Enter Application 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.

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
Send advices to customer (if any)

We have decided
Slide 8
Business Functionality
When and What we must do
Other Features
-Functions
-Product Information
-Type of Application H, U. L etc.,
-Classification FIN, CUS, INT etc.,

T24 Application Flow
My new
Application
Slide 9
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
THE.TEMPLATE that we must use to create an application

Thats why this course is called TEMPLATE PROGRAMMING
What now
Slide 10
Business Functionality
When and What we must do
METHODS
Other Features
-Functions
-Product Information
-Type of Application H, U. L etc.,
-Classification FIN, CUS, INT etc.,
Properties defined in TEMPLATE
T24 Application Flow
THE.TEMPLATE
My new
Application
Slide 11
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, GLOBUS.BP
and bnk.run

$INCLUDE <Dir> I_File must specify the directory in which file is
present
Slide 12
A Must Know
Following common variables need to be understood before we attempt to
create version routines

ID.NEW
ID.OLD
ID.NEW.LAST
R.NEW()
R.OLD()
R.NEW.LAST()

All the above mentioned variables are common variables defined in
I_COMMON.

Slide 13
What Happens When A New Record Is Created In T24?
ID.NEW : 123456
R.NEW
Mnemonic : TRG
Name.1 : TRG
Street : RANGA ROAD
Sector : 1100
Target : 999
Customer Status : 1
Nationality : IN
Residence : IN
Language : 1
Record Status :
ID.NEW.LAST - NOT USED

R.NEW.LAST



NOT USED
ID.OLD - NOT USED
R.OLD



NOT USED

User creates new CUSTOMER record using CUSTOMER I F3
When record is committed

Slide 14
ID.NEW
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 15
R.NEW
Common variable defined in I_COMMON

Dimensioned array which comprises of 500 dynamic arrays

Holds the currently opened record in any application

ID.NEW holds the ID of the currently opened record, while R.NEW holds the
actual record. R in the variable name stands for Record

Definition as seen in I_COMMON : DIM R.NEW(C$SYSDIM)
Where C$SYSDIM = 500


Inference : Since the size of R.NEW is now restricted to 500 it implies that
no application in T24 has more than 500 fields. The day it exceeds 500,
C$SYSDIMs value will be increased
Slide 16
When Happens When A Record Is Authorized?
ID.NEW : 123456
R.NEW
Mnemonic : TRG
Name.1 : TRG
Street : RANGA ROAD
Sector : 1100
Target : 999
Customer Status : 1
Nationality : IN
Residence : IN
Language : 1
Record Status : INAU
ID.NEW.LAST 123456

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



Not Used
Values from R.NEW only are written into the database when record is COMMITTED/AUTHORISED

User opens INAU record to authorise it

Slide 17
ID.NEW.LAST
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 18
R.NEW.LAST
Common variable defined in I_COMMON

Dimensioned array which comprises of 500 dynamic arrays

Holds the currently opened record in any application

ID.NEW.LAST holds the ID of the currently opened records unuathorised
record (if it exists), while R.NEW.LAST holds the actual unauthorized record
(If it exists). R in the variable name stands for Record

Definition as seen in I_COMMON : DIM R.NEW.LAST(C$SYSDIM)
Where C$SYSDIM = 500

Slide 19
What Happens When An Authorized Record Is Amended?
ID.NEW : 123456
R.NEW
Mnemonic : TRG
Name.1 : TRG
Street : RANGA ROAD
Sector : 1100 1200
Target : 999
Customer Status : 1
Nationality : IN
Residence : IN
Language : 1
Record Status :
ID.NEW.LAST NOT USED

R.NEW.LAST



NOT USED
ID.OLD - 123456
R.OLD
Mnemonic : TRG
Name.1 : TRG
Street : RANGA ROAD
Sector : 1100
Target : 999
Customer Status : 1
Nationality : IN
Residence : IN
Language : 1
Record Status :
Values from R.NEW only are written into the database when record is COMMITTED/AUTHORISED

Slide 20
ID.OLD
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 21
R.OLD
Common variable defined in I_COMMON

Dimensioned array which comprises of 500 dynamic arrays

Holds the currently opened records previously authorized record (if
any) in any application

ID.OLD holds the ID of the currently opened records authorised record
(if it exists), while R.OLD holds the actual live record (If it exists). R in
the variable name stands for Record

Definition as seen in I_COMMON : DIM R.OLD(C$SYSDIM)
Where C$SYSDIM = 500


Slide 22
What Happens When A Change On An Authorized Record Is Authorized?
ID.NEW : 123456
R.NEW
Mnemonic : TRG
Name.1 : TRG
Street : RANGA ROAD
Sector : 1200
Target : 999
Customer Status : 1
Nationality : IN
Residence : IN
Language : 1
Record Status : INAU
ID.NEW.LAST - 123456

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

ID.OLD - 123456
R.OLD
Mnemonic : TRG
Name.1 : TRG
Street : RANGA ROAD
Sector : 1100
Target : 999
Customer Status : 1
Nationality : IN
Residence : IN
Language : 1
Record Status :

The old authorized record (With Sector 1100) goes to history (FBNK.SECTOR$HIS)

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

Contents of R.NEW is written to the LIVE file
Slide 23
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 THE.TEMPLATE itself to display errors if any

ID.COMPANY and R.COMPANY Variable that holds the ID of the
company we are currently logged into and the COMPANY record is
loaded into R.COMPANY
Slide 24
Some more Common Variables
R.USER - 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 T24s today (date)

C$SYSDIM Common variable equated to 500 in I_COMMON, used to
define the size of all dimensioned array common variables




Slide 25
The TEMPLATE Subroutine
Static Information or Properties of our application

Use core subroutine TEMPLATE (GLOBUS.BP)

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 going to be permitted

Why do we need to mention all this?
To create additional components of an application


Slide 26
Other Component of an Application
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

PGM.FILE Entry
Type of application
Special properties (additional info)

FILE.CONTROL Entry
File suffixes available
Classification

Slide 27
Other Component of an Application
STANDARD.SELECTION Entry
Actual field names
Field properties


Insert File - I_ File
For programming


Files at database level to store data
To store data

Slide 28
Getting Started
DO NOT MODIFY the TEMPLATE subroutine in GLOBUS.BP

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




The above line must be modified to reflect <NEW APPNAME> as the
name of the subroutine

Properties of an application are defined here






jsh-->COPY FROM GLOBUS.BP TEMPLATE TO DBCARD.BP
jsh-->COPY FROM DBCARD.BP TEMPLATE, <NEW APPNAME>

Table Objects
Slide 29
Table.name = 'XX.TABLE.NAME' ;* Full application name
Table.title = 'XX TABLE.NAME' ;* Screen title
Table.stereotype = 'H' ;* H, U, L, W or T
Table.product = 'XX' ;* Must be on EB.PRODUCT
Table.subProduct = ' ;* Must be on EB.SUB.PRODUCT
Table.classification = 'INT' ;* As per FILE.CONTROL
Table.systemClearFile = 'Y' ;* As per FILE.CONTROL
Table.relatedFiles = '' ;* As per FILE.CONTROL
Table.isPostClosingFile = '' ;* As per FILE.CONTROL
Table.equatePrefix = 'XX.YY' ;* Use to create I_F.EB.LOG.PARAMETER
Table.idPrefix = '' ;* Used by EB.FORMAT.ID if set
Table.blockedFunctions = '' ;* Space delimited list of blocked
functions
Table.trigger = '' ;* Trigger field used for OPERATION style
How are the properties used?
The ID of the FILE.CONTROL ,PGM.FILE and SS entry - Table.name

The TYPE for the PGM.FILE record Table.stereotype

The SCREEN.TITLE in PGM.FILE record(Description) Table.title

The PRODUCT field in FILE.CONTROL and PGM.FILE
Table.product

The CLASSIFICATION field in FILE.CONTROL Table.classification

The prefix for all fields in the I_ files Table.equatePrefix

Functions that are not allowed for the application
Table.blockedFunctions

Slide 30
I_Table
Contains all common variables used in table object

Slide 31
COMMON/OBJECT.TEMPLATE/Table.fieldNeighbourArray(C$SYSDIM),Table.name,
Table.title,
Table.stereotype,
Table.product,
Table.subProduct,
Table.idPrefix,
Table.blockedFunctions,
Table.systemClearFile,
Table.relatedFiles,
Table.isPostClosingFile,
Table.equatePrefix,
Table.triggerField,
Table.classification,
Table.noInputFields,
Table.inputtableFields,
Table.lastApplication,
Table.idPrefix,
Table.blockedFunctions,
Table.systemClearFile,
Table.relatedFiles,
Table.isPostClosingFile,
Table.equatePrefix,
Table.triggerField,
Table.lastCompany,

Slide 32
How is TEMPLATE and THE.TEMPLATE related?
To launch an application, we type its name in the command prompt
It is validated VALIDATE.APPLICATION subroutine
Checks PGM.FILE

Calls RUN.APPLICATION which in turn calls
EB.EXECUTE.APPLICATION
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

EB.EXECUTE.APPLICATION also invokes THE.TEMPLATE



EB.EXECUTE.APPLICATION
Slide 33
SUBROUTINE EB.EXECUTE.APPLICATION(APPLICATION.NAME)
Table.name = ''
CALL @APPLICATION.NAME
IF Table.name THEN
CALL THE.TEMPLATE ;* We need to call the central template routine
END ELSE
Table.lastApplication = "" ;* We've called a non central template
END

Note: In releases before R9, EB.EXECUTE.APPLICATION called the <Application>
Subroutine which in turn called THE.TEMPLATE
THE.TEMPLATE Subroutine
The core subroutine used by every application in T24 since it contains
the execution flow

An applications business logic is broken up into individual subroutines,
called method.

THE.TEMPLATE contains code to call or invoke these methods at the
right time

Slide 34
Slide 35
Methods in Template Programming
The business logic of an application is not part of TEMPLATE or
THE.TEMPLATE

It is split up into methods

There are 11 methods available for use

THE.TEMPLATE determines the order of execution

Methods are nothing but individual subroutines called from
THE.TEMPLATE

Must follow naming convention APPNAME.METHODNAME


Methods
Where are method names defined?

Are they hard coded?
Slide 36
Slide 37
I_METHODS.AND.PROPERTIES
Common variable to define method names

Methods with different names ignored
Slide 38
I_METHODS.AND.PROPERTIES
T24s convention is to represent each position C_ROUTINES array by
a name not a number










Slide 39
Methods in Template Programming
INITIALISE
FIELDS
FUNCTION
ID
RECORD
VALIDATE
PREVIEW
OVERRIDES
PROCESS
AUTHORISE
RUN

This is also the order in which they are executed by THE.TEMPLATE
Slide 40
THE.TEMPLATE
Pattern of Execution of an application

MUST NOT BE MODIFIED

Advantage of having THE.TEMPLATE
We can maintain code consistency and code standard
Enables rapid code development, no need to start from scratch





Slide 41
Behind the Scenes THE.TEMPLATE
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.

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



Slide 42
Behind the Scenes THE.TEMPLATE
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 43
Behind the Scenes THE.TEMPLATE
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, 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 44
Using the Template Methods Common Variables Available
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)

ID
Special editing to the ID entered, special validations to the ID (ID.NEW)

RECORD
Editing of the requested record before display to the user (R.NEW,
R.NEW.LAST,R.OLD)
Slide 45
Using the Template Methods
The methods listed here are executed after Commit is clicked

VALIDATE
Special validation of data
R.NEW, R.NEW.LAST, R.OLD, E, Subroutine ERR

OVERRIDES
Overrides if any, must be raised here
R.NEW, R.NEW.LAST, R.OLD, ETEXT, Subroutine STORE.OVERRIDE

PROCESS
Processing that has to be done before the record is written to the $NAU file
Limits
Accounting
Charges
Slide 46
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 47
T Array
Dimensioned array that holds information about
Data type
List of possible values
NOINPUT / NOCHANGE characteristics
Justification
HOT.FIELD, HOT.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> = 10015000 will display all numbers from 1001 to
5000





Slide 48
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

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 Left justified, no need to specify T(FieldPosition)<5>
Right justified (R) and center justified (C ) are the other 2 options




Slide 49
T Array

T(FieldPosition)<6> - MACHINE to default to machine date instead of
T24 date
Used in the USER application

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> - HOT.FIELD/HOT.VALIDATE/WEB.VALIDATE
HOT.FIELD causes field to be validated immediately
HOT.VALIDATE causes all fields to be validated
WEB.VALIDATE triggers validation at web server level



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 50
I_Datatypes
Slide 51
EQU T24_String TO 'T24.STRING'
EQU T24_BigString TO 'T24.BIG.STRING'
EQU T24_Text TO 'T24.TEXT'
EQU T24_TextWide TO 'T24.TEXT.WIDE'
EQU T24_Numeric TO 'T24.NUMERIC'
EQU T24_Date TO 'T24.DATE'
EQU T24_Portfolio TO 'T24.PORTFOLIO'
EQU T24_Account TO 'T24.ACCOUNT'
EQU T24_InternalAccount TO 'T24.INTERNAL.ACCOUNT'
EQU T24_Customer TO 'T24.CUSTOMER'
EQU T24_Frequency TO 'T24.FREQUENCY

EQU Field_Mandatory TO ',mandatory'
EQU Field_NoInput TO ',NOINPUT'
EQU Field_NoChange TO ',NOCHANGE'
EQU Field_Unique TO ',UNIQUE'
EQU Field_NoNulls TO ',NONULLS'
EQU Field_AllowNegative TO ',ALLOW.NEGATIVE'

COMMON/DataTypeCommon/DataType.list,
DataType.nArrays,
DataType.tArrays,
DataType.checkFiles


TableUtil.loadFieldTypes
THE.TEMPLATE invokes TableUtil.loadFieldTypes which loads the id,
length and type depending on the basic data types





DataType.list is a common variable in I_Datatypes, which holds the list
of data types

The values populated by this subroutine are session specific
Slide 52
IF NOT(DataType.list) THEN
CALL TableUtil.loadFieldTypes
END

TableUtil.loadFieldTypes
Loads each of the basic data types as given below
Slide 53
SUBROUTINE TableUtil.loadFieldTypes
id = "T24.STRING"
length = 35
type = "A"
file = ''
GOSUB addBasicType

addBasicType:
typePos +=1
DataType.list<typePos> = id
DataType.nArrays<typePos> = length
DataType.tArrays<typePos> = LOWER(type)
DataType.checkFiles<typePos> = file
RETURN

Field Definitions






Field Definitions
Slide 54
Slide 55
Defining Fields APIs
T24 supports a number of APIs are used to define fields.

These APIs internally update the F, N and T arrays.



Slide 56
Table.defineId
Defines the ID field

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

Table.defineId(idName, dataType)

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

The data type of the key can either be

A standard data type defined in I_Datatypes in DataType.list

Populate data type with values corresponding to N and T arrays


Slide 57
Table.defineIdProperties
Defines the ID field

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

Table.defineIdProperties(idName, dataType)

Table.defineId invokes this API to define the fields.



SUBROUTINE EB.DEBIT.CARD.PARAMETER.FIELDS
dataType = ''
dataType<2> = 16.1
dataType<3> = ''
dataType<3,2> = 'SYSTEM'
CALL Table.defineId("DB.PARAMETER.ID",dataType)
Slide 58
Table.addField
Adds a field with standard data types

Table.addField(fieldName, fieldType, args, neighbour)

It takes 4 parameters, where,
fieldName - The name of the field to add. The "F" array 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 Table.addField("XX.LL.DESCRIPTION",T24_String,,)
Slide 59
Table.addFieldDefinition
Adds a field using the F, N and T definitions

Table.addFieldDefinition(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 Table.addFieldDefinition("XX.LL.DESCRIPTION",35,A,)
Slide 60
Table.processArgs
Processes the arguments passed to Table.addField API

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

Table.processArgs(args, nArrayItem, tArrayItem)

It takes 3 parameters, where,
args the list of arguments passed to Table.addField.
nArrayItem - The N array item to process
tArrayItem - The T array item to process



Slide 61
Field.setAttributes
Sets the N and T array

Field.setAttributes(fieldLength, fieldType, neighbour)

It takes 3 parameters, where,
fieldLength : The N array item
fieldType : The T array item
neighbour : Reserved for future use

Table.addField and Table.addFieldDefinition use this API to set the N
and T arrays based on the parameters passed on to them



Slide 62
Table.addFieldWithEbLookup
Add a field with a virtual table

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

Table.addFieldWithEbLookup(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 EB.LOOKUP
Application.
neighbour - Reserved for future use
Slide 63
Adds a field with a virtual table.

Performs the same functionality as Table.addFieldWithebLookup,
except that the list of options are configurable.

Table.addVirtualTableField(fieldName, tableName, args, neighbour)

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 EB.LOOKUP
Application.
args - (optional) Any additional arguments (mandatory, no input, etc.)
neighbour - Reserved for future use



Table.addVirtualTableField
Slide 64



Sets the default value for the current field









Field.setDefault
CALL Table.addField("START.DATE",T24_Date,Field_NoInput,'')
CALL Field.setDefault(TODAY) ;* Assign default value
Slide 65
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 66
Adds a check file to a field

Turns tableName(argument to Field.setCheckFile) into a checkfile
argument using the default enrichment field (DEFAULT.ENRICH field)
set on standard selection or the 1
st
field.




For the field Customer, whatever is entered in validated against the
CUSTOMER application.

This routine internally assigns.
CHECKFILE(currentFieldPosition) = tableName : FM :
enrichmenentField



Field.setCheckFile
CALL Table.addField("CUSTOMER",T24_Customer,Field_Mandatory,'')
CALL Field.setCheckFile("CUSTOMER")
Slide 67
Adds amount field to the application

Table.addAmountField(fieldName, currencyFieldName,args, neighbour)

It takes 4 parameters, where,



fieldName - The name of the field to add. The "F" array item
currencyFieldName Name of the field that holds the currency the field is held
in.
args Any additional arguments (mandatory, no input, etc.)
neighbour Reserved for future use




Table.addAmountField
CALL Table.addAmountField("MAX.WITHDRAWAL.AMT",'CURRENCY','',' ')
Slide 68
Adds a field with pre-defined set of options

Table.addOptionsField(fieldName, options, args, neighbour)

It takes 4 parameters, where,
fieldName - The name of the field to add. The "F" array 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.



Table.addOptionsField
CALL Table.addOptionsField("WITHDRAW.SWIPE","S_W",'','')
Slide 69
Adds a simple field that holds the value YES or blank

Table.addYesNoField(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



Table.addYesNoField
Slide 70
API to set a number of fields to be NOINPUT, NOCHANGE or
inputtable

Table.setAttributeOnFields(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 through each field in fieldList and sets the atribute in the third
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.





Table.setAttributeOnFields
Slide 71
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








Table.addReservedField
CALL Table.addField("RESERVED.1", T24_String, Field_NoInput,"")
CALL Table.addReservedField(RESERVED.1)

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

The name of this field should be DELIVERY.REF

Delivery Reference fields can be added in 2 ways







It can be multi valued to hold delivery references for multiple parties
involved
Table.addDeliveryReferenceField
CALL Table.addField(XX.DELIVERY.REF", T24_String, Field_NoInput,"")
CALL Table.addDeliveryReferenceField(neighbour)

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

The name of this field should be LOCAL.REF

Local reference fields can be added in 2 ways








Table.addLocalReferenceField
CALL Table.addField(XX.LOCAL.REF", T24_String, Field_NoInput,"")
CALL Table.addLocalReferenceField(neighbour)

Slide 74
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 STMT.NOS

Statement Numbers field can be added in 2 ways








Table.addStatementNumbersField
CALL Table.addField(XX.STMT.NOS", T24_String, Field_NoInput,"")
CALL Table.addStatementNumbersField(neighbour)

Slide 75
All applications MUST have a field to store overrides

Override fields can be added in 2 ways

















Table.addOverrideField
CALL Table.addField(XX.OVERRIDE", T24_String, Field_NoInput,"")
CALL Table.addOverrideField

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 76
How to create additional components?
No, EB.DEV.HELPER will do it for us..

Slide 77
Slide 78
EB.DEV.HELPER
Workfile Application to create
PGM.FILE entry
FILE.CONTROL entry
I_ File(insert file in BP)
STANDARD.SELECTION
Create files at Database level
Create DAS routines discussed later on

Record ID is Application Name

Verify record

Say Y to all questions asked
When to create which additional component?
If static properties have changed
Rebuild PGM.FILE, FILE.CONTROL, 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 79
Workshop
Run EB.DEV.HELPER and create additional components for all the
applications created relating to DEBIT CARD


Slide 80