TEMENOS T24. Application Development. User Guide

Pages 34
Views 25
of 34
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Description
TEMENOS T24 Application Development 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
Transcript
TEMENOS T24 Application Development 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 2008 TEMENOS Holdings NV. All rights reserved. Table of Contents Overview... 3 Creating an Application... 4 Naming... 4 Step 1 - Defining the Application... 4 Step 2 - Define the Fields (.FIELDS)... 7 Step 3 Artefact Creation using EB.DEV.HELPER Step 4 Adding Business Logic to the Application Step 5 Creating the Data Access Service Other Considerations The Infrastructure Introduction Screen Management Data Entry Functions Security Management Validation Main File Maintenance History Maintenance Transaction Journaling and System Recovery Audit Trail Close of Business Processing Appendices Appendix 1 - Glossary Appendix 2 - Development Artefacts Appendix 3 - Program Flow Appendix 4 Older Templates TEMENOS T24 User Guide Page 2 of 34 Overview This document explains how to develop applications in T24. T24 has an extensive infrastructure in place that enables the rapid development of business components. The creation and maintenance of T24 applications is based on a series of templates, which have had numerous incarnations throughout the life of T24. Now in its fourth iteration, this document details how applications are created in a step by step process. For an understanding of the genesis of the templates, refer to the appendix Older Templates. This document does not explain the process of the previous release of the templates refer to Template Programming V3. T24 is based on a one to one relationship between the data fields on the screen and the data fields in a file. The only way to enter data into T24 is via an APPLICATION which records the data entered and stores it in an associated file, field by field. There are the following stereotypes: Application allows the full functionality of T24: data entry, authorisation, deletion, history restore, etc. e.g. CUSTOMER Display is used to simply view the data on a file maintained by the system rather than the user e.g. STMT.ENTRY Utility allows data entry and a Verification function which initiates a process, e.g. ENQUIRY.REPORT which records the selection criteria for an enquiry and then on Verification builds a report and spools it. TEMENOS T24 User Guide Page 3 of 34 Creating an Application Naming The name of the application must be meaningful, should give some indication as to its purpose and should be prefixed by the product code of the application, where the product code should exist on EB.PRODUCT e.g. CR.CAMPAIGN.DEFINITION, PW.ACTIVITY, etc. Note: The file name cannot exceed 40 characters, to allow for the addition of the company mnemonic and the $NAU or $HIS suffix. Step 1 - Defining the Application Having decided on the product and name of the application, the first step is to define the high level properties of the application. The example TEMPLATE, which ships with each release of T24, holds the properties for the application. Whilst there is tooling support for the creation of new applications, this section explains the mechanics behind the GUI. Property Example Explanation name CR.CAMPAIGN.OPPORTUNITY Full application name including the product prefix. Must be the same as the application name title Campaign Opportunities Screen title stereotype H See Stereotypes product CR The product of the application. Must be an entry on EB.PRODUCT subproduct CAMPAIGN The sub product of the application. Must be an entry on EB.SUB.PRODUCT classification INT See Classifications systemclearfile Y Flag to indicate if the file should be cleared down when running the SYSTEM.CLEAR.FILES utility. Should be set to YES for any transient (i.e. financial) applications relatedfiles ispostclosingfile CUSTOMER CR.CAMPAIGN.DEFINITION A space delimited list of related files. Used in creating the data model Y or blank. Only required when the application is required for use by Post Closing. Normally this should be left blank. equateprefix CR.CD Used to create the insert for the application that contains the equated field names idprefix CRCD If set, invokes EB.FORMAT.ID to produce transaction reference style keys TEMENOS T24 User Guide Page 4 of 34 blockedfunctions triggerfield A space delimited list of functions that are not allowed on an application Used as the trigger field for operation processing. Refer to Operations. Below is the actual code showing the above settings: Table.name = 'CR.CAMPAIGN.OPPORTUNITY' Table.title = 'Campaign Opportunities' Table.stereotype = 'H' Table.product = 'CR' Table.subProduct = 'CAMPAIGN' Table.classification = 'INT' Table.systemClearFile = 'Y' Table.relatedFiles = 'CUSTOMER CR.CAMPAIGN.DEFINITION' Table.isPostClosingFile = '' Table.equatePrefix = 'CR.CO' * Table.idPrefix = 'CRCO' Table.blockedFunctions = '' Table.triggerField = '' Stereotypes There are three stereotypes to choose from depending on the type of application program: Type Application (H or U) Display (L) Utility (W) Description Used for all standard input programs to maintain a live, unauthorised and history file. This template is also used for type U programs that have a live and unauthorised file but do not have a history file. Used for the display of a 'non-inputtable / live file Used to allow standard input without an unauthorised file and the verify function to execute special procedures The stereotype of the application decides which files will be created and used. There are three files that may be created: 1. The main file is the live file or authorised file and has no suffix. 2. The unauthorised file is suffixed with $NAU and holds the record as input or changed before it has been authorised. 3. The history file is suffixed by $HIS and contains images of the record prior to each change. The user inputs or amends data in the unauthorised file. Another user must then view the data and authorise it at which point it is moved from the unauthorised file into the live file. The existing record in the live file is moved to the history file. The infrastructure handles all the reading and writing of these files. TEMENOS T24 User Guide Page 5 of 34 Classifications There are three primary classifications of application: Classification Details INT Installation - This covers files like COMPANY, USER, LANGUAGE, where only one version of the file will exist regardless of the number of companies CUS Customer - for files where the data can be shared between companies. Primarily static information and tables. FIN Financial - for files that hold financial level details (amounts, balances etc.) where the data cannot be shared with other companies. For further explanation and a full list of the classifications, refer to the FILE.CONTROL help text. Non Stop Processing Application may be NS enabled by setting the common variable C$NS.OPERATION. Value Meaning ALL Full Non Stop operation providing NS module is installed NEW new deals allowed in NS mode only providing NS module is installed NOD Nonstop input allowed with NS module (for apps like PGM.FILE, BATCH etc) no NS operation allowed If the application does not allow NS there is no need to specify it as null. This allows local developments to be non-stop if required. Further information on nonstop processing can be found in the nonstop processing user guide. TEMENOS T24 User Guide Page 6 of 34 Step 2 - Define the Fields (.FIELDS) Having defined the high level properties of the application, the next step is to define the fields that make up the application. Every application MUST have a corresponding field definitions subroutine. The name of this subroutine is the full name of the application with the suffix.fields, e.g. CR.CAMPAIGN.OPPORTUNITY.FIELDS. Your new.fields subroutine should be based on the TEMPLATE.FIELDS template that is shipped as part of the release. Once defined, save and compile your.fields subroutine. Standard APIs Table has the following methods to define the fields: Table.addField Add a field with standard data types Table.addFieldDefinition Add a field using F, N and T style Table.addFieldWithEbLookup Add a field with a virtual table Table.defineId Define the ID field Field.setCheckFile Add a check file to a field Table.setAuditPosistion Defines the last field position Refer to the object documentation for full details. Examples of usage are below, and can also be found in the TEMPLATE.FIELDS template routine: CALL Table.defineId( MESSAGE.ID , T24_String) CALL Table.addField( TO.DAO , T24_String, , ) CALL Table.addFieldDefinition( DISPL.APPLICATION , 1 , : FM : Y_ , ) CALL Field.setCheckFile( DEPT.ACCT.OFFICER ) CALL Table.addField( XX.MESSAGE , T24_Text,Field_Mandatory, ) CALL Table.addField( DATE.READ , T24_Date,Field_NoInput, ) CALL Table.addField( TO.CUSTOMER , T24_Customer, , ) CALL Table.setAuditPosition TEMENOS T24 User Guide Page 7 of 34 Field Settings Each field is defined by five settings 1. Field Names and Grouping 2. Field Length 3. Field Type 4. Check file There are also corresponding variables to define the parameters for the record id. The standard APIs hide the complexity of these items, but it is important to understand the underlying mechanism that is used in order to use the full flexibility of the field definitions. When defining the arrays you must use the incrementing variable, Z, to reference the element of the array. In this way fields can be added later without having to renumber all the other array assignments. The variable V is an important common variable used to hold the number of fields in the record and should be set to Z + 9 for input applications and Z for display only applications (where Z is the last field defined in the 'F' array). If the standard APIs have been used instead of direct array manipulation, this is achieved using the Table.setAuditPosition method. Field Names and Grouping The F array is a dimensioned array used to define the field name associated with each field and also specifies whether the field is a single value, multi-valued or sub-valued. The corresponding variable for the record id is ID.F. The record id must be single valued. NB the maximum size of the field name is 18 characters, which includes any multi-value definitions. Single valued fields Each element of the array is assigned the text string to be used on the screen to label the field. This can be up to 18 alphanumeric characters and must NOT include spaces. The first two characters cannot be 'XX' e.g. ID.F = 'CHARGE.CODE' F(Z) = 'CHARGE.TYPE' Multi-valued fields Any field (except the record id) can be multi-valued. They can be individual multi-valued fields; multivalued in association with a language code, or part of a group of fields whose multi-values are always in association with each other. Individual multi-valued fields are defined by setting their 'F' table element to 'XX.' followed by the field name, e.g. F(Z) = XX.NARRATIVE Language associated multi-values allow several translations of the value of the field to be held on the record, the appropriate multi-value being used according to the language code of the user. These are defined by setting the 'F' table element to 'XX.LL' followed by the field name, e.g. F(Z) = XX.LL.DESCRIPTION Multi Value Associated Fields Associated groups of multi-values are defined by setting the third character of the 'F' table to ' ' for the first field of the association, '-' for intermediate fields and ' ' for the last associated field. = 'XX CURRENCY' = 'XX-CHARGE.RATE' TEMENOS T24 User Guide Page 8 of 34 = 'XX-LOWER.LIMIT' = 'XX UPPER.LIMIT' Sub valued fields Any multi-valued field can be sub-valued. These can be defined individually or as associations on sub-values within each multi-value. Single valued fields or record ids cannot be sub-valued. Subvalues are defined in the same way as multi-values except characters 4 to 6 of the 'F' table elements are used instead of characters 1 to 3. = 'XX CURRENCY' = 'XX-XX CHARGE.RATE' = 'XX-XX-LOWER.LIMIT' = 'XX XX UPPER.LIMIT' TEMENOS T24 User Guide Page 9 of 34 Field Length The 'N' array is a dimensioned array that defines the maximum and minimum length of each field. The corresponding variable for the record id is ID.N. The element is assigned with three sub-fields separated by a. : Sub-field 1 This parameter defines the maximum length that will be allowed on input for the field or for each multivalue or sub-value if applicable, e.g. N(Z)= 35 This field can have a maximum of 35 characters If the number is prefixed by 0 (e.g. 035) then leading zeroes will not be removed. If it is prefixed by a leading space then spaces will not be trimmed; if it is not prefixed by a leading space, all leading, trailing and multiple spaces removed. Sub-field 2 This parameter defines the minimum length that will be allowed on input for the field or for each multivalue or sub-value if applicable. Null, space or zero defines that the field is optional. If the field is mandatory, this should be set to a value of 1 (as some languages assign significant meaning to one character, and putting an arbitrary length is pointless) Sub-field 3 Although this field is no longer used, the definition is included here for completeness. Older versions of the template defined a CHECK.FIELDS extension to do field level validation. However, with the move to a stateless architecture, this feature is irrelevant. Where this parameter is set to 'C' special editing as coded in the CHECK.FIELDS routine will be performed. Examples: '10' '10.1' Up to 10 characters allowed, no special editing will be done. Optional. Between 1 and 10 characters allowed, no special editing will be done. '006.6.C' Input must be 6 characters. Leading zeros will not be removed and the field will be subject to processing by the CHECK.FIELDS routine. 35..C' Up to 35 characters of input will be accepted, leading spaces, trailing spaces and duplicated embedded spaces will be removed. For example, the keyed input 'LLOYDS BANK PLC' will be edited to 'LLOYDS BANK PLC.' Null will be accepted and the input will be subject to FIELD.CHECKS. TEMENOS T24 User Guide Page 10 of 34 Field Type The 'T' array is a dimensioned array that defines additional editing to be carried out when data is input in the fields. The corresponding variable for the record id is ID.T. Each element consists of a dynamic array. The first field identifies the name of the routine to call to perform specific editing for on data input. Fields 3, 4 and 5 are used to define display masks, input restrictions and display justification respectively. The other fields define parameters, which are used in ways specific to the particular validation subroutine and are described later in this section. The use of Fields 1, 3, 4 and 5 are described here: Field 1 Routine Name Each routine is named 'IN2suffix'. This field contains 'suffix', and may be blank to invoke IN2. Below is a summary table of the so-called IN2 routines that are available in T24. For more complete details refer to the IN2 Routines User Guide. Type Account Number Alphabetic Alphanumeric Any character Amount Company Code Currency Code Customer Number Date Frequency Mnemonic Numeric Program Name Range Rate Security Specific Values Swift Characters Version Routine IN2ACC,IN2.ACCD,IN2ALL,IN2ANT,IN2INT IN2AAA,IN2SSS IN2A,IN2AA,IN2S,IN2SS IN2ANY IN2AMT IN2COM IN2CCY,IN2.CCYD IN2CUS IN2D,IN2.ACCD,IN2.CCYD,IN2.D,IN2YM,IN2.YM,IN2FQU IN2FQU IN2MME IN2, IN2R IN2PG,IN2PV IN2 IN2R IN2SEC IN2 IN2S,IN2SS,IN2SSS IN2PV TEMENOS T24 User Guide Page 11 of 34 Field 3 Defines input restrictions and can be any of the following values: Value Null NOINPUT NOCHANGE EXTERN Description Input will be accepted in all circumstances (subject to editing and security restrictions etc.). Input will never be allowed Input will not be allowed once the record has been authorised Input will never be allowed and the field will be cleared by the copy function Field 4 This field is used to define a mask for input and display editing. The format of the mask is generally as used by the BASIC function FMT. A special mask is used by routines that edit dates (see the section describing these particular IN2 routines). Field 5 Defines the display justification, Null = Left justified, R = Right justified. Field 7 Fields to be deleted when containing default figures after input of this field when more than one field defined VM = Field marker Field 8 Defines restrictions on multivalue fields. If used, the settings should be specified for the first field in the association and may be set to the following values: 'NOMODIFY' - No changes allowed to association 'NODELETE' - No deletion allowed to association 'NOEXPAND' - No expansion allowed to association Field 9 'Hot Field' properties for browser: 'HOT.FIELD' Check field validation will be performed on this field 'HOT.VALIDATE' Check field validation will be performed on ALL fields (equiv. to pressing browser 'Validate' button) TEMENOS T24 User Guide Page 12 of 34 Virtual Tables The concept of virtual tables has been added to prevent the growth in the number of simple tables that are shipped as part of T24 which serve only to provide a list of options that Temenos cannot hard code, e.g. statuses, titles, etc. Rather than create a new table for each of these, a virtual table can be defined. VIRTUAL.TABLE.LIST = '' VIRTUAL.TABLE.LIST = 'VIRTUAL.TABLE' CALL EB.LOOKUP.LIST(VIRTUAL.TABLE.LIST) The variable VIRTUAL.TABLE.LIST can then be used to directly populate the T array directly: T(Z) = VIRTUAL.TABLE.LIST ; * List from EB.LOOKUP The actual items for the virtual table are defined on one table, called EB.LOOKUP. The key to this table is VIRTUAL.TABLE.NAME*REAL.KEY, e.g. EB.STATUS*COMPLETE. The list populates the second field of the T array, such that a list of the available options is available to the user without need to use a dropdown. EB.LOOKUP contains additional fields in a name value pair structure that may be used to contain parameter information. Refer to the help text on EB.LOOKUP for more information. Operations Provision has been added to allow OPERATION style fields to be defined. The concept is that a trigger field is used to determine the action that is being performed, and depending upon that action certain fields in the application will be made available for input while others will become no input. This concept has existed in T24 applications for some time (e.g. in the LC and PD modules) and now support has been added to the template. Firstly, a field must be defined that holds the options, and should be named OPERATION Z+=1 ; F(Z) = OPERATION ; N(Z) = 35 ; T(Z) = ; T(Z) 2 = 'ACCEPT_REJECT' The property Table.Trigger is used to store which field will act as the trigger for the operation process, and should be set to the equated field name: Table.Trigger = MY.APP.OPERATION There are two further properties that are used to control which fields will be made available for input, and which fields will be set to no input. Each property takes a value mark (VM) delimited list of fields. ACCEPT.FIELDS.NOINPUT = MY.APP.REJECT.DATE : VM : MY.APP.REJECT.REASON REJECT.FIELDS.INPUT = MY.APP.REJECT.DATE : VM : MY.APP.REJECT.REASON accept = 1 reject = 2 Table.inputtableFields reject = REJECT.FIELDS.INPUT Table.noInputFields accept = ACCEPT.FIELDS.NOINPUT In the above example, the fields REJECT.DATE and REJECT.REASON will be no input when the ACCEPT operation is selected all other fields will behave as defined in the T array. When the REJECT operation is selected, only the REJECT.DATE and REJECT.REASON fields will be available for input all others will no input. If both properties are set for an operation, the C_NOINPUTS property is ignored. NB If we are processing a NOINPUTS list, then any field that is already defined as NOINPUT, NOCHANGE, etc. will retain that defini
Advertisements
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks