Temenos Connector 1x1z1n

OFS VERSION 2.0

/<>,<enquiry_name>

If the test is successful then the TCServer is ready to be deployed. To quit the test type: “exit”.

Installing TCServer.jar and dependencies The jar File and a Setup.sh (or Setup.bat), should be copied to any desired location and the script executed. Prompts will appear for the following information:

•

The path for the TCServer installation

•

The path to T24 (the xxx.run directory)

•

The path to the jBase version

•

The OFS.SOURCE record ID.

Note that this setup will only deploying files in the install directory, so special privileges to install it (apart from write access to this directory) will not be required.

For Windows, there is no update to the registry, so to uninstall, simply delete the whole directory. However, if installing the NT Service (in the ./bin path), write access to the Registry will be required. The removeService.bat will remove any entry.

TEMENOS Guide

Page 6 of 31

Temenos Connector

Figure 1 - TCServer Installation program

Once installed, the two 2 files (TCServer.bat and TCServer.sh) will be present in the /bin directory and can be executed (.bat for windows, .sh for Unix/Linux) to start the server. On unix, the rights of this file, may need review.

Environment Variables The Environment Variables are listed in the environment.vars file located in the /conf directory.

There are two different ed format for this file:

The default one has the tags <win32>. Depending the platform, the values listed in or <win32> will be used.

The second format contains only the “name-values” pair. This means that if necessary, the result of an “env” (unix) or “set” (win32) can be piped to this file.

TEMENOS Guide

Page 7 of 31

Temenos Connector

By default, this file contains “tags” like “ , <JBASEPATH> etc. These tags are substituted on the fly by the values specified in the tcserver.xml file. Even if the environment has been “piped”, this file can be edited and these special tags added, instead of having a “hardcoded” path.

Figure 2 - Default environment.vars file

TEMENOS Guide

Page 8 of 31

Temenos Connector

Configuration of tcserver.xml This file contains all the configuration parameters of the TCServer and is located in the ./conf directory. The structure of this file looks like this :

Message formatters are used to format (change) the requests and/or the responses

Adapters define how to connect with T24. The link to the message formatters can be specified here.

The listeners define the channel by which external programs connect to the TCServer (MQSeries, T, SSL etc.)

Initial settings

<MONITOR_PORT> 9500 9501 9502 <STACKEXPIRATION>120

MONITOR_PORT, TELNETD_PORT, DEBUGGER_PORT are T ports the TCServer will listen on. They are all optional.

TEMENOS Guide

Page 9 of 31

Temenos Connector

STACKEXPIRATION is the number of seconds a RESPONSE will stay in the internal queue before the server removes it; this can happen if the client application does not retrieve it. The encryption key will be described later in this document.

Messageformatters

<MESSAGEFORMATTERS> <MESSAGEFORMATTER id="CRLFtoVM"> com.temenos.formatter.CRLFtoVM

<MESSAGEFORMATTER id="VMtoCRLF">

MESSAGEFORMATTERS are java classes used to format a request or a response. The classes can be listed here by giving them a specific ID. The TCServer will load the class, but will not activate them. There is no restriction on listing classes; they will not affect resource usage.

Adapters

CRLFtoVM VMtoCRLF <MAX_SESSION> 5 <MIN_SESSION> 1 30 /bnk/bnk.run <JBASEPATH>/opt/jbc OFS.CONNECTION.MANAGER GCS <ENVIRONMENT>environment.vars

TEMENOS Guide

Page 10 of 31

Temenos Connector

ADAPTERS define the way the TCServer connects with T24Server. Multiple adapters can be specified, defined by the attribute “id” with different settings, they will only be activated if referenced by a listener

Tags OFSENTRY specifies which process will be used to communicate with T24Server. This should always be OFS.CONNECTION.MANAGER.

OFSTIMEOUT specifies after how many seconds the TCServer will assume that something went wrong, and will stop waiting. A value of 0 means “wait forever”.

MIN_SESSION is the number of initial processes. The TCServer will create new session if necessary up to MAX_SESSION.

