... | @@ -55,14 +55,14 @@ Note that you can register as much of your API specification as you like. You on |
... | @@ -55,14 +55,14 @@ Note that you can register as much of your API specification as you like. You on |
|
"info": {
|
|
"info": {
|
|
"description": "This is a sample Wellbore domain DM service.",
|
|
"description": "This is a sample Wellbore domain DM service.",
|
|
"version": "1.0.0",
|
|
"version": "1.0.0",
|
|
"title": "DELFI Data Ecosystem Wellbore Domain DM Service",
|
|
"title": "Wellbore Domain DM Service",
|
|
"contact": {
|
|
"contact": {
|
|
"email": "dataecosystem-sre@slb.com"
|
|
"email": "email@domain.com"
|
|
}
|
|
}
|
|
},
|
|
},
|
|
"servers": [
|
|
"servers": [
|
|
{
|
|
{
|
|
"url": "https://subsurface.data.delfi.slb.com/v1"
|
|
"url": "https://subsurface.data.osdu.com/v1"
|
|
}
|
|
}
|
|
],
|
|
],
|
|
"tags": [
|
|
"tags": [
|
... | @@ -264,7 +264,7 @@ Remember, you should append your DDMS Id, entityType and the bulk data’s local |
... | @@ -264,7 +264,7 @@ Remember, you should append your DDMS Id, entityType and the bulk data’s local |
|
|
|
|
|
As mentioned, a DDMS should create a shadow record for each retrievable entity ingested. This can have advantages beyond global discover-ability. Whenever you request a storage record, both compliance and entitlements are checked before returning the data. A DDMS can use this to their advantage.
|
|
As mentioned, a DDMS should create a shadow record for each retrievable entity ingested. This can have advantages beyond global discover-ability. Whenever you request a storage record, both compliance and entitlements are checked before returning the data. A DDMS can use this to their advantage.
|
|
|
|
|
|
By forwarding on any request by the client to retrieve the record, you can delegate these responsibilities to the Storage service. If Data Ecosystem returns the Record, the client can access both this and the bulk data, and so you can return the same to the client or only the Record.
|
|
By forwarding on any request by the client to retrieve the record, you can delegate these responsibilities to the Storage service. If OSDU returns the Record, the client can access both this and the bulk data, and so you can return the same to the client or only the Record.
|
|
|
|
|
|
<details><summary>curl</summary>
|
|
<details><summary>curl</summary>
|
|
|
|
|
... | @@ -274,8 +274,8 @@ By forwarding on any request by the client to retrieve the record, you can deleg |
... | @@ -274,8 +274,8 @@ By forwarding on any request by the client to retrieve the record, you can deleg |
|
--url '/api/storage/v2/query/records:batch' \
|
|
--url '/api/storage/v2/query/records:batch' \
|
|
--header 'Authorization: Bearer <JWT>' \
|
|
--header 'Authorization: Bearer <JWT>' \
|
|
--header 'Content-Type: application/json' \
|
|
--header 'Content-Type: application/json' \
|
|
--header 'Slb-Data-Partition-Id: common' \
|
|
--header 'Data-Partition-Id: common' \
|
|
--header 'slb-frame-of-reference: NONE' \
|
|
--header 'frame-of-reference: NONE' \
|
|
--data '{
|
|
--data '{
|
|
"records": [
|
|
"records": [
|
|
"common:test:fetchtest-1",
|
|
"common:test:fetchtest-1",
|
... | @@ -291,7 +291,7 @@ By forwarding on any request by the client to retrieve the record, you can deleg |
... | @@ -291,7 +291,7 @@ By forwarding on any request by the client to retrieve the record, you can deleg |
|
|
|
|
|
</details>
|
|
</details>
|
|
|
|
|
|
In this scenario, you also don’t need to store the ACL or legal tag information in your DDMS because those are being retrieved directly from the Data Ecosystem in this request. However, you need to either store or be able to generate the Storage record ID needed to retrieve the record for the bulk data requested. Therefore using a deterministic ID for the Storage Record is advisable.
|
|
In this scenario, you also don’t need to store the ACL or legal tag information in your DDMS because those are being retrieved directly from the OSDU in this request. However, you need to either store or be able to generate the Storage record ID needed to retrieve the record for the bulk data requested. Therefore using a deterministic ID for the Storage Record is advisable.
|
|
|
|
|
|
## Client retrieves the bulk data <a name="retrieve"></a>
|
|
## Client retrieves the bulk data <a name="retrieve"></a>
|
|
|
|
|
... | @@ -339,14 +339,14 @@ This will return them the registered DDMS with the API specification. So if we r |
... | @@ -339,14 +339,14 @@ This will return them the registered DDMS with the API specification. So if we r |
|
"info": {
|
|
"info": {
|
|
"description": "This is a sample Wellbore domain DM service.",
|
|
"description": "This is a sample Wellbore domain DM service.",
|
|
"version": "1.0.0",
|
|
"version": "1.0.0",
|
|
"title": "DELFI Data Ecosystem Wellbore Domain DM Service",
|
|
"title": "Wellbore Domain DM Service",
|
|
"contact": {
|
|
"contact": {
|
|
"email": "dataecosystem-sre@slb.com"
|
|
"email": "email@domain.com"
|
|
}
|
|
}
|
|
},
|
|
},
|
|
"servers": [
|
|
"servers": [
|
|
{
|
|
{
|
|
"url": "https://subsurface.data.delfi.slb.com/v1"
|
|
"url": "https://subsurface.data.osdu.com/v1"
|
|
}
|
|
}
|
|
],
|
|
],
|
|
"tags": [
|
|
"tags": [
|
... | @@ -411,7 +411,7 @@ Using the returned specification and data we discovered, the resulting API call |
... | @@ -411,7 +411,7 @@ Using the returned specification and data we discovered, the resulting API call |
|
|
|
|
|
```
|
|
```
|
|
curl --request GET \
|
|
curl --request GET \
|
|
--url 'https://subsurface.data.delfi.slb.com/v1/wellbore/123456' \
|
|
--url 'https://subsurface.data.osdu.com/v1/wellbore/123456' \
|
|
--header 'Authorization: Bearer <JWT>' \
|
|
--header 'Authorization: Bearer <JWT>' \
|
|
--header 'Content-Type: application/json' \
|
|
--header 'Content-Type: application/json' \
|
|
--header 'Data-Partition-Id: common'
|
|
--header 'Data-Partition-Id: common'
|
... | | ... | |