SEAT Foundation Creating and Executing Scripts– R18 1

At the end of this session you will be able to

• State what is Testing
• Difference between Test Scenario and Test Case
• What is a script?
• What is a check?
• Important SEAT applications
• Creating scripts
• Executing Scripts

SEAT Foundation Creating and Executing Scripts– R18 2

 SE product in T24 consists of several applications. We will discuss six major SEAT
applications in this course.

SEAT.SCRIPTS- used to create transactions in T24 for e.g. create a CUSTOMER, LD

contract. SEAT.SCRIPTS can also be used to run enquiry in T24.
SEAT.RESULTS: to check the status of the transaction. Was the record created
successfully in T24? Was the record not created because of an ERROR? Does the
record contain the expected values in the different fields.
SEAT.SCRIPT.FIELD.VALUES: is used to specify the field names(along with the
multivalue, subvalue position) and the expected value in the field. For e.g. Is the
value in the field BILL.DATE:1:1 20091227
SEAT.SCRIPT.RESULT.FILES: when creating the field values, we specify only the field
name and its expected value. How will SEAT know from which file, which record has
to be considered for this check? When should this check be performed? After
CUSTOMER is created? After ACCOUNT is created? These questions are answered in
the RESULT.FILES
SEAT.SCRIPT.ACTIVITY: SSA contains information about all the scripts that make up a
test case
SEAT.SCRIPT.FORMAT.OUTPUT – Used when we want to check the results from an

SEAT Foundation Creating and Executing Scripts– R18 3

 enquiry. For e.g. is the CUSTOMER ID displayed on line 2 column 32 of the report.

SEAT Foundation Creating and Executing Scripts– R18 3

 Transactions/records are created in T24 using the SEAT.SCRIPTS(abbreviation
SST). The script ID is 21 characters and made of 2 parts separated by a
hyphen. The first part is the test case id. The second part (after the hyphen) is
called the sequence number.

SCRPTYYJJJVVXXXXX – NNN
YY Year – two digits of the current year. For e.g. 18 from 2018
JJJ Julian Date. The Julian date is the number of elapsed days from Jan 1.
Jan 31 is Julian day 31 and Feb 1 is Julian day 32. December 31 is Julian day
365.
VV Vertical Code (CORPORATE – 05 RETAIL -03 BFW 01). All teams in
Temenos are given codes so that the script created by the teams can be
identified easily and also the scripts created by members of different teams
on the same day should not overwrite each others’ scripts.
XXXXX Script Number (Running numbers). Every member within a team
will be given running sequence numbers so that scripts created by different
members will be unique
NNN Sequence Number (TPR Number). Sequence number starts with 001.

SEAT Foundation Creating and Executing Scripts– R18 4

 For e.g. if your sequence number within retail team is 00343, the script id for the
script created on Jan 7, 2018 will be SCRPT1800700343-001

SEAT Foundation Creating and Executing Scripts– R18 4

 A script represents a single transaction
What information is needed when a transaction is input in T24?

SEAT Foundation Creating and Executing Scripts– R18 5

 The above screenshot shows some fields from SEAT.SCRIPTS. We can see that
the data that we enter when creating a transaction is captured in the script

SEAT Foundation Creating and Executing Scripts– R18 6

 DESCRIPTION : meaningful Description of the test case
COMPANY CODE: In which COMPANY is this record being created? We can have multi
company set up in T24. this field specifies the company in which the transaction should be
created.
SCRIPT.STATUS: must be active if script should be considered for execution. Scripts can be
made Obsolete or put on hold if required.
SCRIPT.SOURCE: why was this script created? Give Defect.Id or SI for which this script was
created
SELECT.ROUTINE: To attach a sub-routine to modify a TXN.ID of SEAT.SCRIPTS. The routine
should have a record in PGM.FILE with type as ‘S’ . This routine will be called either with an
input of SCRIPT.ID in the field TXN.ID or with a Transaction reference or even without a
TXN.ID. It will read the Original script ID and return an output of TRANSACTION.ID from the
Script record being read.
BASE.RELEASE: Which release of T24 is this script meant to be executed in? could be R17,
201704. A script can also be executed in multiple releases. This feature will be discussed
when we discuss SEAT.SCRIPT.ACTIVITY
PRODUCT.GROUP: Which team owns this script?. We can select a value from the drop
down.
APPLICATION: Transaction should be created in which T24 application?

