CA SDM Text API-Schnittstelle

Dieser Artikel enthält die folgenden Themen:
casm173
Dieser Artikel enthält die folgenden Themen:
Übersicht der Text API
Die
Text-API
ist eine Schnittstelle, über die Sie textbasierte Objekte in der CA SDM-Datenbank, zum Beispiel Issues, Anfragen, Kontakte und Assets, erstellen und aktualisieren können. Bei der Verwendung der Text-API können Sie den meisten Feldern Werte zuweisen, auf die Anwender zugreifen können.
Für CA SDM müssen alle Eingaben im UTF-8-Format vorliegen. Andernfalls können Daten beschädigt werden. Mit dem Dienstprogramm "pdm_unconv" können Sie Daten aus einem lokalen Zeichensatz in UTF-8 und von UTF-8 in einen lokalen Zeichensatz konvertieren.
Sie können über folgende Schnittstellen auf die Text-API zugreifen:
  • Befehlszeile
  • E-Mail
Eine Alternative zur Text-API für die anwendungsübergreifende Integration sind Webservices.
Befehlszeilenschnittstelle
Mit dem Befehl
pdm_text_cmd
können Sie die Befehlszeilenschnittstelle der Text-API aktivieren. Sie geben bestimmte Informationen, zum Beispiel die zu verarbeitende Tabelle und die auszuführende Operation, mit Hilfe von Parametern für den Befehl "pdm_text_cmd" an.
Die Eingabe in die Text-API wird an den Befehl "pdm_text_cmd" in Form einer Eingabedatei oder direkt von STDIN übergeben.
Wenn Sie Parameter über die Eingabeaufforderung weitergeben, verwenden Sie STRG+Z in Windows und STRG+D in POSIX.
Sie können einzelne oder doppelte Anführungszeichen nicht als Parameter für die Befehle "bop_cmd" und "pdm_text_nxd" verwenden.
Eingabeformat
Die Eingabe in die Text-API geschieht folgendermaßen:
  • In der Befehlszeilenschnittstelle wird geschieht die Eingabe typischerweise in einer Textdatei, die an den Befehl "
    pdm_text_cmd
    " übergeben wird.
  • In der E-Mail-Schnittstelle geschieht die Eingabe im Text der E-Mail. Sie geben einen regulären Ausdruck an, um die Zielobjektkennungen zu suchen.
Sie formatieren die Text-API-Eingabe auf die gleiche Weise unabhängig von der verwendeten Schnittstelle.
Das grundlegende Format für die Eingabe sieht wie folgt aus:
%keyword=value
oder
%PROPERTY={{property_label}}value
Das normale Verhalten von Text-API-Befehlen hat die folgenden Ausnahmen, wobei der zuletzt angezeigte von zwei oder mehreren, in Konflikt stehenden Befehlen Vorrang hat:
  • Wenn eine Meldung mehrere gültige Ticket-ID-Artefakte, die mit der Filterzeichenfolge der Postfachregel übereinstimmen, oder mehrere Text-API-Ticket-ID-Befehle enthält, wird die erste Übereinstimmung verwendet. Ebenso überschreibt ein Ticket-ID-Artefakt, das unter Verwendung der Filterzeichenfolge der Postfachregel identifiziert wird, einen beliebigen Text-API-Ticket-ID-Befehl, unabhängig davon, welcher zuerst angezeigt wird.
  • Wenn eine Meldung mehrere Protokollkommentar-Text-API-Befehle enthält, werden alle Kommentare bereitgestellt, obwohl die Reihenfolge, in der sie im Ticket-Aktivitätsprotokoll erscheinen, variieren kann.
