AA Advanced Customisation - Part 3

Temenos University - June 2012 1

AA Advanced Customisation - Part 3

Temenos University - June 2012 2

AA Advanced Customisation - Part 3

As a first step of this last chapter of the AA Advanced Customisation course, let
us try to jog our memory and review some core concepts regarding the Open
Financial Services module and how it is used. Later we will see how AA
transactions are dealt with by OFS.

OFS stands for Open Financial Services and it is –

The native T24 message format and only standard Gateway to T24
A core module of T24, abbreviated as OF
OFS enables both transaction requests and enquiry request to T24
OFS can be used in 3 different ways with 4 different modes –
Batch processing
• BATCH mode – for offline requests from a third-party
system (e.g. updates from another application used by the
Sales Department of a Retail Bank, which stores details of
prospective customers; when these client information has to
be migrated to T24, BATCH mode can be used)
Inter-application processing
• GLOBUS mode – for posting transaction requests on T24
applications issued by other T24 applications/routines (e.g. if
we want to update the DE.ADDRESS application, storing the
address/es to be used for delivery advices, whenever we input
a ‘holiday address’ in the client’s record on the CUSTOMER
file, we should use the GLOBUS mode)

Temenos University - June 2012 3

AA Advanced Customisation - Part 3

Online processing
• TELNET mode – for processing messages online from third-party
systems (e.g. messages posted by a SWIFT interface)
• SESSION mode – for processing messages online from Temenos
interfaces (e.g. Browser or ARC-IB interfaces)

Temenos University - June 2012 3

AA Advanced Customisation - Part 3

Let us now review briefly the message syntax for an OFS transaction. This is
composed of 5 parts separated by commas.

Operation
The ‘Operation’ part of the message contains the name of the application
that we are going to use to post our transaction. Eg: ACCOUNT.

Options
As its name imply, the ‘Options’ part of the message is optional since
many of the parameters here may be defaulted. This contains many sub-
parts, separated from one another through a forward slash sign. The sub-
parts are Version name/Function/Process type/ GTS.Control
value/No.of.authorisers. E.g. TRG/I/VALIDATE//2

Version name – this must a valid version suffix (e.g. if the version name is
ACCOUNT,TRG then the value contained by this parameter will be just
TRG). As comma versions don’t have any suffix, they cannot be used
here.
Function – a T24 function such as I, R, A,H,V. Note that C and P is not
supported.
Process Type – this may be VALIDATE or PROCESS and controls
whether the transaction is to be validated (i.e. checked for error) or

Temenos University - June 2012 4

AA Advanced Customisation - Part 3

processed (meaning, that the transaction is going to be actually committed).

Gts.control – indicates the way in which override and error messages should be
treated.
No of authorisers may be used to specify the no of authorisers . I.e. zero, one or
two. GTS control and no of authorisers if supplied will override the corresponding
settings in the Version.

User Information
This consists of the Sign On Name, Password and Company code of the user
whose SMS credential are going to be used in the transaction
E.g INPUTT/123456/GB0010001

Temenos University - June 2012 4

AA Advanced Customisation - Part 3

Transaction ID
The ‘Transaction Id’ part of the message contains the key of the record used
within the transaction. This is optional for new transactions if the underlying
application is configured for Automatic ID Generation.
The transaction ID parameter is, instead, mandatory for See , Authorize, Delete,
Reverse, History-Restore and Validate functions or when we are trying to edit a
specific record. The transaction ID can also contain an optional Message ID for
the message.
For eg 20548/20081010001 .
In this case the 20548 is the record id and 20081010001 is the message id. This
message id, which is an optional information, could be used by external systems
to uniquely identify each OFS message.

Message Data
The message data portion of the message structure contains the data
required to create or update the transaction. Message portion follows the
format
Fieldname=data
Eg CUSTOMER=100297
When you need to assign values to multi values or sub values , you may
follow the format
Fieldname :multi value number : sub value number = data

Temenos University - June 2012 5

AA Advanced Customisation - Part 3

Eg CUSTOMER:1:1=100297
This implies the first sub value belonging to the first multi value of the field
CUSTOMER is assigned a value of 100297. The first multi value or sub value is
taken as the default in the absence of positions If ‘NULL’ is specified as field data,
OFS will blank the field of all data.
The message data portion of the message can be repeated for each field
separated by a comma (,).

Temenos University - June 2012 5

AA Advanced Customisation - Part 3

Look at the sample requests shown.

The first one is a sample request to input an account record. This has not used a
version. The mandatory field values have been specified.
The second request is one to authorise the record previously input. This does not
contain values in the data portion. PROCESS has not been specified either since
that is the default process type.

Temenos University - June 2012 6

AA Advanced Customisation - Part 3

Let us now review, as well, the syntax of an Enquiry Request Message.

The diagram on this slide shows the syntax of this type of messages.
As you probably remember, the structure is very much similar to a Transaction
Request. The options part has been omitted, since it is not relevant to an enquiry.
However commas are given to indicate the placeholder, and retain the general
structure of an OFS message.

The portions of an Enquiry Request are

ENQUIRY.SELECT
The first portion of an enquiry request must always be
ENQUIRY.SELECT. This is the name of the routine that is used to run
queries and return the data, abbreviated as ENQ when you are invoking it
in CUI or GUI Interfaces.

User information
The user information portion of the message structure is the same as that
of the transaction type request.

Enquiry Name

Temenos University - June 2012 7

AA Advanced Customisation - Part 3

You will specify here the @ID of the T24 ENQUIRY record which should be
executed. (i.e. the enquiry name placed in this OFS message part must be found
under the ENQUIRY application of T24).

Message data
The message data portion, finally, contains

