diff options
author | Matthieu Geerebaert <matthieu.geerebaert@orange.com> | 2019-04-30 07:02:57 +0000 |
---|---|---|
committer | Gerrit Code Review <gerrit@onap.org> | 2019-04-30 07:02:57 +0000 |
commit | 4cc6d439284f5ca5ad09e14f6ac4186ca5b507e6 (patch) | |
tree | 7966c3a67ed8b96c375bc82ee3a5b73131b3550a /docs/offeredapis/offeredapis.rst | |
parent | e49da59b5e68847a83e269d988b43f863687cffc (diff) | |
parent | 7fc17ba505e7472645592b6d4ee3275e04621508 (diff) |
Merge "CCVPN (East-west Interface)"
Diffstat (limited to 'docs/offeredapis/offeredapis.rst')
-rw-r--r-- | docs/offeredapis/offeredapis.rst | 22 |
1 files changed, 22 insertions, 0 deletions
diff --git a/docs/offeredapis/offeredapis.rst b/docs/offeredapis/offeredapis.rst index ac9b486..9578a90 100644 --- a/docs/offeredapis/offeredapis.rst +++ b/docs/offeredapis/offeredapis.rst @@ -301,6 +301,28 @@ The following diagram illustrates such notification flow: .. image:: images/notification.jpg :width: 800px +**East-west interaction of ONAP instances through External API** + +Operator’s SO component will talk to service provider’s external API component through its own external API component. + +External API support two methods of posting a Service Order or registering for Hub. + +1. If the incoming request is per current implementation (no additional headers) then no changes will be made. The request will be serviced per BAU flow. +2. If the incoming request has additional *Target* header parameters, External API will identify that the request has to be relayed to another ONAP instance and route the request accordingly. + +Target parameter: The public endpoint url for target ONAP instance’s External API, for instance +http://externalDomain/nbi/api/vX + +• For posting service order and getting service order status, the request will be relayed to target (service provider’s External API) as-is. These are synchronous requests and operator’s External API will wait for response from the target and relay it back to original calling system (operator’s SO). +• For Hub API, there is an additional step required. The listener from calling system (operator’s SO) will be replaced with External APIs own listener. A mapping of registered subscriber and its original listener will be maintained in External API’s DB. Operator’s External API will relay the Hub API call to service provider’s External API. The service provider’s External API will register operator’s External API as a listener. +• After SO processing in service provider’s ONAP is completed (irrespective of status – reject, success, fail etc), service provider’s External API will notify the operator’s External API about request completion. Operator’s External API will look-up for registered subscriber and its original listener (operator’s SO) and relay the message. + +Operator’s Service Orchestrator will invoke its own External API component and add SP Partner URL in the header. After receiving an acknowledgement for Service Order request, the SO component will register with External API’s hub and provide its listener for processing callback events. + +Technical information about **East-west interaction exercise** design specification and API Flow illustration (with example messages) could be found here: + +https://wiki.onap.org/download/attachments/8227019/CCVPN%20Phase%202%20HLD.docx?api=v2 + *************** Developer Guide |