This is an IBM Automation portal for Cloud Management, Technology Cost Management, Network Automation and AIOps 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
At present when discovering resources from servicenow we specify the tables to collect data from and have to be explicit with the parent and child classes because whilst resources can be discovered from the parent class and it traverses the children, the final stage where relationships are discovered only discovers the relationship from the parent table to another parent table and doesn't discover anything within the discovered child tables.
ie say we discover these classes :
cmdb_ci_service,cmdb_ci_datacenter,u_cmdb_service_component,u_cmdb_service_lane,cmdb_ci_appl,u_cmdb_service_application,u_cmdb_service_environment,cmdb_ci_server,cmdb_ci_unix_server,cmdb_ci_aix_server,cmdb_ci_linux_server,cmdb_ci_win_server,cmdb_ci_solaris_server,cmdb_ci_mainframe,cmdb_ci_mainframe_lpar,cmdb_ci_cluster,cmdb_ci_ip_network,cmdb_ci_ip_switch,cmdb_ci_firewall_network,cmdb_ci_ip_firewall,cmdb_ci_ip_router,cmdb_ci_database,cmdb_ci_db_instance,cmdb_ci_db_db2_instance,cmdb_ci_db_mssql_instance,cmdb_ci_db_ora_instance,cmdb_ci_lb,cmdb_ci_lb_network,cmdb_ci_lb_service,u_cmdb_ci_tandem,u_cmdb_ci_tandem_controller,u_prc
discovering these classes is necessary because when the observation moves to discovering the relationships in /api/now/table/cmdb_rel_ci then unless each class is specified it doesn't perform a parent/child discovery of the resource and find the upstream and downstream relationships.
If we go with the parent class, then it will discover the children, but never tests the children's resources for relationships within /api/now/table/cmdb_rel_ci so you end up with no relationships drawn for the children.
This has the effect of increasing discovery time and can take 5+ hours as it has to go over the same data and discover children it has already discovered.
So by adding in the ability to have a list of classes to discover for resources and separately a list of classes to discover for relationships it means I can have a cut down list of classes for the first part of the observation and when this is complete it will use the relationship discovery classes to find the remaining relationships and this can then include the child tables.
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.