Skip to main content

Übersicht der Macro Actions

Nachfolgend finden Sie eine Übersicht der mit KIX ausgelieferten Macro Actions zur Verwendung in Jobs oder Aktionen.

Tipp

Einige der Macro Actions bieten einen Editor zum Hinterlegen von Text an (z. B. Ticket anlegen oder Artikel erstellen). Wenn Sie KIX Platzhalter via Copy & Paste im Editor einfügen, werden diese aufgrund der spitzen Klammern nicht anerkannt. Verwenden Sie daher zum Einfügen von KIX Platzhaltern die Tastenkombination STRG + SHIFT + V bzw. COMMAND+ SHIFT + V.

Artikel Anhang hinzufügen

Fügt einem bestehenden Artikel einen Dateianhang hinzu.

In Verbindung mit der Macro Action "Convert to PDF" können PDF Dateien unmittelbar bei Erstellung eines Artikels generiert und diesem beigefügt werden (z. B. Ausdruck der von der KIX Field Agent App erzeugten Arbeitsberichte).

macroaction_AddArticleAttachment.png

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

ArticleID

Definiert, an welchem Artikel der Dateianhang erzeugt werden soll

Z. B. der jeweils aktuelle Artikel: <KIX_ARTICLE_ArticleID>

Attachment

Definiert welche Datei angehängt wird

Z. B. ein mit der Macro Action "Convert to PDF" erstelltes PDF eines Tickets bzw. Artikels

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Artikel Anhänge löschen

Die Macro Action entfernt die Dateianhänge eines Artikels. Sie kann bspw. für Anonymisierungs-Jobs genutzt werden, um Datenschutz- oder Verwaltungsverordnungen zu entsprechen.

Beim Ausführen der Macro Action wird für jeden Dateianhang aller Artikel des relevanten Tickets die Erfüllung konfigurierter Regeln geprüft. Die Regeln können auf den Dateinamen, den Inhaltstyp (Contenttype) und die Disposition ('inline' oder 'attachment') mit regulären Ausdrücken prüfen. Sobald eine Regel der 'Keep Rules' zutrifft, wird die Datei nicht gelöscht. Wenn es keine 'Keep Rules' gibt, oder keine Regel zutrifft und irgendeine Regel der 'Delete Rules' erfüllt ist, wird die Datei gelöscht.

In der Konfiguration kann definiert werden, welche Anhänge entfernt und welche beibehalten werden sollen.

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Keep Rules

Definiert, welche Dateianhänge beibehalten werden (z. B. Internas, Signaturen u.a.m.)

Anzugeben sind die Eigenschaften, welche die Dateianhänge aufweisen müssen, damit sie nicht entfernt werden.

Geben Sie in alle Parameter als RegEx an, damit die Regel ausgewertet wird. Ist der Wert für ein Prüffeld egal, kann der RegEx .* angegeben werden.

  • Dateiname: Angabe des Dateinamen

  • Inhaltstyp: Angabe des Dateityps

  • Disposition: Art des Anhangs

    • inline: Inline-Elemente

      (z. B. Bilder innerhalb des E-Mail-Textes)

    • attachment: Anhang-Elemente

      (z. B. Dateianhänge an einer E-Mail)

Hinweis: Keep Rules gewinnen gegenüber Delete Rules.

Verwenden Sie die seitlichen Plus- und Minus-Schaltflächen, um weitere Regeln hinzuzufügen oder zu entfernen.

Delete Rules

Definiert, welche Dateianhänge gelöscht werden sollen.

Anzugeben sind die Eigenschaften, welche die Dateianhänge aufweisen müssen, damit sie entfernt werden.

Geben Sie in alle Parameter als RegEx an, damit die Regel ausgewertet wird. Ist der Wert für ein Prüffeld egal, kann der RegEx .* angegeben werden.

  • Dateiname: Angabe des Dateinamen

  • Inhaltstyp: Angabe des Dateityps

  • Disposition: Art des Anhangs

    • inline: Inline-Elemente

      (z. B. Bilder innerhalb des E-Mail-Textes)

    • attachment: Anhang-Elemente

      (z. B. Dateianhänge an einer E-Mail)

Hinweis: Keep Rules haben Vorrang.

Verwenden Sie die seitlichen Plus- und Minus-Schaltflächen, um weitere Regeln hinzuzufügen oder zu entfernen.

Die Macro Action ist initial vorbelegt mit folgender Konfiguration:

  1. Keep Rule: Beibehalten werden alle internen Dateien, die für die Artikeldarstellung benötigt werden (nur der Inhalt und die Formatierungen, aber nicht die Inline-Bilder)

    • Dateiname: ^(?:file-1|file-2|file-1.html)$

    • Inhaltstyp: ^text/(?:plain|html)

    • Disposition: ^inline$

  2. Keep Rule: Beibehalten werden Zertifikatsdateien an E-Mails

    • Dateiname: smime

    • Inhaltstyp: ^application\/(?:x-pkcs7|pkcs7)

    • Disposition: .+

  1. Delete Rule: Gelöscht werden alle Dateien, die keine Inline-Attachments (z. B. Bilder innerhalb des Textes) sind.

    • Dateiname: .+

    • Inhaltstyp: .+

    • Disposition: ^attachment$

Artikel E-Mail Attribute setzen

Setzt E-Mail-Attribute an einem Artikel. Kann für die Anonymisierung verwendet werden.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Von | An | Kopie an (Cc) | Blind-Kopie an (Bcc)

Anzugeben sind jeweils gültige E-Mail-Adressen.

Die Verwendung von KIX Platzhaltern ist möglich.

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Artikel erstellen

Legt einen Artikel mit vordefinierten Inhalten an.

Verwendung/Jobtyp: Ticket

Die in der Macro Action anzugebenden Parameter entsprechen denen zum Anlegen eines neuen Artikels.

Zusätzliche Parameter sind:

Parameter

Beschreibung

Überspringen

Wenn aktiviert: Überspringt die Ausführung der Aktion

Debug

Wenn aktiviert, werden die Artikeldaten nach Platzhalterersetzung geloggt (Menü System > Logs)

NewArticleID

Ergebnisvariable.

Individueller Bezeichner zum Speichern der Artikel ID (z. B. myArticleID).

Über diese Variable kann auf den Artikel in nachfolgenden Macro Actions referenziert und deren Wert verwendet werden.

DoNotSendEmail

Wenn aktiviert, wird das Versenden des neuen Artikels durch das System verhindert.

So kann bspw. bei Kopplung von 2 Systemen verhindert werden, dass das Empfängersystem den Artikel noch einmal versendet, obwohl das Sendersystem dies bereits getan hat.

Anhangsobjekt

Optional: Angabe eines Anhang-Objektes mit den Attributen Filename, ContentType und Content. Der binäre Inhalt muss base64-kodiert sein.

Es ist der Bezeichner der Ergebnisvariable anzugeben. Z. B.: ${varReportAttachment}

Anhang-Objekte können mit der Macro Action Objekt zusammenstellen oder Konvertieren zu PDFerstellt werden.

Anwendungsbeispiel: Berichte automatisiert erstellen

Dynamische Felder

Setzen von Dynamischen Feldern am Artikel

  • Name: Name des Dynamischen Feldes, welches am Artikel gesetzt werden soll.

    Achten Sie darauf, dass es sich um ein Dynamisches Feld mit Objekttyp "Artikel" handelt!

  • Wert: Wert der in das Dynamische Feld gesetzt werden soll

Hinweis

Ein Dynamisches Feld mit Objekttyp "Article" steht nur dann am Artikel zur Verfügung, wenn ein Kanal ausgewählt wurde.

Hinweise:

  • Verwendung der ArtikelID s. Variablen

  • Soll ein mehrzeiliger Text (DF Typ "TextArea") in einen Artikel eingefügt werden, so müssen Sie das Suffix "_HTML" verwenden, um Zeilenumbrüche zu erhalten. Zum Beispiel: <KIX_TICKET_DynamicField_WorkOrder_HTML>

Artikel löschen

Löscht den durch die ArticleID identifizierten Artikel.

Die Historie am Ticket erhält den Eintrag, dass der Artikel gelöscht wurde. 

Verwendung/Jobtyp: Ticket

Parameter

Hinweise 

ArticleID

ID des zu löschenden Artikelswerden soll.

Es können Platzhalter verwendet werden (z. B.: <KIX_LAST_ArticleID> )

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Hinweise:

  • Das Löschen fungiert im Hintergrund; bei Jobs also mit den Berechtigungen des Systemusers.

    Es gelten damit nicht die Rollenberechtigungen des auslösenden Nutzers wenn die Macro Action verwendet wird.

  • Die Aktion ArticleDelete verwendet ebenfalls diese Macro Action.

Asset Attribute abrufen

Referenziert auf ausgewählte Asset Attribute, um diese bspw. in den Ticketinformationen anzuzeigen.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden die zu setzenden Wert der Dynamic Fields nach Platzhalterersetzung geloggt (Menü System > Logs)

Assetbezug aus dynamischen Feld

Referenz zum Asset, dessen Attribute abgerufen werden sollen.

Geben Sie den Namen des Dynamischen Felds an, welches die ID des zu verwendenden Assets enthält, z. B. AffectedAsset oder RelatedAssets.

Beispiel: Sollen Attribute des am Ticket ausgewählten "betroffenen Assets" ausgelesen werden, so tragen Sie hier "AffectedAsset" ein.

Erzwingen

Wenn aktiviert: Das Dynamische Feld wird überschrieben, egal ob das entsprechende Asset Attribut leer ist oder das Dynamische Feld bereits einen Wert enthält.

Attribut - Dynamisches Feld Mapping

Definiert, welches Asset Attribut in welchem Dynamischen Feld angezeigt wird.

Beispiel: Liest den Hersteller des Assets aus und zeigt diesen im Dynamischen Feld "DFHersteller" an.

  • Attribut: Vendor

  • DynamicField: DFHersteller

(Der Wert des Dynamischen Feldes "DFHersteller" wird dort angezeigt, wo es in der Oberfläche eingebunden ist.)

Praxisbeispiele: Asset Attribute in den Ticketdetails anzeigen und Services in den Ticketdetails anzeigen

Asset erstellen oder aktualisieren

  1. Aktualisiert ein bestehendes Asset (inkl. neuer Version), wenn eine Asset ID angegeben ist und die neuen Daten Änderungen zum aktuellen Stand darstellen.

  2. Legt ein neues Asset (inkl. Versionsdaten) an, wenn keine Asset ID angegeben ist.

Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket

Die Macro Action kann bspw. verwendet werden:

  • um die aufbereitete Rückgabe eines Webhook-Aufrufs zur Anlage bzw. Aktualisierung eines Assets zu nutzen

  • um bei Erreichen eines Ticketzustands das/die referenzierte/n Asset/s mit Angaben aus dem Ticket (oder absoluten Werte) zu aktualisieren

  • um den Automatismus auf beliebige Dynamische Felder vom Typ "AssetReference" bei bestimmten Ereignissen oder zeitlich gesteuert anzuwenden.

Konkrete Anwendungsfälle wären zum Beispiel:

  • Mit KIXConnect: Eine periodische Anfrage an eine Webservice-Schnittstelle liefert Angaben zu einem Asset zurück. Diese Daten sollen zur Aktualisierung der Eintragung im KIX-Assetmanagement genutzt werden können ( => Baramundi-Inventarisierung; => IDoIT-Inventarisierung; etc.)

  • Ohne KIXConnect:

    • An einem Ticket wird die Auslieferung von N Assets in einem Dynamischen Feld vom Type Date/Time dokumentiert. An den betroffenen Assets soll der Tag der Inbetriebnahme mit diesem Wert gesetzt und der Verwendungsstatus auf "Produktion" gesetzt werden.

    • An einem Ticket zu einem Servicevertrag werden Zeiteinheiten verbucht. Am Asset Servicevertrag wird das verbrauchte Budget geführt. Bei Ticketabschluss soll das verbrauchte Budget am Asset um die Summe der Zeitaufwände am Ticket erhöht werden.

    • An einem Ticket wird der km-Stand eines Kfz erfasst. Das Kfz ist als Asset erfasst und beinhaltet den zuletzt abgelesenen Kilometerstand. Dieser soll automatisch aus dem Ticket in das Asset geschrieben werden.

    • An einem Ticket zum Austausch eines Arbeitsplatzrechners wird das Altgerät und das Neugerät eingetragen. Mit Erreichen eines Bearbeitungsstatus "ausgetauscht", wird die Nutzerzuordnung des Altgeräts entfernt und der Nutzer am Austauschgerät eingetragen. Der Nutzer ist Kundenkontakt des Tickets.

