Intégrations bidirectionnelles de création de tickets pour les incidents
Une intégration bidirectionnelle échange des données entre votre instance de ServiceNow et un système tiers afin que les informations d'incident soient synchronisées entre les systèmes.
- Définitions complètes des mappages de champs.
- Standardisation des lieux des transformations : entrant, sortant ou les deux.
- Prise en compte de la propriété des données de référence.
- Méthodes de mise à jour sur une base continue.
Implémentation de la gestion des erreurs. Inclusion de toutes ces implémentations dans le plan d'intégration.
Bien que les implémentations bidirectionnelles soient développées en fonction de leurs mérites, vous pouvez développer un cadre de travail dans la ServiceNow AI Platform qui peut être réutilisé, par exemple des règles de validation axées sur les données.
Contenu du plan d'intégration
- Planifiez le contenu pour tous les aspects nécessaires à une intégration bidirectionnelle.
- Modèles d'état pour chaque organisation.
- Définitions de règles métier pour conserver la synchronisation des tickets.
- Exigences relatives au stockage de l'historique des transactions individuelles. Si cette forme d'audit est une exigence, envisagez de créer une table d'interface qui est renseignée avant la création et la mise à jour de la table de destination.
- Règles de transformation pour tous les éléments de données.
- Chronologies selon lesquelles les données de référence sont transportées vers le système d'information. Inclusion des exigences pour effectuer les transformations avant d'envoyer les données vers et depuis chaque système.
- Énoncé de la propriété des données de référence à toutes les étapes.
- Mise à jour des définitions de schéma.
Exemple utilisant des ensembles d'importation et des services Web
Dans cette implémentation, l'authentification des données est effectuée avant l'insertion dans le jeu d'importation. Les cartes de transformation et les scripts s'exécutent avant que les données n'atteignent la table Incident. La table Incident est utilisée pour stocker l'historique des enregistrements d'incidents. Pour le chemin de données sortant, la table cible pourrait déclencher des règles métier avant que les données ne soient mises en file d'attente dans le service Web sortant.
Exemple utilisant des ensembles d'importation et la file d'attente ECC
Une variante d'implémentation pour le chemin entrant serait d'utiliser une table de jeu d'importation (dans notre exemple la table Interface d'incident) pour stocker les données d'historique. La validation des données est également effectuée, et vous pouvez effacer les exceptions à l'aide d'un traitement ou d'une intervention manuelle. La table Incident utilise une table d'information tierce comme référence, et les messages sont générés en fonction des règles métier.
L'implémentation de ce type d'intégration implique un composant de service Web pour applications tierces pour les données entrantes. La file d'attente ECC est recommandée pour les données sortantes.