General Main Release 10.6.0 – New features - Preview

Important

We are still working on this release. Some release notes may still be modified or moved to a later release. Check back soon for updates!

Highlights

• Swarming [ID 37381] [ID 37437] [ID 37486] [ID 37925] [ID 38019] [ID 39303] [ID 40704] [ID 40939] [ID 41258] [ID 41490] [ID 42314] [ID 42535]

New features

Swarming [ID 37381] [ID 37437] [ID 37486] [ID 37925] [ID 38019] [ID 39303] [ID 40704] [ID 40939] [ID 41258] [ID 41490] [ID 42314] [ID 42535]

From now on, you can enable the Swarming feature in a DataMiner System in order to be able to swarm elements from one DataMiner Agent to another Agent in the same cluster. Prior to this, this feature is available in preview if the Swarming soft-launch option is enabled.

The primary goal of Swarming is to eliminate downtime resulting from maintenance activities and provide a more polished user experience.

Note that when Swarming is enabled, this will result in some major changes to the DataMiner configuration:

• Alarm identifiers will be generated on a per-element basis instead of per Agent to make them unique within the cluster. Because of this change, you will need to make sure your system is prepared before you can enable Swarming.

• Element configuration will be stored in the cluster-wide database instead of in the element XML files on the disk of the DataMiner Agent hosting each element.

  When Swarming is enabled, a file named Where are my elements.txt will be present in the C:\Skyline DataMiner\Elements\ folder. In that file, users who wonder why this folder no longer contains any element.xml files will be referred to the Swarming documentation in docs.dataminer.services.

When you create or update an element in DataMiner Cube, you will be able to indicate that the element is not allowed to swarm to another host. To do so, go to the Advanced section, and enable to Block Swarming option. By default, this option will be set to false.

If you try to swarm an element of which the Block Swarming option is set to true, then the error message Element is not allowed to swarm (blocked) will be displayed.

In DataMiner Cube, this Block Swarming option will only be visible if Swarming is enabled in the DataMiner System.

Important

• Swarming cannot be enabled on DataMiner Main Release 10.5.
• If you decide to roll back Swarming again, you will need to restore a backup to get the element XML files back. Any changes that have been implemented to elements after you enabled Swarming will be lost. As a consequence, the sooner you decide to roll back, the smaller the impact of the rollback will be.

Capabilities

Currently, the Swarming feature provides the following capabilities:

• As a DataMiner System Admin, you can apply maintenance (e.g. Windows updates) on a live cluster, Agent by Agent, by temporarily moving functionalities away to other Agents in the cluster.

• As a DataMiner System Admin, you can easily extend your system with an extra node and move functionalities from existing nodes to new nodes, so you can rebalance your cluster (i.e. spread the load across all nodes).

• Swarming makes it possible to recover functionalities from failing nodes by moving activities hosted on such a node to the remaining nodes.

In a later iteration, the Swarming feature will also be able to assist in making rolling DataMiner software updates on live clusters possible, with limited downtime of specific functionality.

Note

The above capabilities are possible with limited downtime and as long as there is spare capacity.

Limitations

Swarming is not available in the following DataMiner Systems:

• DataMiner Systems with a storage per DMA setup (Cassandra or MySQL).

• DataMiner Systems with Failover.

• DataMiner Systems where the LegacyReportsAndDashboards soft-launch option is enabled.

Note

• Currently, Swarming is limited to basic elements. Support for other types of elements will be added in future versions.
• Prerequisite checks are in place to prevent the enabling of the Swarming feature when non-supported objects are present. Where possible, you will also be prevented from configuring or creating these on a Swarming-enabled system.

Required user permissions

To enable the Swarming feature, the Admin Tools user permission is required.

Once the feature has been enabled, users will need the Swarming user permission to trigger any swarming actions. Users who previously had the Import DELT and Export DELT user permissions before Swarming was enabled will automatically also get the Swarming user permission when upgrading from a version without the Swarming permission to a version with the Swarming permission.

To swarm an element, users will also need config rights on the element.

Swarming elements

When Swarming has been enabled, you can swarm elements in DataMiner Cube via System Center > Agents > Status. On that page, the Swarming button will be displayed instead of the Migration button. Clicking the button will open a window where you can select the elements you want to swarm and the destination DMA.

Swarming elements is also possible via Automation, QActions or other (external) tools. See the following Automation script example, in which two input parameters are defined to retrieve the element key and the target agent ID:

• a parameter named "Element Key", containing the DMA ID/element ID pair of the element you want to swarm, and
• a parameter named "Target Agent ID", containing the ID of the target Agent.

using System;
using System.Linq;
using Skyline.DataMiner.Automation;
using Skyline.DataMiner.Net;
using Skyline.DataMiner.Net.Swarming.Helper;

public class Script
{
  public void Run(Engine engine)
  {
    var element = ElementID.FromString(engine.GetScriptParam("Element Key").Value);
    int targetAgentId = Int32.Parse(engine.GetScriptParam("Target Agent ID").Value);
    
    var swarmingResults = SwarmingHelper.Create(Engine.SLNetRaw)
        .SwarmElement(element)
        .ToAgent(targetAgentId);

    var swarmingResultForElement = swarmingResults.First();  

    if (!swarmingResultForElement.Success)
    {
      engine.ExitFail($"Swarming failed: {swarmingResultForElement?.Message}");
    }
  }
}

Retrieving additional logging from a DataMiner System [ID 40766]

From now on, the GetAdditionalLoggingMessage can be used to retrieve additional logging from a DataMiner System. It will return a GetAdditionalLoggingResponseMessage with the following information:

• Log Name: The name of the log.
• Log Type: The type of the log. Currently, only the log type "DxM" is supported.

Example:

// Send a request to collect additional logging info 
var additionalLoggingMessage = new GetAdditionalLoggingMessage();
var response = engine.SendSLNetMessages(additionalLoggingMessage);
var loggingInfo = response.AdditionalLoggingInfo;
foreach (var logEntry in loggingInfo)
{
    engine.GenerateInformationEvent($"Log Name: {logEntry.Name}, Log Type: {logEntry.Type}");
}

Also, the existing messages GetLogTextFileStringContentRequestMessage and GetLogTextFileBinaryContentRequestMessage now have two new properties that will allow them to retrieve additional logging:

• AdditionalLogName: The name of the additional log to be retrieved.
• LogType: The type of the log. Example: LogFileType.DxM

Example:

// Create a request to retrieve a specific additional log in a string format
var logRequest = new GetLogTextFileStringContentRequestMessage
{ 
    AdditionalLogName = "DataMiner UserDefinableApiEndpoint", 
    LogType = LogFileType.DxM
};

Note

These are SLNet messages that are subject to change without notice.

SLNet 'GetInfo' messages for the PropertyConfiguration' and 'ViewInfo' types now support retrieving information for a specific item [ID 41169]

SLNet GetInfo messages for the PropertyConfiguration and ViewInfo types now support retrieving information for a specific item. This will enhance the performance of the Skyline.DataMiner.Core.DataMinerSystem.Common NuGet package used in protocols or Automation scripts.

Type PropertyConfiguration

In the ExtraData property you can now specify ";type=<propertyType>" or ";type=<propertyType>;", where <propertyType> is either ELEMENT, SERVICE or VIEW.

If another value is specified, then all property configurations will be returned.

Type ViewInfo

In the ExtraData property you can now specify ";viewId=<ID>" or ";viewId=<ID>;", where <ID> is the ID of the view for which you want to retrieve more information.

Note

These are SLNet messages that are subject to change without notice.

New SLNet call GetProtocolQActionsStateRequestMessage to retrieve QAction compilation warnings and errors [ID 41218]

A new SLNet call GetProtocolQActionsStateRequestMessage can now be used to retrieve the compilation warnings and errors of a given protocol and version. The response, GetProtocolQActionsStateResponseMessage, will then contains all faulty QActions and their respective warnings and errors.

In future versions, this call will be used to verify whether DataMiner Swarming can be enabled on a DataMiner System.

Note

This SLNet message is subject to change without notice.

Alarms - Proactive cap detection: User feedback [ID 41371]

From now on, users will be allowed to give feedback (positive or negative) on alarms and suggestion events generated by the proactive cap detection feature.

• Positive feedback will make the detection process more forgiving, and future alarms and suggestion events will more likely be generated again when the trend prediction for the parameter in question directs towards the critical value or the values configured in the alarm template.

• Negative feedback will decrease the chance of a similar alarm or suggestion event being re-generated upon a future occurrence of (a) the instance that received the feedback and (b) other instances related to the same parameter. For example, if you give negative feedback on suggestion events of type "Predicted minimum value...", less suggestion events of that type will get generated for some time in the future.

Note

• For this user feedback feature to work, the DataMiner System has to include an indexing database.
• For more information on how to provide feedback on alarms and suggestion events generated by the proactive cap detection feature in DataMiner Cube, see Alarm Console - Proactive cap detection: User feedback [ID 41451].

Web visual overviews: Load balancing [ID 41434] [ID 41728]

It is now possible to implement load balancing among DataMiner Agents in a DMS for visual overviews shown in web apps.

Up to now, the DataMiner Agent to which you were connected would handle all requests and updates with regard to web visual overviews.

Configuration

