Need Help Updating Existing Metric Instance Instead of Creating Duplicate Records
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
Hi,
I have configured a Metric Definition on the Problem table to calculate the total time a Problem record spends in the RCA state, starting from the Problem creation time.
Requirement:
When the Problem state changes:
From RCA → Fix in Progress
From RCA → Resolved
From RCA → Closed
The system should calculate the total time from:
Problem Created Time → Until it exits the RCA state
This part is working correctly.
The Issue:
If the Problem lifecycle behaves like this:
Created
Moves to RCA
Moves to Fix in Progress → Metric calculated correctly
Moves back to RCA
Again moves to Fix in Progress / Resolved / Closed
Now, instead of updating the existing Metric Instance record, the system creates a new Metric Instance entry in the metric_instance table.
So for a single Problem record, I am getting multiple metric instance records.
Expected Behavior:
For a single Problem record:
Only one Metric Instance record should exist.
When the record re-enters RCA and exits again, the same Metric Instance record should be updated with the latest calculated value.
No duplicate metric instance entries should be created.
Current Problem:
The metric script is:
Creating a new metric instance every time the record exits RCA.
Not checking whether a metric instance already exists for that Problem.
Not updating the existing metric instance with the new value.
I need guidance on how to:
Prevent multiple metric instance records for the same Problem.
Update the existing metric instance instead of inserting a new one.
Properly handle state transitions when a record re-enters RCA.
My code:
incidentTime = current.first_reported_by_task.sys_created_on;
if (gs.getProperty('com.snc.best_practice.problem.mandfld.state.model')) {
if (current.problem_state == ProblemState.STATES.RESOLVED ||
current.problem_state == ProblemState.STATES.FIX_IN_PROGRESS ||
current.problem_state == ProblemState.STATES.CLOSED) {
createMetric();
}
}
function createMetric() {
if (mi.metricExists()) {
var gr1 = mi.getMetricInstance();
gr1.end = current.sys_updated_on;
gr1.update();
}
var gr = mi.getNewRecord();
gr.start = current.sys_updated_on;
gr.end = current.sys_updated_on;
gr.duration = gs.dateDiff(gr.start, gr.end);
gr.insert();
mi.complete(gr);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
34m ago
I would recommend not to over complicate it and address this via reporting in a pivot etc.
Considering its "problem", the volume should be less for a given month. I am not sure how it would be in your environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
27m ago
@Santhana Rajhan thanks for the reply
What does "address this via reporting in a pivot etc." mean. I didn't get this
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4m ago
This would be a large transaction. Can I get the business requirement? Would they be reporting of each problem or is it like a monthly report?
