Skip to Main Content
Integration


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).


Shape the future of IBM!

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:

Search existing ideas

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 your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

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.


Status Future consideration
Workspace App Connect
Created by Guest
Created on Feb 13, 2024

ACE: update-thread-pool non-permanent change

IIB 10 has the option to provision Policies or Instances permanently to each MessageFlow that exists within the integration nodes.

This allowed to adjust the services in a fast and persistent way to each service depending on the transactional load of the moment.

On the ACE version, the exit of this utility was notified, where it is indicated that the values must be modified from the service sources.

The option to edit instances is still enabled but the changes are not persistent, for customers with more than 6000 Flows modifying the development is not a quick option although it is the most recommended.

To ease the transition between IIB and ACE it is recommended to enable the option to save instances permanently as ACE currently purges changes with each product restart.

For the UDPS IBM provisioned the variable UDP-persist-global-overrides: true which facilitated the mentioned scenario to udps, how good it would be to provision it for the change of Instances.

Idea priority Urgent
  • Admin
    Ben Thompson
    Reply
    |
    May 10, 2024

    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.