Hi All!
Our Workday aggregation starts fine but after few hours of running, it fails with following error. Has anyone seen this error?
We have following setting in our connector:
<entry key="ChunkSize" value="750"/> --changed to 350 that did not help
<entry key="aggregationThreadSize" value="4"/>
<entry key="version" value="44.2"/>
Exception during aggregation. Reason: openconnector.ConnectorException: Aggregation failed in one or more thread execution:: exception : openconnector.ConnectorException: [ ConnectorException ] [ Error details ] Exception : <?xml version="1.0" encoding="utf-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><SOAP-ENV:Fault xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wd="urn:com.workday/bsvc"><faultcode>SOAP-ENV:Server.processingError</faultcode><faultstring>Processing error occurred. Page 1 must be requested first.</faultstring><detail><wd:Processing_Fault><wd:Detail_Message>Page 1 must be requested first.</wd:Detail_Message></wd:Processing_Fault></detail></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>
@kpudasaini This is a known issue with the Workday SOAP API and multi-threaded aggregation in SailPoint IIQ. We also used to get this error in our environment.
When aggregationThreadSize is set to a value greater than 1, multiple threads attempt to fetch pages concurrently. If a thread tries to request a page (e.g., Page 2, 3, etc.) before Page 1’s response is fully processed or if the Workday session times out after hours of running, Workday returns this error.
The session/cursor on the Workday side can expire during long-running aggregations, forcing the connector to restart pagination — but the subsequent threads don’t know to re-request Page 1
Can you please try reducing the aggregationthreadSize to 1.. basically run it on a single thread and also with ChunkSize to 200?
SailPoint documents this exact “Page 1 must be requested first” error and recommends lowering the page size (Workday Troubleshooting). Since 350 already failed, the single-thread test is the important additional change here.
If it still fails, I would capture the aggregation logs and raise it with SailPoint Support.
The Page 1 must be requested first error points to a pagination issue on the Workday side. Since the aggregation runs successfully for a few hours before failing, I would first look at the pagination/session handling rather than the chunk size.
SailPoint’s Workday connector troubleshooting documentation recommends reducing the Page Size to improve aggregation stability, so that would be the first thing I’d try.
Since you’ve already changed the chunk size to 350, I’d also try reducing the aggregation thread count temporarily, for example to 1 or 2. This can help determine whether multiple threads are causing an issue with the pagination context.
It would also be worth checking the Workday side for any session or web-service timeout settings, especially because this is a long-running aggregation.
