Welcome to Temenos Connectors learning unit.

In this learning unit, you will learn how to

configure TCC, MQ and TCS to talk to each other

TC4-Temenos Connectors 1
 After completing this learning unit/course you will be able to understand

•Relate TCC and TCS to talk to MQ

•Describe working of MQ, TCC and TCS
•Illustrate Failure scenarios
•Explain MQ clustering

TC4-Temenos Connectors 2
 You are very well familiar with the above T24 architecture which has Message Queuing
Software incorporated. By incorporating MQ as discussed earlier what you are going to
achieve is what you won’t be able to with the help to Temenos Connectors as MQ allows to
store both requests and responses.

TC4-Temenos Connectors 3
 By this time you are an MQ expert having created queue managers, queues and channels, it is
right time now to configure TCC, MQ and TCS to talk to each other. So let’s see now how you
are going to utilise this message queuing software.

TC4-Temenos Connectors 4
 As a first step, let us establish the connection between MQ and TCS.
You know that the configuration file for TCS is tcserver.xml file.

You will find this file under

For TCS releases prior to 1.5 : <Path where TCS is installed>\conf
For TCS releases 1.5 and above : <Path where TCS is installed>\conf\TCServer

TCS supports communication with MQ. What does this mean?

Since IBM MQ is not a Temenos’s proprietary product how this external software system is
going to talk to Temenos Connectors. Well, you know the answer, any external system
wanting to communicate with TCS must use an existing or user defined plug-ins.

TCS has a predefined listener of type ‘mqseries’ which enables you to talk to MQ. All that you
need to do is to configure this listener to talk to the queue manager that you have created. Isn’t
that simple?

TC4-Temenos Connectors 5
 There is no change to the adapter definition as the communication between TCS and T24 is
not going to change with inclusion of MQ.

TC4-Temenos Connectors 7
 Let’s configure TCS to talk to MQ.
There is a predefined listener with type set to ‘mqseries’ in tcserver.xml. Just make necessary
changes to this listener and your job is done.
Let’s try to consolidate your understanding with this default listener of type mqseries
Listener name is defined as “mq” with type as “mqseries” and active flag set to true.
Adapter ID is adapter name where you wish to attach this listener.
MQHOST is the ip address and the port number of a system where IBM MQ has been running.
The default port on which MQ operates is 1414, where there is no need to specify the port
number and it can be any port of your choice.
MQCHANNEL is a channel name you have already created which is a communication link
between two queue managers
MQQUEUE is a local queue which is going to hold incoming request in this case it is Q.IN
NBTHREADS are number of connection threads between MQ and TCS. You will learn about
this parameter in detail as you proceed
CONSUMER
MQQUEUE is a local queue which is going to hold response once request is
processed by T24 in this case it is Q.OUT
DEADLETTERQUEUE is the name of a queue defined on the local queue manager.
Messages are sent to this queue if they cannot be routed to their correct destination

Here the queue has to be defined for both supplier and consumer. Supplier is
implied and for defining for consumer a separate tag ‘CONSUMER’ is used.

TC4-Temenos Connectors 8
 Ok, now you are all set with configuring tcserver.xml with the predefined listener mqseries.
This mqseries listener is attached to the adapter named T24jmeter.

tcslog.properties has LOG LEVEL set to DEBUG,file for the mqseries listener, so that we can
log whatever it does.

TC4-Temenos Connectors 9
 Once you restart your TCServer and make sure that mqseries listener is up and running, what
you need to do next is start your IBM WebSphere MQ.

TC4-Temenos Connectors 10
 In the TCServer console, you might find that the listener mq has started up as discussed
earlier but it actually might not be. To verify if all is well check the global.log for messages like
these.

This problem usually arises when,

1. You have not started MQ explorer by using the ‘run as’ option and supplying a user name
that you exclusively created for MQ purposes.
2. You have not specified the correct port number in the tcserver.xml file. If the port that you
are using is 1414, you need to specify it as it is the default port of MQ. Any other port
number, if used, needs to be explicitly specified.

TC4-Temenos Connectors 11
 Now, lets post a message to MQ’s in queue Q.IN and see the magic.
Post the message to queue Q.IN by right clicking on the queue Q.IN and choosing the option
‘Put Message”

As soon as you post the message to MQ’s in queue, TCS would have picked it up, processed it
by sending the request to T24 and would have placed the response in MQ’s out queue Q.OUT.
See the ‘Current Depth’ of the Q.OUT queue. You should see a value 1.

