Deletes specified key-value pairs from the incoming message data or its metadata.
Preconditions
If you’re deleting from the message data, it must be a valid JSON object. If the message data is not a JSON object, the node will pass the message through without modification.
Configuration
Field descriptions
- Delete key-values from — specifies where the deletion should happen. Can be either:
- Message — deletes key-value pairs from the message data.
- Metadata — deletes key-value pairs from the metadata.
- Keys — a set of keys to delete from the source. Java regular expressions are supported. If a configured key pattern does not match any key in the source, it is ignored.
JSON Schema
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "TbDeleteKeysNodeConfiguration",
"type": "object",
"properties": {
"deleteFrom": {
"type": "string",
"enum": [
"DATA",
"METADATA"
],
"description": "Where to delete key-value pairs from: message data or metadata."
},
"keys": {
"type": "array",
"items": {
"type": "string"
},
"description": "A set of keys to delete from the source. Java regular expressions are supported."
}
},
"required": [
"deleteFrom",
"keys"
],
"additionalProperties": false
}
Message processing algorithm
- The node checks the configured source for deletion (Message or Metadata).
- It iterates through all keys in the source.
- For each key, it checks if the key matches any of the patterns listed in the Keys configuration.
- All matching key-value pairs are removed from the source.
- If at least one key-value pair was deleted, a new message is created with the updated data or metadata and passed to the next node via
Success
. - If no keys matched or the source was empty, the original message is passed through unchanged via
Success
. - If an unexpected error occurs, the message is routed via
Failure
.
Output connections
Success
:- if processing completes without exceptions, even if no keys were deleted.
Failure
:- if an unexpected error occurs during processing.
Examples
The examples below show only the relevant parts of the incoming message, rule node configuration, and system state. Any information not explicitly shown has no effect on the processing.
Example 1 — Delete from data
Incoming message
Data:
1
2
3
4
5
6
{
"temperature": 25.4,
"humidity": 62,
"internal_id": "xyz-123",
"deviceName": "Sensor-A1"
}
Node configuration
1
2
3
4
5
6
7
{
"deleteFrom": "DATA",
"keys": [
"internal_id",
"deviceName"
]
}
Outgoing message
Data:
1
2
3
4
{
"temperature": 25.4,
"humidity": 62
}
Output connections: Success
.
Explanation: The key-value pairs for internal_id
and deviceName
are deleted from the message data.
Example 2 — Delete from metadata
Incoming message
Metadata:
1
2
3
4
5
6
{
"deviceType": "Thermostat",
"location": "Floor 1",
"rssi": "-56",
"snr": "12.1"
}
Node configuration
1
2
3
4
5
6
7
{
"deleteFrom": "METADATA",
"keys": [
"rssi",
"snr"
]
}
Outgoing message
Metadata:
1
2
3
4
{
"deviceType": "Thermostat",
"location": "Floor 1"
}
Output connections: Success
.
Explanation: The key-value pairs for rssi
and snr
are deleted from the metadata.
Example 3 — Using Java regular expressions
Incoming message
Data:
1
2
3
4
5
6
{
"temp_main": 33.1,
"humidity": 45,
"pressure": 1012,
"temp_ambient": 21.5
}
Node configuration
1
2
3
4
5
6
{
"deleteFrom": "DATA",
"keys": [
"temp_.*"
]
}
Outgoing message
Data:
1
2
3
4
{
"humidity": 45,
"pressure": 1012
}
Output connections: Success
.
Explanation: The regular expression temp_.*
matches temp_main
and temp_ambient
. These key-value pairs are deleted from the message data.
Example 4 — No matching keys
Incoming message
Data:
1
2
3
4
{
"temperature": 22.5,
"humidity": 55
}
Node configuration
1
2
3
4
5
6
{
"deleteFrom": "DATA",
"keys": [
"pressure"
]
}
Outgoing message
Data:
1
2
3
4
{
"temperature": 22.5,
"humidity": 55
}
Output connections: Success
.
Explanation: The key pressure
does not exist in the message data, so nothing is deleted. The original message is passed through unchanged.