# Owner.Remove Request
This message is used to abandon ownership of one or more object models.
Currently sending one object model at a time is supported. If the body contains more than one object model, the request will be rejected by the platform.
'owner.remove' action message is sent to the platform by a connected device (i.e. Edge) via IoTHub.
(Information Model) Requested model must exist and be owned.
# Idempotency
This request is idempotent, meaning that sending several identical requests will result in the owner being successfully removed from model(s) in IM. One of the two following outcomes will occur due to this design:
- First owner removal will be successful
- Following owner removals will also be considered successful
# Event Properties
# Unique Message Headers
Property | Mandatory | Description |
---|---|---|
owner | Optional | An owner of this model, as a relative path. If absent, a directly connected device is presumed to be the owner |
# Message Body
A json array of objects. An object contains:
objectId - Required. Object identifier. Must be in GUID format model - Required. Model definition identifier (modelId). Case sensitive
ARRAY LIMITS
Due to lack of transactional support, array can currently contain only one element!
# Message Format
owner.remove
action message has following format when it is received and ready
for processing. Only showing data relevant for message processing.
{
"msgType": "owner.remove",
"version": 2,
"ack": "<ack>",
"correlationId": "<GUID>",
"target": "<connected device path>",
"owner": "<relative path>",
"body": [
{
"objectId": "<GUID>",
"model": "<model definition>"
}
]
}
# Validation Rules
DCS validates all message properties, that the message body is in proper JSON format, and that all message body properties as specified in the summary of all v2 Device API messages.
# Expected Acknowledgement Responses
The acknowledgement, positive or negative, will be sent in the standard Device API format. This action does not have any specific properties for this message
# Functionality
The ownership on all requested models is abandoned in IM. 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, acknowledgement c2d message is sent back to directly connected device where it can also be propagated further if needed (based on target). For more details see Acknowledgement Handling
# Error handling
When an error occurs the error information is logged inside platform in the Azure Portal on the Application Insight blade.
If a response can be delivered back to device then the acknowledgments are sent back to device, only if requested. More details can be found here: Acknowledgement Handling