Aaadvancedcustomisationpart3.pdf

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 subparts, separated from one another through a forward slash sign. The subparts 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-NEWARRANGEMENT if we are creating a brand new loan) AA.ARR. – 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-NEWARRAMGEMENT. 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-NEWARRANGEMENT,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 LENDINGNEW-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-DISBURSECOMMITMENT), 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., 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. 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.. All these AA.ARR. 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. 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.

2.

3.

4.

5.

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

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