SEAT Foundation Creating and Executing Scripts– R18 7

 STATIC SETUP: We can have different set up in t24 like single company, multi
company, trade dated, value dated etc. Choose appropriate value from dropdown.
Note: This field is mandatory if results must be updated.

SEAT Foundation Creating and Executing Scripts– R18 7

 VERSION: Which version of the application is used to create the transaction.
In Regression area, <APPLICATION>,SEAT (single authoriser version) and
<APPLICATION>,SEAT.ZERO (zero auth version) are available
FUNCTION: What function is being performed? Functions like I,A,R,D,V,H can
be specified. Combination like IA, ID, RA, HA are also allowed
TXN.ID: Can be hard coded or soft coded. Can be left blank for applications
like FT, LD where ID is auto generated
FIELD.NAME: Name of the field along with Multi value and Sub Value
position. MV and SV will be defaulted as 1:1 in SEAT.SCRIPTS
FIELD.VALUE: Value for the field
FIELD.INPUT: Yes or No. Only fields with FIELD.INPUT = YES are considered
when transaction is performed

SEAT Foundation Creating and Executing Scripts– R18 8

 Scripts can be created automatically by using a existing record.ID
Scripts can also be created manually

SEAT Foundation Creating and Executing Scripts– R18 9

 Existing Record ID( Unauthorised , Live, IHLD status) can be used to create the
script automatically. Enter the record id in the TXN.ID field of SST. Tab out of
the field and validate. The values from the existing record will be populated in
FIELD.NAME and FIELD.VALUE. The record id that was entered in TXN.ID field
will be blanked off. The field names and values can be retained or modified as
required.

Set the FIELD.INPUT as YES for the required fields. Only fields with
FIELD.INPUT=YES will be considered when the transaction is created. Remove
the fields that are not required.(i.e. don’t leave fields with the FIELD.INPUT as
blank)

TIP: we can create a record in INAU status using the T24 Browser and use this
feature to create script automatically. As the record is still unauthorised, the
script can be run to create the record in T24.

Note: this feature cannot be used for AA as multiple applications are involved.
Can be used for applications like CUSTOMER, FT, ACCOUNT, LD etc.

SEAT Foundation Creating and Executing Scripts– R18 10

 The above screenshot on the left shows that existing CUSTOMER.ID has been
entered in the TXN.ID field of SST. When we tab out of the field and validate,
the FIELD.NAME and FIELD.VALUE from the record are populated
automatically in the SCRIPT.

SEAT Foundation Creating and Executing Scripts– R18 11

 After entering the record ID in the TXN.ID field, tab out and validate. The
TXN.ID will be blanked off and the field names and field values from the
record will be populated in the script. Remember to modify the values as
required and also enter the TXN.ID if needed for the test case.

SEAT Foundation Creating and Executing Scripts– R18 12

 The script can also be created by specifying the required field names(along
with the MV, SV position) and the values. Note : Multivalue and Subvalue
position will be defaulted as :1:1 if not specified in FIELD.NAME

In the screenshot above, the ACCOUNT record is created by specifying the

required fields CUSTOMER, CURRENCY and CATEGORY

SEAT Foundation Creating and Executing Scripts– R18 13

 OP.CONSOLE field in SPF must be set to TEST.
SEAT.RESULTS will be captured only if OP.CONSOLE is set to TEST

SEAT Foundation Creating and Executing Scripts– R18 14

 Launch the TAFJ shell. To execute the script, we must give the command tRun
tSS SEAT. TAFJ commands are executed from the command line using tRun. tSS
is a program like tSA and tSM. SEAT is a record.ID in an application called
OFS.SOURCE. Using the values from the script, an OFS message is generated
to create the transaction in T24.

The SCRIPT.ID~Function is given to execute the script. ID of previously run

scripts can be recalled using up arrow key and modified to run subsequent
scripts

An OFS response will be displayed. Response starts with the record ID(the
value given in the field TXN.ID of SST followed by slash(/) followed by script ID
followed by a 1. The 1 indicates that the transaction is created successfully. -1
(Minus one) means the record is not created because of some ERROR

SEAT Foundation Creating and Executing Scripts– R18 15

 SEAT.RESULTS record is created when a script is run. ID of the record is
SCRIPT.ID-Function. Example SCRPT170030300373-001-I.
OVERALL.RESULT– Result of all tests done by all the test routines . 0-Success,
Any value not equal to 0 indicates Failure
RESULT - Result of individual test done by each SEAT routine. 0-succes, Any
value not equal to 0 indicates Failure
UPLOAD.STATUS – Processed means record created in T24. Error means
record is not created in T24.
CONTRACT.ID - the record.id of the record that was created by the script. The
TXN.ID is not given when some scripts are created and we will have to refer to
the CONTRACT.ID in SEAT.RESULTS to find the ID of the record that was
created.

We will be discussing linked scripts later in this session and SEAT uses the
record from SEAT.RESULTS when working with Linked scripts.

SEAT Foundation Creating and Executing Scripts– R18 16

 Execute the following command to resolve SEAT.RESULTS Record exits error.

DBTOOLS -s -u t24user -p Temenos_123 JQL CLEAR-FILE F.SEAT.RESULTS. The

user is created by the startup script. We can also use TUserMgnt –Add option
to create users for DBTOOLS.

Alternatively, we can execute the command delete f_seat_results where recid

= 'SCRPT180010312345-001-I'; from the SQL prompt

SEAT Foundation Creating and Executing Scripts– R18 17

 OFS remembers messages that have been executed to prevent accidental
running of same messages again. If we execute the script again,
DUPLICATE.TRAP error will be raised. To resolve this, we have to first create a
user using the tAdduser command

tadduser -u temenos -p Temenos@123

We can then use the DBTOOLS to clear the file F.OFS.UNIQUE.MSG.REF.

DBTOOLS -s -u t24user -p Temenos_123 JQL CLEAR-FILE

F.OFS.UNIQUE.MSG.REF

DBTOOLS is a TAFJ tool used to interact with the database.

-s - is used to run the DBTOOLS in script mode. That is execute a command
without launching the DBTOOLS interface
-u and –p - are used to give the user credentials
JQL – to give a JQL (jBase Query language) command
CLEAR-FILE – will remove all records from the file

SEAT Foundation Creating and Executing Scripts– R18 18

 F.OFS.UNIQUE.MSG.REF - file name

SEAT Foundation Creating and Executing Scripts– R18 18

 1. Create a Script to input CUSTOMER with ID 99999. (Hint use existing
Customer 900002 to create the script)
2. Create another script to authorise the CUSTOMER created in Step 1
3. Run the scripts and view SEAT.RESULTS record

SEAT Foundation Creating and Executing Scripts– R18 19

 We can also create scripts which we know should result in error in T24 and
such record should not be created. This is called Negative testing. For eg, a
CUSTOMER record cannot be created without MNEMONIC, USER.ID and
SIGN.ON.NAME should not be the same, PRINT.1 record in DE.ADDRESS
cannot be reversed. We must specify the appropriate values in FIELD.NAME
and FIELD.VALUE and set GENERATE.ERROR as Yes. The actual error message
that will be displayed must be given in DEFINE.ERROR. The format for giving
DEFINE.ERROR is error message*Function. The comparison is case sensitive
and hence the message must be given in the same case as it will be displayed
in the Browser. A part of the message can also be given. SEAT will check if the
message in DEFINE.ERROR is a part of the error that is actually raised in T24.

SEAT Foundation Creating and Executing Scripts– R18 20

 The screenshot on the left shows the error that will be raised when USER.ID
and SIGN.ON.NAME are same.

Screenshot on right shows script for creating USER with ID and

SIGN.ON.NAME as TEST.USER. Generate Error is set as Yes. The error message
SAME AS ID*I is given in DEFINE.ERROR.

SEAT Foundation Creating and Executing Scripts– R18 21

 The script is run and we can see -1(minus one) in the OFS response. This
means record is not created. The error message is also displayed in the
response. Overall result in SEAT.RESULTS is zero as the expected error has
occurred. The OFS for SEAT is configured such that error records will be
written to Unauthorised file in IHLD status.

SEAT Foundation Creating and Executing Scripts– R18 22

 Comparison is case sensitive. The Overall result is 1 in SEAT.RESULTS as the
defined error Same as ID is not found in the actual error raised by T24.

SEAT Foundation Creating and Executing Scripts– R18 23

 When giving DEFINE.ERROR, we can also specify a part of the actual error that
will be raised. We cannot use …(three dots) to specify partial match

SEAT Foundation Creating and Executing Scripts– R18 24

 When GENERATE.ERROR in script is NO and UPLOAD.STATUS is ERROR
(transaction not created in T24), THE Overall Result is 1. if Upload status is
PROCESSED (Transaction is created in T24), Overall result 0 means all checks
passed successfully or a positive number for e.g. 2 means 2 checks have not
passed.

When GENERATE.ERROR in script is YES and UPLOAD.STATUS is ERROR

(transaction not created in T24), THE Overall Result is 0 as error was expected
and error has occurred.

When GENERATE.ERROR in script is YES and UPLOAD.STATUS is PROCESSED

(transaction created in T24), THE Overall Result is -1. This is a serious problem
as the transaction should not have been created.

SEAT Foundation Creating and Executing Scripts– R18 25

 1. Create CUSTOMER script for customer with ID 921921 and give
MNEMONIC as 921AFW. Use DEFINE.ERROR
2. View and understand SEAT.RESULTS.

SEAT Foundation Creating and Executing Scripts– R18 26

 The validate option in the browser is used to default values into fields and also
check if the values for the different fields have been provided correctly. The
Val option can be used to check if values in related fields is defaulted correctly.
Val does not create the record in T24.

SEAT Foundation Creating and Executing Scripts– R18 27

 Many times record(s) can be created in other related applications. For e.g.
when we authorise a CUSTOMER record, record(s) will be created in
DE.ADDRESS. When we authorise FUNDS.TRANSFER, record(s) can be created
in DE.O.HEADER. If the test case requires the manipulation of records that are
created in other application(s) we can use the above three fields.

SEAT Foundation Creating and Executing Scripts– R18 28

 In the above screen shot, we can see two scripts to create a CUSTOMER and
modify the DE.ADDRESS record that is created when CUSTOMER is authorised.
The UPDATE.APPL is given as DE.ADDRESS(we want THE id of the DE.ADDRESS
record to be the TXN.ID of the script given in UPDATE.SCRIPT)

SEAT Foundation Creating and Executing Scripts– R18 29

 Sometimes, the ID of the record created will be stored in a field. For e.g. the
ID of the DE.O.HEADER records created on authorisation of the FT will be
stored in the DELIVERY.OUTREF field. The DELIVERY.OUTREF:1:1 will be
populated as the TXN.ID of the script given in UPDATE.SCRIPT.ID

SEAT Foundation Creating and Executing Scripts– R18 30

 Transactions are created with the profile of SEAT.USER and authorized using
the profile of SEAT.AUTH. If the transaction must be created using the profile
of a specific user, mention this in the USER field. For e.g. TELLER transactions
can be executed only the appropriate TELLER who is assigned a TILL and the
TILL must also be open.

SEAT Foundation Creating and Executing Scripts– R18 31

 When a script is run, an OFS message is formed from the values specified in
the script. If such OFS message is available, the name of the file can be given
in MSG.FROM.FILE field. For e.g. the incoming SWIFT messages. The
FIELD.NAME, FIELD.VALUES in such script will be left blank as it will be
available in the file. Some mandatory fields like APPLICATION, VERSION have
to be filled

MSG.FROM.FILE – the messages can be seen in the folder MSG.IN or

MSG.IN.<RELEASE>.ST01 under TAFJ/UD or the directory pointed to by
temn.tafj.directory.current

Sample Message to create an ACCOUNT.

ACCOUNT,/I/PROCESS//0,SUSER1/ofcMN+xO8ecGqdax9H0OUtJ2WalNppt11v
YiM76heuE=,,CUSTOMER=900001,CURRENCY=USD,CATEGORY=1001

TPR.FILE.NAME – is populated based on the sequence number of the

SCRIPT.ID. The tpr can be modified to run the script in an earlier tpr if there is
no dependency.

SEAT Foundation Creating and Executing Scripts– R18 32

 Details of every transaction is also recorded in the application
OFS.REQUEST.DETAIL (ORD)
ID of the ORD record is SCRIPT.ID-tpr~FUNCTION

The OFS.REQUEST as well as the response are also recorded in

OFS.REQUEST.DETAIL

SEAT Foundation Creating and Executing Scripts– R18 33

 The Script IDs can be used in another script to create linked scripts
A new FUNDS.TRANSFER transaction can be input and kept in INAU status.
Another script can be created to authorise the FT. The TXN.ID
of the SEAT.SCRIPTS record to authorise the FT should be given as
<SCRIPT.ID>*@ID (SCRIPT.ID is the ID of the script that created the
FT)SEAT has the intelligence to identify the Linked Scripts and its TXN.ID or
FIELD.NAME, if the value given in TXN.ID or FIELD.VALUE starts
with SCRPT

SEAT Foundation Creating and Executing Scripts– R18 34

 The TXN.ID in scripts can be hard coded, soft coded or left blank. CUSTOMER
and ACCOUNT ID are usually hard coded. If ACCOUNT IDs are generated
automatically, the ACCOUNT.ID can be different every time the script is run. It
will then be difficult to identify a recurring error using the ACCOUNT.ID.
Hence, ACCOUNT.ID is hard coded so that we can easily identify recurring
issues.

SEAT Foundation Creating and Executing Scripts– R18 35

 The TXN.ID/FIELD.VALUE can also be soft-coded as SCRIPT.ID*@ID. Transaction id
is fetched from another SCRIPT which was executed successfully.
SEAT.RESULTS must be available for LINKED SCRIPTS to work

SEAT Foundation Creating and Executing Scripts– R18 36

 We have seen how linked scripts can be created using SCRIPT.ID*@ID. The
same can be extended to any field from the record created by earlier script.
The format is SCRIPT.ID*FIELD.NAME:X:Y. The multi value, sub value position
must be specified even if it is :1:1. Remember there is no MV, SV for the @ID
field, hence it is not required when we use SCRIPT.ID*@ID

SEAT Foundation Creating and Executing Scripts– R18 37

 We can prefix or suffix (but not both) a string to the @ID or the value in
FIELD.NAME using the # symbol. For eg in T24, the ID of a PD(Past Dues record
– created when the CUSTOMER does not repay the LD on time) is PD followed
by the LD ID. This feature is used in above script where TXN.ID is given as
PD#SCRIPT.ID*@ID. The script is the script that created the LD record, hence
*@ID will give the LD ID.

