Beruflich Dokumente
Kultur Dokumente
Connector
User 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.
Table of Contents
Application Overview ........................................................................................................................... 3
Temenos Connector Server................................................................................................................. 3
Prerequisites .................................................................................................................................... 3
OFS Setup........................................................................................................................................ 4
Installing TCServer.jar and dependencies ....................................................................................... 6
Environment Variables ..................................................................................................................... 7
Configuration of tcserver.xml ........................................................................................................... 9
Custom Listeners ........................................................................................................................... 15
Message Formatters ...................................................................................................................... 18
TCMonitor....................................................................................................................................... 24
Telnet Daemon............................................................................................................................... 25
Tracing functionality ....................................................................................................................... 25
Troubleshooting ................................................................................................................................. 25
Verification of OFS configuration .................................................................................................. 25
Temenos Connector Client ................................................................................................................ 28
Prerequisites and Compability ....................................................................................................... 28
Configuration : channels.xml.......................................................................................................... 28
Tracing Functionality ...................................................................................................................... 30
Troubleshooting.............................................................................................................................. 30
Introduction
Application Overview
The Temenos Connector allows external programs to link into T24 via the OFS (Open Financial
Service) module. The Temenos Connector consists of two elements:
The java TCServer opens up T24 to external access via OFS. This can be done using many different
channels, including MQSeries, TCP, SSL and RMI.
The TCClient is an API which allows other client programs to connect with the TCServer (and
therefore onto T24) using the same channels listed above. The TCClient API is available as a java
version, as well as C++ offering a COM (Component Object Modelling) layout.
GLOBUS.INITIALISE
GET.ENV.JBASE
OFS.INITIALISE.SOURCE
OFS.CONNECTION.MANAGER
If the result is a full path to a library, this means that jBase can find this subroutine, otherwise, contact
your Temenos Representative to get the latest versions.
Java version
A java Virtual Machine (JRE) version 1.3.0 or above should be installed. To test it, type :
$ java version.
Platform
The TCServer has been deployed and tested on the following platforms :
Windows 32
AIX
HP-UX
Solaris
Linux
OS390
AS400
True64.
OFS Setup
Create an OFS.SOURCE record as presented here :
SOURCE.NAME TCS
21 OUT.QUEUE.NAME
22 QUEUE.INIT.RTN
23 QUEUE.CLOSE.RTN
24 SYNTAX.TYPE OFS
25. 1 LOCAL.REF
26 GENERIC.USER INPUTTER
27 IN.DIR.RTN
28 VERSION
29 IB.USER.CHECK
30 EOD.VALIDATE
31 FIELD.VAL
32. 1 ATTRIBUTES
33 RESERVED1
34. 1 OVERRIDE
35 RECORD.STATUS
36 CURR.NO 16
37. 1 INPUTTER. 0_AUBERT1
38. 1 DATE.TIME 07 NOV 02 07:29
39 AUTHORISER 0_AUBERT1
40 CO.CODE GB-001-0001
41 DEPT.CODE 1
42 AUDITOR.CODE
43 AUDIT.DATE.TIME
Please note that although the SOURCE.TYPE field is set to TELNET, the TCServer does not
actually use telnet, this is merely to specify that we will have online (and not batch) data coming.
To test that T24 is now ready to be accessed by the TCServer, at the jShell type:
$ OFS.CONNECTION.MANAGER TCS
An alternative way is to ensure that the environment variable called OFS_SOURCE is set up to the
value of the Record ID of the table OFS.SOURCE (in our example : TCS)
$ export OFS_SOURCE=TCS
(or set OFS_SOURCE=TCS for windows )
Then type:
$ OFS.CONNECTION.MANAGER
Type anything at the prompt: e.g. hello world. The answer should be:
ENQUIRY.SELECT,,<globus_user_id>/<password>,<enquiry_name>
If the test is successful then the TCServer is ready to be deployed. To quit the test type: exit.
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.
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.
The default one has the tags <unix></unix><win32></win32>. Depending the platform, the values
listed in <unix> 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.
By default, this file contains tags like <GLOBUSPATH>, <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.
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,
TCP, SSL etc.)
Initial settings
<TCSERVER>
<MONITOR_PORT> 9500 </MONITOR_PORT>
<TELNETD_PORT> 9501 </TELNETD_PORT>
<DEBUGGER_PORT> 9502 </DEBUGGER_PORT>
<STACKEXPIRATION>120</STACKEXPIRATION>
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">
<CLASS>com.temenos.formatter.CRLFtoVM</CLASS>
</MESSAGEFORMATTER>
<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
<ADAPTERS>
<ADAPTER id=G13101>
<CHARSET></CHARSET>
<REQUEST_FORMATTER> CRLFtoVM</REQUEST_FORMATTER>
<RESPONSE_FORMATTER> VMtoCRLF</RESPONSE_FORMATTER>
<MAX_SESSION> 5 </MAX_SESSION>
<MIN_SESSION> 1 </MIN_SESSION>
<OFSTIMEOUT>30</OFSTIMEOUT>
<GLOBUSPATH>/bnk/bnk.run</GLOBUSPATH>
<JBASEPATH>/opt/jbc</JBASEPATH>
<OFSENTRY>OFS.CONNECTION.MANAGER</OFSENTRY>
<OFSSOURCE>GCS</OFSSOURCE>
<ENVIRONMENT>environment.vars</ENVIRONMENT>
</ADAPTER>
<ADAPTER id="simulation">
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.
Listeners
LISTENERS define the communication with the TCServer. The following types of listeners are
supported :
Lis.1
<LISTENERS>
<LISTENER Name="lis.1" type="raw-tcp" active="true">
<ADAPTERID>G13101</ADAPTERID>
<PORT> 4001 </PORT>
</LISTENER>
This is the most simple LISTENER possible. By defining such a listener, the TCServer will just listen to
a Socket on the port <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 doesnt 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 tcp looks exactly the same as a raw-tcp 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 :
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</APPEND_MQMD>.
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.
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.
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:
import com.temenos.tocf.tcs.API.*;
public class ListenerTest extends AbstractListener
import com.temenos.tocf.tcs.API.*;
public class ListenerTest extends AbstractListener {
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:
<tcserver_install_path>/ext/.
<tcserver_install_path>/ext/ com/mycompany.
Message Formatters
Message Formatters are classes which can be locally written that will format any
Request/Response before/after having send it to T24.
If the class is a RESPONSE formatter, both the original request and the response will
be passed. The response will be replaced by whatever is returned back.
package com.temenos.formatter;
import com.temenos.messageformatter.*;
import java.io.*;
It is possible to determine the origin of the request and calling adapter. This can be
done using the class Formatter (super) :
<MESSAGEFORMATTER id="MY_FORMATTER">
<CLASS>com.temenos.formatter.TestFormatter</CLASS>
<MYPARAM>Hello World</MYPARAM>
</MESSAGEFORMATTER>
For the above definition, the value of the tag <MYPARAM> can be retrieved as
follows :
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 <tcserver_install_path>/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 :
<MESSAGEFORMATTERS>
<MESSAGEFORMATTER id="CP838_TO_UTF8">
<CLASS>com.temenos.formatter.CP838TOUTF8</CLASS>
</MESSAGEFORMATTER>
<MESSAGEFORMATTER id="UTF8_TO_CP838">
<CLASS>com.temenos.formatter.UTF8TOCP838</CLASS>
</MESSAGEFORMATTER>
</MESSAGEFORMATTERS>
<ADAPTERS>
<ADAPTER id="13101">
<REQUEST_FORMATTER> CP838_TO_UTF8, OFSML, UTF8_TO_CP838 </REQUEST_FORMATTER>
<RESPONSE_FORMATTER> CP838_TO_UTF8, OFSML, UTF8_TO_CP838</RESPONSE_FORMATTER>
<MAX_SESSION> 1 </MAX_SESSION>
<MIN_SESSION> 1 </MIN_SESSION>
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 CP838TOUTF8.class and UTF8TOCP838.class are
in the directory <tcserver>/ext/com/temenos/formatter/ and that the incoming message is
encoded in CP838. Because the OFSML parser does not support this charset, the formatter
chain in the ADAPTER must perform the following operations on the request and the
response:
package com.temenos.formatter;
import com.temenos.messageformatter.*;
package com.temenos.formatter;
import com.temenos.messageformatter.*;
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);
<MESSAGEFORMATTER id="KSC5601TOUTF8">
<CLASS>com.temenos.formatter.CharsetConverter</CLASS>
<CHARSET_IN>KSC5601</CHARSET_IN>
<CHARSET_OUT>UTF-8</CHARSET_OUT>
TCMonitor
The TC Monitor is a monitoring tool allowing remote connection to any TCServer. It
allows the user 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.
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.
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 <TELNETD_PORT> tag
in the jTCServer.xml file. If the <TELNETD_PORT> is left unspecified, the TCServer
will not start the telnet deamon.
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.
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:
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 upgrade to 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 :
Configuration : channels.xml
The channels.xml. file contains all the configuration parameters of the TCClient and is located in
the ./conf directory.
<CHANNELS>
<CHANNEL>
<NAME> . . . </NAME>
<TIMEOUT> . . .</TIMEOUT>
<ADAPTER>
<TYPE> . . .</TYPE>
...
CHANNEL defines a channel available to the API for use from a TCConnection object instance.
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, TCP, 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 supported channel types:
<CHANNEL>
<NAME> tcp.sample </NAME>
<TIMEOUT> 120 </TIMEOUT>
<ADAPTER>
<TYPE> tcp</TYPE>
<PORT> 5003 </PORT>
<SUPPLIER>
<INITIATOR>
<HOSTNAME> localhost </HOSTNAME>
</INITIATOR>
</SUPPLIER>
</ADAPTER>
</CHANNEL>
<CHANNEL>
<NAME> mq.sample </NAME>
<TIMEOUT> 15 </TIMEOUT>
<ADAPTER>
<TYPE> mqseries </TYPE>
<MQHOST> localhost(1414) </MQHOST>
<MQMANAGERqm.test </MQMANAGER> >
<MQQUEUE> test in/MQQUEUE> <
TCP
This channel type needs a port number and a hostname. These correspond to the values set on a
particular Listener of the target TCServer.
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.
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 verify 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.
Then attempt to run one of the samples, and the cause of any problems should
become apparent.