Detailed Software Technical Design (DSTD) for e-rl Project

(1)

Annex 3

Detailed Software

Technical Design (DSTD)

for

e-RL Project

.

ICTA-eRL-DSTD-1.2

(2)

TABLE OF CONTENTS

1 INTRODUCTION ... 3

1.1 PURPOSE ... 3

1.2 SCOPE ... 3

1.3 DEFINITIONS,ACRONYMS AND ABBREVIATIONS ... 4

1.4 REFERENCES ... 5

2 ASSUMPTIONS ... 6

3 SYSTEM ARCHITECTURE ... 7

3.1 HIGH LEVEL ARCHITECTURE OF THE E-RLSYSTEM ... 7

3.2 E-RLAPPLICATION ARCHITECTURE ... 8

4 DATA MIGRATION ... 9

5 DESIGN FOR SYNCHRONISATION MODULE ... 10

5.1 DESIGN FOR DATA SYNCHRONISATION CLIENT ... 11

5.2 DESIGN FOR DATA COMMUNICATION ... 15

5.3 DESIGN FOR DATA SYNCHRONISATION SERVICE MODULE ... 16

5.3.1 XML Loader ... 16

5.4 DESIGN FOR MAINTAINING SYNCHRONISATION STATUS ... 17

5.5 SYNCHRONISATION OF REFERENCE DATA ... 19

6 DESIGN FOR DATA UPLOAD MODULE ... 20

6.1 DESIGN FOR DATA UPLOADING ... 20

6.1.1 User Profile ... 28

6.1.2 UI Screen Design ... 28

6.1.2.1 Screen Layout ... 28

6.1.2.2 Validations ... 28

7 DESIGN FOR LOOKUP MODULE ... 29

7.1 DESIGN FOR REVENUE LICENCE LOOKUP SERVICE ... 29

7.1.1 Input Parameters ... 29

7.1.2 Output Results ... 30

7.2 DESIGN FOR LOOKUP PORTLET ... 33

7.3 DESIGN FOR SMSLOOKUP ... 35

8 DESIGN FOR USER MANAGEMENT MODULE ... 38

8.1 DESIGN FOR ADD NEW USER FEATURE... 39

8.1.1 User Profile ... 39

8.1.2 Navigation Map ... 39

8.1.3 UI Screen Design ... 40

8.1.3.1 Screen Layout ... 40

8.1.3.2 Validations ... 41

(3)

8.2 DESIGN FOR DELETE USER FEATURE ... 43 8.2.1 User Profile ... 43 8.2.2 Navigation Map ... 43 8.2.3 UI Screen Design ... 43 8.2.3.1 Screen Layout ... 44 8.2.3.2 Validations ... 44

8.2.4 Object Model/Data Flow Design ... 45

8.3 DESIGN FOR EDIT USER DETAILS FEATURE ... 45

8.3.1 User Profile ... 45

8.3.2 Navigation Map ... 45

8.3.3 UI Screen Design ... 45

8.3.3.1 Screen Layout ... 46

8.3.3.2 Validations ... 47

8.4 DESIGN FOR SEARCH USERS FEATURE ... 48

8.4.1 User Profile ... 48

8.4.2 Navigation Map ... 48

8.4.3 UI Screen Design ... 48

8.4.3.1 Screen Layout ... 49

8.4.3.2 Validations ... 49

9 DESIGN FOR ONLINE REVENUE LICENCE RENEWAL PORTLET ... 51

9.1 WEB SERVICES DEFINITION FOR INSURANCE ESERVICE ... 52

9.2 WEB SERVICES DEFINITION FOR VET ESERVICE ... 53

10 DATABASE DESIGN ... 54

10.1 ENTITY RELATIONSHIP DIAGRAM ... 55

10.2 DATA ARCHIVAL ... 56

11 CORE TECHNICAL SERVICES DESIGN ... 57

11.1 SECURITY ... 57

12 DEPLOYMENT PREREQUISITES ... 59

12.1 HARDWARE SPECIFICATIONS ... 59

12.2 NETWORK SPECIFICATIONS ... 60

(4)

LIST OF FIGURES

Figure 3.1 - High Level Architecture of the e-RL System ... 7

Figure 3.2 - e-RL Application Architecture ... 8

Figure 5.1 - Synchronisation Process ... 10

Figure 5.2 - Synchronisation Process ... 11

Figure 5.3 - Sequence Diagram for Data Extraction Module ... 12

Figure 5.4 - Job Scheduling Process ... 14

Figure 5.5 - Communication Module ... 15

Figure 5.6 - Synchronisation of Reference Data ... 19

Figure 6.1 - Non-WP DS Data Upload Process ... 20

Figure 6.2 - Non-WP DS Data Upload Screen ... 28

Figure 7.1 - Class Diagram of the Output ... 30

Figure 7.2 - Sequence Diagram for Lookup Service ... 32

Figure 7.3 - High Level Design of Revenue Licence Lookup Portlet ... 33

Figure 7.4 - Activity Diagram for Lookup Portlet... 34

Figure 7.5 - High Level Design of SMS Lookup ... 35

Figure 8.1 - Collaboration Diagram for User Management Module ... 39

Figure 8.2 - Navigation Map for Add User Feature ... 39

Figure 8.3 - Add New User Screen ... 40

Figure 8.4 - Sequence Diagram for Adding New User ... 42

Figure 8.5 - Navigation Map for Delete User Feature ... 43

Figure 8.6 - Delete User Screen ... 44

Figure 8.7 - Sequence Diagram for Deleting a User ... 45

Figure 8.8 - Navigation Map for Edit User Feature... 45

Figure 8.9 - Edit User Screen ... 46

Figure 8.10 - Edit User Screen ... 47

Figure 8.11 - Navigation Ma for User Search Feature ... 48

Figure 8.12 - Search User Screen ... 49

Figure 8.13 - User Search Screen ... 50

Figure 9.1 - e-Citizen RL Renewal Module ... 51

Figure 10.1 - Physical Database Design ... 54

(5)

LIST OF TABLES

Table 1.1 - Scope Inclusions and Exclusions ... 4

Table 5.1 - Synchronisation Status Table ... 17

Table 5.2 - Synchronisation Statuses ... 18

Table 6.1 - Format of Data Upload Files ... 27

Table 7.1 - Input Parameters and Output Results for Lookup Service ... 30

Table 7.2 - Properties of the Classes ... 31

Table 8.1 - User Roles in the e-RL Application ... 38

