Вы находитесь на странице: 1из 29

ETP- T24 Common Variables – R17 1

ETP- T24 Common Variables – R17 2


You can observe that the information shown above is marked as function, application
name etc., These information are accessible by T24 programs.

ETP- T24 Common Variables – R17 3


There are pre-defined common variables in T24 using which such information from the
client browser. is made accessible to code on the server.

ETP- T24 Common Variables – R17 4


Let us understand how data is accessed / modified and validated in a T24 application.
When using applications in T24, we have noticed that many fields have data
validations. How does the code executing behind the scenes have access to what we
see on the screen? When the user enters an ID, how does the application access that
information? Common variables are used throughout T24 and Template programming
is no exception. Let us take a look at the vital common variables that are required to
create applications in T24.

ETP- T24 Common Variables – R17 5


Let us take a look at the important common variables that we must know when
creating applications in T24.

ID.NEW

ID.OLD

ID.NEW.LAST

R.NEW()

R.OLD()

R.NEW.LAST()

All the above mentioned common variables are defined in I_COMMON.

R.NEW, R.NEW.LAST AND R.OLD are three important common variables . When the
validate, commit or authorise button is clicked, these three variables are populated.
R.NEW is populated with the record on the screen. R.NEW.LAST is populated with
the corresponding record from $NAU table if available and R.OLD is populated with
the corresponding record from LIVE table if available. ID.NEW, ID.NEW.LAST,
ID.OLD contains the corresponding ID’s of the record (As is obvious the same ID is
stored in these three variables. The purpose of these three ID variables are discussed

ETP- T24 Common Variables – R17 6


later)

ETP- T24 Common Variables – R17 6


When a request for input is given to T24, For eg AC.DEBIT.CARD I 55, just before the
.RECORD method executes, RECORD.READ routine populates the COMMON
variables R.NEW, R.NEW.LAST & R.OLD with the record from the corresponding
tables(if available). The contents in R.NEW is then refreshed on the client browser and
these variables are cleared.
These COMMON Variables are re-initialised when the user clicks on validate or
commit or authorise on the form, and then the processing method is invoked.
In the scenario in the slide,
ID.NEW – contains ID of the Record that is currently being edited
R.NEW – is a dimensioned array that is populated with the debit card record from the
web-page on commit.
R.NEW takes the format of the underlying application. R.NEW is declared in
I_COMMON as R.NEW(C$SYSDIM), where C$SYSDIM is a common variable
equated to 500 in I_COMMON. 500 is sufficient as no T24 application has more than
500 fields. However a size of 500 is required as fields can be multivalued at runtime.
C$SYSDIM will have to be re-initialised when this arithmetic changes in the future.
Once the validation and other processing codes are executed, contents of R.NEW is
written to the $NAU file. In the above example R.NEW(1) refers to the first field of the
DEBIT CARD application and so on. Do not use field position, use the field name
instead. Eg.,R.NEW(AC.DEBIT.CARD.NO)

ETP- T24 Common Variables – R17 7


The DEBIT CARD record committed earlier is currently in the INAU status in the $NAU
table. This record is picked up and refreshed on the browser, when the user issues
the command AC.DEBIT.CARD A 55. Since this record has to be displayed on the
browser, R.NEW is populated with this record. The record is sent in the response to
the browser and the variables are refreshed.

On clicking the Authorise button, the following common variables are re-initialised

R.NEW contains the record from the web-page. After the execution of the processing
logic if any, R.NEW is written into the Live table.

If required, R.NEW can be manipulated programmatically before its written onto the
LIVE table. R.NEW.LAST is also a dimensioned array defined in I_COMMON as
R.NEW.LAST(C$SYSDIM). The ID corresponding to the record in this variable is
stored in ID.NEW.LAST, also a common variable defined in I_COMMON.

ETP- T24 Common Variables – R17 8


The current status of the DEBIT CARD record is LIVE. When this record is opened for
amendment in T24 and committed, the common variables that come into play are
ID.NEW, R.NEW and ID.OLD, R.OLD. R.NEW is populated with the amended record
from the web-page & R.OLD is populated with the LIVE record from the LIVE table.
Please note that the original Live record is in R.OLD and the amended record is in
R.NEW

R.OLD retains the record copy before the amendment. Contents of R.NEW(which
contain the amendments) are then written into the $NAU table. At this stage, the
previously authorized record is in LIVE and the amended record is in $NAU with an
INAU status.

(Amendment of an authorised record is possible only if the application allows it; some
contract based applications do not allow to edit an authorised record).

Note:- On authorization of an unauthorised record, the $NAU record is deleted and


written into Live file as represented in the previous slide. Since there is no record in
$NAU table, the common variable R.NEW.LAST will not get populated.

ETP- T24 Common Variables – R17 9


If the unauthorised record is opened for amendment(also called change on change),
R.NEW contains the record as it has been modified. R.NEW.LAST contains the
previous unauthorised copy of the record and R.OLD contains the LIVE record. On
commit, the contents of R.NEW is over-written on the existing record in the $NAU
table.

ETP- T24 Common Variables – R17 10


