Multiple Actions

A multiple action allows you to execute an action on all records in a monitor view. When executed, the action takes into account the monitor’s current filtered view, so that the action transmits a list of all IDs to the backend (INUBIT, IGUASU, etc.).

Access Rights

For a user to use multiple actions, they need the right bpcMonitor_bulkAction.

If the system processing the action is accessed via a backend Connection, all users of the function require the right loadModule_backendconnection.

General Settings

The following settings are configured for each monitor:

function_bulkActions
(boolean; default: false)
Shows or hides the configured multiple actions in the monitor toolbar.
function_bulkActionConfig
(json; default: [])
Configuration of the multiple actions. See Configuration.
Certain values (marked with languageKey ) can be specified either with an existing LanguageKey (e.g., "CORE_DESCRIPTION") or as objects with language-specific translations (e.g., { "de": "Beschreibung", "en": "Description" }).
bulkActionEndpointProcessor
(string; default: "")
Selection of the REST endpoint (Backend Connection) or processor (Flow) for executing a multiple action. Can be overridden per action.
function_bulkActionAllowParallel
(boolean; default: false)
Enables or disables the user’s ability to trigger multiple actions at once.
function_bulkActionMetadata
(json; default: null)
Any JSON object that is passed along with the action to provide additional configuration values or context information. Can be overridden per action.

Configuration

This section describes the options for configuring multiple actions.

Syntax

id
(string)
Keyword/ID of the action.
Label
(string, languageKey)
Display name of the action.
tooltip
(string, languageKey)
Additional information displayed when hovering over the display name.
iconCls
(string, optional)
Icon for the action.
Default: "x-fal fa-layer-group".
sortValue
(number, optional)
Order of the actions in the menu. It is first sorted in descending order by sortValue and then in ascending order by label.
Default: 1
requireConfirmation
(boolean, optional)
Confirmation is required before a user performs the action.
Default: true
requireComment
(boolean, optional)
A comment is required before a user performs the action.
confirmationText
(string, optional, languageKey)
Confirmation text for the confirmation box (requireConfirmation must be set to true).
notificationDisplayMode (string, optional)
Can be "toast," "popup," or "silent," thereby overriding Function_ProcessNotificationDisplayMode for this action.
right
(array, optional)
See Restriction Based on User Permissions.
role
(array, optional)
See Restriction Based on User Permissions.
organisation
(array, optional)
See Restriction Based on User Permissions.
metadata
(json, optional)
Any JSON object that is transmitted along with the action to provide additional configuration values or context information.
Overrides function_bulkActionMetadata.
dataLimit
(number, optional)
Maximum number of record IDs sent to the backend for batch processing.
Default: 10000
url
(string, optional)
The BPC URL that specifies the endpoint (backend connection) or processor (flow) for processing the action. Schema: bpc://<flow/backendconnection>/<instanceId>/<EndpointOrProcessor>
Overrides bulkActionEndpointProcessor

Restriction Based on User Permissions

It is possible to restrict the visibility of processes or individual process fields based on organizations, roles, or permissions via the configuration.

To do this, you can add the following attributes to the object:

role
right
organization

If none of the attributes are specified, no access restriction applies. For each attribute, an array of strings can be specified.

Example - In this case, the user must have the right r1 or r2.

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

This is only a visibility restriction. The backend system must check the user’s roles and permissions itself when the request is made.

Example

{
  "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"
}

Expected response format

The client expects a JSON response from the server.

Make sure the ` Content-Type` header is set appropriately to correctly convey the data format to the client:

JSON responses require Content-Type: application/json.

Response to submitting the process

Example error

{
    "success": "false",
    "message": "Fehlermeldung",
    "data": {
        "any": "thing"
    }
}

Example OK

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

Case study for a multi-action with IGUASU

In this example, a Process Monitor was created to track all tickets in a JIRA project. If updates are made to the tickets, they are refreshed in the monitor hourly. The parent data contains, for example, information about the ticket ID, title, description, assignee, and ticket status. The child data contains information about when a ticket was created and updated.
The multiple action is intended to perform a manual update of the JIRA tickets for the monitor’s current view, outside of the hourly cycle.

Prerequisites

An Integrating IGUASU with BPC

Configuration in IGUASU

Create a ListenBPCFlowStarter processor
- Listener Identifier: "fetchUpdates"
- BPC Listener Controller: "HybridRESTServerController" (see IGUASU documentation)
- Name: "Fetch Ticket Updates"
- Description: "Fetch JIRA ticket updates and refresh Process Monitoring data"

Configuration in Process Monitoring

"Multiple Actions" settings group:

Enable Multiple Actions: “Active” (function_bulkActions)
Select Processor: “Endpoint or Processor” (bulkActionEndpointProcessor)
Configure Multiple Action: “Actions” (function_bulkActionConfig):

Multiple Action Configuration

[
    {
        "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

The ListenBPCFlowStarter processor receives the data from the action. The FlowFile content is a JSON object and contains information about the multi-action configuration and the 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
}

To retrieve the current status of the JIRA tickets, the ticket IDs from the key field in the monitor are required. The ticket IDs can be retrieved from the Log Service using the FetchBPCProcessLog processor. Configure

EvaluateJsonPath
Add a dynamic property to extract the processIds into a FlowFile attribute. + Configure processIds: $.processIds
FetchBPCProcessLog
- 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 Configure
FetchBPCProcessLog returns all data from the Log Service. Since only the ticket IDs (key) are relevant for constructing a query to retrieve the JIRA tickets, only the ticket IDs are stored in an attribute.
ticketIds: $.entries[*].parent.key
The following steps are specific to each multi-action and, as summarized in this example at .., involve retrieving the current ticket data using the InvokeHTTP processor via the JIRA API, where the query filters by ticketIds,
1. the transformation of the response data into the schema expected by the Log Service using the JSONataTransformJSON processor
2. and the writing of the data using the PutBPCProcessLog processor to update the monitor data
Finally, the multi-action receives a response via the ListenBPCRespnder processor. + Configure ReplaceText:
- Replacement Strategy: Always Replace
- Replacement Value:

Configure Replacement Value

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

ListenBPCResponder:

BPC Listener Controller: HybridRESTServerController
HTTP Status Code: 200
Add a dynamic property:
Content-Type: application/json

OpenAPI Specification

A detailed description of all endpoints can be found in our OpenAPI specification.

Keywords: