Files
hawkbit/docs/src/main/resources/documentation/interfaces/ddi-api.md

174 lines
6.9 KiB
Markdown
Raw Normal View History

---
layout: documentation
title: DDI-API
---
{% include base.html %}
This API is based on HTTP standards and based on a polling mechanism.
The _hawkbit_ [update server](https://github.com/eclipse/hawkbit) provides REST resources which are consumed by the device to retrieve software update tasks.
Note: in DDI the target is identified using a **controllerId**. Controller is used as a term for the actual service/client on the device. That allows users to have in some cases even multiple clients on the same target for different tasks, e.g. Firmware update and App management.
# State Machine Mapping
For historical reasons the DDI has a different state machine and status messages than the [Target State Machine](../architecture/targetstate.html) of the _hawkBit_ update server.
This is kept in order to ensure that _DDI_ stays compatible for devices out there in the field. A future version "2" of _DDI_ might change that. _DDI_ also defines more states than the update server, e.g. multiple DDI states are currently mapped by the _DDI_ implementation to _RUNNING_ state. It is possible that in the future _hawkBit_ will fully leverage these additional states.
The _DDI_ API allows the device to provide the following feedback messages:
DDI `status.execution` type | handling by update server | Mapped ActionStatus type
--------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -----------------------------------------------------
CANCELED | This is send by the target as confirmation of a cancelation request by the update server. | CANCELED
REJECTED | This is send by the target in case an update of a cancelation is rejected, i.e. cannot be fulfilled at this point in time. Note: the target should send a CLOSED->ERROR if it believes it will not be able to proceed the action at all. | WARNING
CLOSED | Target completes the action either with `status.result.finished` SUCCESS or FAILURE as result. Note: DDI defines also a status NONE which will not be interpreted by the update server and handled like SUCCESS. | ERROR (DDI FAILURE) or FINISHED (DDI SUCCESS or NONE)
PROCEEDING | This can be used by the target to inform that it is working on the action. | RUNNING
SCHEDULED | This can be used by the target to inform that it scheduled on the action. | RUNNING
RESUMED | This can be used by the target to inform that it continued to work on the action. | RUNNING
# Resource Overview
The following chapters provide basic examples for the most important resources but we provide also a [detailed resource documentation](https://docs.bosch-iot-rollouts.com/documentation/rest-api/rootcontroller-api-guide.html).
## Base Poll Resource
```
GET /{tenant}/controller/v1/{controllerId}
```
In the answer to the baseUrl polling the backend can send action links. A possible action is a deploy command. The client makes a GET request on the given link:
_Example Response_
```
{
"config": {
"polling": {
"sleep": "00:05:00"
}
},
"_links": {
"deploymentBase": {
"href": "http://localhost:8080/default/controller/v1/example/deploymentBase/1?c=644088541"
},
"configData": {
"href": "http://localhost:8080/default/controller/v1/example/configData"
}
}
}
```
## Deployment Base Resource
```
GET /{tenant}/controller/v1/{controllerId}/deploymentBase/{id}
```
_Example Response_
```
{
"deployment": {
"download": "forced",
"update": "forced",
"chunks": [
{
"part": "os",
"version": "1.0.0",
"name": "Linux",
"artifacts": [
{
"filename": "linux.zip",
"hashes": {
"sha1": "46fc56de883ec027759d8513458fe1010aa7e793",
"md5": "5813e9655bd6871d0c25b8d510fd8605"
},
"size": 52167,
"_links": {
"download": {
"href": "http://localhost:8080/default/controller/v1/example/softwaremodules/1/artifacts/linux.zip"
},
"md5sum": {
"href": "http://localhost:8080/default/controller/v1/example/softwaremodules/1/artifacts/linux.zip.MD5SUM"
}
}
}
]
}
]
},
DDI API: Extend API response to report previous update execution status. (#506) * DDI API: Limit number of feedback messages for an action status. Even though the number of ActionStatus entries are limited to 1000 per action using QuotaManagement, there is no limit on the number of messages that can be sent as part of a single ActionStatus. This allows a controller to potentially send large number of messages for a single action. Limiting the number of allowed messages to 50 using the javax.validation.constraints.Size within DdiStatus. Signed-off-by: Christian Storm <christian.storm@siemens.com> Signed-off-by: Himanshu Kumar Singh <himanshu.singh@siemens.com> Signed-off-by: Raju HS <raju.hs@siemens.com> * DDI API: Extend API response to retrieve controller feedback. (#381) Resolves #381 The mechanism is useful for example, when the client software running on the device loses this information prior to reporting a final execution status such as 'closed' to hawkBit. This may happen, e.g., due to a power cycle or simply a crash. Upon the client software restarting, it installs the same payload again as advertised by hawkBit (as the device has not sent a final update execution status). Instead, if the last feedback sent to hawkBit would be reported back to the device, the client may resume installation. Feedback messages sent as part of POST /{tenant}/controller/v1/{targetid}/deploymentBase/{actionId}/feedback, are sent back to controller as part of response to GET /{tenant}/controller/v1/{targetid}/deploymentBase/{actionId}. Following example illustrates the API changes: 1. After retrieving the action from server, controller starts download and sends a feedback. curl 'http://127.0.0.1:8080/default/controller/v1/1/deploymentBase/1/feedback' -i -X POST -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/hal+json' -d '{ "id" : "1", "time" : "20170406T121500", "status" : { "result" : { "progress" : { "of" : 1, "cnt" : 0 }, "finished" : "none" }, "execution" : "proceeding", "details" : [ "proceeding with download" ] } }' 2. Once artifact download has finished, controller sends another feedback. curl 'http://127.0.0.1:8080/default/controller/v1/1/deploymentBase/1/feedback' -i -X POST -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/hal+json' -d '{ { "id" : "1", "time" : "20170406T123000", "status" : { "result" : { "progress" : { "of" : 1, "cnt" : 0 }, "finished" : "none" }, "execution" : "proceeding", "details" : [ "downloaded artifacts for update" ] } }' 3. If there is a power outage now, the controller can retrieve the messages posted earlier from the action history when it restarts again. curl 'http://127.0.0.1:8080/default/controller/v1/1/deploymentBase/1?c=411599879&actionHistory=-1' -i -H 'Accept: application/hal+json' Response will be like below { "id": "1", "deployment": { "download": "forced", "update": "forced", "chunks": [ { "part": "os", "version": "1", "name": "1", "artifacts": [....], } ], }, "actionHistory": { "status": "RETRIEVED", "messages": [ "downloaded artifacts for update", "proceeding with download" ] } } 4. Based on the feedback messages, controller may be able to skip the download and resume with installation and send additional feedback. curl 'http://127.0.0.1:8080/default/controller/v1/1/deploymentBase/1/feedback' -i -X POST -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/hal+json' -d '{ "id" : "1", "time" : "20170406T121314", "status" : { "result" : { "progress" : { "of" : 1, "cnt" : 0 }, "finished" : "none" }, "execution" : "resumed", "details" : [ "resuming installation based on previous feedback, download skipped" ] } }' Note: The maximum number of messages to be retrieved from the database by a controller is limited to 100. The actionHistory parameter's value has the following meaning: Input Value | Output ----------------------------- <0 | Retrieve maximum allowed number of messages from | action history. unspecified or =0 | Do not retrieve any message (default). >0 | Retrieve specified number of messages, limited by | maximum allowed number. Signed-off-by: Christian Storm <christian.storm@siemens.com> Signed-off-by: Himanshu Kumar Singh <himanshu.singh@siemens.com> Signed-off-by: Raju HS <raju.hs@siemens.com>
2017-06-06 08:26:01 +02:00
"id": "1",
"actionHistory": {
"status": "RETRIEVED",
"messages": [
"Installing update",
"Downloading artifacts"
]
}
}
```
## Deployment Feedback Resource
To every deployment the client can post feedback back to the update-server about the deployment status.
```
POST /{tenant}/controller/v1/{controllerId}/deploymentBase/{id}/feedback
Content-Type: application/json
```
_Example Body Deployment Success_
```
{
"id": 1,
"time": "20140511T121314",
"status": {
"execution": "closed",
"result": {
"finished": "success",
"progress": {}
}
}
}
```
_Example Body Deployment Proceeding_
```
{
"id": "1",
"time": "20140511T121314",
"status": {
"execution": "proceeding",
"result": {
"finished": "none",
"progress": {
"cnt": 2,
"of": 5
}
},
"details": [
"checking hash sums"
]
}
}
```
_Example Body Deployment Error_
```
{
"id": 1,
"time": "20140511T121314",
"status": {
"execution": "rejected",
"result": {
"finished": "failure",
"progress": {}
},
"details": [
"something bad happend"
]
}
}
```