All all Configurable Services + Security Identities to be reloaded without Execution Group restart.

Idea / RFE Review. Support in this area has evolved further since the last update. In ACE 12.0.3.0 (https://www.ibm.com/docs/en/app-connect/12.0?topic=wniv1-new-function-added-in-version-120-subsequent-modification-fix-packs#v12030__nondynpolicies) you can redeploy non-dynamic policies by using the --restart-all-applications parameter on the mqsideploy or ibmint deploy command. This parameter restarts all applications on the integration server as part of the deploy operation.

RFE Review. Since the time when this RFE was initially raised, the IIB/ACE product architecture has evolved considerably. Configurable services have been replaced with Policies in ACEv11. Policies follow "normal" deployment rules. Most are re-deployable, but some policy changes require a server restart. We document which policies require restart, and over time we are increasing this number with an expectation that eventually all policies will be redeployable without requiring server restart. Additionally, security identities are still used as an abstraction for credential information away from the flow and / or policy. Credentials can be supplied via mqsisetdbparms still, or you can use the new v11 feature known as the credential vault, for encryption of credentials when stored. Using these new capabilities, the use case is achievable:

1. Create vault
2. Create credential
3. Start integration node
4. Deploy FTP Policy (which points at credential)
5. Deploy Application+Flow (which points at policy)
6. You cannot update a credential or delete a credential without reloading the integration server ... however without stopping the server you can ...
7. Create new credential
8. Update FTP Policy (to point at a new credential)
9. Redeploy FTP Policy
10. Redeploy Application+Flow (which did point at old policy, and therefore had old credential cached, but on redeploy will go to new policy and cache new credential)

It is noted that this is only possible in this use case due to the FTP policy being redeployable, so this wouldn't work for the wider problem as posed of allowing security identities to be selectively reloaded. It is also noted that some users prefer to still use mqsisetdbparms rather than credentials. So - this requirement is still valid as a future suggestion regardless of the workaround posted above. For now, status of RFE is maintained as Uncommmitted Candidate.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - WebSphere
Product family - Integration
Product - IBM Integration Bus (WebSphere Message Broker) - IIB

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Connectivity and Integration
Product - IBM Integration Bus (WebSphere Message Broker) - IIB

Thanks for raising this requirement. We spent a significant amount of time making a wide range of configurable services dynamic in V8 (including, crucially the User-Defined Configurable Service). The issue we have is that Configurable Services are fundamentally a data storage mechanism for endpoint information, and the usage of configured properties - i.e. when properties get used - is dependent on the implementation of the nodes using them, so to make all configurable services dynamic requires engineering in every underlying node. We do recognise that having these properties dynamically modifiable is desirable, and newer configurable services do tend to be completely dynamic, but there is still effort required to make these improvements across the board; but it is something we are very keen to do.
I also understand the point that a commenter makes on refreshing properties once they have been reviewed, which I also think is a good requirement; certainly, having the option to do both - choosing when to make the property changes active - is the ideal situation.

All changes need to be effective only when explicitly activated and not when simply updated. This is so that co-dependent changes can be activated together as an atomic operation.

This applies both to configurable services and credential changes. Personally I don't have a problem with mqsireload being used to perform this activation, but if another command was added which refreshed fewer things (e.g. only config services and credentials) that would be a non-disruptive enhancement.

What I don't want to see is changes being effective immediately when made, before any opportunity to review them (list them) and check for correctness, and before other co-dependent changes are also ready.