Mehrfach-Aktionen

Mit einer Mehrfach-Aktion kann eine Aktion für alle Datensätze einer Monitoransicht ausgeführt werden. Bei der Ausführung wird die aktuelle gefilterte Ansicht des Monitors berücksichtigt, sodass mit der Aktion eine Liste aller IDs an das Backend (INUBIT, IGUASU etc.) übertragen wird.

Zugriffsrechte

Damit ein Benutzer Mehrfach-Aktionen nutzen kann, benötigt er das Recht bpcMonitor_bulkAction.

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

Allgemeine Einstellung

Folgende Einstellungen werden je Monitor vorgenommen:

function_bulkActions
(boolean; default: false)
Zeigt oder versteckt die konfigurierten Mehrfach-Aktionen in der Monitor-Toolbar.
function_bulkActionConfig
(json; default: [])
Konfiguration der Mehrfach-Aktionen. Siehe Konfiguration.
Bestimmte Werte (mit languageKey gekennzeichnet) können sowohl mit einem vorhandenen LanguageKey (z.B. "CORE_DESCRIPTION") als auch als Objekte mit sprachspezifischen Übersetzungen (z.B. { "de": "Beschreibung", "en": "Description" }) angegeben werden.
bulkActionEndpointProcessor
(string; default: "")
Auswahl des REST-Endpunktes (Backend Connection) oder Prozessors (Flow) zur Ausführung einer Mehrfach-Aktion. Kann pro Aktion überschrieben werden.
function_bulkActionAllowParallel
(boolean; default: false)
Aktiviert oder deaktiviert, dass der Benutzer mehrere Aktionen auf einmal anstoßen kann.
function_bulkActionMetadata
(json; default: null)
Ein beliebiges JSON-Objekt, das zusammen mit der Aktion übertragen wird, um zusätzliche Konfigurationswerte oder Kontextinformationen zu ergänzen. Kann pro Aktion überschrieben werden.

Konfiguration

Dieser Abschnitt beschreibt die Möglichkeiten, wie die Mehrfach-Aktionen konfiguriert werden können.

Syntax

id
(string)
Schlüsselwort/ID der Aktion.
label
(string, languageKey)
Anzeigename der Aktion.
tooltip
(string, languageKey)
Ergänzende Information beim Mouse-Over des Anzeigenamens.
iconCls
(string, optional)
Icon für die Aktion.
Default: "x-fal fa-layer-group".
sortValue
(number, optional)
Reihenfolge der Aktionen im Menü. Es wird erst nach sortValue absteigend und dann nach label aufsteigend sortiert.
Default: 1
requireConfirmation
(boolean, optional)
Bestätigung ist erforderlich, bevor ein Nutzer die Aktion ausführt.
Default: true
requireComment
(boolean, optional)
Kommentar ist erforderlich, bevor ein Nutzer die Aktion ausführt.
confirmationText
(string, optional, languageKey)
Bestätigungstext für die Confirmation Box (requireConfirmation muss auf true stehen).
notificationDisplayMode (string, optional)
Kann "toast", "popup" oder "silent" sein und überschreibt damit Function_ProcessNotificationDisplayMode für diese Aktion.
right
(array, optional)
Siehe Einschränkung anhand Benutzerrechte.
role
(array, optional)
Siehe Einschränkung anhand Benutzerrechte.
organisation
(array, optional)
Siehe Einschränkung anhand Benutzerrechte.
metadata
(json, optional)
Ein beliebiges JSON-Objekt, das zusammen mit der Aktion übertragen wird, um zusätzliche Konfigurationswerte oder Kontextinformationen zu ergänzen.
Überschreibt function_bulkActionMetadata.
dataLimit
(number, optional)
Maximale Anzahl der IDs von Datensätzen, die zur Mehrfach-Verarbeitung an das Backend gesendet werden.
Default: 10000
url
(string, optional)
Die BPC-Url, die den Endpunkt (Backend Connection) oder Prozessor (Flow) für die Verarbeitung der Aktion angibt. Schema: bpc://<flow/backendconnection>/<instanceId>/<EndpointOrProcessor>
Überschreibt bulkActionEndpointProcessor

Einschränkung anhand Benutzerrechte

Es ist möglich, über die Konfiguration die Sichtbarkeit von Prozessen oder einzelnen Prozessfeldern anhand von Organisationen, Rollen oder Rechten einzuschränken.

Dafür kann man am Object folgende Attribute hinzufügen:

role
right
organisation

Ist keines der Attribute angegeben, so gilt kein Zugriffsschutz. Für jedes Attribut kann ein Array von String angegeben werden.

Beispiel - In diesem Fall muss der Benutzer das Recht r1 oder r2 haben.

{
  "right": ["r1","r2"]
}

Das ist nur eine Einschränkung der Sichtbarkeit. Das Backend-System muss die Rollen/Rechte des Benutzers beim Aufruf selbst prüfen.

Beispiel

{
  "id": "archiveRecords",
  "label": "Archive Records",
  "tooltip": "Archive all records",
  "iconCls": "x-fal fa-archive",
  "sortValue": 1,
  "requireConfirmation": true,
  "requireComment": false,
  "confirmationText": "CONFIRMATION_TEXT_LANGUAGE_KEY_EXAMPLE",
  "notificationDisplayMode": "toast",
  "right": ["CAN_ARCHIVE"],
  "role": ["admin", "editor"],
  "organisation": ["ORG1", "ORG2"],
  "metadata": {
    "archiveType": "soft",
    "logAction": true
  },
  "dataLimit": 5000,
  "url": "bpc://flow/archiveHandler/ArchiveRecords"
}

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",
    "message": "Fehlermeldung",
    "data": {
        "any": "thing"
    }
}

Beispiel OK

{
    "success": "true",
    "message": "Prozess 4711 gestartet",
    "data": {
        "any": "thing"
    }
}

Fallbeispiel für eine Mehrfach-Aktion mit IGUASU

In diesem Beispiel wurde ein Process Monitor erstellt, in dem alle Tickets eines JIRA-Projekts abgebildet werden. Falls an den Tickets Aktualisierungen durchgeführt werden, werden sie im Monitor stündlich aktualisiert. Die Parent-Daten enthalten zum Beispiel Informationen über die Ticket-ID, Titel, Beschreibung, Zugewiesene Person und den Ticketstatus. Die Child-Daten enthalten die Informationen darüber, wann ein Ticket erstellt und aktualisiert wurde.
Die Mehrfach-Aktion soll eine manuelle Aktualisierung der JIRA Tickets für die aktuelle Ansicht des Monitors durchführen, außerhalb des stündlichen Takts.

Voraussetzungen

Eine Anbindung von IGUASU ans BPC

Konfiguration in IGUASU

Einen ListenBPCFlowStarter Prozessor erstellen
- Listener Identifier: "fetchUpdates"
- BPC Listener Controller: "HybridRESTServerController" (siehe IGUASU-Dokumentation)
- Name: "Fetch Ticket Updates"
- Description: "Fetch JIRA ticket updates and refresh Process Monitoring data"

Konfiguration im Process Monitoring

Einstellungsgruppe "Mehrfach-Aktionen":

Mehrfach-Aktionen aktivieren: "Aktiv" (function_bulkActions)
Prozessor auswählen: "Endpunkt oder Prozessor" (bulkActionEndpointProcessor)
Mehrfach-Aktion konfigurieren: "Aktionen" (function_bulkActionConfig):

Mehrfach-Aktion Konfiguration

[
    {
        "sortValue": 1,
        "dataLimit": 10000,
        "tooltip": "Manuelle Aktualisierung der Ticket-Informationen",
        "requireConfirmation": true,
        "id": "fetchUpdates",
        "label": {
            "de": "Updates abrufen",
            "en": "Fetch Updates"
        },
        "iconCls": "x-fal fa-sync"
    }
]

Flow in IGUASU

Der ListenBPCFlowStarter Prozessor erhält die Daten von der Aktion. Der FlowFile Content ist ein JSON-Objekt und enthält Informationen über die Konfiguration der Mehrfach-Aktion und die processIds.

FlowFile Content

{
  "processIds": [
    "1231",
    "1232",
    "1233",
    ...
  ],
  "timezoneName": "Europe/Berlin",
  "view": "allView",
  "dataLimit": 10000,
  "filter": "[{\"operator\":\"gte\",\"invert\":false,\"id\":\"x-gridfilter-created-start\",\"property\":\"created\",\"serializer\":null,\"columnId\":\"created\",\"key\":\"start\",\"value\":\"now/w\"},{\"operator\":\"lt\",\"invert\":false,\"id\":\"x-gridfilter-created-end\",\"property\":\"created\",\"serializer\":null,\"columnId\":\"created\",\"key\":\"end\",\"value\":\"now+1w/w\"}]",
  "timezoneOffset": "+02:00",
  "query": "",
  "type": "bulkAction",
  "instanceId": "jira-imports-monitor",
  "id": "fetchUpdates",
  "bpcUrl": "bpc://flow/iguasu/fetchUpdates",
  "config": {
    ...
  },
  "records": null,
  "metadata": null
}

Um den aktuellen Stand der JIRA Tickets zu bekommen, werden die Ticket IDs aus dem Feld key im Monitor benötigt. Die Ticket IDs können mit Hilfe des FetchBPCProcessLog Prozessors aus dem Log Service geholt werden.

EvaluateJsonPath konfigurieren
Dynamisches Property hinzufügen, um die processIds in ein FlowFile Attribut zu extrahieren.
processIds: $.processIds
FetchBPCProcessLog konfigurieren
- BPC Controller: HybridRESTClientController
- BPCLogger: jira-import
- Fetch Method: Parents by Query
- Complex Filter: [{"property":"parentId","operator":"in","value":${processIds},"source":"raw","invert":false}]
- Add Children: True
EvaluateJsonPath konfigurieren
FetchBPCProcessLog liefert die gesamten Daten aus dem Log Service zurück. Weil nur die Ticket IDs (key) relevant sind, um damit eine Query zur Abfrage der JIRA Tickets zusammenzubauen, werden nur die Ticket IDs in einem Attribut gespeichert.
ticketIds: $.entries[*].parent.key
Die folgenden Schritte sind für jede Mehrfach-Aktion individuell und beinhalten in diesem Beispiel zusammengefasst
1. die Abfrage der aktuellen Ticketdaten mit dem InvokeHTTP Prozessor über die JIRA API, wobei die Abfrage nach den ticketIds filtert,
2. die Transformation der Response Daten in das Schema, das vom Log Service erwartet wird mittels JSONataTransformJSON Prozessor
3. und das Schreiben der Daten mit dem PutBPCProcessLog Prozessor, um die Monitordaten zu aktualisieren
Zuletzt erhält die Mehrfach-Aktion eine Antwort durch den ListenBPCRespnder Prozessor.
ReplaceText konfigurieren:
- Replacemen Strategy: Always Replace
- Replacement Value:

Replacement Value

{
  "success": true,
  "msg": "Ticket Informationen wurden aktualisiert"
}

ListenBPCResponder konfigurieren:

BPC Listener Controller: HybridRESTServerController
HTTP Status Code: 200
Dynamisches Property hinzufügen:
Content-Type: application/json

OpenAPI Spezifikation

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

Keywords: