# Type.Delete Request

This message is used to soft-delete a type definition from the TDR of the given model definition. The type definition is only marked as deleted and stays in the database. No new instances can be created and no new versions added. The 'type.delete' action message is sent to the platform by a directly connected device (i.e. Edge) via the IoT hub. This is a completely new message in Device API v2 format.

The Device API of the Ability platform allows a BL developer to create, read, update, and delete (CRUD) data for managing types from directly connected devices using the Device API. Specifically, the feature supports the type.delete message type.

NOTE

At present, the IoT Hub restricts C2D message size to 64kB. This means that a single type definition larger than 64kB will not be properly handled by the Device API. This limitation will be addressed in a future platform release.

NOTE

There are no changes in messaging for Edge devices in Anaheim. Edge support for Device API v2 messages is planned for a future release.

# Idempotency

This request is idempotent, meaning that sending several identical requests will result in the type being successfully soft-deleted in TDR. One of the two following outcomes will occur due to this design:

  • First delete of an existing type (of specific version) will be successful
  • Following deletes of this type (of specific version) will be rejected

# Event Properties

# Unique Message Headers

Property Mandatory Description
typeId Mandatory Type identifier of the new type definition.
model Optional Source model definition identifier (modelId). Case sensitive. If not provided, defaults to "abb.ability.device".

# Message Body

This message type has an empty body.

# Message Format

{
    "properties": {
        "iothub-connection-device-id": "<authenticated device id>",
        "msgType": "action",
        "action": "type.delete",
        "version": 2,
        "correlationId": "<correlation id>",
        "ack": "<ack>",
        "target": "<connected device path>",
        "timeout":"<integer>",
        "model": "<model definition>",
    "body": "<none>"
    }
}

# Validation Rules

DCS validates all message properties as specified in the summary of all v2 Device API messages. DCS does not validate message body because it is empty.

# Functionality

# Description

  • The type definition is soft-deleted from the TDR.

  • A type notification C2D message is not sent back.

NOTE DCS will never send back a 'request-response' notification message.

Any platform events generated by the IM service related to this request are ignored by the DCS.

  • If requested, an acknowledgement C2D message is sent back to the directly connected device where it can be propagated further, as needed (based on target). Note that the target is reused from the requested message. For more, see Acknowledgement Handling.

  • The target is reused from the requested message.

# Format of Returned Acknowledgement C2D Message

  • The general format of a Device API v2 acknowledgement message is described in Acknowledgement Handling.

  • CorrelationId and target should be reused from the input action.

  • The format of a successful acknowledgement includes a header and the boolean property true in the body. Note the following:

    • Header - contains:

      • a timestamp with a required string data type. The timestamp is rendered in simplified extended ISO format (YYYY-MM-DDTHH:mm:ss.sssZ) and must be a zero UTC offset, as denoted by the suffix "Z".

Successful Acknowledgement:

{
  "properties": {
    "msgType": "ack",
    "action": "type.delete",
    "version": 2,
    "correlationId": "<correlation id>",
    "target": "<target matches the target in the corresponding action>",
    "timestamp": "<YYYY-MM-DDTHH:mm:ss.sssZ>"
  },
  "body": {
    "success": true,
    "code": "ok",
    "details": ""
    }
}
  • The format of a failed acknowledgement includes a header and the boolean property false in the body. Note the following:

    • Header - contains:

      • a timestamp with a required string data type. The timestamp is rendered in simplified extended ISO format (YYYY-MM-DDTHH:mm:ss.sssZ) and must be a zero UTC offset, as denoted by the suffix "Z".
    • Body - contains:

      • success (false), code, and details

Failed acknowledgement:

{
  "properties": {
    "msgType": "ack",
    "action": "type.delete",
    "version": 2,
    "correlationId": "<correlation id>",
    "target": "<target matches the target in the corresponding action>",
    "timestamp": "<YYYY-MM-DDTHH:mm:ss.sssZ>"
  },
  "body": {
    "success": false,
    "code": "<error code>",
    "details": "<error details>"
    }
}
Last updated: 9/6/2021, 1:25:50 PM
Feedback