I have a question from a user: Can we mask a row or multiple rows of a table in advance to prevent an alarm from being generated?
For example, in the image below, the user wants to perform testing or maintenance on the highlighted interface, which would normally trigger alarms. Before the alarm is generated, can the user mask that interface in advance so that no alarm is triggered or appeared in active alarm when testing or maintenance begins?
Is there any other way to suppress alarm generation for that interface beforehand, aside from the masking method?
Hi Jeeva,
Adding an extra option to the previous answer (and as a last resort), you could potentially mask a row. This option is not available by default (it will need to be implemented in an automation script). Below a small demo:
Code snippet:
using Skyline.DataMiner.Automation;
using Skyline.DataMiner.Net;
using Skyline.DataMiner.Net.DataMinerObjectReferences;
using Skyline.DataMiner.Net.Enums;
using Skyline.DataMiner.Net.Messages;/// <summary>
/// Represents a DataMiner Automation script.
/// </summary>
public class Script
{
/// <summary>
/// The script entry point.
/// </summary>
/// <param name="engine">Link with SLAutomation process.</param>
public void Run(IEngine engine)
{
Element element = engine.FindElement("TEST_ELEMENT");int elementId = element.ElementId;
int dmaId = element.DmaId;
int tablePid = 1; /*Se the table PID*/
string tableIndex = "tableIndex"; /*Set the index of the row*/
string reasonMasking = "Test"; /*Reason for making */MaskRow(engine, dmaId, elementId, tablePid, tableIndex, reasonMasking);
}public static void MaskRow(IEngine engine, int dmaId, int elementId, int tablePid, string tableIndex, string reasonMasking)
{
DMAObjectRefTreeHelper helper = new DMAObjectRefTreeHelper();
helper.SetupHelper(engine.SendSLNetSingleResponseMessage);// Define the row to be masked
RowID rowId = new RowID(dmaId, elementId, tablePid, 0, tableIndex);helper.ChangeMaskInfo(
new Skyline.DataMiner.Net.DMAObjectRefTree(rowId),
new Skyline.DataMiner.Net.Masking.MaskInfo()
{
DoMask = true,
MaskType = MaskType.UntilUnmask,
Reason = reasonMasking,
},
new CPECrawlerConfiguration());
}
}
Hope it helps.
"Note that this is an internal call and we do not recommend using this, as it is not officially supported and we cannot guarantee that it will still work in the future. As a rule, you should avoid using SLNet calls, as these are subject to change without notice. We recommend to instead always use the correct UI or automation options provided in DataMiner Automation or through our web API."

Hi Alberto,
In the demo, I showcase the 'mask row' feature. By default, if a row is removed and then recreated with the same index, any alarm associated with that row will lose its masking state. In de the animation, you will notice that when the row (with the same index) is re-created, the masked state for the alarm persists.
Snipped added as reference.
I believe the desired behaviour can be obtained, but with a slightly different approach.
1. Preventively mask the full element (but that means receiving NO alarms for any of the Parameters) - for a period of time (the maintenance window), so that when the planned work is over, if any alarms are still present, they can be promptly notified.
2. Changing the Alarm Template at scheduled times, so that the specific parameter is excluded from monitoring, during the maintenance - a bit of an overkill for just one interface... but possible - some VBxx0 integrations for DM used to have a built-in feature like this, e.g. to exclude from monitoring specific TV programs not aired over night, in order to prevent alarms when not required.
3. If the Protocol (and licensed capacity) allows "DVE creation" for each interface, then the DVE can be masked as in point 1 (gonna be a lot more elements, though)
In practice, to mask a specific alarm, without losing visibility over the rest of KPIs in the element, the alarm needs to be raised first - as an alarm ID is needed to mask a specific alarm.
HTH
That's interesting – thanks for sharing, Miguel.
In this bespoke approach, are you removing the row or just masking an existing alarm?