In the C:\Skyline DataMiner\Webpages\API\Web.config file of a particular DataMiner Agent, add the following keys in the <appSettings> section:

• <add key="visualOverviewLoadBalancer" value="true" />

  Enables or disables load balancing on the DataMiner Agent in question.

  • When this key is set to true, for the DataMiner Agent in question, all requests and updates with regard to web visual overviews will by default be handled in a balanced manner by all the DataMiner Agents in the cluster.

    However, if you also add the dmasForLoadBalancer key (see below), these requests and updates will only be handled by the DataMiner Agents specified in that dmasForLoadBalancer key.

  • When this key is set to false, for the DataMiner Agent in question, all requests and updates with regard to web visual overviews will be handled by the local SLHelper process.

• <add key="dmasForLoadBalancer" value="1;2;15" />

  If you enabled load balancing by setting the visualOverviewLoadBalancer key to true, you can use this key to restrict the number of DataMiner Agents that will be used for visual overview load balancing.

  The key's value must be set to a semicolon-separated list of DMA IDs. For example, if the value is set to "1;2;15", the DataMiner Agents with ID 1, 2, and 15 will be used to handle all requests and updates with regard to web visual overviews.

  If you only specify one ID (without trailing semicolon), only that specific DataMiner Agent will be used to handle all requests and updates with regard to web visual overviews.

Note

These settings are not synchronized among the Agents in the cluster.

New server messages

The following new messages can now be used to which you can target to be sent to other DMAs in the cluster:

• TargetedGetVisualOverviewDataMessage allows you to retrieve a Visual Overview data message containing the image and the content of a visual overview.

• TargetedSetVisualOverviewDataMessage allows you to execute actions on a visual overview that is rendered on a specific DataMiner Agent.

Note

DataMiner Agents will now automatically detect that a visual overview they are rendering has been updated. This means that other agents in the cluster will now be able to correctly process update events and request new images for their clients.

Logging

Additional logging with regard to visual overview load balancing will be available in the web logs located in the C:\Skyline DataMiner\Logging\Web folder.

Information events of type 'script started' will no longer be generated when an Automation script is triggered by the Correlation engine [ID 41653]

From now on, by default, information events of type "script started" will no longer be generated when an Automation script is triggered by the Correlation engine.

In other words, when an Automation script is triggered by the Correlation engine, the SKIP_STARTED_INFO_EVENT:TRUE option will automatically be added to the ExecuteScriptMessage. See also Release note 33666.

If you do want such information events to be generated, you can add the SkipInformationEvents option to the MaintenanceSettings.xml file and set it to false:

<MaintenanceSettings xmlns="http://www.skyline.be/config/maintenancesettings">
    ...
    <SLNet>
        ...
        <SkipInformationEvents>false</SkipInformationEvents>
        ...
    </SLNet>
    ...
</MaintenanceSettings>

DataMiner upgrade: New upgrade action 'UpdateSrmContributingProtocolsForSwarming' [ID 41706]

On systems on which Swarming has been enabled, contributing bookings are not working because protocols of enhanced services do not have a parameter with ID 7.

During a DataMiner upgrade, a new upgrade action named UpdateSrmcontributingProtocolsForSwarming will now check for generated service protocols that do not have a parameter with ID 7. If such protocols exist, the parameter in question will be added to them.

When the above-mentioned upgrade action is executed, it will log the name and the version of every protocol to which it has added a parameter with ID 7. It will also log a warning for every corrupt protocol it has found.

Note

From now on, newly generated service protocols will by default have a parameter with ID 7.

Elements can now be configured to run in isolation mode [ID 41757]

Up to now, the ProcessOptions section of the DataMiner.xml file allowed you to configure that an element had to run in its own SLProtocol and SLScripting processes, and in a protocol.xml file, the RunInSeparateInstance tag allowed you to do the same. However, it was only possible to configure this for all elements using a particular protocol.

From now on, the new Run in isolation mode feature will allow you to also configure this for one single element. For more information on how to configure this in DataMiner Cube, see Elements can now be configured to run in isolation mode [ID 41758].

As creating additional SLProtocol processes has an impact on the resource usage of a DataMiner Agent, a hard limit of 50 SLProtocol processes has been introduced. If, when an element starts, an attempt to create a new SLProtocol process fails because 50 processes are already running, the element will be hosted by an existing SLProtocol process and its matching SLScripting process, regardless of how the Run in isolation mode was configured.

From those 50 SLProtocol processes, 10 processes will be reserved for elements that are not running in isolation mode. This means, that only 40 elements will be able to run in isolation mode at any given time. However, the notice that will appear each time an attempt is made to start an additional element in isolation mode will mention the 50-element limit.

