Konfiguration von Prozessaktionen

An Datensätzen im Monitor können Aktionen angeboten werden, die der Anwender auf bestehende Prozesse auslösen kann. Eine Aktion ruft in der Regel ein Backend System wie z. B. die INUBIT Process Engine auf und veranlasst dort die Verarbeitung der Aktion. So können z. B. Daten verändert oder Fachprozesse angestoßen werden.

Verfügbare Prozessaktionen werden über entsprechende Eintragungen an den Datensätzen hinterlegt und dann in der Oberfläche angeboten.

Toolbar Funktion
Verfügbare Aktionen werden in der Toolbar über Funktions-Icons angeboten.
Kontextmenü
Über das Kontextmenü (Rechtsklick auf einen Datensatz) werden die verfügbaren Aktionen angeboten.
Aktions-Spalte
Wird eine Aktions-Spalte konfiguriert, so wird in der Zeile des Datensatzes eine Schaltfläche mit Zugriff auf die Aktion(en) angeboten, siehe Aktionsspalte.
Detailansicht
Siehe Prozessaktionen in der Monitor-Detailansicht.

Die Anwender-Dokumentation zu dieser Funktion finden Sie hier.

Zugriffsrechte

Damit ein Benutzer Prozessaktionen nutzen kann, benötigt er das Recht bpcMonitor_processAction.

Sollte das System, dass die Prozess-Aktion verarbeitet, über eine Backend Connection angesprochen werden, so wird für alle Nutzer der Funktion das Recht loadModule_backendconnection benötigt.

Aktionen über Datensätze bereitstellen

Um Aktionen anzubieten, müssen die Daten ein Feld mit dem Präfix ACTION_ bereitstellen. Dazu wird in der Regel eine neue Spalte in der zugrundeliegenden Datenbank angelegt.

Es können mehrere Felder mit dem Präfix verwendet werden, um mehr Aktionen anzubieten. Zudem können mehrere Aktionen über ein Feld bereitgestellt werden.

In den folgenden Abschnitten wird beschrieben, wie der Inhalt der Felder interpretiert wird.

Einzelne Aktion

Ein einfacher Text-Wert (ohne Separator, siehe Aktionsliste) wird direkt als Aktion angeboten. Dabei bildet der Wert sowohl die ID der Aktion als auch die Beschriftung an der Oberfläche.

Beispiel: Freigeben

Aktionsliste

Text-Wert, der Separatoren (normalerweise Komma ",") enthält. Dabei wird der Text am Separator getrennt und für jeden Teil eine Aktion angeboten. Dabei bestehen die ID und Beschriftung aus dem jeweils separierten Textteil.

Beispiel: "ACTION_Mehrere" : "Freigeben,Ablehnen,Löschen"

Detaillierte Aktionskonfiguration

Es ist auch möglich, einen JSON-String zu speichern. Dieser kann eine oder mehrere Aktionen enthalten.
Dabei können folgende Attribute bestimmt werden:

id
(string)
ID
name
(string)
Beschriftung
Mindestens eines der Attribute name oder id muss gesetzt sein.
label
(string, languageKey, object)
Beschriftung, überschreibt name
Wenn weder label noch name gesetzt sind, wird keine Beschriftung angezeigt. Es kann ein Language Key oder ein Objekt mit Lokalisierungen verwendet werden.
tooltip
(string, languageKey, object)
Ergänzende Information beim Mouse-Over der Beschriftung
Es kann ein Language Key oder ein Objekt mit Lokalisierungen verwendet werden.
iconCls
(string)
Icon (Font Awesome Icons - siehe FontAwesome-Bibliothek)
sortValue
(number)
Reihenfolge (sollte numerisch sein).
(Default ist 1; es wird erst nach sortValue absteigend und dann nach name aufsteigend sortiert)
requireConfirmation
Bestätigung ist erforderlich, bevor ein Nutzer die Aktion ausführt.
requireComment
(boolean)
Kommentar ist erforderlich, bevor ein Nutzer die Aktion ausführt.
confirmationText
(string, languageKey)
Bestätigungstext für die Confirmation Box (requireConfirmation muss auf true stehen). Hier kann auch ein Language Key verwendet werden. Wenn nicht konfiguriert, wird der Text wie oben als Default gesetzt.
role
(array)
Beschränken der Anzeige je nach Rolle des Anwenders.

Das ist nur eine Einschränkung der Sichtbarkeit. Das Backend-System muss die Rollen/Rechte des Benutzers beim Aufruf selbst prüfen.
right
(array)
Beschränken der Anzeige je nach Recht des Anwenders.

Das ist nur eine Einschränkung der Sichtbarkeit. Das Backend-System muss die Rollen/Rechte des Benutzers beim Aufruf selbst prüfen.
organisation
(array)
Beschränken der Anzeige je nach Organisation/Gruppe des Anwenders.

Das ist nur eine Einschränkung der Sichtbarkeit. Das Backend-System muss die Rollen/Rechte des Benutzers beim Aufruf selbst prüfen.
target
(string)
Dieser Parameter gibt an, welches Ziel die Aktion hat. Mögliche Optionen sind:
- processStarter - Prozess Starter über eine Aktion aufrufen
- forms - Forms über eine Aktion ansteuern
params
(object)
Über dieses Attribut kann ein Objekt mit zusätzlichen Parametern bereitgestellt werden. Wird z. B. für Prozess Starter über eine Aktion aufrufen verwendet.

