automation unification implemented
This commit is contained in:
ValueOn AG
parent
e354431016
commit
7d1a957f77
2 changed files with 139 additions and 53 deletions
|
|
@ -1,6 +1,6 @@
|
|||
<!-- status: canonical -->
|
||||
<!-- lastReviewed: 2026-04-05 -->
|
||||
<!-- verifiedAgainst: gateway (codebase audit 2026-04-05) -->
|
||||
<!-- lastReviewed: 2026-04-06 -->
|
||||
<!-- verifiedAgainst: gateway (codebase audit 2026-04-06, coreTools split) -->
|
||||
|
||||
# AI Agent & Knowledge Store
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ Pro Request propagiert der **ServiceCenterContext** u. a. `userId`, `mandateId`,
|
|||
|
||||
- **Einstieg:** `AgentService.runAgent` (`mainServiceAgent.py`) — baut die Tool Registry, optional Anreicherung des Prompts mit Datei-Metadaten/`FileContentIndex`, startet `runAgentLoop` (`agentLoop.py`).
|
||||
- **Loop:** `runAgentLoop` — `ConversationManager` + Systemprompt; **pro Runde:** optional RAG via `buildRagContextFn`, Budget-Check, **Progressive Summarization** bei Bedarf (`ConversationManager`, Modell-Operation `DATA_ANALYSE`), dann `AiCallRequest` mit `OperationTypeEnum.AGENT`, `messages`, `tools`.
|
||||
- **Tool Registry:** `_registerCoreTools` in `mainServiceAgent.py` registriert die Kern-Tools; **`ActionToolAdapter`** registriert alle Workflow-Actions mit `dynamicMode=True` als zusätzliche Tools (`method_action` → intern `executeAction`).
|
||||
- **Tool Registry:** `registerCoreTools` in `coreTools/registerCore.py` delegiert an domänenspezifische Module (`_workspaceTools`, `_connectionTools`, `_dataSourceTools`, `_documentTools`, `_mediaTools`, `_featureSubAgentTools`, `_crossWorkflowTools`); **`ActionToolAdapter`** registriert alle Workflow-Actions mit `dynamicMode=True` als zusätzliche Tools (`method_action` → intern `executeAction`).
|
||||
- **Parallele Ausführung:** In `_executeToolCalls` werden als **`readOnly=True`** markierte Tool-Calls parallel (`asyncio.gather`), schreibende/übrige sequentiell — vermeidet Race Conditions bei zustandsändernden Tools.
|
||||
- **Budget:** `AgentConfig.maxCostCHF` — vor jeder Runde Abgleich mit Workflow-Kosten; bei Überschreitung Status `budgetExceeded` und abschliessender Fortschritts-Text (`FINAL`).
|
||||
- **Rundenlimit:** `AgentConfig.maxRounds` (Default 25); bei Erreichen während `running` → Status `maxRoundsReached` und Fortschritts-Zusammenfassung.
|
||||
|
|
@ -59,7 +59,7 @@ Tools sind registrierte Handler mit JSON-Schema für Argumente, **`readOnly`-Fla
|
|||
|
||||
Zusätzlich zu den unten genannten **Kern-Tools** existieren **dynamische Tools** aus dem Workflow-System: `ActionToolAdapter` liest `methodDiscovery.methods` und registriert jede Action mit `dynamicMode=True` unter einem zusammengesetzten Namen (`{methodShort}_{actionName}`); im Adapter sind diese derzeit **alle als nicht-readOnly** registriert.
|
||||
|
||||
### Kern-Tools (registriert in `_registerCoreTools`, 40 Stück)
|
||||
### Kern-Tools (registriert via `registerCoreTools` → `coreTools/`, 40 Stück)
|
||||
|
||||
**Workspace / Dateien**
|
||||
|
||||
|
|
@ -204,7 +204,15 @@ Erweiterte Hilfen (z. B. **`readSection`**, Caching) für selektives Lesen sind
|
|||
| Datei | Rolle |
|
||||
|-------|--------|
|
||||
| `gateway/modules/serviceCenter/registry.py` | Registrierung `agent`, `knowledge`, Dependencies, `objectKey` |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/mainServiceAgent.py` | `AgentService`, Tool-Registrierung, `runAgent`, DataSource/Neutralize-Hooks |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/mainServiceAgent.py` | `AgentService`, `runAgent`, Prompt-Enrichment, Registry-Orchestrierung |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/coreTools/registerCore.py` | Orchestrator: delegiert Tool-Registrierung an Domänen-Module |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/coreTools/_workspaceTools.py` | Dateien, Ordner, Web, Übersetzung |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/coreTools/_connectionTools.py` | Externe Connections, Upload, Mail |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/coreTools/_dataSourceTools.py` | DataSource Browse/Search/Download |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/coreTools/_documentTools.py` | Container, Content-Objects, Vision |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/coreTools/_mediaTools.py` | Rendering, TTS, STT, Bildgenerierung, Charts, Neutralize, Code |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/coreTools/_featureSubAgentTools.py` | Feature Data Sub-Agent (queryFeatureInstance) |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/coreTools/_crossWorkflowTools.py` | Workflow-Historie, Messages, `_CORE_ONLY_TOOLS`-Tagging |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/agentLoop.py` | ReAct-Loop, Budget, RAG-Injektion, Tool-Dispatch, Summaries |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/toolRegistry.py` | Registrierung, Dispatch, `readOnly`, Function-Calling-Format |
|
||||
| `gateway/modules/serviceCenter/services/serviceAgent/conversationManager.py` | Kontextfenster, Summarization, Systemprompt |
|
||||
|
|
|
|||
|
|
@ -18,6 +18,8 @@ PowerOn hat drei teilweise ueberlappende Automatisierungssysteme: Automation v1
|
|||
- Klare Datenmodelle mit definierten State Machines als stabile, erweiterbare Grundlage
|
||||
- Klare Trennung von Mandant/Feature/Feature-Instanz und zugehoeriger RBAC-Logik
|
||||
- Skalierbare AI-Tool-Architektur mit Toolboxes und Sub-Agents fuer 50-100+ Tools
|
||||
- Einheitlicher **`Auto`-Prefix** fuer alle neuen Datenobjekte (z.B. `AutoWorkflow`, `AutoVersion`, `AutoRun`) -- klare Erkennbarkeit in der Codebase
|
||||
- **Greenfield-Migration:** Neue DB (`poweron_graphicaleditor`), kein Schema-Umbau auf `poweron_automation2`. Alte DB bleibt als Archiv bestehen, Daten werden **nicht** migriert
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -46,7 +48,7 @@ Die `workflows/methods/` Library (methodAi, methodOutlook, methodSharepoint, etc
|
|||
|
||||
| Tool-Typ | Registrierung | Nutzung |
|
||||
|----------|--------------|---------|
|
||||
| **Core Tools** (40: readFile, webSearch, sendMail, etc.) | `_registerCoreTools()` | Workspace Agent, CommCoach Agent |
|
||||
| **Core Tools** (40: readFile, webSearch, sendMail, etc.) | `registerCoreTools()` via `coreTools/` | Workspace Agent, CommCoach Agent |
|
||||
| **Action Tools** (dynamicMode Actions) | `ActionToolAdapter.registerAll()` | Workspace Agent (toolSet-uebergreifend) |
|
||||
| **Graph Node Types** (ai.prompt, email.checkEmail, etc.) | `STATIC_NODE_TYPES` in `nodeDefinitions/` | Automation2 `executeGraph` |
|
||||
|
||||
|
|
@ -121,7 +123,7 @@ Die `workflows/methods/` Library (methodAi, methodOutlook, methodSharepoint, etc
|
|||
| 2 | **Node Palette** -- abgeleitet aus Toolbox-Registry, jede Action kann als Node exponiert werden | besteht |
|
||||
| 3 | **AI Chat Sidebar** -- Agent mit Toolbox `"workflow"` fuer Graph-Manipulation | neu |
|
||||
| 4 | **UDB Integration** -- UnifiedDataBar im Editor | neu |
|
||||
| 5 | **Tracing/Debug Log** -- RunStepLog mit Input-Snapshot, Duration, Error pro Node | zu erweitern |
|
||||
| 5 | **Tracing/Debug Log** -- AutoStepLog mit Input-Snapshot, Duration, Error pro Node | zu erweitern |
|
||||
| 6 | **Test Runner** -- Visual Highlighting, Step-by-Step, AI-assisted Debugging | zu erweitern |
|
||||
| 7 | **Version Management** -- Draft/Published Lifecycle | neu |
|
||||
|
||||
|
|
@ -485,13 +487,15 @@ Main Agent (Toolboxes: core, ai, datasources, ...)
|
|||
|
||||
### Entitaeten
|
||||
|
||||
**Naming-Konvention:** Alle Datenobjekte tragen den Prefix **`Auto`** fuer eindeutige Erkennbarkeit in der Codebase. Enums ohne Prefix (domainweit gueltig).
|
||||
|
||||
```python
|
||||
class WorkflowStatus(str, Enum):
|
||||
class AutoWorkflowStatus(str, Enum):
|
||||
DRAFT = "draft"
|
||||
PUBLISHED = "published"
|
||||
ARCHIVED = "archived"
|
||||
|
||||
class Workflow(PowerOnModel):
|
||||
class AutoWorkflow(PowerOnModel):
|
||||
id: str
|
||||
mandateId: str
|
||||
featureInstanceId: str
|
||||
|
|
@ -500,22 +504,24 @@ class Workflow(PowerOnModel):
|
|||
tags: List[str] = []
|
||||
isTemplate: bool = False
|
||||
templateSourceId: Optional[str] # geklont von diesem Template
|
||||
templateScope: Optional[str] # user | instance | mandate | system (siehe Abschnitt Workflow-Vorlagen)
|
||||
sharedReadOnly: bool = False # Freigabe: Nutzung ohne strukturelle Aenderung
|
||||
currentVersionId: Optional[str] # aktive/published Version
|
||||
active: bool = True # Scheduler-enabled
|
||||
eventId: Optional[str] # APScheduler Job-ID (v1-Pattern)
|
||||
|
||||
class WorkflowVersion(PowerOnModel):
|
||||
class AutoVersion(PowerOnModel):
|
||||
id: str
|
||||
workflowId: str # FK -> Workflow
|
||||
workflowId: str # FK -> AutoWorkflow
|
||||
versionNumber: int # auto-increment
|
||||
status: WorkflowStatus # draft | published | archived
|
||||
status: AutoWorkflowStatus # draft | published | archived
|
||||
graph: Dict[str, Any] # { nodes: [...], connections: [...] }
|
||||
invocations: List[Dict[str, Any]] # Entry-Points (manual, schedule, webhook, form)
|
||||
publishedAt: Optional[float]
|
||||
publishedBy: Optional[str]
|
||||
```
|
||||
|
||||
### State Machine: WorkflowVersion.status
|
||||
### State Machine: AutoVersion.status
|
||||
|
||||
```
|
||||
+-------+
|
||||
|
|
@ -532,14 +538,14 @@ class WorkflowVersion(PowerOnModel):
|
|||
| ARCHIVED |--> re-publish (-> PUBLISHED)
|
||||
+-----------+
|
||||
|
||||
Invariante: Pro Workflow maximal 1 Version mit status=PUBLISHED.
|
||||
Scheduler nutzt immer die PUBLISHED Version.
|
||||
Invariante: Pro AutoWorkflow maximal 1 AutoVersion mit status=PUBLISHED.
|
||||
Scheduler nutzt immer die PUBLISHED AutoVersion.
|
||||
```
|
||||
|
||||
### Run-Modell
|
||||
|
||||
```python
|
||||
class RunStatus(str, Enum):
|
||||
class AutoRunStatus(str, Enum):
|
||||
PENDING = "pending"
|
||||
RUNNING = "running"
|
||||
PAUSED = "paused"
|
||||
|
|
@ -547,11 +553,11 @@ class RunStatus(str, Enum):
|
|||
FAILED = "failed"
|
||||
CANCELLED = "cancelled"
|
||||
|
||||
class WorkflowRun(PowerOnModel):
|
||||
class AutoRun(PowerOnModel):
|
||||
id: str
|
||||
workflowId: str # FK -> Workflow
|
||||
versionId: str # FK -> WorkflowVersion
|
||||
status: RunStatus
|
||||
workflowId: str # FK -> AutoWorkflow
|
||||
versionId: str # FK -> AutoVersion
|
||||
status: AutoRunStatus
|
||||
trigger: Dict[str, Any] # { type: "manual"|"schedule"|"webhook"|..., metadata }
|
||||
startedAt: float
|
||||
completedAt: Optional[float]
|
||||
|
|
@ -563,7 +569,7 @@ class WorkflowRun(PowerOnModel):
|
|||
costCredits: Optional[float] # Aggregierte Credit-Kosten
|
||||
```
|
||||
|
||||
### State Machine: WorkflowRun.status
|
||||
### State Machine: AutoRun.status
|
||||
|
||||
```
|
||||
+---------+
|
||||
|
|
@ -584,28 +590,28 @@ class WorkflowRun(PowerOnModel):
|
|||
+---------+
|
||||
|
||||
Pause-Gruende:
|
||||
- input.* Node -> HumanTask erstellt
|
||||
- input.* Node -> AutoTask erstellt
|
||||
- email.checkEmail -> EmailWait (Background Poller)
|
||||
Cancel:
|
||||
- Manuell durch User
|
||||
- Timeout bei HumanTask (expiresAt)
|
||||
- Timeout bei AutoTask (expiresAt)
|
||||
```
|
||||
|
||||
### RunStepLog und HumanTask
|
||||
### AutoStepLog und AutoTask
|
||||
|
||||
```python
|
||||
class StepStatus(str, Enum):
|
||||
class AutoStepStatus(str, Enum):
|
||||
RUNNING = "running"
|
||||
COMPLETED = "completed"
|
||||
FAILED = "failed"
|
||||
SKIPPED = "skipped"
|
||||
|
||||
class RunStepLog(PowerOnModel):
|
||||
class AutoStepLog(PowerOnModel):
|
||||
id: str
|
||||
runId: str # FK -> WorkflowRun
|
||||
runId: str # FK -> AutoRun
|
||||
nodeId: str # Node-ID im Graph
|
||||
nodeType: str # z.B. "ai.prompt", "email.checkEmail"
|
||||
status: StepStatus
|
||||
status: AutoStepStatus
|
||||
inputSnapshot: Dict[str, Any] # Parameters + Upstream-Daten bei Execution
|
||||
output: Optional[Dict[str, Any]]
|
||||
error: Optional[str]
|
||||
|
|
@ -615,21 +621,21 @@ class RunStepLog(PowerOnModel):
|
|||
tokensUsed: Optional[int]
|
||||
retryCount: int = 0
|
||||
|
||||
class TaskStatus(str, Enum):
|
||||
class AutoTaskStatus(str, Enum):
|
||||
PENDING = "pending"
|
||||
COMPLETED = "completed"
|
||||
CANCELLED = "cancelled"
|
||||
EXPIRED = "expired"
|
||||
|
||||
class HumanTask(PowerOnModel):
|
||||
class AutoTask(PowerOnModel):
|
||||
id: str
|
||||
runId: str # FK -> WorkflowRun
|
||||
workflowId: str # FK -> Workflow (Convenience-FK)
|
||||
runId: str # FK -> AutoRun
|
||||
workflowId: str # FK -> AutoWorkflow (Convenience-FK)
|
||||
nodeId: str
|
||||
nodeType: str # input.approval, input.form, etc.
|
||||
config: Dict[str, Any] # Node-Parameter (Formular-Felder, Approval-Text)
|
||||
assigneeId: str
|
||||
status: TaskStatus
|
||||
status: AutoTaskStatus
|
||||
result: Optional[Dict[str, Any]]
|
||||
expiresAt: Optional[float]
|
||||
```
|
||||
|
|
@ -638,7 +644,7 @@ class HumanTask(PowerOnModel):
|
|||
|
||||
```
|
||||
+------------------+ +----------------------+
|
||||
| Workflow | 1---N | WorkflowVersion |
|
||||
| AutoWorkflow | 1---N | AutoVersion |
|
||||
|------------------| |----------------------|
|
||||
| id | | id |
|
||||
| mandateId | | workflowId (FK) |
|
||||
|
|
@ -651,7 +657,7 @@ class HumanTask(PowerOnModel):
|
|||
| active | +----------+-----------+
|
||||
| eventId | | 1:N
|
||||
+------------------+ +----------v-----------+
|
||||
| WorkflowRun |
|
||||
| AutoRun |
|
||||
|----------------------|
|
||||
| id |
|
||||
| workflowId (FK) |
|
||||
|
|
@ -668,7 +674,7 @@ class HumanTask(PowerOnModel):
|
|||
+-------------+ +-----------+
|
||||
v v
|
||||
+------------------+ +------------------+
|
||||
| RunStepLog | | HumanTask |
|
||||
| AutoStepLog | | AutoTask |
|
||||
|------------------| |------------------|
|
||||
| runId (FK) | | runId (FK) |
|
||||
| nodeId | | workflowId (FK) |
|
||||
|
|
@ -684,9 +690,75 @@ class HumanTask(PowerOnModel):
|
|||
|
||||
---
|
||||
|
||||
## Workflow-Vorlagen (Template-Management)
|
||||
|
||||
Vorlagen sind spezielle AutoWorkflows (oder dedizierte Template-Entitaeten mit Referenz auf eine `AutoVersion`), die als Wiederverwendbare Startpunkte dienen. Das Template-Management ist Teil der Automation-Unification: ein einheitliches Modell fuer Erstellung, Scope, Bootstrap und Freigabe.
|
||||
|
||||
### Anforderungen (Produktlogik)
|
||||
|
||||
| Aspekt | Regel |
|
||||
|--------|--------|
|
||||
| **Zugehoerigkeit** | Jede Vorlage gehoert zu genau einer **Feature-Instanz** (`featureInstanceId`); der **Ersteller** entspricht wie bei allen Modellen den systemseitig gepflegten Feldern der **Basis-Klasse** (z.B. `sysCreatedBy`). |
|
||||
| **Scope** | Jede Vorlage hat einen **Template-Scope**: `user`, `instance`, `mandate`, `system`. Der Scope steuert Sichtbarkeit, RBAC und ob Inhalte gemeinsam nutzbar oder nur persoenlich sind. |
|
||||
| **Default bei Erstellung** | Ohne explizite Abweichung: **Instanz** = Instanz des aktuellen Users (Kontext der UI/API); **Scope** = `user` (persoenliche Vorlage). |
|
||||
| **Bootstrap** | Initiale Plattform-Vorlagen werden beim Bootstrap mit Scope **`system`** angelegt, technisch durch den User **`sysadmin`** (oder dedizierter System-Principal), damit sie mandantenuebergreifend policy-konform verwaltbar sind. |
|
||||
| **Teilen (1) -- Kopie** | Eine Vorlage (oder Snapshot einer Version) kann als **Kopie** an einen anderen User gesendet werden. Die Kopie ist eine **neue** Vorlage im Scope `user` des Empfaengers; Ersteller-Felder der Basis-Klasse zeigen den Empfaenger, plus Instanz-Kontextregeln beim Import. |
|
||||
| **Teilen (2) -- Freigabe** | Statt Kopie: **Freigabe zur gemeinsamen Nutzung** mit Scope **`instance`** oder **`mandate`**. Alle Berechtigten duerfen die Vorlage **nutzen** (z.B. Workflow daraus ableiten, starten); sie duerfen die **freigegebene Vorlage selbst nicht aendern** (kein Update/Delete der Canonical-Definition ausser fuer Rollen mit explizitem Schreibrecht laut unten). |
|
||||
|
||||
### RBAC nach Rolle (Feature- und Plattform-Rollen)
|
||||
|
||||
**Regel:** **CRUD** nur auf der Spalte, die zum **Template-Scope** der Vorlage passt (und bei `user` nur auf **eigenen** Vorlagen). Alle anderen Spalten: **R** = lesen und nutzen, **keine** Aenderung der Vorlagen-Definition.
|
||||
|
||||
| Rolle | `user` (nur **eigene**) | `instance` | `mandate` | `system` |
|
||||
|-------|-------------------------|------------|-----------|----------|
|
||||
| Alle Rollen (mit Feature-Zugriff) | CRUD | R | R | R |
|
||||
| Instance Admin | CRUD | CRUD | R | R |
|
||||
| Mandate Admin | CRUD | CRUD | CRUD | R |
|
||||
|
||||
**Sysadmin:** **CRUD** auf `system`-Vorlagen; fuer `user` / `instance` / `mandate` nach Plattform-Policy (Break-Glass / Support).
|
||||
|
||||
**Hinweis:** Abbildung auf `AccessRule` (DATA + RESOURCE „instanziieren/ausfuehren“) in der Implementierung.
|
||||
|
||||
### Datenmodell-Erweiterung (Vorschlag)
|
||||
|
||||
Ergänzung zum `AutoWorkflow`-Modell (bereits `isTemplate`, `templateSourceId`):
|
||||
|
||||
```python
|
||||
class AutoTemplateScope(str, Enum):
|
||||
USER = "user" # persoenlich; „eigen“ = Ersteller laut Basis-Klasse (z.B. sysCreatedBy)
|
||||
INSTANCE = "instance" # gemeinsam nutzbar auf Feature-Instanz
|
||||
MANDATE = "mandate" # gemeinsam nutzbar im Mandanten
|
||||
SYSTEM = "system" # plattformweit, verwaltet durch sysadmin
|
||||
|
||||
class AutoWorkflow(PowerOnModel):
|
||||
# ... bestehende Felder ...
|
||||
isTemplate: bool = False
|
||||
templateSourceId: Optional[str]
|
||||
templateScope: Optional[AutoTemplateScope] # gesetzt wenn isTemplate True
|
||||
sharedReadOnly: bool = False # True bei Freigabe: Nutzer duerfen nicht mutieren
|
||||
```
|
||||
|
||||
- **Kopie an User:** neuer `AutoWorkflow` mit `templateSourceId` = Quelle, `templateScope=USER`; Ersteller = Empfaenger ueber Basis-Klassen-Felder beim Anlegen.
|
||||
- **Freigabe:** Scope auf `INSTANCE` oder `MANDATE` setzen, `sharedReadOnly=True` fuer Nicht-Admins; Admins mit CRUD laut Matrix duerfen weiterhin Pflege betreiben.
|
||||
|
||||
### Konsistenz: ist die Logik stimmig?
|
||||
|
||||
**Ja, insgesamt konsistent**, wenn diese Punkte explizit gemacht werden:
|
||||
|
||||
1. **`my` = nur eigene User-Scope-Vorlagen** (Abgleich Ersteller mit aktuellem User ueber Basis-Felder, z.B. `sysCreatedBy`). Ohne diese Einschraenkung waere „alle Rollen: CRUD“ auf `user`-Scope widerspruechlich.
|
||||
2. **„R“ bei Freigabe** umfasst fachlich **Lesen + Nutzen** (Instanziierung/Ableiten); **kein Update/Delete** der Canonical-Vorlage fuer Nicht-Admins -- passt zur Anforderung „nur nutzen, nicht veraendern“.
|
||||
3. **Instance Admin vs. Mandate Admin:** Die Matrix codiert die Grenze: **CRUD** nur in der passenden Scope-Spalte; kreuzweise immer **R**.
|
||||
4. **Sysadmin und `system`-Bootstrap:** Konsistent, solange Bootstrap-Vorlagen eindeutig `templateScope=SYSTEM` und von `sysadmin` stammen; normale User koennen `system`-Vorlagen nicht umschreiben.
|
||||
5. **Begriff „alle Rollen“:** Im Kontext **Feature-Instanz** natürlich
|
||||
|
||||
**Viewer**-Rollen Vorlagen haben keine Rechte hier.
|
||||
**Kopie senden** kann an einen user sein, den ich mit meinen berechtigungen "sehe"
|
||||
|
||||
---
|
||||
|
||||
## Graph-Struktur und Node-Definitionen
|
||||
|
||||
### Graph-Schema (innerhalb WorkflowVersion.graph)
|
||||
### Graph-Schema (innerhalb AutoVersion.graph)
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -720,7 +792,7 @@ class HumanTask(PowerOnModel):
|
|||
| `flow.ifElse` | -- | -- | -- (FlowExecutor) |
|
||||
| `flow.switch` | -- | -- | -- (FlowExecutor) |
|
||||
| `flow.loop` | -- | -- | -- (FlowExecutor) |
|
||||
| `input.*` | -- | -- | -- (InputExecutor -> HumanTask) |
|
||||
| `input.*` | -- | -- | -- (InputExecutor -> AutoTask) |
|
||||
| `ai.prompt` | `ai` | `process` | `prompt->aiPrompt` |
|
||||
| `ai.webResearch` | `ai` | `webResearch` | `query->prompt` |
|
||||
| `ai.summarizeDocument` | `ai` | `summarizeDocument` | -- |
|
||||
|
|
@ -750,7 +822,7 @@ executeGraph(graph, services, ...)
|
|||
| switch: evaluiert Match, setzt active path
|
||||
| loop: iteriert mit _loopState
|
||||
+-- nodeType.startsWith("input.") -> InputExecutor
|
||||
| -> erstellt HumanTask, setzt Run auf PAUSED
|
||||
| -> erstellt AutoTask, setzt Run auf PAUSED
|
||||
+-- alles andere -> ActionNodeExecutor
|
||||
+-- _getNodeDefinition(nodeType) -> _method, _action, _paramMap
|
||||
+-- Parameter-Mapping (Node-Params -> Action-Params)
|
||||
|
|
@ -824,9 +896,9 @@ Sidebar mit Chat. Agent nutzt Toolbox `"workflow"` mit System-Prompt, der den ak
|
|||
|
||||
### UC-3: Workflow testen mit Tracing Log
|
||||
|
||||
User klickt "Test Run" -> Graph wird ausgefuehrt -> jeder Node wird visuell hervorgehoben (Status-Farben) -> Tracing Log zeigt pro Node: Input, Output, Dauer, Fehler. Bei Fehlern: User bespricht den Fehler im AI Chat -> Agent liest RunStepLog und schlaegt Korrekturen vor.
|
||||
User klickt "Test Run" -> Graph wird ausgefuehrt -> jeder Node wird visuell hervorgehoben (Status-Farben) -> Tracing Log zeigt pro Node: Input, Output, Dauer, Fehler. Bei Fehlern: User bespricht den Fehler im AI Chat -> Agent liest AutoStepLog und schlaegt Korrekturen vor.
|
||||
|
||||
**Technisch:** `RunStepLog` pro Node mit Timestamps, Input-Snapshot, Duration, Error-Stack. SSE/WebSocket fuer Live-Updates. Run-Modes: "Full Run" und "Step-by-Step" (Pause nach jedem Node).
|
||||
**Technisch:** `AutoStepLog` pro Node mit Timestamps, Input-Snapshot, Duration, Error-Stack. SSE/WebSocket fuer Live-Updates. Run-Modes: "Full Run" und "Step-by-Step" (Pause nach jedem Node).
|
||||
|
||||
### UC-4: Workflow automatisieren (Scheduler)
|
||||
|
||||
|
|
@ -957,7 +1029,7 @@ frontend_nyla/src/
|
|||
## Phasen-Plan
|
||||
|
||||
### Phase 1: Foundation
|
||||
- Unified Workflow Datenmodell (Workflow + WorkflowVersion + WorkflowRun + RunStepLog + HumanTask)
|
||||
- Unified Workflow Datenmodell (AutoWorkflow + AutoVersion + AutoRun + AutoStepLog + AutoTask)
|
||||
- Toolbox-Registry implementieren (Abloesung `_CORE_ONLY_TOOLS`)
|
||||
- ChatBar-Komponente extrahieren
|
||||
- Feature Rename: `automation2` -> `graphicalEditor`
|
||||
|
|
@ -966,11 +1038,12 @@ frontend_nyla/src/
|
|||
### Phase 2: Editor Enhancement
|
||||
- AI Chat Sidebar im Editor (Toolbox `"workflow"` + Graph-Manipulation-Tools)
|
||||
- UDB Integration im Editor
|
||||
- WorkflowVersion Lifecycle (Draft/Published)
|
||||
- Enhanced RunStepLog + Visual Tracing
|
||||
- AutoVersion Lifecycle (Draft/Published)
|
||||
- Enhanced AutoStepLog + Visual Tracing
|
||||
|
||||
### Phase 3: Productization
|
||||
- Workflow Templates / Marketplace
|
||||
- Workflow-Vorlagen: Template-Management (Scope `user` | `instance` | `mandate` | `system`), Bootstrap durch `sysadmin`, Kopie-vs-Freigabe, RBAC laut Abschnitt „Workflow-Vorlagen“
|
||||
- Marketplace / Katalog (optional auf Basis derselben Vorlagen-API)
|
||||
- Monitoring Dashboard
|
||||
- Retry Policies pro Node
|
||||
- Notifications bei Scheduler-Fehlern
|
||||
|
|
@ -988,7 +1061,7 @@ frontend_nyla/src/
|
|||
|
||||
- Gateway: `features/automation/`, `features/automation2/`, `workflows/`, `serviceCenter/services/serviceAgent/`
|
||||
- Frontend: `components/Automation2FlowEditor/`, `pages/views/automation2/`
|
||||
- DB-Migration: ja (neues Workflow/Version/Run Schema)
|
||||
- DB-Migration: nein (Greenfield -- neue DB `poweron_graphicaleditor`, keine Migration von `poweron_automation2`)
|
||||
- Andere: Scheduler (APScheduler/eventManager), RBAC Template-Rollen
|
||||
|
||||
## Entscheidungen
|
||||
|
|
@ -1001,17 +1074,21 @@ frontend_nyla/src/
|
|||
| 2026-04-05 | Feature-Code `automation2` -> `graphicalEditor` | Klarer Name fuer User und Entwickler |
|
||||
| 2026-04-05 | Graph-Execution und WorkflowManager getrennt lassen | Verschiedene Orchestrierungsmodelle |
|
||||
| 2026-04-05 | Sub-Agent maximal 1 Level tief | Komplexitaet kontrollierbar |
|
||||
| 2026-04-06 | Workflow-Vorlagen mit Scope + getrenntem RBAC; `my` = nur eigene User-Scope-Vorlagen | Einheitliches Teilen (Kopie vs. read-only Freigabe) ohne Widerspruch zu Mandant/Instanz |
|
||||
| 2026-04-06 | `Auto`-Prefix fuer alle Datenobjekte (AutoWorkflow, AutoVersion, AutoRun, AutoStepLog, AutoTask) | Eindeutige Erkennbarkeit in der Codebase; kein Namenskonflikt mit bestehenden Modellen |
|
||||
| 2026-04-06 | Greenfield-Migration statt DB-Schema-Umbau | Neue DB `poweron_graphicaleditor`; `poweron_automation2` bleibt als Archiv; kein Migrationsrisiko |
|
||||
|
||||
## Umsetzungs-Checkliste
|
||||
|
||||
- [ ] Vereinheitlichtes Workflow/WorkflowVersion/WorkflowRun Schema
|
||||
- [ ] Vereinheitlichtes Schema: AutoWorkflow/AutoVersion/AutoRun/AutoStepLog/AutoTask (Greenfield DB)
|
||||
- [ ] v1-Scheduler-Pattern in v2 Engine
|
||||
- [ ] Toolbox Registry + requestToolbox Meta-Tool
|
||||
- [ ] Feature-Code Rename `automation2` -> `graphicalEditor`
|
||||
- [ ] Frontend: ChatBar + ChatStream extrahieren
|
||||
- [ ] Frontend: UDB + Chat im Graph-Editor
|
||||
- [ ] RBAC Template-Rollen konsolidieren
|
||||
- [ ] RunStepLog + Visual Tracing
|
||||
- [ ] Vorlagen: `templateScope`, Ersteller (Basis-Klasse), Freigabe/Kopie, DATA+RESOURCE-Regeln
|
||||
- [ ] AutoStepLog + Visual Tracing
|
||||
- [ ] Neutralisierung: keine Aenderung (nutzt gleiche Services)
|
||||
- [ ] Billing-Impact: pruefen (Automation-Runs zaehlen?)
|
||||
|
||||
|
|
@ -1041,11 +1118,12 @@ frontend_nyla/src/
|
|||
|---------|-----------|
|
||||
| **Toolbox** | Thematisch gebuendelte Gruppe von AI-Tools, kontextabhaengig aktiviert |
|
||||
| **Sub-Agent** | Spezialisierter Mini-Agent mit eigener Tool-Registry, aufgerufen vom Main Agent |
|
||||
| **Workflow** | Persistiertes Automatisierungsmodell mit Graph-Struktur |
|
||||
| **WorkflowVersion** | Immutable Snapshot eines Workflow-Graphen (draft, published, archived) |
|
||||
| **WorkflowRun** | Einzelne Ausfuehrung einer WorkflowVersion |
|
||||
| **RunStepLog** | Detaillierter Log pro Node-Execution innerhalb eines Runs |
|
||||
| **HumanTask** | Aufgabe fuer menschliche Eingabe, erstellt bei Pause eines Runs |
|
||||
| **AutoWorkflow** | Persistiertes Automatisierungsmodell mit Graph-Struktur |
|
||||
| **AutoVersion** | Immutable Snapshot eines Workflow-Graphen (draft, published, archived) |
|
||||
| **AutoRun** | Einzelne Ausfuehrung einer AutoVersion |
|
||||
| **AutoStepLog** | Detaillierter Log pro Node-Execution innerhalb eines Runs |
|
||||
| **AutoTask** | Aufgabe fuer menschliche Eingabe, erstellt bei Pause eines Runs |
|
||||
| **AutoTemplateScope** | `user` \| `instance` \| `mandate` \| `system` -- steuert Sichtbarkeit und RBAC von Workflow-Vorlagen |
|
||||
| **Node** | Ausfuehrungsschritt im Graph (Trigger, Action, Flow-Control, Input/Human) |
|
||||
| **Method** | Integrations-Kategorie (z.B. methodOutlook) mit mehreren Actions |
|
||||
| **Action** | Spezifische Operation innerhalb einer Method (z.B. outlook.readEmails) |
|
||||
Loading…
Reference in a new issue