Konfigurationsparameter

Parameter

Beschreibung

AssetID

Ergebnisvariable

Die ID des zu aktualisierenden Assets. 

Die Angabe bestimmt, ob Update oder Create des Assets erfolgt.

  • Update: wenn Asset ID angegeben ist

  • Create: wenn keine Asset ID angegeben ist

Ist keine Asset ID angegeben, wird ein neues Asset angelegt.

Tipp: Die ID des Assets können sie der Adress- oder Fußzeile des Browsers entnehmen.

VersionID

Ergebnisvariable.

Die ID der neuen Version.

Überspringen

Ermöglicht temporäres Deaktivieren der Aktion.

Debug

Wenn aktiviert, werden die Assetdaten geloggt (Menü System > Logs)

Asset JSON Objekt

JSON-Editor zum Hinterlegen der Konfiguration.

Möglich ist die Verwendung einer ${XYZ}-Notation für die Objektübergabe oder die Angabe eines JSON-Strings welcher das Objekt beschreibt (wie API).

Wert der Vorversion übernehmen

Legt fest, wie mit Leerwerten verfahren wird (analog Import von Assets).

Wenn aktiviert, werden nicht enthaltene Angaben aus vorherigen Versionen übernommen.

Grundlagen der Macro Action

Die Macro Action erwartet eine Konfiguration im JSON-Format. In der Konfiguration wird definiert, welches Asset von welcher Asset-Klasse angesprochen wird und welche Attribute dieses Assets mit welchen Werten belegt werden.

Zum Beispiel ein PC mit der Asset ID 4 in der Asset-Klasse Computer. An diesem PC können über die Macro Action der Vorfallstatus und der Verwendungsstatus gesetzt werden sowie ausgewählte Attributwerte am Asset, bspw. das Datum der Inbetriebnahme.

Der grundlegende Aufbau des JSON orientiert sich an einem POST-Request für ConfigItems/Assets (ohne Images).

  • Das Verhalten der Macro Action entspricht dem CSV-Import von Assets.

  • Ergebnisse der Macro Action: AssetID und VersionsID.

  • Bei Datumsangaben muss im CI und im Dynamischen Feld, dessen Wert ins Asset übertragen wird, der Feldtyp "DateTime" benutzt werden. Der Feldtyp "Date" funktioniert nicht.

  • Die Verwendung von KIX Platzhaltern für Asset-Attribute ist möglich.

Grundkonfiguration

{   
  "AssetID": 1,   
  "ClassID": 4,   
  "Version": {     
    "Name": "some name",    
    "DeplStateID": 16,     
    "InciStateID": 1,
    "Data": {}   
  } 
}

  • AssetID: ID des zu aktualisierenden Assets

    • Update: wenn Asset ID angegeben ist

    • Create: wenn keine Asset ID angegeben ist

  • ClassID: ID der Asset-Klasse

    z. B.: "4" für die Assetklasse Computer

    Angabe ist Pflicht bei "Create"; optional bei "Update"

  • Name: Name des Assets

    Angabe ist Pflicht bei "Create"; optional bei "Update"

  • DeplSateID: ID des Verwendungsstatus

    wenn nicht angegeben:

    • bei Create: Default zu Produktion

    • bei Update: Werte der vorherigen Version

  • InciStateID: ID des Vorfallstatus

    wenn nicht angegeben:

    • bei Create: Default zu Operational

    • bei Update: Werte der vorherigen Version

  • Data{...}:

    Die unter Data{...} angegebenen Attribute sprechen die Asset-Attribute in der Klassendefinition an. Hier wird definiert, welche Werte an welchem Attribut der Klassendefinition gesetzt werden. Die Angaben können auf 3 Arten erfolgen:

    1. Direkt (Wert nach dem Attributs-Key)

      {   
  "Version": {
    "Data": {          
      "SomeAttribute": "Value"      
    }
  } 
}

    2. Direkt (Wert-Liste (Array) nach dem Attributs-Key)

      {   
  "Version": {
     "Data": {       
       "SomeAttribute": [          
          "Value1",
          "Value2"
          ]
      }
   }
}

    3. Als Objekt-Liste (Array of "Hashes") nach dem Attributs-Key.  Wobei der Attributs-Key selbst darin enthalten ist und dieser den Wert wiederum direkt erhalten muss.

      Diese Variante muss genutzt werden, wenn man Kind/Sub-Attribute angeben will. Die Kind/Sub-Attribute können dann wiederum eine der Varianten nutzen.

      {   
  "Version": {
     "Data": {
       "SomeAttribute": [
          {
            "SomeAttribut": "Value1",
            "SomeChildAttribute": "ChildValue"
          },
          {
            "SomeAttribut": "Value2"
          }
       ]
     }
   }
 }

Es ist möglich, die zuvor genannten Varianten 2 und 3 zu kombinieren: Wird in Variante 3 bei allen Werten (direkt in der Liste, ohne Kinder) ein Objekt/Hash angegeben, kann anstatt des Hashs für den 2. Wert direkt ein "Value2" - wie in der 2. Variante - angegeben werden.

Anhänge (Attachments) sind möglich . Der Wert ist - wie in der API üblich: Object mit "Filename", "ContentType" und base64-codiertem "Content"

Der Inhalt von Data muss nicht die komplette Versions-Definition umfassen, ein einzelnes Attribut ist ausreichend. Attribut-Werte müssen - soweit notwendig - IDs sein (wie bei POST). Es findet keine "Auflösung" der Werte statt (z. B. bei GeneralCatalog-Attributen).

Bei Datumsangaben muss im CI und im Dynamischen Feld, dessen Wert ins Asset übertragen wird, der Feldtyp "DateTime" benutzt werden. Der Feldtyp "Date" funktioniert nicht.

Nicht angegebene Attribute werden ignoriert; deren Werte bleiben unverändert.

Der Code erwartet im "Version"-Objekt mindestens eine Angabe (Name, DeplState oder InciState). Die "Data"-Angaben sind optional.

Die Verwendung von KIX-Platzhaltern ist überall möglich. Nicht auflösbare Platzhalter werden mit einem Leerstring ersetzt.

Statt einem "JSON-Object"-String kann auch ein "Result"-Platzhalter verwendet werden ( $ {SomeAssembledObject} ). Dieser wird zwar vom Editor als falsch gekennzeichnet (da kein valides JSON), aber dennoch akzeptiert.

Als Result-Variablen werden gesetzt: "AssetID" - ID des erstellten/aktualisierten Assets "VersionID" - ID der neuen Version

.

Umgang mit Leerwerten

Die Option Wert der Vorversion übernehmen bestimmt, wie mit leeren Attribut-Werten (null, Leerstrings) umgegangen werden soll (analog CSV-Import von Assets). Nicht angegeben Attribut-Werte werden generell ignoriert, d. h. sie haben keine Auswirkung auf Alt-Werte. Standardmäßig ist die Checkbox im Frontend angehakt (aktiv).

Beispiel

  • Variante A: Das Asset hat im Attribut bereits 2 Werte 

  • Variante B: Das Asset hat im Attribut bereits 5 Werte 

Folgendes JSON wird angewendet:

{
  "SomeAttribute": [
    null,
    null,
    null,
    "NewValue"
  ]
}

  • Wenn die Option aktiviert ist: Neue Werte werden "angehangen" oder überschreiben an selber Wert-Position.

    • In Variante A: "NewValue" wird als 3. Wert abgelegt. 1. und 2. Wert bleiben erhalten, da der Leerwert die alten Werte belässt. Einen 3. Wert gab es nicht, also ist dieser Platz frei (Vermeidung leerer Wert- Plätze).

    • In Variante B: Wert 4 wird mit dem neuen Wert überschrieben, der Rest bleibt.

  • Wenn die Option deaktiviert ist: Neue Werte überschreiben bestehende Werte; Leerwerte (null, Leerstring) überschreiben/entfernen bestehende Werte.

    • in Variante A: Der neue Wert ist als einziger vorhanden. 1. und 2. Wert wurden geleert und sind somit frei. Der neue Wert rückt an den ersten freien Platz

    • in Variante B: Das Attribut hat nun 2 Werte: der neue Wert auf Position 1 und der Wert von Position 5 ist nun an Position 2 (aufgerückt).

Besonderheiten beim Verhalten, wenn deaktiviert und Kind-Attribute vorhanden sind:

  • Das Verhalten zu frei gewordenen Positionen gilt nur, wenn das Attribut keine Sub-Attribute (Werte) hat. Es wird nur der Wert entfernt, nicht dessen Subs/Kinder. Am o. g. Beispiel werden z. B. der Position 2 noch Werte für dessen Sub-Attribute gegeben.

    • Da Position 1 seinen Wert verliert und keine Subs besitzt, ist diese Position frei. Damit rücken die Subs der Position 2 zur 1 auf, um Leerwerte zu vermeiden. Somit ist Position 2 frei geworden, da der Wert ebenfalls entfernt wurde (null).

    • Der neue Wert wird entsprechend an Position 2 gesetzt.

    • Bei B rückt zudem der Wert 5 noch an Position 3.

  • Der CSV-Import von Assets verhält sich prinzipiell gleich (jedoch werden da die Subs "leer" gesetzt). Würden im o. g. Beispiel auch für die Sub-Attribute Leerwerte gesetzt, würde man auch die "Sub- Beschränkung" umgehen bzw. auflösen:

    {
  "SomeAttribute": [
    null,
    {
      "SomeAttribute": null,
      "SomeChildAttribute": [
          null,
          null,
          ...
      ],
    },
    null,
    "NewValue"
  ]
}

Konfigurationsbeispiel

Das nachfolgende Konfigurationsbeispiel legt ein neues Asset der Klasse Computer mit folgenden Parametern an:

  • Titel des Tickets (Typ Ticket-Job) als Notiz

  • ein Bild als Anhang/Attachment

  • ein Dynamisches Feld (Datumsfeld für Inbetriebnahme)

  • da die Asset-ID nicht im Eingabefeld der Macro Action gesetzt ist, muss "ClassID" und "Name" in der Version angegeben werden

  • "DeplStateID" ist enthalten ("Produktion")

  • "InciStateID" ist nicht enthalten (wird Default auf "Operational" gesetzt).

{
  "ClassID": 4,
  "Version": {
     "Name": "Created by Job",
      "DeplStateID": 16,
      "Data": {
         "SectionGeneral": [
           {
            "Note": "<KIX_TICKET_Title> and some text",
            "Attachment": [
              {
                "ContentType": "image/jpeg",
                "Filename": "test.jpg",
                "Content": "<base64-String des Bildes> "
              }
             ]
            }
           ],
         "SectionWarranty": [
           {
             "WarrantyExpirationDate": "2021-08-11 12:00:42",
             "FirstUsageDate": "<KIX_TICKET_DynamicField_PlanBegin_ObjectValue>"
           }
         ]
      }
   }
}

Der angelegte Computer wird im weiteren Verlauf angepasst (Auf korrekte "AssetID" achten!).

  • Die "AssetID" muss im Eingabefeld der Macro Action angegeben sein, ansonsten wird ein Create versucht. Dies würde jedoch fehlschlagen, da "ClassID" fehlt (irrelevant bei Update).

  • Der Name des Assets wird geändert

  • Der Vorfallstatus wird geändert ("Störung")

  • "Data" -Attribute  sind nicht angegeben. die bestehenden Werte bleiben daher unberührt.

{
  "AssetID": 42,
  "Version": {
  "Name": "Created by Job - updated",
  "InciStateID": 3
 }
}

Der angelegte Computer wird erneut angepasst:

  • Es wird nur eine FQDN hinterlegt, alles andere bleibt unberührt

    • keine weiteren Attribute notwendig

{
  "AssetID": 42,
  "Version": {
  "Data": {
     "SectionNetwork": [
        {
           "FQDN": "some.test-computer.com"
        }
     ]
   }
  }
}

Der angelegte Computer wird zum 3. Mal angepasst:

  • Es wird nur eine weitere FQDN hinterlegt, die vorherige soll erhalten bleiben.

    • Wert der Vorversion übernehmen ist aktiv

{
  "AssetID": 42,
  "Version": {
  "Data": {
     "SectionNetwork": [
      {
       "FQDN": [
         null,
         "another.test-computer.com"
       ]
      }
    ]
  }
 }
}