Table 9.1 - Web Services Definition for Insurance eService ... 52

(6)

Document Revisions

Date Version Description Author

2009-06-22 0.1 – Draft Created initial draft with data synchronisation module details

Thilina Kularathna 2009-07-16 0.2 – Draft Added Stage 2 design details Padman

Reginold 2009-07-31 0.3 – Draft Incorporated internal review

comments

2009-08-03 1.0 Client shared version

2009-08-24 1.1 Incorporated Data Upload Tool

Validations

2009-08-28 1.2 Incorporated ICTA review Comments

and added appendix with all WSDLs

Change Log

Revision ICTA Review Comment Review Incorporation Comments

1.2

Section 11.1 - 2-way SSL is not always required for certain service.

Added 1 way SSL for eService security Section 12.1 – Incorporate

updated hardware specifications

Updated hardware configuration has been added to the document

(7)

1 Introduction

1.1 Purpose

This document describes the detailed technical design for the e-Revenue Licence project.

1.2 Scope

Component In Scope Out of Scope

1 Canonical Database Design

● Compatibility with WPDMT and Western Province DS database schemas

● Compatibility with non-Western Province DS database schemas 2 Data Synchronisation ● Synchronisation of data between canonical

databases at DSs and the central database

● Reliable messaging and error handling

3 Data Migration ● Migration of data from all 40 DSs of western province to the central database

● Correction of data inconsistencies in old revenue licence records 4 Provincial Data

Upload Module and Service

● Manual upload of data from other provinces brought to the WPDMT to the central canonical database

● Definition of upload formats

● Getting data from other provinces to the WPDMT ● Convert provincial data into

the specified format

5 Revenue Licence Lookup Portlet

● Reading of data available in the central database

● Addition, deletion or modification of RL information

● Securing access to the RL Lookup portlet beyond user token

● WAP access to lookup portlet

6 Mobile Lookup of Revenue

Licence

● Provide an eService for SMS lookup

● Authorising SMS by mobile number of source

● e-RL functionalities other than licence information lookup (Update, Delete, etc.)

● Developing an SMS gateway

● Ensuring the integrity of SMS transmission

(8)

7 Web Services to External

Systems

● Consumption of services available through LIX ● Defining interface

specifications

● Development of services to connect to external systems in order to retrieve

information 8 Revenue

Licence Renewal Portlet

● Renewing annual revenue licence

● Redirecting to Payment Gateway for credit card processing

● Online verification of VET and Insurance by

consuming web services exposed through a single interface

● Processing of credit card payments by connecting to banks

● WAP access to Revenue Licence renewal portlet

9 Data Security ● Within the e-RL application and the e-RL country portlets

● LIX, Country portal, OS and database security controls

Table 1.1 - Scope Inclusions and Exclusions

1.3 Definitions, Acronyms and Abbreviations

Term Explanation

CCPGP Credit Card Payment Gateway Proxy

DB Database

DMT Department of Motor Traffic DS Divisional Secretariat

DSRS Detailed Software Requirement Specification

e-RL e-Revenue Licence

eServices Electronic Services GUI Graphical User Interface HTTP Hyper Text Transfer Protocol

HTTPS Hyper Text Transfer Protocol Secure

ICTA Information and Communication Technology Agency IDC Internet Data Centre

LGN Lanka Government Network LIX Lanka Interoperability Exchange MPG Mobile Payment Gateway

On the Wheel Drive-in Revenue Licence counter where a customer may renew their Revenue Licence

(9)

Term Explanation

RL Revenue Licence

SAGE Software Architecture Group of Experts Superuser Supervisor / Administrator / Commissioner

UI User Interface

VET Vehicle Emissions Testing

WPDMT Western Province Department of Motor Traffic

WS Web Service

WSDL Web Services Description Language

1.4 References

(10)

2 Assumptions

1. Network infrastructure and network security implementation is considered out of scope

2. Maintenance of the network infrastructure and providing security updates for firewalls are considered out of scope

3. Limitations in country portal and LIX will not be addressed in the scope of this project

4. Automated data synchronisation is unidirectional and occurs from the DS to central database. However, central database to DS database synchronisation of reference data can be manually initiated by the DS application

5. Synchronisation issues will be identified by the synchronisation status report. However, rectification of same will not be handled by the system and should be a manual offline process

6. Validating the accuracy of the Non-Western province data upload feeds will not be done by the e-RL data upload application. Only the format of the data will be validated and if the data is not received in the specified format, the data feed will be rejected

7. The e-RL system will not handle any security lapses in the part of the mobile network

(11)

3 System Architecture

3.1 High Level Architecture of the e-RL System

(12)

3.2 e-RL Application Architecture

(13)

4 Data Migration

Data migration involves the process of transforming and transferring existing data from the legacy databases at the WPDMT and other Western Province DSs to a canonical database. The data sources for migration comprised of two types of legacy databases - one being an SQL Server Database (at WPDMT) and the others based on Oracle (at DS offices). The destination data source is the central canonical database.

The methodology used for data migration is given below: 1. Identification of transaction tables -

The initial task is to identify the tables of the legacy databases which need to be migrated.

2. Identification of transaction table mapping -

This includes the definition of a mapping between the schema of the legacy databases and the canonical database schema.

3. Develop migration scripts -

