- Erste Schritte
- Best Practices
- Organisationsmodellierung im Orchestrator
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Optimieren von Unattended-Infrastruktur mithilfe von Maschinenvorlagen
- Organisieren von Ressourcen mit Tags
- Exportieren von Rastern im Hintergrund
- Durchsetzung der Governance der Integration Service-Verbindung auf Benutzerebene
- Mandant
- Über den Kontext „Mandant“
- Suche nach Ressourcen in einem Mandanten
- Verwaltung von Robotern
- Verbindung von Robotern mit Orchestrator
- Speicherung von Roboterzugangsdaten in CyberArk
- Speichern der Kennwörter von Unattended-Robotern im Azure Key Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im HashiCorp Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im AWS Secrets Manager (schreibgeschützt)
- Löschen von getrennten und nicht reagierenden Unattended-Sitzungen
- Roboter-Authentifizierung
- Roboter-Authentifizierung mit Client-Anmeldeinformationen
- Konfigurieren von Automatisierungsfunktionen
- Solutions (Lösungen)
- Audit
- Enforced encryption
- Einstellungen
- Registrierung
- Benachrichtigungen
- Events
- Anzeigen und Zugreifen auf Benachrichtigungen
- Anzeigen und Zugreifen auf E-Mail-Benachrichtigungen
- Es werden nur ungelesene Benachrichtigungen angezeigt
- Alle Benachrichtigungen als gelesen markieren
- Alle Benachrichtigungen löschen
- Löschen von Benachrichtigungen
- Abonnieren von Ereignissen
- Abbestellen von Ereignissen
- Ordnerkontext
- Prozesse
- Jobs
- Apps
- Auslöser
- Protokolle
- Überwachung
- Indizes
- Warteschlangen
- Assets
- Über Assets
- Verwalten von Assets in Orchestrator
- Verwalten von Assets in Studio
- Speichern von Assets im Azure Key Vault (schreibgeschützt)
- Speichern von Assets im HashiCorp Vault (schreibgeschützt)
- Speichern von Assets im AWS Secrets Manager (schreibgeschützt)
- Speichern von Assets in Google Secret Manager (schreibgeschützt)
- Verbindungen
- Geschäftsregeln
- Speicher-Buckets
- Agent-Gateway
- Testverfahren in Orchestrator
- Ressourcenkatalogdienst
- Integrationen
- Fehlersuche und ‑behebung
Gemeinsame Grundlage von MCP-Server
Befehls-, codierte und selbst gehostete MCP-Server führen alle codebasierte MCP-Server-Implementierungen aus und haben eine gemeinsame Grundlage. Auf dieser Seite werden die Laufzeit-, Transport- und Konfigurationsformate beschrieben, die sie gemeinsam haben.
Runtime-Bibliothek
Die gemeinsame Laufzeit basiert auf uipath-mcp-python, einer Open-Source-Python-Bibliothek, die die Laufzeit, das SDK und die CLI zum Erstellen und Ausführen von MCP-Servern auf der UiPath-Plattform bereitstellt. Er baut auf der uipath-python- Bibliothek auf.
Transport
Die Kommunikation mit der Plattform erfolgt über Streamable HTTP. Ein einzelner Prozess verarbeitet mehrere Sitzungen gleichzeitig, jede mit einer eigenen Verbindung, und der gleiche Transport wird für externe MCP-Clients verfügbar gemacht. Dies ist der empfohlene Pfad für neue MCP-Server.
Der ältere Studio- Transport, der einen neuen Prozess pro Sitzung startet, ist veraltet und wird nur für die Abwärtskompatibilität mit MCP-Servern beibehalten, die vor der Einführung von Streamable HTTP erstellt wurden.
Konfigurationsformat
Jeder MCP-Server wird durch eine mcp.json -Konfigurationsdatei beschrieben, die die in der Runtime-Umgebung verfügbaren Server definiert: deren Typ, Einstiegspunkt und Argumente. Das Format wird für Befehls-, codierte und selbst gehostete MCP-Server freigegeben.