Bidirektionale Incident-Ticketintegrationen
Bei einer bidirektionalen Integration werden Daten zwischen Ihrer ServiceNow-Instanz und einem System eines Drittanbieters ausgetauscht, sodass Incident-Informationen zwischen den Systemen synchronisiert werden.
- Umfassende Definitionen von Feldzuordnungen.
- Standardisierung, wo Transformationen stattfinden: Eingehend, Ausgehend oder beides.
- Berücksichtigung des Eigentums an Referenzdaten.
- Wie werden Updates fortlaufend durchgeführt?
Implementieren Sie die Fehlerbehandlung. Fügen Sie alle diese Implementierungen in den Integrationsplan ein.
Während bidirektionale Implementierungen für sich entwickelt werden, können Sie ein Framework auf der Now Platform entwickeln, das wiederverwendet werden kann, z. B. datengesteuerte Validierungsregeln.
Inhalte des Integrationsplans
- Planen Sie Inhalte für alle Aspekte, die für eine bidirektionale Integration benötigt werden.
- Statusmodelle für jede Organisation.
- Business Rule-Definitionen für die Synchronisierung der Tickets.
- Anforderungen zum Speichern des Verlaufs einzelner Transaktionen. Wenn diese Art der Prüfung erforderlich ist, sollten Sie eine Schnittstellentabelle erstellen, die vor dem Erstellen und Aktualisieren der Zieltabelle ausgefüllt wird.
- Transformationsregeln für alle Datenelemente.
- Zeitachsen für den Zeitpunkt, zu dem Referenzdaten zum Informationssystem transportiert werden. Fügen Sie Anforderungen ein, um Transformationen vor dem Senden der Daten an und von jedem System durchzuführen.
- Referenzdatenbesitz in allen Phasen.
- Aktualisieren Sie Schemadefinitionen.
Beispiel mit Import Sets und Webdiensten
In dieser Implementierung wird die Datenauthentifizierung vor dem Einfügen in das Import Set durchgeführt. Transformationszuordnungen und -skripts werden ausgeführt, bevor die Daten die Incident-Tabelle erreichen. Die Incident-Tabelle wird verwendet, um den Verlauf der Incident-Datensätze zu speichern. Für den ausgehenden Datenpfad kann die Zieltabelle Business-Rules auslösen, bevor die Daten im ausgehenden Webdienst in die Warteschlange gestellt werden.
Beispiel mit Import Sets und der ECC-Warteschlange
Eine Implementierungsvariante für den eingehenden Pfad wäre die Verwendung einer Import Set-Tabelle (in diesem Beispiel die Incident Interface-Tabelle) zum Speichern historischer Daten. Die Datenüberprüfung wird jetzt ebenfalls durchgeführt, und Sie können Ausnahmen bei der Verarbeitung oder durch manuelle Intervention löschen. Die Incident-Tabelle verwendet eine Drittanbieter-Informationstabelle als Referenz, und Nachrichten werden basierend auf Business Rules generiert.
Zur Implementierung dieser Art von Integration gehört eine Webdienst-Komponente für Anwendungen von Drittanbietern für eingehende Daten. Die ECC-Warteschlange wird für ausgehende Daten empfohlen.