Der angelegte Computer wird zum 4. Mal angepasst:

  • Die 2. FQDN wird überschrieben und eine 3. FQDN wird angefügt:

    • Wert der Vorversion übernehmen ist aktiv

{
  "AssetID": 42,
  "Version": {
    "Data": {
      "SectionNetwork": [
        {
          "FQDN": [
             null,
            "changed-another.test-computer.com",
            "yet-another.test-computer.com"
          ]
        }
      ]
    }
  }
}

Der angelegte Computer wird zum 5. Mal angepasst:

  • Die alten FQDN werden durch eine neue ersetzt. Es gibt dann nur noch eine.

    • Sollte es bereits mehr als 3 FQDN geben, müsste die Liste mehr "null" Elemente enthalten. Wir wissen aber, es sind nur 3 FQDN. Also reichen 2, welche die 1. und 2. FQDN leer setzen und die 3. ersetzt. Diese wiederum rückt auch auf, da die Plätze davor frei geworden sind.

    • Wert der Vorversion übernehmen ist inaktiv. Somit ersetzen Leerwerte die Alt-Werte.

{
  "AssetID": 42,
  "Version": {
    "Data": {
      "SectionNetwork": [
        {
        "FQDN": [
          null,
          null,
          "one-and-only.test-computer.com"
        ]
       }
     ]
    }
  }
}

Asset Name setzen

Die Macro Action kann nur in Jobs verwendet werden.

Ändert den Namen eines Assets, ohne eine neue Version zu generieren. Es wird die aktuelle Version des Assets aktualisiert (Name und Änderungszeitpunkt).

Wichtig

Schränken Sie die zu ändernden Assets mittels Filter ein (Schritt 3 in der Job-Konfiguration)!

Anderenfalls werden alle Assets umbenannt.

Dient bspw. dem automatischen Generieren des Asset-Namens anhand von Attributwerten, wie:

  • Name des Computers - bestehend aus Hersteller, User und IP-Adresse

  • Name eines Raumes - bestehend aus Name der übergeordneten Location und dem Raumtyp

Verwendung/Jobtyp: Asset

Parameter

Beschreibung

Überspringen

Ermöglicht temporäres Deaktivieren der Aktion.

Debug

Wenn aktiviert, wird der zu setzende Asset-Name geloggt (Menü System > Logs)

Asset Name

Der neue Name des Assets.

Es können KIX-Platzhalter verwendet werden, z. B..:

  • <KIX_ASSET_Name>

  • <KIX_ASSET_ParentAttribute_0_SubAttribute_0>

Weitere Platzhalter: Assetbezogene Platzhalterbereiche

Asset Nummer setzen

Ersetzt die beim Import durch KIX vergeben Assetnummern durch eigene Identifikatoren.

Verwendung/Jobtyp: Asset

Parameter

Beschreibung

Assetnummer

Der neue Identifikator des Assets.

Es können KIX-Platzhalter verwendet werden, z. B.:

  • <KIX_ASSET_Name>

  • <KIX_ASSET_ParentAttribute_0_SubAttribute_0

Debug

Wenn aktiviert, wird die zu setzende Assetnummer geloggt (Menü System > Logs)

UseCase: Assetnummern beim Import ändern

Bearbeiter setzen

Setzt den Bearbeiter an einem Ticket.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Bearbeiter

ID oder Login-Name des Bearbeiters.

KIX Platzhalter sind möglich, z. B.: <KIX_CURRENT_UserID>

Hinweis: Es findet keine Prüfung statt, ob der gewählte Agent berechtigt ist, das Ticket zu bearbeiten.

Bedingungen

Ermöglicht den Kontrollfluss in Macros. Prüft, ob eine Bedingung wahr (true) oder nicht wahr (false) ist und führt im jeweiligen Fall die angegebenen Aktionen aus.

macroaction_bedingungen.png

Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, wird der auszuwertende Ausdruck nach Platzhalterersetzung geloggt (KIX System > Logs)

Wenn

Logischer Ausdruck der Bedingung.

Wenn dieser Ausdruck zutrifft, dann werden die unter Dann angegebenen Macro Actions ausgeführt.

Sie können hier Platzhalter und die in vorangehenden Macros definierten Variablen angeben.

Beispiel:

Wenn die Variable varResult definiert ist bzw. einen Wert besitzt: defined ${varResult}

Dann

Die angegebenen Aktionen werden ausgeführt, wenn die unter Wenn angegebene Bedingung wahr (true) ist. 

Ansonsten

Die angegebenen Aktionen werden ausgeführt, wenn die unter Wenn angegebene Bedingung nicht wahr (false) ist. 

Tipp

Zum Abbilden eines ELSEIF können Sie hier als untergeordnete Aktion eine weitere Bedingung angeben.

Hinweise

  • Mögliche Operatoren sind u. a.:

    • defined - Prüfung auf Vorhandensein (true)

    • !defined - Prüfung auf Nichtvorhandensein (false)

    • && - Logisches UND

    • || - Logisches ODER

  • Die Macro Action unterstützt (eingeschränkten) Perl-Code.

    Das heißt, es muss ein valider Perl-Ausdruck verwendet werden, der einen booleschen Wert ergibt.

  • Beachten Sie bei Vergleichen:

    • Texte werden mit eq (equals) verglichen

    • Zahlen werden mit == verglichen

Berechnen

Führt Berechnungen von Formularfeldern durch, z. B.:

  • Berechnen der Werte von zwei Dynamischen Feldern

  • Ermitteln der Zielzeiten für die Wiedervorlage

Kann gut in Verbindung mit der Macro Action "Conditional" verwendet werden.

Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket

Parameter

Beschreibung

Result

Ergebnisvariable; Bezeichner der Ergebnisvariable (z. B. "CalcResult").

Die Ergebnisvariable nimmt nur das Ergebnis (Wert) der Berechnung auf.

Die Ergebnisvariable kann 

  • in weiteren Macros verwendet und ausgegeben werden

  • als Wert in Dynamischen Feldern gesetzt werden.

Debug

Wenn aktiviert, werden der auszuwertende Ausdruck nach Platzhalterersetzung und das Ergebnis geloggt (Menü System > Logs)

Formel

Mathematischer Ausdruck der Berechnung.

Platzhalter können verwendet werden, z. B.: DF_TotalN := <DF_TotalN> + <DF_NewValueN>

  • Result:CalcResult

  • Formel: scale=2;<KIX_TICKET_DynamicField_DFMenge>*<KIX_TICKET_DynamicField_DFPreis>

macroaction_berechnen.png

Hinweise

Wichtig

Vermeiden Sie Schleifen!

Das Ergebnis sollte nicht im Wert der Berechnung enthalten sein.

Bericht erstellen

Erzeugt einen Bericht auf Basis einer bestehenden Berichtsdefinition.

Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket

Parameter

Beschreibung

Bericht

Bezeichner der Ergebnisvariable.

Der Bericht liefert ein Ergebnis, was in Folgeaktionen auch als Variable verwendet werden kann.

Debug

Wenn aktiviert, werden die Reportparameter nach Platzhalterersetzung geloggt (Menü System > Logs)

Berichtsdefinition

Auf Basis der gewählten Definition werden die Parameter des Berichts als Eingabefelder eingebunden.

Tragen Sie die entsprechenden Werte ein. Die Werte werden durch den Job gesetzt und der Bericht erzeugt.

Die Auswahl des Ausgabeformates ist ebenfalls abhängig von der Berichtsdefinition.

Der Bericht liefert ein Ergebnis, was in Folgeaktionen auch als Variable verwendet werden kann.

Parameter

Anzeige der Report-Parameter.

Die zur Auswahl stehenden Parameter sind von der gewählten Berichtsdefinition abhängig. Wählen Sie daher zunächst eine Berichtsdefinition aus.

Geben Sie die vom Bericht geforderten Informationen an, um auf deren Basis den Bericht zu erstellen.

Ausgabeformate

Legt fest, in welchen Ausgabeformaten der Bericht erzeugt wird.

Zur Auswahl stehen die in der Berichtsdefinition festgelegten Ausgabeformate. Wählen Sie daher zunächst eine Berichtsdefinition aus.

Hinweis: Ein Anwendungsbeispiel finden Sie unter: Berichte automatisiert erstellen

Create Ticket from System Template

Erstellt ein Ticket, welches auf einer Ticketvorlage mit Nutzungskontext "System" basiert (Systemvorlage).

Die Macro Action liefert als Rückgabewert die IDs des erstellten Tickets und - sofern in der Vorlage definiert - die ID des erstellten Artikels.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

NewArticleID

Ergebnisvariable

Individueller Name/Bezeichner einer Variable zum Speichern der Artikel ID (z. B. myArticleVariable)

NewTicketID

Ergebnisvariable

Individueller Name/Bezeichner einer Variable zum Speichern der Ticket ID  (z. B. myTicketVariable)

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Vorlage

Auswahl der Ticketvorlage, auf deren Basis die Tickets erstellt werden.

Es stehen nur gültige Vorlagen mit Nutzungskontext "System" zur Auswahl. Legen Sie ggf. im Vorfeld entsprechende Ticketvorlagen an.

Dynamisches Feld setzen

Setzt einen Wert in ein Dynamisches Feld.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Überspringen

Wenn aktiviert: Überspringt die Ausführung der Aktion

Debug

Wenn aktiviert, wird der neue Wert des Dynamic Field nach Platzhalterersetzung geloggt (Menü System > Logs)

Objekt ID

Nur verfügbar in Jobs vom Typ "Ticket"

ID des Objekts, an welchem das Dynamische Feld gesetzt werden soll, z. B. ID eines bestimmten Tickets oder eines bestimmten Artikels.

Wichtig: Beachten Sie den Objekttyp des Dynamischen Feldes! Für Dynamische Felder mit Objekttyp "Ticket" muss die ID eines Tickets angegeben werden. Für Dynamische Felder vom Objekttyp "Artikel" muss die ID eines Artikels angegeben werden.

Ist keine explizite ID angegeben, wird die ID des auslösenden Objekts verwendet (${ObjectID}). Ist diese nicht gegeben, so wird die RootObjectID verwendet (s. auch: Sondervariablen).

Dynamic Field Name 

Name des Dynamischen Feldes, z. B. "DFMobileProcessingState".

Dynamic Field Value 

Wert, der in das Dynamische Feld gesetzt werden soll, z. B. "accepted".

Der zu setzende Wert ist abhängig vom Typ des Dynamischen Feldes:

  • Selection: Key-Wert aus der Konfiguration des Dynamischen Feldes

  • AssetReference: AssetID

  • Date: Datum im Format: YYYY-MM-DD 00:00:00

  • DateTime: Datum-Zeit-Angabe im Format: YYYY-MM-DD hh:mm:ss

  • TicketReference: TicketID

  • Checklist: JSON-Beschreibung der Checkliste

  • Table: JSON-Beschreibung der Tabelle

  • Text: Der zu setzende Text (einzeilig)

  • TextArea: Der zu setzende Text (mehrzeilig)

Hinzufügen 

  • Wenn aktiviert: Der unter "Dynamic Field Value" angegebene Wert wird in das Dynamische Feld gesetzt.

    Der Wert wird hinzugefügt.

    Bereits im Dynamischen Feld vorhandene Werte bleiben erhalten.

  • Wenn deaktiviert: Der unter "Dynamic Field Value" angegebene Wert wird als neuer Wert in das Dynamische Feld gesetzt.

    Bereits im Dynamischen Feld vorhandene Werte werden dabei überschrieben. 

Erfüllungszeit setzen

Setzt die Erfüllungszeit für ein SLA Kriterium.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

SLA Kriterium

ID oder exakter Name des SLA

Erzwingen wenn nicht leer

Festlegung zum Überschreiben einer bereits existierenden Erfüllungszeit

Mögliche Werte: 0 | 1

  • 0 - Überschreiben der Erfüllungszeit wird nicht erzwungen

  • 1 - erzwingt das Überschreiben der Erfüllungszeit

Erstellt von und Geändert von für Artikel setzen

Setzt einen bestimmten Agenten in einen Artikel. Kann für die Anonymisierung verwendet werden.

Der angegebene Agent wird in den Feldern "Erstellt von" und "Geändert von" hinterlegt. 

Anzugeben ist die ID oder der Login-Name des Agenten. KIX Platzhalter können verwendet werden.