Migration scripts were developed using Talend Open Studio (http://www.talend.com/products-data-integration/talend-open-studio.php), an Open Source data integration tool.

Please refer to e-RL Data Migration Plan

(14)

5 Design for Synchronisation Module

This section describes the detailed design of the one-way data synchronisation service from a DS database to the central database.

The data synchronisation module provides the core functionality of propagating up-to-date data from each DS database to the central database. This is designed to be a scheduled task which will run at a configurable pre-defined frequency and will fulfil the requirement of maintaining up-to-date records in the central database. This section explains the automated synchronisation that will be implemented from DSs to central database while the reverse process will not be facilitated by this module.

Vehicles will be assigned to the DS at which the latest revenue licence has been obtained. This will be known as the „last issued DS‟ under the new e-RL system. At the time of renewal, the e-RL application will fetch the required information from the central database if the latest record does not exist in the local database. Thereafter, the particular DS will be assigned as the „last issued DS‟ of that vehicle.

The diagram below shows a high-level overview of the modules involved in the data synchronisation service design. The synchronisation between a single DS and the central database is shown in the diagram for clarity.

(15)

Figure 5.2 - Synchronisation Process

The transaction tables of the canonical database that require synchronisation are the “Vehicle_Owner”, “Vehicle”, “Rev_License_Record” and “Payment” tables.

(16)

The data synchronisation client is responsible for extracting the set of data that has been changed in the local database since the previous synchronisation. A change would include an insertion or any deletion / modification to an existing record. It is essentially the „delta‟ from the last synchronised state of the DS database that should be sent to the canonical database.

Figure 5.3 - Sequence Diagram for Data Extraction Module

The following terms and definitions will be used for explaining the functionality of this module:

 Synchronisation data begin time – Earliest modified / inserted time of data selected for synchronisation

 Synchronisation data end time – Latest modified / inserted time of data selected for synchronisation

 Synchronisation job start time – Start time of the synchronisation job  Synchronisation job finish time – End time of the synchronisation job

(17)

The core of the data synchronisation client is a stored procedure that will identify and prepare the set of database records that should be synchronised. Furthermore, the data synchronisation module is responsible for the following tasks:

1. Invoke Synchronisation

The synchronisation job will be invoked by a scheduler in the e-RL application at the DS offices.

2. Obtaining the synchronisation job identification number

This will be performed by accessing the „synchronisation status‟ table at the central database through a web service. Initially, the data synchronisation client at the DS will send its authority ID and request for the synchronisation data end time of the previous job, from this table.

If a previous synchronisation job exists, the synchronisation data end time will be sent to the data synchronisation client. This will be followed by a request by the Data Synchronisation Client module for a Job ID with the synchronisation data start time and end time of the synchronisation job.

The start time will be equal to the end time of the data of the previous synchronisation job, while the end time will be the start time incremented by a pre-defined synchronisation period.

This request will be assigned a job ID as the response and it is allowed to proceed with synchronisation. If the last synchronisation job is still incomplete, the current request to synchronise will be rejected. This is done by returning „-1‟ as the job id. Synchronisation will recommence at the next scheduled time. If any problem occurs during synchronisation, the entire synchronisation job will be rolled back.

(18)

Figure 5.4 - Job Scheduling Process

A prerequisite for synchronisation is that every DS should have one record in the synchronisation status table indicating the latest time of the DS data in the central database. Therefore, at the end of migrating the data of a particular DS, a record indicating the status will be entered to the synchronisation status table.

3. Identifying the set of database records to be synchronised

Having determined the time window to be synchronised, it will retrieve the particular database records from the transaction tables that have been inserted or updated since the last successful synchronisation. This data will be extracted using a stored procedure.

4. Load the data into temporary tables

(19)

5. Generate the XML file

Once the data is loaded into the temporary tables, the data synchronisation client will use them to generate the XML data file containing the data to be synchronised.

6. Archive the XML Payload

The XML Payload file will be archived (in .zip format) before being transferred to the communication module to be sent to the central database.

5.2 Design for Data Communication

The purpose of the communication module is to transmit a payload containing database records from the client side to the server side while ensuring data integrity. It utilises the support extended by the Axis2 Web Services framework in order to send attachments in an optimised manner. The payload for transmission will be an archived file and will contain the data that needs to be synchronised in XML format. However, it can handle any type of data file that is either text or binary.

This module is designed to work independently from the rest of the synchronisation modules.

Figure 5.5 - Communication Module

Being a Web Service, the communication module follows the client server model and the communication module client will perform the following tasks.

1. Get the archived data file and calculate the checksum

2. Transmit data over to the service along with its checksum value and get the acknowledgement

(20)

In the case of successful data transfer, the communication module service will perform the following tasks:

1. Calculate the checksum of the entire data file

Calculate the checksum value for the data file. Send an acknowledgment to the client if the checksum matches the value sent by the client.

2. Save the data file to a predefined location to be used by the Data Synchronisation Service Module

5.3 Design for Data Synchronisation Service Module

The Data Synchronisation Service Module provides the three main functions listed below:

1. Read and load the XML Payload file

The archived XML data file given by the communication service will be extracted and reading of the XML data file will commence. The data will be loaded into the temporary tables using „XML Loader‟ described in the next section.

2. Update central database

Call the stored procedure to insert/update data from the temporary tables into the central canonical database.

3. Update the synchronisation status table indicating the completion of the synchronisation

5.3.1 XML Loader

Retrieving the records into the canonical database by parsing the XML data file is one of the most important functionalities of the data loading module. Depending on the amount of the data that needs to be loaded into the database, this can easily become a performance bottleneck.

e-RL data synchronisation will use the „XML Loader‟, which has been developed in-house. It is a java based light weight tool that can be used to load XML data into the database tables. This has been used extensively in various products and has proven capabilities for similar tasks.

It is necessary to provide a database parameter file and a table mapping file for the XML Loader to connect to the target database and identify the relationships among the tables. It will then read the XML data file containing the records that needs to be synchronised and will load them into the temporary tables.

(21)

5.4 Design for Maintaining Synchronisation Status

One of the most important aspects of the data synchronisation process is to accurately maintain the status of synchronisation. Since the data synchronisation happens between two databases the most convenient way to achieve that is to maintain a database table that will keep the information regarding a particular synchronisation task as a database record.

The synchronisation status table will be maintained in the central database. The schema of the synchronisation status table in the central database would be as given below.

Column Name Data Type Nullable Default Description

Job_ID BIGINT(20) No (Primary Key)

Authority_Code VARCHAR(20) No Sync_Data_Begin_Time DATETIME No Sync_Data_End_Time DATETIME No

Sync_Job_Start_Time DATETIME Yes Null Sync_Job_Finish_Time DATETIME Yes Null Synchronisation_Status VARCHAR(45) No

One of the statuses given in the table below

Payload_Received_Time DATETIME Yes Null

Synchronization_Type SMALLINT Yes Null

One of the following types:

 0 - Data migration (one time task)

 1 - DS to central data migration  2- non-Western province data upload Payload_File_Name VARCHAR(40 0) Yes Null

Table 5.1 - Synchronisation Status Table

Status Description

JOB_ID_ISSUED The synchronisation job was started from DS end. The Job ID was requested and issued

PAYLOAD_RECEIVED XML payload (Sync. data files) received to the server. (This status will be set by the application)

(22)

TEMP_TABLES_UPDATED

Successfully loaded data (from XML payload) into the synchronisation temporary tables. This status will be set once the data loading finished

IN_PROGRESS

The synchronisation of transaction tables is in progress. This status will be set by the „main data import SP‟ at the beginning of the data import process.

COMPLETED The synchronisation was successfully completed. This will be updated by the data import SP

FAILED In case of any error in the above states

NO_CLIENT_SYNC_DATA No data was available for synchronisation at the client side

Table 5.2 - Synchronisation Statuses

There will be a unique Job ID created for each synchronisation task at the service (central database) side and it will be required for the client to start the synchronisation. The client can obtain this Job ID by making a Web Service call. Once the synchronisation task is completed, the synchronisation table will be updated in the central database so that subsequent synchronisations of a particular authority will be aware of the last successful synchronisation.

(23)

5.5 Synchronisation of Reference Data

There are many data elements in the canonical database that are used as „reference‟ data by the transaction tables (e.g.: The Vehicle table uses the Authority table data as reference). Any update to reference data will be made to the central database and this has to be updated in the DS databases in order to preserve consistency. However, unlike the automated synchronisation of the transaction tables which were described in the previous sub sections; this will only take place on-demand (at the click of a button by the DS administrator). Since these reference data tables contain small amount of data synchronisation of reference tables will happen through data services. In order to do this all the reference tables in the central database will be exposed through data services and the e-RL application can access the data services via a data service client.

Figure 5.6 - Synchronisation of Reference Data

By using data services, the DS application will look for any updates in the central database and it updates the corresponding table in the DS database accordingly.

(24)

6 Design for Data Upload Module

This section describes the detailed design of the upload of Non-western Province DS data from the WPDMT to the central database.

6.1 Design for Data Uploading

The diagram below describes a high level design of the data uploading module. The data upload will have end-to-end security via LIX. There will be no user authentication to identify the administrator. The input to the module will be a zip file containing three CSV files which adhere to the format described in the subsequent sections.

(25)

Following are the prerequisites for the data upload module:

1. MySQL databases created using canonical database schema should exist in both client and server side.

2. In Linux environment it is assumed that the user has sufficient file permissions to read, write and execute. It is highly recommended to run the Data Synchronisation as the „root‟ user.

3. e-Revenue Licence Data Synchronisation module is installed and functioning properly.

4. Feed should adhere to the format defined for each entity (Vehicle/Vehicle Owner/Revenue Licence). If not the feed will be rejected and a message will be displayed to the user

5. Reference Data associated with each entity should match what is available in the canonical database. (e.g.: Fuel Types, Vehicle Class etc). Here what is recommended is to have mappings in the source DS database to convert them in to the correct format in the canonical database (similar to the approach followed in Data Migration)

6. Correctness/format validation of Licence Number, Chassis Number, Engine Number, Tare Weight, Gross Weight and Number of Seats will not be in the scope of the data upload tool. Source system should be responsible for sending it in the correct format

7. Users / Counters / Authorities of each non-Western Province DS should be available in the Central database. If not the feed is rejected and audit log will be updated with the reason for the failure. Admin should add relevant entity to the database using eRL application and continue re-processing the feed

8. Each column in the feed should be received in the correct data type (Especially date and integer types). If not the feed will be rejected for corrections

9. Validation on the specified format e.g. correct file naming according to the given naming convention, use of correct file type, correct separators being used etc

(26)

1. Licences received either without vehicle or vehicle owner will be rejected. Updates to non-existent records in central database is rejected (either vehicle/vehicle owner/ license)

2. If vehicle owner/vehicle records are received to be inserted and license record to be updated, then it is an invalid scenario.

3. If vehicle owner records are received to be inserted and vehicle & license records received to be updated, then it is an invalid scenario

4. If vehicle owner records are received to be updated and vehicle records to be inserted, then it is an invalid scenario

5. Duplicate license records received to be inserted are rejected

Note: Neither NIC nor Company registration number is part of the vehicle owner data feed. This will be a limitation identifying vehicle owners uniquely. (If a given person has two vehicles, there will be two entries in the vehicle_owner table. This is because without a unique identity two vehicles cannot be mapped to the same owner record in the vehicle owner table. This is a known limitation identified from stage 1)

Any rejections when uploading that occur due to not meeting the validations will be displayed as part of the Synchronization status report in the e-RL application. The records that pass the validations will be successfully uploaded.

(27)

The following tasks will be performed by the Data Uploading application: 1. Extract the archive and check for the availability of the three CSV files

The archive file and the three CSV files should follow the naming convention given below:

 Zip archive must be named as follows: FILE NAME_YYYY-MM-DD.zip  CSV file containing vehicle owner details

vehicle_owner_YYYY-MM-DD.csv  CSV file containing vehicle details

vehicle_YYYY-MM-DD.csv

 CSV file containing revenue licence details license_YYYY-MM-DD.csv

2. Parse the CSV files and convert to XML 3. Transfer XML files to synchronisation module 4. The uploaded file will be saved as:

Payload_<AUTHORITY_CODE>_YYYY-MM-DD.zip

5. If the data has been successfully uploaded, a record will be inserted to the synchronisation_status table as shown below.

Job_ ID Author ity_Co de Sync_Data_ Begin_Time Sync_Data _End_Time Sync_Job _Start_Ti me Sync_Job _Finish_Ti me Synchro nisation _Status Payload_ Received _Time Synchr onisatio n_Type Payload _File_N ame 73 CMB. CMB 2009-07-28 00:00:00 2009-07-28 11:59:00 PAYLO AD_RE CIEVED 2009-07-28 11:11:14 2 Payload _CMB.C MB_200 9-12-05.zip

(28)

The format of the three CSV files is given below:

File Fields Mapping field from

DS database Data Type Description

CSV file containing vehicle owner details Name VEHICLES.INIT+ VEHICLES.SURNAME _VARCHAR(100)

Addr1 VEHICLES.ADDR1 _VARCHAR(100)

Addr2 VEHICLES.ADDR2 _VARCHAR(100)

City VEHICLES.ADDR3 _VARCHAR(100)

Created_Time Time of creation of

the record DATETIME

Created_UserName

If this is not

available, a dummy value will be used and the user should be available in the canonical database

VARCHAR(60)

Modified_Time

If the RECORD is modified time of the modification

DATETIME

Modified_UserName

If this is not

available, a dummy value will be used and the user should be available in the canonical database VARCHAR(60) Vehicle_Registration_No VEHICLE .SERIES + VEHICLESEQUENCE E.g.: (GH-XXXX) VARCHAR(20) This a unique number which links the vehicle owner to a vehicle. As a prerequisite, Vehicle Registration number should be available with correct format Authority_Code Matching of the authority code in canonical database VARCHAR(20) Action Indicates whether the record is an Insert, “I” or Update, “U” CHAR(1) Indicates whether the record is an Insert, “I” or Update, “U” CSV file containing vehicle details Vehicle_Reg_No VEHICLE .SERIES + VEHICLESEQUENCE E.g.: (GH-XXXX) VARCHAR(20) Vehicle_Class_Code Matching vehicle classes in the canonical database. This might differ from DS to DS. This should be generated using the column

TYPES.VDESC

(29)

Chassis_No _{VEHICLES .CHASSINO} VARCHAR(50)

Engine_No _{VEHICLES .ENGINNO} VARCHAR(50)

First_Reg_Date _{VEHICLES REGDATE} DATE

Tare_Weight _{VEHICLES .UWGT} DECIMAL(10,2)

Gross_Weight

VEHICLES .GWGT DECIMAL(10,2)

No_Of_Seats _{VEHICLES .SEATS} INTEGER

Authority_Code Matching authority _{code in Canonical} database

VARCHAR(20)

Fuel_Type

Matching Fuel code in Canonical Database. This can be generated from VEHICLES .FDESC VARCHAR(20) Petrol / Diesel / Kerosene / Gas / Electric / <NO_FUEL_TYPE > Vehicle_Status Should be mapped to one of the values below. VALID BLACKLISTED, INELIGIBLE, FREE LICENSE , NON USER, ARCHIVED Mapping should be done with TYPES.VDESC Column in DS database. VARCHAR(20) Possible values VALID BLACKLISTED, INELIGIBLE, FREE LICENSE , NON USER, ARCHIVED Created_Time

Time of the creation of the record in DS database

DATETIME

Created_UserName

created user of the record.

If this is not

VARCHAR(60)

Modified_Time Time of modification

of the record DATETIME

Modified_UserName

Name of the user who modified the record

If this is not

VARCHAR(60)

Ineligible_Reason VARCHAR(45)

(30)

the record is an Insert, “I” or Update, “U” CSV file containing revenue licence details

License_No _{LICENSES .LICNO} VARCHAR(20)

License_Type_Code

If rec_amt > 0 then licence type = “AR” else

“NI” VARCHAR(10)

AR - Arrears NI - Normal Issuance

License_Year _{LICENSES .YEAR} DATE

Vehicle_Reg_No

VEHICLE .SERIES + VEHICLESEQUENCE E.g.: (GH-XXXX)

VARCHAR(20) License_Issued_Date _{LICENSES .ISSDATE} DATE

License_Expiry_Date _{LICENSES .UPTO} DATE Insurance_Status

EXINDATE is for nullability. If it is Null It is stored as N and If it is Not Null it is stored as Y

VARCHAR(20) Insurance_Expiry_Date _{LICENSES .EXINDATE} DATE

VET_No LICENSES .RECIPT_NO VARCHAR(50)

Vehicle Emissions Testing certificate number

Counter_Description

Name of the counter issued the revenue licence. This counter should be available in the canonical database VARCHAR(100) License_Status_Descript ion

Here we can always

use „ISSUED‟ state VARCHAR(20)

Either Issued, Verified, Deleted or Paid

Authority_Code

code of the authority which issued the license

VARCHAR(20)

License_Amount LICENSES .DUE_AMT DECIMAL(10,2) License fee for this _year

Arrears _{LICENSES .REC_AMT} DECIMAL(10,2) Arrears fee

Fine _{LICENSES .FINE} DECIMAL(10,2) Total fine

Tax _{LICENSES .RDTAX} DECIMAL(10,2) Created_Time

Time of the record created in the database

DATETIME

Created_UserName

User who created the record If this is not

VARCHAR(60)

Modified_Time Time of the

(31)

record

Modified_UserName

If this is not

VARCHAR(60)

Route_Permit_No LICENSES .RO_PE_NO _VARCHAR(100)

Route_Permit_Expiry_D ate

This can be empty string since this is not available in the DS database

DATE

Fitness_Test_Status

LICENSES .FITNO (If we have a value for fit number „Yes‟ Otherwise „No‟

VARCHAR(10)

Comments Empty string VARCHAR(512)

Entered_Date _{LICENSES .ISSDATE} DATE

Effective_Date keep this field empty _DATE

Action

Indicates whether the record is an Insert, “I” or Update, “U” CHAR(1) Indicates whether the record is an Insert, “I” or Update, “U”

Table 6.1 - Format of Data Upload Files Furthermore, the CSV file should adhere to the following:

 The field separator should be the pipe symbol (|)  Each row must end with a new line

(32)

6.1.1 User Profile

Administrators at the WPDMT can upload data to the central database.

6.1.2 UI Screen Design

Page Summary

Name Upload non-WP DS data

Description The user uploads the CSV file containing the non-WP DS data to the central canonical database.

Use Case Number UC-25

6.1.2.1 Screen Layout

Figure 6.2 - Non-WP DS Data Upload Screen

Button Description

Browse Prompts the user to select the CSV file containing the non-WP DS data.

Upload Uploads the data in the CSV file into the central canonical database

6.1.2.2 Validations

Error Trigger Action Description

If a file is not specified

Displays the message “Please select a file to be uploaded”.

Displays an error message and prompts the user to select a file containing the relevant data. The Zip file does not

contain the three CSV files required

Displays the message “The Zip file does not contain required CSV files”.

Displays an error message and prompts the user to select a new file.

If the file does not adhere to the specified format

Displays the message “File does

(33)

7 Design for Lookup Module

This section elaborates the detailed design on the Revenue Licence Lookup Module.

7.1 Design for Revenue Licence Lookup Service

This section describes the Revenue Licence Lookup Service, which can be accessed by authorised personnel to retrieve revenue licence information.

This is a common service where users can retrieve the revenue licence information using different clients. For the purpose of this project, it will be implemented for lookup requests coming through the e-RL Lookup Portlet of the Country Portal and the mobile lookup requests via SMS.

The input parameters and output results for this service are given section 6.1.1.

7.1.1 Input Parameters

Parameter Name Description Value Expected Result

1 Vehicle Registration Number

Vehicle Registration Number of vehicle

Empty ServiceException with

the error message “Enter a vehicle registration number” Invalid vehicle

number

ServiceException with the error message “Invalid vehicle registration number” Non-existent vehicle

number in DB

ServiceException with the error message “Could not find the vehicle for given vehicle number”

Valid vehicle number, In following format, [a-zA-Z]{1..2} or [0-9]{1..3} - [0-9]{1..4} , E.g.: GF-5053 E-6029 1-3456 18-1234 301-4567

Matching Vehicle with vehicle owner and revenue licence information

2 Number of Revenue Licence Records

Number of revenue licence required for the matching value in parameter 1.

0 ServiceException with

the error message “Invalid revenue licence record number, at least revenue licence number = 1”

(34)

1 Matching Vehicle with latest revenue licence n, where n < nDB, nDB

is number of revenue licence for matching vehicle registration in the database

Matching Vehicle with n number of latest

revenue licence records

n, where n = nDB Matching Vehicle with n number of latest revenue licence records n, where n > nDB Matching

VehicleLookupInfo with n number of latest revenue licence records

n < 0 Matching Vehicle with

all the matching

revenue licence records

Table 7.1 - Input Parameters and Output Results for Lookup Service

7.1.2 Output Results

(35)

Class Field Name Description Type Nullable Vehicle vehicleRegistrationN umber Vehicle Registration Number STRING no

firstRegDate First registration date of the

vehicle DATE no

province Province vehicle belong STRING no

fuelType Fuel Type of the Vehicle STRING no

class Vehicle Class STRING no

vehicleOwner Name of the vehicle owner VEHICLEOWNER no

vehicleStatus Vehicle Status STRING no

revenueLicenceReco rd

The revenue licence record which matches the vehicle

ARRAY OF

REVENUELICENCE Yes

VehicleOwner name Vehicle owners full name STRING No

RevenueLicenc e

licenceNo Licence Number STRING no

expiryDate Expiry Date of the licence DATE no

year Year of the licence taken INT no

issuedDate Issue date of the Licence DATE no

authority Authority where the licence

is taken STRING no

fee Licence fee DOUBLE no

fine Fine for the licence DOUBLE yes

arrears Arrears for the licence DOUBLE yes

type type of the licence STRING no

vetNumber Vehicle Emission Test

number STRING no

fitnessCertificateNum

ber Fitness Certificate Number STRING yes

routePermitNo Route Permit Number STRING yes

(36)

(37)

7.2 Design for Lookup Portlet

Revenue Licence Lookup Portlet will be implemented as a client, which consumes the Revenue Licence Lookup eService. This portlet will be used by non-Western Province DS staff or any other authorised personnel to access the revenue licence information.

Figure 7.3 - High Level Design of Revenue Licence Lookup Portlet

The user credentials will be passed to the Revenue Licence Lookup web service through the user name token. The user name and password captured at the login will be passed through a user name token. The credentials are then mapped against the users who have the role of “lookup user”.

(38)

Figure 7.4 - Activity Diagram for Lookup Portlet

A successful lookup will retrieve the information described in Section 7.1.2. However, the information displayed to the e-RL lookup portlet users will be limited to the following:

 Revenue Licence Status  Name of Owner

 First Registration Date  Province

 Fuel Type  Vehicle Class

(39)

7.3 Design for SMS Lookup

The revenue licence lookup web service is accessible through mobile phones via SMS.

Figure 7.5 - High Level Design of SMS Lookup

The above diagram describes the high-level design of the SMS lookup. For testing purposes a mobile simulator created with Java Swing will be used as the mobile phone.

However, this module is designed to extend its functionality to work with a GSM modem in the future, if required. To facilitate this, there are two directories defined.

1) SMS In Directory - This directory is used to receive SMS messages as files. In a simulated environment a property file will be used to represent a SMS file. When this is used with a GSM modem, this directory can be specified as the directory to place all the SMS messages received by the GSM modem.

2) SMS Out Directory - This directory is used to send SMS messages as files. In a simulated environment a property file will be used to represent a SMS file. When this is used with a GSM modem, this directory can be specified as the directory to place all the SMS messages to be sent through the GSM modem.

