Repository navigation
KI Integration
VertexBPMN kann KI als optionale Prozessintegration einsetzen. Das Modell bleibt BPMN: Ein AI-Aufruf läuft als Service Task oder über einen getrennten External Worker. VertexBPMN enthält kein allgemeines LLM und die Studio-Oberfläche hat derzeit keinen eingebauten Chat-/Copilot-Assistenten.
Der AIServiceTaskHandler verarbeitet AI-Service-Tasks über konfigurierbare BPMN-Attribute. Der direkte Providerpfad unterstützt:
| Provider | Konfiguration / Credential |
|---|---|
| OpenAI |
ai:provider=openai; Schlüssel über die für das Modell konfigurierte Umgebungsvariable, standardmäßig OPENAI_API_KEY
|
| Anthropic |
ai:provider=anthropic; Schlüssel über die für das Modell konfigurierte Umgebungsvariable, standardmäßig ANTHROPIC_API_KEY
|
| Google Gemini |
ai:provider=gemini oder google; Schlüssel aus GEMINI_API_KEY oder GOOGLE_API_KEY
|
Übliche Attribute sind ai:model, ai:prompt, ai:systemMessage, ai:inputVariables, ai:resultVariable, ai:temperature, ai:maxTokens, ai:timeout, ai:retryCount und ai:includeMetadata. Optional gibt es Context Enrichment und einen nachgelagerten MCP-Aufruf. Die tatsächlichen Defaults und vollständigen BPMN-Beispiele stehen im AI-Service-Task-Beispiel im Hauptrepository.
Ergebnisse werden in der konfigurierten Prozessvariable abgelegt. Fehler setzen aiTask_error und aiTask_failed und werden als Service-Task-Fehler zurückgegeben, sodass der Prozess sie behandeln kann.
Nicht jeder registrierte ai:*-Alias ist ein echter Modellprovider. GenericAiServiceTaskHandler liefert derzeit einen lokalen Platzhaltertext und führt keinen HTTP-Aufruf an Cohere, Hugging Face, Ollama oder einen beliebigen Custom-Endpunkt aus. Diese generischen Aliase sind daher keine nutzbare produktive Providerintegration. mock/test sind für Entwicklung und Tests gedacht.
Die Provider-Handler werden durch automatisierte Tests mit simulierten HTTP-Antworten geprüft. Das ist kein Live-Kompatibilitäts- oder Verfügbarkeitsnachweis für ein externes Anbieter-Konto.
MCP stellt BPMN-/DMN-/CMMN-Funktionen als Werkzeuge für kompatible KI-Clients und Agenten bereit. Umgekehrt kann ein BPMN-Service-Task einen externen MCP-Endpunkt über mcpServerUrl und mcpMethod aufrufen; die Anfrage führt Prozessvariablen mit und ein erfolgreiches JSON-RPC-Ergebnis wird wieder in Variablen übernommen. Ein externer MCP-Server, Transport und seine Authentifizierung müssen separat eingerichtet werden.
Die optionale Einstellung ai:mcpIntegration=true kann nach einem AI-Aufruf eine MCP-Aktion anstoßen. Das ersetzt keine allgemeine autonome Tool-Schleife des Modells: Der Workflow und die erlaubten Prozessschritte bleiben durch das BPMN-Modell bestimmt.
VertexBPMN.AgentWorker enthält zusätzlich einen Contract-Review-External-Task-Handler mit einem Ollama-kompatiblen lokalen Modell. Er ist standardmäßig deaktiviert (ContractReviewer:Enabled=false) und auf einen Loopback-Endpunkt begrenzt.
Der Beispiel-Reviewer arbeitet lesend mit begrenzten Dokumentgrößen, Laufzeit-, Token- und Tool-Budgets. Seine Werkzeuge können nur freigegebene Dokumentabschnitte lesen oder wörtlich durchsuchen. Ergebnisse müssen Fundstellen mit Zitaten enthalten; der Agent darf einen Vertrag weder genehmigen noch ablehnen. Die fachliche Entscheidung bleibt immer bei einer Person. Details: External-Task- und Agent-Vertragsprüfung.
- Provider-Zugangsdaten nicht in BPMN-Dateien oder Prozessvariablen speichern; Secret Provider oder geschützte Umgebungsvariablen verwenden.
- Prompts und ausgewählte Prozessvariablen können an den konfigurierten externen Anbieter übertragen werden. Datenklassifikation, Einwilligung, Aufbewahrung und Anbieterbedingungen vor Aktivierung prüfen.
- MCP- und Agent-Endpunkte als Vertrauensgrenzen behandeln, authentifizieren und auf benötigte Werkzeuge beschränken.
- LLM-Ausgaben als nicht vertrauenswürdige Eingabe behandeln. Kritische Aktionen durch BPMN-Gates, Validierung und erforderliche menschliche Freigaben absichern.