Alle Ticket-ID-Artefakte, die mit dem Filter übereinstimmen - gültig oder anderweitig - und Text-API-Ticket-ID-Befehle innerhalb der Meldung - anwendbar oder anderweitig, angewandt oder anderweitig - werden auskommentiert, bevor die Meldung bereitgestellt wird. Die Ticket-ID-Artefakte, die durch die Postfachregelfilter identifiziert werden, werden als -((...))- angezeigt. Vorangestellte Prozentzeichen (%) in Text-API-Ticket-ID-Befehlen werden in zwei Klammer-auf-Symbole vor und zwei Klammer-zu-Symbole nach dem Befehl konvertiert. Wenn ein Text-API-Ticket-ID-Befehl nach einem anderen Text-API-Befehl mit einem Protokollkommentar (%LOG=…) erscheint, wird der auskommentierte Text-API-Ticket-ID-Befehl zu einem separaten Protokollkommentar.
Der Protokollkommentar ist der einzige Text-API-Befehl, der mehrmals in einer Meldung erscheinen kann und trotzdem bei jedem Vorkommen angewendet wird. Bei allen anderen Befehlen verwendet die Text-API nur den letzten vorkommenden Befehl, da mehrmals vorkommende Befehle zueinander in Konflikt stehen. Mehrere Protokollkommentarbefehle stellen separate Protokollkommentarmeldungen im Ticket bereit; dies geschieht nicht notwendigerweise in einer besonderen Reihenfolge.
Wenn ein Text-API-Ticket-ID-Befehl in der Meldung entweder am Anfang der Meldung oder zwischen zwei anderen Text-API-Befehlen erscheint, wird er zusätzlich in einen Protokollkommentar konvertiert. Wenn der vorherige Befehl ein Protokollkommentar (%LOG=…) oder eine Aktualisierungsbeschreibung (%DESCRIPTION=…) ist, wird er an diesen Befehl angehängt und wird nicht zu einem separaten Protokollkommentar.
So verwendet Text-API Schlüsselwörter
Sie können zwei Arten von Schlüsselwörtern als Eingabe in der Text-API verwenden.
  • Definitionen im Abschnitt [KEYWORDS] der Datei
    "text_api.cfg"
    : Dieser Typ ist eine Gruppe von Schlüsselwörtern, die sich direkt auf die Felder der verschiedenen Tabellen beziehen, die Sie aktualisieren können. Zum Beispiel sind hier die meisten der Felder im Formular "Issue – Detail" definiert. Mit diesen Schlüsselwörtern können Sie Werte für Felder in dem Datensatz festlegen, den Sie aktualisieren oder erstellen. Zum Beispiel stellt die folgende Zeile die Priorität des Issue auf 5 ein:
    %PRIORITY=5
    Der Abschnitt [KEYWORDS] der Datei
    "text_api.cfg"
    listet alle Schlüsselwörter auf. Sie können zusätzliche Schlüsselwörter definieren (zum Beispiel, um Text-API-Zugriff auf Felder zu gewähren, die Sie beim Anpassen Ihres Datenbankschemas hinzugefügt haben).
  • Die folgenden besonderen Schlüsselwörter werden immer folgendermaßen definiert, ungeachtet der Inhalte der Datei "
    text_api.cfg
    ":
