- 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
- Einstellungen
- Registrierung
- Cloud Robots
- Übersicht über Cloud Robots
- Ausführen von Unattended-Automatisierungen mit Cloud Robot – VM
- Hochladen Ihres eigenen Image
- Wiederverwenden von benutzerdefinierten Maschinen-Images (für manuelle Pools)
- Zurücksetzen der Anmeldeinformationen für eine Maschine (für manuelle Pools)
- Überwachung
- Sicherheitsupdates
- Testversion anfordern
- Häufig gestellte Fragen
- Konfigurieren einer VPN für Cloud-Roboter
- Konfigurieren einer ExpressRoute-Verbindung
- Live-Streaming und Remotesteuerung
- 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
- Automation Suite-Roboter
- 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
- MCP-Server
- Testverfahren in Orchestrator
- Ressourcenkatalogdienst
- Integrationen
- Fehlersuche und ‑behebung
Orchestrator-Anleitung
Wenn MCP-Server lokal ausgeführt werden (mit uipath run), erfolgt die Authentifizierung auf zwei separaten Ebenen:
- Runtime zu Cloud: Die lokale Runtime authentifiziert sich, damit sie den MCP-Server bei der Cloud registrieren kann.
- Client zu Cloud: Externe Clients authentifizieren sich, wenn sie den mit der Cloud verbundenen MCP-Server-Endpunkt aufrufen.
Ebene 1: Runtime to Cloud (Server-Registrierung)
Der Befehl uipath run benötigt ein eigenes Token, um den MCP-Server bei der Cloud zu registrieren. Dies ist die Authentifizierung des Entwicklers, die Identität der Person, die den Server lokal ausführt.
# Authenticate the runtime — interactive login
uipath auth
# Or authenticate the runtime — client credentials
uipath auth --client-id "..." \
--client-secret "..." \
--base-url "https://cloud.uipath.com/{org}/{tenant}" \
--scope "OR.Default"
# Start the local server
uipath run mcp-server
# Authenticate the runtime — interactive login
uipath auth
# Or authenticate the runtime — client credentials
uipath auth --client-id "..." \
--client-secret "..." \
--base-url "https://cloud.uipath.com/{org}/{tenant}" \
--scope "OR.Default"
# Start the local server
uipath run mcp-server
Die Runtime verwendet dieses Token, um eine SignalR-Verbindung zur Cloud herzustellen und die Tools des Servers zu registrieren.
Ebene 2: Client zu Cloud (Server aufrufen)
Externe Clients (wie MCP-Instanz, cURL, ein IDE oder ein beliebiger HTTP-Client) authentifizieren sich bei der Cloud über eine der vier Standardmethoden, die unter MCP-Server-Authentifizierung beschrieben sind. Die URL ist die gleiche wie für jeden anderen MCP-Server:
https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
Wie Anforderungen fließen
Das Bearer-Token des Clients erreicht nie die lokale Runtime. Die Cloud validiert das Token und leitet nur die MCP-Protokollnachricht über Redis weiter. Die lokale Runtime und der MCP-Serverprozess sehen das Token nicht.
Anwendbare MCP-Servertypen
Die Ground-to-Cloud-Authentifizierung gilt für MCP-Servertypen mit einer lokalen Runtime:
- Selbst gehostet: Wird immer lokal ausgeführt und verwendet immer die Ground-to-Cloud-Authentifizierung.
- Codiert und Befehl: Verwenden Sie die Ground-to-Cloud-Authentifizierung, wenn sie während der Entwicklung lokal über
uipath runausgeführt werden. Nach der Bereitstellung für Orchestrator werden sie als Cloud-Aufträge ausgeführt und es ist keine lokale Laufzeit vorhanden.
Client-Anmeldeinformationen mit lokalen Servern
Wenn Sie Client-Anmeldeinformationen mit uipath run verwenden, legen Sie die Umgebungsvariable UIPATH_FOLDER_KEY fest. Der GetFoldersForCurrentUser -Aufruf des Python-SDK unterstützt keine Client-Anmeldeinformationen. Weitere Informationen finden Sie unter Bekannte Einschränkung: GetFoldersForCurrentUser.