Skip to main content

We are getting the below warning messages in the Events tab for PSO

‘Warning GWY Timeout waiting for appointment broadcast’

Need to investigate reason behind the above warning message 

Any suggestion

I assume your other broadcasts (DSE etc) and usual communication (new activities etc.) are working fine.

By default there is a 30 sec timeout for Polling broadcasts and if PSO cannot return offers within 30 secs it will return this timeout. First, increase the AppointmentRequestPollingTimeout parameter may be to 2 minutes and check whether only the delay is there or broadcast is failing due to some other reason. If there is any other reason, this will record in event log. 

If ABE takes 30+ secs to generate offers,

  1. .If HTM is connected and Routing is used, test again by turning off Routing.
  2. Check whether memory utilization of environment is within limits. If the environment is Azure, check for DTU hits.

I assume your other broadcasts (DSE etc) and usual communication (new activities etc.) are working fine.

By default there is a 30 sec timeout for Polling broadcasts and if PSO cannot return offers within 30 secs it will return this timeout. First, increase the AppointmentRequestPollingTimeout parameter may be to 2 minutes and check whether only the delay is there or broadcast is failing due to some other reason. If there is any other reason, this will record in event log. 

If ABE takes 30+ secs to generate offers,

  1. .If HTM is connected and Routing is used, test again by turning off Routing.
  2. Check whether memory utilization of environment is within limits. If the environment is Azure, check for DTU hits.

@Sajith Anushan   We have increased the AppointmentRequestPollingTimeout parameter to 2 minutes and switched off the HTM but we are getting timeout error in the event Logs


Hi,

Then worth checking some mandatory information is missing in appointment request (Location details etc.). Usually, if some mandatory information missing, ABE cannot generate offers. But GWY is looking for the offers until the time period mentioned by above parameter and if the offers are not returned, throwing that warning. 

Regards,

Sajith


Hi,

Out of curiosity, are you using a unique Appointment_Request.id in each payload you're sending in?

Thank you


@GeorgeFeghali great catch!

@TatSrikaD If you are manually sending the payloads, appointment request id should be unique. Otherwise this will also not returning any slots resulting in the said warning.