Appearance
Runtime Request Flow
Verified runtime/reporting anchorsFlow synthesis
Related pages:
Verified anchors behind this flow
NGB.PropertyManagement.Api/Program.csNGB.Runtime/Documents/DocumentService.csNGB.Runtime/Reporting/ReportEngine.csNGB.Runtime/Reporting/ReportExecutionPlanner.csNGB.PostgreSql/Reporting/PostgresReportDatasetCatalog.csNGB.PostgreSql/Reporting/IPostgresReportDatasetSource.csNGB.PostgreSql/Reporting/PostgresReportSqlBuilder.csNGB.PostgreSql/Reporting/PostgresReportDatasetExecutor.cs
Architecture flow
The platform is designed so that hosts stay thin and runtime orchestration stays central. The following diagram shows the typical business flow through NGB.
Document flow, simplified
- A host composes the platform with
AddNgbRuntime(), PostgreSQL provider registration, and vertical module registration. - HTTP enters through the host’s ASP.NET Core pipeline.
- Request handling resolves platform services.
DocumentServiceperforms metadata-driven CRUD/lifecycle orchestration.- Runtime delegates to posting/derivation/relationship/effects services where needed.
- Persistence abstractions and PostgreSQL implementations perform durable reads/writes.
- The host returns DTOs/UI-ready payloads.
Reporting flow, simplified
- A report request reaches runtime.
ReportEngineresolves the report definition and effective request/layout.ReportExecutionPlannerbuilds aReportQueryPlan.- Runtime delegates execution to the plan executor.
- For PostgreSQL-backed composable reporting, the dataset catalog resolves the dataset binding.
- SQL builder converts the logical plan into concrete SQL.
- Dataset executor runs SQL through the active unit of work connection/transaction.
- Runtime shapes the result into a sheet/response DTO.
Why this split matters
The planner is not the SQL builder.
The SQL builder is not the report engine.
The host is not the runtime.
That separation is what keeps NGB extensible without making every host/provider re-implement orchestration logic.