Who changed that CME object?

The platform SDK makes it pretty easy for use to track changes to CME objects by means of a Conf Server Configuration instance, Protocol Management Service instance and an associated Event Broker instance to handle the following configuration server events:

  • EventObjectCreated
  • EventObjectUpdated
  • EventObjectDeleted

The only extra thing to do is to register for notifications as shown in the code snippet below:

Image

By setting the property “UseDeltaOptimization” to true in the Conf Server Configuration object this can be used as the basis for a Genesys Configuration audit and tracking tool. Life is a bit more complicated in reality since “EventObjectDeleted” only tells us the database ID (DBID) of what has been deleted so we need to keep an internal object cache to have full auditing – more of that in a later post.

Unfortunately although configuration server events tell us ‘What’ has changed, they do not tell us ‘Who’ made the change!

Registering for permissions events using a “RequestRegisterPermissionsNotification” does not help us either.

The required information is however contained on the Configuration Server log when the log level is set to trace. This information is also available in Solution Control Server logs and the log database when network logging is enabled. However trying to parse log files is a) resource intensive and b) not supported by Genesys!

There is a thread on the Genesys Discussion Forum about this (https://forums.genesyslab.com/showthread.php?t=894&highlight=username).

The answer to the problem is to configure alarm conditions in CME which match log events generated by Configuration Server. The relevant log events are 24200 (object created), 24201 (object changed) and 24202 (object deleted). These log events are defined in the ‘confserv.lms’ file in the configuration server installation folder:

Image

The good news is that these are standard level log events and we can prove that we get alarms by creating some alarm conditions in CME. The steps required are:

  • Ensure that standard level network logging is enabled on Config Server:

Image

  • Create alarm conditions for each of the log events (24200, 24201 and 24202):

Image

Putting the pieces together we need create a SCS Configuration instance, Protocol Management Service instance and an associated Event Broker instance to handle SCS “EventAlarmInfo” events. We also need to subscribe to Alarm Conditions:

Image

When the SCS “EventAlarmInfo” event fires we can then parse the log message text using regular expressions to extract the object Type, object DBID and username of the CME person who changed the object.

Here is an example of a log message and some C# code to parse out the data:

Description = “Object: [CfgPerson], name [readc06], DBID: [104] is changed by client, type [SCE], name: [ConfigManager], user: [readc06]”

// Regex out the data
string pattern = @”\[(.*?)\]”;
MatchCollection matches = Regex.Matches(eventAlarmInfo.AlarmDescription.LogMessageText,pattern);
string[] data = new string[matches.Count];
for (int i = 0; i < matches.Count; i++)
{
data[i] = “”;
Match match = matches[i];
data[i] = match.Groups[1].ToString();
}

if (data.Length >= 6)
{
objectType = data[0];
objectName = data[1];
DBID = Convert.ToInt32(data[2]);
clientType = data[3];
clientName = data[4];
username = data[5];
}

Image

So that is it – well nearly. Solution Control Server is a bit too clever and will not raise additional alarms when there is an existing alarm condition and therefore we could lose log events relating to other configuration changes.

The Framework 8 Management User Guide states: “Once configured, an alarm condition automatically triggers an alarm in response to an occurrence of the log event on which the alarm condition is based. If the same log event occurs subsequently while the alarm is active, the clearance timeout is reset.”

I raised a support ticket to double check on this functionality and Genesys confimed that to disable this behaviour we would need to raise a new Feature Request.

The challenge therefore is to ensure that the cancel timeout on each alarm condition is high enough to see the log event and low enough not to miss new log events. The minimum we can set the cancel timeout is 1 second but to make the alarms fire reliability the cancel timeout needs to be 2 seconds which means we run the risk of losing events during bulk configuration changes for example when using configuration wizards.

This is something we can probably live with for now.

Share

Leave a Reply