This type of operation is generally used in SU listeners on deploy and start. Adding such retry feature means that it must be an asynchronous task and really need more work on the CDK by introducing this asynchronous aspect on the SU manager with callback handlers.
On the other side, a native support of such things (out of SU scope) is potentially a good idea but the CDK also need many work for that; I suggest that we postpone this issue for a future major version of the CDK.
For now (and since the notification is not part of the core CDK API), by getting a reference to AbstractComponent, ones can get the NotificationService instance and get the Sender which can be used as communication channel between the component and the notification layer by abstracting the JBI world.
Improvement Request
Resolved
Major
This type of operation is generally used in SU listeners on deploy and start. Adding such retry feature means that it must be an asynchronous task and really need more work on the CDK by introducing this asynchronous aspect on the SU manager with callback handlers.
On the other side, a native support of such things (out of SU scope) is potentially a good idea but the CDK also need many work for that; I suggest that we postpone this issue for a future major version of the CDK.
For now (and since the notification is not part of the core CDK API), by getting a reference to AbstractComponent, ones can get the NotificationService instance and get the Sender which can be used as communication channel between the component and the notification layer by abstracting the JBI world.