Wenn die Debug-Option aktiviert ist, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Verwendung/Jobtyp: Ticket

Erstellt von und Geändert von setzen

Setzt einen bestimmten Agenten in ein Ticket.

Der angegebene Agent wird in den Feldern "Erstellt von" und "Geändert von" hinterlegt. 

Anzugeben ist die ID oder der Login-Name des Agenten. KIX Platzhalter können verwendet werden.

Wenn die Debug-Option aktiviert ist, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Verwendung/Jobtyp: Ticket

FAQ Artikel erstellen

Erstellt einen neuen FAQ Eintrag.

Ermöglicht aus einem Vorgang heraus FAQ Einträge zu erstellen.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

NewFAQArticleID

Ergebnisvariable

Wird ein Variablenbezeichner angegeben, wird darin die ID des FAQ Artikels zur Weiterverwendung gespeichert.

Debug

Wenn aktiviert, werden die FAQ-Artikeldaten nach Platzhalterersetzung geloggt (Menü System > Logs)

Titel

Titel des FAQ Eintrags, KIX Platzhalter sind möglich, z. B. <KIX_FIRST_SUBJECT>

Kategorie

FAQ Kategorie, welcher der FAQ Eintrag zugeordnet wird

Sprache

Zuordnung des FAQ Artikels einer Sprache (analog Erstellmaske für neue FAQ Artikel)

Schlagworte

Sie können den FAQ Artikel mit Schlagworten versehen (analog Erstellmaske für neue FAQ Artikel)

Symptom, Ursache, Lösung

Auswahlfelder

Die Auswahl bestimmt, mit welchen Ticket-/Artikel-Inhalten der FAQ Eintrag befüllt wird.

Artikel des ausgelösten Ereignisses: Dieser Auswahlwert funktioniert nur, wenn die Macro Action durch das Event "Artikel erstellen" oder "Artikel senden"  ausgelöst wurde. Eine Verwendung in Aktionen, bei anderen Events oder in einer zeitgesteuerten Ausführung wird aktuell nicht unterstützt.

macroaction_faq-artikel-erstellen.png

Historie löschen

Löscht die Historie von Tickets ausgewählter Agenten bzw. nach vorangegangenen Ticketaktionen.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Aktion

Optional: Definiert, welcher History-Eintrag (basierend auf der Aktion) verändert werden soll

Die Angabe regulärer Ausdrücke (RegEx) ist möglich.

Der Ausdruck .+ wird genutzt, wenn hier nichts eingetragen wird (alle Aktionen)

Neuer Kommentar

Optionaler Kommentar zum Historieneintrag

Agent

Optional: ID oder Login-Name des Agenten

Definiert, welcher Agent im Attribut Erstellt von des Historieneintrags gesetzt wird.

Ist hier kein Agent angegeben, wird das Attribut nicht geändert.

Kontakt erstellen oder aktualisieren

  • Aktualisiert einen bestehenden Kontakt, wenn eine ContaktID oder Kontakt-E-Mail-Adresse angegeben ist und die neuen Daten Änderungen zum aktuellen Stand darstellen.

  • Legt einen neuen Kontakt an, wenn keine ContaktID angegeben ist und die Kontakt-E-Mail-Adresse unbekannt ist.

In Verbindung mit dem Zusatzmodul Connect Database ermöglicht die Macro Action die Synchronisation mit einer externen Datenbanktabelle/-view, um Kontaktdaten in KIX bereitzustellen. Agenten können so die Kontaktdaten aus einem CRM, ERP o. a. ohne doppelte Datenpflege in KIX verwenden.

Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket

Parameter

Beschreibung

ContactID

Ergebnisvariable für den Rückgabewert. Es ist die ID des neuen bzw. zu aktualisierenden Kontakts anzugeben.

  • KontaktID ist höher priorisiert als Kontakt-E-Mail

  • Es kann eine OrganisationID oder Organisationsnummer übergeben werden

    • nur für PrimärOrganisation

    • ist eine OrganisationID angegeben, ist diese dominant

    • PrimaryOrganisationID kann aus einem optionalem Parameter "PrimaryOrganisationNumber" ermittelt werden

Debug

Wenn aktiviert, werden die Daten geloggt (Menü System > Logs)

Rollenobjekt (JSON)

JSON-String des Eingabeobjekts.

Erlaubt sind:

  • die Verwendung einer "${XYZ}"-Notation für die Objektübergabe 

  • oder die Angabe eines JSON-Strings welches das Objekt beschreibt (wie API)

  • Analog zur API werden bestehende Angaben übernommen, solange der entsprechende Schlüssel nicht definiert ist.

    Sobald ein Schlüssel in den Daten definiert wird, wird auch dessen Wert überschrieben.

Beispiel:

{
  "Email": "maxmuster4@example.com",
   # oder "ContactID": 123,
   "Firstname": "Max",
   "Lastname": "Muster",
   "Phone": null,
   "PrimaryOrganisationNumber": "KNR0815",
   # oder "PrimaryOrganisationID": 456, "Street":
   "Musterstr. 123",
   "City": "Musterstadt",
   "Comment": "some comment",
   "Country": "Germany",
   "Fax": null,
   "Mobile": null,
   "Title": null,
   "Zip": null,
   "DynamicFields": [{
      "Name": "Source",
      "Value": "created by ticket <KIX_TICKET_TicketNumber>"
   }]
}

Sie können in der Konfiguration angeben, ob auch ein Nutzerkonto angelegt bzw. aktualisiert werden soll. Somit können beim Abgleich von Kontakten auch Zugänge für das Agentenportal bzw. Self Service Portal eingerichtet werden. Dies kann relevant sein, wenn kein LDAP-AuthSync-Backend eingerichtet werden kann.

  • Beim Abgleich des Nutzerkontos kann angegeben werden:

    • welcher Login-Kenner verwendet wird

    • welches Passwort gesetzt wird

    • welcher Nutzungskontext gesetzt wird

    • welche Rollen zugeordnet werden

  • Wenn kein Nutzerkonto zu angegebenen Login-Kenner vorhanden ist und dem Nutzer noch kein Nutzerkonto zugeordnet ist:

    • wird ein neues Nutzerkonto angelegt

    • ist kein Passwort angegeben, wird der Login-Kenner als Passwort verwendet

    • ist ein Passwort angegeben, wird dieses gesetzt

    • werden Nutzungskontext und Rollen entsprechend der Vorgabe aktualisiert

    • wenn keine Angabe: Es erfolgt keine Zuordnung

  • Wenn kein Nutzerkonto zum angegebenen Login-Kenner vorhanden ist und dem Nutzer bereits ein Nutzerkonto zugeordnet ist:

    • wird das bestehende Nutzerkonto aktualisiert (Loginkenner aktualisiert)

    • ist kein Passwort angegeben, wird das bestehende Passwort nicht verändert

    • ist ein Passwort angegeben, wird dieses gesetzt

    • werden Nutzungskontext und Rollen entsprechend der Vorgabe aktualisiert

    • wenn keine Angabe: Es erfolgt keine Änderung

  • Wenn bereits ein Nutzerkonto zum angegebenen Login-Kenner vorhanden ist:

    • wird das bestehende Nutzerkonto dem zu aktualisierenden bzw. dem neuen Kontakt zugeordnet (und dem alten entzogen)

    • ist kein Passwort angegeben, wird das bestehende Passwort nicht verändert

    • ist ein Passwort angegeben, wird dieses gesetzt

    • werden Nutzungskontext und Rollen entsprechend der Vorgabe aktualisiert

    • wenn keine Angabe: Es erfolgt keine Änderung

Die Aktualisierung des Kontaktes mittels E-Mail als Indentifier ist ohne Angabe von ContactID, Firstname und Lastname möglich, sofern der SysConfig-Schlüssel ContactEmailUniqueCheck aktiviert ist.

{
  "Email": "maxmuster4@example.com",   # oder "ContactID": 123,
   "Firstname": "Max",
   "Lastname": "Muster",
   "Phone": null,
   "PrimaryOrganisationNumber": "KNR0815",    # oder "PrimaryOrganisationID": 456, "Street":
   "Musterstr. 123",
   "City": "Musterstadt",
   "Comment": "some comment",
   "Country": "Germany",
   "Fax": null,
   "Mobile": null,
   "Title": null,
   "Zip": null,
   "DynamicFields": [{
      "Name": "Source",
      "Value": "created by ticket <KIX_TICKET_TicketNumber>"
   }],
   "User": {
      "UserLogin": "Test",
      "UserPw": "Test",
      "IsAgent": 1,
      "IsCustomer": 0,
      "UserComment": "Comment",
      "ValidID": 1,
      "Roles": [
        "Superuser"
      ]
   }
}

Kontakt setzen

Setzt den Kontakt an einem Ticket.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Kontakt

ID, Login oder E-Mail-Adresse des zu setzenden Kontakts.

KIX Platzhalter sind möglich. 

Hinweise:

  • Bei gleichzeitigem Setzen von Kunde und Kontakt erfolgt aktuell keine Prüfung auf

    • Abhängigkeit zwischen Kunde (Organisation) und Kontakt

    • Existenz des gesetzten Kontakts.

  • Mit dem Setzen eines Kontaktes wird dem Ticket dessen Primär-Organisation zugeordnet.

  • Das Setzen eines unbekannten Kontakts ist möglich.

Konvertieren zu PDF

Die Macro Action konvertiert Informationen eines Objekts (wie bspw. Artikel, Ticket oder Asset) entsprechend der gewählten Druckvorlage in eine PDF-Datei. Sie ist das Pendant zum Konsolen-Befehl Console::Command:: Admin::HTMLToPDF::Convert.

Sie ermöglicht

  • die Ausgabe von Objekt-Informationen mittels Job oder Aktion in einer PDF-Datei.

  • die Bereitstellung von Artikel- oder Ticket-Inhalten in automatisiert erstellten Tickets oder in E-Mails (z. B. Erstellen und Versenden von Abrechnungen oder Serviceberichten).

  • die Bereitstellung des erstellten PDFs an einem Dynamischen Feld vom Typ Attachment (z. B. als Artikel-Anhang).

  • in Verbindung mit Webhooks auch das Archivieren von Ticketvorgängen als PDF in ein Dokumentenmanagementsystem

  • die kombinierte Verwendung mit den Macro Actions Artikel Anhang hinzufügen und Objekt zusammenstellen.

Die Macro Action nutzt die im System hinterlegten Druckvorlagen für den PDF-Druck. In der Konfiguration der Macro Action müssen Sie angeben, welche der zur Auswahl stehenden Druckvorlagen genutzt werden soll und von welchem Objekt (basierend auf der Angabe der Druckvorlage) die Informationen für das PDF bezogen werden sollen.

Zusätzlich zu den Pflichtangaben können Sie Dateiname, Filter, Allow und Ignore angeben und so die zu druckenden Informationen beeinflussen. Hierbei werden bestimmte Informationen der gewählten Druckvorlage überschrieben, sofern diese enthalten sind. Die Vorgaben der Druckvorlage werden dabei nur temporär für die PDF-Ausgabe geändert.

Als Rückgabewert liefert die Macro Action einen Dateianhang im JSON-Format, in dem Content, Filename, FileSize und ContentType enthalten ist. Auf diesen Rückgabewert kann bspw. in der Macro Action Article Attachment Add referenziert werden, um das erzeugte PDF als Anhang an einen Artikel zu setzen. 

macroaction_PDFConvert.png

Abb.: Verwendungsbeispiel Macro Action "Konvertieren zu PDF"

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Datei

Name der Ergebnisvariable

Gibt einen Dateianhang als JSON zurück, in dem Content, Filename, FileSize und ContentType enthalten ist.

Sie können bspw. in der Macro Action "Artikel Anhang hinzufügen" auf die Variable referenzieren, um das erzeugte PDF als Anhang an einen Artikel zu setzen.

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Vorlage

Auswahl der Vorlage, welche für den PDF-Druck verwendet werden soll.

Zur Auswahl stehen die im System hinterlegten Vorlagen für den PDF-Druck.

Identifier Type

Bestimmt den internen Parameter des Objekts (Objekttyp der gewählten Druckvorlage), z. B. ArticleID

Definiert, von welchem Objekt die Daten bezogen werden.

Identifikator

Wertangabe, die aufgrund des Identifikator-Typs gesetzt werden muss, damit die Daten für die Druckvorlage gewonnen werden können.

Z. B.<KIX_ARTICLE_ArticleID> oder ${RootObjectID}.

Dateiname