Reducing the number of SLProtocol processes in the DataMiner.xml file will reduce the number of reserved processes. However, increasing the number of SLProtocol processes to above 50 will keep the reserved number of SLProtocol processes to 50 (i.e. the maximum number of SLProtocol processes).

For example, if 15 SLProtocol processes are configured in the DataMiner.xml file, and 45 elements are configured to run in isolation mode, then:

• 10 SLProtocol processes will be used for elements that are not running in isolation mode,
• 35 SLProtocol processes will be used to host an element in isolation mode, and
• the remaining 5 SLProtocol processes will be used for elements running either in isolation mode or not, depending on which elements starts first.

This means, that some elements will not be able to run in isolation mode, and some SLProtocol processes will not be able to host elements that are not running in isolation mode. In each of those cases, an alarm will be generated.

In the DataMiner.xml file, it is possible to configure a separate SLProtocol process for every protocol that is being used. This setting will also comply with the above-mentioned hard limit of 50 SLProtocol processes. As this type of configuration is intended for testing/debugging purposes only, an alarm will be generated when such a configuration is active to avoid that this setting would remain active once the investigation is done.

See also RunInIsolationModeConfig property added to SLNet messages ElementInfoEventMessage and LiteElementInfoEvent [ID 42247]

For more information on how to configure elements to run in isolation mode in DataMiner Cube, see Elements can now be configured to run in isolation mode [ID 41758].

DataMiner Object Models: Configuring trigger conditions for CRUD scripts [ID 41780]

From now on, conditions can be used to prevent the update script from being triggered for each and every DomInstance update. This allows you to make a solution more efficient as no unnecessary script triggers are executed. These conditions can be configured by instantiating one of the supported condition classes and adding it to the OnUpdateTriggerConditions collection property on the ExecuteScriptOnDomInstanceActionSettings.

The conditions are evaluated using a logical 'OR', meaning that only one condition needs to be true for the script to trigger.

Important

When you configure conditions, the update script will no longer be triggered when a status transition is done. A status-related condition to define a trigger based on a specific status is currently not available.

FieldValueUpdatedTriggerCondition

This condition type allows you to check whether a FieldValue for a given FieldDescriptor has been added, updated, or removed. It also supports multiple sections, meaning the condition will be met if:

• A new FieldValue is added in a new or existing Section.
• An existing FieldValue is deleted from a deleted or existing Section.

To use this condition, define the ID of the FieldDescriptor by passing it to the condition's constructor.

Example:

var licensePlate = new FieldDescriptorID(Guid.Parse("81915fe0-8f55-4ad1-8da5-3b703f9e7842"));
var insuranceId = new FieldDescriptorID(Guid.Parse("7cd4366c-983c-46d2-aa92-e0308a3102e5"));

moduleSettings.DomManagerSettings.ScriptSettings.OnUpdateTriggerConditions = new List<IDomCrudScriptTriggerCondition>
{
   new FieldValueUpdatedTriggerCondition(licensePlate),
   new FieldValueUpdatedTriggerCondition(insuranceId)
};

Service & Resource Management: Defining an availability window for a resource [ID 41894]

For each resource, you can now define an availability window, i.e. a period during which the resource is available.

An availability window has the following (optional) properties:

Property	Description
AvailableFrom	The start time of the availability window. Default value: DateTimeOffset.MinValue (i.e. no start time).
AvailableUntil	The end time of the availability window. Default value: DateTimeOffset.MaxValue (i.e. no end time).
RollingWindowConfiguration	The size of the availability window relative to the current time. For example, if you set this property to 30 days, the resource will be available for booking until 30 days from now. If both a fixed end time and a rolling window are set, the earlier time of the two will be used. For example, if the fixed end time is 15 days from now, but the rolling window is 30 days, the resource will no longer be available after the 15-day mark, even though the rolling window would extend to 30 days.

When you use the GetEligibleResources API call to retrieve resources available during a specific time range, resources that are not available for the entire requested range will not be returned.

Example showing how to configure the above-mentioned properties:

var resource = _rmHelper.GetResource(...);
resource.AvailabilityWindow = new BasicAvailabilityWindow()
{
    AvailableFrom = DateTimeOffset.Now.AddHours(1),
    AvailableUntil = DateTimeOffset.Now.AddDays(30),
    // RollingWindow can be left as 'null' if no rolling window needs to be configured
    RollingWindowConfiguration = new RollingWindowConfiguration(TimeSpan.FromHours(5))
};
resource = _rmHelper.AddOrUpdateResources(resource)?.FirstOrDefault();
var td = _rmHelper.GetTraceDataLastCall();
if (!td.HasSucceeded())
{
    // Handle the error
}

