OPEN FINANCIAL SERVICE - MarkMail

GLOBUS USER GUIDE OPEN FINANCIAL SERVICE

Ref. OF April 2000 Release G10.2.02

CHAPTER 41

OPEN FINANCIAL SERVICE

Return to MainMenu


Ref : OF April 2000 Release G10.2.02

TABLE OF CONTENTS

41 OPEN FINANCIAL SERVICE...........................................................................41-1

41.1 Introduction .......................................................................................................................41-1

41.2 OFS Architecture ..............................................................................................................41-2

41.3 Definition of interface types..............................................................................................41-3

41.4 Online communication with OFS.....................................................................................41-341.4.1 Preparation for Online connection..................................................................................41-341.4.2 Online communication process.......................................................................................41-541.4.3 Monitoring Online Activity ............................................................................................41-5

41.5 Online request management.............................................................................................41-641.5.1 Using the ’<>’ tag syntax to wrap messages....................................................................41-6

41.6 Offline / Store and Forward Capability ..........................................................................41-641.6.1 Windows NT On-line processing ...................................................................................41-7

41.7 Batch communication with OFS. .....................................................................................41-8

41.8 Security and OFS.............................................................................................................41-10

41.9 Transaction definition and error handling options ......................................................41-11

41.10 Multi-company processing..............................................................................................41-11

41.11 Message Logging .............................................................................................................41-11

41.12 Customisation / API ........................................................................................................41-11

41.13 OFS MESSAGE SYNTAX .............................................................................................41-1241.13.1 General Structure .....................................................................................................41-1241.13.2 OPERATION...........................................................................................................41-1241.13.3 OPTIONS ................................................................................................................41-1341.13.4 USER INFORMATION ..........................................................................................41-1341.13.5 TRANSACTION ID................................................................................................41-1541.13.6 MESSAGE DATA - applications ............................................................................41-1541.13.7 MESSAGE DATA – Enquiries................................................................................41-1641.13.8 TRANSACTION ID – returned...............................................................................41-1741.13.9 MESSAGE DATA – returned successful transaction..............................................41-1741.13.10 MESSAGE DATA – returned errors encountered...................................................41-1741.13.11 MESSAGE DATA – returned from successful Enquiry..........................................41-1841.13.12 OFS message examples............................................................................................41-2041.13.13 OFS Input and Output message examples ...............................................................41-21

41.14 GTS MESSAGE SYNTAX .............................................................................................41-2241.14.1 GTS.MESSAGE examples ......................................................................................41-22

41.15 OFS SET UP EXAMPLE : .............................................................................................41-2341.15.1 Using OFS in Batch Mode.......................................................................................41-23

41.15.1.1 Create the directories...........................................................................................41-2341.15.1.2 Setup OFS.SOURCE ...........................................................................................41-2441.15.1.3 Create the Phantom EB.PHANTOM record for BATCH Mode.........................41-26


Ref : OF April 2000 Release G10.2.02

41.15.1.4 Test the EB.PHANTOM record..........................................................................41-2741.15.2 Using OFS in TELNET / Online mode....................................................................41-28

41.16 OFS Preparation for use with IBI..................................................................................41-2941.16.1 Configuring OFS for Online Processing..................................................................41-29

41.16.1.1 Step 1 - Pre-configuration procedures.................................................................41-2941.16.1.2 Step 2 - Preparing OFS for Telnet Mode ............................................................41-2941.16.1.3 Step 3 - Test the TELNET configuration ............................................................41-31

41.17 OFS message syntax example .........................................................................................41-3241.17.1 General structure......................................................................................................41-32

41.18 Auto-shutdown and Auto-startup of EB.PHANTOMs ................................................41-33


Ref : OF April 2000 Release G10.2.0241-1

41 OPEN FINANCIAL SERVICE

41.1 Introduction

The Open Financial Service module (OFS) provides an interface to allow the update andinterrogation of GLOBUS applications. OFS provides a real time transaction and batch basedmechanism, which accepts messages in a specific format.

OFS complements the existing GLOBUS Transaction Server (GTS) module and will supportthe existing field based GTS message syntax described in the GTS chapter of the user guide.

OFS provides the following functionality:

½ Allows online real-time updates of GLOBUS records using messages supplied inspecified OFS syntax.

½ Batch update of the GLOBUS database using files containing messages specified in eitherGTS or OFS syntax

