- Démarrage
- Meilleures pratiques
- Modélisation de l'organisation dans Orchestrator
- Meilleures pratiques d'automatisation
- Optimisation de l'infrastructure Unattended à l'aide de modèles de machine
- Organisation des ressources avec des balises
- Exportation des grilles dans l'arrière-plan
- Appliquer la gouvernance de la connexion Integration Service au niveau de l'utilisateur
- Locataire
- À propos du contexte du locataire
- Recherche de ressources dans un locataire
- Gestion des Robots
- Connexion des Robots à Orchestrator
- Enregistrement des identifiants du Robot dans CyberArk
- Stockage des mots de passe de l’Unattended Robot dans Azure Key Vault (lecture seule)
- Stockage des informations d’identification de l’Unattended Robot dans HashiCorp Vault (lecture seule)
- Stockage des informations d'identification du robot Unattended dans AWS Secrets Manager (lecture seule)
- Suppression des sessions Unattended déconnectées et qui ne répondent pas
- Authentification du Robot
- Authentification du Robot avec les informations d'identification du client
- Configurer les capacités d’automatisation
- Solutions
- Audit
- Paramètres
- Registre
- Cloud Robots
- Présentation des robots cloud
- Exécution d'automatisations Unattended à l'aide de Cloud Robots - VM
- Téléchargement de votre propre image
- Réutilisation des images de machines personnalisées (pour les pools manuels)
- Réinitialisation des informations d'identification d'une machine (pour les pools manuels)
- Surveillance
- Mises à jour de sécurité
- Demander un essai
- Questions fréquemment posées
- Configuration du VPN pour les robots du cloud
- Configurer une connexion ExpressRoute
- Diffusion en direct et contrôle à distance
- Robots Automation Suite
- Contexte des dossiers
- Processus (Processes)
- Tâches (Jobs)
- Apps
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Index
- Files d'attente (Queues)
- Actifs
- À propos des actifs
- Gestion des actifs dans Orchestrator
- Gestion des actifs dans Studio
- Stockage des ressources dans Azure Key Vault (lecture seule)
- Stockage des ressources dans HashiCorp Vault (lecture seule)
- Stockage des ressources dans AWS Secrets Manager (lecture seule)
- Stocker des ressources dans Google Secret Manager (lecture seule)
- Connexions
- Règles métier
- Compartiments de stockage
- Serveurs MCP
- À propos des serveurs MCP
- Base partagée du serveur MCP
- Obtenir l’URL du serveur MCP
- Utiliser les ressources Orchestrator dans les serveurs MCP
- Directives de conformité MCP
- Tests d'Orchestrator
- Service de catalogue de ressources
- Intégrations
- Résolution des problèmes
Guide de l'utilisateur d'Orchestrator
Les serveurs MCP ont souvent besoin de secrets (clés API, informations d’identification de la base de données, jetons de service) pour se connecter aux systèmes externes. Au lieu de coder en dur ces valeurs dans la configuration du serveur MCP, vous pouvez référencer les ressources Orchestrator à l’aide de la syntaxe %ASSETS/AssetName% . Au moment de l'exécution, le robot résout ces références et injecte les valeurs réelles des ressources sous forme de variables d'environnement.
Le mécanisme est le même pour les serveurs MCP de type Commande et Codés. Uniquement lorsque les variables d'environnement sont configurées diffère entre les deux.
Créer la ressource dans Orchestrator
Accédez à votre dossier dans Orchestrator > Ressources > Créer une ressource. Par exemple:
- Nom :
MyApiKey - Type: Secret (ou Credential pour les paires nom d'utilisateur/mot de passe)
- Valeur:
sk-abc123...
La ressource doit se trouver dans le même dossier que le serveur MCP.
Référencer la ressource dans les variables d'environnement du serveur MCP
La syntaxe de référence de la ressource est identique pour tous les types de serveurs. L'emplacement des variables d'environnement diffère:
| Type de serveur | Où configurer les variables d’environnement |
|---|---|
| Commande serveur MCP | Directement sur le serveur MCP, dans le champ Variables d'environnement du formulaire de création ou de modification dans Orchestrator. |
| Serveur MCP codé | Sur le processus dans Orchestrator: Paramètres > Variables d'environnement. |
Dans les deux cas, les entrées prennent la forme KEY=VALUE, avec %ASSETS/AssetName% comme valeur:
API_KEY=%ASSETS/MyApiKey%
DATABASE_URL=%ASSETS/MyDatabaseUrl%
REGION=us-east-1
API_KEY=%ASSETS/MyApiKey%
DATABASE_URL=%ASSETS/MyDatabaseUrl%
REGION=us-east-1
Les références de ressources et les valeurs simples peuvent être mixtes. Chaque variable va sur sa propre ligne.
Lire les variables dans votre code serveur
Orchestrator stocke les variables d'environnement brutes, y compris les espaces réservés %ASSETS/...% , dans la base de données, chiffrés au repos. Lorsqu'une session démarre, Orchestrator la transmet au runtime sans serveur, ce qui résout les références de ressources à leurs valeurs réelles avant de les transmettre au processus du serveur MCP.
Dans le code du serveur MCP, les variables sont alors disponibles en tant que variables d'environnement standard. Par exemple:
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
Les comportements suivants s'appliquent à l'inférence de ressources dans les serveurs MCP:
- Les noms de ressource ne sont pas sensibles à la casse dans la syntaxe
%ASSETS/...%. - La clé de variable d'environnement détermine le masquage des secrets dans l'interface utilisateur. Les clés correspondant à des modèles tels que
API_KEY,SECRET,PASSWORD,TOKENouAuthorizationsont automatiquement masquées par****. La référence%ASSETS/...%est toujours visible (non masquée). - Si une ressource n'existe pas ou si le Robot n'y a pas accès, la variable d'environnement ne sera pas résolue et le serveur recevra la chaîne
%ASSETS/...%brute.