Inconsistant problem in the automatic link creation

[PrathibaJee]

In all the TAC application , the response of the "/v1/regard-application" depends on the result of the neccesary link creations. For example , in the EATL application ,

/v1/regard-application()
{
    Step 1: creates tcp, http , operation client stack for the newly regarded application
    Step 2: creates link for the "/v1/redirect-service-request-information" API between the server(NewApp) and the client(EATL)
    Wait().... until a new operation-key is received for the "NewApp:/v1/redirect-service-request-information" operation-client in the EATL application
    Step 3: Performs the API call "NewApp:/v1/redirect-service-request-information"
+  Note : If the NewApp:/v1/redirect-service-request-information makes a change in the http-client instance , then ALT://v1/update-ltp will also be triggered.
    Step 4: Creates link for the "/v1/record-service-request" API between the server(EATL) and the client(NewApp)
-  Note : Link creation will be successful if and only if the http-server of the serving application and the http-client of the consuming application is same.
    Step 5: Send response to the requestor
}

Potential problem : link creation will not be successful if the callback(ALT://v1/update-ltp) of "newApplicationName://v1/redirect-service-request-information" is not completed its job before the link creation.

Example in the below sequence diagram ,

[openBackhaul]

I confirm the existence of the problem. As long as there is no HttpClient for EATLv2.1.0 at the documentation of the newApp inside ALT, it is not feasible to create a link between EATLv2.1.0://v1/record-service-request and the newApp.

I don't see any event that is sensed by EATL and could be used as a trigger for creating that link.

Two workarounds could potentially be applied:

• A delay time could be added between EATL addressing newApp://v1/redirect-service-request-information and ALT://v1/add-operation-client-to-link{eatl://v1/record-service-request}
• The connecting process (or parts of it) could be repeated (once), if the ALT://v1/add-operation-client-to-link{eatl://v1/record-service-request} is answering with 200 {client-successfully-added==false, reason-of-failure==ALT_SERVING_APPLICATION_RELEASE_NUMBER_UNKNOWN}

[PrathibaJee]

Yes , as you mentioned , EATL cannot able to sense the completion of newApp://v1/redirect-service-request-information --> ALT://v1/update-ltp before initiating the link creation between EATLv2.1.0://v1/record-service-request and the newApp.

Many thanks for the potential proposal. Kindly please find the proposal that complements your proposal,

If the link creation between "EATLv2.1.0:/v1/record-service-request" and the "newApp" fails with the reason "ALT_SERVING_APPLICATION_RELEASE_NUMBER_UNKNOWN"
then , 
a "second attempt" of the same link creation shall be made.
If the "second attempt" also failed with the same reason  "ALT_SERVING_APPLICATION_RELEASE_NUMBER_UNKNOWN"
then , 
a "third attempt" of the same link creation shall be made.

For sure before this 2 attempts the NewApp's HttpClient would have been updated in the ALT's application data. Kindly please let me know your views. Thanks.

[openBackhaul]

In the latest proposal, EATL://v1/regard-application is doing a self-call under specific error conditions. Chances of an endless loop to be checked.