On authorizing an amendment to an already authorized record, R.NEW will be
populated with values from the record R.NEW.LAST will not be used for the A function
and the previously authorized Live record is populated in R.OLD. ID.NEW,
ID.NEW.LAST and ID.OLD contain the same record id. Contents of R.NEW is then
written to the Live table and R.OLD is written to $HIS table with id as
ID.OLD;<CurrNo> where CurrNo is the sequence no which keeps track of the current
version of the history record.

ETP- T24 Common Variables – R17 11


ETP- T24 Common Variables – R17 12
ETP- T24 Common Variables – R17 13
ETP- T24 Common Variables – R17 14
OPERATOR will be used for updating audit fields in a record. The common variable
OPERATOR holds the id of the active user in the current session. It is not possible to
get the list of users logged in the system.

The USER.ID of the current USER logged in to T24 and his user profile is loaded in
the common variable R.USER. R.USER is declared as a dynamic array in
I_COMMON. Every time T24 needs to perform an SMS check, instead of reading the
USER record, it refers to this variable. If the user has USER.SMS.GROUP attached,
the values of USER.SMS.GROUP is embedded in the appropriate fields in R.USER

ETP- T24 Common Variables – R17 15


R.COMPANY is a dimensioned array

ETP- T24 Common Variables – R17 16


R.SPF.SYSTEM – is a Dynamic array which stores the SPF SYSTEM record

ETP- T24 Common Variables – R17 17


ETP- T24 Common Variables – R17 18
1.When you input a record in any Application in T24 and On validation it can generate
Errors and Overrides

1.1 Error Messages: Such type of messages are displayed -

Due to data not being input in mandatory fields

Due to incorrect data input

Due to incorrect relationship between field name and the data that is input.

In case of Error Messages, you need to correct the data input in the particular fields
and commit the transaction again.

A record is not saved till all errors are corrected.

1.2 Override Messages: These are warning messages, at least most of the time. A
user may accept or reject override. If accepted, T24 saves the record and the override
message is stored as part of it in the field OVERRIDE. If you do not want to accept the
Override, you may either put the record on hold to correct it later or amend the record
and commit it again.

ETP- T24 Common Variables – R17 19


Its not advised to hard code error messages for two reasons – the same error
message may be required to be displayed in other applications and in the language
preference set by the bank. Hence create a record for the error message in
EB.ERROR and provide this ID in E as shown in the code snippet. You do not have to
explicitly call ERR as it is implicitly called in THE.TEMPLATE

The requirement is coded in .ID method

ETP- T24 Common Variables – R17 20


Notice the error variable used here is ETEXT instead of E and there is an explicit call
to STORE.END.ERROR. E is used to code for exceptions, in all methods that gets
invoked before the record is displayed to the user. ETEXT is an advanced error
variable which facilitates display of error messages beside the specific field which
raised the exception. AF in the code denotes the field position where the error
message must be displayed.

The requirement is coded in the .VALIDATE method.

ETP- T24 Common Variables – R17 21


When using Classic, error messages in T24 are displayed adjacent to the erroneous field. In
Browser, the error messages are displayed with the field numbers displayed as a link, clicking on
which takes the focus to the erroneous field. Errors can be trapped from anywhere in the life cycle
of a transaction. To display the errors adjacent to the appropriate field use AF, AV & AS.
To display an error message at
Field Number, Multivalue, Subvalue (e.g. 3.2.1). Set AF=3, AV=2 and AS=1.
AF denotes the field position where the error message must be displayed. AV is used for multi
value position and AS for sub value position.
All exceptions raised, appear as errors on the users screen for correction. T24 will proceed to the
next step only on correction of all these errors.

AF=AC.CLASS (AC.CLASS has been defined in the I_ file and refers to the field position of class.
Here it is 1
In the for loop AV is used as the loop counter so that we can check if all classes are in the correct
position. Value in pos 1 must be 1, value in pos 2 must be 2 and so on.
Explanation for R.NEW(AF)<1,AV> - R.NEW is a dimensioned array. Each dimension refers to field
in the table. AF has been set to 1, hence we are looking at the contents of R.NEW(1). We know
each dimension is actually a dynamic array. To refer to a value within a dynamic array we must give
the field position and also multi value position. When working with R.NEW field position is always 1
as each dimensioned array contains data about only one field only. The second subscript within <>
tells us which multi value we are referring to.
R.NEW(1)<1,1> is 1 and R.NEW(1)<1,2> is 3.
In the second iteration of the for loop AV is 2, AF is 1
R.NEW(1)<1,2> is 3 and AV is 2. As the values are not equal error gets displayed against the

ETP- T24 Common Variables – R17 22


incorrect value
Field 2 can be multi-valued and has a subvalue.

ETP- T24 Common Variables – R17 22


ETP- T24 Common Variables – R17 23
ETP- T24 Common Variables – R17 24
Note the usage of TEXT common variable, instead of E or ETEXT. And that, the
subroutine STORE.OVERRIDE(CURR.NO) is called for overrides. E, ETEXT and
TEXT are common variables defined in I_COMMON.

The given code is written in the .OVERRIDES method

ETP- T24 Common Variables – R17 25


CALL ERR is implicitly called by THE.TEMPLATE.

ETP- T24 Common Variables – R17 26


ETP- T24 Common Variables – R17 27

Вам также может понравиться