Welcome to this session on Open Financial Service.

You will learn to use the logging

facilities available in OFS. You will also learn the purpose and use of ,some of the
special fields in OFS.SOURCE.

OFS5.OFS Logging - R15 1

 At the end of this session you should be able to
Configure logging in OFS
Handle duplicate messages
Disable OFS
List more of the OFS.SOURCE fields and state their purpose

OFS5.OFS Logging - R15 2

 There are two logs that you can set within OFS. One is a log very much like COMO, in
that it records on a file, the request and response that could have appeared on a telnet
screen.
The second log, uses an application called the OFS.REQUEST.DETAIL (commonly
called as ORD).
Logging is initiated by the OFS Request Manager.

OFS5.OFS Logging - R15 3

 In SPF, if INT.LOG.FILE = YES meaning T24 level log is enabled and then messages
will be logged into log file directory
if INT.LOG.FILE = null (no input), meaning TAFJ level log is enabled by default and
then messages will be logged into TAFJ log files

You need to use two fields in your OFS.SOURCE record to enable logging
Log File Dir
This field contains the name or relative path and name to the log file directory. If the
name alone is specified (as in the sample data shown), the log file is created under the
T24 Home directory.

This log file is in essence a UD type directory. Yes, it is very much like COMO, in that
it records the screen output from OFS, i.e. the request and response. Each session is
logged into a record (i.e. a physical file). The record id (i.e. the filename) comprises of
the OFS.SOURCE id followed by an underscore followed by a 5 digit number.

Log Detail Level

You can choose from three levels , described below;
NONE - Don’t log anything.
EXCEPT - Log only the Exceptions
FULL - Logs everything, i.e. log the request and response for all messages.
OPEN - Captures log information , when a background process is started/closed

OFS5.OFS Logging - R15 4

 You can see a sample log file output here. Notice the record id. Each request is written
in one line and a response in the next.

OFS5.OFS Logging - R15 5

 ORD records information such as Application, Function, Transaction Reference, User
Name, Company, Date time received and processed, the status of the message –
whether it was processed or resulted in an error, the message in and message out as
well as the GTS control value . Each transaction is recorded in a separate record. The
record id could be the transaction id (if your OFS message contained one) , or ORD
will generate one of it’s own. Since the ORD is an application it may be queried like
any other T24 application.

You need to use two fields in your OFS.SOURCE record to enable

OFS.REQUEST.DETAIL.
Maint Msg Dets
This can contain value Y or blank. Y indicates that the ORD has been activated.
Det Prefix
ORD is a common application used by all the OFS Source records to log information.
If you have specified the message id in your OFS message itself you wouldn’t have
difficulty in locating the ORD record. However , if you haven’t, ORD would generate it’s
own id , and you may find it tedious to locate logs pertaining to your messages from
among the many others. ORD eases this by allowing you to specify your own prefix.
ORD would then attach the generated id to the prefix and form a record id.

OFS5.OFS Logging - R15 6

 See the list records in ORD. Observe the record ids.
E.g.
ABCEDFG10 - this is a message id given by the user as part of the OFS message.
OL080100000233213.01 – this id is generated by OFS.

The generated id’s follow the format PPPPPPJJJJJUUUUUTTTTT.NN

Where
PPPPPP = six char (max) prefix
JJJJJ = last five digits of Julian date
UUUUU = User number
TTTTTT =Time in five digits (i.e seconds since midnight)
NN = two digit sequence number

OFS5.OFS Logging - R15 7

 Application: Application name of the transaction.
Version: Gets populated with the VERSION name if used.
Function: Stores the function performed on the transaction
Trans Reference: Contains the transaction ID or message ID of the transaction.
User Name: Sign on name of the USER used to perform the request.
Company: In a multi-company environment it identifies the company to which the
transaction belongs.
Status: Status of the message which can be one of the following - RECEIVED,
VALIDATED, PROCESSED, ERROR
Msg In: Contains the message received from the external application to process the
transaction.
Msg Out: Contains the OFS response of the processed request.
Date Time Recd: Identifies the application server date and time when the request was
received from external application.
Date Time Proc: Identifies the application server date and time when the request was
processed.
When the field ‘use local time’ in SPF is set to ‘Yes’ and the company’s time zone is
specified in Company record, then these two fields additionally get populated
Date Time Recd Loc: Indicates the date and time according to the company’s time
zone, when the request was Received from external application.
Date Time Proc Loc: Indicates the date and time according to the company’s time
zone, when the request was Processed.

