Paging Based on Limit-Offset

This section describes paging based on limit-offset for ServiceNow and Workday managed systems.

For ServiceNow

For example, the initial aggregation URL for ServiceNow managed system would be as follows:

https://XYZ.service-now.com/api/now/v1/table/sys_user?sysparm_limit=100&sysparm_fields=sys_id

The above URL includes the following parameters:

  • baseUrl – https://XYZ.service-now.com

  • relativeURL – api/now/v1/table/sys_user?sysparm_limit=100&sysparm_fields=sys_id

Following are the configuration steps in the paging tab based on limit-offset:

  1. Use the following for ServiceNow managed system:

    Copy 
    $sysparm_limit$ = 100
    TERMINATE_IF $RECORDS_COUNT$ < $sysparm_limit$
    $sysparm_offset$ = $sysparm_offset$ + $sysparm_limit$
    $endpoint.fullUrl$ = $application.baseUrl$ + "/api/now/v1/table/sys_user?sysparm_fields=sys_id&sysparm_limit=100&sysparm_offset=" + $sysparm_offset$

    In the above example, maximum record count has been set using sysparm_limit and RECORDS_COUNT. In this case RECORDS_COUNT represents the number of records fetched from the response and sysparm_limit can be changed as required.

    Based on the above step the next page URL will be as mentioned in the steps below.

  2. Second page URL based on paging steps configuration:

    https://XYZ.com/api/now/v1/table/sys_user?sysparm_limit=100&sysparm_fields=sys_id&sysparm_offset=100

  3. Third page URL based on paging steps configuration:

    https://XYZ.com/api/now/v1/table/sys_user?sysparm_limit=100&sysparm_fields=sys_id&sysparm_offset=200

The paging would be terminated when the RECORDS_COUNT is less than the sysparm_limit as follows:

$RECORDS_COUNT$ < $sysparm_limit$

For Workday

For example, the initial aggregation URL for Workday managed system would be as follows:

https://XYZ.workday.com/ccx/service/sailpoint_pt1/Human_Resources/v24.1

The above URL includes the following parameters:

  • baseUrl – https://XYZ.workday.com

  • relativeURL – /ccx/service/sailpoint_pt1/Human_Resources/v24.1

Following are the configuration steps in the paging tab based on limit-offset:

  1. Use the following for Workday managed system:

    Copy 
    TERMINATE_IF $response.wd:Response_Results.wd:Page$ > $response.wd:Response_Results.wd:Total_Pages$
    $offset$ = $response.wd:Response_Results.wd:Page$ + 1
    $request.bsvc:Response_Filter.bsvc:Page.text()[1]$ = $offset$

    In the above example, the number of pages is verified with response from Workday and compared with the total number of pages.

    If the current page number is less than total pages, then the request body (SOAP BODY) is updated with the new page by incrementing it.

    The following is an example of initial payload request with Initial Page Size (the initial page would be the beginning index) as 1 and Page Size (number of records per page) as 10:

    Copy 
    <soapenv:Body>
    <bsvc:Get_Workers_Request bsvc:version="v24.1">
    <bsvc:Request_Criteria>
              ....
              ....
              </bsvc:Request_Criteria>
             <bsvc:Response_Filter>
      <bsvc:Page>1</bsvc:Page> 
      <bsvc:Count>10</bsvc:Count>
    </bsvc:Response_Filter>
     
            <bsvc:Response_Group>
              ....
              ....
            </bsvc:Response_Group>
            </bsvc:Get_Workers_Request>
       </soapenv:Body>

  2. Based on the previous paging step, the next payload is as follows:

    The second aggregation payload: Incrementing offset (page number)

    Copy 
    <soapenv:Body><bsvc:Get_Workers_Request bsvc:version="v24.1">
    <bsvc:Request_Criteria>
              ....
              ....
              </bsvc:Request_Criteria>
             <bsvc:Response_Filter>
      <bsvc:Page>2</bsvc:Page>
     
      <bsvc:Count>10</bsvc:Count>
    </bsvc:Response_Filter>
     
            <bsvc:Response_Group>
              ....
              ....
            </bsvc:Response_Group>
            </bsvc:Get_Workers_Request>
       </soapenv:Body>