Now, right click on Q.OUT and click on browse message to view the output in
readable format.

Congratulations. You have successfully made TCS and MQ speak to each

other.

TC4-Temenos Connectors 12
 Well, now that you have configured a predefined listener in tcserver.xml, let’s turn to TCC .

You know that the configuration file for TCC is channels.xml which you can find;
For Browser : under the WEB-INF\conf
For TCC alone : in the <Directory where TCC is installed>\conf
You need a channel to communicate with the mqseries listener. So, what changes do you
need to make in TCC’s channels.xml?

TC4-Temenos Connectors 13
 Likewise there was a predefined listener in tcserver.xml you will find a predefined channel with
type mqseries.
Let’s make changes accordingly in this file

NAME This is a channel name in our case it’s ‘mq’

TYPE This is type of listener ‘mqseries’

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 This is a system where MQ software is running on port 1416

MQMANAGER This is a Queue Manager created earlier used to administer queues in our
example it is T24.QM1
MQQUEUE is a local queue which is going to hold incoming request in this case it is Q.IN
MQCHANNEL is a channel name you have already created which is a communication link
between two queue managers in this case it is T24.CH
MQQUEUE is a local queue which is going to hold response in this case it is Q.OUT

TC4-Temenos Connectors 14
 This is a part of the BrowserConnection.xml file with the CHANNEL set to mq.

TC4-Temenos Connectors 15
 This parameter specifies how the web server communicates to the T24 host machine.

Options possible are AGENT/ INSTANCE /JMS

If the value is INSTANCE, then web server can be configured to connect to the T24 server via
various channels (as defined for the instance in browserConnection.xml)

TC4-Temenos Connectors 16
TC4-Temenos Connectors 17
 Now that you have configured T24 Browser, TCC, MQ and TCS ensure that all required
components including MQ are up and running so that you can input transactions through
Browser.
Now, try and login into Browser. If you are able to successfully able to login and work in
Browser, it means that you are an MQ expert 
Well, take a look at the queues Q.IN and Q.OUT after you have logged in through Browser.
What is there current depth?
Did you expect 1 to be the current depth for both the queues?
Did you expect 1 to be the current depth for Q.OUT alone?
Current Depth will be 0 for Q.IN because, TCS would have picked up the request from that
queue to process.
Current Depth will be 0 for Q.OUT as well because, TCC would have picked up the response
so that the response can be sent to the IE screen that initiated the request.
So, I am sure, you now understand why ‘Current Depth’ will be 0 for both Q.IN and Q.OUT
when you configure T24 Browser, TCC, MQ and TCS.

TC4-Temenos Connectors 18
 An important point to note here is NBTHREADS parameter in tcserver.xml file. This defines the
number of connection threads between MQ and TCS. When a message is to be sent from MQ
to TCS, one of the connection threads get locked, and TCS does an mqget as shown in the
diagram using this connection thread, and the message is placed in TCS’s in stack. Until a
response posted back to MQ by TCS, the connection thread remains locked. Hence, if you
define NBTHREADS to have a value 3, then, at a point, 3 messages can be processed
between MQ and TCS.

TC4-Temenos Connectors 19
 Ok, so you are done with configuring NBTHREADS in listener type mqseries. There is a link
between this NBTHREADS parameter and MAXSESSION parameter in the adapter definition.
Caution needs to be taken while defining values for NBTHREADS and MAXSESSION tags.
Always ensure that the value for NBTHREADS is higher than MAXSESSION so that TCS
always has a request to process and does not have to wait for a request to fall into its instack.

TC4-Temenos Connectors 20
 I am sure you have questions relating to failure scenarios.

Now, let us discuss the various failure scenarios and understand the need for a message
queuing software.

TC4-Temenos Connectors 21
 Remember that TCC will always wait for an acknowledgement from TCS saying that it has
received the request, so, if TCS is not up and running, TCC will keep resending the request
and requests will get queued up in MQ’s in queue.
So, how many times will TCC retry. TCC will retry 10 times(This retry count of TCC is fixed),
so you will find 11 messages in MQ’s in queue after which TCC will time out.
Assume that TCS has been started now. What will happen to the 10 messages in MQ’s in
queue? Will they all get processed? Assume that it was a message to commit a Funds
Transfer transaction, Will 11 Funds Transfer transactions be created in T24?
When a request is posted from Browser, all requests come with a token number. This token
number is a unique identifier for a request sent from Browser. Hence, when TCC reposts a
request, all these requests will have the same token number. Hence, when TCS is started and
messages are sent to T24, T24 will process only of the requests(ideally the first in MQ’s in
queue) and not process the others as they have the same token number. MQ will anyway
remove all the 11 requests from its ‘in’ queue and place them its ‘out’ queue from where TCC
will pick up.
Now, what if the client(Browser) times out before TCS can be started? What happens to the 11
requests posted by TCC? Will they remain inside the MQ’s in queue?
When a user using Browser receives a time out error, he needs to refresh the page in order to
resubmit the message. Refreshing the page will ensure that the request goes with the same
token number as before. A new token number is allocated only when a response is sent back
from T24. A token number is generated by T24 and the client receives his first token number
on successful login to T24. Resubmitting a request by refreshing the page will only result in on
more message getting added to MQ’s in queue with the same token number. When TCS is
restarted subsequently, only one of the requests will get processed as all have the same token
number.
What if the user does not refresh the page, but logs in again? This time, his request will be
treated as a new request and will get processed. T24 has a functionality to identify duplicate
contracts. So, the only check at this stage is the override raised by T24 – “Possible duplicate
contract”. So, always encourage users to refresh the page rather than re-login.

TC4-Temenos Connectors 22
 When a request comes from an interface(anything other then Browser), normally it will be
routed to T24 via TCC as TCC is the client API of TCS.
Assume that a request to create a Funds Transfer record in INAU status is send by the
interface to TCC. What if TCS is not up and running at this point?
As discussed earlier, TCC will keep resending the request and they will all be held in MQ’s in
queue until the time TCS is started. So, there will be 11 FT requests in MQ’s in queue. Once
TCS is started, how does TCS know that they are duplicate messages? There is no token
number to identify the requests as requests are not coming from Browser.
TCC will always add a ‘Correlation ID’ to the request before sending it to TCS. This correlation
ID is a unique identifier of a request. The response for a particular request will also come back
with the same correlation ID. This is how TCC knows which response belongs to which
request. Thus, in this case, because of the correlation id, TCS can identify duplicate messages
and hence will only process one of them. Hence only one FT record in INAU status will get
created in T24.
Now, let us continue with the assumption that TCS is not up and running. The interface sent an
FT request to TCC and waits for a response. Since it did not receive a response within the
stipulated time frame, the interface RESENDS the request to TCC. Please note here that now
the INTERFACE is resending the request. When the interface resends the request, there is no
way that TCC can know whether it is request being resent or it is a new request. Hence, TCC
will allocate a new correlation ID to this request and place it in MQ’s in queue. So, this
becomes a brand new request.

TC4-Temenos Connectors 23
 Well, if TCC dies after posting a request but before receiving a response, the response will be
available in MQ’s out queue and TCC can pick it up when it comes alive again. There is no
expiration period for MQ’s queues. But care needs to be taken as there is a maximum queue
depth for MQ queues.
At this point, it would be ideal to revisit the concept of persistent and non-persistent queues
that are supported by MQ.
Persistent queues will
Hold the messages after a queue restart
Hold the messages after MQ has been restarted
Hold the messages even if MQ has crashed and then started again (abnormal
termination of MQ)
Non-persistent queues will
Not hold the messages after a queue restart
Not hold the messages after MQ has been restarted
Not hold the messages even if MQ has crashed and then started again (abnormal
termination of MQ)

TC4-Temenos Connectors 25
 Well, MQ could die as well. The entire T24 architecture is build based on resilience – no single
point failure. So, the best way to setup would be to have a MQ cluster. An MQ cluster in simple
terms is having multiple installations of MQ, but to show these installations as a single
installation to TCC and TCS. We will discuss more about clustering later in this document.

TC4-Temenos Connectors 26
 Temenos consultants are not expected to set up MQ clusters at client sites. However, this
section has been written in order to ease understanding of cluster setup at client sites. MQ
clustering and performance tuning is a very vast topic. This section will only give you an
overview of the clustering concept.

What are you going to achieve by configuring MQ clustering?

Remote queue definitions are not required- one or more cluster repositories hold information
about all cluster queues.

Additionally, message channels do not need to be defined between every queue manager, as
the cluster can create them automatically.

When an application sends a message to a cluster queue, their queue manager uses a cluster
repository to find the queue location, then dynamically creates a message channel.

TC4-Temenos Connectors 27
 In this learning unit you learnt,

•Relate TCC and TCS to talk to MQ

•Describe working of MQ, TCC and TCS
•Illustrate Failure scenarios
•Explain MQ clustering

TC4-Temenos Connectors 28
TC4-Temenos Connectors 29