Welcome to “T24 Delivery Carriers eMAIL, SMS and Secure Message” learning unit.

This learning unit

will teach you to configure and use SMS, eMAIL and Secure Message delivery carriers in T24.

After completing this learning unit, you will be able to:

¨ Understand the architecture of Delivery carriers- SMS, eMAIL and Secure Message

¨ Configure applications related to these carriers

¨ Set up eMAIL and SMS using related jar files

T24 core delivery module has been enhanced to introduce new email and SMS carriers. This has
facilitated creation of email / SMS as a core delivery message.

Explanation of Overview Diagram:

T24 core delivery module constructs email messages as an XML package (providing all the required
content and formatting information).

It then invokes the java email carrier interface. Java email carrier interface then converts the xml string
into an email object and uses open source Java Mail API’s to transport email message to an SMTP
server.

Explanation of the Overview Diagram:

Message is generated in T24 as per the user requirements. Then the generated message is passed to
the Java SMS interface using a jBASE API called CALLJ, as XML data.
The interface, using the data it received, constructs the XML requests based on a predefined XML
schema defined by the client and sends it to the client over the HTTP/S.

The client SMS gateway contacts the addressed handset and delivers the message. It comes back with
the response and the response is passed back to T24 as acknowledgement.

A secure message is a message that a customer will see when he/she logs in through his/her Internet
Banking (ARC-IB) account into T24. Basically, an enquiry is running in the front end, that displays all the
secure messages for that customer from an application called EB.SECURE.MESSAGE.

Explanation of the Overview Diagram:

A transaction is performed in T24 for that customer. The customer has requested for a secure message to
be sent to his IB (Internet Banking account).

The message, which is in XML format, goes through the SECURE MESSAGE INTERFACE.

The message is then converted into an OFS String and written into a file called
F.OFS.MESSAGE.QUEUE. The OFS string is to create a record in the
application EB.SECURE.MESSAGE.

Starting the OFS.MESSAGE.SERVICE will pick up the OFS String from the above queue.

And create a record in the application EB.SECURE.MESSAGE. Now, when this customer logs into his/her
IB account, he/she will be able to see the Secure
message waiting for him/her.

The CUSTOMER application has been modified to introduce new fields for the Delivery Carriers email,
SMS and Secure Message.

In the field SMS, the mobile number of the customer along with the country code needs to be entered. As
soon as the CUSTOMER is authorised, a record is automatically created in DE.ADDRESS with ID as
<Company.Code>.C-<Customer.ID>.SMS.1.

In the field EMAIL, the email ID of the customer needs to be entered. As soon as the CUSTOMER record
is authorised, a record is automatically created in DE.ADDRESS with ID as <Company.Code>.C-
<Customer.ID>.EMAIL.1.

In the field SECURE.MESSAGE, a value of “YES” needs to be entered, indicating that this customer
would like to enable secure messages for his/her profile. As soon as the CUSTOMER record is
authorised, a record is created automatically in DE.ADDRESS with ID as <Company.Code>.C-
<Customer.ID>.SECUREMSG.1.

Compare this functionality to DE.ADDRESS record being created for the PRINT.1 address of the
CUSTOMER when the CUSTOMER record is authorised.

Three new outward carriers have been introduced in T24.

The Delivery Parameter setup file DE.PARM is updated with the new Delivery Carriers. The record
SYSTEM.STATUS has been appended with the three carriers namely SMS, EMAIL and SECUREMSG.

Corresponding records have to be created in DE.CARRIER. As you have already learnt a record in
DE.CARRIER contains details of delivery carriers available in T24.

A new FORMAT.MODULE has been introduced called XML apart from the regular PRINT and SWIFT
earlier available. This is because SMS, EMAIL and
SECUREMSG are sent as a XML format to their respective carriers. A new application called
DE.FORMAT.XML has been introduced to format records in XML.

The advice, as stated earlier is sent through an interface. You are already aware that if an interface
should be used then the CARRIER.MODULE should be
GENERIC.

The interface to be used is specified in the field INTERFACE which is nothing but the ID of the record in
DE.INTERFACE file. This file contains the actual
definition of the INTERFACE. A screen shot of DE.INTERFACE has also been shown for your
understanding.