(40)

The following steps describe how make a revenue licence lookup request and how to receive its response.

1) The sender will type following message in an SMS message and sends that to a predefined number of SMS Gateway (Simulator).

ERL VEH <Vehicle Registration Number> E.g.:- ERL VEH GP-4647

2) In simulated scenario, the mobile simulator will create an SMS file and put that in SMS_In_Directory. In actual scenario, the GSM modem will receive and actual message from a mobile phone and that message will be copied to SMS_In_Directory. (In the scope of this project only simulation will be implemented).

3) The SMS Gateway will detect the message reception and convert the SMS file to a web service call.

4) The SMS call will transmit to the Revenue Licence Lookup eService through LIX. LIX will enforce the required security policies. In this scenario encryption, signing and user token is required. The mobile phone number of the sender will be used for the user token.

5) If the SMS gateway failed to connect to Licence Lookup eService, it will return the following message.

“Service not available”

6) If the SMS gateway successfully connected to Licence Lookup eService, the Revenue Licence Lookup eService will authenticate the lookup request using the mobile number of sender. If the mobile number is not an authorised number following message will be sent to the sender.

“You are not authorised to use this service”

7) If the mobile number is an authorised number, the Revenue Licence Lookup eService will search for the revenue licence details using the lookup procedure describe in Section 7.1