• The message data portion of the enquiry message structure contains the
selection criteria passed to the enquiry.
• The message data portion of the message can be repeated for each selection
criteria separated by a comma (,).
• This is optional depending on the Enquiry

The three different parts of a Selection Criteria part of the MESSAGE DATA are:
• Selection Field – denotes the name of the field of that must be either a field
in the STANDARD.SELECTION for the file on which the enquiry is based
(ie- the application that is specified in FILE.NAME field of the ENQUIRY
application )or a value set in SELECTION.FLDS field of the ENQUIRY
application.
• Operand – denotes the operand that must be used for selection for the value
specified in the SELECTION.FLDS field of the ENQUIRY application. The
operands can be EQ, NE, GE, GT, LE, LT, UL, LK and NR. The operand
must be separated from the selection fields using a colon (:).
• Field Value – denotes the data value for the values specified in the
SELECTION.FLDS (field of the ENQUIRY application) and the operand for
selection. This must be separated from the operand using a equal sign (=).

E.g. ACCOUNT.NUMBER:EQ=11107

Temenos University - June 2012 7

AA Advanced Customisation - Part 3

This is an enquiry request to call the default account enquiry

ENQUIRY.SELECT,,INPUTT/654321,%ACCOUNT

This is the same enquiry request with a criteria

ENQUIRY.SELECT,,INPUTT/654321,%ACCOUNT,
CURRENCY:EQ=USD,CATEGORY:EQ=1000

Temenos University - June 2012 8

AA Advanced Customisation - Part 3

Temenos University - June 2012 9

AA Advanced Customisation - Part 3

Arrangement Architecture transactions can be also posted to T24 using OFS

In this chapter we will see how OFS can cope with AA transactions even if the
OFS syntax only accepts one message per time, while the creation of new
arrangements and many other activities in AA require that multiple applications
are accessed and updated

Temenos University - June 2012 10

AA Advanced Customisation - Part 3

As we know and as we have stated in the previous slide, a single arrangement

data is stored in multiple files in T24. In order to clarify how OFS can update all
of them when an arrangement is created or modified, we should first clarify what
are the applications that our OFS transaction should consider while dealing with
an AA arrangement.
Let us try to list them –

AA.ARRANGEMENT – this application is definitely required as it holds the

details of the arrangement itself
AA.ARRANGEMENT.ACTIVITY – this other application, instead, stores the
details of the activity performed on the arrangement (e.g. LENDING-NEW-
ARRANGEMENT if we are creating a brand new loan)
AA.ARR.<PROPERTY.CLASS> – applications with this kind of name structure
are crucial as they contain the actual data of the arrangement (e.g.
AA.ARR.TERM.AMOUNT will store – for a loan – the amount of the
commitment, the repayment date etc; AA.ARR.ACCOUNT will define the
accounts used for disbursement or repayments etc)

In the coming slides, we are going to see how OFS can support multiple updates
on all kind of applications above with just one transaction.

Temenos University - June 2012 11

AA Advanced Customisation - Part 3

Please note that the OFS message syntax has not changed at all to support the
creation and updates of contracts in the Arrangement Architecture module
1. Operation
As you are aware of, the section contains the name of the application that
needs to be updated. For AA, this will always store the value
AA.ARRANGEMENT.ACTIVITY, i.e. the application used to define
which activities are performed on an arrangement. In AA, every action
you take on an arrangement is an activity. When you create a new
arrangement, you are performing an activity called LENDING-NEW-
ARRAMGEMENT. When you wish to decrease the term of the
arrangement or the amount of the arrangement, then the activity is
LENDING-DECREASE-TERM.AMOUNT.
2. Options
The structure of this section stays the same. It contains the suffix of the
AA.ARRANGEMENT.ACTIVITY version to be used if any, the
function to be used and the value ‘VALIDATE’ or ‘PROCESS’ to
denote whether the transaction just needs to be validated or committed
etc. Example : TRG/I/VALIDATE

Temenos University - June 2012 12

AA Advanced Customisation - Part 3

3. User Information
No change. This part of the message contains, like for all other kind of
transaction, Sign On Name/Password/Company Code of the user whose
SMS credentials are going to be checked when the OFS message is posted
to T24.
4. Transaction ID
No change here, either. As usual, it holds the Transaction ID and, in case,
the unique Message ID

Temenos University - June 2012 13

AA Advanced Customisation - Part 3

5. Message Data
The ‘Message Data part contains the data required to create or update the
transaction action. As for non-AA transactions, the existing format for
message data is FIELD.NAME:Multi Value Position:Sub Value
Position:=VALUE. As you are already aware, the name of the application
that you need to specify in the OFS message is always
AA.ARRANGEMENT.ACTIVITY – therefore the OFS message should
contain values for the record in AA.ARRANGEMENT.ACTIVITY. Take
a look at the fields in AA.ARRANGEMENT.ACTIVITY. These fields’
values need to be supplied in the OFS message – e.g.
ARRANGEMENT=NEW, ACTIVITY=LENDING-NEW-
ARRANGEMENT,EFFECTIVE.DATE=20120620,CUSTOMER=100301
,PRODUCT=NEGOTIABLE.LOAN,CURRENCY=USD.
You may have noticed that the value ‘NEW’ to which we initialise the
field ARRANGEMENT is later transformed into a standard
AA.ARRANGEMENT ID, i.e. AA120307GNCY and also that, so far, we
have not specified the content of any of the product’s properties. We will
explain these two point and see an example of a complete OFS request
in the next slides.

Please note that AA.ARRANGEMENT.ACTIVITY should be used for any AA

