Why aren't updated AlarmEvents showing in SBO

[sesa197614_brid]

As my developing the EWS Server to generate Alarm Event, I come across a confused problem.

There is one requirement that I receive the alarms from third party and display them in SBO, for this case, I created an EWS server, and override the function of MongooseGetAlarmEventsProcessor()

My override function is as:

protected override void PushDataOntoResponse(GetAlarmEventsResponse1 response, List<AlarmEventsType> pageOfData, bool isLastPage)

        {

            List<AlarmEventsType> newEventList = new List<AlarmEventsType> { };

            //My custom function to receive alarms from third party

            var retrievedAlarms = ReceiveTrap.AlarmList;

            foreach (var newItem in retrievedAlarms)

            {

                newEventList.Add(new AlarmEventsType { Acknowledgeable = "1", SourceName = "TestSample", State = newItem.Alarmstate, ID = newItem.ID, Message = newItem.AlarmText, SourceID = newItem.Source, Priority = newItem.Priority });

            }

            base.PushDataOntoResponse(response, newEventList, isLastPage);

        }

In this way, I DO get all alarm events in SBO and I could also acknowledge the alarms with my another override function.

However , My problem is:

All the alarms from EWS server cannot be updated automatically, now I only found I can update alarms by changing the alarm polling parameters of EWS interface and save.

I guess I override the wrong function of MongooseGetAlarmEventsProcessor, or I still need trigger some flag in the processor , to make alarms be auto updated by polling of client?

Please kindly help for it.

Cheers

Austen Yin

[sesa180908_brid]

Austen,

There are three approaches you can use to provide custom data to an EWS Client.  I'll paste in some text from the soon to be updated Developer's Guide to explain:

4.2 Providing Data to an EWS Client

While StuxureWare Building Operation ASs and ESs are the most likely EWS clients you will be integrating with, any system which is can consume an EWS 1.1 or EWS 1.2 feed can be integrated with your SmartConnector enabled solution.  SmartConnector provides fast, EWS 1.2 compliant, database backed, EWS Servers for this purpose. 

Where the data served originates depends on whichever technique works best for your solution.  Generally, there are three data management techniques used to manage EWS data: asynchronous data management, synchronous data management, or a hybrid approach which uses both asynchronous and synchronous methods.  While each technique comes with its own complexities and pros and cons, asynchronous data management is the easiest method to implement and the more common technique used.

4.2.1 Asynchronous Data Management

Asynchronous data management involves provisioning a native SmartConnector EWS server via the portal (see SmartConnector Installation and Configuration Guide) or through code using the EwsServerDataAdapter class.

Regardless of the provisioning approach, the data served would be stored in the SmartConnector database and managed asynchronously to the inbound client calls.  This is typically done with one or more custom Processors which maintain the data using the aforementioned EwsServerDataAdapter class.

Pros:

• Serve performance is fast.

• Simpler to implement. 

Cons:

• Served data may be stale between refresh cycles of the update Processor.

4.2.2 Synchronous Data Management

Synchronous data management involves provisioning a native SmartConnector EWS server via the portal (see SmartConnector Installation and Configuration Guide).  Once provisioned, all data is retrieved and served synchronous to the client request.  This is accomplished by creating custom EWS Server request processors for every EWS method to be supported.

Pros:

• Greater customization is achievable.

Cons:

• Serve performance is typically slower.

• Harder to configure.

• More involved to implement.

4.2.3 Hybrid Data Management

While synchronous data management offers a higher degree of customization, most solutions typically only require synchronous actions to support write, force, and unforce methods.  In these or similar situations, a hybrid approach is usually the best. 

Hybrid solutions are asynchronous solutions where only those method(s) which need to be performed synchronously are overridden from the base implementation. 

Pros:

• Serve performance is fast for reads.

• Allows selective customization.

Cons:

• Served data may be stale between refresh cycles of the update Processor.

• Harder to configure.

• Incrementally more involved to implement.

You choose to implement the Synchronous approach.  While what you did is certainly correct, it is only half of the battle.  When a client retrieves alarm data, there are two calls at work GetAlarmEvents and GetUpdatedAlarmEvents.  Since you only choose to provide custom GetAlarmEvents logic, the EWS Client (SBO) is making GetUpdatedAlarmEvents calls to get updates to what it already knows about and it is hitting the standard handler - which doesn't know about the data you already served.

You have two options here.

1. Supply custom GetUpdatedAlarmEvents logic (similar to what you did with GetAlarmEvents) that would respond to the client with updates since the "LastUpdate" value you originally returned in the GetAlarmEvents response.

2. Switch to an Asynchronous approach.  This would involve using a standard SmartConnector EWS Server and then creating a Processor which would poll your Alarm source and update the SmartConnector database accordingly (use the EwsServerDataAdapter class as referenced above).  The benefits to this approach is that you do not need to concern yourself with the idiosyncrasies of GetAlarmEvents, GetUpdatedAlarmEvents, and paging.

Hope this helps.

Mark

[sesa197614_brid]

Thanks Mark, by overriding both the function of GetAlarmEvents and GetUpdatedAlarmEvents, I get the right result.

One more question, I found there is no way to set the "Count" of alarm, could you please help me point out which attributes of "EwsAlarmEvent" or "AlarmEventsType" will be binding with "Count", or the "Count" will be always "0", that's incorrect.

[sesa180908_brid]

The "Count" isn't an EWS thing so I'm not sure there is anything you can do in your custom EWS Server that can control that. 

If others know how/where SBO derives this information, please update this thread.