8) If the vehicle number is not found, the Revenue Licence Lookup eService will return following message.

“Vehicle not found in the system”

9) If the vehicle number is found, the Revenue Licence Lookup eService will return revenue license details of that vehicle as follows.

E.g.:- GP-4647, Kesbewa:1234567, from 02/10/2009 to 01/10/2009, Amal Tharanga Perera, Piliyandala

(41)

10) Any message returned by the Revenue Licence Lookup eService will be sent to SMS Gateway through LIX.

11) The SMS gateway will convert that response to a SMS file and put that file in SMS_Out_Directory.

12) In simulated environment the Mobile Simulator will detect the reception of SMS file from SMS_Out_Directory and display it to the sender. In actual environment the GSM modem will detect the reception of SMS file from SMS_Out_Directory and send that to the sender‟s mobile phone number. (In the scope of project only simulation will be implemented).

(42)

8 Design for User Management Module

This section describes the detailed design for the user management module module/sub-system. User management will be handled centrally from the PDMT for the DSs belonging to the particular province.

The following user roles will be provided by the system:

User Role Description

Operator Counter staff who issue licences will have this user role

PDMT Supervisor Superusers at the PDMT who perform tasks which require special approval to proceed with licence issuance

DS Supervisor Superusers at the DS offices who perform tasks which require special approval to proceed with licence issuance

