Résolution des problèmes

Cette page explique comment résoudre les problèmes que vous pourriez rencontrer lors de l'utilisation du package d'activités ServiceNow.

Problèmes d'autorisations

Problème

Un utilisateur ouvre Insert ServiceNow Record, Update ServiceNow Recordou Get ServiceNow Record et, bien qu’il puisse choisir un objet, la liste des propriétés est vide.

Solution

Vous trouverez ci-dessous la liste des appels d'API effectués par le pack d'activités :

Comportement	URL API
éléments de la liste déroulante	/api/now/table/sys_db_object?&sysparm_action=getRecords&sysparm_fields=sys_name,super_class,label,sys_id,name
obtenir toutes les colonnes de la table des incidents	/api/now/table/sys_dictionary?sysparm_fields=internal_type,element,column_label,mandatory&sysparm_query=name%3Dincident%5EORname%3Dtask
obtient la valeur d'échantillon d'un incident	/api/now/table/incident?sysparm_action=getRecords&sysparm_limit=1

Conseil : les deux premières autorisations ne sont requises que pour les développeurs RPA travaillant avec l'expérience au moment de la conception. Les comptes utilisés par les robots pour exécuter le processus n'en ont pas besoin.

Explication détaillée

Par exemple , /api/now/table/incident?sysparm_action=getRecords&sysparm_limit=1 est l'API que nous appelons pour la table des incidents. Vous voudrez vérifier auprès de votre administrateur système ServiceNow que vous disposez des autorisations/accès appropriés pour récupérer les données de la table.

Votre administrateur ServiceNow doit également être en mesure de vérifier les autorisations sous-jacentes/plus précises ; ceux-ci peuvent être différents, mais l'idée générale est la même.  

Quant à la configuration des rôles, elle peut varier, c'est-à-dire Les administrateurs ServiceNow peuvent choisir d'ajuster les paramètres de rôle par défaut. Par exemple, si nous voulons lire les métadonnées de la table *Incident *, nous aurons besoin d’accéder à la fois à sys_db_object et à la table *Incident *.

Chaque table contient des contrôles d' accès et chaque contrôle d'accès contient des rôles. Ces rôles doivent être configurés pour que l'utilisateur puisse lire les deux tables.

Utilisateurs Active Directory

Problème

Vous ne savez pas si vous pouvez utiliser un utilisateur du répertoire d'activités avec le pack d'activités ServiceNow et votre locataire ServiceNow.

Solution

UiPath a validé que cela fonctionne correctement. Pour vérifier cela, nous avons suivi les étapes ci-dessous :

1. Créez un utilisateur Azure AD et validez la possibilité de se connecter avec l'authentification unique :

   
   

   

   
   

2. Attribuez un rôle d'administrateur à cet utilisateur (pour l'instant) :

   
   

   

   
   

3. Dans une fenêtre de navigation privée, connectez-vous en tant qu'utilisateur Azure AD et configurez un ID client et une clé secrète client pour OAuth 2.0 :

   
   

   

   
   

4. Lorsque nous utilisons cet ID client et cette clé secrète client, l'authentification a réussi :