Ofs
Ofs
Return to Main
Menu
CHAPTER 41
TABLE OF CONTENTS
41 OPEN FINANCIAL SERVICE...........................................................................41-1
The Open Financial Service module (OFS) provides an interface to allow the update and
interrogation of GLOBUS applications. OFS provides a real time transaction and batch based
mechanism, which accepts messages in a specific format.
OFS complements the existing GLOBUS Transaction Server (GTS) module and will support
the existing field based GTS message syntax described in the GTS chapter of the user guide.
Batch update of the GLOBUS database using files containing messages specified in either
GTS or OFS syntax
Multi-company processing
ATM processing
External
Feed
OFS/GTS
batch file
OFS online
manager
OFS queue
manager
OFS Request
manager
OFS
Details OFS offline
queue
Each type of external OFS data source is defined using the OFS.SOURCE application, which
defines the rules and processing details for that specific interface.
In order to communicate with OFS an external application must establish communication with
OFS. Communication takes place using a Telnet connection.
The connection will be established with the GLOBUS server supplying a pre-defined UNIX /
NT login. The LOGIN voc should be set up such that PTERM CASE NOINVERT is set and
that the routine EB.AUTO.INIT.PROCESS is launched before the EBS.LOGIN command.
See Figure 41-2 for an example.
!('92&/2*,1
OLQHVORQJ
3
3$
6(7375$735
'$7$<
37(50&$6(12,19(57
(%$872,1,7352&(66
',63/$<
',63/$<
',63/$<
',63/$<
%/2&.7(502)6%$1.
',63/$<
',63/$<
,)#77<(4
SKDQWRP
7+(1*2(;,7
,)67$57*/2%86<1!!(4
<
7+(1(%6/2*,1
,)67$57*/2%86<1!!(4
\
7+(1(%6/2*,1
(;,7
%RWWRPDWOLQH
Figure 41-2 Sample login VOC for use with online OFS Processing
In order to automatically start the process the LOGIN paragraph in the VOC file needs to
have the job EB.AUTO.INIT.PROCESS inserted as shown above:
A maximum number of open OFS connections for a particular source can be specified. Each
OFS connection will continue to be active until either shutdown from GLOBUS or by the
external application. The connection can remain active during the offline mode to allow
enquiry functions to take place.
Each online connection will use its own EB.PHANTOM record. If no free EB.PHANTOM
records exist, one will be created. As each request is received the EB.PHANTOM record keeps
a record of transaction count and status. It is therefore possible to monitor each OFS
connection by enquiry on the EB.PHANTOM records.
Each online request to OFS must be supplied as a message in the specified OFS format. The
details to be supplied include:
The OFS.REQUEST.MANAGER will attempt to process the request and return the required
data including:
Where OFS is used as an interface to an external source, for example in conjunction with the
Internet Banking Interface, it may be necessary to wrap messages to ensure consistent
delivery of data - to inform OFS of where the start and end points of a message are. This may
be done by adding to the start of a message a tag packaged between < > signs and repeating
the tag packaged between </ >. The / sign indicates the end of the message.
Example:
<MSG1>ABBREVIATION,INPUTT/******,SEC,ORIGINAL.TEXT=SECTOR</MSG1>
will enter an ABBREVIATION record, using the SMS settings of the user which signs on as
INPUTT with password ******, to edit/create the record with an ID of SEC, and
ORIGINAL.TEXT of SECTOR.
In the example above the confirmation message returned will also be prefixed with <MSG1>
and suffixed with </MSG1>.
If processing is allowed the system will return details from Enquiry requests. For application
update requests the system will allow messages to be added to a store and forward queue. In
this situation the message will be recorded as passed to the OFS.ONLINE.MANAGER, a
success / failure indicator will show that the message has been queued.
A background process, the OFS.QUEUE.MANAGER will be initiated when the system returns
to its online state and will submit each queued message back to the
OFS.REQUEST.MANAGER, results are written to an outward queue.
When creating OFS.SOURCE records for Telnet (On-Line) processing it should be noted that
the LOGIN.ID should be preceded by the domain name of the NT machine. Therefore, on
UNIX you may use a Login id of user189 whereas on Windows NT this would appear like
TEMUKNT3X\user189.
If IN.FILE.NAME is defined then only that file will be processed from the input directory.
In order to execute an OFS transaction a sign on name and password must be supplied by the
source application. This will be validated before processing any online request.
Batch and offline processing will be controlled via the user defined in the GTS.USER.ID of
the EB.PHANTOM record used to initiate the OFS.QUEUE.MANAGER phantom. Note when
defining the USER record to be used for GTS.USER.ID that the user must have access to
application EB.PHANTOM.PH, - this is necessary for the user to be able to use OFS
TELNET.
N.B. a valid sign on and password must be supplied before the online server can accept a
message.
Once validated all access to data is controlled using the standard SMS definitions specified in
the user profile.
Each transaction to be updated using OFS can be configured using the standard VERSION
utility. This can be used to define default values, and can be customised with user defined
sub-routines.
The version will also control the handling of error messages and override conditions. The
following options are available:
OFS will allow transactions to be processed in any company that the user has access. The
company for the transaction can be specified as part of the message syntax.
A logging facility will be provided for all messages for a particular service. This can log all
traffic, exception messages, communication start and end or no messages.
Full history of each message can be recorded if required. The details are stored in the
OFS.REQUEST.DETAIL file if message audit is required. If message auditing is required full
details of the message and subsequent processing statuses will be recorded.
Processing can be customised to suit specific requirements by the use of API at various points
within the processing path. User routines can be incorporated at the following points:
Where:
OPERATION
Contains the GLOBUS application to be executed
OPTIONS
Contains the Version of the application, the Function to be performed and an operation flag.
USER INFORMATION
Contains the details of the GLOBUS user that will execute the transaction passed to
GLOBUS, including sign on name, password and company code.
TRANSACTION ID
Contains the transaction number for the application to be executed this can be automatically
allocated for new transactions the transaction id is left blank, and the Message Id.
MESSAGE DATA
Contains the data required to create/update the transaction, this is repeated for as many data
items as required, each item being separated by a ,.
41.13.2 OPERATION
The Operation will be validated and will follow standard SMS validation based on the User
Information supplied.
41.13.3 OPTIONS
The options supplied determine the version and function to be executed and are supplied in
the following format:
Version Name
This defines the name of the version of the application specified in OPERATION to be used
when executing the request.
For ENQUIRY.SELECT operation nothing must be specified, mandatory for all other
applications.
Function
The function to be used when executing the request currently only the Input function is
supported if not supplied function I will be assumed.
Operation
Can be either PROCESS or VALIDATE.
User Password
The password for the USER sign on name supplied. This must be supplied with each online
request.
Company Code
In a multi-company environment the company to enter the transaction in can be specified
this will validated against the USER profile. If not supplied the first company specified in the
USER profile will be assumed.
41.13.5 TRANSACTION ID
Transaction Message
Id / Id
Transaction Id
This is passed with the transaction key to be updated, or if not specified and the GLOBUS
application allows it, a new id will be allocated.
Mandatory for Operations of ENQUIRY.SELECT, used to specify the name of the enquiry to
be executed.
Message Id
The Id of the message being currently processed can be passed in.
Field Name
The field name must be defined in the STANDARD.SELECTION record for the application.
At least one field must be specified.
For sub-valued fields a specific sub-value number within the multi-value can be specified, if
not defined the first sub-value is assumed.
Field Content
The content to be added to the specified field. The value supplied will be validated as per the
standard application.
N.B.
If a , (comma) character is required within the field content then it should be replaced by the
? (Question mark) character.
The data required to initiate an Enquiry has a different layout to the standard application and
is defined as follows:
Selection Operand Field Value
Field : =
Selection Field
The name of the field to select which must be either a valid SELECTION.FLDS for the Enquiry
or defined in the STANDARD.SELECTION record for the FILE.NAME of the Enquiry.
Operand
The operand for the selection, must be specified with a SELECTION.FLDS, may be EQ, NE,
GE, GT, LE, LT, UL, LK, NR.
Field Value
The data value for the SELECTION.FLDS and requested operand for the selection.
Transaction Id
This will either contain the id supplied initially, or if no id was supplied the next available id
(if generated) will be returned.
Message Id
This will contain the message Id of the processed message.
A successfully processed update will return the fully populated record in the same format as
the data passed to OFS.
A transaction encountering errors when processed will return errors in the Message Data field
in the following format:
Field Name
The name of the field in error is returned, the name will be found in the Standard Selection
record for the application.
Error Message
The error message generated for the associated Field name, Multi Value, sub value will be
returned here. The message will be returned with variable elements expanded.
The data returned from enquiry will be in the following format, in three sections:
Header / Header
caption = Text / ,
identifier
Header Text
Contains the text for the corresponding identifier.
Column Identifier
Contains the column identifier, which can be a name or a number. Each column to return
information must be defined in the underlying ENQUIRY.
Column Label
Indicates the name of the column used as the column header.
Row
Tab ,
Value
column n
SECTOR,OFS//PROCESS,PWEISS/123456,7719,DESCRIPTION::=OFS DESCRIPTION
DATA,SHORT.NAME::=OFS DATA
Operator
SECTOR,
Options
OFS//PROCESS,
User Info
PWEISS/123456,
Transaction ID
7719,
Field Data
DESCRIPTION::=OFS DESCRIPTION DATA,
SHORT.NAME::=OFS DATA
Field Name
DESCRIPTION
SHORT.NAME
Multi Value
: i.e. defaults to 1
Sub Value
: i.e. defaults to 1
Field Data
OFS DESCRIPTION DATA
SHORT.NAME
The following example relates to a foreign exchange swap transaction where information is
required for both legs of the swap, in this case the _ (underscore) character is used to delimit
information for record 1 from record 2.
FOREX,GTS//PROCESS,GTUSER/QWERTY,,DEAL.TYPE=SW,COUNTERPARTY::=10
0076,CURRENCY.BOUGHT::=USD,AMOUNT.BOUGHT::=500000,CURRENCY.SOLD::
=GBP,SPOT.RATE::=1.6,DEAL.DATE::=20011026,VALUE.DATE.BUY::=20011028_1M,
FORWARD.RATE::=_1.55,REVALUATION.TYPE:_1:=_IN,NOTES:1_1="first
leg"_"second leg",NOTES:_2:_"second-line"
VALUE.DATE.BUY::=20011028_1M,
N.B. the underscore separates the spot date for leg 1 from the forward date for leg 2.
FORWARD.RATE::=_1.55,
N.B. for the forward rate information is only required for the second leg, so the first leg
information is left blank.
N.B. the above example will populate the first multi value field of NOTES for both legs,
leave the first leg second multi value blank and populate the second multi value of the second
leg.
The following example shows input for two sector records in OFS format.
SECTOR,OF//PROCESS,OFSUSER/QWERTY,5011,DESCRIPTION=TESTreference,SHO
RT.NAME=Testref
SECTOR,OF//PROCESS,OFSUSER/QWERTY,5012,DESCRIPTION=TEST2
reference,SHORT.NAME=Test2 toooooooolooooooongref
The output for the two examples indicates that the second record has been put on hold due to
a validation error.
5011/OFS0129900088/1,DESCRIPTION=TESTreference:1:1,SHORT.NAME=Test
ref:1:1,RECORD.STATUS=INAU:1:1,CURR.NO=1:1:1,INPUTTER=-
29515_TEST1_OFSUSER:1:1,DATE.TIME=9903291339:1:1,CO.CODE=GB0010001:1:1,D
EPT.CODE=1:1:1
5012/OFS0129900089/-1,VALIDATION ERROR - ON HOLD
The following example shows an enquiry request followed by the returned data.
ENQUIRY.SELECT,,,ACCOUNT-LIST,CURRENCY:EQ=GBP,CUSTOMER:EQ=100053
The returned fields are separated by the tab (ASCII 9) character with lines separated by ,
(comma).
GTS message syntax is described in the GLOBUS TRANSACTION SERVER chapter of the
user guide.
OFS directories can be positioned where required assuming that access permissions are
correctly set up.
One possibility would be to create the OFS directories in the data area of a GLOBUS account
as follows (See the SYSTEM ADMINISTRATION GUIDE for more details).
If directories are created in the data area then they will be backed up when GLOBUS backups
take place.
Assume that the GLOBUS account is called bnk and that the operating system is UNIX.
Then directories could be created as follows, where the current directory is bnk.run
../bnk.data/ofsdata
../bnk.data/ofsdata/ofslog - the directory to contain log files
../bnk.data/ofsdata/ofsin - the directory to contain the input files in OFS/GTS format
../bnk.data/ofsdata/ofsout - the directory to contain the output files generated by OFS
If pre or post processing routines need to be run on batch files then additional directories may
need to be created.
Once the directories are set up then an OFS.SOURCE record is updated as follows.
MAX.CONNECTIONS Specifies the maximum number Number must be less than the maximum
of on-line OFS connections for number of users as defined in SPF.
the specified service which can
be active at any one time.
SYNTAX.TYPE Specifies the syntax type for For Batch processing, may be either GTS
messages to be received or OFS.
GENERIC.USER The Generic user is the Must be a valid user on the USER File.
GLOBUS user that will be used Must have authority to use
to access the GLOBUS server. EB.PHANTOM.PH
For external users determines
SMS options. Generic User
must have authority to use
EB.PHANTOM.PH i
SLEEP.SECS The regularity with which the system The shorter the gap, the more resources are
checks whether there is anything in taken by the system in running the
the in directory phantom.
TIMEOUT.SECS If a process has difficulty reading At the discretion of the user. Too short a
from a specific file, such that it fails gap may result in unnecessary timeouts,
to read the file in the time set here, the too long a gap means delay before
process will stop, reporting a timeout reporting timeout.
GTS.USER.ID Defines the user that will appear in User definable, according to reporting
the audit information for the jobs requirements.
processed by that batch.
To set the batch phantom running, the EB.PHANTOM record must be VERIFIED (select
phantom with function set to Verify and press F5)
Create a txt file with one or several valid OFS Messages. Two examples are shown below,
one for an enquiry and the other to create a new record.
ENQUIRY.SELECT,,<USER>/<PASSWORD>,ACCOUNT-
LIST,CUSTOMER.MNEMONIC:EQ=*
ABBREVIATION,,<USER>/<PASSWORD>,TEST1,ORIGINAL.TEXT=TEST OFS BATCH
Place the document into the ofsin directory you specified in the OFS.SOURCE record earlier.
If the document is processed and the output placed into the ofsout directory you specified in
the OFS.SOURCE above, then your OFS Batch set-up is correct. For the ABBREVIATION,
check the ABBREVIATION file to see if there is a record called TEST1.
To stop the phantom, recall the record and type in STOP in field 4, followed by F5 to
confirm.
For accessing via TELNET an Online record is needed. Note that the user will be logging in
via a remote session and the login voc will need to initiate the program
EB.AUTO.INIT.PROCESS as this will handle the interactive communication process.
To install and configure OFS on the GLOBUS system, please follow the steps outlined below.
Create a new NT or UNIX user account to be used with OFS. Consult your UNIX or NT
systems administrator for further assistance regarding this.
Ensure that the LOGIN record of the VOC file contains the correct syntax to launch the
routine EB.AUTO.INIT.PROCESS. See Figure 41-2 Sample login VOC for use with
online OFS Processing for an example of a LOGIN record which would facilitate this.
Create an OFS.SOURCE record for TELNET. For additional information, check the
individual help text for each field
SYNTAX.TYPE Specifies the syntax type for For OFS Online Processing requirements,
messages to be received this field must be set to OFS.
GENERIC.USER The Generic user is the Must be a valid user on the USER File.
GLOBUS user that will be used
to access the GLOBUS server
The input/output OFS message is divided into the following components shown bellow.
NOTE: If left blank, certain components can be automatically allocated by the system, see
the example bellow
ENQUIRY.SELECT,,INPUTT/123456,ACCOUNT-LIST,CUSTOMER.MNEMONIC:EQ=ALEXCOURT