This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Idea Review. Thank you for taking the time to raise this enhancement idea.
As mentioned in the submission, there are several ways in which a user can choose to assign additional instances to a message flow. Settings can be applied as a property on the message flow artifact itself. These settings remain in force across restarts of the server. Another option is to abstract the desired number of additional instances away from the flow itself and define it as a property of a workload management policy. The workload management policy can then be associated with one or more message flows as a setting applied in the BAR file at the point of deployment. Using the same policy with multiple flows means that if a user later updates the policy it will automatically apply to all the flows associated with it. WLM policies are also redeployable. We mention this option specifically because it appears that one of the motivations of the suggestion is based on the large number (6000) of message flows. Given this large number of message flows, using a WebUI action to manually and individually update each message flow would seem just as user-intensive, but worse because that would need to be used on each flow where as a policy can be reused across multiple flows. As mentioned, another option is to use the Web UI (or directly through the public admin REST API on which the ACE Web UI is based) to update the number of instances. These changes are currently deliberately not persisted across server restarts (the API deliberately utilizes a non-CRUD action which is non-persistent, as opposed to a PATCH verb action which is used when wanting to persist an update).
Given this background, we could see a couple of potential enhancements that could be investigated in future - either providing a PATCH method and an associated Web UI action to "update and persist" ... or a global server-wide setting in the server.conf.yaml file in a similar vein to the referenced feature "UDP-persist-global-overrides: true" which would then impact the manual actions used by the existing Web UI option. We are updating the status of this request to Future Consideration in acknowledgement that a fraction of our users might prefer one of these options over the existing intended persistent mechanisms already provided (setting in the flow or on a WLM policy)... whilst noting that the product does already provide two ways of achieving the described use-case (one of which could be argued is more suitable for large numbers of flows) and therefore it is likely this request will be seen as a low business priority unless we receive strong evidence to the contrary via comments on this request.