OFS5.OFS Logging - R15 8

 You can see two ORD records on the screen. The first one is a log of a message that
was successful. The second is that of a message which failed. The status field tells us
the message status.

The status of a message could be;

RECEIVED - message has been received by OFS but not processed nor validated
VALIDATED - message has been validated
PROCESSED - message has been processed
ERROR - message resulted in an error

OFS5.OFS Logging - R15 9

OFS5.OFS Logging - R15 10
OFS5.OFS Logging - R15 11
 An OFS message could have a message id embedded within it.

OFS5.OFS Logging - R15 12

 This is a different FT but using the same message id as the previous. Notice the error
message. The FT does not get processed because of the duplicate id and a
DUPLICATE.TRAP response is returned. Only the last 10 message for each session
will be stored in this file, if you are posting continuously messages in a single session
with the interval of duplicate message after every 15 message system will allow you to
post this.

It is suggested to use EB.DUPLICATE.CHECK

OFS5.OFS Logging - R15 13

 When OFS messages are sent from a third party system, there is a possibility that the
same message might be sent twice. How does OFS ensure that a message is not
repeated? Simple!! It uses the message reference id. This means the message id has
to be included within a OFS message and OFS has to store this message reference so
that it can check against it later. Where does it store the message reference? In a file
called F.OFS.UNIQUE.MSG.REF.

OFS5.OFS Logging - R15 14

 The possible values in OFS.SOURCE Attributes field

NO.DUPLICATE.CHECK :
If we set this value in the attribute field, the error ‘DUPLICATE OFS MESSAGE’ can
be avoided.

SPECIAL.CHAR.CONV :
If this is set, then the special characters '?', 'ˆ', and ',' used in OFS request will remain
same in OFS response. The actual record in disk will always have converted
characters as per character conversion rule.

USE.LOCAL.REF :
All local reference fields will use actual names rather than "LOCAL.REF" unless
'USE.LOCAL.REF' is set as an attribute

OFS5.OFS Logging - R15 15

 The parameters in OFS.SOURCE Attributes field

ARC.VALIDATE :
Setting this attribute will not allow transactions in HOLD status to be edited by external
users (through ARC-IB). Error will be raised that stops transactions from editing

OVERRIDE.TWS.MSG :
No. of Authorizer and GTS.CONTROL definition in VERSION overrides TWS message
definition. Setting up this attribute will always take Version definition
into priority. Incoming NO.OF.AUTH / GTS.CONTROL values from web service
request will be discarded

PREAUTHENTICATED:
If the value for the field ATTRIBUTES is set as “PREAUTHENTICATED” and if value
for the field SOURCE.TYPE is set as SESSION, T24 BROWSER user will be treated
as pre authenticated user. Only sign on name authentication will be done.

OFS5.OFS Logging - R15 16

 The parameters in OFS.SOURCE Attributes field

TWS :
This attribute indicates that the message comes from SOAP interface.

INTERFACE :
This attribute indicates the system to understand that the request comes via an
interface.

OFS5.OFS Logging - R15 17

 You may restrict access to OFS in the following way,
b. At an application level
Enter .NOFS in the ADDITIONAL.INFO field, in the PGM.FILE entry for that
record.

OFS5.OFS Logging - R15 18

 This page illustrates the effect of setting .NOFS in PGM.FILE.

OFS5.OFS Logging - R15 19

 There are two fields in OFS.SOURCE meant specifically for the Temenos Internet
banking products. The internet banking products of Temenos do not use the standard
USER application to maintain security profiles.
IB.USER.CHECK
This field is used by the old TIB (Temenos Internet Banking) product.
Setting this tells SMS to check IB.USER and not USER for the security profile
of the user
The Generic User in Ofs Source must be specified and valid if IB.USER is
enabled. This is because access to the T24 system is controlled using security
profile of the Generic User.
CHANNEL
This specifies a channel through which a request may be received. A list of
channels are maintained in EB.CHANNEL
This is used with the new ARC Internet Banking product. When this is
enabled, SMS checks EB.EXTERNAL.USER to validate the user.

OFS5.OFS Logging - R15 20

 A sample OFS.SOURCE record containing a Channel field is shown in this page. The
channel is defined in EB.CHANNEL.

OFS5.OFS Logging - R15 21

OFS5.OFS Logging - R15 22
OFS5.OFS Logging - R15 23
 You should now be able to
Configure logging in OFS
Handle duplicate messages
Disable OFS
Configure OFS.SOURCE for TIB & ARC-IB
List more of the OFS.SOURCE fields and state their purpose

OFS5.OFS Logging - R15 25