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 Jun 4, 2013

WMB - provide ODBC information in a configurable service

ODBC data source configuration information is current provided to Unix platform WMB brokers in a single flat file (odbc.ini). This file is very sensitive to small changes, such as a trailing blank on the stanzas causing problems. Also a problem may affect every ODBC connection definition as they are all in the same file. This makes updating this file a risky process and we want to see an alternative that is more like the FTP configurable service.

So a new type of configurable service should be made available that can contain the same information that currently resides in ODBC.ini. There would be one configurable service entry of this type per Data Source and so updating one of these would not risk any inadvertant change or loss of service to other ODBC data sources.

It would also facilitate the automation of ODBC information updates using commands in scripts - currently this would be very hard to achieve.

The configurable service entry would, at a minimum be able to hold the hostname, database name (SID or SERVICE NAME), port number and other frequently updated values. Clearly there would have to be some allowance for the dfifferent types of Database and it would be acceptable to have different types of configurable service for Oracle, Sybase, DB2, and SQL Server.

The use of these service definitions would be optional but would override any entry in ODBC.ini for the data source and keywords specified (in the event that both entries existed). Longer term the use of ODBC.ini should be deprecated as it is a cumbersome way to hold configuration data.

Alternatively the configurable service entry for the data source could refer to a particular ODBC.ini file, so that it was possible to isolate the definitions into separate files - again achieving the aim of removing the risk of affecting unrelated items during a change.

Idea priority Medium
RFE ID 35522
RFE URL
RFE Product IBM App Connect Enterprise (formerly IBM Integration Bus)
  • Guest
    Reply
    |
    Aug 10, 2020

    Thank you for raising this RFE. In concept we understand and have sympathy with the complaint that because ODBC configuration is centralised in a single file, there is potential for syntax mistakes to have wider implication than a single ODBC connection. Editting a single file for the benefit of multiple ODBC connections might also seem unecessarily cumbersome, and make it more difficult to isolate the potential impact of changes. These motivations were in mind when we introduced the conept of policies in policy projects as a replacement for configurable services in ACEv11. Of course, currently ACEv11 still centralises ODBC configuration in a similar file structure as we have done in the past in IIBv10 and earlier versions. This has some advantages in terms of back-compatability and familiarity for existing users, but also some disadvantages as the RFE notes. Long term we may consider making this enhancement suggestion to make ODBC definitions more granular, or in a file system structure that complements the policy approach. One thing which we would need to factor in is the degree to which this might be possible with the internal UNIX ODBC Driver Manager component which the ACE product utilises. This might therefore bring other aspects to the problem space which would need solving - such as potentially having to store this information in more than one file and deal with keeping the two in sync with one another. Thank you for the RFE suggestion. Status is updated to Uncommitted Candidate.

  • Guest
    Reply
    |
    Oct 7, 2015

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - WebSphere
    Product family - Integration
    Product - IBM Integration Bus (WebSphere Message Broker) - IIB

    For recording keeping, the previous attributes were:
    Brand - WebSphere
    Product family - Connectivity and Integration
    Product - IBM Integration Bus (WebSphere Message Broker) - IIB

  • Guest
    Reply
    |
    Mar 3, 2014

    Execution group specific odbc.ini files would be yet another way to reduce the scope of these definitions to avoid inadvertant impact from a change to one application affecting another.

  • Guest
    Reply
    |
    Jan 26, 2014

    It would be nice to see all configutation moved to config services, including ODBC

  • Guest
    Reply
    |
    Jun 6, 2013

    Although the odbc.ini file is a placeholder, yes its true that any foreign chars within can cause great upheaval and is not apparent in diagnostics when db connections don't work! Yes, definitely need the type of data source configurable service within the configurable service and this should serve to override odbc.ini just like other configurable services which override msgFlow parms.

  • Guest
    Reply
    |
    Jun 4, 2013

    I am of 2 minds with this one. Whose job is this RFE supposed to make easier: the developers, or the admin? Also there is no "standard" content as each database type seems to have different relevant parameters...

  • Guest
    Reply
    |
    Jun 4, 2013

    This is indeed much needed functionality to be deveoploed as configurable service.