Clarification regarding ApprovingApplicationCausesPreparingTheEmbedding.RequestForOldRelease

[PrathibaJee]

We have two initiating request for this ApprovingApplicationCausesPreparingTheEmbedding.RequestForOldRelease callback. initiating-requests:

• server-name: /v1/regard-updated-approval-status uuid: ro-2-1-0-op-s-is-003
• server-name: /v1/update-operation-key uuid: ro-2-1-0-op-s-bm-010

But , as per the concept , /v1/update-operation-key(ro-2-1-0-op-s-bm-010) only will be the initiating request for this forwarding.

Clarification required : I think , /v1/regard-updated-approval-status(ro-2-1-0-op-s-is-003) is included because , the major API that initiates the ApprovingApplicationCausesPreparingTheEmbedding forwarding is this API and that’s the reason for the inclusion of this API as an initiating request.

Kindly please let me know whether this understanding is correct. (Also the same doubt applicable for the RequestForUpdatingNewReleaseClient forwarding)

[openBackhaul]

In AP_v2.1.0_spec, the AP://v1/inform-about-preceding-release had a security: apiKeyAuth statement. In RO_v2.1.0_spec, The ApprovingApplicationCausesPreparingTheEmbedding process had a CreateLinkToGetOldRelease forwarding before the RequestForOldRelease forwarding. So, it made sense to wait for RO://v1/update-operation-key providing the correct OperationKey for addressing AP://v1/inform-about-preceding-release.

In AP_v2.1.1_spec, it has been decided to remove the security: apiKeyAuth statement from AP://v1/inform-about-preceding-release according to AP issue#934. The CreateLinkToGetOldRelease forwarding has been removed from the ApprovingApplicationCausesPreparingTheEmbedding process. No, OperationKey will be provided via RO://v1/update-operation-key. Consequently, it can no longer be an initiating-requests and has been removed from the ForwardingList and the CONFIGfile.