We’re experiencing 504 Gateway Timeout errors when posting consolidated journal entries via OData API during month-end close. Our integration sends batch requests with 200-300 journal entries per payload to SAP S/4HANA 1809.
The timeout occurs inconsistently - sometimes after 60 seconds, sometimes after 90 seconds. We’ve tried adjusting the batch size and implementing retry logic, but the issue persists during peak processing periods.
POST /sap/opu/odata/sap/API_JOURNALENTRY_SRV/$batch
HTTP/1.1 504 Gateway Timeout
Content-Length: 0
Our current batch request structure uses change sets with transaction boundaries, but we’re unsure if payload optimization or chunking strategy needs adjustment. The API timeout configuration on both SAP Cloud Integration and S/4HANA backend might need tuning. Any guidance on proper change set transaction handling for large consolidation volumes?
The 504 errors during month-end suggest your batch size exceeds the processing window. For consolidated journal entries, I’d recommend chunking batches to 50-75 entries maximum. Large change sets can cause transaction locks that contribute to timeouts.
Check your SAP Cloud Integration timeout settings in the OData adapter configuration. Default is typically 60 seconds. You’ll also need to verify the ICM timeout parameters on the S/4HANA backend - icm/server_port_* and rdisp/max_wprun_time are key. We had similar issues and found the backend timeout was terminating long-running transactions before the integration layer timeout kicked in. Also, are you using $batch with multiple change sets or one large change set? Splitting into multiple change sets can help isolate transaction boundaries.
We’re using single change sets per batch request. The SAP Cloud Integration timeout is set to 120 seconds, but we haven’t checked the backend ICM parameters yet. Would splitting into multiple change sets per batch improve performance even if total entry count stays the same?