Schlüsselwort
Beschreibung
ASSET
Wird verwendet, um einem Ticket ein Element anzuhängen (gültig für Anfragen, Issues und Changes). Der angegebene Wert ist der Elementname, der bereits existieren muss. Sie können dieses Schlüsselwort mehrmals angeben, da einem Ticket mehrere Elemente angehängt werden können.
ATTACHMENT
Wird intern von der E-Mail-Schnittstelle verwendet, um einem Ticket E-Mail-Anhänge hinzuzufügen.
DESCRIPTION
Gibt den Wert an, der für das Beschreibungsfeld des Tickets verwendet werden soll. Dieses Schlüsselwort wird übernommen, wenn eine Eingabe an die Text-API ohne Angabe eines expliziten Schlüsselwortes gesendet wird. Dieses Schlüsselwort wird automatisch vom Post-Vernichter angewandt, wenn die Meldung mit keinem Schlüsselwort anfängt, aber ein Ticket-ID-Artefakt oder Schlüsselwort enthält.
Sie können die Art und Weise ändern, wie das Schlüsselwort DESCRIPTION für Aktualisierungen behandelt wird.Verwenden Sie hierzu den folgenden Eintrag im Abschnitt [OPTIONS] der Datei "text_api.cfg":
UPDATE_DESC_IS_LOG
Wenn diese Option auf YES eingestellt ist, wird der Wert zur Erstellung eines Protokollkommentars verwendet. Wenn der Wert NO lautet, überschreibt der Wert das vorhandene Beschreibungsfeld.
FROM_EMAILFROM_EMAIL_OVERRIDE
Wird von der E-Mail-Schnittstelle für den Abgleich mit dem Feld für die E-Mail-Adresse im ca_contact-Datensatz verwendet. Er wird auch als "log_agent" für das Ticket verwendet. Wenn beides angegeben wird, wird FROM_EMAIL ignoriert.
FROM_EMAIL wird automatisch vom Mail Eater mit der Absenderadresse der Meldung gesetzt.
FROM_PERSID
Wird von der Befehlszeilenschnittstelle verwendet, um "log_agent" für eine Operation zu definieren (wenn zum Beispiel ein ca_contact-Datensatz keine Anwender-ID enthält). Dieses Schlüsselwort wird automatisch von "pdm_text_cmd" weitergegeben, wenn der Parameter "p" angegeben wird
.
Der Wert wird mit der persistent_id eines ca_contact-Datensatzes abgeglichen.
FROM_USERID
Wird nur in der Befehlszeilenschnittstelle verwendet, um log_agent für eine Operation zu definieren. Dieses Schlüsselwort wird automatisch von
"pdm_text_cmd"
weitergegeben, wenn der Parameter "u" angegeben wird. Der Wert wird mit der Anwender-ID eines Kontakts abgeglichen.
LOG
Wird zur Erstellung eines Protokolleintrags verwendet (gültig für Anfragen, Changes, Issues und Kontakte). Dieses Schlüsselwort wird automatisch vom Post-Vernichter angewandt, wenn die Meldung ohne ein Schlüsselwort anfängt, aber entweder ein Ticket-ID-Artefakt oder Schlüsselwort, oder ein DESCRIPTION-Schlüsselwort enthält.
PROPERTY
Wird zur Einstellung des Wertes für eine Eigenschaft verwendet (gültig nur für Anfragen, Changes und Issues). Im Gegensatz zu anderen Schlüsselwörtern, die von einem Gleichheitszeichen und einem Wert gefolgt werden, muss die PROPERTY-Schlüsselwortsyntax die Eigenschaft folgendermaßen angeben:
PROPERTY={{property_label}}value
Sie müssen
property_label
genauso angeben, wie es in der Datenbank angezeigt wird.
SEARCH
Wird nur in der Befehlszeilenschnittstelle verwendet und liefert eine Liste von Schlüsselwörtern zur Verwendung in einer Abfrage, um mehrere Tickets für ein Asset zu aktualisieren. Der Wert besteht aus einer Liste von Schlüsselwörtern, die in der Suche verwendet werden.
Eingabekonventionen für Schlüsselwörter
Die folgenden Konventionen beziehen sich auf die Formatierung bei der Schlüsselworteingabe:
  • Setzen Sie vor jedes Schlüsselwort (einschließlich PROPERTY) ein Prozentzeichen (%). Das Prozentzeichen muss in Spaltenposition eins stehen. Wenn die erste nichtleere Zeile der Eingabe kein Prozentzeichen am Anfang der Zeile hat, wird entweder %
    DESCRIPTION= oder %LOG=
    als das Präfix für die eingehenden Daten benutzt, je nachdem, ob ein Ticket-ID-Artefakt oder ein Schlüsselwort gefunden wurde. Wenn
    %DESCRIPTION
    gesetzt wird, wird der Inhalt der Meldung bis zum ersten Schlüsselwort als Ticket-Beschreibung bereitgestellt. Wenn
    %LOG=is
    gesetzt wird, wird der Inhalt der Meldung bis zum ersten Schlüsselwort als Protokollkommentar bereitgestellt.
  • Verwenden Sie innerhalb des Schlüsselwortes keine Leerzeichen zwischen dem %-Zeichen und dem Schlüsselwort oder zwischen dem Schlüsselwort und dem Gleichheitszeichen (=).
  • Setzen Sie Werte nicht in Anführungszeichen; alle Daten nach dem Gleichheitszeichen werden als Werte interpretiert.
  • Bei Schlüsselwörtern wird nicht zwischen Groß- und Kleinschreibung unterschieden.
  • Wenn die Eingabe doppelte Schlüsselwörter enthält, wird das letzte Schlüsselwort verwendet; ansonst ist die Reihenfolge, in der Sie die Schlüsselwort-/Wertpaare angeben, unwichtig.
  • Geben Sie Schlüsselwortwerte genauso an wie für das entsprechende Feld in der Web-Schnittstelle. Um zum Beispiel einen Analysten-Kontakttyp anzugeben, verwenden Sie
    %CONTACT_TYPE=Analyst
    , auch wenn in der Datenbank dieser Wert als Ganzzahl gespeichert ist. Das Schlüsselwort
    CONTACT_TYPE
    ist in
    text_api.cfg
    definiert und konvertiert den angegebenen Wert gemäß dem gespeicherten Wert.
    Ob beim Wert zwischen Groß- und Kleinschreibung unterschieden wird, hängt vom zugrunde liegenden DBMS ab.
  • Zeichenfolgendaten können sich über mehrere Zeilen erstrecken.