Setting AvailableFrom to a date after AvailableUntil, or AvailableUntil to a date before AvailableFrom will throw an ArgumentOutOfRangeException. Also, passing a zero or negative TimeSpan to the RollingWindowConfiguration will throw an ArgumentOutOfRangeException.

Adding an availability window to an existing resource, or adding a resource to a booking that runs outside the availability window of the resource will trigger quarantine. The following errors will be returned when quarantine is triggered:

• When you add an availability window to a resource, an error of type ResourceManagerError with reason ResourceUpdateCausedReservationsToGoToQuarantine will be returned. The quarantine reason in the trigger will be ResourceAvailabilityWindowChanged.

• When you try to book a resource that is not available in the requested time range, an error of type ResourceManagerError with reason ReservationUpdateCausedReservationsToGoToQuarantine will be returned. The quarantine reason in the trigger will be ReservationInstanceUpdated. The ReservationConflictType will be OutsideResourceAvailabilityWindow.

The availability window provides a method to retrieve the time ranges in which the resource is available:

AvailabilityResult result = resource.AvailabilityWindow.GetAvailability(new AvailabilityContext());
List<ResourceWindowTimeRange> availableRanges = result.AvailableTimeRanges;
foreach (var range in availableRanges)
{
    DateTimeOffset start = range.Start;
    DateTimeOffset end = range.Stop;
    
    // A corresponding details property 'StopDetails' exists for the stop;
    TimeRangeBoundaryDetails startDetails = range.StartDetails;

    // Indicates if this boundary was defined by a fixed point (start/stop) or by a rolling window
    BoundaryDefinition startDefinition = startDetails.BoundaryDefinition;
    if (startDefinition == BoundaryDefinition.RollingWindow)
    {
        // ...
    }
}

The AvailabilityContext parameter has a property Now, which can be used to override the "now" timestamp in order to calculate e.g. the current end of a rolling window. For regular use cases, there is no need to override this. This is mainly used for testing purposes and to ensure a consistent timestamp when performing internal checks.

Information events of type 'script started' will no longer be generated when an Automation script is triggered by the Scheduler app [ID 41970]

From now on, by default, information events of type "script started" will no longer be generated when an Automation script is triggered by the Scheduler app.

In other words, when an Automation script is triggered by the Scheduler app, the SKIP_STARTED_INFO_EVENT:TRUE option will automatically be added to the ExecuteScriptMessage. See also Release note 33666.

If you do want such information events to be generated, you can add the SkipInformationEvents option to the MaintenanceSettings.xml file and set it to false:

<MaintenanceSettings xmlns="http://www.skyline.be/config/maintenancesettings">
    ...
    <SLNet>
        ...
        <SkipInformationEvents>false</SkipInformationEvents>
        ...
    </SLNet>
    ...
</MaintenanceSettings>

Relational anomaly detection [ID 41983] [ID 42034] [ID 42181] [ID 42276] [ID 42283] [ID 42319] [ID 42429] [ID 42480] [ID 42602]

Relational anomaly detection (RAD) will detect when a group of parameters deviates from its normal behavior. A user can configure one or more groups of parameter instances that should be monitored together, and RAD will then learn how the parameter instances in these groups are related.

Whenever the relation is broken, RAD will detect this and generate suggestion events for each parameter instance in the group where a broken relation was detected. These suggestion events will then be grouped into a single incident so that it is shown on a single line in the Alarm Console. When you clear such an incident, all its base alarms (i.e. the suggestion events created by Relational anomaly detection) will also be cleared.

Configuration file

Per DataMiner Agent, the above-mentioned parameter groups must be configured in the C:\Skyline DataMiner\Analytics\RelationalAnomalyDetection.xml file. This file will be read when SLAnalytics starts up, when RAD is enabled or re-enabled, or when a ReloadMadConfigurationMessage is sent.

The configuration file must be formatted as follows.

<?xml version="1.0" ?>
  <RelationalAnomalyDetection>
    <Group name="[GROUP_NAME]" updateModel="[true/false]" anomalyScore="[THRESHOLD]" minimumAnomalyDuration="[THRESHOLD2]">
      <Instance>[INSTANCE1]</Instance>
      <Instance>[INSTANCE2]</Instance>
      [... one <Instance> tag per parameter in the group]
    </Group>
    [... one <Group> tag per group of parameters that should be monitored by RAD]
</RelationalAnomalyDetection>

Group arguments

