Architecture — Vue d'ensemble

                     ┌──────────────────────┐
   utilisateurs ────►│ Chargemsi.Portal     │
                     └──────────────────────┘
                              │
                              ▼
                     ┌──────────────────────┐
   opérateurs ─────►│ Chargemsi.Mgmt.Portal│──┐
                     └──────────────────────┘  │   ┌──────────────────────┐
                                               │   │ Chargemsi.Database   │
                              ┌────────────────┼──►│ (OCPP + OCPI schemas)│
                              │                │   └──────────────────────┘
                              │                │              ▲
                     ┌──────────────────────┐  │              │
   bornes (OCPP) ───►│ Chargemsi.Ev.Server  │──┘              │
                     └──────────────────────┘                 │
                                                              │
                     ┌──────────────────────┐                 │
   Gireve (OCPI) ───►│ Chargemsi.OcpiGateway│─────────────────┤
                     └──────────────────────┘                 │
                              ▲                               │
                              │ outbox + retry                │
                     ┌──────────────────────┐                 │
                     │ Chargemsi.Worker     │─────────────────┘
                     │ (Hangfire + OCPI BG) │
                     └──────────────────────┘

Flux clés

1. OCPP : bornes ↔ Chargemsi.Ev.Server via WebSocket. Les transactions, statuts, meter values sont écrits dans OCPPCoreContext.
2. OCPI : Gireve ↔ Chargemsi.OcpiGateway. Le Gateway lit OCPPCoreContext (en lecture seule pour les Locations/Sessions/CDRs) et écrit OcpiDbContext (audit + outbox + credentials).
3. Worker : Chargemsi.Worker dépile l'outbox OCPI et publie vers Gireve, en plus de ses jobs Hangfire historiques (billing, cleanup, etc.).

Base de données

Une seule base SQL Server physique. Deux DbContexts coexistent :

• OCPPCoreContext : entités métier historiques (ChargePoint, Transaction, Tariff…)
• OcpiDbContext : entités OCPI uniquement (Partner, Credential, Session push state, CDR push state, Inbound/Outbound message audit, Command log). Schéma SQL : ocpi.

Les deux contextes ont leurs propres tables de migration : __EFMigrationsHistory pour OCPP et __EFMigrationsHistory_Ocpi pour OCPI. Aucune entité n'est dupliquée.