Formatieren von E-Mail-Nachrichten zum Aktualisieren eines Tickets
Anwender können E-Mail-Nachrichten formatieren, um Tickets zu erstellen oder zu aktualisieren.
So können Sie E-Mail-Nachrichten durch Ändern der folgenden Felder formatieren, um Tickets zu erstellen oder zu aktualisieren:
  • Bis
    Gibt den Mailboxnamen an, der dem für den berechtigten Anwender eingerichteten CA SDM-Kontakt zugewiesen ist.
  • Von:
    Gibt die Person an, die die E-Mail versendet. Die Person muss in der Tabelle
    "ca_contact"
    definiert sein, oder die Option
    "Anonymen Zugang erlauben"
    ist in der anzuwendenden Postfachregel angegeben.
    Die Absenderadresse wird i. d. R. der Konfiguration Ihres E-Mail-Clients entnommen und muss daher nicht für einzelne Nachrichten angegeben werden.
  • Anhänge
    Ermöglicht das Anhängen von Dokumenten und anderen Dateien an die E-Mail-Nachricht, um auf diese Weise Anhänge an das Text-API zu übermitteln.
  • Betreff
    Führt einen Abgleich mit Schlüsselwörter in einer Postfachregel-Filterzeichenfolge durch, insbesondere bei der Erstellung von Tickets.
  • Text
    Legt den Nachrichtentext der E-Mail unter Verwendung des Text-APIs fest. Sie können eines der Schlüsselwörter
    ISSUE_ID
    ,
    REQUEST_ID
    oder
    CHANGE_ID
    angeben, um ein entsprechendes Ticket zu erstellen oder zu aktualisieren.
Start- und Endtrennzeichen in E-Mail-Nachrichten
Einige E-Mail-Schnittstellen fügen Informationen am Anfang oder Ende von E-Mail-Nachrichten hinzu, die eine Fehlfunktion der E-Mail-Schnittstelle verursachen können (zum Beispiel MIME-Codierung).
Wenn Ihre E-Mail-Schnittstelle Informationen hinzufügt, können Sie die folgenden Trennzeichen verwenden:
"start-request" und "end-request". Die E-Mail-Schnittstelle ignoriert Informationen die vor "startrequest" angegeben wurden und nach "endrequest".
CA SDM Maileater unterstützt jetzt E-Mails in HTML und im Rich-Text-Format (RTF) für eingehende E-Mails.
Beispiel: Verwenden von "start-request"- und "end-request"-Trennzeichen
"start-request" message_body "end-request"
Text-API und Artefakte
Mit der Text-API wird der Betreff oder Text von E-Mail-Benachrichtigungen verarbeitet. Mit Postfachregeln können Sie Artefakte und Werte identifizieren, die die Text-API benutzt. Zum Beispiel können Sie die Regel für Incidents als "Incident:{{object_id}}" definieren. "Suche Incident:1234" wird für die Text-API als "%INCIDENT_ID=1234" übersetzt. 1234 ist die Ref_Num für den Incident. Weil das Artefakt in der E-Mail eindeutig und leicht zu finden sein muss, können Sie das Artefakt ausgeprägter machen, wie z. B. "%Incident:{{object_id}}%".
Das Zeichen nach dem Schlüsselwort {{object_id}} darf kein Buchstabe, keine Zahl, kein Komma, kein Schrägstrich (/), kein Pluszeichen (+) und kein Gleichheitszeichen (=) sein, weil diese Zeichen innerhalb eines Artefakts erscheinen können. Anderenfalls können Zeichen, die dem Artefakt folgen, als Teil des Wertes des Artefakts missverstanden werden, oder ein Zeichen innerhalb des Wertes des Artefakts kann als Zeichen, das dem Wert folgt, missverstanden werden.
Die Komponente "Mail Eater" führt folgende Schritte aus:
  1. Sucht das Artefakt in einer E-Mail (wie "Incident:1234"), das dem entsprechenden Ticket oder einem anderen von der Text-API unterstützten Objekt zugeordnet ist.
  2. Übersetzt das Artefakt in ein Text-API-Token (wie etwa "%INCIDENT_ID=1234").
  3. Die Komponente "Mail Eater" sendet die markierte Nachricht an die Text-API. Die Text-API verarbeitet die E-Mail, wendet den Text, Befehle oder beides auf das entsprechende Ticket an und erzeugt eine automatische Antwort-E-Mail, die zeigt, ob die erhaltene E-Mail-Nachricht erfolgreich angewendet wurde. Je nach den ausgeführten Aktionen wird eine Benachrichtigungs-E-Mail-Nachricht auch separat verschickt, um bestimmte Ereignisse, wie die Erstellung eines Tickets, anzuzeigen.
Einrichten von Benachrichtigungsantworten zum Aktualisieren von Tickets
Der Text-API-Dämon (pdm_text_nxd) erstellt und aktualisiert Tickets mit Informationen von externen Schnittstellen, wie beispielsweise Befehlszeile und E-Mail. Sie können Post für die Verwendung der Text-API einrichten, so dass Anwender (Kontakte) Tickets aktualisieren können, indem sie auf E-Mail-Benachrichtigungen antworten. Der Text der Antwort wird dem Ticket als Protokollkommentaraktivität hinzugefügt.
So richten Sie Benachrichtigungsantworten ein, um Tickets zu aktualisieren:
  1. Setzen Sie die Benachrichtigungsmethode, die der Kontakt verwendet, auf "pdm_mail -T
    reply_email_address
    " oder "pdm_mail -F
    reply_email_address".
    Die
    Antwort-E-Mail-Adresse
    gibt die Eingangsadresse für das Postfach an. Wenn der Kontakt bei einer E-Mail auf "Antwort" klickt, wird diese Adresse mit dem Feld "Von" oder der Antwortadresse der Nachricht ausgefüllt, auf die er antwortet.
    -T legt die Antwortadresse fest. -F legt die Adresse "Von" fest, die als Antwortadresse benutzt wird, wenn keine andere Adresse angegeben ist.
    Nicht alle E-Mail-Programme können eine Antwortadresse verarbeiten.
  2. Erstellen oder aktualisieren Sie eine Postfachregel mit Hilfe eines Text-API-Schlüsselwortes.
    Die benutzerdefinierten Artefakte in den Postfachregelfiltern ersetzen die folgenden Text-API-Schlüsselwörter:
Objekt
Text-API-Schlüsselwort
Kennung
Incident (Störung)
%INCIDENT_ID
Ref_num
Problem
%PROBLEM_ID
Ref_num
Request
%REQUEST_ID
Ref_num
Chg_ref_num
%CHANGE_ID
Chg_ref_num
Issue
%ISSUE_ID
Ref_num
  1. Erstellen oder aktualisieren Sie eine Benachrichtigungswortfolge, die der Regel entspricht.
  2. Erstellen oder aktualisieren Sie eine Meldungsvorlage, die die Benachrichtigungswortfolge verwendet.
  3. Aktualisieren Sie die in Schritt 2 erstellte Postfachregel, um die in Schritt 4 erstellte oder aktualisierte Meldungsvorlage festzulegen.
Nachdem der Anwender die Benachrichtigung erhalten und darauf geantwortet hat, werden die folgenden Aktionen automatisch ausgeführt:
  1. Wenn die Filterzeichenfolge gefunden wird, werden das dazugehörige Ticket-ID-Schlüsselwort und der vom Platzhalter angezeigte Wert an die Nachricht angehängt.
  2. Wenn ein passendes Ticket-ID-Artefakt gefunden wird, wird das entsprechende Ticket mit einem Protokollkommentar, einer neuen Beschreibung oder mit anderen Werten in Übereinstimmung mit dem Text, den Schlüsselwörtern und Befehlen in der Nachricht aktualisiert.
  3. Wenn kein passendes Ticket-ID-Artefakt gefunden wird, wird ein Ticket mit einer Beschreibung und mit anderen Parametern in Übereinstimmung mit dem Text, den Schlüsselwörtern und Befehlen in der Nachricht erstellt.