Argument	Description
name	The name of the parameter group. This name must be unique, and will be used when a suggestion event is generated for the group in question.
updateModel	Indicates whether RAD should update its internal model of the relation between the parameters in the group. - If set to "false", RAD will only do an initial training based on the data available at startup. - If set to "true", RAD will update the model each time new data comes in.
anomalyScore	Optional argument that can be used to specify the suggestion event generation threshold. By default, this value will be set to 3. Higher values will result in less suggestion events, lower values will result in more suggestion events.
minimumAnomalyDuration	Optional argument that specifies the minimum duration (in minutes) that deviating behavior must persist to be considered a significant anomaly. Default value: 5 - When minimumAnomalyDuration is set to a value greater than 5, the deviating behavior will need to last longer before an anomaly event is triggered. - minimumAnomalyDuration can be set to a non-default value, for example, to filter out noise events caused by a single, short, harmless outlying value in the data. - If minimumAnomalyDuration is either not set or set to a value less than or equal to 5, an anomaly event will be generated as soon as values deviate sufficiently from the RAD model.

Parameter instance formats

In each Instance, you can specify either a single-value parameter or a table parameter by using one of the following formats:

• Single-value parameter: [DataMinerID]/[ElementID]/[ParameterID]
• Table parameter: [DataMinerID]/[ElementID]/[ParameterID]/[PrimaryKey]

Note

When you add a new parameter group, an error message will appear when that parameter group contains an invalid group name, an invalid number of parameters, an invalid anomaly threshold, or an invalid minimum anomaly duration value.

Average trending

RAD requires parameter instances to have at least one week of five-minute average trend data. If at least one parameter instance has less than a week of trend data available, monitoring will only start after this one week becomes available. In particular, this means that average trending has to be enabled for each parameter instance used in a RAD group and that the TTL for five-minute average trend data has to be set to more than one week (recommended setting: 1 month). Also, RAD only works for numeric parameters.

If necessary, users can force RAD to retrain its internal model by sending a RetrainMadModelMessage. In this message, they can indicate the periods during which the parameters were behaving as expected. This will help RAD to identify when the parameters deviate from that expected behavior in the future.

History set parameters

Under certain conditions, Relational anomaly detection (RAD) is able to detect relational anomalies on history set parameters:

• If there is at least one history set parameter in a RAD parameter group, that parameter group will only be processed when all data from all parameters in the group has been received. In other words, if a history set parameter receives data 30 minutes later than the real-time parameters, possible anomalies will only be detected after 30 minutes.

• RAD will only process data received within the last hour. If a history set parameter receives data more than an hour later than the real-time parameters, that data will be disregarded.

Limitations

• RAD is only able to monitor parameters on the local DataMiner Agent. This means that all parameter instances configured in the RelationalAnomalyDetection.xml configuration file on a given DMA must be hosted on that same DMA. Currently, RAD is not able to simultaneously monitor parameters hosted on different DMAs.

• Some parameter behavior will cause RAD to work less accurately. For example, if a parameter only reacts on another parameter after a certain time, then RAD will produce less accurate results.

Messages

The following API messages can be used to create, retrieve and remove RAD parameter groups:

Message	Function
AddRADParameterGroupMessage	Creates a new RAD parameter group. If a group with the same name already exists, no new group will be added. Instead, the existing group will be updated.
GetRADDataMessage	Retrieves the anomaly scores over a specified time range of historical data.
GetRADParameterGroupInfoMessage	Retrieves all configuration information for a particular RAD parameter group.
GetRADParameterGroupsMessage	Retrieves a list of all RAD parameter groups that have been configured.
RemoveRADParameterGroupMessage	Deletes a RAD parameter group.
RetrainRADModelMessage	Retrains the RAD model over a specified time range.

Note

• Names of RAD parameter groups will be processed case-insensitive.
• When a Relational Anomaly Detection (RAD) parameter group is deleted, all open suggestion events associated with that parameter group will automatically be cleared.
• The following messages have been deprecated: AddMADParameterGroupMessage, GetMADParameterGroupInfoMessage, RemoveMADParameterGroupMessage, and RetrainMADModelMessage.

SLNetClientTest tool: Element process ID information [ID 42013]

In the SLNetClientTest tool, you can now retrieve live information about the mapping between elements running on a DataMiner Agent and the processes they use, including SLProtocol and SLScripting. To do so, go to Diagnostics > DMA > Element Process ID Info.

The information provided is similar to the information found in the SLElementInProtocol.txt log file. It will allow you to monitor and troubleshoot process usage in real time.

Warning

Always be extremely careful when using this tool, as it can have far-reaching consequences on the functionality of your DataMiner System.

RunInIsolationModeConfig property added to SLNet messages ElementInfoEventMessage and LiteElementInfoEvent [ID 42247]

A new RunInIsolationModeConfig property has been added to the SLNet messages ElementInfoEventMessage and LiteElementInfoEvent. This property will allow client applications to indicate if and how an element is configured to run in isolation mode.

The property can have one of the following values:

