Feature request: receiving initial event snapshot / bulk loading

[ssteiner]

I've made this request before for OTMS but they wouldn't hear me - hopefully this will work out better on O2G

When an application starts up, e.g one that would do CTI and thus monitors calls and call routing, you need an initial state. So, at the moment, before you make the subscription, you would load the current call state of all devices that you're interested in. Depending on your system size, this means thousands of requests. Of course you can parallelize, but there's a sweet spot after which you'll just bog down the system instead of speeding things up. It would be useful to have the means to do this more efficiently.

One way would be to indicate that you want an initial event snapshot when you make the subscription. So you'd immediately get the current call state / routing state for all the users you've subscribed for (assuming you're subscribing for telephony and routingManagement) . So if a user is in a call when your application starts, you know.

Alternatively, it would be useful to have a way to get these states in bulk. So instead of thousands of requests to GET /telephony/calls?loginName=oxeXXXX, you'd have a way to do a POST, providing a list of loginNames, and you'd get their state. Again, focus on telephony and routing state.

Now, you might say... for telephony.. what kind of OnCallXXX would be sent? I'd say OnCallCreated.. if you're extracting the info, you'd get the call(s) without the info about since when they're active, too. So the initial snapshot would send an OnCallCreated even if the call isn't new. But the CTI App could do whatever needs doing (if somebody thinks it would be useful an optional isSnapshop tag could be added to the event so you know what's a snapshot and what isn't)

I hope you consider this. I think it would help us write more efficient solutions. At the moment I have a tool that when fully rolled out will do about 3.5k users.. that's a lot of state loading at startup.

[yblanchard]

In order to optimize the start of the application when the telephony state of all the users is required to its initialization, the following solution is proposed:
- New method POST …/telephony/state/snapshot([?loginName=xxx] which doesn’t return any answer but triggers an event (OnTelephonyState) on the events channel of the user concerned by the request.
- If the request is done by an administrator account and no loginName is asked, then an event will be individually sent for each user of the system (and which corresponds to at least one subscription).

It requires the application to do the subscription at first, prior to do any request (NB: this principle must already be respected by any application to be sure to not miss any state change).

This method is preferable to a bulk response or a bulk event which would contain the data for all users, for the following reason: a bulk response would need to freeze the O2G telephony automaton for the whole time the bulk is built and this for an undefined period. This freezing would be necessary to insure a consistency of data in the bulk (in case new telephony events are received from the pbx on a user during the bulk is built).

In the opposite, sending the data in individual event is not blocking and allows to continue to update the telephony model in real time.

The data will be sent in a new OnTelephonyState (which will contains the same structure than the GET …/telephony/state response) and not re-using an existing event like OnCallCreated which would be confusing on a subscription which would already receive the true one at call creation and would receive another one on snapshot request.

NB: The snapshot request is immediately acknowledged but the processing of all the users may take a long time in case of huge number of users and specially if the system has been recently started.
If a second snapshot request is asked since the first is always running, the second request is acknowledged but with no effect.

For the the routing state of the users, the same method is proposed: …/routing/state/snapshot([?loginName=xxx] which triggers an event (OnRoutingStateChanged) on the events channel of the user concerned by the request.

In order to facilitate the subscription, the filter with id="*" (means to subscribe for all users) will become possible for an administrator session only. In case of huge number of users, this solution is highly recommended instead of using a big filter of user list, which would penalize the internal system map.