Once the delivery advice has been formatted the routine specified in the field OUT.IF.ROUTINE is invoked
to carry on further processing of the delivery
advice.
You can see the sample screen shot of DE.CARRIER record and DE.INTERFACE record for SECURE
MESSAGE delivery carrier.

The field FORMAT.MODULE is set to “XML”, which means that the message will be formatted using a
record in the application DE.FORMAT.XML.

The field CARRIER.MODULE is set to “Generic”, which means that an Interface will be used to send the
message to its carrier or final destination.

The field INTERFACE contains the name of the Interface through which the message will pass through. A
data here, as you can see, is the ID of a record in
the application DE.INTERFACE.

Notice that the OUT.IF.ROUTINE field contains the name of the actual routine that is responsible for the
transportation of the message.

To make the whole system more user friendly, a CUSTOMER can now login through Temenos Internet
Banking product and go to his/her settings and decide what carrier they would like their advices to be
delivered to them.

Basically this screen that you see is a version of the application DE.CUSTOMER.PREFERENCES. When
a customer enters his/her preferences here and saves it, a record is created in this application.

As you can see, this customer wants his Credit Advices to be sent through PRINT, SMS, EMAIL.

In order to provide a more user friendly interface to DE.PRODUCT, two applications called
DE.CUSTOMER.PREFERENCES and DE.MESSAGE.GROUP has been created.

The record that you see here, is the corresponding record created in DE.CUSTOMER.PREFERENCES.

The ID of a record in this application is the customer number.

The field MESSAGE.GROUP contains the ID of a record in DE.MESSAGE.GROUP. Delivery messages

can be grouped by meaningful terms such as Statement,
Advice, Alert etc., through a new application DE.MESSAGE.GROUP. A record in this application contains
the message type that will eventually make up the
ID of the record in DE.PRODUCT.

For e.g.: 910 is the message type for Credit Advices. “910.ALL” signifies that 910 type of messages
generated from any application form a group. Based on information entered in here, a record is created in
the application DE.PRODUCT with id GB0010001.C-100224.910.ALL.

The field CARRIER specifies how the delivery advice should be sent to the customer.

The ADDRESS field contains the address of the customer that the advice must be sent to.

The FORMAT field contains the format record to be read for formatting the advice.

The LANGUAGE field contains the language in which the advice should be generated in.

NOTE:
When a user enters his/her preferences through the Internet Banking screen, the data to be filled up in
fields ADDRESS, FORMAT and LANGUAGE is populated as AUTO.NEW.CONTENT from the version
and is updated here.

The corresponding record is created in DE.PRODUCT. This record is created automatically when record
is authorised in DE.CUSTOMER.PREFERENCES.

Please go through the contents of this record. You will find that all the data from the
DE.CUSTOMER.PREFERENCES record has been updated to appropriate fields in this record.

As stated earlier, an email is sent from T24 through a java email carrier to the SMTP server. The steps
that you are going to see now, is going to help you set up the necessary jar files.

Create a folder called jars inside bnk.run folder. Inside this create a folder called t24email. Place the
following jar files inside this folder - t24email.jar,
activation.jar, mail.jar and xercesImpl.jar. Create a folder called config.

Inside the folder config, create a file called t24email.properties. Type the data that you see in the screen
inside this file and save it. Please note that the IP
address entered here is the IP Address of the SMTP server. You will have to enter the IP address of your
SMTP server configured in your company. For
WINDOWS, enter the SMTP server name. For eg: MAAEXCHANGE.asia.temenosgroup.com.

The next step is to open your remote.cmd (for WINDOWS) or .profile (FOR UNIX) and append to the
environment variable CLASSPATH with what you see
on the screen now. Please note that the screen shot that you see here is taken from a windows
environment. For a UNIX environment you will have to
replace the “;” with a “:”

As stated earlier, an SMS is sent from T24 through a java SMS carrier to the SMS Gateway. The steps
that you are going to see now, is going to help you set up the necessary jar files.

In the jars folder (that you created earlier), create another folder called t24sms. Place the following jar
files inside this folder – t24sms-ci.jar, t24sms-impl.jar, xercesImpl.jar. Create a folder called config.

Inside the folder config, create a file called t24-sms.properties. Enter the data as shown in the screen.
Before you do this step, you will have to register with Clickatell SMS Gateway service through
www.clickatell.com. Upon successful registration you will receive an API ID, along with user ID and a
password. You will have to enter these details in the properties file, as shown in the screenshot. You will
also have to enter the proxyHost and the proxyPort details that is used in your company.

The next step is to open your remote.cmd (for WINDOWS) or .profile (FOR UNIX) and append to the
environment variable CLASSPATH with what you see on the screen now. Please note that the screen
shot that you see here is taken from a windows environment. For a UNIX environment you will have to
replace the “;” with a “:”

The formatting is done according to a record in DE.FORMAT.XML. In case of email ,SMS and Secure
Message the formatted output is an xml message. You can design the contents of an email ,SMS and
Secure Message using this application. The ID of a record in this application is similar to the
DE.FORMAT.PRINT ID, It is a combination of DE.MESSAGE ID, the Application Format.

Format Version Number and Language.

For e.g.: 910.2.7.GB

The field DATA.NAME, contains the name of an XML tag element. This field can contain any variable
name or a variable defined in DE.MESSAGE.

The field TEXT is used to specify any string value within quotes.

The field PRODUCE.SCHEMA can be set to YES or NO, when the value is “YES”, a record is created in a
file called.

F.DE.XML.SCHEMA. This file contains all the schema definitions required to produce a xml message.
F.DE.XML.SCHEMA contains XML schema definition records (XSD). An XML schema describes the
structure of an XML document.

Take a look at the XSD record created for the corresponding DE.FORMAT.PRINT record that you saw in
the previous slide. All the DATA.NAME fields have been listed as XML tag elements. These tags will hold
the values that were specified in the field TEXT or a value from the HANDOFF record (by specifying the
corresponding DE.MESSAGE variable name).

Both email and SMS are sent through standard interfaces and should therefore follow an uniform XML
schema. The data content can vary from message to message but the structure and the tags should be
the same. Therefore there are two standard XSD records available in F.DE.XML.SCHEMA namely
T24Email.xsd and T24Sms.xsd, that will come along with your T24 area.

NOTE:
The screen shot that you see is not the entire XML schema definition but only a snapshot of the record
created for the DE.FORMAT.XML record 910.2.7.GB.

In case of EB.SECURE.MESSAGE, the default schema record (.XSD) does not come with your T24 area.
You will have to create it on your own. As the application evolves over a period of time, the XSD record
should also change in accordance and therefore should be create manually. The following procedure can
be done for any application in T24 and not just this one.

STEP 1:
Create a JR or J4 file called F.SCHEMA

STEP 2:
Log into T24. Open the STANDARD.SELECTION record for the application EB.SECURE.MESSAGE.
Enter the value “Y” in the field REBUILD.SYS.FLDS. Authorise the record.

STEP 3:
The default XSD record will be created in the F.SCHEMA file as EB_SECURE_MESSAGE.xsd.
You have to map your record created through DE.FORMAT.XML with that of the standard XML schema
definition that is understood by the interface. In order to accomplish this you can use a software called
ALTOVA MAPFORCE.

The screen shot here shows the mapping done between the schema definition record 910_2_7_GB.xsd
and the standard T24Email.xsd.
For e.g.: The record that is defined in DE.FORMAT.XML makes up the body of the email and is mapped
appropriately to the body element, using the CONCAT function in ALOTVA.

Once the mapping has been done successfully, this software generates a corresponding XSLT
(Extensible Stylesheet Language Transformations). XSLT is most often used to convert data between
different XML schemas.

A record in EB.TRANSFORM is created for the Delivery subsystem, to apply the given Stylesheet to the
outgoing SMS EMAIL message and a standard format for a Secure Message. The Format for a secure
message, as you have already learnt, will be in accordance to the fields of the application
EB.SECURE.MESSAGE.

The ID of a record in this application should follow the syntax – “DE.<DE.FORMAT.XML ID>.<Carrier
Name>”.