transaction and it is appropriate even when an arrangement is input for the
first time – in this example, you are performing an activity called LENDING-
NEW-ARRANGEMENT, but you may use the same OFS format also for

Temenos University - June 2012 14

AA Advanced Customisation - Part 3

disbursing the commitment of a loan (with activity set to LENDING-DISBURSE-

COMMITMENT), to update the commitment details, to change the repayment rules
etc.

Temenos University - June 2012 14

AA Advanced Customisation - Part 3

Let us try to sum up what we have learnt so far about AA Transactions in OFS
with an example. The request displayed in this slide shows the 5 blocks forming
an AA transaction request (even if the Data Message part is still incomplete, as
we will see)

1. The application name used in Operation is

AA.ARRANGEMENT.ACTIVITY
2. Options are supplied and refer to version
AA.ARRANGEMENT.ACTIVITY,AA. The function is Input and the Process
option is set, so that the records get committed.
3. The User Information’s credentials are supplied
4. Transaction Id is not supplied as AA.RRANGEMENT.ACTIVITY supports
Auto ID generation – so T24 will automatically assign an Id to our new
activity
5. Data Message part:
a. Since this is a new activity to create a new record in
AA.ARRANGEMENT, we assign to the field ARRANGEMENT the
value ‘NEW’. T24 will automatically create a new record in the
AA.ARRANGEMENT table and also populate the ID of the new
arrangement record in this field in AA.ARRANGEMENT.ACTIVITY.
If we were in a scenario where a new activity has to be performed on
an existing arrangement (for instance, disbursing the amount of a loan
we have already created), we would need to input the

Temenos University - June 2012 15

AA Advanced Customisation - Part 3

AA.ARRANGEMENT ID in this position instead .

b. Since the activity to be performed is LENDING-NEW-ARRANGEMENT,
supply that value to the field ACTIVITY
c. Supply values for EFFECTIVE.DATE, CUSTOMER and CURRENCY
d. Supply values for PRODUCT
This OFS transaction request for AA, though, is still incomplete – in fact, as we know,
AA.ARRANGEMENT.ACTIVITY and AA.ARRANGEMENT are not the only two files
which get updated when an activity is performed on an arrangement. Also applications of
the type AA.ARR.<PROPERTY.CLASS>, which contain the actual arrangement details,
will need to be amended – and hence, we have to include them as well in the ‘Data part’ of
our OFS transaction.

Temenos University - June 2012 15

AA Advanced Customisation - Part 3

1. Together with AA.ARRANGEMENT and AA.ARRANGEMENT.ACTIVITY

an OFS request aimed to the creation of an arrangement should also define
contents for its product properties – this is done by updating the relevant set
of AA.ARR.<PROPERTY.CLASS> applications. E.g., when we draw up an
OFS request which creates a new NEGOTIABLE.LOAN arrangement, we
should include in it also a request to update the ‘COMMITMENT’ and the
‘SETTLEMEMENT’ properties, which are associated with the
AA.ARR.TERM.AMOUNT application and with the
AA.ARR.SETTLEMENT application
2. Following is the syntax to supply values for all properties
PROPERTY:Multi Value Position:Sub Value Position:= {Property name}
FIELD.NAME:Multi Value Position:Sub Value Position:= {Field name}
FIELD.VALUE:Multi Value Position:Sub Value Position:= {Field value}

Temenos University - June 2012 16

AA Advanced Customisation - Part 3

3. OFS message
We have to specify PROPERTY, FIELD.NAME and FIELD.VALUE in the OFS
message because these fields belong to the
AA.ARRANGEMENT.ACTIVITY application. These fields are used by
AA.ARRANGEMENT.ACTIVITY to import the supplied property values
into the respective properties for that arrangement. This is because it is not
possible to send an OFS request directed towards a specific property that is
part of the arrangement.

If you take a look at the entire OFS message to create a new arrangement in AA
via OFS. As you can see, the values for the various properties which in-turn
update values in AA.ARR.XXX applications are supplied using the amended
OFS syntax. If you have multiple properties for which values need to be
supplied, then you may do so, by supplying values as specified here

PROPERTY:1:1=COMMITMENT,FIELD.NAME:1:1=AMOUNT:1:1,FIELD.VA
LUE:2:1=8000,FIELD.NAME:1:2=TERM:1:1,FIELD.VALUE:1:2=Y1,
PROPERTY:2:1=SETTLEMENT,FIELD.NAME:2:1=PAYIN.ACCOUNT:1:1,FI
ELD.VALUE:2:1=6077

Note : If you have defaulted values for properties using product

conditions/versions, then you need not specify those properties as part of
your OFS message. For instance, look at the 1st OFS message in the slide

Temenos University - June 2012 17

AA Advanced Customisation - Part 3

above. It only contains values for the properties COMMITMENT and SETTLEMENT
that belong, respectively, to the property class TERM.AMOUNT and to the property
class SETTLEMENT. This means that the values for all other the properties
associated with the NEGOTIABLE.LOAN product have been defaulted from
product conditions or version’s settings.

Temenos University - June 2012 17

AA Advanced Customisation - Part 3

If you take a look at this AA.ARRANGEMENT.ACTIVITY record, you can see

that the field values for the two properties supplied in the OFS message for AA
have been mapped to each of the properties and therefore for each of the property
classes.

Temenos University - June 2012 18

AA Advanced Customisation - Part 3

It is possible to define local reference fields in any of the AA Property classes

which will get inherited at the arrangement level. Now, if there is arrangement
specific data that need to be imported into a Local ref field during data migration,
then it can be supplied in the OFS Message in the same manner as if it was a
system field.
In this slide, we can see an example – a local reference field named
POST.REST.TA has been created for the property class TERM.AMOUNT. If we
want to assign a value to the local reference field and assign the field to the
correct property (i.e. COMMITMENT), we should include it in our OFS string
just like any others. In this example, the local reference field name is highlighted
through a red frame and the value assigned to it is ‘1’.

