Skip to Main Content
IBM Sustainability Software - Ideas Portal


This portal is to open public enhancement requests against the products and services belonging to IBM Sustainability Software. 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
Created by Guest
Created on May 19, 2020

VET Improve escalation related error information for support teams

The current escalation system does not give administrators visibility of the number of errors that are encountered when an escalation runs. The lack of visibility means that administrators can create escalations without realising that they are failing for large numbers of the records that are expected to be processed.
If the numbers were recorded then automatic checks could be implemented e.g. to send a notification if an escalation hit a significant number of problems

This RFE proposes extending the escalation application to provide more information about the results of the escalation.
There are several potential levels of information that could be provided.
I am happy to create other RFEs if development decide to implement the functionality in parts.

Level 1
-------
Record the number of rows that were returned by the initial query – This would remove the need for support staff to go through the logs to identify if the escalation processed any records
Record the number of errors that were raised for the run. These would be fatal errors that prevented the record being processed.
Record the percentage of records that were successfully processed – Having this as a value means that it is easy to read

Level 2
-------
Create a KPI to show the top 10 escalations sorted by the percentage of failed records – this would allow system administrators to see which escalations they need to focus on
Customers could build this themselves but then everyone would have to go to the effort.

Include the crontask CID in the escalation history so support staff can quickly search for the related log entries.

Use an escalation specific prefix in the CID. Currently it is a CRON so it is referenced as CRON-. Replacing CRON with ESC would make it easier for support staff to instantly identify if the log message related to an escalation.

Level 3
-------
Create a CLOB/Long description field on the escalation and store the error messages for the records that failed.
Store the BMX code that was generated for analysis purposes. The last BMX code, or a list of the BMX codes for child exceptions, could be stored.
This would allow system administrators to assess how often a particular problem, e.g. invalid email address, was occurring and prioritise the most frequent ones that are causing log rollover.

This would allow system adminstrators to check for errors even if the logs have rolled over. It could also be used to check if the same records have failed in previous runs.

Build a BIRT report to show the details for the escalations so the administrators can act on it.
Include a seprate table that counts the number of records by BMX number.

Idea priority High
  • Guest
    Reply
    |
    May 20, 2020

    The EscStatus record already records the last (or first?) error that occurs on an Escalation. If a separate record were generated for each error and an ObjectID column were added to this table, that would allow clients to identify and correct each error rather than correcting one and then waiting for the next execution to identify the next error.

  • Guest
    Reply
    |
    May 19, 2020

    Interesting concept because a lot set and forget.