-Table of Content
-WebDoorCreator is the web incarnation and evolution of Egalware's DoorCreator© software.
-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).
- -Here a general introduction to terminology used for each component of the project, both for component and items to better understand subsequents details.
-| Term | -Description | -
|---|---|
| (A) Public WebServer | -Reverse proxy, manages web access from final user decoupling access to local infrastructure | -
| (B.1) Internal WebDoor Server | -Actual main web server application (C# / .Net) | -
| (B.2) Redis Server | -High speed cache & messaging server for inter-application comunication | -
| (B.3) Main DB | -Main Database for data storage, Microsoft SqlServer | -
| (B.4) EgwDoor Processor | -EgtCam5 based application for processing actual CAD/CAM/3D specific tasks | -
| (C) EgwProd (Multiax Machine) | -Main Workstation for specific door-data processing | -
| WF_OrderMan | -WorkFlow for actual order managemend: to be better defined | -
| ERP | -WorkFlow needs to be defined | -
| EgwProd | -Local APplication onc Multiax Machine for production execution | -
| ProdCode | -Generic unique code (with barcode/QRCode/DataMatrix) to be used from remote Machine to scan and execute automatic production | -
| DDF | -Door Definition Format, the base data-format to describe Doors (measures, attributes, hardware, ...) in order to generate CAD/CAM/3D/ISO program and each format requested for the solution | -
| Project | -Each Customer will be able to create project, consisting of 1+ doors defined in each project; each project will be managed as a whole (from approval to production/billing phase) | -
This schema is the general representation of the solution, better defined in subsequenct chapters.
-
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.
-This way there will be secured access to internal IT infrastructure decoupled from external internet.
- -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:
-We expect to deliver more than 1 instance of this server, bot for redundancy and scalability (to give final user best performances we expect to have many instance, each managing many final-user session)
-Final note: while the load balancer can fit also a mixed setup (IIS, Linux, docker), this is normally less user-friendly and slow in updating.
-Each single instance will run as follow:
-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.
-It is a RAM based server and must be kept secure in the "green zone" of the customer IT datacenter.
-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.
- -This component, based on EgtCAM5 Kernel and libraries, is the main core of CAD/CAM/3D task execution.
-This will be linked (with bot REST webservices + REDIS channels/cache) to the (B.1) WebDoor Server.
-In particulare the WebDoor will send DDF online-generated file (derived from user -input via web-interface) to the EgwDoor Processor. This processor will generate in (near) realtime various output format upon request (base geomtry, 3D web based artifacts, simulated ISO path for CAM calculation, ...).
-The produced 3D (javascript based) web artifacts will be presented to the user in order to evaluate the finale expected product during web-based door definition wizard.
- -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).
-The software, after recognizing the unique code for each signle door, will be able to call (B.1) WebDoor Server to receive DDF file corresponding to each unique door. A backup solution (eg taking into account the case of network connectivity problems/disconnection) can be put in place in the form of distribuited/replicated "approved DDF file storage" in order to replicate on each production facility the set of near term part production (to be defined in detail, for example next 2-7 days of scheduled production).
- -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
-| Component | -Virt | -Num | -Critical resource | -Hw requirements | -
|---|---|---|---|---|
| (A) Public WebServer | -Y | -1+ | -Bandwith, Latency | -Linux Nginx, 2vCPU/2GB RAM each, 1GBit Fiber + static IP | -
| (B.1) Internal WebDoor Server | -Y | -1+ | -Processing (RAM/CPU) | -4+ vCore / 4GB RAM, Windows/Linux/Docker (to be tested) | -
| (B.2) Redis Server | -Y | -1 | -RAM | -Linux redis server, 4 vCpu, 4GB Ram | -
| (B.3) Main DB | -Y | -1 | -Storage | -Windows server + MsSqlServer, high speed storage (SSD min, better NVME), 4 vCPU (min), 8GB RAM (min) | -
| (B.4) EgwDoor Processor | -N | -1 | -Processing (CPU/GPU/RAM) | -Min 16Gb RAM, min 8 CPU core, high speed storage (SSD/NVME) + 8Gb videocard (min NVidia 3060 class expected) | -
special notes:
-Here the brief description of use case and expected system behaviour.
-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.
-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.
-The role levels will be (at minimun) the following:
-| Role | -Level | -Parameter | -Description | -
|---|---|---|---|
| User | -0 | -- | -Standar user, only access on platform | -
| Customer | -1 | -Customer Code | -Group used to represent a final customer, representing the company = Door destination | -
| CustomerUser | -2 | -Customer Code + UserId | -User associated with a Customer, can see/manage all customer orders | -
| CustomerAdmin | -2 | -Customer Code + UserId | -SPECIAL User with highest privileges for Customer, can add users to group and approve orders | -
| AbhOrderManager | -3 | -UserId | -SPECIAL User, from ABH, that is responsible for final customer's order acceptance | -
| AbhAdmin | -4 | -UserId | -SPECIAL User, from ABH, that is responsible for ABH user management | -
| SuperAdmin | -5 | -UserId | -General platform superuser for maintenance/setup task | -
As already stated
---Each Customer will be able to create project, consisting of 1+ doors defined in each project; each project will be managed as a whole (from approval to production/billing phase)
-
So the object hearchy will be
-Order ACB.02
-Order DEF.01
-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).
-Each Customer User will be able to create a project or use an already available one in a "pre purchase" state.
-When the order is completed, customer will sent to ABH for Estimation confirmation (because automatic costing can be done but final check for cost and expected delivery time is required to be user-driven).
-After Estimation stage, purchase must be carried on from customer (with standard and already in-place company workflow of order management).
-Resource allocation will be reported to ERP (materials + machine time, to be defined)
-Finally resource planning and final extimation for delivery will be sent back to customers.
-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.
-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.
-The process of defining the final expected door will be carried out with web-based interface.
-In particular a wizard multi-step process, similar to the actual process implemented on "single-user" DoorCreator software.
-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, ...)
-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...)
- -| Date | -Edit | -Version | -Note | -
|---|---|---|---|
| 2022.11.09 | -S.E. Locatelli | -0.2 | -Draft completion | -
| 2022.11.03 | -S.E. Locatelli | -0.1 | -Initial draft | -