Value	Description
None	The element is not running in isolation mode.
Dma	In the ProcessOptions section of the DataMiner.xml file, it has been specified that all elements using the protocol in question should be running in isolation mode.
Protocol	In the protocol.xml file, the RunInSeparateInstance tag specifies that all elements using the protocol in question should be running in isolation mode.
Element	The element has been individually configured to run in isolation mode.

If multiple settings indicate that the element should be running in isolation mode, the RunInIsolationModeConfig property will be set to one of the above-mentioned values in the following order of precedence: "Protocol", "Element", "Dma".

Note

• If, in DataMiner Cube, you specified that a particular element had to run in isolation mode, the boolean property RunInIsolationMode will be true. In some cases, this boolean RunInIsolationMode property will be false, while the above-mentioned RunInIsolationModeConfig property will be set to "Protocol". In that case, the element will be running in isolation mode because it was configured to do on protocol level.
• See also Elements can now be configured to run in isolation mode [ID 41757]

Failover: NATS cluster state will now be visible in DataMiner Cube's Failover Status window [ID 42250]

In DataMiner Cube, the NATS cluster state will now be visible in the Failover Status window. This state will indicate whether NATS communication between main agent and backup agent is up and running and whether the clusterEndpoints.json file is synchronized between the two agents.

New NotifyProtocol call NT_CLEAR_PARAMETER [ID 42397]

A new NotifyProtocol call NT_CLEAR_PARAMETER (474) can now be used to clear tables and single parameters. When used, it will also clear the parameter's display value and save any changes when the parameter is saved.

Internally, this new NT_CLEAR_PARAMETER call will now also be used by the existing SLProtocol function ClearAllKeys(). As a result, the latter will now be able to clear tables of which the RTDisplay setting was not set to true.

Note

• NT_CLEAR_PARAMETER cannot be used to clear table columns.
• This new NotifyProtocol method can be invoked from within a QAction by using the protocol.ClearParameter(<paramId>) function.
• When using ProtocolExt, you can now use e.g. protocol.getRequests.Clear() to clear a table parameter named getRequests. Internally, this new Clear() function will then execute a protocol.ClearAllKeys(<getRequests parameter ID>) call.

Automation: Separate log file for every Automation script that is run [ID 42572]

From now on, when an Automation script is run, every entry that is logged in the SLAutomation.txt file by the Engine.Log method will also be logged in a separate log file located in C:\Skyline DataMiner\Logging\Automation\. That log file will have a name that is identical to that of the Automation script.

• The first time an Automation script is run, a log file will be created in C:\Skyline DataMiner\Logging\Automation\ for that particular script.
• After a DataMiner restart, the first time a script is executed, its existing log file will get the "_Bak" suffix and a new log file will be created.
• If an Automation script is renamed, a new log file will be created with a name identical to that of the renamed script. The old file will be kept.
• If you want to configure a custom log level for a particular Automation script, send an UpdateLogfileSettingMessage in which Name is set to "Automation\ScriptName". If no custom log configuration exists for a particular Automation script, the default configuration will be used.
• These new Automation script log files will also be included in SLLogCollector packages.
• Each time a DataMiner upgrade package is installed, all Automation script log files will be deleted.

Log entry format: 1|2|3|4|5|6|7|8

1. Date/time
2. "SLManagedAutomation"
3. Method that created the log entry
4. Log type
5. Log level
6. Thread ID
7. Script run ID
8. Message

Example: 2025/04/01 16:31:31.813|SLManagedAutomation|RunSafe|INF|0|959|473|Example message

Note

• In the Automation script log file, you will find an indication of when the script execution started and stopped. However, this indication will be slightly different from the one you will find in the SLAutomation.txt log file. The one in the SLAutomation.txt log file will represent the total time it took for the script to run, while the one in the script log file will only take into account the C# blocks in the Automation script.
• For each entry that is logged in one of the above-mentioned script log files, an identical copy will also be logged in the SLAutomation.txt file. However, note that the timestamps of both entries may not be identical.

Automation: Hash property of GetScriptInfoResponseMessage now contains a hash value of the script [ID 42616]

A Hash property has now been added to the GetScriptInfoResponseMessage. This property will contain a calculated hash value of the script based on the following script data:

• Name

• Description

• Type

• Script options:

  • Options included in the hash value calculation:

    • DebugMode
    • SkipElementChecks
    • SkipInfoEventsSet
    • SupportsBackAndForward
    • AllowUndef
    • WebCompliant (see soft-launch option UseWebIAS)

  • Options not included in the hash value calculation:

    • None
    • RequireInteractive
    • SavedFromCube
    • HasFindInteractiveClient

  Note

  For more information on the different script options, see options attribute.

• CheckSets

• Protocols

• Memories