PDMT Administrator Superusers at the PDMT who perform the administrative tasks of the system

DS Administrator Superusers at the DS offices who perform the administrative tasks of the system

Commissioner The highest level of authority among all the user roles

Lookup user User accounts to lookup vehicle revenue licence details via the e-RL lookup portlet of the country portal

Mobile user User accounts to lookup vehicle revenue licence details via SMS

Table 8.1 - User Roles in the e-RL Application

User management actions performed at the central database will be synchronised with the relevant DS databases on-demand (i.e. updates are pulled by the e-RL application at the DS). This module will be responsible for the creation, deletion and modification of user accounts of the e-RL application and the lookup through the portlet and via SMS.

(43)

Figure 8.1 - Collaboration Diagram for User Management Module

The database tables related to the User Management Module are listed below:  User

 Role  Authority  Province

8.1 Design for Add New User Feature

This section describes the detailed design for the Add New User feature of the User Management Module including the user interface design.

This feature can only be accessed by administrators of the e-RL application.

8.1.2 Navigation Map

(44)

Page Summary

Name Add New User

Description The user creates a new user account in the central database by providing the user‟s name, authority, role, login name and password.

Figure 8.3 - Add New User Screen

Element Type Description

Name Text box Full name of the new user

User Role Drop-down list The level of access privileges given to the new user Authority Drop-down list The DS to which the user belongs

