AlarmItemReader LastUpdate

[Adam_Summers]

I have a query about using the built in AlarmItemReader type  using SC 2.2.127 libraries.

The code snipped below works in a long running processor, but I seem to read the same alarm set twice as inspecting the LastUpdate key it looks like the value is not updated until it is requested for the second time.

            var alarmItemReader = new AlarmItemReader

            {

                EwsEndpoint = _endpoint.EwsEndpoint,

                UserName = _endpoint.UserName,

                Password = _endpoint.Password

            };

            while (!IsCancellationRequested)

            {

                Logger.LogDebug(LogCategory.Processor, $"Alarm Poll Time : {DateTime.Now}");

                Logger.LogDebug(LogCategory.Processor, $"Last Alarm Update Key - Before alarmItem.ReadData(): {alarmItemReader.LastUpdate}");

                var alarms = alarmItemReader.ReadData();

                Logger.LogDebug(LogCategory.Processor, $"Alarms Read : {alarms.DataRead.Count}");

                foreach (var alarm in alarms.DataRead)

                {

                    //Do something with the alarms...

                }

                Thread.Sleep(PollTimerSeconds * 1000);

            }

I'm currently working around by storing read alarms short term in memory cache and checking if they are already processed but I wondered if this was a error in the way in which I'm using the AlarmItemReader or potentially a bug? I know the EWS last update works and the code snippet below shows using an IManagedEwsClient and calling GetUpdatedAlarmEvents that the key advances before the AlarmItemReader when run in parallel to the code above.

         var alarmItemReader = new AlarmItemReader

            {

                EwsEndpoint = _endpoint.EwsEndpoint,

                UserName = _endpoint.UserName,

                Password = _endpoint.Password

            };

            var lastUpdate = string.Empty;

            while (!IsCancellationRequested)

            {

                Logger.LogDebug(LogCategory.Processor, $"Alarm Poll Time : {DateTime.Now}");

                Logger.LogDebug(LogCategory.Processor, $"Last Alarm Update Key - Before alarmItem.ReadData(): {alarmItemReader.LastUpdate}");

                var alarms = alarmItemReader.ReadData();

                Logger.LogDebug(LogCategory.Processor, $"Alarms Read : {alarms.DataRead.Count}");

                foreach (var alarm in alarms.DataRead)

                {

                    //Do something with the alarms...

                }

                if (string.IsNullOrEmpty(lastUpdate))

                {

                    var alarmEvents = client.GetAlarmEvents(_endpoint);

                    lastUpdate = alarmEvents.GetAlarmEventsResponseStatus.LastUpdate;

                }

                else

                {

                    var updatedAlarmEvents = client.GetUpdatedAlarmEvents(_endpoint, lastUpdate);

                    lastUpdate = updatedAlarmEvents.GetUpdatedAlarmEventsResponseStatus.LastUpdate;

                }

                Thread.Sleep(PollTimerSeconds * 1000);

            }

Thanks,

Adam.

[JeffBowman]

Hi Adam,

What you are seeing is a bug. Ironically, I found this same issue yesterday while writing an extension, and it turned out to be a bug in the AlarmItemReader. The bug has been fixed in the development branches, but is not yet available.

Do you need a fix for this ASAP? Or is this something that can wait for 2.3?

Regards,

-Jeff

[Adam_Summers]

Hi Jeff,

Thanks for the quick response, that's great, at least I'm not going crazy! I was beginning to think it was me..

I can work around the probelm, I just keep the AlarmId's I've read in memory cache for a short period but more than double my poll time and check against that before handing the alarms off for processing by the extension. I'm happy to wait for the next release to get a fix.

If I recall from a recent discussion with Mark the *ItemReaders don't use Managed Connections either do they? Will that be corrected in 2.3 as well?

I could just use the managed client and deal with the extra code my side if there's a real performance problem with my workaround for any solutions in the interim but I like how easy the readers make it so I don't have to handle refresh and paging etc

[sesa180908_brid]

Adam,

Yes, in v2.3 all EwsDataReader and EwsDataWriter subclasses will leverage the IManagedEwsClient.