½ Allow interrogation of the GLOBUS database by returning information based onENQUIRY layouts in a specified layout.

½ Optional offline store and forward capability

½ Optional audit trail for each message processed

½ Customisation of message processing using user defined routines

½ Multi-company processing

½ Support for sub-values

½ Enhanced error message details

½ Ability to run on platforms other than UNIX (i.e. NT)

OFS may be used for a variety of external purposes, these include:

½ Home Banking applications

½ ATM processing

½ External dealing system feeds



41.2 OFS Architecture

OFS can be configured to run in several ways as outlined below.

Figure 41-1OFS Architecture

The diagram illustrates the three main configurations available

½ Online link via a telnet connection½ Store and forward via the offline queue½ Batch updating via text files containing OFS/GTS type messages

OFS online manager

OFS Request manager

OFS queue manager

OFS enquiry manager

Globus Transaction

OFS offline queue

OFS Details

OFS/GTS batch fi le

External Feed



41.3 Definition of interface types

Each type of external OFS data source is defined using the OFS.SOURCE application, whichdefines the rules and processing details for that specific interface.

Details stored include:

½ Number of active processes allowed½ Whether the link is open, or open only for enquiry processing½ Routine to build the OFS syntax from incoming message½ Routines to perform special processing at start up and shutdown½ Routines to perform special processing for each request, before and after processing½ Whether offline store and forward capability is allowed½ Whether syntax is OFS or GTS compatible

41.4 Online communication with OFS

In order to communicate with OFS an external application must establish communication withOFS. Communication takes place using a Telnet connection.

41.4.1 Preparation for Online 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 andthat the routine EB.AUTO.INIT.PROCESS is launched before the EBS.LOGIN command.See Figure 41-2 for an example.

Figure 41-2 Sample login VOC for use with online OFS Processing