SEAT Foundation Creating and Executing Scripts– R18 38

 SCRIPT.GROUP is an important field in SEAT.SCRIPTS and is used to sequence
the scripts during regression. For e.g. if we want to check repayments on an
arrangement with weekly schedule, the script to create the arrangement can
be run in TB02. the bill will be raised only in Day 4 COB, hence the script for
repayment must be a Day 5 script. For e.g. the script to create CUSTOMER
cannot be in TB02 if the script to create account for the same customer is in
TB01. In single upload, we are running the scripts manually and the account
will be created, but the scripts will be sequenced based on SCRIPT.GROUP
group during regression and hence the account creation script will fail

SEAT Foundation Creating and Executing Scripts– R18 39

 In a fresh series, create the following scripts
1. Script to Create CUSTOMER with ID 777888
2. Script to create ACCOUNT for the CUSTOMER created in step 1.
ACCOUNT.ID 10077788801
3. Script to create another ACCOUNT for the CUSTOMER created in Step 1.
ACCOUNT.ID 10077788802
4. FT to transfer $100 from account created in 2 above to account created
in 3 above
Note : Use LINKED script for all questions given above
Give SCRIPT.GROUP as TB01
Understand the records created in SEAT.RESULTS

SEAT Foundation Creating and Executing Scripts– R18 40

 We now know how to
Create scripts
Execute Scripts
Understand SEAT.RESULTS
Work with Linked Scripts
Use SCRIPT.GROUP in the script

SEAT Foundation Creating and Executing Scripts– R18 41