CFG Environment Cloud to PSO Dataset load still running (potential Dataset locks)

 we changed the control parameter to PARALLEL_BATCH_QUEUE = 0 and performed the “Initialize Parallel Batch Queues” action. This removed the parallel batch queue configuration. (Now there is only one queue available as expected — Scheduling Optimization Queue.) After the change, the control parameter was set back to the default “*”.

and monitored whether the initially reported warning occurs "Error: SchedulingUtility.DATASET_IS_UPDATING: Dataset 'HML' is updating currently. Please try again in a few moments." again:

If so, we can change DATASET_LOCK_TIMEOUT = 60 or 45 as recommended. 

then the customer shared:

error in application messages:
ifs.fnd.base.SystemException: ExecutionException from Sender thread Caused by: ifs.fnd.connect.senders.ConnectSender$TemporaryFailureException: Exception while sending data Caused by: ifs.fnd.connect.http.InternalServerErrorException: InternalServerErrorException: 500#<ApiResponse xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/RESTfulGateway.ResponseObjects"> <Code>3</Code> <Message>FAILED</Message> <Type i:nil="true" /></ApiResponse>

and they have followed the next recommended step to change DATASET_LOCK_TIMEOUT = 60.But still the error is there.

then we took PSO assistance and shared below update:

We reviewed the application error "ifs.fnd.base.SystemException: ExecutionException from Sender thread Caused by: ifs.fnd.connect.senders.ConnectSender$TemporaryFailureException: Exception while sending data Caused by: ifs.fnd.connect.http.InternalServerErrorException: InternalServerErrorException: 500#<ApiResponse xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/RESTfulGateway.ResponseObjects"> <Code>3</Code> <Message>FAILED</Message> <Type i:nil="true" /></ApiResponse>"

This indicates that:
The IFS Connect Sender thread successfully attempted to send data
But the PSO REST endpoint rejected the request internally
Resulting in a HTTP 500

In similar scenarios, this can occur when mandatory attributes in the payload contain NULL or invalid values. Since the PSO REST API returns a generic 500 error without detailed validation feedback, data-level issues may surface as an Internal Server Error on the sender side.

We reviewed this in PSO end. There were timeout errors thrown by the PSO SRG service. Upon reviewing the audit logs, we observed that PSO ignores these activities because no duration is defined at either the activity or activity type level. (Refer to the attached screenshot and task CSTASK0265155) As a result, the activities are excluded from scheduling, no offers are generated, and therefore no response is returned to the appointment requestor via SRG.

Consequently, the request times out exactly 30 seconds after submission, as the default gateway timeout parameter (AppointmentRequestPollingTimeout) was set to 30 seconds. This may be the reason we are seeing 500 errors when appointment booking in IFS Cloud side.

Could someone kindly advise us on how to proceed further as the error still occurs.

Thank you!

BR,

Krishari