C_CPI Integration Suite Development Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use the adapter's client-driven paging with $skip and $top parameters and manually increment them in a loop using a looping process call.

  Why it's wrong here

  Client-driven paging is supported by the adapter, but it requires the developer to manage $skip and $top values and to implement a loop with a process call. This is more complex and error-prone than server-driven paging. The scenario states the service supports server-driven paging, so relying on the adapter's server-driven option is the intended, simpler configuration.

• ✓

  Set the adapter's paging option to server-driven and configure a maximum page size, so the adapter follows the __next link until all pages are consumed.

  Why this is correct

  The OData V2 receiver adapter supports server-driven paging. When enabled, the adapter respects the service's __next link and automatically requests subsequent pages, aggregating the results into a single message. Configuring a page size controls how many records are requested per call, and the adapter continues until no next link remains, which meets the requirement to collect all records.

• ✗

  Enable the adapter's batch processing option so that all records are returned in a single OData batch response without paging.

  Why it's wrong here

  OData batch processing groups multiple operations into one HTTP request, but it does not eliminate server-driven paging for large result sets. A batch response still contains individual responses that may be paged. Batch is used for combining operations, not for retrieving an entire large entity set in one response, so it does not satisfy the requirement.

• ✗

  Set the adapter's operation to Query with a large $top value equal to the expected total number of records to force the service to return all records at once.

  Why it's wrong here

  Setting a large $top may be ignored or capped by the service, and it does not handle server-driven paging. The service decides page size and may still return a __next link. Relying on $top to return all records is unreliable and can cause timeouts or memory issues, so it is not the correct approach when server-driven paging is available.