If you want to use Open API 3.0 with HTTP/2 agents, you require an Open API profile configuration. You select the profile that you configure in the HTTP/2 Server agent configuration. In the Open API profile configuration, you import your OpenAPI specification file and view any other included files defined by the specification.
Note!
For the old Open API Profile used for the REST Server and Client agents in versions before 8.1.8.0, see /wiki/spaces/MD82/pages/3783710.
Warning!
If you have been using the Open API Profile before version 8.1.8.0 and are using OpenAPI 2.0. You must convert from OpenAPI 2.0 to OpenAPI 3.0, before using the Open API Profile from version 8.1.8.0 onwards.
Configuration Tab
Setting | Description |
---|---|
Open API file | Import the OpenAPI specification file from where the desktop client is running. Upon successful import, the contents of the file will be displayed in the box below. The Web Desktop If using the Web Desktop it is not possible to upload YAML files linked to other YAML files. |
Refreshing the content.
To refresh the content of the imported API file or the contents of other included files, the imported file will have to be imported once again.
View Included Files Tab
Setting | Description |
---|---|
Included Files | A list of files that are referenced in the imported OpenAPI specification file will be shown here. Selecting from this list will have its contents be displayed in the box below. |
Limitations
This section lists the limitations that users may encounter when using the OpenAPI profile.
OpenAPI specification schema which contains oneOf
tag will be decoded as a map instead of a UDR
In the following example, the SubscriptionData
schema contains the subscrCond
property with oneOf
tag:
Example: SubscriptionData schema contains the subscrCond with oneOf tag
SubscriptionData: description: Information of a subscription to notifications to NRF events, included in subscription requests and responses type: object required: - nfStatusNotificationUri - subscriptionId properties: nfStatusNotificationUri: type: string reqNfInstanceId: $ref: 'TS29571_CommonData.yaml#/components/schemas/NfInstanceId' subscrCond: oneOf: - $ref: '#/components/schemas/NfInstanceIdCond' - $ref: '#/components/schemas/NfInstanceIdListCond' - $ref: '#/components/schemas/NfTypeCond' - $ref: '#/components/schemas/ServiceNameCond' - $ref: '#/components/schemas/AmfCond' - $ref: '#/components/schemas/GuamiListCond' - $ref: '#/components/schemas/NetworkSliceCond' - $ref: '#/components/schemas/NfGroupCond' - $ref: '#/components/schemas/NfSetCond' - $ref: '#/components/schemas/NfServiceSetCond' - $ref: '#/components/schemas/UpfCond' - $ref: '#/components/schemas/ScpDomainCond' - $ref: '#/components/schemas/NwdafCond' - $ref: '#/components/schemas/NefCond'
The subscrCond
is a schema of NfSetCond
but it is decoded as a map with key value pair as shown below:
Example: SubscriptionData schema decoded in the APL
[openapi.issue_http.OAPI_NrfMgt.udr.SubscriptionData] nfStatusNotificationUri: http://localhost/dummy subscriptionId: 123456 subscrCond: {nfSetId=MU01}
To retrieve the value of the map, enter the following command:
string ID = mapGet((map<string, any>)subscriptionData.subscrCond, "nfSetId") debug(ID)
The debug output is as follows:
MU01