CPLv4.0/docs/architecture.md

Architektur: fetchAnalogeEingaengeService.ts

Dieses Diagramm beschreibt die Datenflussarchitektur des Services fetchAnalogeEingaengeService.ts.

🎯 Ziel

Egal ob json, jsmock oder production-Modus – der Service gibt immer ein einheitliches JSON-Objekt zurück.

---

🧠 Datenfluss

flowchart TD
    Start[fetchAnalogeEingaengeService aufgerufen] --> CheckMode{CPL Mode}

    CheckMode -->|json| FetchJSON[📄 JSON-Datei laden: /CPLmockData/SERVICE/analogeEingaengeMockData.json]
    FetchJSON --> ReturnJSON1[✅ JSON zurückgeben]

    CheckMode -->|jsmock| ImportJSMock[📜 JS-Datei importieren: analogeEingaengeMockData.js]
    ImportJSMock --> ParseMock[🔁 parseWindowData]
    ParseMock --> ReturnJSON2[✅ JSON zurückgeben]

    CheckMode -->|production| LoadCGI[🌐 JS vom Gerät laden: /CPL/SERVICE/analogeEingaenge.js]
    LoadCGI --> ParseCGI[🔁 parseWindowData]
    ParseCGI --> ReturnJSON3[✅ JSON zurückgeben]

    style ReturnJSON1 fill:#d4f4dd
    style ReturnJSON2 fill:#d4f4dd
    style ReturnJSON3 fill:#d4f4dd

Architecture

In dieser Anwendung werden drei Betriebsmodi unterstützt:

• json: lädt Mockdaten über API-Handler
• jsmock: lädt JS-Dateien mit window.win_* Variablen
• production: lädt Platzhalterdaten vom echten Gerät (CPL)

Ziel: Alle Services liefern immer standardisiertes JSON-Objekt
➡️ Redux und UI bleiben unabhängig von Datenquelle

---

flowchart TD
  A[.env: NEXT_PUBLIC_CPL_MODE] -->|json| B1[/api/.../APIHandler.ts/]
  A -->|jsmock / production| B2[window.win_* Variablen aus JS-Datei]
  B1 --> C[fetchXYZService.ts]
  B2 --> C
  C --> D[Normiertes JSON-Objekt]
  D --> E[Redux Thunk]
  E --> F[Redux Slice]
  F --> G[UI-Komponente z.B. Tabelle]

  subgraph Service-Schicht
    C
  end

  subgraph Redux-Schicht
    E --> F
  end

  subgraph UI-Schicht
    G
  end