Attaching work load policy to a certain flow in ACE v12

Hi,

thank you for your detailed answer.

I understand your wish to make the creation of a policy and its attachment to a flow, a one step action done by deployment.

However, I don't understand why the change of the number of threads is entangled with the deployment of the code (BAR file). Those two should be separated. Though it is possible to change the number of threads at runtime, this is not persistent.

Maybe if it was easier for me to rebuild the BAR file, I would have been OK with it, but since I have a lot of projects, I would have to search for its code, find the correct version that is now deployed to production, clone it and build an entirely new BAR, risking that I may forget other BAR properties that I should set before deploying to production, set the correct policy and then deploy just to change the number of threads persistently. This doesn't feel right.

Idea / RFE Review. Thank you for taking the time to raise this suggestion. This area of product behaviour has altered slightly between the versions mentioned: IIBv10 (which became generally available in 2015) and ACEv12 (which became generally available in May 2021). In IIBv10, the product maintained a distinction between a workload management policy which was deployed but not currently being used (attached) to a message flow, as opposed to a workload management policy which was deployed but also attached to one or more message flows. In this version of the product architecture it was not possible to separately remember overrides distinctly from the resources to which they were applied, and so this distinct extra "attachment" step was the only way in which the product could support the use case of being able to dynamically change workload management properties after deployment of the initial artifacts. Moving forward to ACEv11 and ACEv12, we unified many product concepts (previous policies, all configurable services, monitoring profiles and also WS-policy/policy set bindings) under the generalised banner of "policies". We evolved the product in this way in order to try and simplify the number of product concepts in play when needing to describe when overriding changes should take effect ... and accordingly took soundings from many users registered on our Early Experience Program about whether it was appropriate to carry forward the concept of having to "attach" policies. The strong feedback we received was that requiring policies to be both deployed and then later "attached" was overkill and too complicated. So - our aim with v11 and v12 is still to allow changes to be both dynamic and non-dynamic according to preference, but the main notion of whether a policy is "in force" or not is to be achieved simply through the act of deployment. Applying this state of affairs to the highlighted area of additional instances, this results in the following:

1. Users can still create one or more workload management policies, which can be deployed together as part of a single policy project, or in separate policy projects.

2. Workload management policies can be redeployed. For workload management policies which are in use by a message flow, the flow will be stopped and restarted when the policy changes.

3. A message flow's use of a workload management policy is controlled through a property of the BAR file... so if you wish to separate the flow from a particular set of workload management settings as an "override", you can still do this using the override of the flow properties in the BAR ... and if you wish to switch the policy being used you can either redeploy the flow with a different linked policy... or change the policy and redeploy it, and the flow will pick up the change. These actions are persistent ways of altering the workload management settings which are in effect ... if the integration server is restarted, then the deployed flows, policies and links between them which were established using the BAR file, are persisted through the artifacts held on disk in the run directory of the working directory and will still be in effect when the server starts again.

4. For users who do not wish to make such persistent changes, or who do not like the concept of using BAR files / redeploys to change the settings for additional instances, there is also the option to make non-persistent changes to the number of additional instances using the product's administrative REST API. This REST API is also exploited by the administrative Web User Interface which has an option to "Update thread pool". These updates are intended to be used in a dynamic fashion and are deliberately not persisted on server restart (though of course once you have "performance tuned" a server you could duplicate the settings which you've applied dynamically into a policy project and then deploy them as persistent settings that way as described previously above.)

The ACEv11/12 product architecture still leaves open to us a further possibility of offering a "PATCH" based enhancement to the admin REST API (as opposed to the non-CRUD API method for updating the thread pool). We reserve the PATCH verb for situations when we want to persist a change across an integration server restart. We could in future implement this change (outside of the policy concept) and then build Web UI features on top of the admin REST API to offer the chance of "update the thread pool and persist across future restarts without the need of using WLM policies". Of course, this potential future enhancement is somewhat removed from the initial request made in this idea ... and to be frank is not something which has been widely discussed or requested from our users since v11 became GA back in March 2018 (most likely because of the fullsome capabilities for persistent updates with policies and redeployment).

Given the capabilities discussed above, we are closing this RFE. In the unlikely event you still remain disatisfied with these options and would like to see the PATCH REST API idea described above implemented in the product, then feel free to open a more targetted idea for that aspect and we would be happy to consider this for the future ... and of course we would invite the community to comment on such an idea if interested.