diff --git a/Docs/General Architecture.md b/Docs/General Architecture.md
index 58fda5b..9f0692b 100644
--- a/Docs/General Architecture.md
+++ b/Docs/General Architecture.md
@@ -1,6 +1,33 @@
-# WebDoor Creator
+# 1. WebDoor Creator
-WebDoorCreator is the web incarnation and evolution of Egalware's DoorCreator © software.
+**Table of Content**
+
+- [1. WebDoor Creator](#1-webdoor-creator)
+- [2. WebDoor Creator Project](#2-webdoor-creator-project)
+ - [2.1. Terminology](#21-terminology)
+- [3. Overall Functional Schema](#3-overall-functional-schema)
+ - [3.1. (A) Public WebServer](#31-a-public-webserver)
+ - [3.2. (B.1) Internal WebDoor Server](#32-b1-internal-webdoor-server)
+ - [3.3. (B.2) Redis Server](#33-b2-redis-server)
+ - [3.4. (B.3) Main DB](#34-b3-main-db)
+ - [3.5. (B.4) EgwDoor Processor](#35-b4-egwdoor-processor)
+ - [3.6. EgwProd (Multiax Machine)](#36-egwprod-multiax-machine)
+- [4. Hw specifications](#4-hw-specifications)
+- [5. Expected Use cases](#5-expected-use-cases)
+ - [5.1. User registration / login](#51-user-registration--login)
+ - [5.2. User Role assignments](#52-user-role-assignments)
+ - [5.3. Projects and Orders](#53-projects-and-orders)
+ - [5.4. Order creation](#54-order-creation)
+ - [5.5. Base Library](#55-base-library)
+ - [5.6. Door creation](#56-door-creation)
+ - [5.7. Time/Cost calculation](#57-timecost-calculation)
+- [6. Document Revision](#6-document-revision)
+
+
+
+# 2. WebDoor Creator Project
+
+WebDoorCreator is the web incarnation and evolution of Egalware's DoorCreator© software.
In particular those are expectec use case
* multi user setup
@@ -10,18 +37,7 @@ In particular those are expectec use case
This document aims to represent detailed information about system actual internals and functional implementation and is passible of revision with the actual software production phases (requirements, general develop, alpha testing, beta testing, staging and go-live).
-
-autoauto- [WebDoor Creator](#webdoor-creator)auto - [Overall Functional Schema](#overall-functional-schema)auto - [Terminology](#terminology)auto - [(A) Public WebServer](#a-public-webserver)auto - [(B.1) Internal WebDoor Server](#b1-internal-webdoor-server)auto - [(B.2) Redis Server](#b2-redis-server)auto - [(B.3) Main DB](#b3-main-db)auto - [(B.4) EgwDoor Processor](#b4-egwdoor-processor)auto - [EgwProd (Multiax Machine)](#egwprod-multiax-machine)auto - [Hw specifications](#hw-specifications)auto - [Expected Use cases](#expected-use-cases)auto - [User registration / login](#user-registration--login)auto - [User Role assignments](#user-role-assignments)auto - [User Role assignments](#user-role-assignments-1)auto - [Order creation](#order-creation)auto - [Door creation](#door-creation)auto - [Order Workflow](#order-workflow)auto - [Time/Cost calculation](#timecost-calculation)auto - [Document Revision](#document-revision)autoauto
-
-
-
-## Overall Functional Schema
-
-This schema is the general representation of the solution, better defined in subsequenct chapters.
-
-
-
-## Terminology
+## 2.1. Terminology
Here a general introduction to terminology used for each component of the project, both for component and items to better understand subsequents details.
@@ -44,7 +60,15 @@ Here a general introduction to terminology used for each component of the projec
-## (A) Public WebServer
+
+# 3. Overall Functional Schema
+
+This schema is the general representation of the solution, better defined in subsequenct chapters.
+
+
+
+
+## 3.1. (A) Public WebServer
The public webserver will act as a reverse proxy (expected to use nginx) and load balancer for actual user access. It will decouple internal system to the external user web access optimizing static contenct caching & security. Setup of a standard single WAN Nginx linux virtual machine is included.
@@ -69,7 +93,7 @@ This way there will be secured access to internal IT infrastructure decoupled fr
-## (B.1) Internal WebDoor Server
+## 3.2. (B.1) Internal WebDoor Server
The internal WebDoor Server is a Blazor C# application, made to be hosted in one of this alternative scenario, to be discussed with ABH IT people:
* IIS managed windows websites for c# .net (standard windows scenario)
@@ -101,7 +125,7 @@ queue "EgwDoor Proc" AS B.4
-## (B.2) Redis Server
+## 3.3. (B.2) Redis Server
The REDIS server vill act as a cache / high speed data layer for example for managing multiple session with the cluster of WebDoor Instances and, at the same time, to act as a inter-process channel manager to permit data exchange between each solution component.
@@ -121,13 +145,13 @@ queue "EgwDoor Proc" AS B.4
@enduml
-## (B.3) Main DB
+## 3.4. (B.3) Main DB
The Main DB server will be, as a first choice (and if not otherwise requested by customer) a Microsoft SqlServer Express instance. Can be swapped for a MariaDB (MySQL) solution, in particular in case ofcluster DB requirements (high availability and if concurrent data access requirements exceed SqlServer capacity), but at the moment we expect MS SqlServer is the best fit.
-## (B.4) EgwDoor Processor
+## 3.5. (B.4) EgwDoor Processor
This component, based on **EgtCAM5** Kernel and libraries, is the main core of CAD/CAM/3D task execution.
@@ -140,7 +164,7 @@ The produced 3D (javascript based) web artifacts will be presented to the user i
-## EgwProd (Multiax Machine)
+## 3.6. EgwProd (Multiax Machine)
For each Multiax machine put in place, there will be a local copy of the standard EgwProd software (enabled to read barcode/qrcode/datamatrix data) and a copy of DoorCreator software (enabling realtime part program generation based on DDF final-product specification with respect on current tools and unique machine setup).
@@ -149,7 +173,7 @@ The software, after recognizing the unique code for each signle door, will be ab
-## Hw specifications
+# 4. Hw specifications
Hw requirements must be considered a work-in process based on general recomendation. Those are reserved for specific IT infrastructure for the current project and that can (and must) be setup in order to get best result
@@ -169,17 +193,17 @@ special notes:
-## Expected Use cases
+# 5. Expected Use cases
Here the brief description of use case and expected system behaviour.
-### User registration / login
+## 5.1. User registration / login
User registration process will be based on email: each user must have a unique email (eg: used for password retrieval and user 2FA confirmation) and from email / tokenized-link exchange process the process will be carried out.
Each user must be registered (self registered or initially mass imported) before being given role on the platform.
-### User Role assignments
+## 5.2. User Role assignments
The platform will be managed throught RBAC policy (Role-Based Access Control). So each user will be granted 1+ roles. Each role will permit single operation or multiple operation on the system.
@@ -196,7 +220,7 @@ The role levels will be (at minimun) the following:
| SuperAdmin| 5 | UserId | General platform superuser for maintenance/setup task |
-### Projects and Orders
+## 5.3. Projects and Orders
As already stated
@@ -224,7 +248,7 @@ Each item can be in several states, for example:
Normal workflow will be in forward direction only, returning to previous state will require escalation/approval (to be better defined).
-### Order creation
+## 5.4. Order creation
Each **Customer User** will be able to create a **project** or use an already available one in a "pre purchase" state.
@@ -238,13 +262,13 @@ Finally resource planning and final extimation for delivery will be sent back to
Production will be driven interally by ABH with support of the planned scheduling and actual machine task will be reported to the central system to record order fulfill and trigger logistics task on completion.
-### Base Library
+## 5.5. Base Library
Like for actual DoorCreator software, our automated part-program generation process requires definition of hardware in form of drawing and parameters in the form of a user-generated items library the system will consider in automatic program generation.
The process will be carried out with standard DoorCreator software instances already available to the customer.
-### Door creation
+## 5.6. Door creation
The process of defining the final expected door will be carried out with web-based interface.
@@ -260,15 +284,15 @@ The process will define at least these data:
As a final product a DDF file will be real-time generated upon each data input, sent to the EgwDoor Processor for calculation and results will be presented to the user, in both form of 3D we-based content for display and data produced (feasibility, time/cost expectation, ...)
-### Time/Cost calculation
+## 5.7. Time/Cost calculation
During standard user process the task of time/cost estimation (based on actual DDF model) will be carried out.
In particular we expect to have some data auto-calculated (ex time from CAM), while other data will be required to external system (ex: materials cost, availability date for materials or machine time, cost markup to define final user price, custom discount based on customer special agreements...)
-## Document Revision
+# 6. Document Revision
-| Date | Edit | Version | Note |
-|------------|---|:-------:|-----------------:|
-| 2022.11.09 |S.E. Locatelli| 0.2 | Draft completion |
-| 2022.11.03 |S.E. Locatelli| 0.1 | Initial draft |
+| Date | Edit | Version | Note |
+|------------|----------------|:-------:|-----------------:|
+| 2022.11.09 | S.E. Locatelli | 0.2 | Draft completion |
+| 2022.11.03 | S.E. Locatelli | 0.1 | Initial draft |
diff --git a/Docs/General Architecture.pdf b/Docs/General Architecture.pdf
index ae37256..5f326b0 100644
Binary files a/Docs/General Architecture.pdf and b/Docs/General Architecture.pdf differ