Optionaler Dateiname, der anstatt des Standardnamens verwendet werden soll

Z. B.: Article_<KIX_ARTICLE_ArticleID>_<TIME_YYMMDD>.

Sie können den Platzhalter <TIME_YYMMDD> verwenden, um dem Dateinamen die Erstellungszeit der PDF-Datei hinzuzufügen.

Erweitert

Optional: Definiert, welche zusätzlichen Daten (Expands) für den Druck herangezogen werden sollen, z. B.: Dynamisches Feld.

Die zur Auswahl stehenden Erweiterungen hängen von der gewählten Vorlage ab.

Filter

Optional: Sie können Filter angeben, um bestimmte Erweiterungen einzuschränken (Format als JSON)

Möglich nur bei ID-Listen. Gilt überall dort, wo das gleiche Objekt genutzt wird.

Beispiel: Von einem Ticket sollen nur die für den Kunden sichtbaren Artikelberücksichtigt werden:

{
  "Article": {
      "AND": [{
        "Field": "CustomerVisible",
        "Type": "EQ",
        "Value": "1"
      }]
  }
}

Erlaubt

(Whitelist)

Optionale Einschränkung des Tabelleninhalts.

Nur möglich bei Tabellentyp "KeyValue" oder "DataSet"

Überschreibt/manipuliert das, was in der Druckvorlage für die jeweilige Tabelle gespeichert ist.

Die Verwendung von Regulären Ausdrücken (RegEx) ist möglich.

{
  "InfoTableLeft": {
    "AccountedTime": "KEY",
    "DynamicField_DFChecklist": "KEY",
    "DynamicField_DFDropdown": "^regex$",
    "Created": "KEY",
    "CreateBy": "KEY",
    "ContactID": "KEY",
    "PendingTime": "KEY"
  }
}

Ausführliche Hinweise zum Parameter: Die Parameter Allow und Ignore

Ignorieren

(Blacklist)

Optionale Einschränkung des Tabelleninhalts.

Nur möglich bei Tabellentyp "KeyValue" oder "DataSet"

Überschreibt/manipuliert das, was in der Druckvorlage für die jeweilige Tabelle gespeichert ist.

Der Aufbau ist analog Erlaubt - mit dem Unterschied, dass die gesetzten Werte ignoriert werden.

Ausführliche Hinweise zum Parameter: Die Parameter Allow und Ignore

Kunde setzen

Setzt den Kunden an einem Ticket.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Organisation

ID der Organisation oder Kundennummer.

KIX Platzhalter sind möglich.

Hinweise:

  • Bei gleichzeitigem Setzen von Kunde und Kontakt erfolgt aktuell keine Prüfung auf

    • Abhängigkeit zwischen Kunde (Organisation) und Kontakt

    • Existenz der gesetzten Organisation

LDAP zu Kontakt

  • Aktualisiert eine bestehende Organisation, wenn eine OrganisationID oder Organisationsnummer angegeben ist und die neuen Daten Änderungen zum aktuellen Stand darstellen.

  • Legt eine neue Organisation an, wenn keine OrganisationID angegeben ist und die Organisationsnummer unbekannt ist. 

Verwendung/Jobtyp: Synchronisation

Konfigurationsparameter

Informationen zu den Parametern finden Sie auch unter: Attribute der Konfiguration

Parameter

Bedeutung

Überspringen

Ist hier das Häkchen gesetzt, wird die entsprechende Aktion nicht ausgeführt.

Damit können Sie einzelne Aktionen von der Synchronisation (zeitweise) ausschließen, ohne den Job neu zu konfigurieren.

Sind mehrere Aktionen im Job konfiguriert (z. B. zwei verschiedene LDAP-Server), laufen die anderen Aktionen normal weiter.

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Host

FQDN welches der LDAP-Server für die Synchronisation nutzt oder kommaseparierte Liste wenn mehrere Hosts angesprochen werden sollen.

Beispiele:

  • ldap.example.org

  • ldap1.example.org,ldap2.example.org

BaseDN

Einstiegspunkt in die Verzeichnisstruktur.

Beispiel: dc=meinUnternehmen,dc=de

Contact / User Sync Map

JSON-String, der das Mapping von KIX-Attributen zu AD-/LDAP-Attributen beinhaltet.

Das Mapping muss folgende Form haben:

{
  "KIXAttributName" : "LDAPAttributName",
  "KIXAttributName" : "LDAPAttributName"
}

Alle im Mapping angegebenen Attribute müssen existieren. Anderenfalls kann keine korrekte Zuordnung erfolgen. Achten Sie auch auf korrekte Schreibweise.

Der Kontakteintrag wird auf Basis der aus dem LDAP/AD ermittelten oder fixierten Werte erstellt bzw. aktualisiert.

Die Angabe folgender Attribute ist dazu mindestens erforderlich:

  • Email

  • Firstname

  • Lastname

  • UserLogin

Achtung

Achtung!: Sind diese Angaben im LDAP-/AD-Eintrag nicht gesetzt (leer), kann kein Kontakteintrag erzeugt oder aktualisiert werden. 

Beispiel einer UserSync Map

"ContactUserSync": {
   "Email": "mail",
   "Email1": "SET:mail@example.com",
   "Email3": "mail",
   "Email5": "automatedmail",
   "Title": "title",
   "Firstname": "givenname",
   "Lastname": "sn",
   "Street": "streetAddress",
   "City": "l",
   "Zip": "postalCode",
   "Phone": "telephoneNumber",
   "Mobile": "mobile",
   "Fax": "facsimileTelephoneNumber",
   "UserLogin": "sAMAccountName",
   "PrimaryOrganisationID": "SET:123",
   "OrganisationIDs": [
      "department",
      "SET:13"
   ],
   "ImgThumbNail": "BINARY:jpegPhoto",
   "DynamicField_Source": "SET:ActiveDirectory1",
   "DynamicField_XYZ": "department",
   "DynamicField_ZIPCity":"CONCAT: postalCode}-{l}-DE"
}

UID

Name des LDAP-Attributes, welches zur eindeutigen Identifikation eines LDAP-Eintrages verwendet wird (Nutzerlogin).

Zum Beispiel: UID | sAMAccountName

Sollte kein UserLogin in der Sync Map angegeben werden, wird auf Basis der UID in der KIX Datenbank ein Nutzerlogin erstellt und auf invalid gesetzt. UID und UserLogin können ohne Probleme auf das selbe Attribut zeigen.

Tipp

Durch Setzen des Attributs "AuthAttr" im SysConfig-Schlüssel Authentication###000-Default können Sie einen alternativen Kenner für das UserLogin setzen.

Ist dieser bspw. auf "mail" gesetzt, kann sich ein Nutzer mit seiner im System hinterlegten Mailadresse anmelden.

Werden zudem die Nutzerdaten mit dem LDAP per Job synchronisiert, kann der Nutzer sich immer mit seiner aktuellen Mailadresse anmelden, auch wenn diese sich z. B. aufgrund von Namensänderung geändert hat.

Sollte die Anmeldung via Mailadresse fehlschlagen, wird die UID/das im System hinterlegte Nutzer Login als Fallback für die Authentifizierung verwendet.

Bitte beachten Sie:

Die Aktualisierung eines Kontaktattributs "Email" ist nur dann möglich, wenn in KIX ein Nutzereintrag vorhanden ist. Anderenfalls wird bei Änderung einer Email-Adresse im AD/LDAP ein neuer Kontakt angelegt.

Parameter

JSON-String für LDAP-Verbindungsparameter, z. B.:

Default:
{
    "port": "389",
    "version": "3",
    "timeout": "120",
    "async": "0"
}

Suchnutzer DN

User DN des Nutzers mit dem sich KIX mit dem LDAP Server verbindet, um die Suche durchzuführen

Beispiel: cn=kix,cn=user,dc=meinUnternehmen,dc=de

Suchnutzer Password

Passwort des Nutzers mit dem sich KIX mit dem LDAP Server verbindet, um die Suche durchzuführen

Beschränkung auf GroupDN

Erlaubt die Einschränkung der abzufragenden Einträge auf Objekte, die in der angegebenen Gruppe enthalten sind. Dies kann erforderlich sein, wenn die Gruppenmitgliedschaft nicht über einen direkten Filter auf dem Kontakteintrag eingeschränkt werden kann.

Access Attribute

Definiert das LDAP-Attribut, das zum Überprüfen der Gruppenmitgliedschaft verwendet wird. Verwendet memberUid, wenn nichts angegeben ist.

Beispiel: member| memberUid| ...

User Attribute

Legt fest, ob der Distinguished Name des Benutzers ("DN") oder das im Parameter "UID" definierte LDAP-/AD-Attribut zur Überprüfung der Gruppenmitgliedschaft verwendet wird.

Immer filtern

Permanenter LDAP Filter, der für alle Anfragen angewandt wird.

Syntax: (&amp;(mail=*)(sAMAccountName=*))

Beispiele:

  • alle nicht-deaktivierten Nutzerkonten:

    (&amp;(objectClass=user)(! (userAccountControl:1.2.840.113556.1.4.803:=2)))

  • alle Nutzereinträge, bei denen "departmentNumber" und "mail" gesetzt ist:

    (&amp;(objectClass=user)(departmentNumber=*)(mail=*))

Sie können auch Gruppenfilter eingetragen.

Weitere Beispiele finden Sie unter: http://www.selfadsi.de/ldap-filter.htm

Zeichensatz

Zeichensatz, in den die LDAP-Suchergebnisse konvertiert werden.

Default: utf-8

Seitengröße

Sie können bei Bedarf die Gesamtanzahl der zu synchronisierenden Daten in mehrere Datenpakete zu je n Datensätzen aufsplitten.

Bspw. wenn Sie vom Server die Nachricht erhalten, dass der Antwortdatensatz zu groß ist ("max size exceeded"). 

Tragen Sie hier die Anzahl der Datensätze ein, die pro Anfrage (Request) übertragen werden. Die Verarbeitung erfolgt dann blockweise in Paketen mit bspw. 20 Datensätzen.

Debug

Debug-Ausgaben de-/aktivieren.

Mögliche Werte: yes | no

Ist der Parameter aktiv, werden wesentliche Schritte des LDAP-/AD-Datenabgleichs im Log des Jobs (Job-Historie) vermerkt. 

Hinweis

  • Diese Option sollte nur vorübergehend aktiviert werden, da sonst die Historieneinträge sehr umfangreich werden und entspr. Speicherbedarf erzeugen.

  • Der SysConfig-Schlüssel Automation::MinimumLogLevel muss auf den Wert "Debug" gesetzt sein. Anderenfalls werden nur die von der Macro Action gelieferten Fehlermeldungen erfasst, alle anderen Debug-Informationen jedoch nicht.

Dry Run

Trockenlauf (Testlauf) de-/aktivieren.

Ist der Parameter aktiviert, erfolgt kein tatsächlicher Datenabgleich. Die aus der LDAP-/AD-Quelle ermittelten Daten werden jedoch im Job-Log vermerkt, als würde ein Update stattfinden. Der Datenabgleich kann somit im Vorfeld zu Testzwecken simuliert werden. 

Hinweis

Diese Option sollte wie Debug nur vorübergehend aktiviert werden, da sonst die Historieneinträge sehr umfangreich werden und entsprechend Speicherbedarf erzeugen.

Es wird weiterhin empfohlen, diese Funktion in Verbindung mit AlwaysFilter zu verwenden um spezifische oder eine geringe Anzahl von LDAP-Einträgen zu prüfen.

Anmerkung

  • Ist im Mapping das User-Attribut "Login" enthalten, wird auch ein User synchronisiert.

  • Ein vorhandener Kontakt wird beim Ausführen des Jobs, basierend auf dem Mapping, aktualisiert.

  • Ein nicht vorhandener Kontakt wird beim Ausführen des Jobs neu erstellt.

Hinweis

  • Die Nutzeranmeldung ist von der Synchronisation nicht direkt betroffen, jedoch die Funktion des "AuthSync".

  • Beim automatischen Import ist auf Datenbeschränkungen des AD zu achten (blockweises Einlesen).

  • Single-Point-of-Trust ist das externe System.

Macro ausführen

Erlaubt das Ausführen weiterer Macros innerhalb einer MacroAction. 

Zur Unterscheidung:

  • Die Macro Action Macro ausführen kann nur an einem spezifischen Objekt ausgeführt werden. 

  • Die Macro Action Schleife hingegen kann auf mehrere Werte/Arrays ausgeführt werden.