!('�92&�/2*,1��OLQHV�ORQJ�

��3��3$��6(7375��$7�35��'$7$�<��37(50�&$6(�12,19(57��(%�$872�,1,7�352&(66��',63/$<��',63/$<��',63/$<��',63/$<��%/2&.�7(50�2)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�%RWWRP�DW�OLQH��

�



In order to automatically start the process the LOGIN paragraph in the VOC file needs tohave the job EB.AUTO.INIT.PROCESS inserted as shown above:

When EB.AUTO.INIT.PROCESS is launched it looks for a record on theEB.AUTO.PROCESS file with an id equal to the UNIX login id of the user logging in. If arecord exists then the OFS online application will be invoked.

The EB.AUTO.PROCESS record is updated from OFS.SOURCE - when a telnetOFS.SOURCE record is created, an EB.AUTO.PROCESS record is created with an idgenerated from the LOGIN.ID field from the OFS.SOURCE record.



41.4.2 Online communication process

Once the connection is established the OFS.ONLINE.MANAGER will be startedautomatically. OFS.ONLINE.MANAGER performs the following functions:

½ Receive messages from the external application½ Pass the message to the OFS.REQUEST.MANAGER to perform the required processing½ Pass the message returned to the external application.

A maximum number of open OFS connections for a particular source can be specified. EachOFS connection will continue to be active until either shutdown from GLOBUS or by theexternal application. The connection can remain active during the offline mode to allowenquiry functions to take place.

41.4.3 Monitoring Online Activity

Each online connection will use its own EB.PHANTOM record. If no free EB.PHANTOMrecords exist, one will be created. As each request is received the EB.PHANTOM record keepsa record of transaction count and status. It is therefore possible to monitor each OFSconnection by enquiry on the EB.PHANTOM records.

Figure 41-3 EP.MONITOR phantom enquiry



41.5 Online request management

Each online request to OFS must be supplied as a message in the specified OFS format. Thedetails to be supplied include:

½ GLOBUS user name , password, company½ Application and version to be invoked½ Function and transaction key½ Input data to application

The OFS.REQUEST.MANAGER will attempt to process the request and return the requireddata including:

½ Transaction key if not supplied½ Updated message½ Success / Fail flag½ Details of error messages½ Details of enquiry request

41.5.1 Using the ’<>’ tag syntax to wrap messages

Where OFS is used as an interface to an external source, for example in conjunction with theInternet Banking Interface, it may be necessary to wrap messages to ensure consistentdelivery of data - to inform OFS of where the start and end points of a message are. This maybe done by adding to the start of a message a tag packaged between < > signs and repeatingthe 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 asINPUTT with password ******, to edit/create the record with an ID of SEC, andORIGINAL.TEXT of SECTOR.

In the example above the confirmation message returned will also be prefixed with <MSG1>and suffixed with </MSG1>.

41.6 Offline / Store and Forward Capability

If the OFS.ONLINE.MANAGER is invoked from an external application and GLOBUS is off-line at the time, an option in the OFS.SOURCE will determine if processing is allowed.

If processing is allowed the system will return details from Enquiry requests. For applicationupdate requests the system will allow messages to be added to a store and forward queue. Inthis situation the message will be recorded as passed to the OFS.ONLINE.MANAGER, asuccess / failure indicator will show that the message has been queued.



A background process, the OFS.QUEUE.MANAGER will be initiated when the system returnsto its online state and will submit each queued message back to theOFS.REQUEST.MANAGER, results are written to an outward queue.

41.6.1 Windows NT On-line processing

When creating OFS.SOURCE records for Telnet (On-Line) processing it should be noted thatthe LOGIN.ID should be preceded by the domain name of the NT machine. Therefore, onUNIX you may use a Login id of ’user189’ whereas on Windows NT this would appear like’TEMUKNT3X\user189’.



41.7 Batch communication with OFS.

Batch and offline processing is performed by OFS.QUEUE.MANAGER running as aphantom. The mode of operation is determined by the relevant OFS.SOURCE recordconfiguration. Processing is repeated at pre determined intervals defined in the relevantEB.PHANTOM record.

Figure 41-4 Definition of OFS.SOURCE batch processing record



The phantom is started via EB.PHANTOM.

Figure 41-5 Setting up EB.PHANTOM to run OFS in batch mode

When running in batch mode a predetermined input directory defined in IN.QUEUE.FILE isselected for batch input files, which will contain either OFS or GTS messages.

If IN.FILE.NAME is defined then only that file will be processed from the input directory.



Each input file is processed as follows:

½ Individual messages are extracted½ A pre processor routine is called if required½ The message is passed to OFS.REQUEST.MANAGER to update GLOBUS½ A post update routine is called if required½ The output file is updated as follows

½ the returned message for OFS format½ the input message appended with a return code for GTS format

½ When all messages have been processed the output file is written to the output directorydefined in OFS.SOURCE

When running in offline mode the following processing takes place.

½ OFS.OFFLINE.QUEUE is selected for the relevant OFS.SOURCE.½ Each record contains the identity of an OFS.REQUEST.DETAIL record, which is read and

the OFS message is extracted.½ The message is processed as above.½ The OFS.OFFLINE.QUEUE record is deleted and the OFS.REQUEST.DETAIL is

updated with the returned message.

41.8 Security and OFS

In order to execute an OFS transaction a sign on name and password must be supplied by thesource 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 ofthe EB.PHANTOM record used to initiate the OFS.QUEUE.MANAGER phantom. Note whendefining the USER record to be used for GTS.USER.ID that the user must have access toapplication EB.PHANTOM.PH, - this is necessary for the user to be able to use OFSTELNET.

N.B. a valid sign on and password must be supplied before the online server can accept amessage.

Once validated all access to data is controlled using the standard SMS definitions specified inthe user profile.



41.9 Transaction definition and error handling options

Each transaction to be updated using OFS can be configured using the standard VERSIONutility. This can be used to define default values, and can be customised with user definedsub-routines.

The version will also control the handling of error messages and override conditions. Thefollowing options are available:

½ Reject message on error½ Place new transactions in HLD status on error/override condition½ Automatically approve override conditions encountered.½ Automatically place all transactions on hold.

41.10 Multi-company processing

OFS will allow transactions to be processed in any company that the user has access. Thecompany for the transaction can be specified as part of the message syntax.

41.11 Message Logging

A logging facility will be provided for all messages for a particular service. This can log alltraffic, exception messages, communication start and end or no messages.

Full history of each message can be recorded if required. The details are stored in theOFS.REQUEST.DETAIL file if message audit is required. If message auditing is required fulldetails of the message and subsequent processing statuses will be recorded.

41.12 Customisation / API

Processing can be customised to suit specific requirements by the use of API at various pointswithin the processing path. User routines can be incorporated at the following points:

Communication Start and EndThis will allow specific operations to take place at the start and end of thecommunication process.

Individual message receipts and returnsThis will allow manipulation of the message immediately after receipt andimmediately after return to/from the calling application.

Individual message pre and post processThis allows the message to be manipulated prior to and on return from processing fromwithin the OFS.REQUEST.MANAGER.



41.13 OFS MESSAGE SYNTAX

41.13.1 General Structure

The input/output OFS message is divided into the following components:

Figure 41-6 OFS message structure

Where:

OPERATIONContains the GLOBUS application to be executed

OPTIONSContains the Version of the application, the Function to be performed and an operation flag.

USER INFORMATIONContains the details of the GLOBUS user that will execute the transaction passed toGLOBUS, including sign on name, password and company code.

TRANSACTION IDContains the transaction number for the application to be executed – this can be automaticallyallocated for new transactions the transaction id is left blank, and the Message Id.

MESSAGE DATAContains the data required to create/update the transaction, this is repeated for as many dataitems as required, each item being separated by a ‘,’.

41.13.2 OPERATION

The operation simply contains the GLOBUS application to be executed, e.g.FUNDS.TRANSFER. In order to interrogate the GLOBUS Database the Operation should beENQUIRY.SELECT.

The Operation will be validated and will follow standard SMS validation based on the UserInformation supplied.

Operation,

Options,

UserInformation ,

TransactionID ,

MessageData



41.13.3 OPTIONS

Figure 41-7 Option format

The options supplied determine the version and function to be executed and are supplied inthe following format:

Version NameThis defines the name of the version of the application specified in OPERATION to be usedwhen executing the request.

For ENQUIRY.SELECT operation nothing must be specified, mandatory for all otherapplications.

FunctionThe function to be used when executing the request –currently only the ‘I’nput function issupported if not supplied function ‘I’ will be assumed.

OperationCan be either PROCESS or VALIDATE.

½ PROCESS indicates that the message is to be committed to the database.½ VALIDATE indicates the all normal processing takes place without actually updating the

database, an example would be to return all default fields.

41.13.4 USER INFORMATION

User Information can be supplied in the following format:

Figure 41-8 User information format

User Sign On NameThe sign on name of a valid GLOBUS USER used to perform the request. This must besupplied with each online request.

User Password

User SignOn Name

UserPassword

CompanyCode/ /

VersionName

Function/

Operation/



The password for the USER sign on name supplied. This must be supplied with each onlinerequest.



Company CodeIn 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 theUSER profile will be assumed.

41.13.5 TRANSACTION ID

The transaction id and Message Id are supplied as follows:

Figure 41-9 Transaction ID format

Transaction IdThis is passed with the transaction key to be updated, or if not specified and the GLOBUSapplication allows it, a new id will be allocated.

Mandatory for Operations of ENQUIRY.SELECT, used to specify the name of the enquiry tobe executed.

Message IdThe Id of the message being currently processed can be passed in.

41.13.6 MESSAGE DATA - applications

The data required to update an application is supplied as follows:

Figure 41-10 Update message format

Field NameThe field name must be defined in the STANDARD.SELECTION record for the application.At least one field must be specified.

Multi Value NumberFor multi-value fields a specific multi value number can be specified, if not specified the firstvalue is assumed.

Sub Value Number

Field Name Multi ValueNumber

Sub ValueNumber

FieldContent: : =

TransactionId

Message Id/



For sub-valued fields a specific sub-value number within the multi-value can be specified, ifnot defined the first sub-value is assumed.

Field ContentThe content to be added to the specified field. The value supplied will be validated as per thestandard application.

Each MESSAGE.DATA specification should be separated by a ‘,’.

N.B.If a ‘,’ (comma) character is required within the field content then it should be replaced by the‘?’ (Question mark) character.

Foreign Exchange Swaps.Foreign exchange swaps require that information is provided for both legs of a swap within asingle message, in this case information for the first leg is separated from information for thesecond leg by a ‘-‘ (underscore) character. This applies to the multi value number, sub valuenumber, and field data parts of the message.

41.13.7 MESSAGE DATA – Enquiries

The data required to initiate an Enquiry has a different layout to the standard application andis defined as follows:

Figure 41-11 Enquiry request message format

Selection FieldThe name of the field to select which must be either a valid SELECTION.FLDS for the Enquiryor defined in the STANDARD.SELECTION record for the FILE.NAME of the Enquiry.

OperandThe operand for the selection, must be specified with a SELECTION.FLDS, may be EQ, NE,GE, GT, LE, LT, UL, LK, NR.

Field ValueThe data value for the SELECTION.FLDS and requested operand for the selection.

Each Message Data specification should be separated by a ‘,’.

SelectionField

Operand Field Value: =



41.13.8 TRANSACTION ID – returned

The Transaction id for applications is returned in the following format:

Figure 41-12 Transaction ID format

Transaction IdThis will either contain the id supplied initially, or if no id was supplied the next available id(if generated) will be returned.

Message IdThis will contain the message Id of the processed message.

Success / Fail indicatorThis flag will indicate the success or failure of the request for both application and enquirytransactions. The following values can be returned:1 Successful transaction-1 Error encountered-2 Override condition encountered-3 System offline

41.13.9 MESSAGE DATA – returned successful transaction

A successfully processed update will return the fully populated record in the same format asthe data passed to OFS.

41.13.10 MESSAGE DATA – returned errors encountered

A transaction encountering errors when processed will return errors in the Message Data fieldin the following format:

Figure 41-13 Error message format

Field NameThe name of the field in error is returned, the name will be found in the Standard Selectionrecord for the application.

Field Name Multi ValueNumber

Sub ValueNumber

ErrorMessage: : =

TransactionId

MessageId/

Success /Fail/



Multi Value NumberIf an error occurs in a multi valued field the value number will be returned here, no value willbe returned for single value fields.

Sub Value NumberIf an error occurs in a sub valued field the sub value number will be returned.

Error MessageThe error message generated for the associated Field name, Multi Value, sub value will bereturned here. The message will be returned with variable elements expanded.

41.13.11 MESSAGE DATA – returned from successful Enquiry

The data returned from enquiry will be in the following format, in three sections:

Figure 41-14 Format of returned ENQUIRY data

Figure 41-15 Header / caption details for display

Header / Caption IdentifierContains an identifier to determine which element of the header / caption is being defined.May be alphanumeric defined in the underlying ENQUIRY.

Header TextContains the text for the corresponding identifier.

Each repeating series of header definitions is delimited by a ‘/’.

Figure 41-16 Column definitions for the returned data

Columnidentifier

ColumnFormat type

ColumnLabel: : / ,

Header /caption

identifier

HeaderText= / ,

HeaderCaptionDetails

ColumnDetails

ReturnedData, ,



Column IdentifierContains the column identifier, which can be a name or a number. Each column to returninformation must be defined in the underlying ENQUIRY.

Column Format TypeContains the type of data contained in the column. This information can be used forformatting. Possible types include:DATE - Formatted using standard date formatsAMOUNT - Formatted to an amount with decimal format

Column LabelIndicates the name of the column used as the column header.

Each series of column details is followed by a ‘/’

Figure 41-17 Row and column data in a repeating series

Row Value Column nEach row will be comprised of a number of columns defined in the previous element of themessage data. For each column the value will be returned delimited by the <tab> character.Each Row is delimited by a ‘,’.

RowValue

column n

Tab ,



41.13.12 OFS message examples

SECTOR,OFS//PROCESS,PWEISS/123456,7719,DESCRIPTION::=OFS DESCRIPTIONDATA,SHORT.NAME::=OFS DATA

OperatorSECTOR,

OptionsOFS//PROCESS,

N.B. input mode is assumed

User InfoPWEISS/123456,

N.B. user sign on company is assumed

Transaction ID7719,

Field DataDESCRIPTION::=OFS DESCRIPTION DATA,SHORT.NAME::=OFS DATA

Field NameDESCRIPTIONSHORT.NAME

Multi Value: i.e. defaults to 1

Sub Value: i.e. defaults to 1

Field DataOFS DESCRIPTION DATASHORT.NAME



The following example relates to a foreign exchange swap transaction where information isrequired for both legs of the swap, in this case the _ (underscore) character is used to delimitinformation for record 1 from record 2.

FOREX,GTS//PROCESS,GTUSER/QWERTY,,DEAL.TYPE=SW,COUNTERPARTY::=100076,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="firstleg"_"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 leginformation is left blank.

NOTES:1_1="first leg"_"second leg",NOTES:_2:_"second-line"

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

41.13.13 OFS Input and Output message examples

The following example shows input for two sector records in OFS format.

SECTOR,OF//PROCESS,OFSUSER/QWERTY,5011,DESCRIPTION=’TESTreference’,SHORT.NAME=TestrefSECTOR,OF//PROCESS,OFSUSER/QWERTY,5012,DESCRIPTION=’TEST2reference’,SHORT.NAME=Test2 toooooooolooooooongref

The output for the two examples indicates that the second record has been put on hold due toa validation error.

5011/OFS0129900088/1,DESCRIPTION=’TESTreference’:1:1,SHORT.NAME=Testref: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,DEPT.CODE=1:1:15012/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

,@ID::/CCY::/CUSTOMER::/CUST MNEMONIC::/WORK BALANCE::," 17148""GBP" " 100053" " DBL" " 10,000.00"," 17159" "GBP" "100053" " DBL" " "

The returned fields are separated by the tab (ASCII 9) character with lines separated by ‘,’(comma).

41.14 GTS MESSAGE SYNTAX

GTS message syntax is described in the GLOBUS TRANSACTION SERVER chapter of theuser guide.

41.14.1 GTS.MESSAGE examples

Updates to two Sector records.SECTOR,GT,I,5011,DESCRIPTION=TEST local reference,SHORT.NAME=Test LrefSECTOR,GT,I,5012,DESCRIPTION=TEST2 local reference,SHORT.NAME=Test2 LrefT

Forex Swap transactionFOREX,GTS,I,,DEAL.TYPE=SW,COUNTERPARTY=100076,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=_IN,NOTES="first leg"_"second leg":1_1:_"second-line":_2T



41.15 OFS SET UP EXAMPLE :

41.15.1 Using OFS in Batch Mode

41.15.1.1 Create the directories

OFS directories can be positioned where required assuming that access permissions arecorrectly set up.

One possibility would be to create the OFS directories in the data area of a GLOBUS accountas 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 backupstake 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 mayneed to be created.



41.15.1.2 Setup OFS.SOURCE

Once the directories are set up then an OFS.SOURCE record is updated as follows.

A record for Batch mode (initiated by EB.PHANTOM).

Figure 41-18 OFS.SOURCE sample OFS batch set up



Field Name Field Purpose Requirements for BATCH OFS

@ID Id Key of OFS.SOURCERecord

ID allows alphanumeric characters. Usermay define own appropriate name.

DESCRIPTION Simple Description Field Again, use appropriate description toaddress purpose of OFS.SOURCErecord.

SOURCE.TYPE Defines whether you will beusing this OFS.SOURCErecord for BATCH or TELNETprocessing

For batch processing, select BATCH

LOGIN.ID Specifies the UNIX or NT loginthat will automatically initiatethe communication with theexternal source

For BATCH : Leave Blank.

EB.PHANT.ID Specifies the EB.PHANTOMrecord to be used for processingbatch jobs.

For BATCH processing, selectEB.PHANTOM record to be used.

MAX.CONNECTIONS Specifies the maximum numberof on-line OFS connections forthe specified service which canbe active at any one time.

Number must be less than the maximumnumber of users as defined in SPF.

LOG.FILE.DIRDefines the name of thedirectory used to store the logfiles created when running OFS.

Either refer to existing pre-defineddirectory. Otherwise directory will becreated at authorisation.

LOG.DETAIL.LEVELSpecifies the type of OFSmessage logging to beperformed by OFS

Can select as much or as little logging asrequired - does not affect OFS processing.

IN.QUEUE.DIR For batch processing, thedirectory where batches will beplaced for processing

OFS Batch Processing : Enter name ofdirectory to be used for batch processing.

SYNTAX.TYPE Specifies the syntax type formessages to be received

For Batch processing, may be either GTSor OFS.

GENERIC.USER The Generic user is theGLOBUS user that will be usedto access the GLOBUS server.For external users determinesSMS options. Generic Usermust have authority to useEB.PHANTOM.PH i

Must be a valid user on the USER File.Must have authority to useEB.PHANTOM.PH

IB.USER.CHECK Specifies whether transactionssupplied to GLOBUS using thisservice requires the sign on

For Batch processing leave null..



name and password to validatedfor the external user.

Table 41-1 OFS.SOURCE Fields required for BATCH processing.

41.15.1.3 Create the Phantom EB.PHANTOM record for BATCH Mode

Field Name Field Purpose What to enter

@ID ID of EB.PHANTOM Recognisable name

DESCRIPTION Description Recognisable description

RUN.MODE Can either be INTERACTIVE (souser starts & stops each stage) orPHANTOM (process runscontinuously in the background)

Set to PHANTOM

SLEEP.SECS The regularity with which the systemchecks whether there is anything inthe ’in’ directory

The shorter the gap, the more resources aretaken by the system in running thephantom.

TIMEOUT.SECS If a process has difficulty readingfrom a specific file, such that it failsto read the file in the time set here, theprocess will stop, reporting a timeout

At the discretion of the user. Too short agap may result in unnecessary timeouts,too long a gap means delay beforereporting timeout.

GTS.USER.ID Defines the user that will appear inthe audit information for the jobsprocessed by that batch.

User definable, according to reportingrequirements.

OFS.SOURCE The OFS.SOURCE record to beused with this batch.

The id of the OFS.SOURCE recordpreviously created.

Table 41-2 EB.PHANTOM table for OFS BATCH records

An example of an EB.PHANTOM record is shown below :



Figure 41-19 Sample EB.PHANTOM record for OFS Batch Processes

To set the batch phantom running, the EB.PHANTOM record must be VERIFIED (selectphantom with function set to Verify and press F5)

41.15.1.4 Test the EB.PHANTOM record

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



41.15.2 Using OFS in TELNET / Online mode

For accessing via TELNET an Online record is needed. Note that the user will be logging invia a remote session and the login voc will need to initiate the programEB.AUTO.INIT.PROCESS as this will handle the interactive communication process.

Figure 41-20 OFS.SOURCE online sample set up



41.16 OFS Preparation for use with IBI

41.16.1 Configuring OFS for Online Processing

To install and configure OFS on the GLOBUS system, please follow the steps outlined below.

41.16.1.1 Step 1 - Pre-configuration procedures

• Create a new NT or UNIX user account to be used with OFS. Consult your UNIX or NTsystems administrator for further assistance regarding this.

• Ensure that the LOGIN record of the VOC file contains the correct syntax to launch theroutine EB.AUTO.INIT.PROCESS. See ’Figure 41-2 Sample login VOC for use withonline OFS Processing’ for an example of a LOGIN record which would facilitate this.

41.16.1.2 Step 2 - Preparing OFS for Telnet Mode

• Create an OFS.SOURCE record for TELNET. For additional information, check theindividual help text for each field



Field Name Field Purpose Requirements for TELNET OFS

@ID Id Key of OFS.SOURCERecord

ID allows alphanumeric characters. Usermay define own appropriate name.

DESCRIPTION Simple Description Field Again, use appropriate description toaddress purpose of OFS.SOURCErecord.

SOURCE.TYPE Defines whether you will beusing this OFS.SOURCErecord for BATCH or TELNETprocessing

For online processing, select TELNET.

LOGIN.ID Specifies the UNIX or NT loginthat will automatically initiatethe communication with theexternal source

For TELNET : UNIX servers, enter UNIXid to be used. For NT Servers, enterDOMAINNAME/User ID, EG NT1/User1

EB.PHANT.ID Specifies the EB.PHANTOMrecord to be used for processingbatch jobs.

For TELNET, leave blank.

MAX.CONNECTIONS Specifies the maximum numberof on-line OFS connections forthe specified service, which canbe active at any one time.

Number must be less than the maximumnumber of users as defined in SPF.

LOG.FILE.DIRDefines the name of thedirectory used to store the logfiles created when running OFS.

Either refer to existing pre-defineddirectory. Otherwise directory will becreated at authorisation.

LOG.DETAIL.LEVELSpecifies the type of OFSmessage logging to beperformed by OFS

Can select as much or as little logging asrequired - does not affect OFS processing.

IN.QUEUE.DIR For batch processing, thedirectory where batches will beplaced for processing

For TELNET - leave blank

SYNTAX.TYPE Specifies the syntax type formessages to be received

For OFS Online Processing requirements,this field must be set to OFS.

GENERIC.USER The Generic user is theGLOBUS user that will be usedto access the GLOBUS server

Must be a valid user on the USER File.

IB.USER.CHECK Specifies whether transactionssupplied to GLOBUS using thisservice requires the sign onname and password to validatedfor the external user.

If the OFS.SOURCE is to be used inconjunction with IBI (i.e. from a web/htmlsource) then this should be flagged Y.Otherwise N or left NULL.

Table 41-3 OFS.SOURCE Fields required for ONLINE processing.



41.16.1.3 Step 3 - Test the TELNET configuration

• Invoke a TELNET session with the GLOBUS server.• When prompted for your user name and password, use the NT or UNIX user you created

in Step 1• If you are using NT, you will also be prompted to enter the name of the GLOBUS account

being used.• If your set-up has been successful you will not be prompted to start GLOBUS. You will

instead be at a ’command’ line from which OFS Messages can be sent.• Press enter, if successful, you will be prompted with APPLICATION / OPERATION

MISSING• OFS is now set-up correctly

If you now type the following example OFS Message, you should get a reply,ENQUIRY.SELECT,,< GLOBUS SIGNON NAME>/<PASSWORD<,ACCOUNT-LIST

• The enquiry should now be processed and the answer displayed on your screen.



41.17 OFS message syntax example

41.17.1 General structure

• The input/output OFS message is divided into the following components shown bellow.

Operation,Options,User Information, Transaction ID, Message data

• NOTE: If left blank, certain components can be automatically allocated by the system, seethe example bellow

OFS message example (enquiry)

ENQUIRY.SELECT,,INPUTT/123456,ACCOUNT-LIST,CUSTOMER.MNEMONIC:EQ=ALEXCOURT

Operator Globus account to be executedENQUIRY.SELECT

Options: Version of the applicationN/A

User information: Globus sign on name & passwordINPUTT/123456

Transaction ID: The enquiry to be executedACCOUNT LIST

Message Data – Enquiries: Data required to initiate an enquiry

Selection field: CUSTOMEROperand: EQUAL TOField Value: ALEXCOURT



41.18 Auto-shutdown and Auto-startup of EB.PHANTOMs

EB.PHANTOM records can be set to automatically shut down at End-of-Day, and toautomatically restart the with Start On Line. This can be done through fields AUTO.SHUTDOWNand AUTO.STARTUP on the EB.PHANTOM record. If AUTO.SHUTDOWN is set to ’Yes’ then atInitiate End of Day the system looks for all EB.PHANTOM records with AUTO.SHUTDOWN setto ’Y’, and sets PHANT.STOP.REQ to STOP for those records. The converse occurs withAUTO.STARTUP, where at Start Online the system looks for EB.PHANTOM records withAUTO.STARTUP set to Y and activates them.

Figure 41-21 EB.PHANTOMs automatically closed at End of Day



Index of Tables & Figures

Table 41-1 OFS.SOURCE Fields required for BATCH processing...........................................................41-26Table 41-2 EB.PHANTOM table for OFS BATCH records.......................................................................41-26Table 41-3 OFS.SOURCE Fields required for ONLINE processing. ........................................................41-30

Figure 41-1OFS Architecture..........................................................................................................................41-2Figure 41-2 Sample login VOC for use with online OFS Processing ...........................................................41-3Figure 41-3 EP.MONITOR phantom enquiry ...............................................................................................41-5Figure 41-4 Definition of OFS.SOURCE batch processing record...............................................................41-8Figure 41-5 Setting up EB.PHANTOM to run OFS in batch mode.............................................................41-9Figure 41-6 OFS message structure ..............................................................................................................41-12Figure 41-7 Option format.............................................................................................................................41-13Figure 41-8 User information format ...........................................................................................................41-13Figure 41-9 Transaction ID format...............................................................................................................41-15Figure 41-10 Update message format ...........................................................................................................41-15Figure 41-11 Enquiry request message format ............................................................................................41-16Figure 41-12 Transaction ID format.............................................................................................................41-17Figure 41-13 Error message format..............................................................................................................41-17Figure 41-14 Format of returned ENQUIRY data.......................................................................................41-18Figure 41-15 Header / caption details for display........................................................................................41-18Figure 41-16 Column definitions for the returned data ..............................................................................41-18Figure 41-17 Row and column data in a repeating series ...........................................................................41-19Figure 41-18 OFS.SOURCE sample OFS batch set up................................................................................41-24Figure 41-19 Sample EB.PHANTOM record for OFS Batch Processes....................................................41-27Figure 41-20 OFS.SOURCE online sample set up .......................................................................................41-28Figure 41-21 EB.PHANTOMs automatically closed at End of Day...........................................................41-33

OPEN FINANCIAL SERVICE - MarkMail

Documents

Transcript of OPEN FINANCIAL SERVICE - MarkMail