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.
See this idea on ideas.ibm.com
I classified this "needed By" yesterday, because it reflects a capacity which I had in previous versions, and sorely feel its loss.
In IIB v10, we had the capacity to create and maintain connection
metadata in a procedural manner. For example: I have a data source
named
UFIRST
which I know to refer to database named
UFIRST
with user
UF_IIB_TST
in test, reached at host
yadda.youdontcare.ufl.edu
with password I know.
I have similar metadata I know about the QAT and PRD configuration of
that datasource.
On some schedule, we update the DB users' password, or the host at which
the database should be addressed.
We have a script that can look up the new metadata, and deploy the
updated configuration.
If a human has to clicky-clicky a web interface to make these changes,
then there is no way to reliably maintain the configuration. Errors
creep in, and this is just a fact of human data entry.
Ironically, in the containerized ACE environment, I'm told that this
capacity has been retracted. My support issue TS007100330 was the
explicit statement of this lack of support.
I am saddened that this infrastructure-as-code feature was taken
away. It's a material feature loss, bearing directly on
maintainability and reliablity of services.
Idea priority | High |
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
Hm. Might be some support training indicated, then; I was pretty specific in the ticket; I even asked if policies were the appropriate feature to do this automatic configuration.
I don't have enough experience with the Designer to make concrete examples; we're still trying to get the thing to run. I can speak with some precision about the idea I want to accomplish.
We have a taxonomy of connections; to databases, external apps (salesforce et. al.) authentication sources and what-not.
My expectation is that a new integration server can be deployed, with reference to some list of configuration objects, and not require that the deploying person (or continuous integration process!) click on web pages to make it happen. They would need to make configuration statements in the deploy descriptor analogous to: 'here's the list of datasources I need to access', and expect that they be available.
I interpret your response as "Yeah, you can do this, it'll be reflected in a list of policies applied to the deploying barfile(s)".
So once we get ACE actually functioning, I'll seek for this pattern. Thanks for your prompt response!
Idea / RFE Review. Thank you Allen for taking the time to raise this enhancement request. The case which you reference discussed the name of the account configuration used by the App Connect Designer ... and yet in the description of this idea there is reference to IIBv10 having the capacity to create and maintain connection metadata (it sounded like you may also have been referring to ODBC.ini configuration with your example?) ... so it wasn't clear to us whether your intentions are now relating specifically to Designer flows or are you still using Toolkit message flows?
ACE software absolutely maintains the same abilities of IIB to enable procedural configuration of connection metadata. Configurable services are now policies (defined in policy projects), and can either be deployed in a BAR file or laid on to the server's filesystem as an override ... which works very nicely in container based architectures. On this basis, we don't think ACE has taken anything away from what was in IIB, so we're putting this idea into status "Not under consideration" for now ... but if we've misunderstood and you're actually only seeking enhancement to App Connect Designer, then it is certainly true that more could be done to extend configuration options in that environment to make them more amenable for override. If this is what you're after, to ensure we get the idea routed and considered by the right people, perhaps could we ask you to further clarify the precise part of the configuration metadata which you'd like to change, and also confirm that your deployment here is to Cloud Pak for Integration (as opposed to a native software installation directly on metal) ? Best Regards, Ben