diff --git a/artifacts/CAMARA_common.yaml b/artifacts/CAMARA_common.yaml index 0fdd2c35..14364341 100644 --- a/artifacts/CAMARA_common.yaml +++ b/artifacts/CAMARA_common.yaml @@ -5,9 +5,9 @@ info: license: name: Apache 2.0 url: https://www.apache.org/licenses/LICENSE-2.0.html - version: wip + version: wip x-camara-commonalities: "0.6" - + paths: {} components: securitySchemes: @@ -76,7 +76,7 @@ components: networkAccessIdentifier: $ref: "#/components/schemas/NetworkAccessIdentifier" ipv4Address: - $ref: "#/components/schemas/DeviceIpv4Address" + $ref: "#/components/schemas/DeviceIpv4Addr" ipv6Address: $ref: "#/components/schemas/DeviceIpv6Address" minProperties: 1 @@ -102,7 +102,7 @@ components: type: string example: "123456789@example.com" - DeviceIpv4Address: + DeviceIpv4Addr: type: object description: | The device should be identified by either the public (observed) IP address and port as seen by the application server, or the private (local) and any public (observed) IP addresses in use by the device (this information can be obtained by various means, for example from some DNS servers). @@ -114,9 +114,9 @@ components: In all cases, publicAddress must be specified, along with at least one of either privateAddress or publicPort, dependent upon which is known. In general, mobile devices cannot be identified by their public IPv4 address alone. properties: publicAddress: - $ref: "#/components/schemas/SingleIpv4Address" + $ref: "#/components/schemas/SingleIpv4Addr" privateAddress: - $ref: "#/components/schemas/SingleIpv4Address" + $ref: "#/components/schemas/SingleIpv4Addr" publicPort: $ref: "#/components/schemas/Port" anyOf: @@ -126,7 +126,7 @@ components: publicAddress: "84.125.93.10" publicPort: 59765 - SingleIpv4Address: + SingleIpv4Addr: description: A single IPv4 address with no subnet mask type: string format: ipv4 @@ -234,44 +234,44 @@ components: maximum: 180 responses: -####################################################### -####################################################### -# ERROR RESPONSE SCHEMA TEMPLATE -# - Objective: Make normative error `status` and `code` values -# - Schema Template rationale: -# - The `allOf` in content.application/json.schema allows a combination of both the generic ErrorInfo schema and the specific schema for this error response, -# which validates that `status` and `code` have only the specified values. -# This `allOf` is used without discriminator because it does not imply any hierarchy between the models, just 2 schemas that must be independently validated. -####################################################### -# ErrorResponseSchema: -# ... -# content: -# application/json: -# schema: -# allOf: -# - $ref: '#/components/schemas/ErrorInfo' -# - type: object -# properties: -# status: -# enum: -# - -# code: -# enum: -# - -# - -# examples: -# ExampleKey1: -# value: -# status: -# code: -# message: -# ExampleKey2: -# value: -# status: -# code: -# message: -####################################################### -####################################################### + ####################################################### + ####################################################### + # ERROR RESPONSE SCHEMA TEMPLATE + # - Objective: Make normative error `status` and `code` values + # - Schema Template rationale: + # - The `allOf` in content.application/json.schema allows a combination of both the generic ErrorInfo schema and the specific schema for this error response, + # which validates that `status` and `code` have only the specified values. + # This `allOf` is used without discriminator because it does not imply any hierarchy between the models, just 2 schemas that must be independently validated. + ####################################################### + # ErrorResponseSchema: + # ... + # content: + # application/json: + # schema: + # allOf: + # - $ref: '#/components/schemas/ErrorInfo' + # - type: object + # properties: + # status: + # enum: + # - + # code: + # enum: + # - + # - + # examples: + # ExampleKey1: + # value: + # status: + # code: + # message: + # ExampleKey2: + # value: + # status: + # code: + # message: + ####################################################### + ####################################################### Generic400: description: Bad Request headers: @@ -510,7 +510,7 @@ components: value: status: 409 code: INCOMPATIBLE_STATE - message: A referenced resource is in an incompatible state. + message: A referenced resource is in an incompatible state. GENERIC_409_{{SPECIFIC_CODE}}: description: Specific conflict situation that is relevant in the context of the API value: @@ -803,5 +803,3 @@ components: code: TIMEOUT message: Request timeout exceeded. - - diff --git a/artifacts/Github_templates/.github/ISSUE_TEMPLATE/config.yml b/artifacts/Github_templates/.github/ISSUE_TEMPLATE/config.yml index 0067a970..d94493b5 100644 --- a/artifacts/Github_templates/.github/ISSUE_TEMPLATE/config.yml +++ b/artifacts/Github_templates/.github/ISSUE_TEMPLATE/config.yml @@ -1,6 +1,6 @@ blank_issues_enabled: true contact_links: - - name: 🗣 Subproject discussions + - name: 🗣 Subproject discussions url: https://github.com/camaraproject/Commonalities/discussions about: Please ask and answer questions here. - name: 📖 CAMARA API Design Guidelines diff --git a/artifacts/camara-cloudevents/event-subscription-template.yaml b/artifacts/camara-cloudevents/event-subscription-template.yaml index 8a48405b..8d782acb 100644 --- a/artifacts/camara-cloudevents/event-subscription-template.yaml +++ b/artifacts/camara-cloudevents/event-subscription-template.yaml @@ -14,14 +14,14 @@ info: url: https://www.apache.org/licenses/LICENSE-2.0.html version: wip x-camara-commonalities: "0.6" - + externalDocs: description: Product documentation at CAMARA - url: https://github.com/camaraproject/{apiRepository} + url: https://github.com/camaraproject/apiRepository # {apiRepository} MUST be replaced by the CAMARA Subproject Repository name where the API design based on this template is hosted. servers: - url: "{apiRoot}/api-name/vx.y" - # api-name and version should be valued accordingly to the CAMARA API versioning guidelines, e.g. for a version x.y.z, put v0.y for x=0 or just vx for x>0 in the url. + # api-name and version should be valued accordingly to the CAMARA API versioning guidelines, e.g. for a version x.y.z, put v0.y for x=0 or just vx for x>0 in the url. variables: apiRoot: default: http://localhost:9091 @@ -352,7 +352,7 @@ components: - ACCESSTOKEN - REFRESHTOKEN description: | - The type of the credential. + The type of the credential. Note: Type of the credential - MUST be set to ACCESSTOKEN for now discriminator: propertyName: credentialType @@ -924,7 +924,7 @@ components: code: INVALID_PROTOCOL message: Only HTTP is supported GENERIC_400_INVALID_CREDENTIAL: - description: Invalid sink credential type + description: Invalid sink credential type value: status: 400 code: INVALID_CREDENTIAL @@ -1046,7 +1046,8 @@ components: value: status: 403 code: PERMISSION_DENIED - message: Client does not have sufficient permissions to perform this action. + message: Client does not have sufficient permissions to perform this action. + SubscriptionPermissionDenied403: description: Client does not have sufficient permission headers: diff --git a/artifacts/notification-as-cloud-event.yaml b/artifacts/notification-as-cloud-event.yaml index f79b6d22..2093c40f 100644 --- a/artifacts/notification-as-cloud-event.yaml +++ b/artifacts/notification-as-cloud-event.yaml @@ -7,34 +7,34 @@ info: # Introduction A lot of CAMARA APIs offer the capability to API consumer to receive events. - Event data are defined in each API definition but in order to provide consistency across CAMARA APIs and to increase - interoperability we will use [cloudevents](https://cloudevents.io/) specifications. In particular, every CAMARA Event will + Event data are defined in each API definition but in order to provide consistency across CAMARA APIs and to increase + interoperability we will use [cloudevents](https://cloudevents.io/) specifications. In particular, every CAMARA Event will be defined using [cloudevents-json-format](https://github.com/cloudevents/spec/blob/main/cloudevents/formats/json-format.md) - + # Relevant terms and definitions * **Occurrence** : An "occurrence" is the capture of a statement of fact during the operation of a software system. - - * **Event**: An "event" is a data record expressing an occurrence and its context. Events are routed from an + + * **Event**: An "event" is a data record expressing an occurrence and its context. Events are routed from an event producer (the source) to interested event consumers. - - * **Producer**: The "producer" is a specific instance, process or device that creates the data structure + + * **Producer**: The "producer" is a specific instance, process or device that creates the data structure describing the CloudEvent. - - * **Source**: The "source" is the context in which the occurrence happened. In a distributed system it might - consist of multiple producers. If a source is not aware of CloudEvents, an external producer creates + + * **Source**: The "source" is the context in which the occurrence happened. In a distributed system it might + consist of multiple producers. If a source is not aware of CloudEvents, an external producer creates the CloudEvent on behalf of the source. - - * **Consumer**: A "consumer" receives the event and acts upon it. It uses the context and data to execute some + + * **Consumer**: A "consumer" receives the event and acts upon it. It uses the context and data to execute some logic, which might lead to the occurrence of new events. - - * **Data**: Domain-specific information about the occurrence (i.e. the payload). This might + + * **Data**: Domain-specific information about the occurrence (i.e. the payload). This might include information about the occurrence, details about the data that was changed, or more. - + # API Functionality - + Only one endpoint/operation is provided: `POST /your_webhook_notification_url` - This endpoint describes the event notification received on subscription listener side when the event occurred. + This endpoint describes the event notification received on subscription listener side when the event occurred. A detailed description of the event notification is provided in the [CAMARA API Event Subscription and Notification Guide](https://github.com/camaraproject/Commonalities/blob/main/documentation/CAMARA-API-Event-Subscription-and-Notification-Guide.md#3-event-notification) termsOfService: http://swagger.io/terms/ @@ -48,8 +48,8 @@ externalDocs: description: Product documentation at CAMARA url: https://github.com/camaraproject/Commonalities security: - - notificationsBearerAuth: [] - - {} + - notificationsBearerAuth: [] + - {} servers: - url: '{apiRoot}' @@ -62,14 +62,14 @@ tags: description: | Events received on subscription listener side. paths: - /your_webhook_notification_url: + /your-webhook-notification-url: post: tags: - CAMARA Cloud Event summary: "Cloud Event notification endpoint to notify consumer that statement of fact had occurred" description: | INFORMATIVE ENDPOINT: The value of this endpoint is freely declared by each client app by means of resource-based - subscription or instance-based subscription. /your_webhook_notification_url is + subscription or instance-based subscription. /your_webhook_notification_url is just a convention naming referring to an absolute URL, indeed the one indicated by API client in the triggering of the procedure (resource-based or instance-based). In this way, it represents an absolute URL, i.e.: notifications won't be sent to /event-notification/vX/your_webhook_notification_url. @@ -87,20 +87,20 @@ paths: $ref: '#/components/examples/QOS_STATUS_CHANGED_EXAMPLE' responses: - 204: + "204": description: No Content headers: x-correlator: $ref: "#/components/headers/x-correlator" - 400: + "400": $ref: "#/components/responses/Generic400" - 401: + "401": $ref: "#/components/responses/Generic401" - 403: + "403": $ref: "#/components/responses/Generic403" - 410: + "410": $ref: "#/components/responses/Generic410" - 429: + "429": $ref: "#/components/responses/Generic429" components: securitySchemes: @@ -125,7 +125,7 @@ components: message: type: string description: A human-readable description of what the event represents - + XCorrelator: type: string pattern: ^[a-zA-Z0-9-_:;.\/<>{}]{0,256}$ diff --git a/artifacts/testing/C01-device-errors.feature b/artifacts/testing/C01-device-errors.feature index f947ec5d..a3dcd23a 100644 --- a/artifacts/testing/C01-device-errors.feature +++ b/artifacts/testing/C01-device-errors.feature @@ -1,7 +1,7 @@ Feature: CAMARA Common Artifact C01 - Test scenarios for device errors CAMARA Commonalities: 0.6 - + Common error scenarios for operations with device as input either in the request body or implied from the access. @@ -18,91 +18,91 @@ Feature: CAMARA Common Artifact C01 - Test scenarios for device errors * {operationId} has to be substituted to the value of operationId for the tested operation - * {path_to_device} has to be substituted to the JSON path of the device property in the body request, typically + * {path_to_device} has to be substituted to the JSON path of the device property in the body request, typically "$.device" or "$.config.subscriptionDetail.device" for Subscription APIs # This feature file is to be used by CAMARA subproject when Common error scenarios for operations with device as input either in the request body or implied from the access. # # References to OAS spec schemas refer to schemas specified in {apiname}.yaml - # Error scenarios for management of input parameter device - - @{feature_identifier}_C01.01_device_empty - Scenario: The device value is an empty object - Given the header "Authorization" is set to a valid access token which does not identify a single device - And the request body property "{path_to_device}" is set to: {} - When the request "{operationId}" is sent - Then the response status code is 400 - And the response property "$.status" is 400 - And the response property "$.code" is "INVALID_ARGUMENT" - And the response property "$.message" contains a user friendly text - - @{feature_identifier}_C01.02_device_identifiers_not_schema_compliant - Scenario Outline: Some device identifier value does not comply with the schema - Given the header "Authorization" is set to a valid access token which does not identify a single device - And the request body property "" does not comply with the OAS schema at "" - When the request "{operationId}" is sent - Then the response status code is 400 - And the response property "$.status" is 400 - And the response property "$.code" is "INVALID_ARGUMENT" - And the response property "$.message" contains a user friendly text - - Examples: - | device_identifier | oas_spec_schema | - | {path_to_device}.phoneNumber | /components/schemas/PhoneNumber | - | {path_to_device}.ipv4Address | /components/schemas/DeviceIpv4Addr | - | {path_to_device}.ipv6Address | /components/schemas/DeviceIpv6Address | - | {path_to_device}.networkAccessIdentifier | /components/schemas/NetworkAccessIdentifier | - - # This scenario may happen e.g. with 2-legged access tokens, which do not identify a single device. - @{feature_identifier}_C01.03_device_not_found - Scenario: Some identifier cannot be matched to a device - Given the header "Authorization" is set to a valid access token which does not identify a single device - And the request body property "{path_to_device}" is compliant with the schema but does not identify a valid device - When the request "{operationId}" is sent - Then the response status code is 404 - And the response property "$.status" is 404 - And the response property "$.code" is "IDENTIFIER_NOT_FOUND" - And the response property "$.message" contains a user friendly text - - @{feature_identifier}_C01.04_unnecessary_device - Scenario: Device not to be included when it can be deduced from the access token - Given the header "Authorization" is set to a valid access token identifying a device - And the request body property "{path_to_device}" is set to a valid device - When the request "{operationId}" is sent - Then the response status code is 422 - And the response property "$.status" is 422 - And the response property "$.code" is "UNNECESSARY_IDENTIFIER" - And the response property "$.message" contains a user-friendly text - - @{feature_identifier}_C01.05_missing_device - Scenario: Device not included and cannot be deduced from the access token - Given the header "Authorization" is set to a valid access token which does not identify a single device - And the request body property "{path_to_device}" is not included - When the request "{operationId}" is sent - Then the response status code is 422 - And the response property "$.status" is 422 - And the response property "$.code" is "MISSING_IDENTIFIER" - And the response property "$.message" contains a user-friendly text - - @{feature_identifier}_C01.06_unsupported_device - Scenario: None of the provided device identifiers is supported by the implementation - Given that some types of device identifiers are not supported by the implementation - And the header "Authorization" is set to a valid access token which does not identify a single device - And the request body property "{path_to_device}" only includes device identifiers not supported by the implementation - When the request "{operationId}" is sent - Then the response status code is 422 - And the response property "$.status" is 422 - And the response property "$.code" is "UNSUPPORTED_IDENTIFIER" - And the response property "$.message" contains a user-friendly text - - # When the service is only offered to certain types of devices or subscriptions, e.g. IoT, B2C, etc. - @{feature_identifier}_C01.07_device_not_supported - Scenario: Service not available for the device - Given that the service is not available for all devices commercialized by the operator - And a valid device, identified by the token or provided in the request body, for which the service is not applicable - When the request "{operationId}" is sent - Then the response status code is 422 - And the response property "$.status" is 422 - And the response property "$.code" is "SERVICE_NOT_APPLICABLE" - And the response property "$.message" contains a user-friendly text +# Error scenarios for management of input parameter device + + @{feature_identifier}_C01.01_device_empty + Scenario: The device value is an empty object + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "{path_to_device}" is set to: {} + When the request "{operationId}" is sent + Then the response status code is 400 + And the response property "$.status" is 400 + And the response property "$.code" is "INVALID_ARGUMENT" + And the response property "$.message" contains a user friendly text + + @{feature_identifier}_C01.02_device_identifiers_not_schema_compliant + Scenario Outline: Some device identifier value does not comply with the schema + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "" does not comply with the OAS schema at "" + When the request "{operationId}" is sent + Then the response status code is 400 + And the response property "$.status" is 400 + And the response property "$.code" is "INVALID_ARGUMENT" + And the response property "$.message" contains a user friendly text + + Examples: + | device_identifier | oas_spec_schema | + | {path_to_device}.phoneNumber | /components/schemas/PhoneNumber | + | {path_to_device}.ipv4Address | /components/schemas/DeviceIpv4Addr | + | {path_to_device}.ipv6Address | /components/schemas/DeviceIpv6Address | + | {path_to_device}.networkAccessIdentifier | /components/schemas/NetworkAccessIdentifier | + + # This scenario may happen e.g. with 2-legged access tokens, which do not identify a single device. + @{feature_identifier}_C01.03_device_not_found + Scenario: Some identifier cannot be matched to a device + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "{path_to_device}" is compliant with the schema but does not identify a valid device + When the request "{operationId}" is sent + Then the response status code is 404 + And the response property "$.status" is 404 + And the response property "$.code" is "IDENTIFIER_NOT_FOUND" + And the response property "$.message" contains a user friendly text + + @{feature_identifier}_C01.04_unnecessary_device + Scenario: Device not to be included when it can be deduced from the access token + Given the header "Authorization" is set to a valid access token identifying a device + And the request body property "{path_to_device}" is set to a valid device + When the request "{operationId}" is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNNECESSARY_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + @{feature_identifier}_C01.05_missing_device + Scenario: Device not included and cannot be deduced from the access token + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "{path_to_device}" is not included + When the request "{operationId}" is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "MISSING_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + @{feature_identifier}_C01.06_unsupported_device + Scenario: None of the provided device identifiers is supported by the implementation + Given that some types of device identifiers are not supported by the implementation + And the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "{path_to_device}" only includes device identifiers not supported by the implementation + When the request "{operationId}" is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNSUPPORTED_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + # When the service is only offered to certain types of devices or subscriptions, e.g. IoT, B2C, etc. + @{feature_identifier}_C01.07_device_not_supported + Scenario: Service not available for the device + Given that the service is not available for all devices commercialized by the operator + And a valid device, identified by the token or provided in the request body, for which the service is not applicable + When the request "{operationId}" is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "SERVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user-friendly text diff --git a/artifacts/testing/C02-phoneNumber-errors.feature b/artifacts/testing/C02-phoneNumber-errors.feature index 8330523b..690443d3 100644 --- a/artifacts/testing/C02-phoneNumber-errors.feature +++ b/artifacts/testing/C02-phoneNumber-errors.feature @@ -18,62 +18,63 @@ Feature: CAMARA Common Artifact C02 - Test scenarios for phoneNumber errors * {operationId} has to be substituted to the value of operationId for the tested operation - * {path_to_phoneNumber} has to be substituted to the JSON path of the phoneNumber property in the body request, typically + * {path_to_phoneNumber} has to be substituted to the JSON path of the phoneNumber property in the body request, typically "$.phoneNumber" or "$.config.subscriptionDetail.phoneNumber" for Subscription APIs # This feature file is to be used by CAMARA subproject when Common error scenarios for operations with phoneNumber as input either in the request body or implied from the access # # References to OAS spec schemas refer to schemas specified in {apiname}.yaml - # Error scenarios for management of input parameter phoneNumber + # Error scenarios for management of input parameter phoneNumber - @{feature_identifier}_C02.01_phone_number_not_schema_compliant - Scenario: Phone number value does not comply with the schema - Given the header "Authorization" is set to a valid access token which does not identify a single phone number - And the request body property "{path_to_phoneNumber}" does not comply with the OAS schema at "/components/schemas/PhoneNumber" - When the request "{operationId}" is sent - Then the response status code is 400 - And the response property "$.status" is 400 - And the response property "$.code" is "INVALID_ARGUMENT" - And the response property "$.message" contains a user friendly text + @{feature_identifier}_C02.01_phone_number_not_schema_compliant + Scenario: Phone number value does not comply with the schema + Given the header "Authorization" is set to a valid access token which does not identify a single phone number + And the request body property "{path_to_phoneNumber}" does not comply with the OAS schema at "/components/schemas/PhoneNumber" + When the request "{operationId}" is sent + Then the response status code is 400 + And the response property "$.status" is 400 + And the response property "$.code" is "INVALID_ARGUMENT" + And the response property "$.message" contains a user friendly text - @{feature_identifier}_C02.02_phone_number_not_found - Scenario: Phone number not found - Given the header "Authorization" is set to a valid access token which does not identify a single phone number - And the request body property "{path_to_phoneNumber}" is compliant with the schema but does not identify a valid phone number - When the request "{operationId}" is sent - Then the response status code is 404 - And the response property "$.status" is 404 - And the response property "$.code" is "IDENTIFIER_NOT_FOUND" - And the response property "$.message" contains a user friendly text + @{feature_identifier}_C02.02_phone_number_not_found + Scenario: Phone number not found + Given the header "Authorization" is set to a valid access token which does not identify a single phone number + And the request body property "{path_to_phoneNumber}" is compliant with the schema but does not identify a valid phone number + When the request "{operationId}" is sent + Then the response status code is 404 + And the response property "$.status" is 404 + And the response property "$.code" is "IDENTIFIER_NOT_FOUND" + And the response property "$.message" contains a user friendly text - @{feature_identifier}_C02.03_unnecessary_phone_number - Scenario: Phone number not to be included when it can be deduced from the access token - Given the header "Authorization" is set to a valid access token identifying a phone number - And the request body property "{path_to_phoneNumber}" is set to a valid phone number - When the request "{operationId}" is sent - Then the response status code is 422 - And the response property "$.status" is 422 - And the response property "$.code" is "UNNECESSARY_IDENTIFIER" - And the response property "$.message" contains a user friendly text + @{feature_identifier}_C02.03_unnecessary_phone_number + Scenario: Phone number not to be included when it can be deduced from the access token + Given the header "Authorization" is set to a valid access token identifying a phone number + And the request body property "{path_to_phoneNumber}" is set to a valid phone number + When the request "{operationId}" is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNNECESSARY_IDENTIFIER" + And the response property "$.message" contains a user friendly text - @{feature_identifier}_C02.04_missing_phone_number - Scenario: Phone number not included and cannot be deducted from the access token - Given the header "Authorization" is set to a valid access token which does not identify a single phone number - And the request body property "{path_to_phoneNumber}" is not included - When the request "{operationId}" is sent - Then the response status code is 422 - And the response property "$.status" is 422 - And the response property "$.code" is "MISSING_IDENTIFIER" - And the response property "$.message" contains a user friendly text + @{feature_identifier}_C02.04_missing_phone_number + Scenario: Phone number not included and cannot be deducted from the access token + Given the header "Authorization" is set to a valid access token which does not identify a single phone number + And the request body property "{path_to_phoneNumber}" is not included + When the request "{operationId}" is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "MISSING_IDENTIFIER" + And the response property "$.message" contains a user friendly text + + # When the service is only offered to certain type of subscriptions, e.g. IoT, , B2C, etc + @{feature_identifier}_C02.05_phone_number_not_supported + Scenario: Service not available for the phone number + Given that the service is not available for all phone numbers commercialized by the operator + And a valid phone number, identified by the token or provided in the request body, for which the service is not applicable + When the request "{operationId}" is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "SERVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user friendly text - # When the service is only offered to certain type of subscriptions, e.g. IoT, , B2C, etc - @{feature_identifier}_C02.05_phone_number_not_supported - Scenario: Service not available for the phone number - Given that the service is not available for all phone numbers commercialized by the operator - And a valid phone number, identified by the token or provided in the request body, for which the service is not applicable - When the request "{operationId}" is sent - Then the response status code is 422 - And the response property "$.status" is 422 - And the response property "$.code" is "SERVICE_NOT_APPLICABLE" - And the response property "$.message" contains a user friendly text