Verwenden des Ersteller-Frameworks für ausgehende Benachrichtigungen

  • Freigeben Version: Washingtondc
  • Aktualisiert 1. Februar 2024
  • 2 Minuten Lesedauer

    • Das Ersteller-Framework wählt das Event aus der Instanz ServiceNow aus und sendet die ausgehende Benachrichtigung an das externe System. Sie können die Details der Benachrichtigung aus dem Messaging-Service abrufen, der in Ihrem externen System installiert ist.

    Systemeigenschaften

    Sie müssen die Systemeigenschaften konfigurieren, um das Ersteller-Framework für ausgehende Benachrichtigungen zu verwenden. In der folgenden Tabelle wird die Liste der Systemeigenschaften erläutert, die für die geplanten Aufgabenfestgelegt werden.

    Tabelle : 1. Systemeigenschaften des Produzenten-Frameworks
    Eigenschaft Beschreibung Typ
    sn_api_notif_mgmt.event.log
    Protokollierungsebene, die in die Debug-Protokolle geschrieben werden soll. Sie können die folgenden Protokollierungsebenen auswählen:
    • notfall: Gesamtausfall.
    • Warnung: Systembeschädigung einer Datenbank, z. B.
    • crit: Wird normalerweise für Hardwarefehler verwendet, z. B.
    • err: Beliebige Fehler.
    • warning: Alle Warnungen
    • Hinweis: Mögliche Aktion erforderlich, aber nicht unbedingt.
    • Info: Keine Aktion erforderlich.
    • debuggen: Wird im Allgemeinen nicht verwendet, außer um alles für die Fehlersuche zu erfassen.

    Standardwert: err

    		 Zeichenfolge
    sn_api_notif_mgmt.publisher_message_bus_configuration Definiert, ob Nachrichten mit dem Hermes Messaging Service, dem Open Message Bus oder beiden Nachrichtenbussen veröffentlicht werden. Sie können die folgenden Werte verwenden:
    • openMessageBus
    • hermes
    • beides

    Standardwert: openMessageBus

    		 Zeichenfolge
    sn_api_notif_mgmt.inboundqueue.maxrecords Maximale Anzahl von Datensätzen, die der Planer für eine Planerausführung aus der eingehenden Warteschlange abruft. Dieser Wert wird in Verbindung mit dem Parameter sn_api_notif_mgmt.inboundqueue.batch.limit verwendet.
    • Standardwert: 200
    • Andere mögliche Werte: nach Bedarf

    Beispiel: Wenn die Batch-Grenze auf 50 und maxrecords auf 200 festgelegt ist und die Anzahl der Datensätze in der eingehenden Warteschlange 130 beträgt, ruft der Scheduler drei verschiedene Datensatz-Batches in einer einzigen Ausführung ab. zwei mit 50 Datensätzen und einer mit 30 Datensätzen. Wenn die Anzahl der Datensätze in der eingehenden Warteschlange 220 beträgt, ruft der Planer vier Stapel mit 50 Datensätzen ab, und die verbleibenden 20 Datensätze werden erst bei der nächsten Ausführung des Planers verarbeitet.

    Beim Festlegen dieses Werts müssen Sie auch die Zeit berücksichtigen, die der Scheduler für die Verarbeitung mehrerer Batches benötigt, und den Wert sn_api_notif_mgmt.schedule.max.runtime entsprechend festlegen.

    		 Ganzzahl
    sn_api_notif_mgmt.inboundqueue.batch.limit Anzahl der Datensätze, die der Planer in einem Batch aus der eingehenden Warteschlange abruft und verarbeitet.
    • Standardwert: 200
    • Andere mögliche Werte: nach Bedarf
    		 Ganzzahl
    sn_api_notif_mgmt.glide.mutex.script.maxspins Maximale Anzahl von Versuchen, eine Mutex-Sperre in den Datensätzen der eingehenden Warteschlange zu erfassen.
    • Typ: Ganzzahl
    • Standardwert: 100
    • Andere mögliche Werte: nach Bedarf
    		 Ganzzahl
    sn_api_notif_mgmt.schedule.max.runtime Die maximale Zeit in Millisekunden, die die geplante Aufgabe ausgeführt werden kann, bevor sie fehlschlägt und einen Fehler meldet.
    • Typ: Ganzzahl
    • Standardwert: 90.000
    • Andere mögliche Werte: nach Bedarf
    		 Ganzzahl
    sn_api_notif_mgmt.glide.mutex.script.spinwait Maximale Wartezeit in Millisekunden zwischen Versuchen, eine Mutex-Sperre für die Datensätze in der eingehenden Warteschlange zu erfassen.
    • Typ: Ganzzahl
    • Standardwert: 100
    • Andere mögliche Werte: nach Bedarf
    		 Ganzzahl

    Workflow des Produzenten-Frameworks

    Wenn das System ein Event an die Staging-Tabelle sendet, werden die folgenden Schritte als Teil des Ersteller-Framework-Mechanismus ausgeführt:
    1. Der Scheduler wählt eine Anzahl von Datensätzen in einem vorkonfigurierten Intervall aus und sendet dann Glide-Snapshots an den Event-Prozessor.
    2. Das System konvertiert den Glide-Snapshot basierend auf dem Event-Typ in eine TMF 688-Beschwerdeereignisnutzlast.

      Weitere Informationen zu den Methoden zum Definieren und Generieren der TMF-konformen Nutzlasten für Problemticket-Ereignisse finden Sie unter TopicAPIUtilsOOB - Scoped.

    3. Das System überprüft, ob die Benachrichtigungskonfiguration für Hermes Kafka oder den offenen Nachrichtenbus vorgesehen ist.

      Weitere Informationen zum Konfigurieren des Frameworks für Ersteller-Event-Benachrichtigungen finden Sie unter Producer Event Notification Framework developer guide.