Bulk Retrieve - not supported with EWS REST Provider

[SteveGregory]

Are there any plans to make features like Bulk Retrieve available in the EwsRest provider, like they are in the SboRest provider? These sorts of requests can make third party integrations much easier as they don't have to work their way through the tree to discover all the relevant points. I would really like to see things like GET /Values and GET /Trends work with the EwsRest provider.

[ardak · Accepted solution]

Hi Steve,

Bulk retrieve will never be available in the EWS provider, since EWS unfortunately doesn't support it.

We are looking into other ways of improving the REST gateways capabilities, hopefully including some kind of bulk retrieve capability.

BR

Armend

[SteveGregory]

Hi Armend, 

Thanks for that info.

Are there any plans to update the SboRest provider which did support it?

Steve

[ardak]

That is one of the options that we are looking into. Todays implementation has some drawbacks since it's tied to one version of EBO, which even if updated, would have compatibility problems both backwards and in the future. We are looking into ways of mitigating this.

BR

Armend

[LucasJohnsson]

Hi Armed!

I have customer whom ran into this problem when they want to bulk retrieve status of all the current alarms through EWS REST Provider. 
Do you have any update on on this topic? 🙂

BR
Lucas Johnsson

[ard]

Hi,

This functionality exists in todays EWS Rest Provider. GET/AlarmEvents if I'm not mistaken.

--Armend

[LucasJohnsson]

Hi!

Yes, you're right. But that method is a bit trickier do deal with on the receiving end. GET/AlarmEvents retrieves a long list of every alarm event instead of have known alarm-objects that simply refreshes it's alarm-status.

In detail; GET/AlarmEvents, at first, store the current status of defined alarm in EBO in SC's cache. All subsequent GET/AlarmEvents will just add new events to the event list in SC's cache. This makes it that the same alarm object can have several posts in the list depending on the alarms' state have changed.

Sure, the system integrators can still use GET/AlarmEvents, but then they have to apply some filters that ignores all but the most latest event for a specific alarm object.

Or are there an more easier and existing method for "syncing" EBO's alarm view outwards?

BR
Lucas Johnsson

[ard]

True, I'm not a big fan of how cached events are exposed, ideally only the latest event should be in the list. However in practice using the filters, keeping track of the last time you asked for the AlarmEvents should work fine!

--Armend