diff --git a/Assets/AzureBlobStorageContainer.png b/Assets/AzureBlobStorageContainer.png deleted file mode 100644 index c99ce7a..0000000 Binary files a/Assets/AzureBlobStorageContainer.png and /dev/null differ diff --git a/Assets/CosmosDBScreenshot.png b/Assets/CosmosDBScreenshot.png deleted file mode 100644 index a56aa7a..0000000 Binary files a/Assets/CosmosDBScreenshot.png and /dev/null differ diff --git a/Assets/DevicesShowcase.gif b/Assets/DevicesShowcase.gif deleted file mode 100644 index 977c647..0000000 Binary files a/Assets/DevicesShowcase.gif and /dev/null differ diff --git a/Assets/MeasurementsShowcase.gif b/Assets/MeasurementsShowcase.gif deleted file mode 100644 index 866dbc0..0000000 Binary files a/Assets/MeasurementsShowcase.gif and /dev/null differ diff --git a/Assets/RaportGenerationFlow.png b/Assets/RaportGenerationFlow.png deleted file mode 100644 index 3fa7de5..0000000 Binary files a/Assets/RaportGenerationFlow.png and /dev/null differ diff --git a/Assets/RaportGenerationSteps.png b/Assets/RaportGenerationSteps.png deleted file mode 100644 index 9efd4cf..0000000 Binary files a/Assets/RaportGenerationSteps.png and /dev/null differ diff --git a/Assets/RaportsShowcase.gif b/Assets/RaportsShowcase.gif deleted file mode 100644 index 9605ff0..0000000 Binary files a/Assets/RaportsShowcase.gif and /dev/null differ diff --git a/Assets/api_gateway.png b/Assets/api_gateway.png new file mode 100644 index 0000000..b641a74 Binary files /dev/null and b/Assets/api_gateway.png differ diff --git a/Assets/api_gateway_architecture.png b/Assets/api_gateway_architecture.png new file mode 100644 index 0000000..12c43c1 Binary files /dev/null and b/Assets/api_gateway_architecture.png differ diff --git a/Assets/architecture-top-most.png b/Assets/architecture-top-most.png deleted file mode 100644 index f551682..0000000 Binary files a/Assets/architecture-top-most.png and /dev/null differ diff --git a/Assets/azure_top_down_architecture.png b/Assets/azure_top_down_architecture.png new file mode 100644 index 0000000..58f8f2b Binary files /dev/null and b/Assets/azure_top_down_architecture.png differ diff --git a/Assets/containers.png b/Assets/containers.png deleted file mode 100644 index bddc456..0000000 Binary files a/Assets/containers.png and /dev/null differ diff --git a/Assets/dbschema.png b/Assets/dbschema.png deleted file mode 100644 index 849a409..0000000 Binary files a/Assets/dbschema.png and /dev/null differ diff --git a/Assets/devices_architecture.png b/Assets/devices_architecture.png new file mode 100644 index 0000000..e1bfd64 Binary files /dev/null and b/Assets/devices_architecture.png differ diff --git a/Assets/devices_db_schema.png b/Assets/devices_db_schema.png new file mode 100644 index 0000000..274ccec Binary files /dev/null and b/Assets/devices_db_schema.png differ diff --git a/Assets/emulators_architecture.png b/Assets/emulators_architecture.png new file mode 100644 index 0000000..4b96ec9 Binary files /dev/null and b/Assets/emulators_architecture.png differ diff --git a/Assets/emulators_db_schema.png b/Assets/emulators_db_schema.png new file mode 100644 index 0000000..cbb544d Binary files /dev/null and b/Assets/emulators_db_schema.png differ diff --git a/Assets/homeelogo.png b/Assets/homeelogo.png deleted file mode 100644 index ba17177..0000000 Binary files a/Assets/homeelogo.png and /dev/null differ diff --git a/Assets/logo.png b/Assets/logo.png new file mode 100644 index 0000000..a7e8a0b Binary files /dev/null and b/Assets/logo.png differ diff --git a/Assets/measurements_architecture.png b/Assets/measurements_architecture.png new file mode 100644 index 0000000..07e81dc Binary files /dev/null and b/Assets/measurements_architecture.png differ diff --git a/Assets/microservices_communication.png b/Assets/microservices_communication.png new file mode 100644 index 0000000..9381f45 Binary files /dev/null and b/Assets/microservices_communication.png differ diff --git a/Assets/raport_generation.png b/Assets/raport_generation.png new file mode 100644 index 0000000..6b33124 Binary files /dev/null and b/Assets/raport_generation.png differ diff --git a/Assets/raports_architecture.png b/Assets/raports_architecture.png new file mode 100644 index 0000000..7d08232 Binary files /dev/null and b/Assets/raports_architecture.png differ diff --git a/Assets/raports_db_schema.png b/Assets/raports_db_schema.png new file mode 100644 index 0000000..51605e4 Binary files /dev/null and b/Assets/raports_db_schema.png differ diff --git a/README.md b/README.md index 9fdefc4..866a9fd 100644 --- a/README.md +++ b/README.md @@ -1,301 +1,178 @@ -# `Homee system` - Backend +
-Image +# Homee System - Microservices -The `Homee System` backend is built with `.NET 8` and `ASP.NET Core`, designed as a distributed architecture composed of multiple `microservices` that operate independently yet integrate seamlessly to form a reliable and scalable platform. Its primary purpose is to serve as a central backend for managing devices and sensors within a single facility, enabling `device registration`, `real-time measurement data collection`, and `automated report generation`. +### Microservices architecture for IoT device management and monitoring -System exposes both `RESTful` endpoints and `gRPC` connections to facilitate efficient client communication and service-to-service interactions. To ensure flexibility and scalability, the backend is fully `containerized` and optimized for deployment in orchestrated environments such as `Azure Container Apps` or local `Docker-compose`, while a Docker Compose setup allows developers to run the entire stack locally without requiring any external dependencies. +[![.NET](https://img.shields.io/badge/.NET-8.0-512BD4?logo=dotnet&logoColor=white)](https://dotnet.microsoft.com/) +[![C#](https://img.shields.io/badge/C%23-Language-239120?logo=csharp&logoColor=white)](https://docs.microsoft.com/en-us/dotnet/csharp/) +[![ASP.NET Core](https://img.shields.io/badge/ASP.NET%20Core-Framework-512BD4?logo=dotnet&logoColor=white)](https://dotnet.microsoft.com/apps/aspnet) +[![Entity Framework Core](https://img.shields.io/badge/Entity%20Framework%20Core-9.0.11-512BD4?logo=dotnet&logoColor=white)](https://docs.microsoft.com/en-us/ef/core/) +[![SQL Server](https://img.shields.io/badge/SQL%20Server-2022-CC2927?logo=microsoftsqlserver&logoColor=white)](https://www.microsoft.com/sql-server) +[![Azure Cosmos DB](https://img.shields.io/badge/Azure%20Cosmos%20DB-NoSQL-0078D4?logo=microsoftazure&logoColor=white)](https://azure.microsoft.com/services/cosmos-db/) +[![Azure Service Bus](https://img.shields.io/badge/Azure%20Service%20Bus-Messaging-0078D4?logo=microsoftazure&logoColor=white)](https://azure.microsoft.com/services/service-bus/) +[![Azure Blob Storage](https://img.shields.io/badge/Azure%20Blob%20Storage-Storage-0078D4?logo=microsoftazure&logoColor=white)](https://azure.microsoft.com/services/storage/blobs/) +[![gRPC](https://img.shields.io/badge/gRPC-2.71.0-244C5A?logo=grpc&logoColor=white)](https://grpc.io/) +[![SignalR](https://img.shields.io/badge/SignalR-Real--time-512BD4?logo=dotnet&logoColor=white)](https://dotnet.microsoft.com/apps/aspnet/signalr) +[![Docker](https://img.shields.io/badge/Docker-Containerized-2496ED?logo=docker&logoColor=white)](https://www.docker.com/) +[![MassTransit](https://img.shields.io/badge/MassTransit-8.5.5-0066CC?logo=message&logoColor=white)](https://masstransit.io/) +[![YARP](https://img.shields.io/badge/YARP-2.3.0-512BD4?logo=dotnet&logoColor=white)](https://microsoft.github.io/reverse-proxy/) +[![MediatR](https://img.shields.io/badge/MediatR-13.0.0-FF6347?logo=dotnet&logoColor=white)](https://github.com/jbogard/MediatR) +[![FluentValidation](https://img.shields.io/badge/FluentValidation-12.0.0-2C5BB4?logo=dotnet&logoColor=white)](https://fluentvalidation.net/) +[![QuestPDF](https://img.shields.io/badge/QuestPDF-2025.7.4-FF6B6B?logo=adobe&logoColor=white)](https://www.questpdf.com/) +[![OpenAI](https://img.shields.io/badge/OpenAI-2.7.0-412991?logo=openai&logoColor=white)](https://openai.com/) -This repository focuses on the `backend architecture` of the `Homee System`, emphasizing clean separation of concerns, high maintainability, and an `event-driven approach` to data processing. +
-## `System's components` +## 📖 Overview -System is designed as a collection of independent services, each with a clearly defined responsibility: -- `Device Management` – Handles the full lifecycle of devices, including adding, updating, and removing them from the system. -- `Measurement Collection` – Records and stores data captured by devices for later processing and analysis. -- `Report Generation` – Creates comprehensive reports that summarize collected data and make it accessible for users. -- `Intelligent Assistant` – Analyzes measurement data, identifies key insights, and provides summaries that enhance the reports. +Backend for **Homee System** - A .NET microservices architecture that provides device management, real-time environmental data collection, automated PDF raport generation, and AI-powered data analysis. The system enables device registration, measurement tracking for 15+ environmental parameters (temperature, humidity, air quality, etc.), and comprehensive raporting with LLM-based insights. -Additional supporting components include: -- `Message Queue` – Enables asynchronous communication between services, ensuring reliable data exchange. -- `Gateway Service` – Acts as a single entry point for all requests and routes them to the correct service within the system. +Built on `.NET 8` and `ASP.NET Core`, the backend is composed of four core microservices (`Devices`, `Measurements`, `Emulators`, `Raports`) orchestrated through an `API Gateway`. Services communicate via `gRPC` for inter-service calls and `Azure Service Bus` for event-driven workflows. The architecture is fully containerized with `Docker` and deployed to `Azure App Service`. -## `Architecture` +## 🏗️ Architecture Overview -Backend architecture is illustrated in the following diagram: +### Microservices -![image](Assets/architecture-top-most.png) +The system is composed of independent microservices, each with dedicated databases and clearly defined responsibilities: -At the top level, the system is composed of four core microservices (`Devices`, `Measurements`, `Reports`, and `AiAssistant`), supported by two key infrastructure components: +- **Devices Service** - Manages device lifecycle, configurations, and status using `Microsoft SQL Server` +- **Measurements Service** - Stores time-series sensor data in `Azure Cosmos DB` with flexible schema support +- **Raports Service** - Generates PDF raports using `QuestPDF` and stores them in `Azure Blob Storage` +- **Emulators Service** - Emulates devices. +- **API Gateway** - Routes external traffic using `YARP` reverse proxy with authentication and throttling -`API Gateway` – Serves as a single entry point for all external requests and routes them to the appropriate microservices. It is implemented using the `YARP` library, which offers advanced features such as `connection throttling` and `authentication`. In this implementation, `YARP` is primarily used for `traffic redirection` and consolidating all requests into one gateway. +Each service exposes `RESTful APIs` for external communication and `gRPC endpoints` for efficient inter-service communication. Real-time updates are delivered via `SignalR WebSockets`. -`Message Queue` – Handles asynchronous messaging between services, implemented using `RabbitMQ` and the `MassTransit` library. It is one of the two communication methods between services and is primarily used to store and distribute messages related to report generation. +![API Gateway Overview](Assets/api_gateway.png) -### `Microservices` +### Communication Patterns -All microservices run inside separate `Docker containers` and are `orchestrated` together using `Docker Compose`, providing a fully containerized and self-contained backend environment. +Services communicate using multiple protocols optimized for different use cases: -- `Devices` - This microservice manages all operations related to `registering`, `updating`, and `removing devices` within the system. It uses `Entity Framework` as the `ORM` for interacting with a `MS SQL Server database`. This service also provides a `gRPC server` for sharing device information with other services. To maintain a clean and modular architecture, it leverages several libraries: - - `FluentValidation` – Validating all incoming data. - - `Carter` – Building minimal API endpoints. - - `MediatR` – Implements the mediator pattern, enabling clean separation of concerns and streamlined request handling. - - `Mapster` – Mapping between DTOs and internal domain models. +- **gRPC** - High-performance inter-service communication for data retrieval +- **AMQP** - Asynchronous messaging via `Azure Service Bus` for event-driven workflows +- **WebSockets** - Real-time data streaming to frontend clients via `SignalR` +- **REST APIs** - External client communication through the API Gateway -- `Measurements` - Microservice focuses on storing data captured by devices. Since the structure of measurement data can vary, a `NoSQL` database was chosen. It uses `Azure Cosmos DB`, which offers low latency, high performance, and generous free-tier storage. Like the Devices service, it also provides a `gRPC server` to share measurement data with clients. It features endpoints for registering and retrieving measurements. For report generation, this service aggregates data by calling the gRPC endpoints of Devices and other services, processes the data, and packages it for the AiAssistant service to produce descriptive insights. +![Microservices Communication](Assets/microservices_communication.png) -- `Reports` - Generates data summaries based on the information stored in Measurements. Currently, it supports generating daily reports, which are exported as `PDF` files and stored in `Azure Blob Storage`. This design ensures that reports remain accessible even when the service is offline. +### Azure Deployment -- `AiAssistant` - Uses an embedded `Ollama` container running `Meta’s LLaMa` model to analyze measurement data. It exposes a `gRPC server` that receives data packets, processes them, and generates descriptive summaries. These AI-generated summaries are then included in the final reports produced by the Reports service. +Backend is deployed to Microsoft Azure using a combination of services optimized for microservices architecture: -All microservices running in single `Docker-compose`: +- **Azure App Service** - Hosts the API Gateway and core microservices with built-in scaling and load balancing. Was used because of pricing. It is far the cheapest option for hosting microservice, even though it was not build for that. +- **Azure Cosmos DB** - Provides globally distributed, low-latency NoSQL database for measurement data. +- **Azure Service Bus** - Handles asynchronous messaging and event-driven communication between services. +- **Azure Blob Storage** - Stores generated PDF raports with high availability and durability +- **Azure SQL Database** - Manages relational data for Devices, Emulators and Raports services -![image](Assets/containers.png) +![Azure Architecture](Assets/azure_top_down_architecture.png) ---- +## 📦 Devices Service -# Devices +Manages detailed information about each device, including registration dates, descriptions, locations, statuses, and measurement schedules. Users can modify device information (e.g., changing location from 'Kitchen' to 'Living Room') and control device status to enable or disable measurement capturing capabilities. Measurement frequencies are configured using CRON expressions stored in a separate configuration table. -## Database schema +This service uses `Entity Framework Core` as the ORM for interacting with a `Microsoft SQL Server` database. It provides both a `gRPC server` for inter-service communication and `WebSockets` for real-time frontend updates. -The `Devices` service manages detailed information about each device, including unique identifiers, registration dates, descriptions, and links to their locations, statuses, and measurement schedules. Devices are assigned statuses like registered, active, or removed to indicate their current state. Measurement frequencies are configured using CRON expressions stored in a separate configuration table, allowing flexible scheduling of device data collection. Together, these tables organize device data, operational states, and timing configurations to support effective device management. +### Architecture -![image](Assets/dbschema.png) +The service exposes multiple communication channels: a gRPC server for inter-service communication, WebSockets for real-time data streaming to the frontend, and RESTful endpoints for device management operations. -## Showcase +![Devices Architecture](Assets/devices_architecture.png) -This demo shows how to interact with `Devices` service via it's endpoints by using `Postman`. +### Database Diagram -![image](Assets/DevicesShowcase.gif) +The main goal of this service is to store device configurations that can be accessed by other services. ---- +![Devices Architecture](Assets/devices_db_schema.png) -# Measurements +## 📊 Measurements Service -## CosmosDB database +Stores time-series measurement data captured by devices using `Azure Cosmos DB`, a NoSQL database that provides low latency, high performance, and flexible schema support. The service handles dynamic data structures where measurement fields vary by device type—for example, a temperature-only sensor will store only temperature data, omitting other fields. -`Measurements` microservice uses `CosmosDB` database with it's `5 GB` free tier which is sufficient for usecases of this project. +The service exposes both a `gRPC server` for inter-service data retrieval and `RESTful endpoints` for registering and querying measurements. For raport generation, it aggregates data from multiple sources and prepares datasets for the AiAssistant service to analyze. -![image](Assets/CosmosDBScreenshot.png) +### Architecture -## Examplary measurement data +The service architecture supports dual communication patterns: gRPC for efficient inter-service data exchange and REST APIs for device data ingestion and client queries. -The data sent to and received from the `Measurements` service can vary in structure, depending on the type of device and the measurements it performs. For example, a device might only capture temperature readings, in which case only the temperature field will be present while other fields will be omitted. By leveraging a `NoSQL database`, the system is able to store this dynamic data structure seamlessly, without requiring a predefined schema, allowing maximum flexibility in handling different types of measurement data. +![Measurements Architecture](Assets/measurements_architecture.png) + +### Database Entity ```json { - "id": "97f2e838-f479-40be-92c7-e55896b01378", - "DeviceNumber": "83f17437-0048-416e-a57a-a8a13a06a1df", - "RegisterDate": "2025-06-14T00:38:34", - "Temperature": { - "Value": 22.30064309330003, - "Unit": "°C" - }, - "Humidity": { - "Value": 42.49535920225, - "Unit": "% RH" - }, - "CO2": { - "Value": 898.4858812123161, - "Unit": "ppm" - }, - "VOC": { - "Value": 190.35422347880603, - "Unit": "µg/m³" - }, - "ParticulateMatter1": { - "Value": 7.941211856272382, - "Unit": "µg/m³" - } - # more ... + "id": "ffba2831-c186-4f57-b4a6-4103b151dfd2", + "deviceNumber": "8070047f-f866-408f-bf2f-8822eb0f5e76", + "measurementCaptureDate": "2025-11-29T16:02:30.178686Z", + "locationHash": "138dfe8e-f8c6-462d-a768-0b7910ba61b0", + "temperature": 22.4, + "humidity": 41.25, + "carbonDioxide": 591.52, + "volatileOrganicCompounds": 87.19, + "particulateMatter1": 4.04, + "particulateMatter2v5": 8.01, + "particulateMatter10": 16, + "formaldehyde": 16.48, + "carbonMonoxide": 591.52, + "ozone": 13.09, + "ammonia": 0.62, + "airflow": 80, + "airIonizationLevel": 563.48, + "oxygen": 20.98, + "radon": 38.51, + "illuminance": 393.17, + "soundLevel": 44.66 } ``` -`Measurements` service can handle various types of measurements. - -| Measurement Type | -| -------------------------------- | -| Temperature | -| Humidity | -| Carbon Dioxide (CO₂) | -| Volatile Organic Compounds (VOC) | -| Particulate Matter 1 (PM1) | -| Particulate Matter 2.5 (PM2.5) | -| Particulate Matter 10 (PM10) | -| Formaldehyde | -| Carbon Monoxide (CO) | -| Ozone (O₃) | -| Ammonia | -| Airflow | -| Air Ionization Level | -| Oxygen (O₂) | -| Radon | -| Illuminance | -| Sound Level | - -## Showcase - -This demo shows how to interact with `Measurements` service via it's endpoints by using `Postman`. - -![image](Assets/MeasurementsShowcase.gif) - ---- - -# Raports - -## Flow - -The following diagram illustrates the flow of generating a new report. First, a request to validate the measurements for the specified day is placed in the message queue (RabbitMQ). This step ensures that there is a complete and accurate dataset available for report generation. Once the validation is complete and successful, another message is added to the queue—this time to initiate the report generation process. The Reports service listens for such messages, consumes them, and begins generating the report. - -![image](Assets/RaportGenerationFlow.png) - -When the Reports service starts generating a report, it requires several sets of data. First, it requests the validated dataset from the Measurements service via gRPC. Next, it retrieves device details from the Devices service, also via gRPC. The service then organizes the collected measurement data into packets, grouping values by categories such as temperature or humidity. These data packets are then sent to the AiAssistant service, where the LLM analyzes and summarizes the information. The analyzed insights are returned to the Reports service, which then finalizes and generates the report. Once completed, the report is stored in Azure Blob Storage, making it accessible for further use. +## 🔧 Emulators Service -![image](Assets/RaportGenerationSteps.png) +Generates simulated measurement data for testing and development purposes. The service listens to device status changes from the Devices service via `Azure Service Bus` and dynamically adjusts measurement generation based on device configuration updates. This enables realistic testing scenarios without requiring physical sensors. -## Examplary raport +The service uses `Quartz.NET` as a CRON-based job scheduler to generate measurements at configured intervals. Scheduling configurations are stored in a `SQL Server` database, allowing flexible adjustment of measurement generation patterns based on location-specific templates. -Here are some pages from generated raport. +### Architecture -

- - -

+When a device status change message is received, the service adjusts measurement generation parameters. Quartz.NET manages periodic jobs that generate measurements according to stored schedules and send them to the Measurements service. -

- - -

+![Emulators Architecture](Assets/emulators_architecture.png) -

- - -

+### Database Diagram +The database stores predefined measurement templates that define realistic value ranges for different locations and environmental conditions. For example, a template might specify typical temperature ranges for a garage. Each template supports customization through parameters like X/Y offsets and device-specific precision settings, allowing fine-tuned control over generated measurement values. -## Showcase +![Emulators Database Schema](Assets/emulators_db_schema.png) -This demo shows how to enqueue raport generation by using `Postman`. +## 📄 Raports Service -![image](Assets/RaportsShowcase.gif) +Generates comprehensive daily raports based on measurement data collected from devices. Raports are created as PDF files using `QuestPDF` and stored in `Azure Blob Storage`, ensuring they remain accessible even when the service is offline. The service uses an event-driven architecture with `Azure Service Bus` via `MassTransit` to orchestrate multi-stage raport generation workflows. -## Azure Blob Storage container +### Architecture -![image](Assets/AzureBlobStorageContainer.png) +The service leverages the `OpenAI API` with GPT models to generate AI-powered summaries of measurement data. Completed raports are stored in `Azure Blob Storage` for long-term accessibility, while raport metadata and configuration are managed in a `SQL Server` database. The raport generation pipeline is built on `Azure Service Bus`, where each processing stage has dedicated topics and subscriptions for reliable message handling. ---- - -# AiAssistant - -Here is code snippet from `AiAssistant` service that generates description based on input data packet. - -```cs -using Microsoft.Extensions.Configuration; -using OllamaSharp; - -namespace AIAssistant.Implementation.General; - -public class OllamaRaportChat -{ - private readonly IConfiguration _configuration; - private readonly OllamaApiClient _client; - - public OllamaRaportChat(IConfiguration configuration) - { - _configuration = configuration; - - string endpoint = _configuration.GetValue("Ollama:Endpoint"); - string model = _configuration.GetValue("Ollama:Model"); - - _client = new OllamaApiClient(endpoint, model); - } - - public async Task HelloWorld() - { - string result = string.Empty; - - var res = _client.GenerateAsync("Hello, who are you?"); - await foreach (var item in res) - { - result += item.Response; - } - - return result; - } - - /// - /// Returns description for given measurement input. - /// - /// - /// - public async Task GenerateDescription(string input) - { - string result = string.Empty; - - string prompt = $"I will provide data for collected measurements for you. " + - $"Your job is to analyze this data and create description of this measurements. " + - $"I only want conclusions in one paragraph, plain text, witout obsolete symbols. Make sure answer is at least 300 words long. Reduce number of digits after decimal point to two. Dont put any notes to reponse." + - $"Examplary answear:" + - $"```" + - $"Temperature measurements were concluded in two rooms ..." + - $"```" + - $"Data: {input}"; - - var res = _client.GenerateAsync(prompt); - await foreach (var item in res) - { - result += item.Response; - } - - return result; - } - -} - -``` +![Raports Architecture](Assets/raports_architecture.png) ---- +### Database Diagram -# Endpoints +The database stores aggregated, sorted, and filtered measurement data for each specific raport. Users can customize raports by selecting which measurement types and locations to include, requiring a flexible schema design. Measurements are organized by location and measurement category to enable efficient querying and raport generation. -## Endpoints +![Raports Database Schema](Assets/raports_db_schema.png) -``Devices`` microservice feature couple of endpoints. They are privided in table below. +### Raport Generation Flow -| Method | URI | Description | Response | -| ------ | -------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | -| GET | `/devices/all` | Retrieve a list of all devices registered in the system. | List of detailed device records including IDs and metadata. | -| GET | `/devices/{ID}` | Retrieve detailed information for a specific device by its unique ID. | Full device data including status and configuration details. | -| GET | `/devices/devicenumber/{DeviceNumber}` | Retrieve detailed information for a device by its unique device number. | Device data with current status and relevant attributes. | -| POST | `/devices/` | Register a new device or notify the system that a device is active (e.g., after restart). | Confirmation of registration along with the created device data. | -| PUT | `/devices/{DeviceNumber}` | Update information for an existing device identified by its device number. | Confirmation of update with the latest device data. | -| DELETE | `/devices/{ID}` | Remove a device from the system by its unique ID. | Confirmation of deletion along with the removed device details. | -| GET | `/health` | Check the health status of the Devices microservice and its dependent services. | Status report indicating service availability and health. | +Raport generation follows a multi-stage pipeline orchestrated through `Azure Service Bus` topics and subscriptions. Each green box in the diagram represents a consumer handling a specific stage of raport processing. If an error occurs at any stage, the raport message is routed to the 'Raport Failed' topic for error handling and monitoring. -## Measurements +![Raport Generation Flow](Assets/raport_generation.png) -`Measurements` microservice feature couple of endpoints. They are privided in table below. +## 🌐 API Gateway -| Method | URI | Description | Response | -| ------ | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | -| GET | `/measurements/all` | Retrieve a list of all devices currently registered in the system. | List of full device details, including IDs and metadata. | -| GET | `/measurements/{ID}` | Retrieve detailed information for a specific device identified by its unique ID. | Full device data including measurements and status. | -| GET | `/measurements/devices/{DeviceNumber}` | Retrieve detailed information for a device using its unique device number. | Device data including recent measurements and status. | -| GET | `/measurements/devices/{DeviceNumber}/day/{DateTime}` | Retrieve measurement data for a specific device for the specified day. | List of measurements recorded by the device on that day. | -| GET | `/measurements/devices/{DeviceNumber}/week/{DateTime}` | Retrieve measurement data for a specific device for the week containing the specified date. | Aggregated measurements for the specified week. | -| GET | `/measurements/devices/{DeviceNumber}/month/{DateTime}` | Retrieve measurement data for a specific device for the month containing the specified date. | Aggregated measurements for the specified month. | -| POST | `/measurements/` | Register or update a device’s active status; used by devices to notify the server they are online or resumed operation. | Confirmation of device registration or update with device data. | -| DELETE | `/measurements/{ID}` | Remove a device from the system by its unique ID. | Confirmation of deletion along with the removed device data. | -| DELETE | `/measurements/devices/{DeviceNumber}` | Remove a device from the system using its unique device number. | Confirmation of deletion along with the removed device data. | -| GET | `/health` | Check the health status of this microservice, including its dependencies. | Status report indicating health and availability of this service and related services. | +Serves as the single entry point for all external requests, routing traffic to the appropriate microservices. Implemented using `YARP` (Yet Another Reverse Proxy), the gateway provides advanced features such as connection throttling, load balancing, and authentication. In this implementation, YARP primarily handles traffic routing and request consolidation, ensuring all client requests flow through a unified interface. -## Raports +### Architecture -`Raports` microservice feature one endpoint. +The gateway acts as a reverse proxy, intercepting incoming requests and forwarding them to the correct backend service based on routing rules. -| Method | URI | Description | Response | -| ------ | ----------------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------- | -| POST | `/raports/enqueuedaily/{DateTime}` | Enqueue a request to validate measurements and generate a daily report for the specified date. | Confirmation of the enqueued request. | +![API Gateway Architecture](Assets/api_gateway_architecture.png) \ No newline at end of file