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 Not under consideration
Workspace App Connect
Created by Guest
Created on Oct 20, 2021

Procedural configuration of connection metadata


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
  • Guest
    Reply
    |
    Oct 28, 2021

    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!




  • Admin
    Ben Thompson
    Reply
    |
    Oct 27, 2021

    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