Temenos University - June 2012 19

AA Advanced Customisation - Part 3

We can choose to test our OFS message through a direct TELNET connection,
which is currently an obsolete way of using the TELNET mode but it is quite
handy for testing purposes (normally we would connect to T24 in TELNET mode
through a listener e.g. TCServer).
In order to do so, we access the jshell prompt and start a tSS (T24 Server Session)
using the ID of an OFS.SOURCE record of type TELNET to feed the correct
connection parameters to the session.
Once the session is started, we can supply our OFS request and then press enter to
post it.
Look at the highlighted section in the output. It is the new AA.ARRANGEMENT
id that has been generated. Please note that only partial output of the OFS
message is displayed .

Temenos University - June 2012 20

AA Advanced Customisation - Part 3

Like all other kind of OFS messages, AA transactions can be posted to T24
through all the 4 modes of OFS – namely TELNET, SESSION, GLOBUS and
BATCH. We have seen an example of a message posted in the TELNET mode, in
the previous slide. We know that OFS works through SESSION, as well, because
of all the previous OFS requests we have posted through the Browser Interface
during this training course. We can now have a look to how OFS messages for
AA are posted in the GLOBUS, mode instead.
As you will certainly remember from the OFS course, there are two APIs which
can be embedded in T24 subroutines to post OFS messages –

1. OFS.GLOBUS.MANAGER (often referred to as OGM), which is only used

by core T24 subroutines but is not available for local development

2. OFS.POST.MESSAGE (OPM) which is currently used for posting any kind

of OFS messages from T24 routines. OFS.POST.MESSAGE takes 4
parameters:
a. OFS.MESSAGE : In parameter. The OFS message to be processed
b. OFS.MSG.ID: Out parameter. Auto generated message id.
c. OFS.SOURCE.ID: In parameter. OFS source record id of type Globus
d. Options: reserved for future use
As soon as the routine containing this API is invoked, OPM places the
OFS message positioned as its first parameter to the
F.OFS.MESSAGE.QUEUE activation file. This queue is processed by a

Temenos University - June 2012 21

AA Advanced Customisation - Part 3

service named OFS.MESSAGE.SERVICE, which picks up the message within it,

processes the OFS message posting it to T24 and then writes a response within the
F.OFS.RESPONSE.QUEUE file.

In the example shown on this slide, a mainline routine with ID TEST.OFS.AA.GLOBUS

which contains an OPM from the T24 Toolbox editor. The OFS string contained in the
routine is a request to authorise the activity previously generated through in TELNET
mode. Please note that the OFS.SOURCE mentioned in the third option of
OFS.POST.MESSAGE has the SOURCE.TYPE field set to GLOBUS.

Temenos University - June 2012 21

AA Advanced Customisation - Part 3

The routine shown in the previous slide has to be written, compiled and set up in
PGM.FILE as a type ‘M’ record. As soon as we run the routine from T24, the
OFS message contained in it is written to F.OFS.MESSAGE.QUEUE

Temenos University - June 2012 22

AA Advanced Customisation - Part 3

Finally, when we run the OFS.MESSAGE.SERVICE process, the OFS request is

posted to T24.
In the screenshot we can see the content of the record created within the
F.OFS.RESPONSE.QUEUE. As we may notice the first part of this record ID
matches with the first part of the ID of the record in the
F.OFS.MESSAGE.QUEUE in the previous slide. The content of this response
record confirms that the activity with ID AAACT120302570FD03 has been
successfully authorised – and this is confirmed by the corresponding
AA.ARRANGEMENT.ACTIVITY record in T24.

Please note that note that, even if a mainline routine is used here, ANY kind of
T24 routines may embed OFS messages – so we could have used a TYPE ‘S’ or
‘B’ routine or maybe even an EB.API routine used for Versions (e.g.
Authorisation routines etc).
For further information regarding Inter Application calls with GLOBUS mode,
please refer to the Oper Financial Services training course.

Temenos University - June 2012 23

AA Advanced Customisation - Part 3

The last mode through which we can post messages to T24 is BATCH. Like for
TELNET, OFS requests can use BATCH directly or through listeners like
TCServer. In this case, we will show an example of a direct BATCH connection.
As we know, in order to work we the BATCH mode, we need to define an
OFS.SOURCE record with SOURCE.TYPE field set to BATCH and mentioning
the IN.QUEUE and OUT.QUEUE directories from which the appropriate
phantom (linked to the OFS.SOURCE record) will pick up requests and write
responses, respectively. It is crucial that the processing phantom is linked to the
correct OFS.SOURCE for it to know from which queue OFS requests have to be
read and also the field RUN.ROUTINE in this EB.PHANTOM record should
always be set to OFS.QUEUE.MANAGER as this is the routine which initiates
OFS processing in BATCH mode. As we know, the BATCH processing will be
started as soon as this EB.PHANTOM record is verified.

Temenos University - June 2012 24

AA Advanced Customisation - Part 3

1. Before verifying our phantom, we need to create – within our IN routine, a

record containing the AA OFS request we whish to execute. The ID of the
RECORD can be any name of your choice – here we use RECORD1. Once
created, we place the OFS message we want to post in it. We can now run our
phantom.
2. Once processed, the response will be palced in the reponse queue directly and
the name of the record that will hold the response is the same as the request’s
one. If we take a look at the RECORD1 content, we’ll see the output of the
OFS message that has been processed successfully.

Temenos University - June 2012 25

