Tc5.tss Workflow

Welcome to Temenos Connectors learning unit. In this learning unit, you will learn how Temenos Connectors communicate with T24 with the help of tSS program.

TC5.tSS Workflow-R11

1

After completing this learning unit/course, you will be able to understand, •What is tSS

•The workflow of tSS

TC5.tSS Workflow-R11

2

What does this program tSS stands for? tSS is t24 Server Session tSS is formerly known as OFS.CONNECTION.MANAGER which is used to send request messages to TEMENOS T24 server and receive back responses. The reason behind this change is just to be in line with the agent/service nomenclature. You learned about TSM and tSA now you have tSS tSS is the gateway into T24, any request coming in via any TCS plug in enters here. The tSS is responsible for receiving the request and passing the response back to the TCS. It does not process the request but passes it to the appropriate OFS routine

TC5.tSS Workflow-R11

3

tSS does the following …

Initializes the TEMENOS T24 environment & common variables for the processing applications / subroutine to work correctly. Reads the OFS.SOURCE record details Receives messages from the TEMENOS Connectors / from console through user input in a TEMENOS T24 classic client. Passes the request message to the OFS.SESSION.MANAGER to perform the required processing.

Passes the reply message returned, to the caller. Checks for a signal to stop initiated by getting a string “EXIT” or “QUIT” from the TEMENOS Connectors / from console through user input in a TEMENOS T24 classic client.

TC5.tSS Workflow-R11

4

Where does this tSS program incorporated inside TCS?

You will find PROGRAM tag in TCServer.xml which is used to mention the name of the PORGRAM which will talk to T24 through OFS that is nothing but tSS. tSS program requires an OFS.SOURCE record is which is placed in <>  tag. Understands the SOURCE TYPE and SYNTAX and communicates with T24.

TC5.tSS Workflow-R11

5

Every tSS request that is spawned has a jBASE level user number associated with it and is appended to the string OLTP to form the ID of the TSA.STATUS record Example : OLTP3122

TC5.tSS Workflow-R11

6

It is possible to monitor all tSS sessions(agents) running with the help of an enquiry AGENT.STATUS. Agent ID is the Agent Number

Server Name is the name of the server where the agents are running. Agent Status is the status of the agent. It can hold either of the three values. RUNNING – Agent performing the job STOPPED – Agent has stopped properly. DEAD – Agent did not report within the time given and hence the tSM has marked the agent as DEAD(applicable while running COB)

Process Id is the Operating system level process ID for the agent process that is running •Current Service is the service the agent is performing at the moment all tSS (agents) are currently working on OLTP (On Line Transaction Processing) •Next Service is the service the agent is supposed to perform next.

TC5.tSS Workflow-R11

7

Why don’t you just post messages OFS directly? Yes provided you know the OFS syntax which is native to T24. OFS is Temenos’s proprietory message format. Then why you need TCServer? Wait before you answer. You should think of multiple channels through with T24 can receive request in different message format. So you shouldn’t expect requests coming in through different channels must be in OFS format. It is TCServer who takes care of translating those messages into format which is native to T24. By now you are familiar with that you can attach different formatters at TCServer Level. So, Temenos has given option to external world to talk to TCServer by writing their own client component provided it follows the rules laid down by Temenos nothing but TCS’s published API.

TC5.tSS Workflow-R11

8

What is a Standard Request? (1) Enquiry Request

(2) If application has .NBK set in PGM.FILE field ADDITIONAL.INFO (3) Subroutine Request (4) S and W type application (5) Delivery Request (Any request that begins with DECARRIER is taken as a delivery request) Why OFS.BULK.MANAGER? The tSS program is the entry point of all requests into T24. You will look at how single and bulk requests are handled with regards to transaction boundaries. tSS has to decide whether the request is a standard or a bulk request meaning whether tSS has to handle multiple messages to determine this it calls OFS.BULK.MANAGER which in turn calls OFS.BULK.CHECK and checks whether an incoming request is a standard request or bulk request. In this scenario the request which tSS is going to handle is a standard request. OFS.BULK.MANAGER passes on request to OFS.PROCESS.MANAGER, this in turn distinguishes if it’s a delivery request or a normal request. For a delivery request it calls OFS.DE.REQUEST and for a normal request it calls OFS.SESSION.MANAGER. Finally the request is processed by OFS.REQUEST.MANAGER. Transaction boundary is controlled by an application since the request is a standard request. Now, what if the tSS sent a message to verify a record in EB.PHANTOM application. Note that this application has the field TYPE in PGM.FILE set to W. This is not a bulk request, but EB.PHANTOM works in batch mode. How will OFS.BULK. MANAGER work now? When an OFS message is received, OFS.BULK. MANAGER checks to see

TC5.tSS Workflow-R11

9

if it is bulk request. It this case, it isn’t. Hence, it does not start a transaction block. It just calls OFS.PROCESS.MANAGER, then OFS.SESSION.MANAGER and then OFS.REQUEST.MANAGER.

9

1.

