Verwendung des Ersteller-Frameworks für ausgehende Benachrichtigungen

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 2 Minuten Lesedauer

    • Das Ersteller-Framework wählt das Ereignis aus dem aus ServiceNow Instanz und sendet die ausgehende Benachrichtigung an das externe System. Sie können die Details der Benachrichtigung aus dem Messaging-Service nutzen, 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 Aufgaben festgelegt sind .

    Tabelle : 1. Systemeigenschaften des Ersteller-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:
    • Auftauchen : Gesamtfehler.
    • Warnung : Systembeschädigung einer Datenbank, z. B.
    • krit : Wird normalerweise für Hardwarefehler verwendet, z. B..
    • Fehler : Alle Fehler.
    • Warnung : Alle Warnungen
    • Hinweis : Mögliche Aktion erforderlich, aber nicht unbedingt.
    • Info : Keine Aktion erforderlich.
    • Debuggen : Wird im Allgemeinen nicht verwendet, außer zum Erfassen aller Elemente für die Fehlersuche.

    Standardwert: Fehler

    		Zeichenfolge
    sn_api_notif_mgmt.Herausgeber_Nachricht_Bus_Konfiguration 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 Zeitplanerausführung aus der eingehenden Warteschlange abruft. Dieser Wert wird in Verbindung mit verwendet sn_api_notif_mgmt.inboundqueue.batch.limitParameter.
    • Standardwert: 200
    • Andere mögliche Werte: nach Bedarf

    Wenn beispielsweise das Batch-Limit auf 50 festgelegt ist und die max-Datensätze auf 200 festgelegt sind und die Anzahl der Datensätze in der eingehenden Warteschlange 130 beträgt, ruft der Planer drei verschiedene Batches von Datensätzen 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 Batches 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 Planer benötigt, um mehrere Batches zu verarbeiten, 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 erwerben.
    • 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: 90000
    • 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 erhalten.
    • Typ: Ganzzahl
    • Standardwert: 100
    • Andere mögliche Werte: nach Bedarf
    		 Ganzzahl

    Ersteller-Framework-Workflow

    Wenn das System ein Ereignis an die Bereitstellungstabelle sendet, werden die folgenden Schritte als ausgeführt Teil des Ersteller-Framework-Mechanismus:
    1. Der Planer wählt in einem vorkonfigurierten Intervall eine Reihe von Datensätzen aus und sendet dann Glide-Snapshots an den Ereignisprozessor.
    2. Das System konvertiert den Glide-Snapshot basierend auf dem Ereignistyp in eine TMF 688-Beschwerdereignisnutzlast.

      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 Erstellererereignisbenachrichtigungen finden Sie unter Producer Event Notification Framework developer guide.