AA Advanced Customisation - Part 3

Temenos University - June 2012 26

AA Advanced Customisation - Part 3

Let us now introduce the concept and use of a T24 API called
OFS.BULK.MANAGER. Please note that OFS.BULK.MANAGER is not a
published T24 API. It is internally used by the OFS framework in T24. To start
with, we need to understand the flow of a standard message in OFS and then see
what changes if the message processed is an AA transaction.

Let us take the example of a transaction to set up a new account issued through
the Browser interface of T24.

1. tSS (which stands for T24 Server Session) is a process spawned by a T24
server listener (e.g. TCServer) and it enables this component to send requests to
the OFS framework. This was originally called
OFS.CONNECTION.MANAGER and then rechristened to tSS to comply with
the standard name structure for T24 process names (similarly to tSM and tSA). To
sum up, tSS is an interface between a T24 server listener and OFS. The OFS
message is posted to T24 via tSS anytime it relies on a listener – in case we have,
instead, a message posted to T24 in BATCH mode though an IN QUEUE, the
routine that picks up OFS strings from the queue is called
OFS.QUEUE.MANAGER. For GLOBUS mode, as we have seen, this task is
performed by the OFS.MESSAGE.SERVICE service.
2. When tSS receives a request, this process passes it to the
OFS.PROCESS.MANAGER routine which checks whether the incoming request
is a delivery request or not (in case it is, the application name in the OFS message
will be ‘DE.CARRIER’). If the request isn’t a delivery request, then

Temenos University - June 2012 27

AA Advanced Customisation - Part 3

OFS.PROCESS.MANAGER calls OFS.SESSION.MANAGER (only if the OFS message

is posted in a SESSION mode).
3. OFS.SESSION.MANAGER as the name denotes, manages requests in the SESSION
mode, i.e. those posted to the Browser Interface, and the connected Token processing
(which means the association of a Token to each Browser requests to avoid message
duplication – for more detailed information regarding this Browser feature, please refer to
the T24 Administration technical course). OFS.SESSION.MANAGER then invokes the
OFS.REQUEST.MANAGER routine.
4. OFS.REQUEST.MANAGER decides whether the incoming browser request is an
enquiry request or a transaction request. In case the OFS message consists of a transaction
request, OFS.REQUEST.MANAGER will also look after the actual message processing.
Else, if the OFS message is an enquiry request, the ‘Request Manager’ routine will call
OFS.ENQUIRY.MANAGER to do the processing

Temenos University - June 2012 27

AA Advanced Customisation - Part 3

The above screen shot shows how messages used to be processed when
OFS.BULK.MANAGER was not used for transaction processing.
1. Imagine a situation where in an input on an account record is committed using
T24 Browser. The request to commit the record passes through the Application
Server (where e.g. Jboss is installed and the Servlet component is deployed), then
is received by the listener on the T24 Application server (e.g. TCServer) and then
it reaches tSS .
2. Assume that this is the OFS message that reaches tSS (Note that requests from
Browser rely on BROWSERXML syntax but to ease the process of learning,
message in OFS syntax has been used here). tSS would have invoked
OFS.PROCESS.MANAGER, OFS.SESSION.MANAGER and finally
OFS.REQUEST.MANAGER.
3. Once the Request Manager routines kicks in, the actual application in charge of
updating the appropriate Database Table with the new record is invoked
(ACCOUNT in this case). The logic within the ACCOUNT application will
a. Validate data
b. Make ready the record to be written into the appropriate
ACCOUNT data file (Live or Unauthorised, depending on the number of
authorisers)
c. Make ready the record(s) to be written to other concat files, live
files, other application’s data files (E.g. CUSTOMER.ACCOUNT)
Once the data is all set to be written, the ACCOUNT application (or any
application in T24 for that matter), branches off to the transaction processing

Temenos University - June 2012 28

AA Advanced Customisation - Part 3

framework.
The term “transaction processing framework” here refers to a set of internal calls made by
the main application to the UNAUTH.RECORD.WRITE API (which is called when a
record is committed) and to the AUTH.RECORD.WRITE API (which is called when a
record is authorised). These T24 APIs internally call another one named
JOURNAL.UPDATE.
JOURNAL.UPDATE is the T24 API that takes care of transaction management in T24. It
internally invokes the EB.TRANS API with the first parameter set to START in order to
mark the beginning of a transaction block, i. e. a set of transactions which are either all
executed successfully after being written to cash or which are all rolled back in case even
only one of them fails. While a transaction block in open, all records that need to be
written to disk are written to cache and then a check is performed to see if the writes have
been successful. If yes, EB.TRANS (END,’’) is called to denote the end of a transaction
block. At this point, all data is flushed from memory to disk. If not successful, EB.TRANS
with ABORT set as first parameter is called to abort the whole block of transactions. At
this point in time, all records that were written to cache memory are flushed out of it.

The crucial thing that you need to note here is that, though multiple files and applications
get updated, the OFS request that came in is just ONE. Where as for arrangements in AA,
this will not be the case. Let us discuss this in detail as we proceed.

Temenos University - June 2012 28

AA Advanced Customisation - Part 3

Before you proceed to understand OFS.BULK.AMANGER, there are certain

