Multiple actions

With a multiple action, an action can be executed for all data records of a monitor view. During execution, the current filtered view of the monitor is taken into account so that a list of all IDs is transferred to the backend (INUBIT, IGUASU etc.) with the action.

Access rights

In order for a user to be able to use multiple actions, they require the right bpcMonitor_bulkAction.

If the system that processes the action is addressed via a Backend Connection, the loadModule_backendconnection right is required for all users of the function.

General setting

The following settings are made 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 both with an existing LanguageKey (e.g. "CORE_DESCRIPTION") and 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 overwritten per action.
function_bulkActionAllowParallel
(boolean; default: false)
Enables or disables the user to initiate multiple actions at once.
function_bulkActionMetadata
(json; default: null)
Any JSON object that is transmitted together with the action to add additional configuration values or context information. Can be overwritten per action.

Configuration

This section describes the options for configuring the multiple actions.

Syntax

id
(string)
Keyword/ID of the action.
label
(string, languageKey)
Display name of the action.
tooltip
(string, languageKey)
Additional information on mouse-over of the display name.
iconCls
(string, optional)
Icon for the action.
Default: "x-fal fa-layer-group".
sortValue
(number, optional)
Sequence of actions in the menu. It is first sorted by sortValue in descending order and then by label in ascending order.
Default: 1
requireConfirmation
(boolean, optional)
Confirmation is required before a user executes the action.
Default: true
requireComment
(boolean, optional)
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" and thus overwrites Function_ProcessNotificationDisplayMode for this action.
right
(array, optional)
See Restriction based on user rights.
role
(array, optional)
See Restriction based on user rights.
organization
(array, optional)
See Restriction based on user rights.
metadata
(json, optional)
Any JSON object that is transmitted with the action to add additional configuration values or context information.
Overwrites function_bulkActionMetadata.
dataLimit
(number, optional)
Maximum number of IDs of data records that are sent to the backend for multiple 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>
Overwrites bulkActionEndpointProcessor

Restriction based on user rights

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

The following attributes can be added to the object for this purpose:

role
right
organization

If none of the attributes are specified, no access protection applies. An array of strings can be specified for each attribute.

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

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

This is only a restriction of visibility. The backend system must check the roles/rights of the user itself when calling.

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 return format

The client expects a JSON response from the server.

Ensure that the Content-Type header is set accordingly in order to correctly transmit the data format to the client:

JSON responses require Content-Type: application/json.

Response to sending 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 multiple action with IGUASU

In this example, a process monitor was created in which all tickets of a JIRA project are mapped. If updates are made to the tickets, they are updated in the monitor every hour. The parent data contains, for example, information about the ticket ID, title, description, assigned person 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 current view of the monitor, outside of the hourly cycle.

Prerequisites

A Connection of IGUASU to the 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

Settings group "Multiple actions":

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 configuration of the multiple action 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 get 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.

EvaluateJsonPath configure
add dynamic property to extract the processIds into a FlowFile attribute.
processIds: $.processIds
FetchBPCProcessLog configure
- 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 the entire data from the Log Service. Because only the ticket IDs (key) are relevant for assembling a query to query the JIRA tickets, only the ticket IDs are saved in an attribute.
ticketIds: $.entries[*].parent.key
The following steps are individual for each multiple action and are summarized in this example
1. the query of the current ticket data with the InvokeHTTP processor via the JIRA API, whereby the query filters for the ticketIds,
2. the transformation of the response data into the schema expected by the Log Service using the JSONataTransformJSON processor
3. and the writing of the data with the PutBPCProcessLog processor to update the monitor data
Finally, the multiple action receives a response from the ListenBPCRespnder processor.
ReplaceText configure:
- Replacemen Strategy: Always Replace
- Replacement Value:

Replacement Value

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

ListenBPCResponder configure:

BPC Listener Controller: HybridRESTServerController
HTTP Status Code: 200
Add Dynamic Property:
Content-Type: application/json

OpenAPI Specification

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

Keywords: