Posted by: imranadeel | July 17, 2010

WebSphere MQ Server with Temenos T24: Part 2

16th July 2010.

This is the second entry on MQ Server with T24.  The previous entry can be found here.

If you read my last post, you would think that I am saying it’s OK to use T24 without MQ Server.  It’s not.  I will shed light on various aspects of it as I go along.

First off, MQ offers message persistence; not having which means that if you have a server crash or your network goes down, the messages will be lost either at a host, or in transmission. For instance, a teller clicked on the option to deposit cash in a customer’s account.  The request came to the application server, and then went to T24 server.  Now, the server processes it and responds with confirmation.  On the way back, the web server went down, or the network broke.  Now the teller will not receive anything except a timeout message (in case of a network failure), or nothing at all (if the web server crashed).  But the transaction has already been committed at T24.  The teller would try to re-login and post the transaction again.  If the failed component is up, the transaction would go through, and the teller would get a confirmation from T24.  So now T24 would have two transactions instead of one.

Message persistence could have been of help here, if implemented with some level of clustering at the web (and application) server and MQ server levels.  Like had there been a web server crash, and there were two web servers clustered together, then the other web server would have been able to receive the message – only if there had been an MQ server, from where it could poll the incoming messages.

T24 Servers Layout

Assembly of servers and their interconnections

Similarly, if the T24 server goes out of business right when a teller sends a withdraw request, MQ would hold it till T24 server is back.  TC Server will pick the message from the MQ’s “IN” queue and process it; all this without the teller actually knowing that there was a problem.  This, of course, assumes that the T24 server is back within a time span not longer than long enough.

But therein lies another problem.  You see, you configure timeout on every browser channel.  This is typically 180 seconds (3 minutes).  If the web server doesn’t receive a response from T24 (or MQ) within this time span, it will time out, and show the user the error screen.  The user can then only go to the login page, which the web server hosts.  So even if MQ is holding a message in its queue, and the other party/network is not back within 3 minutes, the session is going to time out anyway, and the user will not be able to use the same message.  It will be “orphaned out” in MQ, as no party would be interested in taking it.  MQ server will wait till its timeout setting allows it, and then remove this message from its main queue, and put it in the Dead Letter Queue.  So even if you have MQ server, if the transaction is delayed for 3 minutes (or whatever is your timeout setting at the browser/TC Client and TC server levels), the session would expire anyway, thus essentially ignoring whether the transaction ever went through or not.

My advise here is that the IT executives should tell their users in the T24 early adoption/training sessions that if they face a timeout after posting a transaction, and have to login again, they must first check whether the transaction they just posted actually went through or not.