concepts that you need to be clear with. When a new arrangement is created, you
know that an activity LENDING-NEW-ARRANGEMENT is triggered. You
know that every valid activity has an entry in AA.ACTIVITY.CLASS application.
Take a look at the record in the slide above, which represents just the top part of
the LENDING-NEW-ACTIVITY record in the AA.ACTIVITY.CLASS
application.
When a LENDING-NEW-ARRANGEMENT activity is performed, a new record
is manually created in the AA.ARRANGEMENT.ACTIVITY table and a set of
updates to other tables are triggered internally – these internal updates are listed
in this AA.ACTIVITY.CLASS record. Every highlighted section in the
screenshot above explains which other action will be internally invoked anytime
a LENDING-NEW-ARRANGEMENT activity is manually created. For instance
1. Invoke the UPDATE action of the property class CUSTOMER. Which means,
internally a routine named AA.CUSTOMER.UPDATE will be invoked to
update the AA.ARR.CUSTOMER application
2. Invoke the UPDATE action of the property class OFFICERS. Which means,
internally a routine named AA.OFFICERS.UPDATE will be invoked to
automatically update the AA.ARR.OFFICERS application
3. Invoke the UPDATE action of the property class LIMIT. Which means,
internally a routine named AA.LIMIT.UPDATE will be invoked to perform
an input on the AA.AA.LIMIT application
And so on and so fort.

Temenos University - June 2012 29

AA Advanced Customisation - Part 3

(Note that there are other activities listed in the record which will also be triggered but
only some of them will result in an actual table update as not all the mentioned
property classes may be mandatory in a product)

Temenos University - June 2012 29

AA Advanced Customisation - Part 3

1. Take a look at this AA.ARRANGEMENT.ACTIVITY record that gets created

when a new arrangement is generated (i.e. the activity performed is
LENDING-NEW-ARRANGEMENT). When such an activity is performed,
an OFS message would have got generated to create this new arrangement in
T24.

2. Try to recall the properties of the LENDING-NEW-ARRANGEMENT record

in the AA.ACTIVITY.CLASS table, discussed in the previous slide. As part
of the LENDING-NEW-ARRANGEMENT activity you know that action
routines such as AA.CUSTOMER.UPDATE, AA.OFFICERS.UPDATE,
AA.LIMIT.UPDATE etc. would get triggered to automatically update,
respectively, the AA.ARR.CUSTOMER application, the
AA.ARR.OFFICERS application, the AA.ARR.LIMIT application and many
others with name syntax of the kind AA.ARR.<PROPERTY.CLASS>. All
these AA.ARR.<PROPERTY.CLASS> applications, together with
AA.ARRANGEMENT.ACTIVITY, AA.ARRANGEMENT,
AA.PROCESS.DETAILS etc. have to be updated – therefore one OFS
message would have to be formed for each of these applications . Details of
these automatically triggered OFS requests are shown within the
AA.PROCESS.DETAILS application, which shares the same ID as the
AA.ARRANGEMENT.ACTIVITY record.

When an arrangement is input, T24 forms multiple OFS messages (OFS

messages all grouped together but delimited with a FM tag) in order to update

Temenos University - June 2012 30

AA Advanced Customisation - Part 3

both the AA.ARRANGEMENT.ACTIVITY and the required

AA.ARR.<PROPERTY.CLASS> applications . These multiple OFS messages are sent
to T24 via the TCServer or jbase_agent or TAFC_agent. The job of T24 now is to treat
all these OFS messages as a single transaction and process all or none of them. The
crucial point to note here is that the T24 Server listener in charge will now pass on an
OFS message which contains multiple other OFS messages delimited with FM. The
listener is not passing just a single OFS message, as we saw in the previous example
(i.e. the OFS message to update the ACCOUNT application)

Temenos University - June 2012 30

AA Advanced Customisation - Part 3

1. In order to make it possible for T24 to receive multiple OFS messages

together within a transaction block, an API called 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 bulk OFS requests are present, OFS.BULK.MANAGER splits them, and
stores then in a queue in cache memory named c_Txn_RequestQueue.
4. Once all the messages are ready, OFS.BULK.MANAGER starts a transaction
block and for each message it uses the same route of
OFS.PROCESS.MANAGER, OFS.SESSION.MANAGER,
OFS.REQUEST.MANAGER and finally the appropriate T24 applications
5. The transaction management framework in T24 has been modified in such a
way that T24 applications respect the transaction boundary started by
OFS.BULK.AMANGER and they don’t start one on their own.
6. Once all messages have been processed successfully,
OFS.BULK.MANAGER marks the end of the transaction block and commits
all the transactions. If 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

Temenos University - June 2012 31

AA Advanced Customisation - Part 3

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? When you input an
arrangement, you want all related applications to be updated or none to be updated. If
this is what you want then OFS.BULK.MANAGER controlling transaction
management is correct.

Temenos University - June 2012 31

AA Advanced Customisation - Part 3

1. Any request to execute an enquiry is not considered a bulk request. An

enquiry request just picks data from the database and does not update data
in a database. For enquiry requests, the application name in OFS would be
ENQUIRY.SELECT
2. Applications in T24 can explicitly state that they do not want
OFS.BULK.MANAGER to handle transaction management. In such a case,
these applications’ records in PGM.FILE will the field
ADDITIONAL.INFO set to .NBK (No Bulking). E.g.
AA.PRODUCT.MANAGER
3. OFS request for an application which has the field TYPE in PGM.FILE set
to S or W. Records in PGM.FILE with TYPE set to S denote that they are
subroutines and TYPE set to W denotes that they are work files (Meaning
you can verify records in such applications). For such type of applications,
there is no need to bulk and hence not considered a bulk request
4. An OFS message for delivery which will have application name in the OFS
message set to DE.CARRIER will not be bulked. Please note that, such
requests are internally handled by OFS.DE.REQUEST.
5. If PGM.FILE record does not exist for the Operation entry, e.g. TEC

Temenos University - June 2012 32

AA Advanced Customisation - Part 3

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
and therefore this is not a bulk request. How will OFS.BULK. MANAGER work
in this case?
When an OFS message is received, OFS.BULK. MANAGER checks to see 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. At this point the application is invoked and
the control is passed on to the transaction processing framework which controls
the transaction block (see slide 153).

