#Kontextsystem-Übersicht

Das Kontextsystem der NocoBase Workflow-Engine ist in drei Ebenen unterteilt, die jeweils unterschiedlichen Geltungsbereichen entsprechen. Die angemessene Verwendung ermöglicht die flexible gemeinsame Nutzung und Isolierung von Diensten, Konfigurationen und Daten, was die Wartbarkeit und Erweiterbarkeit des Geschäfts verbessert.

• FlowEngineContext (Globaler Kontext): Global eindeutig, alle Modelle und Workflows können darauf zugreifen; geeignet für die Registrierung globaler Dienste, Konfigurationen usw.
• FlowModelContext (Modellkontext): Wird für die gemeinsame Nutzung des Kontextes innerhalb eines Modellbaums verwendet; Untermodelle delegieren automatisch an den Kontext des Elternmodells, unterstützt das Überschreiben bei Namensgleichheit; geeignet für die Isolierung von Logik und Daten auf Modellebene.
• FlowRuntimeContext (Workflow-Laufzeitkontext): Wird bei jeder Workflow-Ausführung erstellt und durchläuft den gesamten Workflow-Laufzeitzyklus; geeignet für die Datenübertragung, Variablenspeicherung und Aufzeichnung des Laufzeitstatus im Workflow. Unterstützt die zwei Modi mode: 'runtime' | 'settings', die jeweils dem Laufzeitstatus und dem Konfigurationsstatus entsprechen.

Alle FlowEngineContext (Globaler Kontext), FlowModelContext (Modellkontext), FlowRuntimeContext (Workflow-Laufzeitkontext) usw. sind Unterklassen oder Instanzen von FlowContext.

#🗂️ Hierarchiediagramm

FlowEngineContext (Globaler Kontext)
│
├── FlowModelContext (Modellkontext)
│     ├── Unter-FlowModelContext (Untermodell)
│     │     ├── FlowRuntimeContext (Workflow-Laufzeitkontext)
│     │     └── FlowRuntimeContext (Workflow-Laufzeitkontext)
│     └── FlowRuntimeContext (Workflow-Laufzeitkontext)
│
├── FlowModelContext (Modellkontext)
│     └── FlowRuntimeContext (Workflow-Laufzeitkontext)
│
└── FlowModelContext (Modellkontext)
      ├── Unter-FlowModelContext (Untermodell)
      │     └── FlowRuntimeContext (Workflow-Laufzeitkontext)
      └── FlowRuntimeContext (Workflow-Laufzeitkontext)

• FlowModelContext kann über einen Proxy-Mechanismus (delegate) auf die Eigenschaften und Methoden von FlowEngineContext zugreifen, um die gemeinsame Nutzung globaler Fähigkeiten zu realisieren.
• Der FlowModelContext eines Untermodells kann über einen Proxy-Mechanismus (delegate) auf den Kontext des Elternmodells zugreifen (synchrone Beziehung) und unterstützt das Überschreiben bei Namensgleichheit.
• Asynchrone Eltern-Kind-Modelle bauen keine Proxy-Beziehung (delegate) auf, um Status-Kontaminationen zu vermeiden.
• FlowRuntimeContext greift immer über einen Proxy-Mechanismus (delegate) auf seinen entsprechenden FlowModelContext zu, gibt jedoch keine Informationen nach oben zurück.

#🧭 Laufzeitstatus und Konfigurationsstatus (mode)

FlowRuntimeContext unterstützt zwei Modi, die durch den Parameter mode unterschieden werden:

• mode: 'runtime' (Laufzeitstatus): Wird für die tatsächliche Ausführungsphase des Workflows verwendet; Eigenschaften und Methoden geben reale Daten zurück. Beispiel:

  console.log(runtimeCtx.steps.step1.result); // 42

• mode: 'settings' (Konfigurationsstatus): Wird für die Design- und Konfigurationsphase des Workflows verwendet; der Zugriff auf Eigenschaften gibt Variablen-Template-Strings zurück, was die Auswahl von Ausdrücken und Variablen erleichtert. Beispiel:

  console.log(settingsCtx.steps.step1.result); // '{{ ctx.steps.step1.result }}'

Dieses Dual-Modus-Design stellt sowohl die Datenverfügbarkeit zur Laufzeit sicher als auch die einfache Variablenreferenzierung und Ausdrucksgenerierung bei der Konfiguration, was die Flexibilität und Benutzerfreundlichkeit der Workflow-Engine verbessert.

#🤖 Kontextinformationen für Tools/Große Sprachmodelle

In bestimmten Szenarien (z. B. RunJS-Code-Bearbeitung im JS*Model, AI-Coding) muss der „Aufrufer“ ohne Code-Ausführung Folgendes verstehen:

• Welche statischen Fähigkeiten unter dem aktuellen ctx vorhanden sind (API-Dokumentation, Parameter, Beispiele, Dokumentationslinks usw.).
• Welche optionalen Variablen in der aktuellen Oberfläche/im Laufzeitstatus vorhanden sind (z. B. dynamische Strukturen wie „Aktueller Datensatz“, „Aktueller Popup-Datensatz“ usw.).
• Ein Snapshot mit geringem Volumen der aktuellen Laufzeitumgebung (für Prompts).

#1) await ctx.getApiInfos(options?) (Statische API-Informationen)

#2) await ctx.getVarInfos(options?) (Variablenstruktur-Informationen)

• Aufbau der Variablenstruktur basierend auf defineProperty(...).meta (einschließlich Meta-Factory).
• Unterstützt path-Zuschneiden und maxDepth-Tiefenkontrolle.
• Wird nur bei Bedarf nach unten ausgeklappt.

Häufig verwendete Parameter:

• maxDepth: Maximale Ausklapptiefe (Standard 3).
• path: string | string[]: Zuschneiden, gibt nur den Teilbaum des angegebenen Pfads aus.

#3) await ctx.getEnvInfos() (Snapshot der Laufzeitumgebung)

Knotenstruktur (vereinfacht):

type EnvNode = {
  description?: string;
  getVar?: string; // Kann direkt für await ctx.getVar(getVar) verwendet werden, beginnt mit "ctx."
  value?: any; // Aufgelöster/serialisierbarer statischer Wert
  properties?: Record<string, EnvNode>;
};