Я полагаю, что причина возникновения тайм-аута в том, что между отправкой запроса и получением ответа нет связи по протоколу TCP.Если для флага TCP KeepAlive установлено значение true, клиент будет периодически пинговать сервер, чтобы сбросить период ожидания.
Это будет наилучшим способом.Однако соединения Acumatica довольно высокого уровня, поэтому я не думаю, что вы сможете легко получить доступ к этому флагу.Сначала я попробую в сценарии, в котором не задействовано внешнее приложение, обернуть код обработчика событий действия в блок PXLongOperation, который должен выполнить нечто подобное, чтобы поддерживать соединение под капотом:
PXLongOperation.StartOperation(this or Base, delegate
{
your code here
});
Когда я сталкиваюсь с тайм-аутами в Acumatica, которые не могут быть решены с помощью PXLongOperation, я выбираю самый простой способ - увеличение тайм-аута IIS в файле Web.Config
.Я не уверен, что ваш вариант использования с внешним приложением будет хорошо работать с async PXLongOperation.Обработчик вернется преждевременно, и клиент не сможет получить асинхронную полезную нагрузку.
Так что вам, возможно, придется увеличить время ожидания.Насколько я знаю, нет практического недостатка в этом, если только ваш сайт не находится под угрозой DOS-атак.
Вы можете найти и отредактировать файл Web.Config
вашего экземпляра Acumatica, используя программу inetmgr
, если выявляются хостингом Acumatica.В противном случае поговорите с вашим контактом SAAS, чтобы узнать, так ли это.
Я почти уверен, что у вас истекло время ожидания IIS.Контрольный знак будет разорван через 5 минут, что является значением по умолчанию 300 секунд.Вы можете редактировать файл Web.Config для увеличения значения executionTimeout
.Также неплохо увеличить maxRequestLength
, если вы запрашиваете большой объем данных у API Acumatica, так как это также распространенная причина сбоя, который вы пропускаете при тестировании и возникает в реальных сценариях:
<httpRuntime executionTimeout="300" requestValidationMode="2.0" maxRequestLength="1048576" />