In order to support this concept of receiving multiple OFS messages together, OFS.BULK.MANAGER was introduced. As the name suggests, it helps process bulk OFS messages.

2.

Meaning, when it receives an OFS message, it checks to see if multiple OFS messages have been supplied delimited with FM.

3.

If yes, splits them, and stores them in a queue in memory named c_Txn_RequestQueue.

4.

Once all the messages are ready, it starts a transaction block and for each message uses the same route of OFS.PROCESS.MANAGER, OFS.SESSION.MANAGER, OFS.REQUEST.MANAGER and finally the application

5.

The transaction management framework in the applications have been modified in such a way that they respect the transaction boundary started by OFS.BULK.MANAGER and they don’t start one on their own.

6.

Once all messages have been processed and if successful, OFS.BULK.MANAGER marks the end of the transaction block thus committing all the transactions. If there was an error in any one of the messages, all are rolled back as OFS.BULK.MANAGER internally calls EB.TRANS with “ABORT”.

What you need to understand here is, why OFS.BULK.MANAGER is managing the transaction block and not each of the application’s transaction processing framework as discussed earlier. Just imagine if OFS.BULK.MANAGER did not start a transaction block, then when each message gets processed, the respective application would start and end its own transaction block . What this evaluates to is, the first message might be successfully processed and hence committed to the database, but if there is an error in the second message, the second message alone will fail and will proceed with the next one. At the end, there will be a situation where in some of the messages would have got processed while some would not have. Is that OK? If this is what you want then OFS.BULK.MANAGER controlling transaction management is correct.

11

Transaction requests are passed from OFS.BULK.MANAGER to OFS.PROCESS.MANAGER

The request type - bulk / standard is known by now Distinguishes if it’s a delivery request or a normal request For delivery request it calls OFS.DE.REQUEST For normal request it calls OFS.SESSION.MANAGER Any request that begins with DECARRIER is taken as a delivery request

TC5.tSS Workflow-R11

12

Token handling is the main responsibility of OFS.SESSION.MANAGER

Takes care of loading style sheets Determines the type of request and the format. Handles TEMENOS T24 Browser sessions (create / destroy) and manages operations. Validates the TEMENOS T24 Browser requests. Checks the access rights (SMS). Parses the Browser XML messages. Checks functions / applications. Locks records (if required) Passes the request message to the OFS.REQUEST.MANAGER to perform the required processing. Creates the required response messages Passes the reply message returned to the caller.

TC5.tSS Workflow-R11

13

The OFS.REQUEST.MANAGER is the main processing routine of the OFS module. It is the heart of the OFS module and has a generic logic to work across various TEMENOS T24 applications and enquiries. OFS.REQUEST.MANAGER does the following Determines the syntax type from the OFS.SOURCE record and process message Parses the requests Performs message logging (request / response) Request types are classified as Transaction requests If transactions are coming via Browser it calls RUN.APPLICATION else it called EB.EXECUTE.APPLICATION to execute the T24 application Enquiry requests

Calls OFS.ENQUIRY.MANAGER

TC5.tSS Workflow-R11

14

To process the request which has been sent a call to respective application should be made. For instance, if the request is to create a record in the FUNDS.TRANSFER application, then, EB.EXECUTE.APPLICATION actually invokes the FUNDS.TRANSFER application to process the request. Actually performs a call to the underlying application in T24 to process the request.

TC5.tSS Workflow-R11

15

No, you don’t need 100 oracle user license because all of them are committed using the same 'T24 environment user'. The number of oracle connections is controlled by the driver, but the problem mentioned in the document is more to do with the tSS becoming a defunct process. When the DB connection is lost, tSS just becomes a defunct process and doesn't end either but TCS wouldn’t know there is still a tSS and would start another tSS based on the number of min_sessions and over a period of 3 to 4 hours you will end up with 100 or 150 tSS sessions while the max_session was set to 15!! As a temporary workaround you set the min_session to 0 so that tSS session knows it has to close after processing a request. Anyway this issue was fixed even way back in TCServer 1.5.0_18 or 1.5.1_18. The number of oracle licenses is equal to the number of concurrent transactions that you will post - each update out of a transaction will open a connection to the DB. So if you have 100 tSS but only 50 concurrent transactions at any point in time then 50 licenses will do.

Please refer to the following KB link for more information http://knowledgebase.temenosgroup.com:2322/DF/Lists/Team%20Discussion/Flat.asp x?RootFolder=%2fDF%2fLists%2fTeam%20Discussion%2fTCServer%20%20%2d%2 0External%20database&FolderCTID=0x0120020097FA856850184146BBC947176EA F2334&TopicsView=http%3A%2F%2Fknowledgebase%2Etemenosgroup%2Ecom%3 A2322%2FDF%2FLists%2FTeam%2520Discussion%2FNew%2520Discussions%2Ea spx

TC5.tSS Workflow-R11

16

In this learning unit/course, you learnt,

•What is tSS •The workflow of tSS

TC5.tSS Workflow-R11

17

TC5.tSS Workflow-R11

19