1- Browser Screen Versions

TEMENOS T24 Browser Screen Versions

User Guide

Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV. Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Browser Screen Versions

Table of Contents Introduction.............................................................................................................................................. 3 Application Overview ........................................................................................................................... 3 Tabbed Screens................................................................................................................................... 4 Opening a tabbed screen ................................................................................................................. 4 Traversing tabbed screens - Enquiry to Enquiry.............................................................................. 7 Traversing tabbed screens - Enquiry to Transaction ....................................................................... 9 Traversing tabbed screens – Transaction to Transaction.............................................................. 10 Scenario 1 TXN – ENQ .................................................................................................................. 11 Tabbed screens – Enquiry command line invocation .................................................................... 11 Tabbed Screens - Transaction command line version invocation ................................................. 13 Composite Screens............................................................................................................................ 15 EB.COMPOSITE.SCREEN ............................................................................................................ 15 Hyperlinks....................................................................................................................................... 19 Custom Field Buttons......................................................................................................................... 20 !CURRENT.XXXX.............................................................................................................................. 21 !CURRENT.XXXX variables........................................................................................................... 21 EB.External.User............................................................................................................................ 23 RE-KEY.............................................................................................................................................. 24

TEMENOS T24 User Guide

Page 2 of 27


Introduction Application Overview VERSION is a standard T24 application, which allows users to create customised screens for input, authorisation, display etc. It may also be used to automate the replacement of data on records.

It will be rare for any client to use the standard (main) screen input for all T24 applications. In fact T24 comes with many useful VERSION records for the majority of T24 applications. You are encouraged to copy these and amend them to suit your requirements. Do not amend the originals because changes may be issued in future releases.

It is also possible to add local sub-routines, which can be used for field, input and authorisation validation. These small programs will allow even greater customisation of T24 by the user.

All T24 trading applications are capable of supporting more than one product, e.g. LD.LOANS.AND.DEPOSITS supports loans, deposits, commitments etc. It also supports a wide variation of options e.g. discounts, maturity, liquidation, rollovers and schedules to highlight a few. In order to support this functionality the main LD contract has two hundred fields. Although all the fields are necessary only a few are needed for the input or maintenance of a particular contract type. Version allows you to create screens, which reflect each contract type, presenting only the necessary fields and defaulting data into other fields.

Each version you define is referenced by the name of the application and the name of the version separated by a “,”. For example, an LD version for inputting call deposits could have an id of LD.LOANS.AND.DEPOSITS, CALLDEP. To ‘run’ the VERSION simply enter the application name with the version reference.

SMS control can be defined specifically for the version by entering the name of the version, with the comma, in USER in the field VERSION. Consequently you can restrict access to the contract types as well as the application itself. The creation of VERSION records can be divided into three main categories; input of the header or title; the fields required for input or display; and the defaults to be pre-filled when using that specific VERSION.

When defining the screen for a version, multi-valued fields should not be placed horizontally in one row i.e. + Field1 |____________| + Field2 |____________| Technically it is possible to do this as it is technically impossible to stop this from happening but when a screen is defined in the above mentioned manner then the user might experience screen alignment problems as well as multi-value expansion/deletion problems.


Page 3 of 27


Tabbed Screens Opening a tabbed screen A tabbed screen enables the Browser to display a series of Enquiries and Versions together, on the same screen.

Figure 1 - Tabbed Screen •

Each of the individual Enquiries and versions are displayed on individual tabs.

•

Each tab is completely independent; only one tab may be active at any given time.

•

Switching to another tab will lose all input to the previous tab.

•

Tabbed screens are defined in the table EB.TABBED.SCREEN. In this example three tabs have been defined: an enquiry and two versions.

•

Whether the tab is to EB.TS.CONTENT.TYPE: o

ENQ – Enquiry

o

TXN – Transaction

be

an

enquiry

or

a

version

is

determined

in

the

field

•

The name that will appear on the tab is entered in the field EB.TS.TAB.TITLE.

•

The actual enquiry, or version, to be run is entered in the field EB.TS.SOURCE.

•

It is possible to link selection criteria, such that once the selection criteria has been set, subsequent tabs can display the enquiry data without the need for the selection criteria to be entered again. If there is no matching selection criteria defined in the EB.TABBED.SCREEN, then the selection criteria will be displayed.


Page 4 of 27


•

The mapping between tabs is made possible via the fields EB.TS.SELECT.FROM and EB.TS.SELECT.TO. The field you want to extract the data from goes in the former, and the field you want to add the data to goes in the latter.

•

The rules on which tabs the actual mapping comes from, is determined by the type of tabs involved in the process. These rules are covered in the proceeding sections.

Figure 2 - EB.TABBED.SCREEN record •

A tabbed screen is invoked from the command line by typing in the command ‘TAB’, followed by the key to the EB.TABBED.SCREEN.


Page 5 of 27


Figure 3 - Calling a tabbed screen from the command line •

The above command will then display all of the tabs laid out in the EB.TABBED.SCREEN record ‘TEST6’.

•

If the first tab on the tabbed screen is an enquiry, then it will present the Enquiry Selection screen. This will only happen on initial display. On subsequent visits to this tab, the enquiry selection criteria, if there is any, will be run.

•

If the first tab is a version then it will be run as is.


Page 6 of 27


Traversing tabbed screens - Enquiry to Enquiry •

All Enquiry mapping will refer to the first enquiry on the tabbed screen, regardless of the designation of the last tab.

•

In Figure 4, if the Enquiry ‘Account Balance’ tab is selected then it will use the fields referred to in the EB.TS.SELECT.FROM field – in this case ACCOUNT – and attempt to map it to the field in the EB.TS.SELECT.TO field. It will use the first enquiry on the tabbed screen to perform the mapping. The first enquiry in this case is ‘Statement Entries’

•

EB.TS.SELECT.FROM and EB.TS.SELECT.TO is multi valued, so more than one field can be put forward for mapping.

•

If the mapping is successful then it will bring back the results of the enquiry.

Figure 4 - Enquiry to Enquiry mapping


Page 7 of 27


Figure 5 - Statement Entries result page

Figure 6 - Account Balance result page based on ACCOUNT mapping from 1st Enquiry


Page 8 of 27


Traversing tabbed screens - Enquiry to Transaction •

When a user traverses from an enquiry to a transaction tab, the version will look for the field specified in its EB.TS.SELECT.FROM field to use as the key to that version.

Figure 7 - Enquiry to transaction mapping •

This field will then be used to interrogate the F.ENQUIRY.SELECT record for the first enquiry on the tabbed screen. On finding the field in the F.ENQUIRY.SELECT record, it will then use this value as its key.

•

In this example, the third multi value is a TXN that has specified that it will look for the field CUSTOMER MNEMONIC.

•

When the Customer Record tab is clicked, the server will attempt to find the field CUSTOMER.MNEMONIC from the first enquiry – ACCOUNT-LIST. It will then attempt to use this as the key to the CUSTOMER record.


Page 9 of 27


Figure 8 - Customer record mapped from Enquiry Selection

Traversing tabbed screens – Transaction to Transaction •

When a version tab is selected, if the previous tab was a version with a valid key, then the new version will attempt to use this key to invoke the new version.

•

The second transaction is set up to look for the field CUSTOMER.MNEMONIC. The following rules apply:

•

o

On selecting this tab, if the previous tab was a version with a valid key, then it will use this as the key to the new version tab.

o

If a version tab had been navigated to with a valid key, then that key will be stored on the client page for future use. When selecting the second version, if there is a stored key, then it will attempt to open up the version with that key.

This will override the Enquiry to Transaction rule. If an enquiry were to be run with a different Customer ID, then the stored key on the client would take precedence.


Page 10 of 27


Figure 9 - Transaction to Transaction mapping

Scenario 1 TXN – ENQ •

Enquiry mapping will always refer to the first enquiry

Tabbed screens – Enquiry command line invocation •

Running an enquiry with parameters via the command line. o

The user can specify the actual tab number of the enquiry to run, along with the selection criteria.


Page 11 of 27


Figure 10 - Running a tabbed enquiry from the command line, with specified selection criteria •

The above example will open the tabbed screen ‘TEST2’.

•

It will run the enquiry on the first screen with the selection criteria: o

•

CUSTOMER.MNEMONIC EQ DBL

See below, for the resultant enquiry screen.


Page 12 of 27


Figure 11 - Command line enquiry result on tabbed screen

Tabbed Screens - Transaction command line version invocation •

The key to a specific tabbed version can be supplied via the command line.

Figure 12 - Running a specific tabbed version from the command line with specified key


Page 13 of 27


Figure 13 - Version invoked from command line •

In the above example, the third tab is invoked using the key “DBL”.

•

If the version on the tabbed screen already has a key specified in the EB.TABBED.SCREEN record, then this will take precedence i.e. the hard coded key will be used instead of DBL.

Figure 14 - An example of overriding a command line version key request


Page 14 of 27


In the above example, if the second tab is invoked from the command line with the key DBL, then the key 100060 will take precedence.

Composite Screens A Composite screen is a collection of screens in T24 placed in one browser window, but in different frames. The individual frames can be set to accept requests for certain enquiries or transactions enabling multiple contract screens and enquiry screens to be utilised without obscuring one another. Individual screens within a composite screen can also be set to contain T24 menus, Tabbed Screens URLs or other content created through utility routines as well as creating a whole new set of composite screens.

Composite screens are defined in the T24 application EB.COMPOSITE.SCREEN and can be invoked using the command COS which can be run through menus, toolbars and on the T24 command line.

EB.COMPOSITE.SCREEN The Composite screen application EB.COMPOSITE.SCREEN is used to define composite screens. This application comprises of a title for the composite screen and a large linked multi value set for defining the contents of each frame and makeup of the frames of the composite screen. The multi value is made up of the following fields: •

CONTENT.TYPE: This field states what the item you are trying to define is. it can be one of the following values: o

OPEN.FRAME: Create a frame set. Tells you are splitting this frame into further frames.

o

CLOSE.FRAME : Closes the frameset.

o

ENQ : This item is an Enquiry.

o

TXN : This item is a contract screen.

o

UTILITY: This allows you to call a browser routine. Not sure on the entire scope of this.

o

TAB : This item is a tabbed screen.

o

COS : This item is a composite screen.

o

MENU : This item is a menu.

o

URL : This item is a URL.

o

BLANK : This item starts blank.

The value of this field then defines what the rest of the item will require: •

BORDER.SIZE: This field defines what the border of the frame set will be. Only used for Open Frame

•

COLS: This defines the number and width of the columns. It is done in the same format as the frameset tag in html. For reference and instructions on this see http://www.w3schools.com/html/html_frames.asp. For a given OPEN.FRAME item you must have either the ROWS or the COLS field set. You cannot however have both.

•

ROWS: As Cols, but used to specify rows.


Page 15 of 27


•

NAME: Gives a name for the Frame. All content defining items (i.e. telling you what is in a frame) must have a name.

•

SCROLLING: This defines whether the frame is going to allow scrolling. Can only be entered with content defining items.

•

CONTENT: This is a multi purpose field that defines the content of the frame. Either a URL, the name of an Application and version, an enquiry etc. Also used to define the name of the utility to be called.

•

CONTENT.ARGS: If a UTILITY type is set then this will define the args for the called utility will be defined here.

•

ITEMS: This sub-valued field is used to define what requests should be sent to this frame. It can be specific requests of application and version or enquiry, or it can be set to take all unassigned enquiries by setting it to ENQ or all unassigned requests by setting it as ALL. Furthermore it can be set to take everything except enquiries by setting it to NOENQ. The request is assigned to a window by running through each item until a valid match is found for the request. If none are found a new window is launched.

NOTE: By default when using Composite Screens, enquiry drilldowns will be opened in a new window. To send an enquiry drilldown to a specific Composite Screen frame, set the ITEMS field to be the drilldown option number (e.g. “1” for the first drilldown, “2” for the second drilldown, etc.).


Page 16 of 27


The structure of a composite screen would be to create a frame set using the OPEN.FRAME type. Then the next items would be the frame contents from left to right or top to bottom. The contents of a frame can be another OPENFRAME item which will create a new frameset within that frame. The next items would then relate to the frames in that frame set. Once all the items in that frame have been defined then the CLOSE.FRAME item is added. This will cause the current frameset to close. If the current frameset was embedded within a frame then the next item definition will return to the previous frameset, unless it is at the top level at which point the composite screen definition is closed.

The content type and defined content of a content item is only defines the starting content of the item. If the frame has any values defined in its ITEMS field then the content will be overwritten by any requests that match those items.

Figure 15 - Composite Screen


Page 17 of 27


Figure 16 - Customer Summary


Page 18 of 27


Hyperlinks T24 Browser provides the facility to attach custom links and buttons to a Version. This is achieved by using the HYPERLINK field on the VERSION application. Please refer to the “Browser Toolbars” user guide for more information.


