StateInfo in RIS SelectCMDevice call with 200+ devices

Version 1
    This document was generated from CDN thread

    Created by: Gena Shumakher on 18-05-2009 07:39:06 AM

    We try to find exact definition of the state that is represented by the StateInfo key contained in the response of CmSelectDevice method from RIS Web Service API. We perform a call where the selection criteria contains the class of the device (`Phone¿), the selection type (`By Name¿) and the status (`Registered¿) but doesn¿t contain the MaxReturnedItems or specific names of the device:
          <soap:SelectCmDevice soapenv:encodingStyle="">
             <StateInfo xsi:type="xsd:string" />
             <CmSelectionCriteria xsi:type="soap:CmSelectionCriteria">
                <Class xsi:type="xsd:string">Any</Class>
                <Status xsi:type="xsd:string">Registered</Status>
                <SelectBy xsi:type="xsd:string">Name</SelectBy>

    In our case (because there is more than 200 registered devices) the first call (with empty state info in the request) will return 200 results and state info id. The question is whether the state that is identified by this id, refers to the returned 200 devices or to the all devices that matched the query (event if they are not included in the first response). When we perform the second call with state info returned by the first one, can we assume that if another phone was registered between the first and the second call  the response will identify that a change in the state has occurred.

    It seems that this behavior is not documented clear enough and from documentation, one can understand either the state info represents only the returned devices  or it represents all devices that match selection criteria (even devices that were not returned).

    Thanks for help.

    Subject: RE: StateInfo in RIS SelectCMDevice call with 200+ devices
    Replied by: David Staudt on 18-05-2009 02:06:37 PM
    From what I've been able to find out, the service will calculate the stateinfo based on all of the devices in the query (no 200 limit.)  After that, when the XML response is being built, the 200 limit is enforced and results are truncated.
    If the application queries again using the same criteria and providing the returned stateinfo, then any change in the entire result set (not just the 200) will be reflected in the stateinfo.  I believe this confirms your speculation.
    Some possible considerations:
    -If the initial set of criteria includes a large number of devices (many hundreds or thousands), then the subsequent stateinfo queries - even if there is no change - may have a significant performance impact on UCM.  You will want to test this carefully.
    - If a large registration event occurs - like a UCM failover - the # of changed devices could easily exceed 200, in which case you would lose some statuses