Tc4.temenos Connectors And Mq

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 \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