# Architektur: fetchAnalogeEingaengeService.ts

Dieses Diagramm beschreibt die Datenflussarchitektur des Services `fetchAnalogeEingaengeService.ts`.

## 🎯 Ziel

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

---

## 🧠 Datenfluss

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

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

    CheckMode -->|jsSimulatedProd| ImportjsSimulatedProd[📜 JS-Datei importieren: analogeEingaengeMockData.js]
    ImportjsSimulatedProd --> 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
- `jsSimulatedProd`: 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

---

```mermaid
flowchart TD
  A[.env: NEXT_PUBLIC_CPL_MODE] -->|json| B1[/api/.../APIHandler.ts/]
  A -->|jsSimulatedProd / 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
```