Verwendung/Jobtyp: Asset, Berichte. Synchronisation. Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

ObjectID

Ergebnisvariable (Optional)

Die ID des Objektes, für das das Macro ausgeführt werden soll.

Macro

Das auszuführende Makro stellt - abhängig von seinem Typ - die entsprechenden Actions zur Verfügung. 

Die Makros können auch von einem anderen Typ sein und sind nicht vom gewählten JobTyp abhängig.

Ein Anwendungsbeispiel finden Sie unter Berichte automatisiert erstellen

Nutzer erstellen oder aktualisieren

Die Macro Action erstellt einen neuen Nutzer oder aktualisiert einen bestehenden. Erlaubt ist die Angabe einer Liste von zugeordneten Rollen.

Parameter

Beschreibung

UserID

Ergebnisvariable für den Rückgabewert. Es ist die ID des neuen bzw. zu aktualisierenden Nutzers anzugeben.

Debug

Wenn aktiviert, werden die Daten geloggt (Menü System > Logs)

Nutzerobjekt (JSON)

JSON-String des Eingabeobjekts.

Erlaubt sind:

  • die Verwendung einer "${XYZ}"-Notation für die Objektübergabe 

  • oder die Angabe eines JSON-Strings welches das Objekt beschreibt (wie API)

  • Analog zur API werden bestehende Angaben übernommen, solange der entsprechende Schlüssel nicht definiert ist.

    Sobald ein Schlüssel in den Daten definiert wird, wird auch dessen Wert überschrieben.

Das grundsätzliche Verhalten für die Aktualisierung bzw. Neuanlage entspricht dem Verhalten der Macro Action Kontakt erstellen oder aktualisieren

Beispiel:

{
    "UserID": 123,
    "UserLogin": "login",
    "UserPw": "****",
    "UserComment": "Comment",
    "IsAgent": 1,
    "IsCustomer": 0,
    "Roles": [
        "Superuser"
    ],
    "ValidID": 1
}

Objekt zusammenstellen

Fügt mehrere Objekte zu einem neuen Objekt zusammen.

Kann bspw. eine aus einem Bericht extrahierte Tabelle als Artikelanhang an ein Ticket anfügen.

Verwendung/Jobtyp: Asset,  Berichte, Synchronisation, Ticket

Parameter

Beschreibung

Objekt

Bezeichner der Ergebnisvariable.

Der angegebene Bezeichner ist eine "Text-Repräsentation" des unter "Definition" deklarierten Objekts. Auf dessen Attribute und Sub-Attribute kann zugegriffen werden.

ObjectName.Definition.Attribute.SubAttribut

Das Objekt besitzt die Eigenschaften:

  • Typ: Format (Datenstruktur) des Objekts (JSON oder YAML)

  • Definition: Deklaration des Objekts (Perl-Struktur).

    Sie können Platzhalter und Variablen verwenden.

    Das erzeugte Objekt wird als Ergebnisvariable zur Verfügung gestellt.

    {
  "Filename":"dummy.csv",
  "ContentType":"${Report.Results:0.ContentType}",
  "Content":"${Report.Results:0.Content|JSON}"
}

Debug

Wenn aktiviert, wird die Objektdefinition nach Platzhalterersetzung geloggt (Menü System > Logs)

Hinweise:

Ein unter Definition erzeugtes Attachment-Objekt hat 3 Eigenschaften:

  • Filename: Name und Dateiendung des erzeugten Attachmentobjekts (z. B. "dummy.csv")

  • ContentType: MIME Type des Inhalts (z. B. ${Report.Results:0.ContentType})

    Infos dazu auch unter: https://wiki.selfhtml.org/wiki/MIME-Type/%C3%9Cbersicht

  • Content: Inhalt des Attachmentobjekts mit Angabe der Pipe

    Z. B.: ${Report.Results:0.Content|JSON}

    Die Angabe der Pipe mit JSON (|JSON) ist notwendig, um den Inhalt valide in das JSON-Format einzufügen.

Anwendungsbeispiel

Im Beispiel wird ein mittels Bericht erstellen (1. Aktion) erzeugter Bericht als neues Attachmentobjekt (Artikelanhang) erzeugt.

Organisation erstellen oder aktualisieren

  • Aktualisiert eine bestehende Organisation, wenn eine OrganisationID oder Organisationsnummer angegeben ist und die neuen Daten Änderungen zum aktuellen Stand darstellen.

  • Legt eine neue Organisation an, wenn keine OrganisationID angegeben ist und die Organisationsnummer unbekannt ist. 

In Verbindung mit dem Zusatzmodul Connect Database ermöglicht die Macro Action die Synchronisation mit einer externen Datenbanktabelle/-view, um Organisationsdaten in KIX bereitzustellen. Agenten können so die Organisationsdaten aus einem CRM, ERP o. a. ohne doppelte Datenpflege in KIX verwenden.

Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket

Parameter

Beschreibung

OrganisationID

Ergebnisvariable für den Rückgabewert / die ID der neuen bzw. zu aktualisierenden Organisation.

OrgID ist höher priorisiert als Organisationsnummer.

Debug

Wenn aktiviert, werden die Daten geloggt (Menü System > Logs)

Organisation JSON Object

JSON-String des Eingabeobjekts. Erlaubt sind:

  • die Verwendung einer "${XYZ}"-Notation für die Objektübergabe

  • oder die Angabe eines JSON-Strings welches das Objekt beschreibt (wie API)

  • Analog zur API werden bestehende Angaben übernommen, solange der entsprechende Schlüssel nicht definiert ist. Sobald ein Schlüssel in den Daten definiert wird, wird auch dessen Wert überschrieben

{   
   "City": "Chemnitz",
   "Comment": "",
   "Country": "Germany",
   "Name": "KIX Service Software GmbH",
   "Number": "KIX Service",
   # oder "OrganisationID": 23
   "Street": "Schönherrstraße 8",
   "Url": "https://www.kixdesk.com",
   "Zip": "09113",
   "DynamicFields": [{
      "Name": "Type",
      "Value": [ "supplier/partner (external)", "customer" ]
   }]
}

Priorität setzen

Setzt die Priorität an einem Ticket.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Priorität

Exakte Bezeichnung der Priorität 

Sie müssen den exakten Namen des Attributs verwenden, das im Backend gespeichert werden soll.

Rolle erstellen oder aktualisieren

Die Macro Action erstellt eine neue Rolle oder aktualisiert eine bestehende. Erlaubt ist die Angabe einer Liste von Berechtigungen und Nutzern. Bei einer Aktualisierung werden bestehende Berechtigungen und Nutzerzuordnungen überschrieben bzw. entfernt.

Parameter

Beschreibung

RoleID

Ergebnisvariable für den Rückgabewert. Es ist die ID der neuen bzw. zu aktualisierenden Rolle anzugeben.

Debug

Wenn aktiviert, werden die Daten geloggt (Menü System > Logs)

Rollenobjekt (JSON)

JSON-String des Eingabeobjekts.

Erlaubt sind:

  • die Verwendung einer "${XYZ}"-Notation für die Objektübergabe 

  • oder die Angabe eines JSON-Strings welches das Objekt beschreibt (wie API)

  • Analog zur API werden bestehende Angaben übernommen, solange der entsprechende Schlüssel nicht definiert ist.

    Sobald ein Schlüssel in den Daten definiert wird, wird auch dessen Wert überschrieben.

Das grundsätzliche Verhalten für die Aktualisierung bzw. Neuanlage entspricht dem Verhalten der Macro Action Kontakt erstellen oder aktualisieren

Beispiel:

Hinweis: Es sind entweder UserLogins ODER UserIDs anzugeben. Bei Angabe von beidem gewinnen die UserIDs. UserLogins und UserIDs können Strings aus kommaseparierten Listen sein (anstatt des Arrays)

{
    "RoleID": 123,
    "Name": "Role1",
    "UsageContext": "AGENT,CUSTOMER",
    "Comment": "Comment",
    "ValidID": 1,
    "Permissions": [
        {
            "Type": "Resource",
            "Target": "/tickets",
            "Value": "CREATE,UPDATE",
            "IsRequired": 1,
            "Comment": "Comment"
        },
        {
            "Type": "Resource",
            "Target": "/contacts",
            "Value": "READ",
            "IsRequired": 0,
            "Comment": "Comment"
        }
    ],
    "UserLogins": ["login1", "login2"],
    "UserIDs": [1, 2]
}

Schleife

Erzeugt mehrstufige (verschachtelte) Aktionen.

Die Macro Action Schleife kann verwendet werden, um ein referenziertes Macro zu definieren und dieses für verschiedene Objekte auszuführen. Bspw. um den in einem Ticket dokumentierten Workaround an alle Kind-Tickets weiterzugeben oder um Änderungen an einem Eltern-Ticket auch an allen Kind-Tickets vorzunehmen (z. B. "Flächenstörung").

Zur Unterscheidung: Die Macro Action Macro ausführen kann nur auf 1 spezifisches Objekt ausgeführt werden.

Mit der Macro Action Schleife können Aktionen beliebig verschachtelt werden. Dadurch können komplexe, mehrstufige Workflows abgebildet und Verweise zwischen mehreren, aufeinander verweisende Tickets für Automatismen genutzt werden. Achten Sie jedoch darauf, keine Endlosschleifen zu erzeugen!

Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, wird die Werte-Liste geloggt (Menü System > Logs)

Werte

Liste von Werten, die vom Loop berücksichtigt werden.

Entweder kommaseparierte Liste oder durch einen Platzhalter generiertes Array (z. B. <KIX_TICKET_DynamicField_RelatedTickets_Key>).

Schleifenvariable

Optional: Bezeichner der Ergebnisvariable für die aktuelle Loop-Wiederholung.

Die Variable kann analog zu anderen Ergebnisvariablen verwendet werden.

Maro

Konfigurationsmöglichkeit weiterer Aktionen der nächst tieferen Ebene.

Beispiel zur Verwendung der Aktion: Verschachtelung von Macro Actions mit "Schleife"

Set Owner (Auto Dispatch)

Ermöglicht in zeit- oder eventbasierten Jobs die automatische Zuordnung von Tickets zu Agenten und entlastet somit den Dispatcher.

Mögliche Anwendungsfälle:

  • Beim Verschieben eines Tickets in ein Team, ordnet die Macro Action den Bearbeiter zu, welcher die wenigsten aktiven Tickets hat (und der online ist).

  • Periodische Prüfung aller Tickets in den Teams, die noch nicht in Bearbeitung sind und Neuvergabe der zu erledigenden Aufgaben entsprechend Auslastung und SLA-Zielen.

Der Automatismus setzt anhand der definierten Parameter den Bearbeiter sowie diverse Eigenschaften am Ticket und verschiebt sie ins entsprechende Team. Dabei wird berücksichtigt, wieviel Tickets der Agent zu bearbeiten hat, um diesen nicht zu überlasten.

Sofern Tickets nicht zugewiesen werden können, erfolgt keine Änderung des Bearbeiters. Die Tickets werden bei erneuter Jobausführung berücksichtigt.

In den Filter-Einstellungen des Jobs können Sie die Sortierreihenfolge festlegen. Damit können Sie bspw. festlegen, dass der Automatismus stets die ältesten Tickets zuerst verarbeitet und zuweist (absteigende Sortierung nach dem Alter).

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Summe relevanter Agenten

Einschränkung der Zuteilung auf Agenten mit den hier ausgewählten Eigenschaften.

  • Mit Lese-Schreib-Basisberechtigungen auf das Ticket

    • Wenn aktiviert, werden die Tickets nur Agenten zugewiesen, die als Basisberechtigung mindestens Lese- und Schreibrechte auf das Ticket haben.

      Erlaubt die zusätzliche Einschränkung auf Agenten, welche das Team abonniert haben.

    • Wenn nicht aktiviert, berücksichtigt der Automatismus alle Agenten bei der Zuordnung.

  • Gebuchte Teams

    Schalter wird nur angezeigt, wenn Mit Lese-Schreib-Basisberechtigung aktiviert ist.

    Erlaubt die zusätzliche Einschränkung auf Agenten, welche das Team des Tickets (in ihren persönlichen Einstellungen) abonniert haben.

Online Status

Einschränkung der Zuteilung auf (nicht) aktive Agenten.

