Commit 459ab5fc authored by Marco Cavalli's avatar Marco Cavalli
Browse files

chore: upload cim008

parent 1f11fbfa
Loading
Loading
Loading
Loading
+337 −0
Original line number Diff line number Diff line
# 10 Information Subscriptions

## 10.1 Overview Information Subscriptions

Clause 10 describes the NGSI-LD API operations for subscriptions and the resulting notifications, i.e. the operations that can be used to request Entity information and asynchronously receive the information in form of notifications. Clause 10.2.1 describes change-based subscriptions and how updates and the creation of new Entities trigger notifications. Clause 10.2.2 describes time-based subscriptions and notifications that are triggered whenever the specified time interval has passed, independent of any changes to the Entity information.

## 10.2 Creating Subscriptions

### 10.2.1 Change-based Subscriptions, Updates and Resulting Notifications

Change-based subscription are based on the change of an Attribute, i.e. the value of a Property or the object of a Relationship. The Attributes whose changes trigger the notification are specified as a list in the [watchedAttributes]{.HTML-Sample} element of a subscription. Only in case this Attribute changes in an existing Entity or a new Entity with this Attribute is created, a notification will be sent.

In Figure 10.2.1-1, a subscription for Entities of type [Store]{.HTML-Sample} (mapped to [https://uri.etsi.org/ngsi-ld/primer/Store ]{.HTML-Sample}in the[\@context]{.HTML-Sample}) and [watchedAttributes ]{.HTML-Sample}with the Property [storeName]{.HTML-Sample} (mapped to [https://uri.etsi.org/ngsi-ld/primer/storeName ]{.HTML-Sample}in the[\@context]{.HTML-Sample}) is shown.

The notification to be sent on a change is further specified in the [notification]{.HTML-Sample} element. The [attributes]{.HTML-Sample} specified are those to be included for the Entities to be returned, if available. If no Attribute is available for an Entity, it will not be returned. If no Attributes are specified, all available Attributes will be returned.

For the avoidance of any doubt, for the Attributes to be returned, only those specified in [attributes]{.HTML-Sample} will be considered. These can include the triggering Attribute from [watchedAttributes ]{.HTML-Sample}or not - the triggering Attribute is not always returned, only in case it is specified. In the example in Figure 10.2.1-1, the Properties [storeName]{.HTML-Sample} and [address ]{.HTML-Sample}(but not [location]{.HTML-Sample}), will be returned, if available.

``` json
POST /ngsi-ld/v1/subscriptions HTTP/1.1
Host: localhost:9090
Content-Type: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
{
    "id": "urn:ngsi-ld:Subscription:storeSubscription",
    "type": "Subscription",
    "entities": [
    {
    "type": "Store"
    }
  ],
    "watchedAttributes": ["storeName"],
  "notification": {
    "attributes": ["storeName","address"],
    "format": "normalized",
    "endpoint": {
    "uri": "http://localhost:8000/notify",
    "accept": "application/json"
    }
}
}
```

::: TF
Figure 10.2.1-1: Subscription to Entities of type Store, based on changes
:::

For the format, either [normalized ]{.HTML-Sample}(which is the default) or [keyValue]{.HTML-Sample} can be specified. Just as in the case of queries, [keyValue ]{.HTML-Sample}will only return pairs of Attribute names and values without any additional information, otherwise the complete information will be returned.

In the [endpoint]{.HTML-Sample} element, the [uri ]{.HTML-Sample}specifies HTTP URL to which the notification is to be sent. This requires that the URL is reachable with an HTTP request, i.e. cannot be behind a firewall. The [accept ]{.HTML-Sample}specifies the JSON-LD format, i.e. valid mime-types are [application/json]{.HTML-Sample} (i.e. the [\@context]{.HTML-Sample} will be provided in a Link header) and [application/ld+json]{.HTML-Sample} (i.e. the [\@context]{.HTML-Sample} will be provided as an element in the JSON body).

``` json
PATCH /ngsi-ld/v1/entities/urn:ngsi-ld:Store:001/attrs/storeName HTTP/1.1
Host: localhost:9090
Content-Type:application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
{
"value": "Mega Store"
}
```

::: TF
Figure 10.2.1-2: Partial update of storeName Property in urn:ngsi-ld:Store:001 Entity
:::

When updating the name of the Store entity with Entity identifier [urn:ngsi-ld:Store:001]{.HTML-Sample} from "Checker Market" to "Mega Store" as shown in Figure 10.2.1-2, the subscription [urn:ngsi-ld:Subscription:storeSubscription]{.HTML-Sample} matches as the type is [Store]{.HTML-Sample} and the updated Property [storeName]{.HTML-Sample} matches an element in the [watchedAttributes]{.HTML-Sample} list. Thus, the notification in Figure 10.2.1-3 is triggered.

``` json
POST /notify HTTP/1.1
Host: localhost:8000
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
Content-Type: application/json
{
    "id": "ngsildbroker:notification:-4999875641436467960",
    "type": "Notification",
    "data": [
    {
    "id": "urn:ngsi-ld:Store:001",
    "type": "Store",
    "address": {
    "type": "Property",
    "createdAt": "2020-02-05T09:04:40.987000Z",
    "value": {
        "address:Locality": "Duck Village",
        "addressRegion": "Metropolis",
        "postalCode": "42000",
        "streetAddress": "Main Street 65"
    },
    "modifiedAt": "2020-02-05T09:04:40.987000Z"
    },
    "storeName": {
    "type": "Property",
    "createdAt": "2020-02-05T09:04:40.987000Z",
    "value": "Mega Store",
    "modifiedAt": "2020-02-05T10:36:22.691000Z"
    }
    }
    ],
    "notifiedAt": "2020-02-05T10:36:23.709000Z",
 "subscriptionId": "urn:ngsi-ld:Subscription:storeSubscription"
}
```

::: TF
Figure 10.2.1-3: Notification to subscription triggered by update of storeName Property
:::

The notification contains the [subscriptionId]{.HTML-Sample}, so it is always clear which subscription triggered the notification and a [notifiedAt]{.HTML-Sample} timestamp.

The Entity is contained in the data [element]{.HTML-Sample} of the notification and, as specified, includes that Properties address and storeName, including [modifiedAt]{.HTML-Sample} timestamp of the [storeName]{.HTML-Sample}, i.e. when the Property was updated.

``` json
POST /ngsi-ld/v1/entities/ HTTP/1.1
Host: localhost:9090
Content-Type: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
{
"id": "urn:ngsi-ld:Store:003",
"type": "Store",
    "address": {
"type": "Property",
"value": {
"streetAddress": "Lion Street 25",
"addressRegion": "Metropolis",
"addressLocality": "Cat City",
"postalCode": "42420"
}
},
    "location": {
"type": "GeoProperty",
"value": {
    "type": "Point",
    "coordinates": [
        57.5722,
        -20.3584
    ]
    } 
    },
    "storeName": {
    "type": "Property",
    "value": "Giga Market"
}
}
```

::: TF
Figure 10.2.1-4: Creation of new Store Entity with storeName Giga Market
:::

A notification for the subscription can also be triggered by the creation of a new Entity as shown in Figure 10.2.1-4. The creation results in the notification in Figure 10.2.1-5, containing the Entity with the Entity identifier [urn:ngsi-ld:Store:003 ]{.HTML-Sample}and Properties [address]{.HTML-Sample} and [storeName]{.HTML-Sample} as specified in the subscription.

``` json
POST /notify HTTP/1.1
Host: localhost:8000
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
Content-Type: application/json
{
    "id": "ngsildbroker:notification:-8311420531544870425",
    "type": "Notification",
    "data": [
    {
    "id": "urn:ngsi-ld:Store:003",
    "type": "Store",
    "address": {
    "type": "Property",
    "createdAt": "2020-02-05T15:54:56.813000Z",
    "value": {
        "addressRegion": "Metropolis",
        "postalCode": "42420",
        "streetAddress": "Lion Street 25",
        "addressLocality": "Cat City"
    },
    "modifiedAt": "2020-02-05T15:54:56.813000Z"
    },
    "storeName": {
    "type": "Property",
    "createdAt": "2020-02-05T15:54:56.813000Z",
    "value": "Giga Market",
    "modifiedAt": "2020-02-05T15:54:56.813000Z"
    }
    }
    ],
    "notifiedAt": "2020-02-05T15:54:57.024000Z",
 "subscriptionId": "urn:ngsi-ld:Subscription:storeSubscription"
}
```

::: TF
Figure 10.2.1-5: Notification to subscription triggered by creation of new Store with storeName Property
:::

### 10.2.2 Time-based Subscriptions and Resulting Notifications

Time-based subscriptions are sent after each notification interval, i.e. independent of whether there have been any changes in the Entities that fit the subscription or not.

In Figure 10.2.2-1, a subscription for Entities of type [Store]{.HTML-Sample} (mapped to [https://uri.etsi.org/ngsi-ld/primer/Store ]{.HTML-Sample}in the[\@context]{.HTML-Sample}) is shown. Notifications are to be sent every [timeInterval]{.HTML-Sample}, in this case every [60]{.HTML-Sample} seconds. The notification element is the same as in Figure 10.2.1-1, i.e. store Entities with the Attributes [storeName]{.HTML-Sample} and [address]{.HTML-Sample}, in [normalized]{.HTML-Sample} format are to be sent as HTTP POST requests to the notification endpoint that has the uri [http://localhost:8000/notify]{.HTML-Sample}.

``` json
POST /ngsi-ld/v1/subscriptions HTTP/1.1
Host: localhost:9090
Content-Type: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
{
    "id": "urn:ngsi-ld:Subscription:intervalStoreSubscription",
    "type": "Subscription",
    "entities": [
    {
    "type": "Store"
    }
    ],
    "timeInterval": 60,
"notification": {
    "attributes": ["storeName","address"],
    "format": "normalized",
    "endpoint": {
    "uri": "http://localhost:8000/notify",
    "accept": "application/json"
    }
}
} 
```

::: TF
Figure 10.2.2-1: Subscription to Entities of type Store, based on time
:::

In Figure 10.2.2-2, a notification sent as the result of the time-based subscription in Figure 10.2.2-1 is shown.

``` json
POST /notify HTTP/1.1
Host: localhost:8000
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
Content-Type: application/json
{
"id": "ngsildbroker:notification:-6431227878819736798",
"type": "Notification",
"data": [ {
"id": "urn:ngsi-ld:Store:002",
"type": "Store",
"address": {
"type": "Property",
"value": {
"addressRegion": "Metropolis",
"postalCode": "42420",
"streetAddress": "Tiger Street 4",
"addressLocality": "Cat City"
}
},
"storeName": {
"type": "Property",
"value": "6-Stars"
}
}, {
"id": "urn:ngsi-ld:Store:001",
"type": "Store",
"address": {
"type": "Property",
"value": {
"address:Locality": "Duck Village",
"addressRegion": "Metropolis",
"postalCode": "42000",
"streetAddress": "Main Street 65"
}
},
"storeName": {
"type": "Property",
"value": "Mega Market"
}
}, {
"id": "urn:ngsi-ld:Store:003",
"type": "Store",
"address": {
"type": "Property",
"value": {
"addressRegion": "Metropolis",
"postalCode": "42420",
"streetAddress": "Lion Street 25",
"addressLocality": "Cat City"
}
},
"storeName": {
"type": "Property",
"value": "Giga Market"
}
} ],
"notifiedAt": "2020-02-09T18:08:02.669000Z",
"subscriptionId": "urn:ngsi-ld:Subscription:intervalStoreSubscription"
}
```

::: TF
Figure 10.2.2-2: Notification to time-based subscription
:::

Subscriptions can also be retrieved as shown in Figure 10.2.2-3.

``` json
GET /ngsi-ld/v1/subscriptions/urn:ngsi-ld:Subscription:intervalStoreSubscription HTTP/1.1
Host: localhost:9090
Accept: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
```

::: TF
Figure 10.2.2-3: Retrieval of a subscription
:::

In addition to the elements that were provided on creation, some status information is provided. In Figure 10.2.2-4, it can be seen when the last notification was sent, when the last successful notification was sent and how many notifications have been sent since the creation of the subscription. In case the sending of a notification failed, the time of the last failed attempt would also be shown.

``` json
{
"id": "urn:ngsi-ld:Subscription:intervalStoreSubscription",
"type": "Subscription",
"entities": {
"type": "Store"
},
"notification": {
"attributes": [
"storeName",
"address"
],
"endpoint": {
"accept": "application/json",
"uri": "http://localhost:8000/notify"
},
"format": "normalized",
"lastNotification": "2020-02-09T18:13:02.676000Z",
"lastSuccess": "2020-02-09T18:13:02.676000Z",
"timesSent": 16
},
"timeInterval": 60
}
```

::: TF
Figure 10.2.2-4: Retrieved Subscription
:::
+347 −0
Original line number Diff line number Diff line
# 11 Batch Operations

## 11.1 Overview Batch Operations

Clause 11 describes the Batch operations for the provision and deletion of groups of Entities (i.e. batches). Clause 11.2 describes the operation for creating a group of Entities that do not exist inside the Context Broker. Clause 11.3 describes the operation for updating a group of Entities that exist inside the Context Broker. Clause 11.4 describes the operation for both creating and updating a group of Entities inside the Context Broker. Clause 11.5 describes the operation for deleting a group of NGSI-LD Entities that exist inside the Context Broker.

## 11.2 Batch Entity Create

In clause 8.2.1 it was shown how to create one single Entity inside a Context Broker. If more suitable, groups of Entities can be provided to Context Brokers, to create more than one Entity in a single request, with the Batch Entity Create operation. Figure 11.2-1 shows the request to create two Entities - which represent a new Store and a new Shelf - in a single request using a link header for providing the [\@context]{.HTML-Sample}.

``` json
POST /ngsi-ld/v1/entityOperations/create HTTP/1.1
Host: localhost:9090
Content-Type: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
[
{
"id": "urn:ngsi-ld:Store:004",
"type": "Store",
"address": {
"type": "Property",
"value": {
"streetAddress": "Tiger Street 7",
"addressRegion": "Metropolis",
"addressLocality": "Cat City",
"postalCode": "42420"
}
},
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
"coordinates": [57.5522, -20.3284] 
}
},
"storeName": {
"type": "Property",
"value": "6-Stars"
},
"contains":{
"type":"Relationship",
"object":"urn:ngsi-ld:Shelf:123",
"observedAt":"2019-09-11T17:11:07Z"
}
},
{
"id": "urn:ngsi-ld:Shelf:234",
"type": "Shelf",
"maxCapacity": {
"type": "Property",
"value": 80
}
}
]
```

::: TF
Figure 11.2-1: Store and Shelf Entities creation
:::

If the creation is successful, the response in Figure 11.2-2 with HTTP return code [201]{.HTML-Sample} Created is returned.

``` json
HTTP/1.1 201 Created
Date: Wed, 04 Apr 2019 11:42:15 GMT
location: /ngsi-ld/v1/entityOperations/create
```

::: TF
Figure 11.2-2: Store and Shelf Entities creation result
:::

When the creation is not successful, i.e. all the Entities were not created, or is partially successful, i.e. at least one Entity was created, the body in the HTTP response shows the reasons of failure for each Entity that was not created. For instance, trying to recreate the Entities in Figure 11.2-1 leads to the result shown in Figure 11.2-3 where it is clearly stated that the Entities could not be created because they already exist in the Context Broker.

``` json
HTTP/1.1 400 Bad Request
Date: Wed, 04 Apr 2019 11:42:15 GMT
location: /ngsi-ld/v1/entityOperations/create
{
"success": [],
"errors": [
{
"@id": "urn:ngsi-ld:Store:004",
"ProblemDetails": "{\n\t"type":"https://uri.etsi.org/ngsi-ld/errors/AlreadyExists",\n\t"title":"Already exists.",\n\t"detail":"urn:ngsi-ld:Store:004 already exists"\n}"
},
{
"@id": "urn:ngsi-ld:Shelf:234",
"ProblemDetails": "{\n\t"type":"https://uri.etsi.org/ngsi-ld/errors/AlreadyExists",\n\t"title":"Already exists.",\n\t"detail":"urn:ngsi-ld:Shelf:234 already exists"\n}"
}
]
}
```

::: TF
Figure 11.2-3: Store and Shelf Entities creation unsuccessful result
:::

If only some or none of the Entities have been successfully created an HTTP return code [207]{.HTML-Sample} Multi-Status is returned.

## 11.3 Batch Entity Update

The Batch Entity Update operation allows to update more than one NGSI-LD Entity at time with a single HTTP request. Specifically, this operation allows the creation, modification and deletion of Properties and Relationships of **existing** Entities. The major difference between the operations described in clause 8.3 and the Batch Entity Update operation is that the body of the POST HTTP request always contains an array of valid NGSI-LD Entities, i.e. each Entity has the "id" and the "type" fields.

Figure 11.3-1 shows how to perform the Batch Entity Update operation using a link header for providing the [\@context]{.HTML-Sample}. The successful result is shown in Figure 11.3-2.

``` json
POST /ngsi-ld/v1/entityOperations/update HTTP/1.1
Host: localhost:9090
Content-Type: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
[
{
"id": "urn:ngsi-ld:Store:004",
"type": "Store",
"address": {
"type": "Property",
"value": {
"streetAddress": "Tiger Street 7",
"addressRegion": "Metropolis",
"addressLocality": "Cat City",
"postalCode": "42420"
},
"observedAt": "2019-09-12T17:11:07Z"
}
},
{
"id": "urn:ngsi-ld:Shelf:234",
"type": "Shelf",
"maxCapacity": {
"type": "Property",
"value": 85
}
}
]
```

::: TF
Figure 11.3-1: Store and Shelf Entities update
:::

``` json
HTTP/1.1 204 No Content
Date: Wed, 04 Apr 2019 11:42:15 GMT
location: /ngsi-ld/v1/entityOperations/update
```

::: TF
Figure 11.3-2: Store and Shelf Entities update
:::

The default behaviour of the Batch Entity Update operation is to append new Properties and Relationships and overwrite existing Properties and Relationships for each Entity performing the Update operation described in clause 8.3.2. If desired, the "options=noOverwrite" URL parameter can be provided to deny the modification of existing Properties and Relationships of each Entity, performing the Append operation described in clause 8.3.1.

Figure 11.3-3 shows how to perform the Batch Entity Update operation without providing the "options=noOverwrite" URL parameter using a link header for providing the [\@context]{.HTML-Sample}. The successful result is shown in Figure 11.3-4.

``` json
POST /ngsi-ld/v1/entityOperations/update?options=noOverwrite HTTP/1.1
Host: localhost:9090
Content-Type: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
[
{
"id": "urn:ngsi-ld:Store:004",
"type": "Store",
"owner": {
"type": "Property",
"value": "JohnDoe"
}
},
{
"id": "urn:ngsi-ld:Shelf:234",
"type": "Shelf",
"minCapacity": {
"type": "Property",
"value": "65"
}
}
]
```

::: TF
Figure 11.3-3: Store and Shelf Entities update with noOverwrite
:::

``` json
HTTP/1.1 204 No Content
Date: Wed, 04 Apr 2019 11:42:15 GMT
location: /ngsi-ld/v1/entityOperations/update
```

::: TF
Figure 11.3-4: Store and Shelf Entities update with noOverwrite result
:::

If only some or none of the Entities have been successfully updated an HTTP return code [207]{.HTML-Sample} Multi-Status is returned.

## 11.4 Batch Entity Upsert

The Batch Entity Upsert operation can be used to create or update a batch of NGSI-LD Entities with a single HTTP request.

Figure 11.4-1 shows how to perform the Batch Entity Upsert operation using a link header for providing the [\@context]{.HTML-Sample}. The successful result is shown in Figure 11.4-2.

``` json
POST /ngsi-ld/v1/entityOperations/upsert HTTP/1.1
Host: localhost:9090
Content-Type: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
[
{
"id": "urn:ngsi-ld:Store:004",
"type": "Store",
"address": {
"type": "Property",
"value": {
"streetAddress": "Tiger Street 7",
"addressRegion": "Metropolis",
"addressLocality": "Cat City",
"postalCode": "42420"
}
},
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
"coordinates": [57.5522, -20.3484] 
}
},
"storeName": {
"type": "Property",
"value": "6-Stars"
},
"contains":{
"type":"Relationship",
"object":"urn:ngsi-ld:Shelf:345",
"observedAt":"2019-09-11T17:11:07Z"
}
},
{
"id": "urn:ngsi-ld:Shelf:345",
"type": "Shelf",
"minCapacity": {
"type": "Property",
"value": "65"
}
}
]
```

::: TF
Figure 11.4-1: Store and Shelf Entities upsert
:::

``` json
HTTP/1.1 201 Created
Date: Wed, 04 Apr 2019 11:42:15 GMT
location: /ngsi-ld/v1/entityOperations/upsert
[
    "urn:ngsi-ld:Shelf:345"
]
```

::: TF
Figure 11.4-2: Store and Shelf Entities upsert
:::

When updating, the default behaviour of the Batch Entity Upsert operation is to replace the existing Entities with the one provided in the body of the POST HTTP request. This behaviour can be changed using the "options=update" URL parameter. If given, when updating the Entities are not replaced, but they are just updated using the same logic of the Batch Entity Update operation described in clause 11.3 (default behaviour).

Figure 11.4-3 shows how to perform the Batch Entity Upsert operation providing the "options=update" URL parameter. The successful result is shown in Figure 11.4-4.

``` json
POST /ngsi-ld/v1/entityOperations/upsert?options=update HTTP/1.1
Host: localhost:9090
Content-Type: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
[
{
"id": "urn:ngsi-ld:Store:004",
"type": "Store",
"storeName": {
"type": "Property",
"value": "12-Stars"
}
},
{
"id": "urn:ngsi-ld:Shelf:345",
"type": "Shelf",
"minCapacity": {
"type": "Property",
"value": "40"
},
"maxCapacity": {
"type": "Property",
"value": "80"
}
}
]
```

::: TF
Figure 11.4-3: Store and Shelf Entities upsert with options=update
:::

``` json
HTTP/1.1 204 No Content
Date: Wed, 04 Apr 2019 11:42:15 GMT
location: /ngsi-ld/v1/entityOperations/upsert?options=update
```

::: TF
Figure 11.4-4: Store and Shelf Entities upsert with options=update
:::

In case of successful results, the returned HTTP response has a code [201]{.HTML-Sample} Created if at least one of the Entities in the body of the HTTP request was created, otherwise an HTTP return code [204]{.HTML-Sample} No content is returned, i.e. all the Entities provided in the body of the HTTP request already existed in the Context Broker and they were all updated.

If only some or none of the Entities have been successfully created or updated an HTTP return code [207]{.HTML-Sample} Multi-Status is returned.

## 11.5 Batch Entity Delete

The Batch Entity Delete operation can be used to delete a batch of NGSI-LD Entities with a single HTTP request.

Figure 11.5-1 shows how to perform the Batch Entity Delete operation using a link header for providing the [\@context]{.HTML-Sample}. The successful result is shown in Figure 11.5-2.

``` json
POST /ngsi-ld/v1/entityOperations/delete HTTP/1.1
Host: localhost:9090
Content-Type: application/json
Link: <https://uri.etsi.org/ngsi-ld/primer/store-context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"
[
"urn:ngsi-ld:Store:004",
"urn:ngsi-ld:Shelf:345"
]
```

::: TF
Figure 11.5-1: Store and Shelf Entities delete
:::

``` json
HTTP/1.1 204 No Content
Date: Wed, 04 Apr 2019 11:42:15 GMT
location: /ngsi-ld/v1/entityOperations/delete
```

::: TF
Figure 11.5-2: Store and Shelf Entities delete
:::

If only some or none of the Entities have been successfully deleted an HTTP return code [207]{.HTML-Sample} Multi-Status is returned.
+348 −0

File added.

Preview size limit exceeded, changes collapsed.

+515 −0

File added.

Preview size limit exceeded, changes collapsed.

+553 −0

File added.

Preview size limit exceeded, changes collapsed.

Loading