To make the ApprovingApplicationCausesPreparingTheEmbedding sequence backward compatible

[PrathibaJee]

In the version 2.1.0 of RegistryOffice, there is an ApprovingApplicationCausesPreparingTheEmbedding sequence.

This ApprovingApplicationCausesPreparingTheEmbedding sequence will work only if, the new approved application supports the API /v1/inform-about-preceding-application + its old version supports the API /v1/update-client-of-subsequent-release

In negative case , the following consequence will happen in the ApprovingApplicationCausesPreparingTheEmbedding sequence ,

ApprovingApplicationCausesPreparingTheEmbedding.CreateLinkToGetOldRelease
-    link creation will fail if "/v1/inform-about-preceding-application" is not available in the new application which is running in version < 2.1.0

ApprovingApplicationCausesPreparingTheEmbedding.RequestForOldRelease
-    API call will fail because "/v1/inform-about-preceding-application" is not available in the new application which is running in version < 2.1.0

ApprovingApplicationCausesPreparingTheEmbedding.CreateLinkToUpdateNewReleaseClient
-    link creation will fail if "/v1/update-client-of-subsequent-release" is not available in the old version of the new application which is running in version < 2.1.0

ApprovingApplicationCausesPreparingTheEmbedding.RequestForUpdatingNewReleaseClient
-    API call will fail because "/v1/update-client-of-subsequent-release" is not available in the old version of the new application which is running in version < 2.1.0

ApprovingApplicationCausesPreparingTheEmbedding.CreateLinkForPromptingEmbedding
+    will work fine even if the application is running in version < 2.1.0

ApprovingApplicationCausesPreparingTheEmbedding.CreateLinkForBequeathYourData
-    will not work if the old release application detail is not known if "/v1/inform-about-preceding-application" is not available in the new application.

ApprovingApplicationCausesPreparingTheEmbedding.CreateFurtherLinksForTransferringData
-    will fail if the ApprovingApplicationCausesPreparingTheEmbedding.RequestForUpdatingNewReleaseClient fails to get the list of data transfer operation-names

ApprovingApplicationCausesPreparingTheEmbedding.RequestForEmbedding
+    will work fine even if the application is running in version < 2.1.0

Proposal :

Proposing the following to make this ApprovingApplicationCausesPreparingTheEmbedding sequence backward compatible ,

The sequence that deals with the new APIs "/v1/inform-about-preceding-application", "/v1/update-client-of-subsequent-release" shall be liberal for this RegistryOffice version 2.1.0 , then later in version 3.0.0 this exception shall be revoked. (a sample idea is as below)

ApprovingApplicationCausesPreparingTheEmbedding.CreateLinkToGetOldRelease
-        If link creation fails , then 
+        we shall consider that the "/v1/inform-about-preceding-application" is not available in the new release. So , we shall also skip performing the forwardings , 
+        RequestForOldRelease ( call to /v1/inform-about-preceding-application)
+        CreateLinkToUpdateNewReleaseClient ( since we dont know the old-release , we cannot address the correct instance)
+        RequestForUpdatingNewReleaseClient (same as above)
+        CreateLinkForBequeathYourData (same as above)
+        CreateFurtherLinksForTransferringData (same as above)

ApprovingApplicationCausesPreparingTheEmbedding.RequestForOldRelease

ApprovingApplicationCausesPreparingTheEmbedding.CreateLinkToUpdateNewReleaseClient
-       If link creation fails , 
+       then we shall consider that the "/v1/update-client-of-subsequent-release" is not available in the old release.So , we shall also skip performing the forwardings , 
+       RequestForUpdatingNewReleaseClient ( call to /v1/update-client-of-subsequent-release)
+       CreateFurtherLinksForTransferringData (since we didn't perform /v1/update-client-of-subsequent-release , we will not have the list of new-release's operation-name )

ApprovingApplicationCausesPreparingTheEmbedding.RequestForUpdatingNewReleaseClient

ApprovingApplicationCausesPreparingTheEmbedding.CreateLinkForPromptingEmbedding
+      will work fine even if the application is running in version < 2.1.0

ApprovingApplicationCausesPreparingTheEmbedding.CreateLinkForBequeathYourData

ApprovingApplicationCausesPreparingTheEmbedding.CreateFurtherLinksForTransferringData

ApprovingApplicationCausesPreparingTheEmbedding.RequestForEmbedding
+      will work fine even if the application is running in version < 2.1.0

[openBackhaul]

Finding during common call:

• Forwarding ApprovingApplicationCausesPreparingTheEmbedding.CreateLinkToUpdateNewReleaseClient will lead to termination of the automated embedding process for the entire installed base of applications
• Even repeatedly initiating newApplication://register-yourself will never lead to RO requesting newApplication://embed-yourself
• Instead of changing the process, links shall be created manually and also newApplication://embed-yourself shall be initiated manually
• Downside:
  • The automated embedding process writes its result into the TAR
  • The embedding status in TAR needs to be corrected manually, in case of manual embedding.

Results:

• This issues to be closed without any change to RO.
• Updating the embedding status to be facilitated via GUI in TAR, covered by TAR issue#299.

[PrathibaJee]

Many thanks for the details. Yes , there won’t be any changes required in the RegistryOffice. If there is a problem occurs in the embedding sequence , then that problem will be reported to TypeApprovalRegistry. After manually resolving the problem , manually the embedding status shall be updated by an administrator by using the new feature defined in the TAR issue https://github.com/openBackhaul/TypeApprovalRegister/issues/299. Hence closing this issue.