bunnycoder1999/ccms-monitor

Purpose and topology

This repository is a CCMS meter-monitoring system: a Next.js operator UI, a Spring Boot backend, and Kafka-based asynchronous meter-reading transport. The backend integrates with configurable service providers, including Jio, to obtain meter identities/readings, persist them, expose REST APIs, and publish/consume reading events.

Entry points and deployment

• Backend application entry point: ccms_monitor/src/main/java/com/example/ccms_monitor/CcmsApplication.java.

• Frontend is a Next.js App Router application rooted at ccms-frontend/src/app/layout.tsx; unauthenticated entry is ccms-frontend/src/app/login/page.tsx.

• Service/container orchestration is represented by root compose.yaml, ccms_monitor/compose.yaml, ccms-frontend/compose.yaml, and Kafka-specific kafka-docker/docker-compose.yml.

• Both application tiers provide Docker build definitions: ccms_monitor/Dockerfile and ccms-frontend/Dockerfile.

Backend API and integration boundary

Spring MVC controllers form the HTTP boundary for meter serial numbers, readings, Jio integration, and related read operations:

ccms_monitor/src/main/java/com/example/ccms_monitor/controller/MeterSerialNoController.java,

ccms_monitor/src/main/java/com/example/ccms_monitor/controller/MeterReadingController.java,

and ccms_monitor/src/main/java/com/example/ccms_monitor/controller/JioController.java.

Service-layer orchestration separates provider/API operations from transport: service/JioService.java, service/DataFetchService.java, and service/MeterService.java.

Provider authentication and scheduled ingestion

Provider definitions are configuration-driven through config/ServiceProvider.java and config/ServiceProviderConfig.java. Authentication handling is isolated in service/AuthService.java, backed by config/AuthProperties.java. Periodic retrieval is initiated by scheduler/ScheduledTasks.java, which drives the fetch-to-processing pipeline rather than requiring UI-triggered ingestion.

Persistence model

Meter serial numbers and readings are distinct domain entities:

model/MeterSerialNo.java and model/MeterReading.java.

Their repositories, repository/MeterSerialNoRepo.java and repository/MeterReadingRepo.java, define the database boundary used by services/controllers. Backend runtime configuration, including infrastructure connection settings, is centralized in src/main/resources/application.properties.

Kafka event pipeline

Kafka decouples reading production from downstream consumption. kafka/KafkaProducerService.java publishes kafka/dto/MeterReadingEvent.java; kafka/KafkaConsumerService.java receives events for processing/persistence workflows. Broker/client setup belongs in config/KafkaConfig.java. Kafka is external infrastructure supplied by kafka-docker/docker-compose.yml.

Frontend application flow

Authenticated navigation and shared shell are defined in ccms-frontend/src/app/(authenticated)/layout.tsx, with operational pages for the dashboard, meter IDs, and meter readings:

dashboard/page.tsx, meter-ids/page.tsx, and meter-readings/page.tsx.

The UI fetches backend data through service modules—services/axiosInstance.ts, services/meterService.ts, and services/meterReadingService.ts—rather than directly from pages.

Client state and presentation boundaries

React Query is installed at the app boundary through providers/QueryProvider.tsx; resource-specific query behavior is encapsulated in hooks/useMeterQueries.ts and hooks/useMeterReadingQueries.ts. Tables and fetch controls (components/MeterTable.tsx, components/MeterReadingTable.tsx, components/MeterFetchForm.tsx) render and trigger operational workflows. providers/ThemeProvider.tsx and components/app-sidebar.tsx provide cross-cutting UI state/navigation.