ServiceNow

Maintenu par OrkyvoVersion 1.0.0Inclus dans l'offre DevOps8 actions · 3 déclencheurs

Incidents, notes de travail, affectations, recherches et demandes de changement ServiceNow.

Intégration maintenue par Orkyvo pour ServiceNow (Table API). Créez, lisez, mettez à jour et affectez des incidents, ajoutez des notes de travail ou des commentaires, recherchez des enregistrements avec une requête encodée et créez des demandes de changement. Déclencheurs par interrogation persistante côté serveur : nouvel incident, incident modifié, changement d'état ou d'affectation. Les ACL, champs obligatoires et valeurs propres à votre instance sont respectés.

Opérations

Opération	Type	Description
Créer un incidenteffet externe : demande une confirmation avant une exécution manuelle	action	Crée un incident. Avec un identifiant de corrélation, un incident déjà créé pour cette corrélation est renvoyé au lieu d'un doublon.
Obtenir un incident	action	Lit un incident par numéro ou sys_id.
Mettre à jour un incidenteffet externe : demande une confirmation avant une exécution manuelle	action	Modifie un incident : seuls les champs renseignés sont envoyés.
Ajouter une note de travail ou un commentaireeffet externe : demande une confirmation avant une exécution manuelle	action	Note de travail (interne) ou commentaire (visible de l'appelant).
Affecter un incidenteffet externe : demande une confirmation avant une exécution manuelle	action	Affecte un incident à un groupe et/ou un utilisateur.
Rechercher des enregistrements	action	Recherche dans une table avec une requête encodée (pagination bornée, 1 000 au plus).
Créer une demande de changementeffet externe : demande une confirmation avant une exécution manuelle	action	Crée une demande de changement (table change_request).
Obtenir une demande de changement	action	Lit une demande de changement par numéro ou sys_id.
Nouvel incident	déclencheur	Démarre le workflow pour chaque nouvel incident correspondant au filtre.
Incident modifié	déclencheur	Démarre le workflow à chaque modification d'un incident correspondant au filtre.
Changement d'état ou d'affectation	déclencheur	Démarre le workflow quand l'état, le groupe d'affectation ou la personne affectée d'un incident change (valeurs précédentes fournies).

Connexion

Utilisez un compte d'intégration dédié aux droits limités (rôles itil ou personnalisés sur les tables nécessaires), avec le fuseau horaire GMT. OAuth 2.0 est recommandé ; l'authentification Basic n'est à utiliser que si l'instance l'autorise.

Documentation

ServiceNow

Intégration maintenue par Orkyvo (non certifiée par ServiceNow) utilisant la Table API (/api/now/table), disponible sur toutes les versions supportées de ServiceNow.

Connexion

Profil	Quand l'utiliser	Prérequis côté instance
OAuth 2.0 – identifiants client (recommandé)	Intégration machine à machine	System OAuth → Application Registry : point de terminaison OAuth pour clients externes, associé à un utilisateur d'intégration ; propriété `glide.oauth.inbound.client.credential.grant_type.enabled` = `true` (Washington DC ou ultérieur).
OAuth 2.0 – mot de passe	Instance plus ancienne sans « client credentials »	Application OAuth + compte d'intégration (identifiant et mot de passe).
Basic	Seulement si l'instance l'autorise	Authentification Basic non désactivée pour l'API REST (de nombreuses instances la refusent ou exigent l'authentification multifacteur).

Le jeton OAuth est demandé à https://<instance>/oauth_token.do au début de chaque exécution, jamais enregistré ni journalisé. Les secrets (client secret, mot de passe) sont chiffrés et masqués partout.

Compte d'intégration aux droits limités (pas d'admin) :

incidents : rôle itil ou rôle personnalisé avec lecture / écriture sur incident ;
demandes de changement : écriture sur change_request ;
sélecteurs : lecture de sys_user_group, sys_user et sys_choice (facultatif : la saisie manuelle reste possible) ;
fuseau horaire du compte : GMT (les déclencheurs comparent des dates UTC ; « Tester la connexion » le vérifie).

« Tester la connexion » obtient un jeton puis lit un incident (sysparm_limit=1) : aucune écriture.

Actions

Action	Appel	Remarques
Créer un incident	`POST /api/now/table/incident`	Identifiant de corrélation recommandé : s'il existe déjà un incident avec ce `correlation_id`, il est renvoyé (`existing: true`) au lieu d'un doublon.
Obtenir un incident	`GET /api/now/table/incident/{sys_id}`	Numéro (`INC…`) ou sys_id.
Mettre à jour un incident	`PATCH …/incident/{sys_id}`	Champs renseignés uniquement. État : valeurs lues sur votre instance (`sys_choice`).
Note de travail / commentaire	`PATCH` (`work_notes` ou `comments`)
Affecter un incident	`PATCH` (`assignment_group`, `assigned_to`)	sys_id, ou noms affichés avec « Valeurs de référence : noms affichés ».
Rechercher des enregistrements	`GET /api/now/table/{table}?sysparm_query=…`	Requête encodée, 100 par page, 1 000 au plus ; `total` d'après `X-Total-Count`.
Créer / obtenir une demande de changement	`change_request`	Type normal, standard ou urgent ; corrélation anti-doublon.

Valeurs propres à l'instance. Aucun état, catégorie, code de clôture ou champ personnalisé n'est supposé : renseignez les valeurs techniques de votre instance, et utilisez Champs supplémentaires (JSON) pour les champs u_…. Les politiques de données, champs obligatoires et ACL de l'instance s'appliquent : une écriture refusée renvoie le message de ServiceNow (ex. « Data Policy Exception »).

Pas de relance aveugle. Une création n'est jamais relancée automatiquement après une réponse réseau perdue (« Résultat incertain ») ; avec un identifiant de corrélation, une relance manuelle est sans risque de doublon.

Déclencheurs : interrogation persistante (mécanisme choisi)

ServiceNow peut envoyer des webhooks sortants (*Business Rules* + *Outbound REST Message*), mais cela exige un développement et des droits d'administration sur l'instance. Orkyvo utilise donc une interrogation côté serveur de la Table API, sans rien installer sur l'instance :

Premier passage : le point de départ est la date du dernier incident existant (horloge de l'instance) ; rien n'est rejoué.
Passages suivants (toutes les 60 s par défaut, 30 s minimum) : lecture des incidents dont sys_created_on / sys_updated_on ≥ curseur, triés par date, 300 au plus par passage (rattrapage au passage suivant).
Chaque événement a un identifiant stable (sys_id + sys_mod_count) : les doublons sont écartés, y compris après un redémarrage.
Le curseur est conservé en base et repris après un redémarrage du worker ; il n'avance qu'une fois les exécutions créées.
En cas d'erreur (401, 429, indisponibilité), l'intervalle double jusqu'à 1 h ; l'erreur s'affiche dans l'éditeur.

« Changement d'état ou d'affectation » compare l'état, le groupe et la personne affectée avec les dernières valeurs connues (1 000 incidents suivis au plus) et fournit les valeurs précédentes. Un incident est suivi à partir de sa première modification observée.

Erreurs

401 identifiants refusés · 403 ACL ou politique de données · 404 enregistrement introuvable ou invisible · 409 conflit · 429 limite de débit (relance des lectures selon Retry-After) · 5xx instance indisponible.

Limites

1 000 enregistrements par recherche ; 100 événements par passage d'interrogation.
Tests automatisés sur API simulées ; test réel : voir docs/INTEGRATIONS.md (instance *Personal Developer Instance* recommandée).