Delete metrics and the data behind them, or only the data
POST/metrics/deletions
Starts the deletion of the given metrics, physically - the data goes from the time-series store first, the metric row afterwards (HET-1713). Answers at once with what it started and what it refused; a refusal names what holds the metric, because a list of orphans is worked through by hand.
A metric is refused when a live signal still reads it, when an OPC-UA variable is mapped to it, when the platform assigned the metric itself, or when a deletion of it is already running.
With scope: DATA only the data goes (HET-2065): the metric, its signals and an OPC-UA variable mapped to it stay, so the first two refusals do not apply - a FORM metric is refused instead, its values being entries made by hand. reimportHistory lets the OPC-UA history catch-up fetch the deleted past again. Note that the data of a deleted metric does not come back, but the metric may - a source that is still sending recreates it under a new id on its next message.
POST rather than DELETE because the request carries a body and answers per metric; a DELETE per id would make the caller assemble the same answer itself.
Request
Responses
- 200
- 400
- 401
- 403
- default
What was started and what was refused
the default error response
Unauthorized — the bearer token is missing, expired or invalid, or carries no role. Errors raised by the security aspects contain an ErrorDto body; requests rejected by the security filter chain may have an empty body.
Forbidden — the authenticated user lacks the required role or access rights.
the default error response