Beispiel

[
    {
        "id": "Annehmen",
        "name": "Qualitätsprüfung erfolgreich",
        "iconCls": "fas fa-award",
        "sortValue": 1,
        "requireComment": true
    }
]

Beispiel

[
    {
        "id": "Ablehnen",
        "name": "Fehler melden/Ablehnen",
        "iconCls": "fas fa-times-circle",
        "sortValue": 2,
        "role": ["bpcadmin"]
    }
]

Weitere benutzerdefinierte Attribute sind zulässig, tragen aber nicht zur Aktionskonfiguration bei.

Prozess Starter über eine Aktion aufrufen

Über eine Aktion lässt sich auch der Prozess Starter für einen bestimmten Prozess aufrufen. Die Konfiguration dieser Prozessaktion erfolgt über ein JSON-Objekt (siehe Detaillierte Aktionskonfiguration).

Dabei wird als target der Wert processStarter gesetzt. Über params kann der key Zielprozess im Attribut process angegeben werden.

Beispiel

[
    {
        "id": "start-process",
        "name": "Prozessstarter",
        "iconCls": "x-fal fa-play",
        "target":"processStarter",
        "params":{
            "process":"testProcess"
        }
    }
]

Auf diesem Weg können auch Prozess Starter für Prozesse aufgerufen werden, die durch die Angabe von hidden: true ausgeblendet sind.

Forms über eine Aktion ansteuern

Zudem können Aktionen genutzt werden um Forms anzusteuern. Die Konfiguration erfolgt über ein JSON-Objekt (siehe Detaillierte Aktionskonfiguration).

Als target wird der Wert forms gesetzt. Per Default wird für das erste gefundene Formular der Submit ausgelöst.

Nur sichtbare Formulare können angesteuert werden. Der Einsatz dieser Funktion bietet sich daher in der Monitor Detailansicht an, wo Prozessaktionen und Forms parallel angezeigt werden können.

Formularauswahl per Selektor

Über einen Selektor kann sichergestellt werden, dass der Submit bei dem richtigen Formular ausgelöst wird. Der Selektor wird unter params über das Attribut selector gesetzt.

Beispiel - mit einem Selektor für das Forms mit der ID FORMS-KOMPONENTEN-ID

[
  {
  "id": "start-process",
  "name": "Prozessstarter",
  "iconCls": "x-fal fa-play",
  "target":"forms",
  "params":{
    "selector":"moduleId=FORMS-KOMPONENTEN-ID"
    }
  }
]

Erweiterte Aufrufe

Um statt eines Submits andere Aktionen aufzurufen, kann eine Aktion über action innerhalb von params angegeben werden. Über payload können weitere Einstellungen für die Aktion übergeben werden. Dadurch lassen sich z. B. benutzerdefinierte Submits mit spezifischen Payload-Einstellungen (content, metaData oder abweichende url) auslösen.

Beispiel – Custom Submit mit selektiver Content-Payload

[
  {
    "id": "start-process",
    "name": "Trigger custom submit",
    "iconCls": "x-fal fa-fire",
    "target": "forms",
    "params": {
      "action": "submit",
      "payload": {
        "content": {
          "records": "${/records}",
          "data": "${/data}"
        }
      }
    }
  }
]

Prozessaktionen in der Monitor-Detailansicht

In der Detailansicht vom Monitor können ebenfalls Prozessaktionen ausgelöst werden. Siehe dafür Konfiguration der Monitor-Detailansicht.

Aktionsspalte

Um eine Spalte im Monitor anzuzeigen, die direkten Zugriff auf die verfügbaren Aktionen bietet, muss in der Monitor_ColumnConfig eine Spalte vom Typ gridActionColumn hinzugefügt werden. Über den Parameter showIconOnly kann gesteuert werden, ob an der Schaltfläche nur die Icons dargestellt werden sollen.

Diese Aktionsspalte kann analog zum Monitor auch im Historien-Grid verwendet werden.

Beispiel - Aktionsspalte in Monitor_Column_Config

{
    "xtype": "gridActionColumn",
    "localized": {
        "text": "Aktionen"
    },
    "showIconOnly": true
}

Erwartetes Rückgabe-Format

Der Client erwartet vom Server eine JSON-Antwort.

Stelle sicher, dass der Content-Type-Header entsprechend gesetzt wird, um dem Client das Datenformat korrekt zu übermitteln:

JSON-Antworten benötigen Content-Type: application/json.

Antwort auf Absenden des Prozesses

Beispiel Fehler

{
    "success": false,
    "msg": "Fehlermeldung"
}

Beispiel OK

{
    "success": true,
    "msg": "Aktion vom Prozess 4711 erfolreich"
}

Beispiel Dateidownload

{
    "success": true,
    "msg": "Alles toll. Siehe Datei!",
    "download": {
        "data": "UHJvemVzc2FrdGlvbiBEb3dubG9hZCE",
        "fileName": "processAction.txt",
        "contentType": "text/plain"
    }
}

OpenAPI Spezifikation

Eine detaillierte Beschreibung aller Endpunkte finden Sie in unserer OpenAPI Spezifikation.

Keywords: