Selbstkorrektur-API

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

    • Stellt einen Endpunkt zum Erstellen oder Verwalten von Next Experience-Problemen bereit.

    Die Selbstkorrektur-API ist als benutzerdefinierte geskriptete REST-API verfügbar. Diese API erfordert das Plugin „Self Remediation Framework“ (self-remediation-framework) und die Rolle sn_srf.experience_issue_create.

    Jeder DEX/DEM - -Provider kann die Selbstkorrektur-API verwenden, um ein Experience-Problem zu erstellen, wenn er ein Problem am Endpunkt eines Benutzers erkennt. Das erstellte Experience-Problem fördert die Interaktion mit dem Benutzer und hilft ihm, das Problem selbst zu lösen. Die Self Remediation API kann von allen internen oder externen DEM/DEX-Providern verwendet werden.

    Um diese API zu verwenden, stellen Sie sicher, dass die folgenden Tabellen mit Datensätzen ausgefüllt sind:

    • sn_srf_issue_registry_template
    • sn_srf_issue_registry
    • sn_srf_resolution
    • sn_srf_notification_content
    • sn_srf_provider

    Selbstkorrektur – CREATE /sn_srf/self_remediation/experience_issue/create

    Ermöglicht Anbietern das Erstellen eines Experience-Problems, wenn der Anbieter DEM/DEX ein Problem am Endpunkt des Anwenders erkennt.

    URL-Format

    Standard-URL: /api/sn_srf/self_remediation/experience_issue/create

    Unterstützte Anforderungsparameter

    Tabelle : 1. Pfadparameter
    Name Beschreibung
    api_version Optional. Version des Endpunkts, auf den zugegriffen werden soll. Zum Beispiel v1 oder v2. Geben Sie diesen Wert nur an, um eine andere Endpunktversion als die neueste zu verwenden.

    Datentyp: Zeichenfolge
    Tabelle : 2. Abfrageparameter
    Name Beschreibung
    Keine
    Tabelle : 3. Anforderungstextparameter (XML oder JSON)
    Name Beschreibung
    endpoint Erforderlich. Das Objekt endpoint gibt Details für das Experience-Problem mithilfe von Schlüsseln an, um Benutzer- und Konfigurationselementinformationen (CI) zu erkennen. Übergeben Sie mindestens einen Schlüssel, damit das Framework den Benutzer identifizieren kann. Ungültige Schlüssel geben einen Fehler zurück.

    Datentyp: Objekt

    
--data “{
  "endpoint": {
    "CI": "String",
    "user_id": "String",
    "user_name": "String",
    "email": "String"
  },
    endpunkt.user_id Optional. Sys_id des Benutzers, für den das Problem erkannt wurde.

    Datentyp: Zeichenfolge
    endpoint.user_name Optional. Benutzername des Benutzers, für den das Problem erkannt wurde.

    Datentyp: Zeichenfolge
    endpunkt.email Optional. E-Mail-Adresse des Benutzers, für den das Problem erkannt wurde.

    Datentyp: Zeichenfolge
    endpoint.CI Optional. Sys_id des CI (Gerät), auf dem das Problem erkannt wurde

    Datentyp: Zeichenfolge
    Ausgabecode Erforderlich. Identifiziert das aufgetretene Problem eindeutig. Der Problemcode muss in der Instanz des Kunden verfügbar sein und bereitgestellt werden. Der Parameter gibt einen Fehler zurück, wenn ein leeres oder ungültiges Problem angegeben wird.

    Datentyp: Zeichenfolge
    Anbieter Erforderlich. Eindeutiger Code für den Anbieter. Dieser Code muss mit provider_code in sn_srf_provider in der Instanz des Kunden übereinstimmen.

    Datentyp: Zeichenfolge
    input_parameters Optional. Die gesendeten Eingabeparameter werden an die konfigurierte Auflösung übergeben (z. B. Subflow, Flow-Aktion oder CI-Aktion).

    Datentyp: Objekt

    "input_parameters": {
    "process_id": "Number"
  }
    Investigative_Details Optional. Gibt alle Details an, die für eine manuelle Untersuchung nützlich sein könnten, wenn die PUE-Auflösung (Power Usage Effektivität) fehlschlägt. Die Untersuchungsdetails werden in den Incident kopiert, der als Fallback erstellt wird, wenn die PUE-Auflösung fehlschlägt.

    Datentyp: Objekt

    "investigative_details": {
    "cpu usage": "String",
    "processes running": "String",
    "available memory": "String"
  }
    Experience_ID Optional. Wenn der Anbieter das Experience-Problem mit einer bestimmten Experience_ID (nicht sys_id) erstellen möchte, senden Sie es in der Anforderung. Dies kann zur weiteren Nachverfolgung in Experience-Problemverkettungsfällen verwendet werden.

    Datentyp: Zahl

    Header

    Die folgenden Anforderungs- und Antwortkopfzeilen gelten nur für diese HTTP-Aktion oder für diese Aktion auf eine bestimmte Weise. Eine Liste der allgemeinen Header, die in der REST-API verwendet werden, finden Sie unter Unterstützte REST-API-Header.

    Tabelle : 4. Anforderungskopfzeilen
    Kopfzeile Beschreibung
    Akzeptieren Datenformat des Antworttexts. Unterstützte Typen: application/json oder application/xml.

    Standard: application/json
    Tabelle : 5. Antwortkopfzeilen
    Kopfzeile Beschreibung
    Keine

    Statuscodes

    Die folgenden Statuscodes gelten für diese HTTP-Aktion. Eine Liste der möglichen Statuscodes, die in der REST-API verwendet werden, finden Sie unter HTTP-Antwortcodesder REST-API.

    Statuscode Beschreibung
    200 Ein Experience-Problem wurde erfolgreich erstellt. Gibt die Experience_Id zurück.
    400 Ungültige Anforderung. Geben Sie Endpunktdetails an.

    In der Anforderung wurde ein leeres Objekt endpoint gesendet.
    400 Ungültiger Problemcode. Geben Sie einen gültigen Problemcode an.

    Ein leerer issue_code wird in der Anforderung gesendet.
    400 Ungültiger Anbieter. Geben Sie einen gültigen Anbieter an.

    In der Anforderung wird ein leerer Provider gesendet.
    400 Ungültiger Problemcode oder Anbieter. Geben Sie gültige Details an.

    Problem kann in Kundeninstanz nicht erkannt werden. Überprüfen Sie die Details issue_code und provider.
    400 Problemcode hat keine richtige Lösung.

    Im PUE-Framework ist keine gültige Lösung für das identifizierte Problem konfiguriert.
    400 Anwender konnte nicht aus Endpunktdetails aufgelöst werden. Geben Sie gültige Details an.

    Dieser Fehler wird zurückgegeben, wenn die PUE-Framework-ID den Benutzer nicht anhand der angegebenen Endpunktdetails identifizieren kann.
    400 Ein Experience-Problem wird mit dem angegebenen Problemcode für den angegebenen Anwender gelöst.

    Das angegebene Experience-Problem befindet sich derzeit im Status „In Bearbeitung“ oder „Offen“.
    400 Vorhandenes Experience-Problem mit dem angegebenen experience_id wird noch ausgeführt oder ist geschlossen.

    Dieser Fehler tritt auf, wenn sich ein Experience-Problem in einem Verkettungsszenario befindet (z. B. wenn ein neuer issue_code -Schlüssel mit einem vorhandenen experience_id gesendet wird und das frühere Experience-Problem noch ausgeführt wird oder sich im Status „Geschlossen“ befindet).

    Das Experience-Problem mit dieser Experience_ID muss sich im Status „action_wait“ befinden, um einen neuen Issue_code mit der vorherigen Experience_ID zu senden.
    400 Beim Erstellen des Experience-Problems ist ein Fehler aufgetreten.

    Dies weist auf einen technischen Fehler hin.

    Antworttextparameter (JSON oder XML)

    Name Beschreibung
    experienceId Die Experience-ID-Nummer des erstellten Experience-Problems.

    cURL-Anforderung

    Im folgenden Beispiel wird ein Experience-Problem für Benutzer Abel Tuter erstellt.

    curl  "http://instance.servicenow.com//api/sn_srf/self_remediation/experience_issue/create" \
--request POST \
--header "Accept:application/json" \
--user 'username':'password'
--data “{
  "endpoint": {
    "CI": "d049b28e936aa1106f98f6db5cba10d5",
    "user_id": "62826bf03710200044e0bfc8bcbe5df1",
    "user_name": "abel.tuter",
    "email": ""
  },
  "issue_code": "100",
  "provider": "sn",
  "experience_id": "09ed4830f393739df33",
  "input_parameters": {
    "process_id": "10644"
  },
  "investigative_details": {
    "cpu usage": "78%",
    "processes running": "35",
    "available memory": "23%"
  }
}”\

    Der Antworttext gibt die Experience-ID zurück, die angibt, dass die Problemerstellung erfolgreich war.

    { 
  "result": { 
    "experience_id": “xxxxxxxxxxxxxx”
  } 
}