Proposal to include operation-key support in GenericRepresentation GUI

[PrathibaJee]

Note : This issue is not related to ApplicationPattern , it is related to GenericRepresentation GUI.

Currently , GenericRepresentation GUI(GRGUI) requires to consume the following services to populate the list of approved applications in the dropdown while loading the initial page ,

Services and application	Reason
List-applications from RegistryOffice(RO)	To get the tcp details of the application
List-applications from TypeApprovalRegister(TAR)	To get the approval status of the application

Problem :

1. Currently the GRGUI uses the default operation-key "Operation key not yet provided." to communicate with the services in RO and TAR.
2. But , when RO and TAR connects to OperationKeyManagement(OKM) the default operation key will be changed.
3. As a result ,GRGUI will have no access to the services in the RO and TAR

Proposals :

Proposal#1 : Including only the relevant basic services to get the latest operation-key for the services in RO and TAR in GRGUI.

(Proposal#1 will not work , just documenting the findings)
Detailed proposal :

1. To receive the operation-key , GRGUI should expose the following service ,

   • /v1/update-operation-key

2. To send operation-key to the to the GRGUI , OperationKeyManagement(OKM) required the approved link details that consists of the operation-server(RO/TAR) and operation-client(GRGUI) details of the “list-application”.
   To provide this , ALT needs to be updated with the GRGUI LTP and FC details.
   So, to facilitate that , GRGUI shall expose the following basic service ,

   • /v1/redirect-topology-change-information

3. GRGUI shall include a load file that consists of the following operation-servers

   • /v1/update-operation-key
   • /v1/redirect-topology-change-information

4. GRGUI shall include a load file that consists of the LTP clients and FC related to the ALT(/v1/redirect-topology-change-information) , RO(/v1/list-application) , TAR (/v1/list-application)

5. If the RO,ALT,TAR application gets update to its service , for example , if /v1/list-application is changed to /v2/list-applications , then GRGUI requires the following services ,

   • /v1/update-operation-client

To facilitate RO to send /v1/update-operation-client , this application needs to be an approved application in the ApplicationLayer

So , without including the GRGUI as one of the Microservice to the ApplicationLayer , it is not possible to have a fail proof model to get the operation-key.

Proposal#2 : Including the complete basic services and making the GRGUI as a part of the application layer.

1. Including Rest server to the GRGUI to expose all the basic services.
2. Along with that , we have to include the “bequeath-your-data-and-die” individual service to automate the embedding process.
3. Include a load file that consists of the LTPs , FCs required to communication with all the TAC.
4. Creating a openAPI yaml file from the applicationPattern specification

Detailed proposal for this will be shared by @vanithaValluripalli .

Rough Estimation : 21 days
load file modelling 5 days
Including Rest server in the GRGUI 2 days
Creating framework file for express openapi.yaml for the basic services 2 days
Implementing and testing the Basic service from the available npm package 7 days
Implementing and testing the bequeath-your-data-and-die service 5 days

Proposal#3 : Including a proxy application that provides operation-key for the required services.

Need to brainstorm in regards to this idea.

[openBackhaul]

In regard with proposal 3:
In a comment in regards with AP issue #649 "Client location sensing for proper URI preparation at server side", it is proposed to connect all applications (including GenericRepresentationGUI) that are located outside the MW SDN MS environment via some Proxy application.
The intention behind this proposal is to simplify TCP/IP address handling.
Handling the OperationKeys could be covered, too.

In regards with proposal 2:
Since above problem statement has been formulated, the RSR application has been specified.
The RSR is placing an own little GUI module at the client side.
Potentially, the GRGUI could be designed according to the same concept.

No matter, which decision we'll take, it does not effect ApplicationPattern v2.0.2.
Consequently, I would like to move this issue into the next release.

[PrathibaJee]

No matter, which decision we'll take, it does not effect ApplicationPattern v2.0.2.
Consequently, I would like to move this issue into the next release.

Yes , as you mentioned, since the proposals are specific to GRGUI , moving this issue to next release would be fine. Thanks.