In my next post, I will explain the scenarios where MQ Server really comes into play as an essential component in the core banking system.  Your feedback and comments are always welcome.




  1. Asalaam alequm,

    Imran, i read your aritcle and found it quite informative. I am an Information security proffesional and is interested in understanding the Temenos architecture with repect to security prespective.

    Is it possible for you to elloborate the low level system flows within the temenos architecture i.e. protocols and services which are being used. And could you please highlight security issues which should be looked into.

    • Wa-alaikum Salam ,

      Thank you for appreciating the article.

      I forgot to respond to your query because of two reasons: 1) I don’t know what type of work you are involved with, and thus didn’t know what to answer; and (2) I got busy with work. I got some time now, so I can respond to the extent that I understand your question.

      Whatever T24 does internally, is completely internal. You have two possible external ends of T24:

      1. TC Server: the listener of T24 from the outside world. It accepts connections from the browser servlet (web application server) and responds back to user requests from the same channels. It also accepts connections from ADCs.
      2. T24’s connection with the database: Generally, this should be jBASE (which is native to T24) or Oracle.

      You can secure these two interfaces so that your stack is ok. For the TC Server bit, you can use secure channel and configure that on the MQ server (if you are using one). Do note that the browser servlet is a web application (Java servlet based) therefore, it accesses T24 on HTTP protocol.

      I hope that helped.


  2. Thanks for your response. Can you guide me if there are any specific threats which i one should look into for MQ server.

    Thanks again, i really appreciated your support.

  3. Hi Imran,

    Perhaps you can help with a question on T24 integration?

    I am looking to integrate automated Forex trade messages into T24 from an external system (without manually inputting the deals in T24).

    It it possible to connect our external system (where Forex trades will be booked) to T24 TC Server using MQ? How do we achieve this? Or do we have to use the TCClient API?

    Any further information on how to insert these trade messages into T24 FOREX table would be much appreciated.



    • Pierre,

      My apologies for the late response. I’ve been stuck lately.

      T24 has two mechanisms to connect: OFSXML, or ISO:8583 (used for electronic transactions). If you know the OFSXML of the messages you want to send, and if you also know the format of the response XML then you can communicate with T24. Otherwise, if you want to use ISO:8583, then you will have to engage the bank’s middleware vendor to provide you the interface/message formats for your app to talk to T24. Personally, I would go OFSXML route for this task.

      Now, I want to drive home another point: T24 front end is a Java servlet application, which talks to T24 Application Server via a software called TCClient. TCC converts all actions/requests from the browser end into OFSXML and sends them to the identified MQ queue. T24 Application Server has a corresponding software, called TCServer, which reads OFSXML from the IN queue, and passes the provided request to the destination T24 sub-application with the required parameters. Similarly, the response is transformed in XML and sent back to TCC via MQ.

      So you should ask your bank’s IT section, or their T24 implementer about the message formats (OFSXML) in which T24 would accept a similar message. Once you know the message structures of both, request and response messages, then you are ready.

      You can use MQ API to put your request messages in the IN queue, and read from the OUT queue.

      We have experienced T24 integration with external apps via an ESB and ISO:8583, both. I particularly liked the ease of Oracle Service Bus (OSB) 11, while IBM MessageBroker also works. But remember: MQ and ESBs only take care of the transport part. Giving your requests the right format is up to you, your client bank, and its T24 implementation partner.

      Feel free to contact me if you need further information.


  4. Thank you Imran.

  5. Hi Imran,

    Some further questions that you can perhaps answer:

    Correct, we will be using OFSXML.

    What we don’t know yet however is the “how” pertaining to the MQ API and /or Temenos Connector Client mentioned above, and whether that varies by implementation, or is standardised as a rule.

    · Does the TC Server and thus T24 use an inherent MQ architecture “in itself” for messages, or is it a standalone one?

    · If it IS NOT inherent (which from the information on OSB and IBM MB I assume is in fact the case) then use of the TC Client would actually be redundant, correct?

    · If it IS inherent, can it be addressable from an external application without being used through standard TC Client interfaces?

    · If necessary, how do we obtain the .Net/COM/etc. libraries for TC Client? Through Temenos directly? Through an implementer? It is likely licensed, I would assume?

    Thanks very much!

    • Pierre,

      While the message structures and fields of each screen in T24 are the same in T24 Model Bank (which is shrink-wrapped T24, out of the box, burnt on a CD) for any particular release (like R7, R8, R9, etc.) the message structure of your transaction may vary in different implementations of T24 due to two reasons:

      1. T24 Release: Like if you develop your applications for R8, while R9 or R10 have some fields added/changed in their messages then you will have to modify your application/messaging to accommodate that.
      2. While T24 message structure for a release would remain the same, a bank may add custom fields to it. In treasury, it is highly likely that the bank may have added a number of fields of its own in the screens, due to which the message structure may have to be changed from one implementation to the other.

      Now, I am not sure what you mean by the word inherent, but from what I understand, I can tell you that if you are putting a message directly in a queue, then you don’t need to work with TCClient or TCClient API. Your application can simply create a message in the format that T24 recognizes, and put that directly in IN queue using MQ API.

      You can use IBM MB or OSB for transport purposes, which would let you connect to an MQ queue in minutes. But the flip side is that the client bank may not want to spend another USD 60K to 80K just for that.

      Temenos does not have the best user and developer documentation in the world. And they will not talk to you unless you are a client bank or an implementation partner. So you cannot get the message formats on your own. As I mentioned before, you need to engage your client bank, and/or the implementer of the bank, to get it for you from Temenos.

      Let me know if you need further info.


  6. Hi Imran,

    I really like your posts especially the ones on Temenos core banking and WebSphere MQ, I am very interested in the 3rd part of that discussion which you have not posted yet as I want to see how MQ can be leveraged with Temenos best.
    I have a few remarks though on the automated Forex Trade Messages using OFSXML and IBM Message Broker V8 ESB. MB is an enrichment layer that leverages MQ extensively as its transport layer and so it performs the mediation, routing, conversions “protocols”, transformations “data formats” and distribution of events. In this context MB will can do more than just transport as it can perform transformations from Eg OFSXML to ISO 8583 or any other format as long as the message model / map is used for the conversion. And so a message producer can send the message to an MQ In queue using MQ API and a broker message flow implemented through broker compute nodes can be used to read from this queue, transform this message using a message model that can be built, imported, (pre built) or purchased (WebSphere Transformation Extender) and then written to an MQ out Queue where T24 (TC Server) can access it from.
    A similar flow can be implemented in the opposite direction for T24 responses.
    Also, IBM WebSphere Message Broker tool kit can be used to invoke Visual Studio directly thereby allowing you to use skills in inserting connectivity / transformation logic etc in known language of C, C# etc

  7. hello imran;
    Rally good post from side, i would like to know from where you are,i means from which country? i would like to know your email id ..i want some training from you..

    Thanks in advance

  8. Hi Imran. I have a small issue with the last part about the ESBs “We have experienced T24 integration with external apps via an ESB and ISO:8583, both. I particularly liked the ease of Oracle Service Bus (OSB) 11, while IBM MessageBroker also works. But remember: MQ and ESBs only take care of the transport part. Giving your requests the right format is up to you, your client bank, and its T24 implementation partner.” Ideally anything that calls itself an ESB should be able to do just more than transport roles in the scenario. A general ESB definition should be middle ware that performs data transformations, protocol conversions, routing, complex event processing, monitoring as well as be standards compliant.
    In a typical scenario the ESB would take the request in whatever format and protocol you give it eg ISO 8583 Over TCP IP, parse it and map it to OFS XML and output in on MQ at a specified WMQ Queue in this case MQ IN Queue where the TC Server can pick it up and send it to the back end.
    I have had the pleasure of implementing a WebSphere Message Broker Work flow using WMB Tool kit which did this exact same scenario above and has been implemented successfully already …. We are integrating Temenos R7 feeding it either OFSXML / ISO 8583 Data via MQ protocol using IBM WebSphere Message Broker V8.0.0.1.
    Also gone ahead and doing caching which is now being done out of the box by WMB V8.0.0.1
    Therefore the ESB does a lot more than just transport capabilities. With a good ESB you can integrate anything to anything. All you need is a sample to get the data structures needed so that the ESB can model them into a logical representation.

  9. Good fan of your blog by the way ! Great work !

  10. Hi Imran,

    I have a problem when T24 Sign in the following message show “Error communicating with the T24 server. “.But I can connected my database server using with terminal. Could you tell me how to solve it.

    Thank you very much.

    • David,

      This means that you may need to check your BrowserParameter.xml or Channels.xml files. They should have the right IP and server names, and the right queues mentioned in them.

      If you are using MQ or JMS at the moment, you can try without it, and going straight via TCP/IP adapter.

      Hope that helped.


  11. Hi Imran,

    I have one dought, (regarding to tcserver) in war file i edited channel.xml, BrowserParameter.xml and browserConnection.xml files. that war i deployed in websphere7. while login time i am not able to login, may be my application not hitting the tcserver. In websphere must i have to use MQ Listener or by using this tcserver port, ip & channel name i can connect to tcserver. if it is possible to connect tcserver by using port, ip, channel name. please tell me the exact path in websphere to connect.

    Thank you

    • Hi,

      Sorry for the late response.

      You can connect to TC Server via MQ as well as TCP/IP. You put the browserparameter.xml in the applications directory of WAS. Do you have the formats of tcserver.xml and browerparameter.xml files?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: