Reporting System

**ID:** REQ-DCN-001 **Status:** enhanced **Priority:** High **Category:** FUNCTIONAL **Feature Group:** Data Connectors **Enhancement Justification:** User requested modification to add support for 'text tab separated' files. The requirement has been enhanced to explicitly include this format in the file system connector's capabilities, improving data source compatibility and aligning with common data export formats. **Original Requirement:** The system shall provide built-in connectors for common data sources. The system shall provide a connector for relational databases (SQL Server, MySQL, PostgreSQL) via ODBC/JDBC. The system shall provide a connector for file systems to read CSV, JSON, and XML files. The system shall provide a connector for OPC UA servers. All ingested data shall be converted to a standardized JSON format. The system shall support custom-developed connectors through a plug-in architecture. The system shall be able to discover and load .NET DLLs from a designated plug-in directory at runtime. Custom connectors shall implement a defined `IConnector` interface. The `IConnector` interface shall specify a method for `ValidateConfiguration(configJson)`. The `IConnector` interface shall specify a method for `TestConnection(configJson)`. The `IConnector` interface shall specify a method for `FetchData(configJson)`. The Control Panel shall dynamically display configuration options for discovered custom connectors. Administrators shall be able to test the configuration of a data connector before saving it. The connector configuration UI in the Control Panel shall provide a 'Test Connection' button. Clicking the 'Test Connection' button shall trigger the connector's `TestConnection` method. The UI shall display a clear success or failure message with detailed error information if the connection fails. <<$Addition>> A connector configuration shall not be saved if the connection test has not been run successfully at least once. **Formalized Specification:** **3.3.1 Built-in Connectors** The system shall provide built-in connectors for the following data sources: - **Relational Databases**: Support for SQL Server, MySQL, and PostgreSQL via ODBC/JDBC drivers. - **File Systems**: Ability to read and parse data from CSV, JSON, **text tab separated**, and XML files. - **Industrial Data**: A dedicated connector for OPC UA servers. **3.3.2 Data Standardization** All data ingested from any connector shall be converted into a standardized JSON format for internal processing. **3.3.3 Custom Connector Architecture** - The system shall support a plug-in architecture for custom-developed connectors. - The system shall dynamically discover and load custom connector .NET DLLs from a designated plug-in directory at runtime. - Custom connectors must implement a defined `IConnector` interface. **3.3.4 IConnector Interface Specification** The `IConnector` interface shall expose the following methods: - `ValidateConfiguration(configJson)`: Validates the provided JSON configuration for correctness. - `TestConnection(configJson)`: Attempts to establish a connection to the data source to verify settings. - `FetchData(configJson)`: Ingests data from the source and returns it in the standardized JSON format. **3.3.5 Configuration and Testing** - The Control Panel shall dynamically render configuration UI elements based on the requirements of discovered custom connectors. - The connector configuration UI shall provide a 'Test Connection' button that invokes the `TestConnection` method. - The UI must display a clear success or failure message, including detailed error information upon failure. - **Acceptance Criterion**: A connector configuration shall not be permitted to be saved unless the 'Test Connection' has been executed successfully at least once within the current session.

<<$Change>> The system shall assume users have stable internet access for initial activation and periodic validation. The system shall assume data sources provide consistent and well-structured data. The system shall assume administrators are trained to configure connectors and templates. The system shall depend on the availability of the cloud-based licensing server for activation. The system shall depend on the availability of third-party data sources and delivery endpoints. The system shall depend on the customer's IT infrastructure (network, firewalls) being configured to allow the required connectivity.

The system's RESTful API shall be expanded to manage new report formats and provide new endpoints for on-demand report generation and delivery. **1.1 API Specification (OpenAPI 3.0):** All changes must be documented in the system's OpenAPI specification. **1.2 Configuration Endpoint Modifications:** - The data models for `POST /api/v1/reports` and `PUT /api/v1/reports/{id}` shall be updated to include a mandatory `outputFormat` field. This field must accept one of the following string values: `HTML`, `PDF`, `JSON`, `CSV`, `TXT`. - The data models for delivery configuration must be updated to include a new delivery type, `API_RESPONSE`, with associated parameters for synchronous timeout and asynchronous mode selection. **1.3 New Generation Endpoints:** - **`POST /api/v1/reports/{id}/generate`**: This endpoint shall trigger an on-demand generation and delivery of a pre-configured report. - **Behavior:** The endpoint will adhere to the synchronous or asynchronous pattern as defined in REQ-RDL-001 and the specific report's configuration. - **Synchronous Response (Success):** HTTP 200 OK with the report content in the body and the correct `Content-Type` header. - **Synchronous Response (Timeout):** HTTP 408 Request Timeout. - **Asynchronous Response (Initiated):** HTTP 202 Accepted with a JSON body containing `{"jobId": "...", "statusUrl": "..."}`. - **`GET /api/v1/jobs/{jobId}`**: Polls the status of an asynchronous job. Returns job status (e.g., `PENDING`, `RUNNING`, `COMPLETED`, `FAILED`), timestamps, and a link to the results if completed. - **`GET /api/v1/jobs/{jobId}/result`**: Retrieves the output of a completed asynchronous job. The response body contains the report content with the appropriate `Content-Type` header.

The system shall be a standalone, self-hosted Windows service designed for on-premise deployment. The system shall follow a Hybrid, Modular Monolith architecture. The system's core processing engine shall operate entirely on the customer's local network to ensure data privacy. The system shall make a minimal, secure connection to a cloud service exclusively for license validation.

The system shall employ a Hybrid, Modular Monolith pattern. The system shall be deployed as a single, self-contained Windows Service. The Windows Service shall host an embedded ASP.NET Core web server.

<<$Addition>> The system shall maintain a version history for critical configurations. <<$Addition>> The system shall allow administrators to roll back to a previous version of a configuration. <<$Addition>> The system shall automatically create a new version of a configuration item (Connector, Transformation, Report Schedule) every time it is saved. <<$Addition>> The Control Panel shall provide a UI to view the version history for a configuration item, showing who made the change and when. <<$Addition>> The UI shall allow an administrator to select a previous version and restore it as the current active version.

The Control Panel and Report Viewer shall be served over HTTP/HTTPS from the embedded web server. Communication with the cloud licensing service shall use HTTPS over TCP port 443. Email delivery shall use SMTP/SMTPS protocols. File transfer delivery shall use FTP/SFTP protocols. Cloud storage delivery shall use HTTPS protocol.

The application shall run as a self-contained Windows service. The activation key shall be validated via a secure cloud API. <<$Change>> All data processing and report generation shall occur locally. <<$Change>> Raw or intermediate data from customer sources shall never be transmitted outside the local network environment. Custom connectors shall be implemented as .NET DLLs following a defined plug-in specification. The system shall use Handlebars.js for HTML templating. The system shall use a local, embedded SQLite database for configuration and user storage.

The system shall provide an engine to manipulate intermediate JSON data using JavaScript. The Control Panel shall provide a UI for writing and managing transformation scripts. The transformation engine shall use a .NET JavaScript interpreter (Jint) to securely execute the scripts. The script shall receive the JSON data from the connector as input. The script shall return transformed JSON data as output. The system shall validate the script for syntax errors upon saving. Administrators shall be able to preview the output of a transformation script using sample data. The transformation editor UI shall include a preview panel. The user shall be able to provide sample JSON data for preview. The user shall be able to use live data from a selected connector for preview. Executing the preview shall run the script against the sample data and display the resulting JSON output in the preview panel. <<$Addition>> The preview function shall have a timeout to prevent long-running scripts from freezing the UI.

The system shall operate on Windows Server 2019/2022 or Windows 10/11 (64-bit). The system shall be deployed as a local installation via a Windows Installer (MSI) package. The system shall have minimum hardware requirements of a 2-core CPU, 4 GB RAM, and 20 GB free disk space. The system shall have recommended hardware requirements of a 4+ core CPU, 16 GB RAM, and 100 GB free disk space for large datasets. The system installer shall include the .NET 8 Runtime. The system shall require database drivers (e.g., ODBC, JDBC) to be installed on the host machine for specific database connectors. The system shall require outbound internet access on port 443 for cloud-based activation key validation. The system shall require network access from the host machine to all configured data sources and delivery destinations.

The system shall provide System Licensing & Activation (Priority: High). The system shall provide a Data Ingestion Framework (Priority: High). The system shall provide a Data Transformation Engine (Priority: High). The system shall provide Report Configuration & Scheduling (Priority: High). The system shall provide Report Generation & Delivery (Priority: High). The system shall provide System Administration via a Control Panel (Priority: High). The system shall provide User & Access Management (Priority: High). The system shall provide Report Viewing & Access (Priority: Medium). The system shall provide Job Monitoring & Management (Priority: Medium). The system shall provide a Secure External API (Priority: Medium).

<<$Addition>> The Control Panel shall include a dashboard to view the status of all report generation and delivery jobs. <<$Addition>> The dashboard shall display a list of recent and currently running jobs. <<$Addition>> Each job in the list shall show its name, status (Queued, Running, Succeeded, Failed), and start/end times. <<$Addition>> The dashboard shall provide real-time updates as job statuses change. <<$Addition>> Administrators shall be able to view detailed execution logs for each job. <<$Addition>> From the job dashboard, an administrator shall be able to access the detailed logs for any specific job. <<$Addition>> The logs shall contain timestamped entries for each stage of the process: data ingestion, transformation, report generation, and delivery. <<$Addition>> All errors encountered during the process shall be logged with detailed context and stack traces. <<$Addition>> Administrators shall be able to manually cancel or retry jobs from the dashboard. <<$Addition>> The dashboard shall provide a 'Cancel' button for jobs that are in the 'Queued' or 'Running' state. <<$Addition>> The dashboard shall provide a 'Retry' button for jobs that are in the 'Failed' state.

An administrator shall be able to activate the system using a cloud-issued activation key. The system shall transition to an 'Active' state and unlock all features when a valid, unexpired activation key is entered in the Control Panel. The system shall display an error message and remain in its current state if an invalid or expired key is entered. The system shall periodically attempt to re-validate the active key with the cloud licensing service. <<$Change>> The periodic validation interval shall be configurable, with a default of 30 days. The system shall operate in a functionally limited Trial Mode if no valid activation key is present. <<$Resolution>> <<$Change>> The Trial Mode limitations shall replace the ambiguous 'limited features' from the original SRS (FR1.3). In Trial Mode, all generated reports shall contain a 'Trial Version' watermark. In Trial Mode, an administrator shall be able to configure a maximum of 3 active report schedules. In Trial Mode, an administrator shall be able to configure a maximum of 1 of each standard connector type (Database, File, OPC). In Trial Mode, custom connectors shall be disabled and cannot be used. The Control Panel UI shall display a persistent, visible indicator that the system is operating in Trial Mode. The system shall enter a Grace Period if a periodic license validation fails. The system shall remain fully functional during the Grace Period. The Control Panel shall display a prominent notification indicating the system is in a Grace Period and the number of days remaining. The system shall return to the 'Active' state if the key is successfully validated before the Grace Period ends. The system shall revert to Trial Mode if the Grace Period expires without a successful validation. <<$Addition>> The Grace Period duration shall be configurable, with a default of 7 days.

All system logs shall be written in a structured JSON format using the Serilog library. Logs shall be written to rolling files in a dedicated `logs` subdirectory. Log files shall be rotated daily. Log files shall be retained for a configurable period, with a default of 30 days. Logs shall capture detailed information for all system activities, including job execution steps, API requests, user actions, and errors with full stack traces. The application shall not have a built-in alerting mechanism. The Job Monitoring Dashboard shall serve as the primary real-time monitoring interface for application-specific activities.

The system shall process datasets of up to 1 million records from a data source into an intermediate JSON file within 5 minutes. Connectors shall use data streaming instead of loading entire datasets into memory. Report generation (HTML to PDF conversion) shall complete within 10 seconds for reports based on datasets under 10,000 records. All Control Panel and Report Viewer API responses shall have a P95 latency of under 200ms under normal load. UI pages shall load within 2 seconds.

The system shall support up to 100 concurrent users accessing the Control Panel or Report Viewer. The system shall handle up to 1,000 scheduled report generations per day without performance degradation. The primary scaling mechanism shall be vertical scaling. The Quartz.NET scheduler shall be configured with a limited-size thread pool, which shall be configurable with a default of 10. The system shall use a modular monolith architecture. <<$Change>> The system shall provide detailed, structured logs in JSON format for all operations. All code shall adhere to defined coding standards. All code shall have a minimum unit test coverage of 80%.

The Windows service shall achieve 99.9% uptime, excluding scheduled maintenance. The Windows service shall be configured to restart automatically upon crashing. The system shall resume any queued or interrupted tasks where feasible upon restart. The user manual shall instruct administrators to include the application's data directory in their standard server backup procedures. Disaster recovery shall be achieved by reinstalling the application and restoring the data directory from a backup.

All external data transmissions shall use HTTPS/TLS 1.2+ encryption. All local web traffic (Control Panel, API) shall use HTTPS/TLS 1.2+ encryption. <<$Change>> Sensitive configuration data stored in the SQLite database shall be encrypted using .NET's Data Protection APIs (DPAPI). The system shall implement Role-Based Access Control (RBAC) for all functions in the Control Panel, Report Viewer, and API. <<$Change>> Audit logs shall track all security-sensitive events. <<$Change>> Audit logs shall include user logins (success and failure), and all CRUD operations on users, roles, report configurations, and system settings. <<$Change>> Audit logs shall include a timestamp, the responsible user, the action performed, and the outcome. <<$Resolution>> <<$Addition>> The system shall be architecturally designed to prevent the transmission of raw or intermediate data from customer data sources over any external network.

The web-based Control Panel's report configuration interface shall be updated to support the selection of new output formats and delivery options. **1.1 UI Modifications:** - In the report definition form, a new mandatory field, 'Output Format', shall be added. - This field shall be implemented as a set of radio buttons or a dropdown menu with the options: `HTML`, `PDF`, `JSON`, `CSV`, `TXT`. - The default selection shall be `PDF`. **1.2 Conditional UI Logic:** - When a user selects `HTML` or `PDF`, the UI section for selecting or editing a Handlebars template shall be visible and required. - When a user selects `JSON`, `CSV`, or `TXT`, the Handlebars template UI section shall be hidden or disabled, as it is not applicable for direct data serialization. **1.3 Data Model Integration:** - The frontend application shall send the selected `outputFormat` value to the backend API when creating or updating a report configuration. - The backend data model for report configurations must be extended to include a non-nullable string field to store the selected output format.

The report delivery module shall be extended to support a new delivery target: a direct response to a synchronous or asynchronous API call. **1.1 Functional Description:** The system shall provide a new delivery mechanism named 'API Response'. When a report is configured with this delivery target, the generated report content is returned directly to the client that initiated the API request, instead of being saved to a persistent storage location. **1.2 Delivery Modes:** - **Synchronous Mode:** For reports expected to generate quickly (e.g., under 30 seconds), the API call shall hold the connection open and return the generated report content directly in the HTTP response body. The `Content-Type` header must be set appropriately (e.g., `application/json`, `text/csv`, `application/pdf`). A configurable timeout (default: 30 seconds) must be implemented, after which the server will respond with a timeout error (e.g., HTTP 408). - **Asynchronous Mode:** For long-running reports, the initial API request shall immediately return an HTTP 202 Accepted response containing a `jobId` and a status polling URL (e.g., `/api/v1/jobs/{jobId}`). The client can then poll the status URL to check for completion. Once the job is complete, the report content can be retrieved via a separate results URL (e.g., `/api/v1/jobs/{jobId}/result`). **1.3 Configuration:** The choice between synchronous and asynchronous behavior for a given API-triggered report shall be configurable at the report definition level.

The report generation engine shall be capable of producing reports in multiple formats based on the job configuration. **1.1 Functional Description:** The engine must support two distinct generation pipelines: - **Templated Generation:** For HTML and PDF output formats, the engine shall process the transformed data using a specified Handlebars template to produce an HTML document. For PDF output, the generated HTML shall then be rendered and converted using an embedded Chromium-based engine. - **Direct Data Serialization:** For JSON, CSV, and TXT output formats, the engine shall bypass the Handlebars templating and Chromium rendering pipeline. It will directly serialize the final transformed data into the selected format. **1.2 Acceptance Criteria:** - The engine must correctly select the generation pipeline (Templated vs. Serialization) based on the 'outputFormat' property of the report configuration. - For JSON output, the result must be a well-formed JSON object or array. - For CSV output, the result must be a standard RFC 4180 compliant file, with the first row containing the data field names as headers. - For TXT output, the result must be a plain text representation of the data, with formatting (e.g., delimiters, line breaks) configurable within the report definition. - The generation process for all formats must be logged, including start time, end time, and success or failure status with detailed error messages.

A web-based viewer shall allow authenticated users to access generated reports. The Report Viewer shall require user authentication. The viewer shall display a list of generated report artifacts. <<$Change>> The report list shall be searchable by report name. <<$Change>> The report list shall be filterable by generation date range. <<$Change>> The report list shall be filterable by status. Clicking on an HTML report in the viewer shall render it directly in the browser. The viewer shall provide a download link for the PDF version of each report. The viewer shall support bulk operations on multiple selected reports. <<$Addition>> The Report Viewer list shall include checkboxes to select multiple reports. <<$Addition>> The UI shall provide an option to delete all selected reports. <<$Addition>> The UI shall provide an option to re-run the delivery process for all selected reports.

The system's scope is defined by the following functional capabilities and explicit limitations. **1.1 In-Scope Capabilities:** - **Deployment:** The system shall provide a locally deployable Windows service for automated report generation. - **Licensing:** The system shall provide a cloud-based activation key mechanism for licensing. - **Data Ingestion:** The system shall provide data ingestion from databases (via JDBC/ODBC), local/network file systems, and OPC UA servers. - **Extensibility:** The system shall provide an extensible plug-in architecture for custom data connectors, with provided examples for FHIR and HL7. - **Data Transformation:** The system shall provide a data transformation engine using JSON-based configurations and user-defined scripts (e.g., JavaScript). - **Report Generation:** The system shall provide report generation using Handlebars templates into human-readable formats (HTML, PDF). It shall also support direct data export to machine-readable formats (JSON, CSV, TXT). - **Report Delivery:** The system shall provide report delivery to cloud storage (e.g., S3, Azure Blob), email (SMTP), local/network storage, and FTP/SFTP. It shall also support direct data delivery via a configurable, secure RESTful API call. - **Management Interface:** The system shall provide a web-based Control Panel for system configuration, user management, and job monitoring. - **Report Access:** The system shall provide a web-based Report Viewer for browsing and accessing generated reports stored by the system. - **On-Demand API:** The system shall provide a secure RESTful API for on-demand report generation. **1.2 Out-of-Scope Limitations:** - The system shall not provide direct integration with Business Intelligence (BI) tools such as Power BI or Tableau. - The system shall not provide a native mobile application for report viewing. - The system shall not provide advanced analytics or machine learning capabilities. - The system shall not provide support for operating systems other than Windows. - The system shall not provide support for report output formats other than HTML, PDF, JSON, CSV, and TXT.

The system shall interface with ODBC/JDBC drivers installed on the host machine. The system shall use an OPC UA client library to connect to industrial data sources. The system shall use a Handlebars.js library for HTML report templating. The system shall interface with a headless Chromium instance via the Puppeteer Sharp library for PDF generation. The system shall use the Quartz.NET library for all job scheduling and management. The system shall use the Jint library to execute JavaScript-based data transformations. The system shall use the Polly library to implement retry and circuit-breaker patterns for external calls. The system shall interface with vendor-provided SDKs for cloud storage delivery. The system shall use standard .NET libraries for report delivery via Email and FTP.

The backend framework shall be C# on .NET 8. The web and API framework shall be ASP.NET Core 8. The frontend framework shall be React 18 with TypeScript. The job scheduling library shall be Quartz.NET 3.x. The local database shall be SQLite via Microsoft.Data.Sqlite. The PDF generation library shall be Puppeteer Sharp. The data transformation library shall be Jint. The resiliency framework shall be Polly. The logging library shall be Serilog. The installer shall be created using the WiX Toolset.

The UI framework shall be React 18 with TypeScript. The UI shall be clean, intuitive, and responsive. The Control Panel and Report Viewer shall be usable on standard desktop screen resolutions of 1280px width and above. The UI shall adhere to Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. The system shall provide a single, standard light theme. The UI theme shall not be customizable by the user. The system shall provide a login screen with inputs for username, password, and a login button. The Control Panel shall use a navigation sidebar for accessing different sections. The Report Viewer shall feature a search/filter bar and a paginated table of reports.

Administrators shall be able to perform full CRUD operations on user accounts. An Administrator shall be able to create a new user by providing a username, password, and role. An Administrator shall be able to view a list of all existing users. An Administrator shall be able to edit an existing user's role. An Administrator shall be able to delete an existing user account. The primary administrator account shall not be deletable. The system shall enforce security policies for user passwords. The system shall enforce a configurable password policy on user creation and password changes. The password policy shall include settings for minimum length, complexity (uppercase, lowercase, numbers, special characters), and expiration. The system shall prevent the reuse of a configurable number of previous passwords. The system shall provide a secure mechanism for users to reset their forgotten passwords. An Administrator shall be able to initiate a password reset for a user, which invalidates their current password. The system shall generate a temporary, one-time-use password that the administrator can provide to the user. A user shall be forced to set a new password that complies with the password policy upon their next login with a temporary password. The system shall lock user accounts after multiple failed login attempts. A user's account shall be locked after a configurable number of consecutive failed login attempts. A locked-out user shall not be able to log in, even with the correct password. An Administrator shall be able to manually unlock a locked user account through the Control Panel. The system shall automatically terminate user sessions after a period of inactivity. User sessions in the Control Panel and Report Viewer shall time out after a configurable period of inactivity. Upon timeout, the user shall be logged out and redirected to the login page.

The system shall define an 'Administrator' user class with full CRUD access to all system configurations. The system shall define an 'End-User (Viewer)' user class with read-only access to the Report Viewer. The system shall define a 'System Integrator' user class that interacts with the system by developing plug-ins against a provided Plug-in Development Kit (PDK). The system shall define an 'IT Support' user class with filesystem and OS-level access for installation and maintenance.

### **Project Overview** This document specifies the requirements for the Reporting System, a locally deployable Windows service designed to generate, manage, and deliver customizable reports. The system integrates with various data sources, processes data locally for privacy, and provides web-based interfaces for configuration and viewing. A key feature is its cloud-based activation mechanism and an extensible plug-in architecture for future data connectors. ### **Core Functional Requirements** - **System Activation**: The service must be activated with a cloud-issued key, which is validated periodically. An inactive or expired key reverts the system to a trial mode. - **Data Ingestion**: The system must support multiple data sources through connectors: - Relational Databases (SQL Server, MySQL, etc.) - File Systems (CSV, JSON, XML) - OPC UA servers - A plug-in framework for custom connectors (e.g., FHIR, HL7). - **Data Processing**: All ingested data is standardized into a JSON format. A transformation engine allows for data manipulation (filtering, aggregation) via a configurable interface. - **Report Generation**: Reports are created in HTML format using Handlebars templates and can be exported to PDF. The system will include default templates and allow users to upload custom ones. - **Report Delivery**: Generated reports can be delivered to multiple destinations: - Cloud Storage (AWS S3, Azure Blob, etc.) - Email via SMTP - Local File System - Secure File Servers via SFTP/FTPS. - **Management & Viewing**: - **Control Panel**: A web-based UI for managing activation, connectors, transformations, report schedules, and delivery settings. It includes user authentication and role-based access. - **Report Viewer**: A separate web-based UI for end-users to browse, search, filter, and view generated reports securely. ### **Key Non-Functional Requirements** - **Performance**: The system must process large datasets (up to 1 million records) within 5 minutes and generate smaller reports (under 10k records) within 10 seconds. UI response times should be under 2 seconds. - **Scalability**: Designed to support up to 100 concurrent users and generate up to 1,000 reports daily without degradation. - **Security**: A critical focus, with requirements for: - Encryption of data in transit (HTTPS, TLS) for all external communications. - Encryption of sensitive configuration data (e.g., credentials) at rest. - Role-based access control (RBAC) for the control panel and viewer. - Comprehensive audit logging of user actions. - **Reliability & Maintainability**: The system must achieve 99.9% uptime with automatic crash recovery. Its modular architecture is designed to simplify updates and maintenance. - **Compatibility**: The service must run on modern Windows operating systems (Windows 10/11, Server 2019/2022), and its web interfaces must be compatible with current browsers (Chrome, Firefox, Edge). ### **System Architecture & Deployment** The system is a Windows service deployed on a local server or workstation. It features a layered architecture separating the presentation (web UI), business logic (Windows service), and data access components. While deployed locally, it requires internet access for initial activation and for optional cloud-based delivery features.

# Software Requirements Specification (SRS) for Reporting System ## Document Control - **Version**: 1.0 - **Date**: November 2, 2025 ## 1. Introduction ### 1.1 Purpose This Software Requirements Specification (SRS) defines the functional and non-functional requirements for a locally deployable Reporting System. The system generates, manages, and delivers customizable HTML and PDF reports based on data from various sources. It includes a cloud-based activation key mechanism, a control panel for configuration, and a viewer for browsing reports. The system is designed to be extensible, secure, and aligned with world-class tech company standards. ### 1.2 Scope The Reporting System provides: - **Data Ingestion**: Connectors for databases, file systems, OPC (OLE for Process Control), and extensible custom connectors (e.g., FHIR, HL7). - **Data Processing**: JSON-based intermediate data storage and transformation. - **Report Generation**: Configurable HTML reports using Handlebars templates, with PDF export. - **Report Delivery**: Outputs to cloud storage, email, local storage, FTP, etc. - **Configuration**: A control panel for managing connectors, transformations, schedules, and templates. - **Viewing**: A report viewer for browsing and accessing generated reports. - **Deployment**: Local Windows service with cloud-based activation key validation. - **Extensibility**: Plug-in architecture for future connectors and features. The system ensures scalability, security, and user-friendly configuration while supporting both scheduled and on-demand reporting. ### 1.3 Definitions, Acronyms, and Abbreviations - **SRS**: Software Requirements Specification - **OPC**: OLE for Process Control, a standard for industrial automation data exchange - **FHIR**: Fast Healthcare Interoperability Resources - **HL7**: Health Level Seven, a standard for healthcare data exchange - **JSON**: JavaScript Object Notation - **Handlebars**: A templating engine for generating HTML reports - **FTP**: File Transfer Protocol - **FTPS**: FTP over SSL/TLS - **SFTP**: SSH File Transfer Protocol - **API**: Application Programming Interface - **UI**: User Interface ### 1.4 References - Handlebars documentation: https://handlebarsjs.com/ - OPC Foundation: https://opcfoundation.org/ - FHIR Specification: https://www.hl7.org/fhir/ - HL7 Standards: https://www.hl7.org/ ### 1.5 Audience This document is intended for: - Software developers and architects - Project managers and stakeholders - Quality assurance teams - System administrators - End-users configuring and viewing reports ## 2. Overall Description ### 2.1 Product Perspective The Reporting System is a standalone Windows service that operates locally but requires a cloud-based activation key for licensing. It integrates with external data sources (databases, files, OPC, etc.), processes data into JSON, applies transformations, and generates HTML or PDF reports using Handlebars templates. Reports can be scheduled or generated on-demand and delivered to various destinations. The system includes a control panel for configuration and a viewer for report access. The system is designed with a modular architecture to support future extensions, such as new connectors (e.g., FHIR, HL7) via a plug-in framework. ### 2.2 Product Functions - **Activation**: Validate and activate the service using a cloud-issued activation key. - **Data Ingestion**: Connect to databases, files, OPC servers, or custom sources. - **Data Processing**: Store intermediate data in JSON and apply configurable transformations. - **Report Configuration**: Define schedules, intervals, and historical data ranges for reports. - **Report Generation**: Create HTML reports using Handlebars templates, with PDF export. - **Report Delivery**: Output reports to cloud storage, email, local storage, or secure file servers. - **Control Panel**: Provide a UI for configuring connectors, transformations, templates, and schedules. - **Report Viewer**: Enable browsing and viewing of generated reports. ### 2.3 User Classes and Characteristics - **Administrators**: Configure connectors, transformations, templates, and schedules via the control panel. Require technical knowledge of data sources and reporting needs. - **End-Users**: View and browse reports through the viewer. Minimal technical expertise required. - **System Integrators**: Develop custom connectors (e.g., FHIR, HL7) using the plug-in framework. - **IT Support**: Manage local deployment, activation, and maintenance of the Windows service. ### 2.4 Operating Environment - **Platform**: Windows Server 2019/2022 or Windows 10/11 (64-bit) - **Deployment**: Local installation as a Windows service - **Network**: Internet access for cloud-based activation key validation - **Dependencies**: - .NET Framework or .NET Core for Windows service - Database drivers (e.g., ODBC, JDBC) for database connectors - OPC UA client libraries for OPC connectivity - Handlebars.js for report templating - PDF generation library (e.g., wkhtmltopdf, iTextSharp) ### 2.5 Design and Implementation Constraints - Must run as a Windows service for background operation. - Activation key must be validated via a secure cloud API. - All data processing and report generation must occur locally to ensure data privacy. - Custom connectors must follow a defined plug-in specification. - Reports must support both HTML and PDF formats. - System must handle large datasets (up to 1M records) efficiently. ### 2.6 Assumptions and Dependencies - **Assumptions**: - Users have stable internet access for initial activation. - Data sources provide consistent and well-structured data. - Administrators are trained to configure connectors and templates. - **Dependencies**: - Cloud-based licensing server availability. - Third-party libraries for PDF generation and data connectivity. ## 3. Functional Requirements ### 3.1 System Activation - **FR1.1**: The system shall validate an activation key via a secure cloud API during initial setup and periodically (e.g., every 30 days). - **FR1.2**: The control panel shall provide a UI to input and update the activation key. - **FR1.3**: The system shall operate in a trial mode (limited features) if the activation key is invalid or expired. - **FR1.4**: Activation failures shall be logged, and users shall be notified via the control panel. ### 3.2 Data Input Connectors - **FR2.1**: The system shall support data ingestion from: - Relational databases (e.g., SQL Server, MySQL, PostgreSQL) via ODBC/JDBC. - File systems (e.g., CSV, JSON, XML). - OPC UA servers for industrial data. - Custom connectors via a plug-in framework. - **FR2.2**: Custom connectors shall follow a documented plug-in specification, including: - Input: Configuration parameters (e.g., connection strings, authentication). - Output: Data in JSON format. - Methods: Connect, Disconnect, Fetch Data, Validate Configuration. - **FR2.3**: The system shall support future connectors (e.g., FHIR, HL7) without modifying core code. - **FR2.4**: Connectors shall handle errors (e.g., connection failures) and log them for debugging. - **FR2.5**: The control panel shall allow configuration of connector parameters (e.g., database credentials, file paths). ### 3.3 Intermediate Data Storage - **FR3.1**: All ingested data shall be converted to a standardized JSON format for processing. - **FR3.2**: The system shall store intermediate JSON data temporarily in memory or on disk, configurable by the administrator. - **FR3.3**: JSON data shall include metadata (e.g., source, timestamp) for traceability. ### 3.4 Data Transformation - **FR4.1**: The system shall provide a transformation engine to manipulate JSON data (e.g., filtering, aggregation, mapping). - **FR4.2**: Transformations shall be configurable via the control panel using a visual editor or script-based interface (e.g., JavaScript, Python). - **FR4.3**: The system shall support predefined transformation templates for common operations (e.g., sum, average, date formatting). - **FR4.4**: Transformations shall be validated to prevent errors in report generation. ### 3.5 Report Configuration - **FR5.1**: The system shall allow configuration of report schedules (e.g., daily, weekly, one-time). - **FR5.2**: Reports shall support historical data ranges (e.g., last 7 days, specific date range). - **FR5.3**: The control panel shall provide a UI to define report parameters (e.g., data source, transformation, template). - **FR5.4**: The system shall support on-demand report generation triggered via the control panel or API. ### 3.6 Report Generation - **FR6.1**: Reports shall be generated using Handlebars templates, accepting JSON data as input. - **FR6.2**: The system shall support custom Handlebars templates uploaded via the control panel. - **FR6.3**: Reports shall be exportable as HTML or PDF. - **FR6.4**: The system shall provide a library of default templates for common report types (e.g., tabular, summary). - **FR6.5**: Report generation errors shall be logged and reported to the user. ### 3.7 Report Delivery - **FR7.1**: Reports shall be deliverable to: - Cloud storage (e.g., AWS S3, Google Cloud Storage, Azure Blob Storage). - Email (SMTP configuration). - Local file system. - <<$Change>>SFTP/FTPS servers<<$Change>>. - **FR7.2**: The control panel shall allow configuration of delivery options (e.g., <<$Change>>credentials, host keys,<<$Change>> file naming conventions). - **FR7.3**: Delivery failures shall be logged, and retry mechanisms shall be implemented (e.g., retry 3 times with 5-minute intervals). - **FR7.4**: Reports shall be archived locally or in the cloud, configurable by the administrator. #### Enhancement Justification The requirement for report delivery via FTP has been updated to specify secure protocols (SFTP/FTPS). This change resolves a technical contradiction and security vulnerability, as standard FTP does not support encryption and transmits data in plaintext. This ensures that all report delivery mechanisms adhere to modern security standards, aligning with the overall security requirements of the system. ### 3.8 Control Panel - **FR8.1**: The system shall provide a web-based control panel accessible via a local URL (e.g., http://localhost:8080). - **FR8.2**: The control panel shall support: - Activation key management. - Connector configuration. - Transformation configuration. - Report scheduling and template management. - Delivery configuration. - System monitoring (e.g., logs, status). - **FR8.3**: The control panel shall require user authentication (e.g., username/password, SSO). - **FR8.4**: The control panel shall support role-based access control (e.g., admin, viewer). ### 3.9 Report Viewer - **FR9.1**: The system shall provide a web-based report viewer to browse and view generated reports. - **FR9.2**: The viewer shall support filtering and searching reports by metadata (e.g., date, type). - **FR9.3**: The viewer shall display HTML reports natively and allow PDF downloads. - **FR9.4**: The viewer shall require user authentication, with access restricted based on roles. ## 4. Non-Functional Requirements ### 4.1 Performance - **NFR1.1**: The system shall process datasets up to 1 million records within 5 minutes. - **NFR1.2**: Report generation shall complete within 10 seconds for datasets under 10,000 records. - **NFR1.3**: The control panel and viewer shall load pages within 2 seconds under normal conditions. ### 4.2 Scalability - **NFR2.1**: The system shall support up to 100 concurrent users accessing the control panel or viewer. - **NFR2.2**: The system shall handle up to 1,000 reports per day without performance degradation. ### 4.3 Security - **NFR3.1**: All data transmissions (e.g., cloud activation, <<$Change>>secure file transfers<<$Change>>) shall use HTTPS/TLS encryption. - **NFR3.2**: Sensitive configuration data (e.g., database credentials) shall be encrypted at rest. - **NFR3.3**: The system shall implement role-based access control for the control panel and viewer. - **NFR3.4**: Audit logs shall track all user actions (e.g., configuration changes, report access). #### Enhancement Justification Requirement NFR3.1 was updated to replace "FTP" with "secure file transfers." This resolves a technical contradiction, as the standard FTP protocol does not natively support TLS encryption. By specifying secure alternatives like SFTP or FTPS, the requirement becomes technically feasible and eliminates a potential security vulnerability associated with transmitting data over an unencrypted channel. ### 4.4 Reliability - **NFR4.1**: The system shall achieve 99.9% uptime, excluding scheduled maintenance. - **NFR4.2**: The system shall recover from crashes automatically and resume pending tasks. ### 4.5 Usability - **NFR5.1**: The control panel and viewer shall have an intuitive UI, requiring less than 1 hour of training for administrators. - **NFR5.2**: The system shall provide inline help and tooltips for configuration options. ### 4.6 Maintainability - **NFR6.1**: The system shall use a modular architecture to allow updates to individual components (e.g., connectors) without affecting others. - **NFR6.2**: The system shall provide detailed logs for debugging and monitoring. ### 4.7 Compatibility - **NFR7.1**: The system shall support modern browsers (e.g., Chrome, Firefox, Edge) for the control panel and viewer. - **NFR7.2**: The system shall be compatible with Windows Server 2019/2022 and Windows 10/11. ## 5. System Architecture ### 5.1 Overview The system follows a modular, layered architecture: - **Presentation Layer**: Web-based control panel and report viewer. - **Business Logic Layer**: Windows service handling data ingestion, transformation, report generation, and delivery. - **Data Layer**: Temporary JSON storage and connector-specific data access. - **Plug-in Layer**: Extensible connectors for custom data sources. ### 5.2 Deployment - **Local Deployment**: Installed as a Windows service on a local server or workstation. - **Cloud Integration**: Connects to a cloud-based licensing server for activation key validation. - **Network Requirements**: Requires outbound HTTPS access for activation and optional cloud storage/secure file delivery. ### 5.3 Component Diagram ``` [Control Panel] <-> [Windows Service] <-> [Data Connectors] [Report Viewer] <-> [Windows Service] <-> [Report Storage] [Windows Service] <-> [Cloud Licensing Server] [Windows Service] <-> [Delivery Endpoints (Cloud, Email, SFTP/FTPS)] ``` ## 6. External Interface Requirements ### 6.1 User Interfaces - **Control Panel**: Web-based UI with forms for configuring connectors, transformations, schedules, and delivery. - **Report Viewer**: Web-based UI with report browsing, filtering, and download capabilities. ### 6.2 Hardware Interfaces - **Local Server/Workstation**: Runs the Windows service and hosts the control panel/viewer. - **Network**: Internet access for activation and optional delivery. ### 6.3 Software Interfaces - **Database Drivers**: ODBC/JDBC for database connectivity. - **OPC UA Client**: For industrial data sources. - **Handlebars.js**: For HTML report templating. - **PDF Library**: For PDF generation (e.g., wkhtmltopdf). - **Cloud APIs**: For activation key validation and cloud storage. - **Email/FTP Libraries**: For report delivery. ### 6.4 Communication Interfaces - **HTTPS**: For cloud activation and cloud storage. - **SMTP**: For email delivery. - **<<$Change>>SFTP/FTPS<<$Change>>**: For file transfer. #### Enhancement Justification The communication interface for file transfer has been updated from "FTP/SFTP" to "SFTP/FTPS". This change standardizes the use of secure, encrypted protocols, removing the insecure FTP option and resolving the technical contradiction identified in the security requirements. ## 7. Other Requirements ### 7.1 Regulatory Compliance - The system shall comply with GDPR and CCPA for data privacy if deployed in relevant regions. - The system shall support FHIR/HL7 standards for healthcare-related connectors. ### 7.2 Documentation - **User Manual**: For administrators and end-users. - **Developer Guide**: For custom connector development. - **API Documentation**: For system integration and automation. ### 7.3 Support and Maintenance - The system shall provide automated updates for the Windows service and connectors. - A support portal shall be available for reporting issues and accessing updates. ## 8. Future Considerations - Support for additional output formats (e.g., Excel, Word). - Integration with BI tools (e.g., Power BI, Tableau). - Mobile app for report viewing. - Advanced analytics (e.g., predictive reporting) using machine learning. ## 9. Acceptance Criteria - The system successfully activates with a valid cloud-issued key. - All connectors (database, file, OPC, custom) fetch data and convert to JSON. - Transformations produce correct JSON output as per configuration. - Reports are generated in HTML and PDF formats using Handlebars templates. - Reports are delivered to all configured destinations without errors. - The control panel and viewer are accessible, secure, and user-friendly. - The system meets performance and scalability requirements under load testing.