Einrichten einer Antwort auf eine Incident-Benachrichtigung – Beispiel
Dieses Beispiel zeigt, wie eine Antwort auf eine Incident-Benachrichtigung eingerichtet wird.
So richten Sie eine Antwort auf eine Incident-Benachrichtigung ein:
  1. Erstellen Sie eine Postfachregel mit den folgenden Feldern und Werten:
    • Filter – Text enthält
    • Filterzeichenfolge – %Incident:{{object_id}}%
    • Fall ignorieren – JA
    • Aktion – Objekt aktualisieren
    • Aktionsobjekt – Incident
  2. Erstellen Sie eine Benachrichtigungszeichenfolge, die folgende Regel enthält:
    • Symbol – IncidentReply
    • Code – IncidentReply
    • Aktiv - Aktiv
    • Beschreibung – Kommentar, der die Antwort für einen Incident/ein Problem/eine Anfrage einbettet.
    • Wortfolge – Um "@{call_req_id.type.sym}" einen Kommentar hinzuzufügen, antworten Sie einfach auf diese E-Mail oder fügen die Zeile unten ein (in einer separaten Zeile).
      %Incident:{call_req_id.ref_num}%
      Lassen Sie im Text einer automatischen Antwort der Postfachregel das Präfix "call_req_id" aus. Dieses Präfix wendet einen Kontext an, in dem sich der Postfachregeltext schon befindet, und solch eine Kontextänderung ist nicht gültig, wenn schon innerhalb dieses Kontextes gehandelt wird.
  3. Erstellen oder aktualisieren Sie eine Meldungsvorlage, die die Benachrichtigungszeichenfolge folgendermaßen verwendet:
    • Benachrichtigungstext
      This is a simple notification. @{notification_phrase[IncidentURL1].phrase}
  4. Aktualisieren Sie die in Schritt 1 erstellte Postfachregel, um die in Schritt 3 erstellte Meldungsvorlage folgendermaßen festzulegen:
    Meldungsvorlage –
    Postfachregelname
Aktualisieren von Tickets durch Endanwender – Beispiel
Das folgende Beispiel zeigt, wie ein Endanwender (Johann Schmid) auf eine E-Mail-Benachrichtigung antwortet, um ein Incident-Ticket zu aktualisieren.
Der Text oder Betreff der E-Mail enthält die Objektkennung. Der Platzhalter "{{object_id}}" in der Filterzeichenfolge steht für die Objektkennung.
  1. Eine Benachrichtigung mit den folgenden Anweisungen wird an Johann Schmid gesendet:
    In order to add a comment to your incident, just reply to this email or include the line below (on a line by itself). %Incident:1234%
  2. Johann Schmid antwortet auf die Benachrichtigung folgendermaßen:
    This is my response...
  3. Die Komponente "Mail Eater" empfängt die folgende Textversion der E-Mail von Johann Schmid:
    This is my response... From: Service Desk Sent: Wednesday, September 18, 2009 10:22 AM To: Smith, John Subject: Simple Notification This is a simple notification. In order to add a comment to your incident, just reply to this email or include the line below (on a line by itself). %Incident:1234%
  4. Die Komponente "Mail Eater" verarbeitet Regeln in der entsprechenden Reihenfolge und findet das Artefakt "%Incident:1234%":
    This is my response... From: Service Desk Sent: Wednesday, September 18, 2009 10:22 AM To: Smith, John Subject: Simple Notification This is a simple notification. In order to add a comment to your incident, just reply to this email or include the line below (on a line by itself). %INCIDENT_ID=1234
  5. Die Komponente "Mail Eater" fügt die Text-API-Schlüsselwörter und den Wert "{{object_id}}" einer Anweisung "%INCIDENT_ID=" hinzu und fügt eine Markierung an der Stelle ein, wo der Wert "{{object_id}}" gefunden wurde. Der folgende Text zeigt die Daten, die an die Text-API gesendet werden. Der fett formatierte Text zeigt Werte, die von der Komponente "Mail Eater" hinzugefügt werden.
    %LOG=This is my response...
    From: Service Desk
    Sent: Wednesday, September 18, 2009 10:22 AM
    To: Smith, John
    Subject: Simple Notification
    This is a simple notification.
    In order to add a comment to your incident, just reply to this email or include the line below (on a line by itself).
    %Incident:-((...))-%
    %INCIDENT_ID=1234
  6. Die Text-API fügt einen Protokollkommentar für Incident 1234 hinzu.
Schlüsselwort-Konvertierungsmethoden
Viele der in "text_api.cfg" definierten Schlüsselwörter enthalten eine zugehörige Methode, um den angegebenen Wert in einen Wert zu konvertieren, der sich für die Speicherung in der Datenbank eignet. Mit dieser Funktion können Anwender Werte genau wie in der Web-Schnittstelle festlegen. Sie benötigen keinerlei Wissen über die Implementierung, die im Hintergrund läuft.
In der Konfigurationsdatei finden Sie verschiedene Beispiele für diese Art der Schlüsselwort-Definition (z. B. ISSUE.PRIORITY und CONTACT.CONTACT_TYPE). Möchten Sie zusätzliche Schlüsselwörter definieren, beispielsweise weil Sie Text-API-Zugriff auf benutzerdefinierte Felder in Ihrem Datenbankschema einrichten möchten, können Sie eine der folgenden vordefinierten Methoden nutzen:
Methode
Ausgabetyp
lookup_actbool
INTEGER
lookup_asset_by_name
UUID
lookup_asset_by_persid
UUID
lookup_chg_category
STRING
lookup_chg_status
STRING
lookup_cnt_by_email
UUID
lookup_cnt_by_last_first_middle
UUID
lookup_cnt_by_logonid
UUID
lookup_cnt_by_persid
UUID
lookup_cnt_meth
INTEGER
lookup_cnt_type
INTEGER
lookup_company
UUID
lookup_cr_status
STRING
lookup_cr_template
STRING
lookup_domain
INTEGER
lookup_grc
INTEGER
lookup_group
UUID
lookup_impact
INTEGER
lookup_iss_category
STRING
lookup_iss_status
STRING
lookup_loc
UUID
lookup_mfr_model
UUID
lookup_nr_family
INTEGER
lookup_org
UUID
lookup_person_contacting
INTEGER
lookup_position
INTEGER
lookup_priority
INTEGER
lookup_prob_category
STRING
lookup_product
INTEGER
lookup_resource_status
INTEGER
lookup_service_lvl
STRING
lookup_severity
INTEGER
lookup_state
INTEGER
lookup_timezone
STRING
lookup_type_of_contact
INTEGER
lookup_urgency
INTEGER
lookup_workshift
STRING
Wenn der Wert, den Sie konvertieren müssen, nicht durch eine dieser vordefinierten Methoden abgedeckt ist, müssen Sie eine benutzerdefinierte Methode erstellen. Die Methode sollte einen STRING-Wert als Eingabe verwenden und einen Wert (INTEGER, STRING oder UUID) als Ausgabe zurückgeben. Geben Sie den Wert -1 (oder „-1”) zurück, um anzugeben, dass der Wert nicht ermittelt werden kann und somit nicht eingestellt wird. Geben Sie für UUID “( uuid) NULL” zurück.
Zum Beispiel können Sie eine Methode entwerfen, um eine Anwender-ID in einen ca_contact-Tabellenverweis zu konvertieren. Der eingehende Wert, zum Beispiel "Administrator", wird dann an die Methode übergeben, und die Methode gibt die ca_contact-Tabellen-ID für die Anwender-ID "Administrator" zurück.
Die Art und Weise, in der Sie Schlüsselwörter in der Konfigurationsdatei definieren, bietet Ihnen den Vorteil, abhängig vom angegebenen Wert mehrere Schlüsselwortzuordnungen für das gleiche Feld zu definieren, einschließlich verschiedener Konvertierungsmethoden. Zum Beispiel kann ein Zuständiger mehrere verschiedene Schlüsselwortzuordnungen haben, die festlegen, wie sein Wert abhängig von den verschiedenen Eingabewerten eingestellt wird. Eine Eingabe könnte die Anwender-ID, eine andere der Nachname, der Vorname und der zweite Vorname und wiederum eine andere Eingabe könnte die eigentliche ca_contact-ID sein (z. B. 793ED69B4E87A545BD8E911834D829FC). Jedes Schlüsselwort wird einer anderen Konvertierungsmethode zugeordnet, mit Ausnahme des letzten, das nicht konvertiert werden muss.