# Technical Specification Document for OMNI Eportal
## Table of Contents
1. **Introduction**
1.1 Purpose
1.2 Scope
2. **System Overview**
2.1 System Architecture
2.2 Technologies Used
2.3 Hosting and Deployment
2.4 High-Level Architecture
3. **Functional Requirements**
3.1 User Authentication
3.2 Admin Features
3.3 Customer Features
3.4 Miscellaneous Features
4. **Non-Functional Requirements**
4.1 Performance
4.2 Security
4.3 Usability
5. **Database Design**
5.1 Database Schema
6. **APIs**
6.1 External APIs
8. **Maintenance and Support**
8.1 Bug Tracking
8.2 Maintenance Schedule
---
## 1. Introduction
### 1.1 Purpose
This document serves as a comprehensive guide outlining the technical aspects of the OMNI Eportal.
### 1.2 Scope
The scope of this document includes the architecture, technologies, and functionalities of the web application.
## 2. System Overview
### 2.1 System Architecture
The web application follows a client-server architecture with components such as front-end, back-end, and database.
### 2.2 Technologies Used
#### 2.2.1 Front-end
- **Library:** [React JS - Version 17]
- **Languages:** [e.g., HTML, CSS, JavaScript]
- **Dependency Libraries:** [React Router, Redux and Redux Saga (for application State management), Axios, Formik(for managing forms), Yup (for form validations)]
- **API Calls**: Communicates with the backend via RESTful APIs.
:::warning
#### Steps to Run Frontend.
:bulb: **Prerequisite** - Node 16.17.0 or above.
1. **Download the Repository:** This step involves cloning or downloading the project repository from the version control system (e.g., Git). You need to replace `<repository-url>` with the actual URL of your repository.
2. **Go into the Repository:** Navigate into the repository folder using the `cd` command. Replace `<repository-folder>` with the actual name of the folder created during the cloning process.
3. **Install Dependencies:** Use npm to install the project dependencies. The `npm install` command reads the `package.json` file and installs all the required packages.
4. **Start the Application:** Once the dependencies are installed, the `npm start` command starts the development server and launches the application in your web browser. You can view the application by going to `http://localhost:3000` or another specified port.
:::
#### 2.2.2 Back-end
- **Framework:** [Ruby on Rails - version 6]
- **Languages:** [Ruby]
- **Database:** [PostgreSQL - version 14]
- **API Layer**: Handles incoming requests from the frontend.
- **Business Logic Layer**: Processes the business logic within the APIs.
- **SAP Integration Layer**: Manages communication with SAP systems using protocols in this scenario OData.
:::warning
#### Steps to Run Backend.
:bulb: **Prerequisite** - Linux OS(Ubuntu), Ruby version 2.7, Rails version 6, postgres version 14, Redis.
1. **Download the Repository:** This step involves cloning or downloading the project repository from the version control system (e.g., Git). You need to replace `<repository-url>` with the actual URL of your repository.
2. **Go into the Repository:** Navigate into the repository folder using the `cd` command. Replace `<repository-folder>` with the actual name of the folder created during the cloning process.
3. **Install Dependencies:** Use npm to install the project dependencies. The `bundle install` command reads the `Gemfile` file and installs all the required packages.
```
Ensure environment variables are set properly which are present in
config/application.yml
environments/staging.rb
```
```
Create Database
-----------------
createdb -h localhost -U ubuntu omni_test
Initiate Database
------------------
RAILS_ENV=staging bundle exec rake db:create db:schema:load
RAILS_ENV=staging bundle exec rake db:migrate
```
4. **Start the Application:** Once the dependencies are installed and DB is up, the `rails s -e staging` command starts the development server and launches the application. You can access the API's by going to `http://localhost:3000/api/v1` or another specified port.
5. **Start Workers using Sidekiq:** Make a service file for Sidekiq as below in /lib/systemd/system as sidekiq.service
```
[Unit]
Description=sidekiq
After=syslog.target network.target
[Service]
Type=simple
# If your Sidekiq process locks up, systemd's watchdog will restart it within seconds.
WatchdogSec=10
WorkingDirectory=/home/ubuntu/omni-1.4
# If you use rbenv:
ExecStart=/bin/bash -lc 'exec /home/ubuntu/.rbenv/shims/bundle exec sidekiq -e staging -C /home/ubuntu/omni-1.4/config/sidekiq.yml -r /home/ubuntu/omni-1.4'
# If you use the system's ruby:
# ExecStart=/usr/local/bin/bundle exec sidekiq -e production
# If you use rvm in production without gemset and your ruby version is 2.6.5
# ExecStart=/home/deploy/.rvm/gems/ruby-2.6.5/wrappers/bundle exec sidekiq -e production
# If you use rvm in production wit gemset and your ruby version is 2.6.5
# ExecStart=/home/deploy/.rvm/gems/ruby-2.6.5@gemset-name/wrappers/bundle exec sidekiq -e production
# Use `systemctl kill -s TSTP sidekiq` to quiet the Sidekiq process
ExecReload=/usr/bin/kill -TSTP $MAINPID
# !!! Change this to your deploy user account !!!
User=ubuntu
Group=ubuntu
UMask=0002
# Greatly reduce Ruby memory fragmentation and heap usage
# https://www.mikeperham.com/2018/04/25/taming-rails-memory-bloat/
Environment=MALLOC_ARENA_MAX=2
# if we crash, restart
RestartSec=1
Restart=on-failure
# output goes to /var/log/syslog (Ubuntu) or /var/log/messages (CentOS)
StandardOutput=syslog
StandardError=syslog
# This will default to "bundler" if we don't specify it
SyslogIdentifier=sidekiq
[Install]
WantedBy=multi-user.target
```
Enable and start the service once backend server is up and running.
```
sudo systemctl enable sidekiq.service
sudo systemctl start sidekiq.service
```
:::
### 2.3 Hosting and Deployment
- **Hosting Provider:** [AWS]
- **Deployment Process:** [Manual]
- For Frontend - https://hackmd.io/@sivapurpleplum/HJ0THp-U3
### 2.4 High Level Architechture.
```
Frontend Backend SAP
| | |
1. User Action | |
| ------------> | |
| HTTP Request | |
| | |
2. API Gateway | |
| ------------> | |
| | |
3. Authentication | |
| ------------> | |
| | |
4. Business Logic | |
| ------------> | |
| | |
5. CRUD Operation | |
| ------------> | |
| | |
6. SAP Sync | --------->|
| | |
| | OData |
| | |
| | |
7. SAP Response | <---------|
| | |
8. Process Response|
| <------------ | |
| | |
9. HTTP Response |
| <------------ | |
| | |
10. UI Update |
| | |
```
## 3. Functional Requirements
### 3.1 User Authentication
- **Feature:** User registration and login
- **Security:** Password encryption, secure token generation
### 3.2 Admin Features
#### 3.2.1 User Login
- **Feature:** User login
- **Description:** Users can securely log in to the Eportal by entering their email and password.
- **Security:** Passwords are encrypted to ensure user data protection.
#### 3.2.2 Sync Users
- **Feature:** Sync Users
- **Description:** Admins can synchronize the Eportal Database with updated user data from SAP, ensuring data consistency.
#### 3.2.3 Enable / Deactivate User
- **Feature:** Enable / Deactivate User
- **Description:** Admins have the authority to enable or deactivate a user account, controlling access to the Eportal.
#### 3.2.4 Admin Management
- **Feature:** Create / Edit / Deactivate / Delete Admins
- **Description:** Admins can perform various actions on other admin accounts, such as creating, editing, deactivating, or deleting. Super admins, in particular, have full control over admin management.
#### 3.2.5 Product Management
- **Feature:** Manage Products
- **Description:** Admins have the capability to upload or delete images associated with products on the Eportal.
#### 3.2.6 Marketing Material Management
- **Feature:** Manage Marketing Materials
- **Description:** Admins can upload or delete images related to marketing materials, providing control over the visual content available on the Eportal.
#### 3.2.7 Sales Order Viewing
- **Feature:** Sales Order
- **Description:** Admins have the ability to view sales orders placed by all active customers on the Eportal. This feature allows admins to monitor and manage the sales activities efficiently.
### 3.3 Customer Features
#### 3.3.1 Customer Login
- **Feature:** Customer login
- **Description:** Customers can securely log in to the Eportal by entering their email and password.
- **Security:** Passwords are encrypted to ensure user data protection.
#### 3.3.2 Dashboard Viewing
- **Feature:** Dashboard
- **Description:** Customers can view Order Activity, Shipment Activity, Pending Actions, and Pending Payments on the dashboard.
#### 3.3.3 New Order
- **Feature:** New Order
- **Description:** Customers can add products to the cart from the list, update the cart, and place a new order.
#### 3.3.4 Order Management
- **Feature:** Order History / Shipment Status / Payments
- **Description:** Customers can view their order history, shipment details, and payment details.
#### 3.3.5 Claims Management
- **Feature:** Claims
- **Description:** Customers can create claims and check the status of their claims.
#### 3.3.6 Profile Management
- **Feature:** Profile
- **Description:** Customers can view personal details and addresses on their profile.
### 3.4 Miscellaneous Features
- Every Day Mid-Night 12 AM Jobs are scheduled to sync customers , products and update prices for customer related products
- Every time when customer logs in a job will be triggred to update material prices of his products.
- File formats allowed for Marketing Materials are - jpg, jpeg, gif, png, pdf, zip
- File formats allowed for Upload pictures of a product are - jpg, jpeg, gif, png
## 4. Non-Functional Requirements
### 4.1 Performance
- **Response Time:** Except for file uploads, all APIs have an average response time of less than 10 seconds, with the quickest response being 1 second. Response times may vary based on the filters applied.
- **Scalability:** As we are using AWS single instance, **Auto-Scaling** would be the preferred method to scale in terms of computation and storage based on the traffic we receive.
### 4.2 Security
- HTTPS protocols are enabled for both frontend and backend url's
- React uses JSX, which inherently escapes dynamic values by default. When you render data in JSX, React escapes it to prevent XSS attacks.
- No Vulnerable and Outdated Components used within the application
- In a traditional client-server architecture, where the client (browser or application) interacts with a server, SSRF is not directly applicable to the client side.
## 5. Database Design
### 5.1 Database Schema
## 6. APIs
### 6.1 External APIs
- https://omns4hdp01.omni-united.com:44300/sap/opu/odata/SAP/ZOMNI_EPORTAL_SRV/
## 8. Maintenance and Support
### 8.1 Bug Tracking
- Reporting and tracking of bugs are done manully.
- Logs are stored in a file in the location /home/ubuntu/omni-1.4/log folder
- For Backend we have Airbrake notification service for Errors and Logs which will help in debugging issues.
### 8.2 Maintenance Schedule
- While jobs are running, the data will not be updated immediately, and this delay might take 10-15 minutes. The duration could increase further if the number of customers and products increases.
- Orders placed during the update process may not reflect the updated values.
Sign in with Wallet
Connect another wallet