User Name Text box The login name of the user

Password Text box

Initial password for the new user. This should adhere to the complex password policy defined below:

 Minimum password length should be 8 characters  Password should contain at least one capital letter  Password should contain at least one number Re-enter

(45)

Change password

on first login Check-box

Gives the option to enforce password change on the first login of the new user

Create Button Creates the new user with the details that have been entered

Cancel Button Cancels the creation of a new user

No user name entered

Displays the message “Please enter the name of the user”.

Prompts the user to enter the name of the new user.

Login name not specified

Displays the message “Please enter the user login name”.

Prompts the user to enter the login name of the new user.

Password not entered Displays the message “Please _{enter a password”.} Prompts the user to enter the login password for the new user.

Password mismatch

Displays the message “Passwords do not match. Please re-enter the password”.

Prompts the user to re-enter the password.

User name exists in the system

Displays the message “User name exists in the system. Please re-enter another user name”.

Prompts the user to enter a new user name.

(46)

8.1.4 Object Model/Data Flow Design

(47)

8.2 Design for Delete User Feature

This section describes the detailed design for the Delete User feature of the User Management Module including the user interface design.

Figure 8.5 - Navigation Map for Delete User Feature

Page Summary

Name Delete User

Description The user deletes an existing user within the province in the central database by clicking on the delete icon corresponding to the particular user

(48)

Figure 8.6 - Delete User Screen

Delete icon Button Deletes the user account from the system

Ok Button Confirms the deletion of user

Cancel Button Cancels the user deletion

Deleting User of higher privilege level

Displays the message “You are not allowed to delete users of

(49)

Figure 8.7 - Sequence Diagram for Deleting a User

8.3 Design for Edit User Details Feature

This section describes the detailed design for the Edit User feature of the User Management Module including the user interface design.

Figure 8.8 - Navigation Map for Edit User Feature

(50)

Page Summary

Name Edit User Account

Description

The user edits the details of an existing user within the province in the central database by clicking on the edit icon corresponding to the particular user

Figure 8.9 - Edit User Screen

User Role Drop down list The level of access privileges given to the new user Authority Drop down list The DS to which the user belongs

User Name Text box The login name of the user. This is disabled by default but _{can be made editable by clicking on the “Reset” button}

Password Text box

Initial password for the new user. This is disabled by default but can be made editable by clicking on the “Reset” button

Reset Button Enables the user name and password text boxes Change

password on first login

Check box Gives the option to enforce password change on the first login of the new user

Save Button Save the modification done to the particular user account Cancel Button Cancels the creation of a new user

(51)

User name is empty Displays the message “Please _{enter the name of the user”.} Prompts the user to enter the name of the user.

Login name is empty Displays the message “Please _{enter the user login name”.} Prompts the user to enter the login name of the new user.

Password is empty Displays the message “Please _{enter a password”.} Prompts the user to enter the login password for the new user.

(52)

8.4 Design for Search Users Feature

This section describes the detailed design for the Search User feature of the User Management Module including the user interface design. Users can be searched by specifying the following criteria:

Input Type Optional Default

Login Name Text box Yes Null

Name Text box Yes Null

User Role Drop down list No All

Authority Drop down list No Colombo

Figure 8.11 - Navigation Ma for User Search Feature

Page Summary

Name Search Users

Description The user can specify the user name, login name, authority and user role

to search the users of the system

(53)

Figure 8.12 - Search User Screen

Login Name Text box The login name of the user.

User Role Drop down list The level of access privileges given to the new user Authority Drop down list The DS to which the user belongs

Search Button Search the database based on either the user name or login name, and role and authority specified

(54)

(55)

9 Design for Online Revenue Licence Renewal Portlet

This section describes the detailed design for the Revenue Licence Renewal via Country Portal e-Citizen module.

(56)

9.1 Web Services Definition for Insurance eService

The table below provides details of the Insurance eService, which is used for the online verification of Insurance Certificates.

Operation Name checkInsuranceInfo

Description Returns insurance information (insurance status, insurance expiry

date, last insurance type and current insurance type) for a given vehicle registration number and a given insurance company.

Sample Java Representation

public InsuranceInfo checkInsuranceInfo(String vehicleRegNo, String insuranceCompany)

Input Parameter(s)

Input Parameter Name Data Type Description

vehicleRegNo string Vehicle Registration Number

insuranceCompany string Insurance company name Return Type

Property Name Data Type Description

insuranceStatus boolean The status of insurance.

If insurance information is available for given vehicle insuranceStatus = true

else

insuranceStatus = false

insuranceExpiryDate datatime The insurance company which issued the latest

insurance

lastInsuranceType string Last insurance type.

Possible values

 TEMPORARY (for cover notes)

 PERMANENT (for fully paid insurance certificates)

CurrentInsuranceType string Current insurance type. _{Possible values}

 TEMPORARY (for cover notes)

 PERMANENT (for fully paid insurance certificates) If the lastInsuranceType AND

CurrentInsuranceType is TEMPORARY then

vehicle is not eligible and proceed through the escalation path.

(57)

9.2 Web Services Definition for VET eService

The table below provides details of the VET eService, which is used for the online verification of VET Certificates.

Operation Name checkVehicleEmissionTestInfo

Description Returns vehicle emission test information (last vehicle emission test

number and last vehicle emission test date) for a given vehicle registration number and a given Vehicle Emission Test (VET) company

public VehicleEmisionTestInfo

checkVehicleEmissionTestInfo(String vehicleRegNo, String vetCompany)

Input Parameter Name

Data Type Description

vehicleRegNo string Vehicle Registration Number

vetCompany string Vehicle emission test company name Return Type

Property Name Data Type Description vehicleEmissionTe

stStatus

boolean The status of vehicle emission test.

If vehicle emission test information is available for given vehicle vehicleEmissionTestStatus = true else vehicleEmissionTestStatus = false lastVehicleEmissi onTestNo

string The vehicle emission test number of last passed _{vehicle emission test} lastVehicleEmissi

onTestDate datatime The vehicle emission test date of last passed vehicle emission test

(58)

10 Database Design

The diagram below depicts the physical database design of the canonical database.

Figure 10.1 - Physical Database Design

The Canonical Database Design may change during successive stages of the project. Please refer to the e-Revenue Licence Canonical Database Design Document (ICTA_eRL_Canonical_Database_Design_V1.0.doc) for the updated version and for further details on the database design.

(59)

10.1 Entity Relationship Diagram

The diagram below provides a graphical representation of the database entities and the relationships among entities.

(60)

10.2 Data Archival

The data collected in the central canonical database must be archived periodically. Data archival will help achieve the following:

 Ensure that the performance of e-RL system does not degrade with the evolution of the database

 Prevent wastage of hardware resources required to accommodate databases with large volume of historic data of little or no importance  Adhere to the data retention policy of the relevant authorities

Archival of historic data will be carried out subject to a data retention period of 5 years as per the requirements of the eGovernment policy. This will be carried out during the maintenance phase of the project.

(61)

11 Core Technical Services Design

This section describes the high level design and usage pattern for the core technical services of the system.

11.1 Security

The potential network security threats faced by the e-RL system and suitable countermeasures:

Threat Counter Measure (Specific to Web Services)

Interception Encryption / User Authentication Modification Digital Signature / User Authentication Fabrication Digital Signature / User Authentication

Interruption The interruptions should be addressed using firewalls, antivirus software, physical security and network setup

Web Service Security Operations used in eRL Application are given in the table below:

Operation Purpose

Encryption Provides authentication and confidentiality

Signing Provides authentication, message integrity, and non repudiation Username

Token

Provides and authorisation and authentication

(62)

User level security is provided by:  User Credentials

 Hardware Identification (Mobile numbers for SMS lookup)

The level of security provided for the various services of the e-RL system are given below.

eService 1-way SSL User Token

Revenue Licence Lookup Service YES YES

Revenue Licence Renewal Service YES NO

DMT Data Import Service YES NO

Data Synchronisation Service YES NO

Reference Data Services YES NO

User Accounts Synchronisation YES NO

VET Validation Service (Client to LIX only *) YES NO

Insurance Validation Service (Clint to LIX only *) YES NO

* - The user level security enforced by the service will be adhered to by the client. Therefore the security of clients which consume external services will be limited to the level of security defined by the relevant service

eService Authentication Successful (Proceed) Authentic ation Handler AxisFault (User Auth

failed)

Request with Username Token

(63)

12 Deployment Prerequisites

The following prerequisites are required for the successful deployment and operation of the e-RL application.

12.1 Hardware Specifications

Counter Machine DS/WPDMT Accountant

Processor Processing speed >800 MHz Processing speed >800 MHz

Physical Memory 512MB RAM 512MB RAM

Secondary Storage 8 GB HDD 8 GB HDD

Mouse Standard Mouse Standard Mouse

Keyboard 101-key US traditional keyboard 101-key US traditional keyboard Display Resolution Monitor with 1024 x 768 pixels Monitor with 1024 x 768 pixels

Optical Drive Not required Not required

Printer Epson LQ-300+ II Epson LQ-300+ II

UPS Not required Not required

DS Counter Machine

functioning as Server Central Server Machine

Processor Dual Core 2 GHz Quad processor

Physical Memory 2GB RAM 64 GB RAM

Secondary Storage 80 GB HDD 500 GB HDD

Mouse Standard Mouse Optical Mouse

Keyboard 101-key US traditional keyboard 101-key US traditional keyboard Display Resolution Monitor with 1024 x 768 pixels Monitor with 1024 x 768 pixels

Optical Drive DVD Writer DVD Writer

Printer Epson LQ-300+ II Not required

(64)

12.2 Network Specifications

Specification

Network Connectivity within the DS / PDMT 100 Mbps LAN with a 100 Mbps Switch with _{sufficient ports}

(65)

Appendix 1 – Vehicle Registration Information eServices

1. Receiving Vehicle Registration Information of a List of Vehicles

Operation Name

getVehicleRegInfoList

Description Returns a list of vehicle registration details from a given date (from Department of Motor Traffic)

public VehicleRegInfo[] getVehicleRegInfoList(Calendar from)

Input Parameter Name

Data Type Description

from dateTime When retrieving vehicle information from DMT database, getVehicleRegInfoList operation will extract vehicle information inserted or updated after the date time specified by this input parameter

Return Type

Return type of getVehicleRegInfoList operation is an array of VehicleRegInfo. The

complex type VehicleRegInfo contains following properties. Property Name Data Type Description

chassisNo string Chassis number of the vehicle

engineNo string Engine number of the vehicle

firstRegDate date First registration date of vehicle

isBrandNewAtRegistration boolean If the vehicle is brand new at registration

isBrandNewAtRegistration = true

else

isBrandNewAtRegistration = false fuelType string Fuel type consumed by the vehicle

(66)

numberOfSeats int Number of seats in vehicle

preferredLanguage string Citizen‟s preferred language. Possible values:

SI: Sinhala TA: Tamil

EN or null: English

ownerAddr1 string[] First part of the owner address in both

English and citizen‟s preferred language. Array element 0: in English

Array element 1: in citizen‟s preferred language (Sinhala or Tamil)

ownerAddr2 string[] Second part of the owner address in both

city string[] City part of the owner address in both

ownerName string[] Owner name in both English and citizen‟s

preferred language. Array element 0: in English

province string The province of the vehicle owner

tareWeight double Tare weight of the vehicle

vehicleClass string Vehicle class of the vehicle