Temenos University - June 2012 33

AA Advanced Customisation - Part 3

Temenos University - June 2012 34

AA Advanced Customisation - Part 3

1. What you see on the bottom part of this slide, is a screenshot representing a
part of an AA.PROCESS.DETAILS record which got created when a new
arrangement was input. You have seen such records before. But, if take a look
at the highlighted section, you will notice that the for the application
AA.ARR.ACTIVITY.MESSAGING (used in the ,AA.NONINPUT version)
the function used is ‘M’. What does this M signify?
2. To understand this, take a look at the AA.ACTIVITY.CLASS record of
LENDING-NEW-ARRANGEMENT
If you look at the ACTIVITY.MESSAGING property classes specified in
LENDING-NEW-ARRANGEMENT, it has the field User Input set to NO for
the SEND.MESSAGE action. So far, we had only seen examples of Activities
applied to Property Classes for which the USER.INPUT field was set to YES
(see slide 155).
As the name suggests, the field ‘User Input’ specifies whether an action on a
given property’s arrangement condition can be performed manually by a user
or not. When USER.INPUT is set to NO, it denotes that user manual update is
not permitted. Any activity for which ‘User Input’ is set to ‘NO’, when an
OFS message is formed, ‘M’ is the function that will be used as part of the
OFS message. Unlike I or A or D or any other T24 function that you are
already aware of, M works differently. When function is ‘M’, the underlying
application’s call to UNAUTH.RECORD.WRITE/AUTH.RECORD.WRITE
will not be triggered’. More details on this as you proceed.

Temenos University - June 2012 35

AA Advanced Customisation - Part 3

When we commit or authorize a record in any application in T24, the route that it
follows is what is depicted diagrammatically. First, the THE.TEMPLATE routine
is called followed by the .INITILIASE to perform any application specific
initialization. Once done, the fields and their properties are read and the fields are
built and are ready to be displayed. First, the ID is accepted, validated and if the
key validation is successful, the corresponding record is fetched from the disk or
a new record is created as the case may be (RECORD.READ). Once the record
has been read and after the user has filled in the appropriate fields, the record data
is validated and overrides are, in case, generated. Once all validations are
successful and all override messages are accepted or corrected, the data control
passes to the T24’s transaction processing framework. The
UNAUTH.RECORD.WRITE API or the AUTH.RECORD.WRITE API are
called to write into unauthorized or to live files respectively (concat files and
connected live files are also updated if it is so coded in the application). If
function is I only UNAUTH.RECORD.WRITE will be called and if function is A
only AUTH.RECORD.WRITE will be called. This will not be the case for a 0
authorizer version. In this case, both will be called.

Temenos University - June 2012 36

AA Advanced Customisation - Part 3

When function used is M, an application takes the normal route, but once the
record is read and stored in memory, it restrains from performing any validation
on the record and therefore does not call the T24’s transaction processing
framework. The control passes to the action routine.
Understand this with an example. In the LENDING-NEW-ARRANGEMENT
activity class, the property class ACTIVITY.MESSAGING was specified with
action SEND.MESSAGE and with the USER.INPUT field set to NO (see slide
160). When ever M function is used, it denotes that data in that particular
application will not be altered manually. In this case, data in
AA.ARR.ACTIVITY.MESSAGING is not going to be altered manually. The data
in it is just read and used. Since there is no data alteration, the sections in light
yellow in the slide above are not invoked. After the current record is read, the
application control skips the routines in light yellow and moves directly to the
action routine.

Temenos University - June 2012 37

AA Advanced Customisation - Part 3

Temenos University - June 2012 38

AA Advanced Customisation - Part 3

Let us now analyse the structure of an OFS request aimed to simulate an activity.
The example shown in this slide is the simulation of a new lending arrangement
creation (the product used is NEGOTABLE.LOAN). The same structure,
however, applies to any simulated activity.
The structure of this kind of OFS message is very similar to the structure of an
OFS message aimed to create a new activity in AA, with a few significant
changes.
1. The first important difference is that, of course, the application name used in
the Operation part of the message is always AA.SIMULATION.CAPTURE
for simulated activities, instead of AA.ARRANGEMENT.ACTIVITY
2. Options are supplied or (in this case) left blank and defaulted in the usual
way.
3. The User Information’s credentials are supplied as in any OFS message
4. Transaction Id, in this example, is not supplied as also
AA.SIMULATION.CAPTURE supports Auto ID generation – so T24 will
automatically assign an Id to our new simulated activity
5. Data Message part:
a. Since this is a new activity to create a new record in
AA.ARRANGEMENT, we assign to the field ARRANGEMENT the
value ‘NEW’. T24 will automatically create a new
AA.ARRANGEMENT ID.If we were in a scenario where a simulated
activity has to be performed on an existing arrangement (for instance,
disbursing the amount of a loan we have already created), we would

Temenos University - June 2012 39

AA Advanced Customisation - Part 3

need to input the AA.ARRANGEMENT ID in this field .