For e.g.: DE.910.2.7.GB.EMAIL

Input and authorise a record in a contract based application. Make sure that you transact using an
account which belongs to a customer for whom SMS and EMAIL information is entered properly. Also
make sure you set up the EMAIL/SMS system in the way that you learnt till now in this presentation.
On authorisation, the core delivery routine APPLICATION.HANDOFF is invoked. It reads the appropriate
records in DE.MESSAGE, DE.MAPPING, DE.PRODUCT, DE.ADDRESS and updates the relevant
DE.O.HEADER record.

Once the mapping stage is over, the ID’s are updated in the appropriate activation files namely
F.SMS.OUT.LIST and F.EMAIL.OUT.LIST, for the service to pick them up from.

Start the services BNK/EMAIL.OUT and BNK/SMS.OUT.

The routine DE.OUTWARD is run as a service.

This routine first reads a record in DE.CARRIER based on the service. Based on the FORMAT.MODULE
field in the DE.CARRIER record.

The appropriate formatting routine is called. In this case the FORMAT.MODULE is XML, therefore the
formatting routine called is DE.O.FORMAT.XML.MESSAGE.

This routine formats the body of the message according to the record in DE.FORMAT.XML. An ID of a
record in this application is of the syntax – “<DE.MESSAGE ID>.<App Format>.<Format Version
Number>.<Language Code>”.

Once this is done, a record is read in EB.TRANSFORM, to convert the message to standard XML format
understood by the gateway. This is done by applying the xslt (style sheet) defined inside the
EB.TRANSFORM record. An ID of a record in this application is of the syntax – “DE.<DE.FORMAT.XML
ID>.<CARRIER NAME>”.

Now the message is formatted, it is written onto the Formatted queues. In case of EMAIL, the formatted
ID’s are placed in F.DE.O.PRI.EMAIL, and the actual message is written in F.DE.O.MSG.EMAIL.

In case of SMS, the formatted ID’s are placed in the file F.DE.O.PRI.SMS and the actual message is
written in F.DE.O.MSG.SMS.

Since, the CARRIER.MODULE field is “Generic” in the DE.CARRIER record, the corresponding
INTERFACE record is read and the respective interface routine is invoked. In case of EMAIL, the name of
the interface routine is DE.EMAIL.JAVA.INTERFACE.

In case of SMS, the name of the routine is DE.SMS.JAVA.INTERFACE.

The Interface routine in turn invokes the Java package defined inside the EB.API record. For email the
record in EB.API is DE.EMAIL.CLIENT.

For SMS, the EB.API record read is DE.SMS.CLIENT.

Now the message is sent by the Java interface routines to the respective servers, i.e. the SMTP Server in
case of EMAIL and the Clickatell SMS Gateway in case of SMS.

Steps 1 - 9 are the same like before, the exceptions being that at step 3, the unformatted ID’s are written
to F.SECUREMSG.OUT.LIST and at Step 4, you will have to start the Service BNK/SECUREMSG.OUT to
format the message.
Step 10:
Now the message is formatted, it is written onto the Formatted queues. In case of EMAIL, the formatted
ID’s are placed in F.DE.O.PRI.SECUREMSG, and the actual message is written in
F.DE.O.MSG.SECUREMSG.

Step 11:
Since, the CARRIER.MODULE field is “Generic” in the DE.CARRIER record, the corresponding
INTERFACE record is read and the respective interface routine is invoked. In case of SECUREMSG, the
name of the interface routine is SECURE.MSG.INTERFACE.

Step 12:
The Interface routine in turn invokes converts the xml message into a OFS STRING and writes the data
using OFS.POST.MESSAGE into F.OFS.MESSAGE.QUEUE. The OFS.SOURCE record to be read is
passed as a parameter to OFS.POST.MESSAGE. The name of the OFS.SOURCE record used is
SECURE.MSG.

Step 13:
Start the service BNK/OFS.MESSAGE.SERVICE.

Step 14:
The services creates a record in EB.SECURE.MESSAGE and places the response in the response
queue which is F.OFS.RESPONSE.QUEUE.

Open a FUNDS.TRANSFER record and perform an FT crediting/debiting the customer’s account for
whom you have set up email or SMS just now. In this example you can see the account of customer
100224 is being credited.

The Delivery Reference ID’s are written to the unformatted queue – F.EMAIL.OUT.LIST. In this setup, the
DE.PRODUCT record is setup to send two emails to the customer. The first one will intimate him about
the transfer of funds, and the other will tell him that there is a secure message waiting for him.

Set the field SERVICE.CONTROL to “START” in the record TSM.

Set the field SERVICE.CONTROL to “START” in the record BNK/EMAIL.OUT.

Log in to the backend (jshell prompt) type START.TSM. This will start the required services.
Two emails that have been generated as a result of this transaction.

Notice the “From address” in the email, you must be wondering where this information came from?

It has been updated from the HEADER record. The HEADER gets the value from the default company
level record in DE.ADDRESS for EMAIL which is <CompanyCode>.EMAIL.1

The corresponding record in DE.O.HEADER. If you notice the field MSG.DISPOSITION has been set to
“ACK” in the multi value field meant for the EMAIL carrier – EMAIL.1.

List the contents of the file F.SMS.OUT.LIST, you will see that there are two ID’s that are waiting to be
formatted. This is because as a result of this transaction two SMS's have to be sent, one for the intimation
of credit, the other to inform the customer that there is a secure message waiting for him.

Set the field SERVICE.CONTROL to “START” in the record BNK/SMS.OUT. Since the TSM is already
running as a result of the previous step, you don’t have to go and start the TSM again.

You can see that the SMS has been delivered to the mobile phone. However if you notice closely, you are
not able to see the actual content of the message. You are able to only see a confirmation of receipt from
Clickatell.

The registration done on the Clickatell gateway is free, however to receive the actual message is a paid
service. A maximum of 10 SMS’s can be sent to the gateway to receive such a reply. This means that the
message has successfully reached Clickatell gateway from T24, and if you pay for the Clickatell service,
then the message will be sent to the customer.

The corresponding record in DE.O.HEADER. If you notice the field MSG.DISPOSITION has been set to
“ACK” in the multi value field meant for the SMS carrier – SMS.1.

You are now going to see a demo of how to generate a secure message:

Input a FT and authorise it. Make sure you use the account of a user for whom secure message has been
enabled.

Note down the Delivery Reference ID. Looking at the F.SECUREMSG.OUT.LIST you will know that the
Delivery message has been created, mapped but is
unformatted.
Set the field SERVICE.CONTROL to “START” in the record TSM.

Set the field SERVICE.CONTROL to “START” in the record BNK/SECUREMSG.OUT.

Log in to the backend (jBASE prompt) type START.TSM.

This will start the required services.Check F.OFS.MESSAGE.QUEUE. The OFS.STRING would have
been written in a record.

Set the field SERVICE.CONTROL to “START” in the record BNK/OFS.MESSAGE.SERVICE.

Search the F.OFS.RESPONSE.QUEUE with the ID that you noted down from the
F.OFS.MESSAGE.QUEUE as shown in the screen shot.

Note down the ID. Open the record in F.OFS.RESPONSE.QUEUE.

Note down the ID of the record created in EB.SECURE.MESSAGE.

The record created in EB.SECURE.MESSAGE as a result of the FT transaction.

You might be wondering where did the delivery subsystem get the other values to fill in the field, as what
you did in the DE.FORMAT.XML record was only the SUBJECT and the MESSAGE part of the Secure
Message.

TO.CUSTOMER:
From CUSTOMER field on DE.O.HEADER.

FROM.DAO:
From DEPARTMENT field on DE.O.HEADER.

FROM.CUSTOMER:
From FROM.ADDRESS field on DE.O.HEADER (updated initially into HEADER record from the field
ACCOUNT.OFFICER in the CUSTOMER’s record).

SUBJECT:
Built from the text output of the XML and style sheet.

MESSAGE:
Built from the text output of the XML and style sheet.

Sometimes, you might have to create a CUSTOMER record for the customer specified in
FROM.CUSTOMER field, else the EB.SECURE.MESSAGE record will not be created. The OFS.STRING
will fail out and return a response of -1, signifying that the processing was not successful.