Clarification regarding the callback ApprovalNotification

[PrathibaJee]

we have the forwarding ApprovalNotification (to broadcast approval) which is marked as deprecated and will be removed in version 3.0.0.

In the version 2.1.0 of RegistryOffice, there is an ApprovingApplicationCausesConnectingWith sequence. In this ApprovingApplicationCausesConnectingWith forwardings ,
the new approved application will be connected to ALT , OKM , EATL , AA , OL applications in a sequence.

Clarification required : Kindly please clarify ,

1. whether this "ApprovalNotification" forwarding will be performed in parallel to the ApprovingApplicationCausesConnectingWith forwarding ?
2. or we will not perform this forwarding ?

[openBackhaul]

It makes no sense to mark forwarding ApprovalNotification as deprecated.

In general, the former subscription based concept has been turned into a fixed process concept. The fixed process is covering the known applications of the TAC.

Two options: 1) The forwarding ApprovalNotification could be deleted. In regard of backward compatibility: Incoming requests at RO://v1/notify-approvals would be ignored, which doesn't matter, because all existing applications are covered by the fixed process. 2) The forwarding ApprovalNotification could be left as is, because there could be future applications that require such notification, but are not covered by the fixed process.

Deleting forwarding ApprovalNotification means also future TAC applications need to be covered by the fixed process. This would mean: No future TAC application without changing the RegistryOffice. That would be the end of modularity.

Alternative proposal: Putting the broadcast to the end of the fixed process.

Proposed changes:

• Removing all notes that are indicating live cycle state deprecated of forwarding ApprovalNotification in
  • ForwardingList
  • CONFIGfile
  • OAS
• Search and Replace of UUID from "ro-2-1-0-op-fc-is-007" to "ro-2-1-0-op-fc-is-040" in all files.
• Adding the forwarding ApprovalNotification (broadcast to all subscribers) behind forwarding ApprovingApplicationCausesConnectingWith.Ol in is010_regardApprovalStatusCausesSequence.plantuml
• Moving forwarding ApprovalNotification from behind forwarding DeregistrationNotification to behind forwarding ApprovingApplicationCausesConnectingWith.Ol in the ForwardingList
• Removing all applications that are covered by the fixed process from the forwarding ApprovalNotification in the ForwardingList
• Moving forwarding ApprovalNotification from behind forwarding DeregistrationNotification to behind forwarding ApprovingApplicationCausesConnectingWith.Ol in the CONFIGfile
• Removing all FcPorts that are connecting applications that are covered by the fixed process from the forwarding ApprovalNotification in the CONFIGfile
• Moving callback ApprovalNotification from beneath RO://v1/notify-approvals to behind ApprovingApplicationCausesConnectingWith.Ol beneath RO://v1/regard-updated-approval-status

[PrathibaJee]

Thanks for the detailed explanation. As discussed , "Alternative proposal: Putting the broadcast to the end of the fixed process." would be fine, as it supports future TinyApplicationController applications to receive notifications about the new approved applications.

[openBackhaul]

Changed as proposed in comment above.