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

<<PARAMETER>>  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=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttp%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