Project

General

Profile

Open Data Connector Documentation » History » Sprint/Milestone 3

Steven (eSHIFT) Uggowitzer, 21 July 2022 10:24 AM

1 1 Steven (eSHIFT) Uggowitzer
h1. Open Data Connector Documentation
2
3
{{>toc}}
4
5
h2. Overview
6
7
The purpose of the system is to enable users to transmit any updates that occur in a database to a configured endpoint. The system can be used to manually transmit records or set to run in the background and ‘auto sync’ – scanning the database at given intervals and transmitting any updates when detected. The system is able to read different types of data file; WHONET, SQLite, Access, xlsx (Excel) and CSV.
8
9
10
11
h2. Interface
12
13
h3. Login PageLink to Login Page
14
15
h3. Interface DashboardLink to Interface Dashboard
16
17
The main dashboard is structured into
18
• Main Menu
19
• Action Bar
20
• Body
21
22
h3. Main Menu
23
24
The main menu gives access to the 7 options. These are as follows:
25
26
* Home
27
* Connectors
28
* Databases
29
* Services
30
* Users
31
* Settings
32
* Notification (Icon)
33
34
Clicking on the different items in the navigator will take you to the specific page.
35
36
h2. Features
37
38
h3. Connectors
39
40
A connector is simply a link between a database and a service. It must be given a reference, so that it can be easily found in the system. It also requires a database object, which must be created in the system before trying to create a connector. A service object is also required and must be configured before creating the connector. A connector has a Boolean field for autosync. All fields in the connector are required and editable.
41
42
The connector has its own dashboard, which is similar to the home dashboard screen, showing a summary of the connector’s stats, as well as the reference of the configured database and service.
43
44
h3. Databases
45
46
A database object in the system is where a user can upload the file representing the database, and assign it
47
a unique reference in the app. The database type must also be selected. 5 different types of database file are supported; WHONET, SQLite, Access, xlsx (Excel) and CSV. For the selected database type, the file type must match, otherwise the database object cannot be saved.
48
49
All fields on the database are editable and required, and a database object can be deleted.
50
51
If the type is SQLite, another field is available; db.statement. This will be the SQL command executed on the database to retrieve the relevant records, in most cases it will just be in the form:
52
53
@SELECT * from ‘table_name’@
54
55
h3. Services
56
57
A service object is the configured endpoint, where records will get transmitted to. A transmission is made via HTTP request, and the method of this can be defined in the service; POST, GET, PUT, etc. The URL is the full location of the endpoint to transmit to, including scheme, host, port and path. Any headers provided will be added to the HTTP request, along with the basic auth if this is provided.
58
59
The body of the request will contain the fields and values from each record in the database. All fields in a service are editable, but only Reference, URL and Request Method are required fields.
60 2 Steven (eSHIFT) Uggowitzer
61
h3. Users
62
63
!image.png!
64
65
66
A user object has just 4 fields; Username, Password, Enabled and Language. Enabled is a Boolean flag, and if it’s set to true the username and password pair can be used to login to the system. The language field will be the language used on the app for the logged-in user and currently can only be set to English or French.
67
All fields are required and editable, and a user can be deleted. Once the password for a user is set, it will not be visible in the edit page, as seen below.
68 1 Steven (eSHIFT) Uggowitzer
69 3 Steven (eSHIFT) Uggowitzer
!image2021-5-26_10-44-56.png!
Go to top