To include a generic non-blocking logic that waits for operation-key updates

NodeJS applications run single task at a time. However , the eventloop concept of NodeJs provide options to execute multiple task with the help of libuv provided the written logics are non-blocking.

In the TAC version 2.1.1(EATL,OL,AA,ALT,OKM) , the outcome of /v1/regard-application API depends on the input received for the API /v1/update-operation-key.

For example ,

1. EATL received /v1/regard-application of a new application "NewApplication1" , "1.0.0"
2. EATL creates link for its OP-C::NewAPP:/v1/redirect-service-request-information and OP-S::NewAPP:/v1/redirect-service-request-information
3. EATL then waits to receive an operation-key for the operation-client OP-C::NewAPP:/v1/redirect-service-request-information
4. After receiving an operation-key , EATL will continue further steps and sends response back to RegisterOffice

/v1/regard-application service will be put in wait until it receives an operation-key for a specific operation-client (or) until waiting for a maximum waiting time as per the integer-profile.
Such waiting time logic in the /v1/regard-application service should not be a "blocking" one , so that NodeJS shall able process the /v1/update-operation-key to avoid a deadlock situation.

So , a generic non-blocking logic to wait for operation-key update shall be implemented in the operationClient module. This logic will have ,

Funtionalities to TURNON and OFF the notificationChannel on demand basis for performance reason
NotificationChannel for the operation-key updates : provided the notificationChannel is switchedON the operationClient uuid + timestamp of the event will be captured in this channel
Functionality that confirms whether an operation-key is received for a specific operation-client (or) the mentioned waiting time exceeded

How to use ?

For performance reason , this notification channel shall be switched ON/OFF on demand basic. here the demand will raise in the regard-application API call. So , at the starting of this API call , the turnONOperationKeyNotification() shall be called with the timeStampOfTheRequest.
Further , the waitUntilOperationKeyIsUpdated() shall be called with operationClientUuid, timeStampOfTheRequest, waitTime(taken from the integer profile)
After receiving a response from the waitUntilOperationKeyIsUpdated() , the notification channel turned on for this event shall be switchedOff by calling the turnOFFOperationKeyNotification() with the timeStampOfTheRequest.

sample code


/**
* step 1: operationClientInterface shall be imported
*/
const operationClientInterface = require('onf-core-model-ap/applicationPattern/onfModel/models/layerProtocols/OperationClientInterface');

// step 2 : a timestamp shall be created 
  let timestampOfCurrentRequest = new Date(); 
// step 3 : notification channel shall be turned ON + an identifier shall be used to handle multiple request incase
  operationClientInterface.turnONNotificationChannel(timestampOfCurrentRequest); 
// step 4 : Waiting time for receiving the operation client shall be determined from the corresponding integer profile
  let waitTime = await integerProfile.getIntegerValueForTheIntegerProfileNameAsync("maximumWaitTimeToReceiveOperationKey");
// step 5: wait until operation key is updated or until exceeding the waiting time
  let isOperationKeyUpdated = await operationClientInterface.waitUntilOperationKeyIsUpdated(operationClientUuid, timestampOfCurrentRequest, waitTime); 
// step 6: Turn OFF the notification channel
  operationClientInterface.turnOFFNotificationChannel(timestampOfCurrentRequest);

openBackhaul / ApplicationPattern

To include a generic non-blocking logic that waits for operation-key updates #966