GLOBUSPATH, JBASEPATH, OFSENTRY and OFSSOURCE are the values entered during installation. These values will be used to “fork” a new OFS.CONNECTION.MANAGER process. These are these values which will replace the tags in environment.vars.

ENVIRONMENT specifies which file contains the name-value pairs for the environment variables. The default value is “environment.vars”.

REQUEST_FORMATTER and RESPONSE_FORMATTER are a link MESSAGEFORMATTERS section. At this point the required formatter is specified.

BACK

to

the

Listeners LISTENERS define the communication with the TCServer. The following types of listeners are ed :

•

raw-t A raw socket accepting anything, processing it as-is.

•

t

Used by the TCClient to communicate through a Socket.

•

Ssl

Same as t, but using a secure socket.

•

mqseries

Connect to an MQSeries Queue, process all messages found and “publish” the response in another MQQueue.

•

mqseries-fwd

Will just forward the message from one queue to another one, without touching it at all

•

custom

This is a type of listener which will allow any java developer to create his own. A special section is dedicated to that type of listener later in this document.

These types of listener are defined in the attribute « type ». Each Listener must have a UNIQUE id (Name) and must have the attribute “active” set to “true” or “false”. Listener can be activated or deactivated using the Monitor or the telnet daemon.

TEMENOS Guide

Page 11 of 31

Temenos Connector

Example listeners in the above tcserver.xls

Lis.1

TEMENOS Guide

Page 12 of 31

Temenos Connector

G13101 4001

G13101 7002

G13101 <MQHOST>myhost <MQMANAGER>qm.test <MQQUEUE>test.in <MQCHANNEL>ch.test 5 <APPEND_MQMD>NO <MQHOST>chlap-taubert <MQMANAGER>qm.test <MQQUEUE>test.out <MQCHANNEL>ch.test

G13101 <MQMANAGER>qm.test <MQQUEUE>test.in 5 <APPEND_MQMD>NO <MQMANAGER>qm.test <MQQUEUE>test.out

TEMENOS Guide

Page 13 of 31

Temenos Connector

This is the most simple LISTENER possible. By defining such a listener, the TCServer will just listen to a Socket on the port and will forward to T24Server whatever it receives. A message ends with a CRLF. If such a Listener is used, one can just “telnet” the server by specifying the port. Eg : telnet localhost 4001.

Note that this listener doesn’t implement a Telnet emulation, so maybe an echo will not be present. This listener type is useful for test purposes. This is NOT recommended to use it in a live environment. The ADAPTERID tag specifies what adapter should be used when a message comes to this listener. All listeners have the same ADAPTERID tag, except mqseries-fwd.

Lis.2 The definition of the type « t » looks exactly the same as a “raw-t” channel type. However, it is not possible to communicate through a raw socket, as this kind of listener is expecting a specific binary format only the TCClient can generate and understand. This type of listener is the most common and can be used from any type of TCClient (java, COM, C++, . . .)

Mq.1 An MQ Queue is defined by four parameters :

•

MQHOST The MQHOST has the format [(<port>)]. Eg : LOCALHOST(1415). If no port is specified, the default 1414 will be used.

•

MQMANAGER

•

MQCHANNEL - This is the name of a “SERVER CONNECTION CHANNEL”

•

MQQUEUE.

NBTHREAD defines how many threads should look at this queue. The CONSUMER defines where to publish the response.

The TCServer will append the MQMD (Message descriptor) if any. This can deactivated by specifying <APPEND_MQMD>NO.

Mq.2 If MQSeries is deployed on the same machine than the TCServer, it is not necessary to specify the HOSTNAME and the CHANNEL. The TCServer will connect to MQSeries natively.

N.B.The directory containing the library “libmqjbnd05.sl” (mqjbnd05.dll for windows) must be in the LIBPATH (SH_LIBPATH, LIB, …).

Fwd The mqseries-fwd just forwards messages to another queue.

TEMENOS Guide

Page 14 of 31

Temenos Connector

ATM This listener has a of type “custom” allowing it to define a java class which will act as a custom listener. This functionality is very useful for development of interfaces. Refer to the following section on creating custom listeners.

Custom Listeners The key in creating custom listeners is to create a java class which extends the class com.Temenos.tocf.tcs.API.AbstractListener. This is in the tcserver.jar.

There are the following methods:

•

public abstract void stopIt();

•

public abstract boolean isStopped();

•

public byte[] process(byte[] bRequest) {

•

public byte[] processAsync(byte[] bRequest, String sTag) {

•

public void messageReady(byte[] requestId, byte[] bResponse, String sTag){};

•

public void run();

stopIt() is called when the TCServer wants to stop the listener. isStopped() must return whether or not the listener is stopped. process() must be called to send a message to T24Server in a synchronous way. This method is blocking and will return the response. processAsync() “posts” the message to T24Server. This method is non-blocking. The response will come back by a call to the method messageReady(). The return value of processAsync() is the unique message ID and will be received again in the method messageReady(). The parameter sTag is “any” value (can be null). This value will be ed back unchanged to the messageReady() method. messageReady() will be automatically invoked whenever an asynchronous response is ready. (After a processAsync(). getParam(String sTag) will return the contents of any custom tag in the block.

TEMENOS Guide

Page 15 of 31

Temenos Connector

run(). The class AbstractListener implements Runnable, and will create a new thread with the class whenever it needs to be started.

Here is the code of a simple Listener. In this instance, the listener does not, in fact, listen to anything, but simply sends in an asynchronous way, a message to T24Server every 5 sec. The responses are received via the messageReady() method:

The same kind of sample, but using a synchronous communication :

import com.temenos.tocf.tcs.API.*; public

class

ListenerTest

private boolean private boolean _bIsStopped = false;

extends _bStopIt

public void messageReady(byte[] requestId, byte[] bResponse, String sTag) { System.out.println("Received : " + new String(bResponse)); } public void run() { String sRequest = “ENQUIRY.SELECT,,INPUTT/123456,%CURRENCY”; while (!_bStopIt) { byte[] bRequestID = super.processAsync(sRequest, null); try { Thread.sleep(5000); } catch (Exception e) { e.printStackTrace(); } } _bIsStopped = true; } public void stopIt() {

TEMENOS Guide

Page 16 of 31

AbstractListener =

false

Temenos Connector

import com.temenos.tocf.tcs.API.*; public class ListenerTest extends AbstractListener { private boolean _bStopIt = false ; private boolean _bIsStopped = false; public void run() { String sRequest = “ENQUIRY.SELECT,,INPUTT/123456,%CURRENCY”; while!_bStopIt) { ( byte[] bResponse = super.process(sRequest.getBytes()); System.out.println("Received : " + new String(bResponse)); try { Thread.sleep(5000); } catch (Exception e) { e.printStackTrace(); } } _bIsStopped = true; } public void stopIt() {

In order that the TCServer can find the classes, they need to be deployed in the directory “ext”. For example, our previous sample (ListenerTest.class) needs to be located in:

TEMENOS Guide

Page 17 of 31

Temenos Connector

/ext/.

If the class had a package name (eg com.mycompany) it should be located in : /ext/ com/mycompany.

Alternatively, if a jar file was made, it can be added in the classpath.

Message Formatters Message Formatters are classes which can be locally written that will format any Request/Response before/after having send it to T24. A message formatter can be very useful in charset conversion or interfaces. For example, it could be very useful to write a Custom Listener, and 2 Message Formatters (one for requests and one for responses) to make any type of online interface, e.g. ATM. A “MessageFormatter” is a class extending com.temenos.formatter.Formatter. This class is in the jar “messageformatter.jar” Formatter has one abstract method : public abstract byte[] format(byte[] request, byte[] response); If the formatter is a REQUEST formatter, response will be null. Whatever is returned back will replace the request. If the class is a RESPONSE formatter, both the original request and the response will be ed. The response will be replaced by whatever is returned back. Here is a sample class which will convert CRLF to VM (253) :

TEMENOS Guide

Page 18 of 31

Temenos Connector

package com.temenos.formatter;

import com.temenos.messageformatter.*; import java.io.*;

public class CRLFtoVM extends Formatter {

private static final byte CR = 13; private static final private static final byte VM = (byte) 253;

byte

LF

=

10;

public byte[] format (byte[] request, byte[] response) { if (request != null) { ByteArrayOutputStream baos = new ByteArrayOutputStream(); int nRealLength = request.length; int nFakeLength = nRealLength - 1; int i = 0; while(i < nRealLength){ if ((request[i] == CR) && ((i < nFakeLength) && (request[i + 1] == LF))) { baos.write(VM); i++; } else { baos.write(request[i]); } i++; }

It is possible to determine the origin of the request and calling adapter. This can be done using the class Formatter (super…) : String sAdapter = super.getAdapterID(); String sListener = super.getListenerID(); It is also possible to retrieve the value of any custom parameter (Tags).

TEMENOS Guide

Page 19 of 31

Temenos Connector

<MESSAGEFORMATTER id="MY_FORMATTER"> com.temenos.formatter.TestFormatter <MYPARAM>Hello World

For the above definition, the value of the tag <MYPARAM> can be retrieved as follows : String sParam = super.getParam(“MYPARAM”); The call can also be cancelled, so that the request will not be sent to T24Server. In this case, if a RESPONSE formatter is defined, it will be invoked with a null response. However this response can be overridden by returning any chosen value from the method format(). super.setCancelCall(true); In order that the TCServer can locate the classes, they need to be deployed in the directory “ext”. For example, the previous sample (CRLFtoVM.class) would need to be located in /ext/com/temenos/formatter (“com/temenos/formatter” being the package name). Alternatively, if a jar file was made, it can be added in the classpath. Multiple Formatters It is possible to specify multiple formatters, by ‘chaining’ them using a comma separator in the specific ADAPTER like this :

TEMENOS Guide

Page 20 of 31

Temenos Connector

<MESSAGEFORMATTERS>

<MESSAGEFORMATTER id="838_TO_UTF8"> com.temenos.formatter.838TOUTF8 <MESSAGEFORMATTER id="UTF8_TO_838"> com.temenos.formatter.UTF8TO838

838_TO_UTF8, OFSML, UTF8_TO_838 838_TO_UTF8, OFSML, UTF8_TO_838 <MAX_SESSION> 1 <MIN_SESSION> 1

The formatter “OFSML” is a special one, and does not require any definition in the <MESSAGEFORMATTERS> tag. This formatter will convert OFSML to OFS for the request, and OFS to OFSML for the answer. The above example assumes that the class 838TOUTF8.class and UTF8TO838.class are in the directory /ext/com/temenos/formatter/ and that the incoming message is encoded in 838. Because the OFSML parser does not this charset, the formatter chain in the ADAPTER must perform the following operations on the request and the response: 1. Convert the message into UTF8 2. Parse the message (assuming this is OFSML) 3. Convert it back in 838 before sending it to T24Server. Example code for 838TOUTF8 class:

TEMENOS Guide

Page 21 of 31

Temenos Connector

package

com.temenos.formatter;

import public

com.temenos.messageformatter.*; class

838TOUTF8

extends

Formatter{

public byte[] formabyte[] request, byte[] response) { t( if (response == null){ return format(request); }else { return format(response); } } private byte[] format(byte[] orig){ try return new String(orig, "838").getBytes("UTF-8");

{

Alternatively the getParam() method can be used. Here is another sample MessageFormatter that formats the message from any charset to another:

TEMENOS Guide

Page 22 of 31

Temenos Connector

package

com.temenos.formatter;

import

com.temenos.messageformatter.*;

public

class

CharsetConverter

extends

Formatter{

public byte[] format(byte[] request, byte[] response) { if (response == null){ return format(request); }else{ return format(response); } } private byte[] format(byte[] orig){ String sFrom = null; String sTo = null; byte[]

bResult

=

try{ sFrom = super.getParam("CHARSET_IN"); sTo = super.getParam("CHARSET_OUT"); if (sFrom != null && !sFrom.equalsIgnoreCase("")){ if (sTo != null && !sTo.equalsIgnoreCase("")){ bResult = new String(orig, sFrom).getBytes(sTo); }else{ bResult = new String(orig, sFrom).getBytes(); } }else{ if (sTo != null && !sTo.equalsIgnoreCase("")){ bResult = new String(orig) getBytes(sTo);

The definition of the formatter would look like this:

TEMENOS Guide

Page 23 of 31

null;

Temenos Connector

<MESSAGEFORMATTER id="KSC5601TOUTF8"> com.temenos.formatter.CharsetConverter KSC5601 UTF-8

TCMonitor The TC Monitor is a monitoring tool allowing remote connection to any TCServer. It allows the the stop the server, check the active channels, reset the statistics data etc. Multiple monitors can be run simultaneously. To run the TCMonitor, copy the tcmonitor.jar (which is in the lib directory of the installation path) to any desired location and start it with the script in the install directory or type “java -jar tcmonitor.jar”. By default, the TCMonitor will try to connect to a server on « localhost », on port 9500. Connection to another server can be reached using the “File”, “Connection to …” menu options. The server is specified by : . The t.port element is optional. The port the TCServer is listening on can be changed using the <MONITOR_PORT> tag in the tcserver.xml file. If the <MONITOR_PORT> is not specified, the TCServer will simply not listen on any port.

TEMENOS Guide

Page 24 of 31

Temenos Connector

Telnet Daemon The server can be managed via a telnet session using the correct port number. The port the TCServer is listening on can be changed using the tag in the jTCServer.xml file. If the is left unspecified, the TCServer will not start the telnet deamon. Eg : telnet localhost 9501 The result will look like this :

Tracing functionality The TCServer uses the log4j tracing API. This API is well described on the log4j website (http://jakarta.apache.org/log4j). The configuration file used for the tracing of tcslog.properties (in the conf directory). During the deployment phase, using the “DEBUG” or “ALL” tracing level is recommended. Thereafter, the level should be set to “ERROR”.

Troubleshooting Verification of OFS configuration Log onto the server and navigate to the jshell prompt.

TEMENOS Guide

Page 25 of 31

Temenos Connector

Type “OFS.CONNECTION.MANAGER TCS”, where “TCS” is the OFS.SOURCE record ID. A message like “ OFS VERSION 2.0 ” should be received, this confirms that OFS is active. Then type an enquiry in OFS format, e.g.: ENQUIRY.SELECT,,INPUTT,123456,CURRENCY-LIST If the enquiry results are displayed then the OFS configuration is correct. Alternatively change the tcslog.properties file (in the conf directory) to redirect the tracing to the console (instead of a file) and to activate all tracing.

And then restart the server, and an extensive set of messages will be received:

TEMENOS Guide

Page 26 of 31

Temenos Connector

Disregard the log4j warning messages and locate the lines highlighted above. If these are present it confirms that the TCServer is active and connecting to the T24Server.

Java version

Type “java-version” at the jshell prompt. If the version is less than 1.3.1, then java cannot execute a binary in another directory than the current one. If this is the case an the java VM is required. However, there is the possibility to copy the entire install directory (i.e. where TCServer.sh is in the xxx.run directory. Then duplicate (and rename) the script .profile (jProfile.bat), and add the java –jar <currdir>\lib\TCServer.jar. OS390 On OS390, it is necessary to be in the xxx.run directory when starting the TCserver. This can be achieved by copying the TCServer.sh file in the xxx.run directory, and editting it to change the path to the tcserver.jar like this : “ java -jar /tcserver.jar”

TEMENOS Guide

Page 27 of 31

Temenos Connector

Temenos Connector Client Prerequisites and Compability •

The TCServer must be available and running.

•

Active channels for use on the particular instance of TCServer/T24. There are several way to ister/query the TCServer for the available channels (Temenos Enterprise Console (TEC), JMX console (standalone), TELNET daemon, Console, etc) but the recommended place is the configuration file (./conf/tcserver.xml).

•

A java Virtual Machine (JRE) version 1.3.0 or above should be installed. To test it, type “java – version”. Note that some problems can occur depending the java VM and the platform. Please refer to the Temenos HelpDesk in order to be sure that there are no known problems with some specific VM.

•

The TCClient has been deployed and tested on the following platforms : Windows 32, AIX, HP-UX, Solaris, Linux, OS390, AS400, True64.

•

The TCClient has also been embedded into J2EE client applications such as Temenos Browser on the following containers: IBM WebSphere 5.0, Apache Tomcat 4.0.

•

The main configuration elements for the java TCClient are its configuration file (./conf/channels.xml) and its logging facilities. They are all reside in the conf directory. For a programming reference please to the javadoc (./doc/index.html) or the samples in the samples directory.

Configuration : channels.xml The channels.xml. file contains all the configuration parameters of the TCClient and is located in the ./conf directory.

The structure of this file looks like this :

. . . <TIMEOUT> . . .

. . . ...

CHANNEL defines a channel available to the API for use from a TCConnection object instance.

TEMENOS Guide

Page 28 of 31

Temenos Connector

NAME defines the name that will be specified in the setChannelName() or open() methods of a TCConnection object instance.

TIMEOUT defines the period (in seconds) that the channel will block for a specific action (typically a response).

ADAPTER and TYPE define (WebSphere MQ, T, SSL, etc). the channel type as well as the particular parameters for each channel.

The following section shows a complete channels.xml and details the particular settings for each one of the ed channel types:

t.sample <TIMEOUT> 120 t 5003 <SUPPLIER> localhost

mq.sample <TIMEOUT> 15 mqseries <MQHOST> localhost(1414) <MQMANAGERqm.test > <MQQUEUE> test in/MQQUEUE> <

TEMENOS Guide

Page 29 of 31

Temenos Connector

T This channel type needs a port number and a hostname. These correspond to the values set on a particular Listener of the target TCServer.

PORT:

The T port number.

HOSTNAME:

The server hostname.

MQSERIES This channel type is split into two categories, the supplier (implied) and the consumer. The supplier part is where the client posts the requests and the consumer is where it reads responses.

MQHOST:

The MQ connection name in the format hostname(mqListenerPort).

MQMANAGER:

The MQ Queue Manager name.

MQQUEUE:

The MQ Queue name.

MQCHANNEL: The MQ Channel name.

REPLYQUEUEPARAMETERS: (consumer only) Defines the MQMD parameters of each request using the replyTo() methods of MQ so that the values of the MQ listener on the server side are overriden. So on the client side, the option is available to force the response on a different queue than the default specified on the server. Use one of (NONE, QUEUE, QMANAGER, ALL). Use this to implement MQ Clustering.

If MQSeries is deployed on the same machine than the TCServer, it is not necessary to specify the HOSTNAME and the CHANNEL. The TCServer will connect to MQSeries natively. Ensure that the directory containing the library “libmqjbnd05.sl” (mqjbnd05.dll for windows) is in the LIBPATH (SH_LIBPATH, LIB, …).

Tracing Functionality The TCClient uses the log4j tracing API. This API is well described on the log4j website (http://jakarta.apache.org/log4j). The configuration file used for the tracing is tcclientlog.properties (in the conf directory). During the deployment phase, using the “INFO” tracing level is recommended. Thereafter, the level should be set to “ERROR”. Troubleshooting To the configuration of the TCClient, change the tcclientlog.properties file (in the conf directory) to redirect the tracing to the console (instead of a file) and to activate all tracing.

TEMENOS Guide

Page 30 of 31

Temenos Connector

Then attempt to run one of the samples, and the cause of any problems should become apparent.

TEMENOS Guide

Page 31 of 31

Temenos Connector 1x1z1n

Overview 26281t

More details 6y5l6z

Related Documents 3h463d

Temenos Connector 1x1z1n

Temenos Connect-internet Fs 1fv1a

Installing Temenos T24 1n136h

Mxc Connector 2x4j56

Union Connector 5b6s24

Cbse Unit 5 Connector 5d5a1q

More Documents from "ahmedm" 5ft1g

Temenos Connector 1x1z1n

T24 Enterprise Console 175n1c