Skip to content
Snippets Groups Projects
Commit b111d3f2 authored by Jorge Moratinos's avatar Jorge Moratinos
Browse files

Merge branch 'OCF-Doc17-add-vendor-extension-test-plan' into 'develop'

Resolve "Add Vendor Extension test plan"

Closes #17

See merge request !19
parents 283377c8 54d3f775
No related branches found
No related tags found
1 merge request!19Resolve "Add Vendor Extension test plan"
Pipeline #10253 passed
......@@ -11,3 +11,6 @@ List of Common API Services implemented:
* [Api Logging Service](./api_logging_service/README.md)
* [Api Auditing Service](./api_auditing_service/README.md)
* [Api Access Control Policy](./api_access_control_policy/README.md)
## Features
* [Vendor Extensibility](./vendor_extensibility/README.md)
# Test Plan for Vendor Extensibility Feature
At this documentation you will have all information and related files and examples of test plan for this feature.
## Test Case 1: Published API with vendor extensibility
**Test ID**: ***vendor_extensibility-1***
**Description**:
This test case will check if a published API with vendorExt flag active and vendorSpecific, can be discovered by invoker with all vendorSpecific fields.
**Pre-Conditions**:
* Network App was registered previously
* Network App was onboarded previously with {onboardingId}
**Execution Steps**:
1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
1. Supported Features with vendorExt flag active (binary 1 0000 0000 -> string **100**)
2. This API includes "Vendor Specific" information at **service API Description** and inside **AEF Profile**.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
1. includes **supported-features** with VendSpecQueryParams active (binary 010 -> string **2**)
**Information of Test**:
1. Perform [Provider Registration] and [Invoker Onboarding]
2. Publish Service API at CCF:
* Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
* body [service api description] with apiName **service_1**
* include [vendor specific service] in root of [service api description].
* include [vendor specific aef profile] in one AEFProfile inside aefProfiles key.
* supportedFeatures **100**
* Use **APF Certificate**
3. Request Discover Published APIs:
* Send **GET** to **https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=2**
* Param api-invoker-id is mandatory
* Use **Invoker Certificate**
**Expected Result**:
1. Response to Publish request must accomplish:
1. **201 Created**
2. Response Body must follow **ServiceAPIDescription** data structure with:
* apiId
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}**
4. Response must include **"vendorSpecific"** keys inside root and at AEF Profile.
2. Response to Onboard request must accomplish:
1. **201 Created**
2. Response Body must follow **APIInvokerEnrolmentDetails** data structure with:
* apiInvokerId
* onboardingInformation->apiInvokerCertificate must contain the public key signed.
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}**
3. Response to Discover Request By Invoker:
1. **200 OK** response.
2. Response body must follow **DiscoveredAPIs** data structure:
* Check if DiscoveredAPIs contains the API Published previously
* Check if contains the **vendorSpecific** keys
## Test Case 2: Published API with vendor extensibility and discover with VendSpecQueryParams disabled
**Test ID**: ***vendor_extensibility-2***
**Description**:
This test case will check if a published API with vendorExt flag active and vendorSpecific, but discovered filter only APIs without vendorSpecific parameter
**Pre-Conditions**:
* Network App was registered previously
* Network App was onboarded previously with {onboardingId}
**Execution Steps**:
1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
1. Supported Features with vendorExt flag active (binary 1 0000 0000 -> string **100**)
2. This API includes "Vendor Specific" information at **service API Description** and inside **AEF Profile**.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
**Information of Test**:
1. Perform [Provider Registration] and [Invoker Onboarding]
2. Publish Service API at CCF:
* Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
* body [service api description] with apiName **service_1**
* include [vendor specific service] in root of [service api description].
* include [vendor specific aef profile] in one AEFProfile inside aefProfiles key.
* supportedFeatures **100**
* Use **APF Certificate**
3. Request Discover Published APIs:
* Send **GET** to **https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=0**
* Param api-invoker-id is mandatory
* Use **Invoker Certificate**
**Expected Result**:
1. Response to Publish request must accomplish:
1. **201 Created**
2. Response Body must follow **ServiceAPIDescription** data structure with:
* apiId
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}**
4. Response must include **"vendorSpecific"** keys inside root and at AEF Profile.
2. Response to Onboard request must accomplish:
1. **201 Created**
2. Response Body must follow **APIInvokerEnrolmentDetails** data structure with:
* apiInvokerId
* onboardingInformation->apiInvokerCertificate must contain the public key signed.
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}**
3. Response to Discover Request By Invoker:
1. **404 Not Found** response.
2. Error Response Body must accomplish with **ProblemDetails** data structure with:
* status 404
* title with message "Not Found"
* detail with message "API Invoker {api_invoker_id} has no API Published that accomplish filter conditions".
* cause with message "No API Published accomplish filter conditions".
## Test Case 3: Publish API with vendorExt active and discover without supported features filter
**Test ID**: ***vendor_extensibility-3***
**Description**:
This test case will check if a published API with vendor extensions can be discovered by invoker but without verdorSpecific parameters if supported-features query parameter is not set properly
**Pre-Conditions**:
* Network App was registered previously
* Network App was onboarded previously with {onboardingId}
**Execution Steps**:
1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
1. Supported Features with vendorExt flag active (binary 1 0000 0000 -> string **100**)
2. This API includes "Vendor Specific" information at **service API Description** and inside **AEF Profile**.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
**Information of Test**:
1. Perform [Provider Registration] and [Invoker Onboarding]
2. Publish Service API at CCF:
* Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
* body [service api description] with apiName **service_1**
* include [vendor specific service] in root of [service api description].
* include [vendor specific aef profile] in one AEFProfile inside aefProfiles key.
* supportedFeatures **100**
* Use **APF Certificate**
3. Request Discover Published APIs:
* Send **GET** to **https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}**
* Param api-invoker-id is mandatory
* Use **Invoker Certificate**
**Expected Result**:
1. Response to Publish request must accomplish:
1. **201 Created**
2. Response Body must follow **ServiceAPIDescription** data structure with:
* apiId
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}**
4. Response must include **"vendorSpecific"** keys inside root and at AEF Profile.
2. Response to Onboard request must accomplish:
1. **201 Created**
2. Response Body must follow **APIInvokerEnrolmentDetails** data structure with:
* apiInvokerId
* onboardingInformation->apiInvokerCertificate must contain the public key signed.
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}**
3. Response to Discover Request By Invoker:
1. **200 OK** response.
2. Response body must follow **DiscoveredAPIs** data structure:
* Check if DiscoveredAPIs contains the API Published previously
* Check **NOT** contains the **vendorSpecific** keys
## Test Case 4: Publish API with vendorExt active but without vendorSpecifics
**Test ID**: ***vendor_extensibility-4***
**Description**:
This test case will check if a published API with vendorExt flag active and without vendorSpecific gets a 400 Bad Request, because is not allowed by definition.
**Pre-Conditions**:
* Network App was registered previously
* Network App was onboarded previously with {onboardingId}
**Execution Steps**:
1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
1. Supported Features with vendorExt flag active (binary 1 0000 0000 -> string **100**)
2. This API **NOT** includes any "Vendor Specific" information.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
**Information of Test**:
1. Perform [Provider Registration] and [Invoker Onboarding]
2. Publish Service API at CCF:
* Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
* body [service api description] with apiName **service_1**
* **NOT INCLUDED** [vendor specific service] in root of [service api description].
* **NOT INCLUDED** [vendor specific aef profile] in one AEFProfile inside aefProfiles key.
* supportedFeatures **100**
* Use **APF Certificate**
**Expected Result**:
1. Response to Publish request must accomplish:
1. **400 Bad Request**
2. Error Response Body must accomplish with **ProblemDetails** data structure with:
* status 400
* title with message "Bad Request"
* detail with message "VendorExt feature active at Supported Features but VendorSpecifics parameters not published".
* cause with message "VendorExt feature active but vendorSpecifics not present".
## Test Case 5: Publish API with vendorExt inactive but with vendorSpecifics
**Test ID**: ***vendor_extensibility-5***
**Description**:
This test case will check if a published API with vendorExt flag inactive and with vendorSpecific gets a 400 Bad Request, because is not allowed by definition.
**Pre-Conditions**:
* Network App was registered previously
* Network App was onboarded previously with {onboardingId}
**Execution Steps**:
1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
1. Supported Features with vendorExt flag active (binary 0 0000 0000 -> string **000**)
2. This API includes any "Vendor Specific" information.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
**Information of Test**:
1. Perform [Provider Registration] and [Invoker Onboarding]
2. Publish Service API at CCF:
* Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
* body [service api description] with apiName **service_1**
* include [vendor specific service] in root of [service api description].
* include [vendor specific aef profile] in one AEFProfile inside aefProfiles key.
* supportedFeatures **000**
* Use **APF Certificate**
**Expected Result**:
1. Response to Publish request must accomplish:
1. **400 Bad Request**
2. Error Response Body must accomplish with **ProblemDetails** data structure with:
* status 400
* title with message "Bad Request"
* detail with message "VendorExt feature inactive at Supported Features but VendorSpecifics are present parameters published".
* cause with message "VendorExt feature inactive but vendorSpecifics present".
## Test Case 6: Published API without vendor extensibility discover with VendSpecQueryParams enabled
**Test ID**: ***vendor_extensibility-6***
**Description**:
This test case will check if a published API with vendorExt flag inactive and vendorSpecific no presnet, but discovered filter only APIs with vendorSpecific parameter
**Pre-Conditions**:
* Network App was registered previously
* Network App was onboarded previously with {onboardingId}
**Execution Steps**:
1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
1. Supported Features with vendorExt flag active (binary 0 0000 0000 -> string **000**)
2. This API **NOT** includes "Vendor Specific" information at **service API Description** and inside **AEF Profile**.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
1. Supported-features: binary 010 -> string 2
**Information of Test**:
1. Perform [Provider Registration] and [Invoker Onboarding]
2. Publish Service API at CCF:
* Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
* body [service api description] with apiName **service_1**
* **NOT INCLUDED** [vendor specific service] in root of [service api description].
* **NOT INCLUDED** [vendor specific aef profile] in one AEFProfile inside aefProfiles key.
* supportedFeatures **000**
* Use **APF Certificate**
3. Request Discover Published APIs:
* Send **GET** to **https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=2**
* Param api-invoker-id is mandatory
* Use **Invoker Certificate**
**Expected Result**:
1. Response to Publish request must accomplish:
1. **201 Created**
2. Response Body must follow **ServiceAPIDescription** data structure with:
* apiId
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}**
4. Response must NOT include any **"vendorSpecific"** keys inside root and at AEF Profile.
2. Response to Onboard request must accomplish:
1. **201 Created**
2. Response Body must follow **APIInvokerEnrolmentDetails** data structure with:
* apiInvokerId
* onboardingInformation->apiInvokerCertificate must contain the public key signed.
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}**
3. Response to Discover Request By Invoker:
1. **404 Not Found** response.
2. Error Response Body must accomplish with **ProblemDetails** data structure with:
* status 404
* title with message "Not Found"
* detail with message "API Invoker {api_invoker_id} has no API Published that accomplish filter conditions".
* cause with message "No API Published accomplish filter conditions".
## Test Case 7: Published API without vendor extensibility and discover with vendSpecQueryParams disabled
**Test ID**: ***vendor_extensibility-7***
**Description**:
This test case will check if a published API with vendorExt flag inactive and no vendorSpecific, can be discovered by invoker filtering by vendSpecQueryParams.
**Pre-Conditions**:
* Network App was registered previously
* Network App was onboarded previously with {onboardingId}
**Execution Steps**:
1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
1. Supported Features with vendorExt flag active (binary 0 0000 0000 -> string **00**)
2. This API **NOT** includes any "Vendor Specific" information at **service API Description** and inside **AEF Profile**.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
1. includes **supported-features** with VendSpecQueryParams active (binary 000 -> string **0**)
**Information of Test**:
1. Perform [Provider Registration] and [Invoker Onboarding]
2. Publish Service API at CCF:
* Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
* body [service api description] with apiName **service_1**
* **NOT INCLUDE** [vendor specific service] in root of [service api description].
* **NOT INCLUDE** [vendor specific aef profile] in one AEFProfile inside aefProfiles key.
* supportedFeatures **000**
* Use **APF Certificate**
3. Request Discover Published APIs:
* Send **GET** to **https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}&supported-features=0**
* Param api-invoker-id is mandatory
* Use **Invoker Certificate**
**Expected Result**:
1. Response to Publish request must accomplish:
1. **201 Created**
2. Response Body must follow **ServiceAPIDescription** data structure with:
* apiId
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}**
4. Response must **NOT** include **"vendorSpecific"** keys inside root and at AEF Profile.
2. Response to Onboard request must accomplish:
1. **201 Created**
2. Response Body must follow **APIInvokerEnrolmentDetails** data structure with:
* apiInvokerId
* onboardingInformation->apiInvokerCertificate must contain the public key signed.
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}**
3. Response to Discover Request By Invoker:
1. **200 OK** response.
2. Response body must follow **DiscoveredAPIs** data structure:
* Check if DiscoveredAPIs contains the API Published previously
* Check if **NOT** contains any **vendorSpecific** keys
## Test Case 8: Published API without vendor extensibility and discover without supported-features query parameter
**Test ID**: ***vendor_extensibility-8***
**Description**:
This test case will check if a published API with vendorExt flag inactive and no vendorSpecific, can be discovered by invoker without filtering by vendSpecQueryParams.
**Pre-Conditions**:
* Network App was registered previously
* Network App was onboarded previously with {onboardingId}
**Execution Steps**:
1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF:
1. Supported Features with vendorExt flag active (binary 0 0000 0000 -> string **000**)
2. This API **NOT** includes any "Vendor Specific" information at **service API Description** and inside **AEF Profile**.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
1. **NOT** includes **supported-features**
**Information of Test**:
1. Perform [Provider Registration] and [Invoker Onboarding]
2. Publish Service API at CCF:
* Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
* body [service api description] with apiName **service_1**
* **NOT INCLUDE** [vendor specific service] in root of [service api description].
* **NOT INCLUDE** [vendor specific aef profile] in one AEFProfile inside aefProfiles key.
* supportedFeatures **000**
* Use **APF Certificate**
3. Request Discover Published APIs:
* Send **GET** to **https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id=${aefId}**
* Param api-invoker-id is mandatory
* Use **Invoker Certificate**
**Expected Result**:
1. Response to Publish request must accomplish:
1. **201 Created**
2. Response Body must follow **ServiceAPIDescription** data structure with:
* apiId
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/published-apis/v1/{apfId}/service-apis/{serviceApiId}**
4. Response must **NOT** include **"vendorSpecific"** keys inside root and at AEF Profile.
2. Response to Onboard request must accomplish:
1. **201 Created**
2. Response Body must follow **APIInvokerEnrolmentDetails** data structure with:
* apiInvokerId
* onboardingInformation->apiInvokerCertificate must contain the public key signed.
3. Response Header **Location** must be received with URI to new resource created, following this structure: **{apiRoot}/api-invoker-management/{apiVersion}/onboardedInvokers/{onboardingId}**
3. Response to Discover Request By Invoker:
1. **200 OK** response.
2. Response body must follow **DiscoveredAPIs** data structure:
* Check if DiscoveredAPIs contains the API Published previously
* Check if **NOT** contains any **vendorSpecific** keys
## Test Case 9: Publish API without supportedFeatures
**Test ID**: ***vendor_extensibility-9***
**Description**:
This test case will check if a published API without supportedFeatures receives the 400 Bad Request, because is not allowed by definition.
**Pre-Conditions**:
* Network App was registered previously
* Network App was onboarded previously with {onboardingId}
**Execution Steps**:
1. Register Provider at CCF, store certificates.
2. Publish Service API at CCF.
3. Register Invoker and Onboard Invoker at CCF
4. Discover Service APIs by Invoker
**Information of Test**:
1. Perform [Provider Registration] and [Invoker Onboarding]
2. Publish Service API at CCF:
* Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
* body [service api description] with apiName **service_1**
* **without supportedFeatures parameter.**
* Use **APF Certificate**
**Expected Result**:
1. Response to Publish request must accomplish:
1. **400 Bad Request**
2. Error Response Body must accomplish with **ProblemDetails** data structure with:
* status 400
* title with message "Bad Request"
* detail with message "supportedFeatures must be present in this request".
* cause with message "supportedFeatures missed".
[service api description]: ../api_publish_service/service_api_description_post_example.json "Service API **Description** Request"
[publisher register body]: ../api_publish_service/publisher_register_body.json "Publish register Body"
[invoker onboarding body]: ../api_invoker_management/invoker_details_post_example.json "API Invoker Request"
[provider request body]: ../api_provider_management/provider_details_post_example.json "API Provider Enrolment Request"
[provider request patch body]: ../api_provider_management/provider_details_enrolment_details_patch_example.json "API Provider Enrolment Patch Request"
[invoker onboarding]: ../common_operations/README.md#onboard-an-invoker "Invoker Onboarding"
[provider registration]: ../common_operations/README.md#register-a-provider "Provider Registration"
[vendor specific service]: ./vendor_specific_service.json "Vendor Specific Service"
[vendor specific aef profile]: ./vendor_specific_aef_profile.json "Vendor Specific AEF Profile"
{
"vendorSpecific-urn:etsi:mec:capifext:transport-info": {
"name": "trasport1",
"description": "Transport Info 1",
"type": "REST_HTTP",
"protocol": "HTTP",
"version": "2",
"security": {
"grantTypes": "OAUTH2_CLIENT_CREDENTIALS",
"tokenEndpoint": "https://token-endpoint/"
}
}
}
\ No newline at end of file
{
"vendorSpecific-urn:etsi:mec:capifext:service-info": {
"serializer": "JSON",
"state": "ACTIVE",
"scopeOfLocality": "MEC_SYSTEM",
"consumedLocalOnly": "True",
"isLocal": "True",
"category": {
"href": "https://www.location.com",
"id": "location_1",
"name": "Location",
"version": "1.0"
}
}
}
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment