Page Comparison

...

In MDONS use case,  the domain OTN service activation sometime could happen in hours, even days, after the service is created in case of OpenRoadM OTN service creation.  Flow steps are the following:

1.   Notification callback URL is usually provided as input of service creation request. 
2.   Upon service activation successful, a notification will be sent back to SDNC from SB domain controller by calling an appropriate DG
3.   The DG will call an SO API to update the status of the corresponding L1 Access Service for SO to complete the OTN service creation flow. 

Async Flow 

Async response for MDONS service creation is applicable when we create a MSA based OTN service using Open ROADM NEs. In this case, after service creation is successful in domain controller and the Sync Response is received in SO BPMN, SO waits for Async response from domain controller/SDNC.

The following URL is exposed by SO for receiving Async notifications:

http://so-bpmn-infra.onap:8081/mso/async/services/updateStatus

The JSON format to be used in POST request is

      {
      "request-id":"abfcf8f5-1123-4870-b0bc-d4d21b03a9fa",
      "response-code":"200",
      "response-message":"SUCCESS",
      "ack-final-indicator":"Y"
      }

Once this response is received, SO performs the following:

1. If response-code is 200, the CREATE service request in request DB table is updated as SUCCESS and progress as 100.
2. If response-code is not 200, the CREATE service request in request DB table is updated as FAILED.
3. If DB update is success, then response code 200 is sent to calling SDNC process.
4. If DB update is failure or any exception occurs during update, then response code 500 is sent to calling SDNC process.
5. Once the result is updated in request DB, the UUI which monitors the table gets updated as success/failure.

SDNC

The DG and notification call back handling in SDNC has already been supported in Frankfurt release. Modification in optical-package as well as in DGs are needed in G Release.

The Async notification is received in SDNC when the service is successfully activated in from domain controller and then SDNC passes it the notification to SO. 

For thsthis, we can use URL for POST: https://<SNDC Public IP>:30267/asyncNotification

The JSON format required for posting in this URL is as below:

      {
      "input":{
      "configuration-response-common":{
           "svc-request-id":"d33e2d45-3ee0-486f-af6e-1caf42db0aa7",
           "response-code":"200",
           "ack-final-indicator":"Y"
            },
      "service-identifiers":{
            "service-name":"async1_MDONS-OTN_Virtuora-MSA",
            "common-id":"abfcf8f5-1123-4870-b0bc-d4d21b03a9fa"
             }
        }
     }

...

The DG and notification call back handing in SDNC has already been supported in Frankfurt release. Modification in optical-package as well as in DGs are needed in G Release.

SO

An asynchronous call back SO Rest API needs to be added to support such functionality if the existing SO Rest API does not support MDONS.

The following URL is exposed by SO for receiving Async notifications:

http://so-bpmn-infra.onap:8081/mso/async/services/updateStatus

The JSON format to be used in POST request is

      {
      "request-id":"abfcf8f5-1123-4870-b0bc-d4d21b03a9fa",
      "response-code":"200",
      "response-message":"SUCCESS",
      "ack-final-indicator":"Y"
      }

Once this response is received, SO performs the following:

1. If response-code is 200, the CREATE service request in request DB table is updated as SUCCESS and progress as 100.
2. If response-code is not 200, the CREATE service request in request DB table is updated as FAILED.
3. If DB update is success, then response code 200 is sent to calling SDNC process.
4. If DB update is failure or any exception occurs during update, then response code 500 is sent to calling SDNC process.
5. Once the result is updated in request DB, the UUI which monitors the table gets updated as success/failure.

UpdateStatus Call Back

DESCRIPTION

...