Accès restreint de l’appelant aux Studio de workflow flux

Suivez les flux et les actions qui nécessitent un accès à des ressources inter-périmètres. Autorisez ou refusez aux flux et aux actions l’accès aux ressources entre périmètres.

La table Privilèges d’accès restreint pour l’appelant dispose de types de sources dédiés pour identifier Studio de workflow les sources d’appel.

Flux

Le système utilise le type de source de flux pour suivre les opérations exécutées par ServiceNow les actions de base. Les enregistrements des privilèges d’accès restreint pour l’appelant permettent à un flux d’effectuer une opération spécifique sur une ressource entre périmètres spécifique. L’approbation d’un flux pour exécuter une opération permet à toute autre action de base au sein du même flux d’effectuer la même opération sur la même ressource entre périmètres.

Par exemple, supposons que vous ayez un flux qui exécute l’action Rechercher des enregistrements sur une table entre périmètres. Lorsque la restriction de l’appelant est activée pour la table entre périmètres, l’action Rechercher des enregistrements génère une demande pour effectuer une opération de lecture. Lorsque vous autorisez le flux à effectuer des opérations de lecture sur la table entre périmètres, toutes les autres opérations de lecture effectuées par les actions principales peuvent également s’exécuter. Par exemple, votre flux peut exécuter les actions Rechercher un enregistrement et Rechercher des pièces jointes sur la même table entre périmètres. Supposons que vous ajoutiez l’action Rechercher des enregistrements pour la même table entre périmètres à un autre flux ou flux secondaire. Étant donné que cette opération de lecture provient d’un autre flux, l’action principale génère une demande de privilège d’accès distincte pour approbation. Si vous configurez l’action Rechercher des enregistrements pour accéder à une autre table entre périmètres, cela génère également une demande de privilège d’accès distincte pour approbation.

Action de flux

Le système utilise le type de source d’action de flux pour suivre les opérations exécutées par des actions personnalisées sur une ressource entre périmètres spécifique. Les enregistrements de privilèges d’accès restreint pour l’appelant permettent à une action personnalisée d’effectuer une opération spécifique sur une ressource entre périmètres spécifique. L’approbation d’une action pour exécuter une opération permet à l’action personnalisée d’effectuer l’opération sur la ressource entre périmètres dans n’importe quel contexte.

Par exemple, supposons que vous créez une action personnalisée qui exécute l’étape Rechercher des enregistrements sur une table entre périmètres. Lorsque la restriction de l’appelant est activée pour la table entre périmètres, l’étape Rechercher des enregistrements génère une demande pour effectuer une opération de lecture. Lorsque vous autorisez l’action personnalisée à effectuer des opérations de lecture sur la table entre périmètres, vous pouvez exécuter l’action personnalisée à partir de n’importe quel contexte. Par exemple, vous pouvez ajouter l’action personnalisée à plusieurs flux ou appeler l’action personnalisée à partir d’un script. Tant que l’action personnalisée effectue l’opération sur la ressource entre périmètres cible, le système autorise l’exécution de l’action personnalisée. Si vous configurez l’action personnalisée pour accéder à une autre table entre périmètres, l’action personnalisée génère une demande de privilège d’accès distincte pour approbation.

Mettre à niveau les privilèges d’accès restreint de l’appelant pour les flux et les actions

Autorisez les instances mises à niveau à partir des versions antérieures afin de générer des demandes de privilège d’accès San Diego restreint pour l’appelant pour les flux et les actions.

Avant de commencer

Si vous activez l’administration des applications pour l’application cible, seuls les administrateurs de l’application cible peuvent définir l’accès à une application. Si l’administration d’application n’est pas activée, un utilisateur administrateur peut définir l’accès à une application.

Rôle requis : admin d’application ou admin

Remarque :

Pour en savoir plus sur les rôles d’administrateur spécifiques aux applications et le développement délégué, consultez Règles de contrôle d’accès dans les applications d’administration d’application et Développement et déploiement délégués.

Pourquoi et quand exécuter cette tâche

Dans San Diego les versions et versions antérieures, la table Privilèges d’accès restreint pour l’appelant ne reconnaissait pas les flux et les actions comme types de sources. Les clients qui souhaitaient générer des enregistrements de privilèges d’accès restreint pour l’appelant pour les flux et les actions ne pouvaient le faire qu’indirectement. Ils peuvent utiliser un include de script ou une règle métier pour appeler un flux ou une action. Lorsque le script include ou la règle métier s’exécutait, il générait une demande de privilège d’accès à la ressource entre périmètres pour approbation.

Avertissement :

La mise à niveau des privilèges d’accès restreint pour l’appelant afin de suivre les flux et les actions peut entraîner des interruptions de service sur les instances qui suivaient auparavant l’accès entre périmètres à partir d’includes de script ou de règles métier. Après la mise à niveau, l’exécution de tous les flux et actions qui tentent d’accéder à des ressources restreintes est bloquée et génère leurs propres demandes de privilège d’accès restreint pour l’appelant. Quelqu’un doit approuver les demandes de privilège d’accès pour que les flux et les actions entre périmètres puissent s’exécuter. Les clients qui autorisaient déjà le suivi indirect des flux et des actions à l’aide d’appels de scripts peuvent ignorer cette tâche et continuer à appeler des flux et des actions à partir de scripts. Les clients qui souhaitent remplacer leurs privilèges d’accès existants par les nouveaux types de sources Flux et Action de flux peuvent planifier une panne pour générer et approuver les nouvelles demandes de privilège d’accès.

Procédure

1. Ajoutez une propriété système .
   Créez cette propriété.

   Champ	Valeur
   Nom	com.glide.hub.flow.restricted_caller_access.suivre_les_flux_en tant que source
   Type	true|false
   Valeur	vrai

2. Définissez l’accès entre périmètres à une ressource d’application .
   Activez la restriction de l’appelant pour les tables auxquelles vous souhaitez demander l’accès aux flux et aux actions.
3. Si vous remplacez les autorisations d’accès basées sur des scripts existantes, identifiez les flux et les actions entre périmètres existants qui nécessitent des autorisations d’accès.
   Vous devez régénérer tous les privilèges d’accès existants pour les flux et les actions entre périmètres. Les privilèges d’accès de flux et d’action remplacent les privilèges d’accès existants d’inclusion de script et de règle métier.
4. Générez des demandes de privilège d’accès pour tous les flux et actions entre périmètres existants.
   Vous pouvez exécuter des flux et des actions entre périmètres en utilisant ou en testant l’application entre périmètres.
   Les flux et les actions entre périmètres génèrent des demandes de privilège d’accès aux tables définies sur la restriction de l’appelant.
5. Autorisez les flux et les actions à accéder aux ressources de votre application .
   Identifiez les demandes de privilège d’accès avec ces types de sources.

   • Flux
   • Action de flux

   Définissez l’état sur Autorisé pour chaque opération que vous souhaitez qu’un flux ou une action effectue sur votre ressource d’application restreinte.

Résultats

Les flux et les actions qui tentent d’accéder à vos ressources d’application restreintes génèrent une demande de privilège d’accès.

Que faire ensuite

Examinez et approuvez les demandes de privilège d’accès à partir de votre enregistrement d’application.