- 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
- Über MCP-Server
- Gemeinsame Grundlage von MCP-Server
- Abrufen der MCP-Server-URL
- Verwenden von Orchestrator-Assets in MCP-Servern
- MCP-Compliance-Richtlinien
- Testverfahren in Orchestrator
- Ressourcenkatalogdienst
- Integrationen
- Fehlersuche und ‑behebung
Orchestrator-Anleitung
MCP-Server benötigen häufig Geheimnisse wie API-Schlüssel, Datenbankanmeldeinformationen oder Diensttoken, um eine Verbindung mit externen Systemen herzustellen. Anstatt diese Werte in die MCP-Serverkonfiguration fest einprogrammieren, können Sie mit der Syntax %ASSETS/AssetName% auf Orchestrator-Assets verweisen.
Asset-Referenzen werden je nach MCP-Servertyp unterschiedlich aufgelöst:
- Befehls- und codierte MCP-Server verwenden die Roboter-/Laufzeit-Asset-Inferenz. Asset-Referenzen werden als Teil der serverlosen Auftragslaufzeit aufgelöst, bevor der MCP-Serverprozess gestartet wird.
- Remote-MCP-Server verwenden Asset-API-Inferenz. Asset-Referenzen in benutzerdefinierten Headern werden über Orchestrator aufgelöst, bevor die Anforderung an den Remote-Endpunkt weitergeleitet wird, ohne dass ein Roboter oder Roboterschlüssel erforderlich ist.
Erstellen Sie das Asset in Orchestrator
Wechseln Sie zu Ihrem Ordner unter Orchestrator > Assets > Asset erstellen. Zum Beispiel:
- Name:
MyApiKey - Typ: Geheimnis oder Zugangsdaten für Benutzername/Kennwort-Paare
- Wert:
sk-abc123...
Das Asset muss sich im selben Ordner wie der MCP-Server befinden.
Referenzassets in Befehls- und codierten MCP-Servern
Befehls- und codierte MCP-Server verweisen auf Assets in Umgebungsvariablen. Der Speicherort der Umgebungsvariablen unterscheidet sich:
| Servertyp | Wo Umgebungsvariablen konfiguriert werden sollen |
|---|---|
| Befehls-MCP-Server | Direkt auf dem MCP-Server, im Feld Umgebungsvariablen des Formulars zum Erstellen oder Bearbeiten im Orchestrator. |
| Codierter MCP-Server | Über den Prozess im Orchestrator: Einstellungen > Umgebungsvariablen. |
In beiden Fällen haben Einträge das Format KEY=VALUE mit %ASSETS/AssetName% als Wert:
API_KEY=%ASSETS/MyApiKey%
DATABASE_URL=%ASSETS/MyDatabaseUrl%
REGION=us-east-1
API_KEY=%ASSETS/MyApiKey%
DATABASE_URL=%ASSETS/MyDatabaseUrl%
REGION=us-east-1
Asset-Referenzen und einfache Werte können gemischt werden. Jede Variable folgt einer eigenen Zeile.
Orchestrator speichert die unformatierten Umgebungsvariablen, einschließlich der %ASSETS/...% -Platzhalter, in der Datenbank, im Ruhezustand verschlüsselt. Wenn eine Sitzung gestartet wird, leitet der Orchestrator sie an die serverlose Runtime weiter, die die Asset-Referenzen auf ihre tatsächlichen Werte auflöst, bevor sie an den MCP-Serverprozess übergeben werden.
Im MCP-Servercode sind die Variablen dann als Standardumgebungsvariablen verfügbar. Zum Beispiel:
import os
api_key = os.environ.get("API_KEY") # Resolved to the asset value at runtime
import os
api_key = os.environ.get("API_KEY") # Resolved to the asset value at runtime
Verweisen Sie auf Assets in Remote-MCP-Server-Headern
Remote-MCP-Server starten keinen UiPath-Runtime-Auftrag, sodass sie keine Inferenz für Roboter-/Runtime-Assets verwenden. Stattdessen können Sie auf Assets in benutzerdefinierten HTTP-Headern verweisen. Der Orchestrator löst die Asset-Werte auf, bevor die Anforderung an den Remote-MCP-Server weitergeleitet wird.
Verwenden Sie %ASSETS/AssetName% als vollständigen Header-Wert:
Authorization: %ASSETS/RemoteBearerToken%
X-Api-Key: %ASSETS/MyApiKey%
X-Region: us-east-1
Authorization: %ASSETS/RemoteBearerToken%
X-Api-Key: %ASSETS/MyApiKey%
X-Region: us-east-1
Wenn der Remoteendpunkt ein Präfix wie Bearer erwartet, speichern Sie den vollständigen Headerwert im Asset. Speichern Sie beispielsweise Bearer <token> im RemoteBearerToken -Asset und konfigurieren Sie dann den Header als Authorization: %ASSETS/RemoteBearerToken%.
Referenzen zu Remote-Header-Assets werden über Orchestrator mithilfe der UiPath-Identität des Aufrufers und des MCP-Server-Ordnerkontexts aufgelöst. Der Orchestrator erzwingt die erforderlichen Asset-Berechtigungen und die Berechtigung für den direkten API-Zugriff. Dieser Pfad funktioniert ohne Roboter oder Roboterschlüssel.
Der Aufrufer muss Zugriff auf den MCP-Serverordner und eine Berechtigung haben, um das referenzierte Asset anzuzeigen. Wenn das Asset fehlt, nicht zugänglich oder nicht für den direkten API-Zugriff berechtigt ist, schlägt die Remote-MCP-Anforderung fehl, anstatt einen ungelösten Platzhalter weiterzuleiten.
Unterstützte Asset-Werte
Das folgende Verhalten gilt für die Asset-Inferenz auf MCP-Servern:
- Bei Asset-Namen wird die Groß-/Kleinschreibung nicht berücksichtigt
%ASSETS/...%. - Bei Befehls- und codiertenMCP-Servern bestimmt der umgebungsvariablenschlüssel die geheime Maskierung auf der Benutzeroberfläche. Schlüssel, die Mustern wie
API_KEY,SECRET,PASSWORD,TOKENoderAuthorizationentsprechen, werden automatisch mit****maskiert. Die Referenz%ASSETS/...%selbst ist immer sichtbar. - Für Remote-MCP-Server-Header werden Text-, Geheimnis-, Boolesch-, Integer-, Anmeldeinformationen- und Windows-Anmeldeinformations-Assets unterstützt. Bei Anmeldeinformations-Assets wird der Kennwortwert für die Substitution verwendet.
- Konfigurieren Sie Asset-gestützte Header nur für vertrauenswürdige Remoteendpunkte, da der aufgelöste Wert an diesen Endpunkt gesendet wird.
Schlüsselwertlisten-Assets werden für den Ersatz von MCP-Server-Assets nicht unterstützt.