b. Since the activity to be performed is LENDING-NEW-ARRANGEMENT,
supply that value to the field ACTIVITY
c. Supply values for EFFECTIVE.DATE, CUSTOMER, PRODUCT and
CURRENCY
d. Supply values for AUTO.RUN – AUTO.RUN is the field which enables a
simulation to be run or to be executed (which means put to live). In this case it
is set to SIMULATE which implies that, once the
AA.SIMULATION.CAPTURE record is authorised, it will be made available
to the AA.SIMULATION.RUNNER application which will actually carry out
the simulation.
e. Like for a standard activity, this OFS message will also contain information
regarding the properties to be updated for this specific product. In this
example, we are updating the COMMITMENT and the SETTLEMENT
properties – if the were dealing with an actual activity, this would mean that
the AA.ARR.TERM.AMOUNT (linked to the Commitment property) and the
AA.ARR.SETTLEMENT application will need to get updated. As we are
dealing with a simulation, though, the two Property Class specific applications
which will be updated because of this OFS request are
AA.SIM.TERM.AMOUNT and AA.SIM.SETTLEMENT – as we will
remember, the standard name syntax for these applications is
AA.SIM.<PROPERTY.CLASS>.

Temenos University - June 2012 39

AA Advanced Customisation - Part 3

From the response we get (partially shown in the screenshot on the top of this
slide), we can see that our transaction request has been successfully processed, as
the Success / Fail indicator is set to 1.
Now we will authorise the previous request to analise the response we get.

Temenos University - June 2012 40

AA Advanced Customisation - Part 3

Simulation capture ID – Id of the record in the application

AA.SIMULATION.CAPTURE. This is the application which is used to capture
information on the simulation. On authorising the application, a record is created
in AA.SIMULATION.RUNNER and a OFS message similar to the one shown in
the screen shot is generated in the list file AA.SIMULATION.SERVICE.LIST
(when “AUTO.RUN” field in AA.SIMULATION.CAPTURE is set to “simulate”,
else the user has to create the record manually). This message will be processed
and the activity simulated on running the service AA.SIMULATION.SERVICE .
This service will pick up the request from the list file
AA.SIMULATION.SERVICE.LIST.

Simulation Runner Reference – Id of record created in the application

AA.SIMULATION.RUNNER. This file is used to hold information on all the
activities that are being simulated on a particular arrangement. Whenever a
record is authorised in the application AA.SIMULATION.CAPTURE a record is
created in the AA.SIMULATION.RUNNER. The information on activities are
captured in the set of multi value fields “S.ACTIVITY” (Scheduled Activity),
“U.ACTIVITY” (User Activity), “T ACTIVITY” (Transaction Activity). Please
note that also authorising a record manually created in
AA.SIMULATION.RUNNER will generate an OFS request and place it in the list
file AA.SIMULATION.SERVICE.LIST.

Activity INIT Type – Whether the activity is User initiated or a Scheduled

activity (USER)

Temenos University - June 2012 41

AA Advanced Customisation - Part 3

Trigger activity – Activity that is currently being simulated on the arrangement

(LENDING-NEW-ARRANGEMENT).

Effective Date – Date on which the particular arrangement is effective

Temenos University - June 2012 41

AA Advanced Customisation - Part 3

Temenos University - June 2012 42

AA Advanced Customisation - Part 3

We are now about to discuss some important APIs which can be used within OFS
messages to build AA transaction requests.

AA.GET.ARRANGEMENT.CONDITIONS

This routine can be used by any application to retrieve the product conditions that
apply to an arrangement for a particular effective date (default value is TODAY)

The specific property or property class required must be supplied

The records and ids for the property conditions that apply are returned

It accepts seven parameters

Temenos University - June 2012 43

AA Advanced Customisation - Part 3

Temenos University - June 2012 44

AA Advanced Customisation - Part 3

AA.GET.PUBLISHED.RECORD

This routine will analyse the published property / product structure and return the
published record detail. It is intended to be used only from the Arrangement level

The parameter STAGE is optional now - the stage would be assumed as

AA$PUBLISH if nothing is stated.

It takes six parameters

Temenos University - June 2012 45

AA Advanced Customisation - Part 3

Temenos University - June 2012 46

AA Advanced Customisation - Part 3

AA.GET.ACTIVITY.CLASS

This simple routine returns the activity class to which the activity belongs

It can take two parameters

Temenos University - June 2012 47

AA Advanced Customisation - Part 3

AA.GET.ARRANGEMENT.PRODUCT

This routine returns the product that the arrangement is running on and the
properties linked to it

It can take five parameters

Temenos University - June 2012 48

AA Advanced Customisation - Part 3

Temenos University - June 2012 49

AA Advanced Customisation - Part 3

Temenos University - June 2012 50

AA Advanced Customisation - Part 3

What is ACTIVITY.API? What is the role of this Property Class in AA

Customisation?
As it is impossible to directly attach routines to AA.ARR.<PROPERTY.CLASS>
applications, ACTIVITY.API allows to associate a certain routine to a Property
and to an Activity within a Product

Which kind of routines can we associated with AA screens through

ACTIVITY.API?
Since R12, 5 kind of routines can be linked to product conditions for
ACTIVITY.API and then associated with a product –
1) Pre-validate routines
2) Validate routines
3) Record routines
4) Pre-routines
5) Post-routines

What is the name of the Property Class which allows advices to be linked to AA
products?
ACTIVITY.MESSAGING.

Is it possible to suppress advices for a single arrangement without updating the

general settings for a product?

Temenos University - June 2012 51

AA Advanced Customisation - Part 3

Yes, individual advices can be suppressed on the arrangement record by setting the
SEND.ADVICE field to ‘NO’ within the ‘Messaging’ property.

Which application is used to subscribe or un-subscribe to specific ALERTS?

EB.ALERT.REQUEST

Which application name do we use in the ‘Operation’ part of an OFS message when we
want to request a new arrangement creation?
AA.ARRANGEMENT.ACTIVITY

Temenos University - June 2012 51

AA Advanced Customisation - Part 3

Temenos University - June 2012 52

AA Advanced Customisation - Part 3

Temenos University - June 2012 53

AA Advanced Customisation - Part 3

Temenos University - June 2012 54