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);
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 ,
So , a generic non-blocking logic to wait for operation-key update shall be implemented in the operationClient module. This logic will have ,
How to use ?
sample code