Somit werden die Tickets keinen inaktiven Agenten zugewiesen (z. B. Urlaub, Krankheit usw.)

  • Nur aktive Agenten

    • Wenn aktiviert, werden die Tickets nur Nutzern zugewiesen, die im Kontext Agent angemeldet sind und deren letzte Aktivität max. n Minuten zurückliegt. Den Zeitpunkt der letzten Aktivität können Sie unter Letzter Request innerhalb festlegen.

    • Wenn nicht aktiviert, werden auch inaktiven Nutzern Tickets zugewiesen.

      Beachten Sie, dass hierbei viele Tickets auflaufen könnten, die unbearbeitet bleiben. Setzen Sie daher zumindest ein Ticket-Limit.

  • Letzte Anfrage innerhalb von

    Eingabefeld wird nur angezeigt, wenn Nur aktive Agenten aktiviert ist.

    Schränkt die Zuweisung der Tickets auf aktive Agenten ein, welche nur innerhalb der letzten n Minuten aktiv waren. Sie können hier die Anzahl an Minuten selbst definieren.

    Default: 60 Minuten

Berechnung Ticketzahlen der Agenten

Angabe der Berechnungsweise für die Ermittlung der Anzahl der aktiven Tickets eines Agenten.

Bei der Ermittlung werden nur Tickets berücksichtigt, welche den hier angegebenen Ticketstatus, Teams und Tickettypen entsprechen.

  • Status

    • Wählen Sie die zu betrachtenden Ticketstatus aus (Mehrfachauswahl möglich)

    • Die Verwendung des Platzhalters <KIX_TICKET_StateID> ist möglich.

    • Wenn nichts ausgewählt ist, werden alle Status (ViewableStateTypes) betrachtet

  • Teams

    • Wählen Sie die zu betrachtenden Teams aus (Mehrfachauswahl möglich)

    • Die Verwendung des Platzhalters <KIX_TICKET_QueueD> ist möglich.

    • Wenn nichts ausgewählt ist, werden alle Teams betrachtet

  • Typen

    • Wählen Sie die zu betrachtenden Tickettypen aus (Mehrfachauswahl möglich)

    • Die Verwendung des Platzhalters <KIX_TICKET_TypeID> ist möglich

    • Wenn nichts angegeben ist, werden alle Tickettypen betrachtet.

Vorgehen

Auswahl des Verteilungsverfahrens

  • Zufall

    • Gleichverteilung der Wahrscheinlichkeiten

    • Agenten, bei denen das angegebene Ticket-Limit erreicht ist, werden nicht berücksichtigt

  • wenigste Tickets

    • Dem Agent mit den wenigsten Tickets wird das Ticket zugeteilt

    • Bei gleicher Anzahl wird zufällig ein Agent ausgewählt

      (entspricht Verteilungsverfahren Zufall)

    • Agenten, bei denen das angegebene Ticket-Limit erreicht ist, werden nicht berücksichtigt.

Ticket-Limit

(Kanban-Limit)

Maximale Anzahl an Tickets pro Agent.

Definiert die maximale Anzahl an Tickets, die ein Agent in seinem Kanban-Board haben darf. Ist diese Anzahl überschritten, wird der Agent bei der Zuweisung nicht berücksichtigt.

Sie können die Anzahl nach Bedarf selbst festlegen.

Default: 0 (keine Limitierung)

Set password for user

Setzt ein neues Passwort.

Wird initial vom Job "Password Reset Confirmed" für den Prozess zum Zurücksetzen des Nutzerpassworts verwendet.

Parameter

Beschreibung

Überspringen

Wenn aktiviert: Überspringt die Ausführung der Aktion

Nutzer Login oder ID

ID des Nutzers, dessen Passwort zurückgesetzt werden soll

KIX Platzhalter werden unterstützt, z. B. <KIX_TICKET_DynamicField_PwResetUserID_Value>

Passwort

Das zu setzende Passwort

Das Passwort kann zuvor mittels Macro Action "Generate Random String" erzeugt werden. Geben Sie hier die Ergebnisvariable an.

Z. B. ${newPassword}

Set Result

Wird in Ruleset-Macros verwendet, um das Macro-Ergebnis zur Weiterverarbeitung an die aufrufende Regel zu übergeben.

Liefert das Ergebnis einer zuvor ausgeführten Macro Action zurück.

Verwendung/Typ: Ticket, Asset, Synchronisation, Berichte, Kontakt

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Result Variable

Name der Ergebnisvariable

Durch Referenz auf diesen Namen kann in einer Regel auf das Macro-Ergebnis (Wert) zugegriffen werden.

Wert

Wert, der in der Ergebnisvariable gespeichert werden soll. Diesen Wert liefert die Macro Action zurück.

Sie können den Namen der Ergebnisvariable einer zuvor ausgeführten Macro Action angeben, um deren Wert zurückzuliefern (z. B.: ${varTicket} ). Es wird die vollständige Variablenfunktionalität von Macros unterstützt (s. auch Variablen)

SLA setzen

Setzt ein SLA Kriterium im Ticket. Lassen Sie das Feld leer, wenn ein SLA vom Ticket entfernt werden soll.

Verwendung/Jobtyp: Ticket

Im Feld SLA ist die ID oder der Name des SLA anzugeben. Die Verwendung von KIX Platzhaltern ist möglich.

Wenn die Debug-Option aktiviert ist, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

SLA Kriterium Pausieren/Fortsetzen

Die Macro Action veranlasst das Pausieren oder Fortsetzen der Reaktions- bzw. Lösungszeit am Ticket anhand des am Ticket gesetzten Status. Sie wird vom initialen Job "SLA Time Suspension" verwendet.

Erhält ein Ticket einen Status, der im zugeordneten SLA als Auszusetzende Ticketstatus für Reaktions- und/oder Lösungsdauer hinterlegt ist, wird das entsprechende SLA Kriterium pausiert. Verlässt das Ticket diesen Status wieder, läuft die Zeit für das entsprechende Kriterium weiter.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

SLA Kriterium

Exakter Name des zu pausierenden/fortzusetzenden SLA Kriteriums (FirstResponse oder Solution)

  • Pausiert das durchs Kriterium benannte SLA, wenn einer der im Kriterium unter Auszusetzende Ticketstatus gespeicherten Status gesetzt ist und noch nicht pausiert und noch nicht erfüllt ist.

  • Fortführung des durchs Kriterium benanntem SLA, wenn keiner der unter Auszusetzende Ticketstatus hinterlegten Status gesetzt ist und aktuell pausiert und noch nicht erfüllt ist.

    Es erfolgt eine Neuberechnung der Zielzeit. Die Dauer der SLA-Pause wird zur ursprünglichen Zielzeit hinzugefügt.

Sperrstatus setzen

Setzt den Sperrstatus eines Tickets.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Sperren

Exakte Bezeichnung des Sperrstatus, z. B. "lock" oder “unlock”

Status setzen

Setzt den Status am Ticket.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Status

Wählen Sie den zu setzenden Status aus.

z. B. neu | offen | warten zu Erinnerung

Hinweise:

Bei Setzen eines Warten-Status (Statustypen "pending reminder" oder "pending auto") sind weitere Parameter möglich. Zudem muss mindestens eine Angabe zur Wartezeit definiert werden:

Warten" - Zeitdifferenz: Differenz des zu setzenden Zeitpunktes zum Ausführungszeitpunkt bzw. relative Wartezeit in Sekunden. Eine Angabe in Form "60 * 60 * 24" ist möglich. Nicht zulässige Werte, werden als "0" interpretiert.

Warte Zeitpunkt: Zielzeitpunkt in Format "YYYY-MM-DD hh:mm:ss". Es können auch Platzhalter verwendet werden, um Zielzeitpunkte bspw. aus dynamischen Feldern des Typs Date oder DateTime zu beziehen (z. B. KIX_TICKET_DynamicField_DatumZeit). 

Zielzeit: kann den Wert EOB, BOB oder <leer> annehmen.

  • BOB setzt den "Begin Of Businessday"  des durch PendingDiffTime oder PendingDateTime avisiert Zielzeitpunkts.

    Liegt der Zielzeitpunkt außerhalb der Servicezeit wird der nächste Servicetag betrachtet.

  • EOB setzt den "End Of Businessday".

    Wird keine der Optionen genutzt, wird der exakte Zeitpunkt eingetragen.

    PendingTimeOffset hat Vorrang gegenüber PendingDateTime.

    Wird bei PendingTimeOffset oder PendingDateTime eine Zeit angegeben und zusätzlich EOB oder BOB, hat die Eingabe bei Target Time Vorrang.

Team erstellen oder aktualisieren

Die Macro Action erstellt ein neues Team oder aktualisiert eine bestehendes.

Parameter

Beschreibung

TeamID

Ergebnisvariable für den Rückgabewert. Es ist die ID des neuen bzw. zu aktualisierenden Teams anzugeben.

Debug

Wenn aktiviert, werden die Daten geloggt (Menü System > Logs)

Nutzerobjekt (JSON)

JSON-String des Eingabeobjekts.

Erlaubt sind:

  • die Verwendung einer "${XYZ}"-Notation für die Objektübergabe 

  • oder die Angabe eines JSON-Strings welches das Objekt beschreibt (wie API)

  • Analog zur API werden bestehende Angaben übernommen, solange der entsprechende Schlüssel nicht definiert ist.

    Sobald ein Schlüssel in den Daten definiert wird, wird auch dessen Wert überschrieben.

Das grundsätzliche Verhalten für die Aktualisierung bzw. Neuanlage entspricht dem Verhalten der Macro Action Kontakt erstellen oder aktualisieren

Beispiel:

{
    "TeamID": 123,
    "Name": "team",
    "UnlockTimeout": 60,
    "SystemAddress": "kix@localhost",
    "Signature": "--<br>&lt;KIX_CONFIG_OrganizationLong&gt;<br>&lt;KIX_CONFIG_OrganizationAddress&gt;",
    "Comment": "Comment",
    "Permissions": [
        {
            "Permission": "READ+WRITE",
            "Role": "Ticket Agent",
            "Type": "Base"
        }
    ],
    "ValidID": 1
}

Team setzen

Setzt das Team an einem Ticket.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Team

Vollständige Bezeichnung des zu setzenden Teams. 

KIX Platzhalter sind möglich.

Um untergeordnete Teams zu setzen, gilt folgende Schreibweise: Ebene1::Ebene2::Ebene3

Beispiel: 2nd-Level::On Site::Chemnitz

  • Ebene 1 = 2nd-Level

  • Ebene 2 = On Site

  • Ebene 3 = Chemnitz

Text entnehmen

Extrahiert Teile aus einem bestehenden Text.

Die Macro Action Kann bspw. die in einem Bericht erzeugte Ergebnistabelle (oder Teile davon) extrahieren, um sie im Nachrichtentext oder im Artikelanhang bereitzustellen.

Verwendung/Jobtyp: Asset, Berichte. Synchronisation. Ticket

Parameter

Beschreibung

ExtractedText

Individueller Bezeichner der Ergebnisvariable, welche den extrahierten Text aufnimmt.

Debug

Wenn aktiviert, wird der übergebene Text nach Platzhalterersetzung und das Ergebnis der Extraktion geloggt (Menü System > Logs)

RegEx

Gültiger Regulärer Ausdruck

z. B. <body>(.*?)</body>

Text

Der Text, auf dem die RegEx angewendet werden soll.

Sie können Variablen und Platzhalter verwenden, z. B. Report.Results:0.Content}

Capture Group Names

Optionale Benennung der einzelnen Capture Groups des RegEx.

Sind keine Namen angegeben, werden die Gruppen per Index durchnummeriert (1,..., n)

Bei Verwendung als Variable in anderen Actions:

  • Wird kein Variablenname vergeben, so lautet dieser: ExtractedText

  • Zugriff auf Werte der Variable erfolgt mittels Angabe der Capture Group, z. B.:

    • keine Variable definiert und auch keine benannte Capture Group: ${ExtractedText.1}

    • benannte Variable und benannte Capture Group: ${MyVariable.MyValue}

Ein Anwendungsbeispiel finden Sie unter Berichte automatisiert erstellen

Ticket anlegen

Legt ein neues Ticket mit vordefinierten Werten an.

Verwendung/Jobtyp: Ticket

Die anzugebenden Parameter sind analog zur Ticketerstellmaske. Zusätzlich können Ergebnisvariablen und Dynamische Felder inkl. ihrer Werte verwendet werden.

Parameter

Beschreibung

Ergebnisbezeichnungen

Ermöglicht die Speicherung der Ticket ID in einer Variablen, um bspw. in nachfolgenden Macro Actions darauf zu referenzieren (s. Variablen)

  • NewArticleID: Individueller Name/Bezeichner einer Variable zum Speichern der Artikel ID 

    z. B. myArticleVariable

  • NewTicketID: Individueller Name/Bezeichner einer Variable zum Speichern der Ticket ID

    z. B. myTicketVariable

Debug

Wenn aktiviert, werden die Ticket- und Artikeldaten nach Platzhalterersetzung geloggt (Menü System > Logs)

Anhangsobjekt 1 bis 5

Optional: Angabe eines Anhang-Objektes mit den Attributen Filename, ContentType und Content. Der binäre Inhalt muss base64-kodiert sein.

Es ist der Bezeichner der Ergebnisvariable anzugeben. Z. B.: ${varReportAttachment}

Anhang-Objekte können mit der Macro Action Objekt zusammenstellen oder Konvertieren zu PDFerstellt werden.

Anwendungsbeispiel: Berichte automatisiert erstellen

Article Dynamic Fields

Setzen von Dynamischen Feldern am Artikel

  • Name: Name des Dynamischen Feldes, welches am Artikel gesetzt werden soll.

    Achten Sie darauf, dass es sich um ein Dynamisches Feld mit Objekttyp "Artikel" handelt!

  • Wert: Wert der in das Dynamische Feld gesetzt werden soll

Ticket Dynamic Fields

Setzen von Dynamischen Feldern am Ticket

  • Name: Name des Dynamischen Feldes, welches am Ticket gesetzt werden soll.

    Achten Sie darauf, dass es sich um ein Dynamisches Feld mit Objekttyp "Ticket" handelt!

  • Wert: Wert der in das Dynamische Feld gesetzt werden soll

Hinweise:

  • Falls nichts gesetzt wird, gelten folgende Standardwerte:

    • Sperrstatus: "unlock"

    • Bearbeiter: der aktuelle Nutzer wird gesetzt

    • Verantwortlicher: root (ID: 1)

    • Kunde:

      • wenn Kontakt gefunden: dessen Organisation

      • kein Kontakt gefunden: Kontakt als unbekannter Kontakt

    • Type: Wert aus SysConfig-Schlüssel "Ticket::Type::Default"

  • Soll in den Artikeltext ein mehrzeiliger Text (DF Typ "TextArea") via KIX-Platzhalter eingefügt werden, so müssen Sie das Suffix _HTML verwenden, um Zeilenumbrüche zu erhalten.

    Beispiel: <KIX_TICKET_DynamicField_WorkOrder_HTML>

  • Konfigurieren Sie Benachrichtigungen so, dass kein neuer Artikel anlegt wird. Sonst erscheint diese Benachrichtigung als erster Artikel.

Ticket löschen

Löscht Tickets.

Achtung

Die Aktion kann nicht rückgängig gemacht werden!

Es ist nicht möglich, spezifische Tickets zu löschen, da die Ticketnummer nicht als Filterkriterium zur Verfügung steht.

Diese Aktion beendet den Job. Nachfolgende, ticketbezogene Aktionen werden nicht ausgeführt (außer Ticket erstellen).

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Tickets zusammenfassen

Fasst 2 Tickets zusammen, bspw. um eine fehlgeleitete E-Mail (Quelle) an ein Ticket (Ziel) anzuhängen. 

Wird auch vom initial ausgelieferten Job "TicketMerge" in Verbindung mit der Ticketaktion "Zusammenfassen" verwendet.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Zielticket

Die Ticketnummer des Zieltickets oder der Name des dynamischen Feldes, welche die ID des Zieltickets enthält.

Ticketattribut

Kommaseparierte Liste von Ticketattributen.

Die Liste enthält die Attribute des Ausgangstickets, welche ans Zielticket geschrieben werden.

Übersetzungen der Attributs-Namen sind nicht möglich.

Dynamische Felder

Kommaseparierte Liste der Namen der dynamischen Felder, die ans Zielticket übernommen werden.

Übersetzungen der Namen sind nicht möglich.

Werte für Dynamische Felder erzeugen

  • Wenn aktiviert: Es werden die Werte der aufgeführten Dynamischen Felder im Zielticket mit den Werten des Quelltickets überschrieben.

  • Wenn nicht aktiviert: Der Wert eines dynamischen Feldes des Quelltickets wird am Zielticket nur gesetzt, wenn ein solcher Wert dort noch nicht vorhanden ist.

Titel setzen

Setzt den Titel an einem Ticket.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, wird der abgerufene SystemData-Wert geloggt (Menü System > Logs)

Titel

Der Text des zu setzenden Titels.

KIX Platzhalter sind möglich. Es können jedoch keine Platzhalter für Dynamische Felder der Typen "Checklist" und "Dropdown" verwendet werden.

Typ setzen

Setzt den Tickettyp an einem Ticket.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Typ

Exakte Bezeichnung des zu setzenden Typs, z. B. "Vorfall".

Variable setzen

Deklariert eine Variable zur flexiblen Verwendung in nachfolgenden Actions.

Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket

Parameter

Beschreibung

Variable

Individueller Bezeichner der Variable

Die Variable dient als Ergebnisvariable. Sie kann folgende Werte aufnehmen:

  • den unter Wert gesetzten Wert

  • den Wert, der ihr bei Verwendung zugewiesen wird

    , z. B. in Berechnungen (Macro Action Berechnen)

Debug

Wenn aktiviert, wird der zu setzende Wert der Variable nach Platzhalterersetzung geloggt (Menü System > Logs)

Wert

Wert mit dem die Variable vordefiniert sein soll oder Variablenbezeichner/Platzhalter für den zu setzenden Wert.

Verantwortlichen setzen

Setzt den Verantwortlichen an einem Ticket.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Verantwortlicher

ID oder Login-Name des Verantwortlichen

KIX Platzhalter sind möglich

Es findet keine Prüfung statt, ob der gewählte Agent berechtigt ist, das Ticket zu bearbeiten.

Vorfallstatus für betroffenes Asset setzen

Setzt den Vorfallstatus an Assets.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Asset

Nummer des Assets, dessen Vorfallstatus geändert werden soll.

Mehrere Assets können durch Komma getrennt angegeben werden. KIX Platzhalter sind möglich.

AssetID

Nummer des Assets, dessen Vorfallstatus geändert werden soll.

Mehrere Assets können durch Komma getrennt angegeben werden. KIX Platzhalter sind möglich.

Vorfallstatus

Name des zu setzenden Vorfallstatus, z. B. Incident

Anzugeben ist der exakte Name, so wie er im General Catalog definiert ist.

Übersetzungen sind nicht möglich.

Warten

Pausiert die Ausführung des Jobs für die angegebene Zeit.

Kann bspw. verwendet werden, wenn der Request für ein Webhook oder WebhookExtended eine längere Zeit zum Verarbeiten benötigt und erst nach einer Wartezeit ein weiterer Request gesendet wird.

Verwendung/Jobtyp: Asset, Kontakt, Report, Synchronisation, Ticket

Geben Sie im Parameter Warten|Wait an, wie lange die Ausführung des Jobs pausieren soll (Angaben in Sekunden).

Der Job wartet die angegebene Anzahl an Sekunden, bevor er mit der Ausführung der nachfolgenden Macro Actions fortfährt.

Wenn die Debug-Option aktiviert ist, werden Debug-Informationen zur Macro Action im KIX-Log ausgegeben (Menü System > Logs)

Webhook

Kommunikation mit anderen Systemen. Sendet eine vordefinierte Ereignismeldung an ein externes System (ERP, Server etc.)

Zum Beispiel: Senden der Ticketnummer und der Summe der gebuchten Aufwände an ein ERP-System.

Verwendung/Jobtyp: Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, werden Request und Response geloggt (Menü System > Logs)

URL

Zeichenkette (Endpunkt-URL für einen API-Aufruf)

Methode

Übertragungsmetode (Protokoll)

Es wird ein asynchroner GET/POST-Request gesendet.

  • GET: Wandelt die Key-Value-Paare in URL-Parameter um und ergänzt diese an der benannten URL.

    Die Abtrennung erfolgt mit ?, oder mit Semikolon, wenn URL ein ? einhaltet.

  • POST: Sendet die Key-Value-Paare als JSONRequest (encodiert)

Header

Request Header

Die angegebenen Werte werden als HTTP-Header verwendet.

Pro Zeile ist 1 Header als Key-Value-Paar anzugeben.

Daten

Request Data

Daten, die der Request übertragen soll.

Pro Zeile ist ein Key-Value-Paar anzugeben.

Es können Platzhalter verwendet werden.

macroaction_webhook.png

Hinweise

  • Steht für Ticket- und Artikel-Aktionen zur Verfügung.

  • Es werden die grundlegenden SysConfig- Einstellungen (Proxy, Timeout, etc.) von WebUserAgent als Grundlage genommen.

  • Es findet keine Ergebnisverarbeitung statt ("fire & forget").

  • Es können keine Strukturen und Wert-Mappings definiert werden.

  • Es können keine Anhänge versendet werden.

  • Veränderung an KIX-Objekten sind nicht möglich.

  • Der Response-Status wird in der Tickethistorie dokumentiert ("Webhook called - response xxx received")

While

Wiederholt die Ausführung des Macros solange eine konfigurierte Bedingung erfüllt ist. 

Zum Beispiel: Ein Webhook-Request liefert, dass weitere Daten abgerufen werden können (Paging bei APIs). Der Job soll weitere Requests auslösen, bis alle Daten abgerufen und verarbeitet wurden. 

Verwendung/Jobtyp: Asset, Kontakt, Report, Synchronisation, Ticket

Parameter

Beschreibung

Debug

Wenn aktiviert, wird der auszuwertende Ausdruck nach Platzhalterersetzung in jedem Schleifendurchlauf geloggt (Menü System > Logs)

While

Geben Sie die Bedingung an, die erfüllt sein muss, damit die unter Macro angegebene Macro Action ausgeführt wird.

Die Macro Action wird solange ausgeführt, wie die hier angegebene Bedingung zutrifft

Macro

Konfigurieren Sie hier die Macro Action, die ausgeführt werden soll.

Wählen Sie den Objekttyp und die auszuführenden Aktionen und konfigurieren Sie diese nach Bedarf

Maximale Ausführung

Zur Vermeidung von Dauerschleifen können Sie die maximale Anzahl an Durchläufen angeben.

Ist keine Anzahl angegeben, wird nach 1000 Durchläufen abgebrochen.

Zeit buchen

Setzt einen Wert als Zeitbuchung in ein Ticket.

Verwendung/Jobtyp: Ticket

Folgende Angaben sind im Parameter Zeit buchen möglich:

  • Zeit in Minuten

    oder:

  • KIX-Platzhalter

    z. B.: <KIX_TICKET_DynamicField_someDynamicFieldName>

    Durch Angabe eines Platzhalters können Sie bspw. den in einem Dynamischen Feld gesetzten Wert als Zeitbuchung setzen.

    oder:

  • Bezeichner einer Ergebnisvariable

    z. B.: ${ErgebnisDerBerechnung}

    Durch Angabe einer Ergebnisvariable kann der Wert einer zuvor durchgeführten Berechnung als Zeitbuchung gesetzt werden.

macroaction_zeit-buchen_berechnen.png

Wenn die Debug-Option aktiviert ist, werden die zu buchenden Zeiteinheiten nach Platzhalterersetzung geloggt (Menü System > Logs)

Zufallszeichenfolge erstellen

Erstellt einen zufällig generierten String, welcher beispielsweise als Passwort für das Nutzer-Login genutzt werden kann.

Sie können im Anschluss die Macro Action Set password for user verwenden, um den String als Passwort für einen Nutzer zu setzen.

Parameter

Beschreibung

RandomString

Individueller Bezeichner der Ergebnisvariable. In dieser wird der erstellte Zufalls-String gespeichert.

Debug

Wenn aktiviert, werden das bereitgestellte Dictionary und der erstellte Zufallsstring geloggt (Menü System > Logs)

Überspringen

Wenn aktiviert: Überspringt die Ausführung der Aktion

Länge

Länge der Zeichenkette (Zeichenanzahl)

Dictionary

Liste der Zeichen, die zur Erzeugung der Zeichenkette verwendet werden.

Falls leer, wird der Standardwert verwendet.

Standard: ( 0 .. 9, 'A' .. 'Z', 'a' .. 'z' )

In diesem Abschnitt: