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

[PrathibaJee]

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

1. /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.
2. 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 ?

1. 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.
2. Further , the waitUntilOperationKeyIsUpdated() shall be called with operationClientUuid, timeStampOfTheRequest, waitTime(taken from the integer profile)
3. 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);

[PrathibaJee]

Issue merged to branch v2.1.1_impl as a part of the PR #967.
Hence closing this issue.