Page 19 of 27


Custom Field Buttons T24 Browser provides the facility to attach custom buttons to fields on a Version. Please refer to the “Browser Toolbars” user guide for more information.


Page 20 of 27


!CURRENT.XXXX !CURRENT.XXXX variables In addition to the system common variables that can be used in ENQUIRY and VERSION there is a feature where users can populate a variable of their own and use it later. There are also a series of new system variables and a much wider option for users to create and use their own. User set variables CURRENT.XXXX where XXXX can be any value that you feel is applicable, the important part for the system to recognise them is the 'CURRENT.' prefix. The same use is made of these in ENQUIRY & VERSION. Setting them is done by using them without the ! prefix and reading the content by using the ! prefix. The variables can be set with values from an existing Enquiry field or with a literal value Example: CURRENT.NAME>SHORT.NAME CURRENT.TEXT>"Hello Everyone" CURRENT.CCYS>[USD][GBP][JPY]

populates the variable with the content of SHORT.NAME field from the Enquiry populates the variable with the simple text "Hello Everyone" populates the variable with a list of values

Then use them in ENQUIRY in the selection field or predefined selection. TEST.DATE EQ !TODAY TEST.NAME EQ !CURRENT.NAME TEST.TEXT EQ !CURRENT.TEXT TEST.CCYS EQ !CURRENT.CCYS Creation of a !CURRENT.TEST1

Figure 17 Creation of Enquiry called CURRENT.TEST1


Page 21 of 27


Linking this enquiry previous enquiry

to

Figure 18 Creating a second enquiry. When this enquiry is run, the system will search for !CURRENT.TEST1 variable, (highlighted) set by the running of the first enquiry, and display the results. These can be set to VERSION too. AUTOM.FIELD.NO = DEBIT.THEIR.REF AUT.NEW.CONTENT = !CURRENT.TEXT

This field should be populated with your !CURRENT enquiry

Figure 19 Above shows how the VERSION record fields should be populated using the new variable data. Note: You can set the Enquiry to drill down to both another Enquiry and a Version on the one screen.


Page 22 of 27


To view the content of any CURRENT.xxxx variables there is an ENQUIRY called USER.VARIABLES which displays the current content. Note: The values of user set variables are empty at initial login and cleared on exit so this Enquiry will only display values set during the current login session.

Figure 20 Showing variables set after running variety of enquiries

EB.External.User These are set on login by an external user and cleared when they logout. This means that ENQUIRY & VERSION can be tailored to accept the content of the variable instead of forcing a user to enter their own customer number or arrangement etc. For example instead of having a selection criteria for an Enquiry like "CUSTOMER.NO EQ 123456" the same Enquiry can use a pre-selection of "CUSTOMER.NO EQ !CURRENT.CUSTOMER". The standard convention of using the variable is to prefix it with an exclamation mark i.e !CURRENT.CUSTOMER. Similarly in VERSION you can now default a field content by using the! CURRENT.CUSTOMER to populate a customer field with the current content of the variable. So the variable could be set in one Enquiry and used in either another Enquiry linked to it; or via VERSION to populate fields in an application triggered from the Enquiry. !CURRENT.CUSTOMER (Customer number) ! CURRENT.EXTERNAL.USER (Mnemonic) !CURRENT.ARRANGEMENT (Arrangement number)


Page 23 of 27


RE-KEY Rekey is the option to force the authoriser to rekey an input value before authorisation can be completed, typically rekeying an amount on a payment as an independent check of the deal. Configuration of fields to be rekeyed at authorisation is achieved through VERSION by specifying the required fields on REKEY.FIELDS field. The option to limit the number of rekey attempts by an authoriser is set in the field EB.REKEY.RETRIES in the SPF. The rekey functionality is invoked at authorisation time based on the VERSION the authoriser is using, the VERSION used at input time has no impact on the process.

Figure 21 Creating version with Rekey field as SECTOR and No.of.Auth as 1.


Page 24 of 27


Figure 22 Creating a new customer record with rekey fields SECTOR.


Page 25 of 27


Figure 23 Upon authorising the deal, re-key is prompted.


Page 26 of 27


Figure 24 Deliberately entering the incorrect sector produces the rekey field to display in red.


Page 27 of 27

1- Browser Screen Versions

Recommend Documents