Search K
Appearance
MinuteView System Architecture Overview
1. Overview
The MinuteView ecosystem is composed of two primary components:
- MinuteView Server – the front-end web interface installed into IIS
- MinuteView Automations Engine – the back-end API and workflow execution engine
Together, these components form a distributed system designed to automate data workflows, integrate with external systems, and manage engineering data securely and efficiently.
2. MinuteView Server
MinuteView Server is the front-end interface of the MinuteView ecosystem.
Key Characteristics
- Framework: .NET Framework 4.8
- Deployment: Installed as a site in IIS on a Windows Server
- Primary Role: User interface and management layer for configuration, workflow control, and user access
- Database: SQL Server (auto-generated)
Installation Behavior
When MinuteView Server is installed, you must point the setup to a SQL Server instance.
Once initialized:
- The system automatically creates the
MinuteDatadatabase. - It provisions all required tables and default configurations.
Data Stored in MinuteData
- User accounts, roles, and permission sets
- Encrypted passwords and authentication tokens
- Group structures and access hierarchies
- Workflow definitions and metadata
- Client application registrations (for API authentication)
- Configuration data and operational history
3. MinuteView Automations Engine
The Automations Engine is a separate application that serves as the back-end API layer for all workflow processing, job execution, and inter-system integrations.
Key Characteristics
- Framework: .NET Core 8
- Hosting: Runs as a standalone web application .NET Core web service (Kestrel)
- Role: Executes automation workflows and provides API endpoints for job control
- Communication: Interacts with MinuteView Server via REST and WebSocket
4. Communication Between Server and Automations
MinuteView Server and the Automations Engine communicate through two main channels:
WebSocket Communication
Used for real-time operations, including:
- “Run Now” workflow executions
- Chat-based AI interactions inside Mesh
WebSockets provide a persistent, low-latency connection between the two services.
⚠️ Important: Both applications must use the same protocol (either
HTTPorHTTPS) for WebSockets to function correctly.
Mixed protocol environments (e.g., one on HTTP and the other on HTTPS) will break socket communication.
REST API Communication
Used for standard operations such as:
- Submitting jobs to the queue
- Managing workflows
- Fetching job results and logs
- Transmitting configuration updates
All API calls are authenticated via the Client Application registration mechanism (see Security section below).
5. Security Architecture
User Authentication and Password Protection
User accounts are created and managed through MinuteView Server, with all authentication data stored in the MinuteData database.
Each user password is:
- Hashed and salted
- Encrypted using a secure encryption algorithm
- Never stored in plain text
This ensures that even if the database were compromised, raw credentials would remain protected.
Client Application Authentication (Server ↔ Automations)
Communication between MinuteView Server and Automations Engine uses Client Application registrations as the authentication method.
Each registered client application includes:
- A Client ID
- A Client Secret
When the Automations Engine connects to MinuteView Server:
- It authenticates using the Client ID/Secret pair.
- Upon successful authentication, the Automations Engine registers a fingerprint (unique identifier) from the host machine.
- This fingerprint locks the credentials to that specific host.
🔒 This means the same Client ID/Secret cannot be reused or spoofed from any other server - ensuring a secure, host-bound trust relationship between the two systems.
SSL and Encryption
Both applications should be assigned valid SSL certificates for secure HTTPS communication.
All data exchanged between the systems is encrypted in transit.
6. Job Queue Architecture (Hangfire)
MinuteView Automations uses Hangfire, an open-source background job library, to manage task execution.
Key Details
- Database Location: Hangfire’s tables reside inside the MinuteData SQL database.
- Purpose: Handles queued, delayed, and recurring tasks.
- Scalability: Supports distributed processing across multiple servers.
Queue Structure
- Default Queue: For standard automation jobs
- Dedicated Queues: For specialized or long-running tasks (e.g., CAD exports, OCR, AI image generation)
Workloads can be distributed across microservices or task-specific servers, allowing high-performance and modular scaling.
7. Webhook and External API Triggers
The Automations Engine also supports custom webhooks and API triggers for integration with external systems.
How It Works
- An external system sends a GET or POST request to MinuteView Server.
- MinuteView Server receives and authenticates the request (if required).
- The request is routed internally to the Automations Engine.
- Automations executes the corresponding workflow.
- The result or response is sent back through MinuteView Server to the originating requester.
Supported Trigger Types
- GET Request
- POST Request
- POST with Content/File Upload
Authentication Options
These external requests can be configured as:
- Authenticated – requiring valid API credentials
- Public – open endpoints (e.g., for anonymous external submissions)
This routing ensures that all external communication is mediated through the secure front-end server, maintaining system integrity while enabling flexible integrations.
8. Distributed Execution Model
MinuteView supports multi-server distribution, allowing different nodes to process different workloads.
Example configuration:
- Primary Automations Server: Handles API requests and main workflows
- Auxiliary Task Nodes: Handle specialized or intensive jobs (e.g., CAD processing, AI generation)
Each node can connect to the shared MinuteData database and Hangfire queue, enabling load balancing and fault isolation.
9. Protocol and Deployment Requirements
| Component | Framework | Deployment Method | Purpose | Notes |
|---|---|---|---|---|
| MinuteView Server | .NET Framework 4.8 | IIS | Front-end interface | Requires SQL Server |
| Automations Engine | .NET Core 8 | Self-hosted (Kestrel or equivalent) | Workflow execution & API | Cross-platform |
| Database (MinuteData) | SQL Server | Auto-generated | Data & job storage | Shared between both apps |
🧠 Tip: “Kestrel” is the default cross-platform web server used by .NET Core applications, replacing the need for IIS.
10. Architecture Diagram (Conceptual)
11. Summary
| Communication Type | Purpose | Authentication | Protocol Requirement |
|---|---|---|---|
| WebSocket | Real-time operations (Run Now, Mesh Chat) | Client App Auth | Same protocol on both ends |
| REST API | Standard automation and status updates | Client App Auth | HTTPS recommended |
| Webhook | External integrations (API triggers) | Optional (Public or Authenticated) | Routed through Server |
| Database (MinuteData) | Shared persistence layer | Encrypted & access-controlled | SQL Server |