• Parameters

• Executables

  Note

  Executable code will be trimmed. All empty lines before and after the code will be removed.

Note

Author will not be included in the hash value as changing the author would result in a different value being calculated.

All hash values of all Automation scripts will be added as AutomationScriptHashInfo objects to the Automation script hash value cache file AutomationScriptHashCache.txt, located in the C:\Skyline DataMiner\System Cache\ folder. This file will be updated one minute after an Automation script was created or updated or one minute after a GetScriptInfoMessage was called.

Format of an AutomationScriptHashInfo object: Script Name;LastUpdate;Calculated hash

Example: Automation script;638786700548555379;48bcb02e89875979c680d936ec19ad5e9697f7ed73498fd061aecb73e7097497

SNMPv3: Parameter value can now be used as context name or context ID when executing an SNMP get or set command [ID 42676]

In a connector of an SNMPv3 element, it is now possible to indicate that the value of a specific parameter should be used as context name or context ID whenever an SNMP get command or an SNMP set command is executed on the particular connection.

To define that the value of a particular parameter should be used as context name for connection 0, specify the following:

<Param ...>
    ...
    <SNMP options="ContextName:0"/>
    ...
</Param>

To define that the value of a particular parameter should be used as context ID for connection 0, specify the following:

<Param ...>
    ...
    <SNMP options="ContextID:0"/>
    ...
</Param>

If the parameter is not initialized or is set to an empty string, the default parameter value will be used (i.e. an empty string).

The context name and context ID can be changed at run-time, and are not saved by default. When the element is restarted, the parameter data will be lost unless the save attribute of the parameter was set to true (e.g. <Param id="1" save="true">).

Automation scripts: Generating information events when editing a connection in a QAction [ID 42783]

The SLNet message EditConnection, which can be used to edit a connection from within a QAction, now has a GenerateInformationEvents property. If this property is set to true, information events will be generated when a connection is created, updated, or deleted.

Automation: New OnRequestScriptInfo entry point [ID 42969]

In an Automation script, you can now implement the OnRequestScriptInfo entry point. This will allow other Automation scripts (or any other code) to request information about the script in question, for example which parameter values are required for a particular profile parameter.

Using the entry point

To use the entry point, add a method with the following signature to the script:

[AutomationEntryPoint(AutomationEntryPointType.Types.OnRequestScriptInfo)]
public RequestScriptInfoOutput OnRequestScriptInfoRequest(IEngine engine, RequestScriptInfoInput inputData)

Both RequestScriptInfoInput and RequestScriptInfoOutput have a Data property of type Dictionary<string, string>, which can be used to exchange information between the script and other code. It is strongly recommended to keep the passed data below 20 MB (i.e. 10 million characters). If larger chunks need to be passed, a reference to that information should be passed instead.

It is allowed to pass null as input data and to return null as output data.

Arguments

If the script has any script parameters, dummies or memory files, then these are not required when executing the OnRequestScriptInfo entry point. However, they are required when executing the Run method of that same script.

• When an omitted script parameter is used in the entry point logic, retrieving the script parameter is possible, but its value will be an empty string.
• When an omitted dummy is used in the entry point logic, retrieving the dummy is possible, but it will refer to DMA ID -1 and element ID -1. Any actions that use the dummy will fail with an exception.
• When an omitted memory file is used in the entry point logic, retrieving the memory file is possible, but it will refer to a linked file that is empty. Retrieving a value using the memory file will fail with an exception.

Subscript

To execute the OnRequestScriptInfo entry point within Automation, you have to use the following PrepareSubScript method on Engine or IEngine:

RequestScriptInfoSubScriptOptions PrepareSubScript(String scriptName, RequestScriptInfoInput input)

The script should be started synchronously. It will return a subscript options object with an Output property containing the information returned by the script. The Input property can be used to check or update the data sent to the script.

Executing subscripts is limited to a maximum of 10 levels.

ExecuteScriptMessage

The ExecuteScriptMessage can be used to trigger the entry point using an SLNet connection.

var input = new RequestScriptInfoInput
{
  Data = new Dictionary<string, string>
  {
    { "Action", "RequestValues" },
  },
};

new ExecuteScriptMessage
{
  ScriptName = scriptName,
  Options = new SA(new []{ "DEFER:FALSE" }),
  CustomEntryPoint = new AutomationEntryPoint
  {
    EntryPointType = AutomationEntryPoint.Types.OnRequestScriptInfo,
    Parameters = new List<object> { input },
  },
};

When an ExecuteScriptMessage is sent, an ExecuteScriptResponseMessage will be returned. The information is returned in an EntryPointResult.Result property of type RequestScriptInfoOutput.

This message should not be used to request the information in an Automation script.