TSDK Implementation Guide
TSDK Implementation Guide
TSDK Implementation Guide
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.
T24 Software Development Kit – Implementation Guide
Table of Content
How To…................................................................................................................................................. 3
How to Write a TSDK T24 Server Side API......................................................................................... 3
Overview .......................................................................................................................................... 3
Creating and Packaging the T24 server class ................................................................................. 5
Package and deploy the class ......................................................................................................... 5
Set up the EB.API record for the new class ..................................................................................... 5
How to Write a TSDK Web Server Side API........................................................................................ 6
Overview .......................................................................................................................................... 6
Create the Web Validation Class ..................................................................................................... 6
Package and deploy the class ......................................................................................................... 8
Set up the EB.API record for the new class ..................................................................................... 8
Set up the Web Validate field on the version ................................................................................... 8
Examples ............................................................................................................................................... 10
Server side APIs ................................................................................................................................ 10
Example 1 ...................................................................................................................................... 10
Example 2 ...................................................................................................................................... 11
Web Server APIs ............................................................................................................................... 13
Example 1 ...................................................................................................................................... 13
How To…
How to Write a TSDK T24 Server Side API
Overview
The following outlines the steps involved in setting up TSDK server side API’s
• Create the T24 server application class (WS.CREATE)
• Package and deploy the class (WS.CREATE)
• Set up the EB.API record for the new class
• Configure API hook to use EB.API
In order to run the Web Validation Java class the class must implement the interface
“com.temenos.t24browser.validation.Validator”. The interface is part of the T24Browser.jar
The interface specifies that the class should implement the following method:
• public ValidationResponse runRoutine(T24Common t24Common, T24Routines
t24Routines)throws FieldException;
The class should have no constructor - a blank one will get created automatically.
The method runroutine passes in a t24Common containing all of the fields displayed on the current
contract, and a t24Routines representation of the field that initiated the web validate. The method
returns a ValidationResponse, which will contain any TProperties that have been altered and
subsequently added to it in order to update the contract.
The following steps should be taken when developing a Validation class:
• The class needs to import the following classes:
o import com.temenos.tdsk.foundation.t24Common;
o import com.temenos.tdsk.foundation.TProperty;
o import com.temenos.tdsk.fx.TCustomer; //specific to any contracts that you need
o import com.temenos.tdsk.validation.ValidationResponse;
• The class can be called anything, but must implement the interface T24Api. Validate has one
method that passes in a T24Common and a T24Routines. The method finally returns a
ValidationResponse that will contain a list of all the properties (field data changes and errors
and messages) needed for update of the contract on display.
• On entering the method, runRoutine, the developer should create a new Contract class
specific to the contract being run. E.g.:
o When running the version CUSTOMER,SAM the class TCustomer should be created.
The class will take one parameter in its constructor – the TContract passed into the
method ‘runRoutine’.
o This will take all of the TProperties from the passed in TContract and add it to the
TForex class.
The global instance variable TCustomer customer should be instantiated.
The class should then be created in the method
• forexContract = new TForex(contract);
method processRequest. The ValidationResponse also hold any errors or messages that
have been reported during the validation.
• The TProperty that is passed into the method processRequest will contain the information
about the field that initiated the validation request. The following methods can be used to
access it:
o getName() – the name of the field
o getValue() - the value of the field
o getMulti() - the multiValue
o getSub() - the sub value
• When a field is to be changed for addition to the ValidationResponse, the developer should
retrieve the relevant TProperty from the newly created TContract. There are two possible
ways of retrieving this from the TContract
o TProperty cusProp = customer.getMnemonic();
o TProperty customer = customer.getProperty(“MNEMONIC”);
• Any changes to be made to this field are made via this TProperty reference:
o cusProp.setEnrich("enrichment")
o cusProp.setError("field error")
• If later in the code this field is to be altered again, then just re-run the previous three steps.
Due to the fact that java passes objects by reference, the updated field in the Validation
response will now point to the same object that the TContract points to. So, if one is updated,
then both will be updated.
• If a general error, or message needs to be added, then it is done via the following methods on
the ValidationResponse class:
o response.addMessage("This is a message");
o response.addError("This is an error");
• If a field specific error is generated, then the following method can be called to set the
TProperty:
o cusProp.setError(“the error”);
• The Enrichment of the field can also be set via a similar method:
o cusProp.setEnri(“the enrichment”);
NB Enrichments set via the “setEnri” method will only be visible if the field ENRICHM.CHAR has been
set in the VERSION record.
The class should have no constructor - a blank one will get created automatically.
The method processRequest passes in a TContract containing all of the fields displayed on the
current contract, a TProperty representation of the field that initiated the web validate, and a
T24Connection which allows communication to the T24 server (currently only used for CHECKFILE
enrichments processing). The method returns a ValidationResponse, which will contain any
TProperties that have been altered and subsequently added to it in order to update the contract.
The following steps should be taken when developing a Validation class:
• The class needs to import the following classes:
o import com.temenos.tdsk.foundation.TContract;
o import com.temenos.tdsk.foundation.TProperty;
o import com.temenos.tdsk.fx.TForex; //specific to any contracts that you need
o import com.temenos.tdsk.validation.Validator;
o import com.temenos.tdsk.validation.ValidationResponse;
• The class can be called anything, but must implement the interface Validator. Validator has
one method that passes in a TContract, a TProperty and a T24Connection. The method
finally returns a ValidationResponse that will contain a list of all the properties (field data
changes and errors and messages) needed for update of the contract on display.
• On entering the method, processRequest, the developer should create a new Contract class
specific to the contract being run. E.g.:
o When running the version FOREX,SPOTBUY, the class TForex should be created.
The class will take one parameter in its constructor – the TContract passed into the
method ‘processRequest’.
o This will take all of the TProperties from the passed in TContract and add it to the
TForex class.
The global instance variable TForex forexContract should be instantiated.
The class should then be created in the method processRequest
• forexContract = new TForex(contract);
• The TProperty that is passed into the method processRequest will contain the information
about the field that initiated the validation request. The following methods can be used to
access it:
o getName() – the name of the field
o getValue() - the value of the field
o getMulti() - the multiValue
o getSub() - the sub value
• When a field is to be changed for addition to the ValidationResponse, the developer should
retrieve the relevant TProperty from the newly created TContract. There are two possible
ways of retrieving this from the TContract
o TProperty counterParty = forexContract.getCounterparty();
o TProperty counterParty = forexContract.getProperty(“COUNTERPARTY”);
• Any changes to be made to this field are made via this TProperty reference:
o counterParty.setValue("USD")
o counterParty.setEnrich("enrichment")
o counterParty.setError("field error")
• If later in the code this field is to be altered again, then just re-run the previous three steps.
Due to the fact that java passes objects by reference, the updated field in the Validation
response will now point to the same object that the TContract points to. So, if one is updated,
then both will be updated.
• If a general error, or message needs to be added, then it is done via the following methods on
the ValidationResponse class:
o response.addMessage("This is a message");
o response.addError("This is an error");
• If a field specific error is generated, then the following method can be called to set the
TProperty:
o counterParty.setError(“the error”);
• The Enrichment of the field can also be set via a similar method:
o counterParty.setEnri(“the enrichment”);
NB Enrichments set via the “setEnri” method will only be visible if the field ENRICHM.CHAR has been
set in the VERSION record.
A version can only have one linked Validation class. The class is linked to the version via the field
‘Web Val Rtn’. The name of the EB.API record set up for the Validation class should be referenced
here. See the figure below.
Examples
Server side APIs
Example 1
The following code outlines a possible example for a Server Validation class:
package com.temenos.tsdk.examples;
import com.temenos.tsdk.T24Api;
import com.temenos.tsdk.T24Routines;
import com.temenos.tsdk.core.TCurrency;
import com.temenos.tsdk.foundation.T24Common;
import com.temenos.tsdk.foundation.TProperty;
import com.temenos.tsdk.fx.TForex;
import com.temenos.tsdk.validation.ValidationResponse;
/**
* This function will examine the value entered into the CURRENCY.BOUGHT
* field and default the COUNTERPARTY field based on the value.
*
* If the currency Bought is USD then the COUNTERPARTY is set to
* 100063 (CHASENY) if it is GBP then the COUNTERPARTY is set to
* 100073 (BARCUK).
*
* To get this example to work you must add the following record to the EB.API
* file on the T24 database you wish to use.
*
* DESCRIPTION....... Defaults the Forex Counterparty
* PROTECTION.LEVEL.. NONE
* SOURCE.TYPE....... JAVA
* JAVA.METHOD.......
* JAVA.CLASS........ ForexDefaultAccounts
* JAVA.PACKAGE...... com.temenos.tsdk.examples
*
* The important fields here are the SOURCE.TYPE which tells T24 to
* run this API as a java routine and then the JAVA.PACKAGE that tells
* T24 which java package to find this in and JAVA.CLASS which tell it
* which class to run
*
* Then you need to set the name of the record you created in a FOREX
* version in the VALIDATION.RTN field with an '@' in front of the EB.API
* record name and the corresponding VALIDATION.FLD set to CURRENCY.BOUGHT
*/
public class ForexDefaultAccounts implements T24Api
{
// First we get the value that has just been entered in the
// T24 contract. This is obtained as a java string by calling
// the method getUserInput from the T24Common object
String currencyBought = t24Common.getUserInput();
}
else if(currencyBought.equals("GBP"))
{
// The currency is GBP, set the counterparty to BARCUK, which
// customer number 100073
forex.setCounterparty("100073");
}
}
else
{
// The currency is not one we can default, so set the counterparty
// to be blank
forex.setCounterparty("");
}
return myResponse;
}
}
Example 2
This example (or series of code snippets will highlight the way a server validation is written, and used.
This will highlight the use of the foundation classes and error setting. IT will also demonstrate the use
of Logging facilities that can be used when implementing and running TSDK server validation. These
will also highlight the ability to go to the T24 Server BASIC and back to Java code as well as setting
EText (Error object)
package com.temenos.tsdk.examples;
import com.temenos.tsdk.T24Api;
import com.temenos.tsdk.ac.TAccount;
import com.temenos.tsdk.core.TCustomer;
import com.temenos.tsdk.exception.ETextException;
import com.temenos.tsdk.exception.FieldException;
import com.temenos.tsdk.foundation.T24Common;
import com.temenos.tsdk.foundation.TProperty;
import com.temenos.tsdk.routines.FileHandling;
import com.temenos.tsdk.routines.T24Routines;
import com.temenos.tsdk.validation.ValidationResponse;
/**
* @author Temenos
* An example showing how a validation routine calls the T24 Routines to read a record,
* and set the value of the Account Title of a new ACCOUNT to the ShortName of the customer
*/
public class AccountValidation implements T24Api
{
/**
* Takes in a TContract containing all of the fields on the current
* contract. Also passes in the TProperty - field - containing the
* information about the field that initiated the validation response
*
* @param t24Common T24Common
* @param t24Routines T24Routines
*
* @return ValidationResponse
*
* @see com.temenos.tsdk.T24Connection#runRoutine(T24Common t24Common,
*T24Routines t24Routines)
*/
public ValidationResponse runRoutine(T24Common t24Common, T24Routines t24Routines)
throws FieldException
{
//First we get the current record, what is in R.NEW. to get
// this we call the getCurrentRecord method of the t24 object.
// This returns the current record as a TContract object. We then cast
//Set the value of Account Title 1 with the ShortName you get
//from Customer Record
tAccountTitle1.setValue(sShortName);
return myResponse;
}
}
import com.temenos.tsdk.foundation.T24Connection;
import com.temenos.tsdk.foundation.TContract;
import com.temenos.tsdk.foundation.TProperty;
import com.temenos.tsdk.fx.TForex;
import com.temenos.tsdk.exception.ValidationException;
import com.temenos.tsdk.validation.ValidationResponse;
import com.temenos.tsdk.validation.Validator;
import com.temenos.tsdk.validation.CurrencyValidator;
public ForexValidator()
{
/**
* Takes in a TContract containing all of the fields on the current contract.
* Also passes in the TProperty - field - containing the information about the
* field that initiated the validation response
* @param TContract contract
* @param TProperty field
*
* @return ValidationResponse
*/
public ValidationResponse processRequest(TContract contract, TProperty field,
T24Connection connection)
{
if (field.getName().equals("COUNTERPARTY"))
{
validateCounterparty();
}
else if (
(field.getName().equals("CURRENCY.BOUGHT"))
|| (field.getName().equals("CURRENCY.SOLD"))
|| (field.getName().equals("BROKERAGE.CCY")))
{
validateCurrency(field);
}
return response;
}
if (cpValue.equals("100069"))
{
cpProp.setEnrichment("DAO HENG BANK INC");
currencyProp.setValue("JPY");
currencyProp.setEnrichment(CurrencyValidator.getCurrencyName("JPY"));
}
else if (cpValue.equals("100070"))
{
cpProp.setEnrichment("DBLA MIAMI");
currencyProp.setValue("USD");
currencyProp.setEnrichment(CurrencyValidator.getCurrencyName("USD"));
}
else if (cpValue.equals("100071"))
{
cpProp.setEnrichment("DEVCOM MERCHANT BANK LIMITED");
currencyProp.setValue("GBP");
currencyProp.setEnrichment(CurrencyValidator.getCurrencyName("GBP"));
}
else
{
cpProp.setError("Missing Customer Record");
cpProp.setEnrichment("");
}
/**
*
* Validate
*
* @param TProperty currency
*/
private void validateCurrency(TProperty currency)
{
// extract the required fields from the forexContract
TProperty currencyProp = forexContract.getProperty(currency.getName());
try
{
CurrencyValidator cv = new CurrencyValidator(currency.getValue());
currencyProp.setEnrichment(cv.getCurrencyName(currency.getValue()));
}
catch (ValidationException ve)
{
currencyProp.setError(ve.getMessage());
currencyProp.setEnrichment("");
}
The following figure represents a version that has been set up to run Web Validation:
With regard to the above figure, three fields have been assigned to be Web Validate fields:
o Couterparty (This field also contains an auto-launch enquiry)
o Ccy Bought
o Ccy Sold
On entering a value and tabbing out of either of these fields, the window will automatically send a Web
Validate request to the web server while still displaying the contract for the user to continue editing.
The web server will then create a TContract class and populate it with all of the fields on the displayed
contract. The field that triggered the request will also be stored as a TProperty. Both of these classes
will then be passed into the Validation class.
The Validation class will build up a list of all the fields that are to be changed on the displayed contract,
and pass them back to the contract. This will result in one of the following:
On entering an invalid Counterparty field the Validation class sets an error against the field, which is
displayed in the side menu. This would also be the case for any general errors set against the
Validation Response instead of the individual field. Any messages displayed would be displayed
under the “Messages” header.