|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
ошибка APLM0012 An unexpected error has occurred while invoking target service operationon  XML
Индекс форума » Автоматизированная система МЕРКУРИЙ
Автор Сообщение
shmuylovich


Зарегистрирован: 29/05/2019 11:09:47
Сообщений: 6
Оффлайн

dk wrote:Не ломайте голову как бы вы не извращались с датами и т.п. избавится от APLM012 не получится. Её можно победить только повторными запросами, пока не получите результат.
Мы пришли к выводу, что ошибка возникает от загрузки самого шлюза, если очередь из запросов на шлюзе образовалась больше какого-то значения, то идёт APLM012, пока очередь не уменьшится.


Так получается, что создатели системы сделали все, чтобы шлюз перегрузить.
Если бы порядок записей в выдаче не менялся, можно было бы запросить маленькую порцию.
Если бы фильтр дат работал корректно, можно было бы запросить один день.

А так приходится постоянно прогружать весь массив записей! Это же чистое безумие!

shmuylovich


Зарегистрирован: 29/05/2019 11:09:47
Сообщений: 6
Оффлайн

Немного прояснилось с фильтром по дате.
Да, как я и догадывался, createDate - это все-таки не дата создания записи, а дата создания версии. А editDate - не дата редактирования, как было бы логично предположить, а дата создания последней актуальной записи.
Таким образом, получив список актуальных записей журнала, вам нужно каждую раскрутить до первой версии, чтобы получить реальную дату создания.
А фильтр таки работает правильно, но не по дате создания первой версии, а по дате создания актуальной версии.

С таким набором параметров инструмент крайне перегружает шлюз и делает алгоритмы запутанными.
dk

[Avatar]

Зарегистрирован: 03/11/2017 00:49:55
Сообщений: 410
Оффлайн

shmuylovich wrote:
dk wrote:Не ломайте голову как бы вы не извращались с датами и т.п. избавится от APLM012 не получится. Её можно победить только повторными запросами, пока не получите результат.
Мы пришли к выводу, что ошибка возникает от загрузки самого шлюза, если очередь из запросов на шлюзе образовалась больше какого-то значения, то идёт APLM012, пока очередь не уменьшится.


Так получается, что создатели системы сделали все, чтобы шлюз перегрузить.
Если бы порядок записей в выдаче не менялся, можно было бы запросить маленькую порцию.
Если бы фильтр дат работал корректно, можно было бы запросить один день.

А так приходится постоянно прогружать весь массив записей! Это же чистое безумие!



Не понял. Используйте Get....ChangesListOperation и запрашивайте с данные с последнего успешного запроса, это может быть хоть час, хоть день, хоть месяц.
Если исходные данные не менять, то порядок в выдаче не меняется.

Это сообщение было редактировано 1 раз. Последнее обновление произошло в 30/05/2019 14:33:06

https://Меркурий.рус - погасите все входящие ВСД по всем площадкам в 1 клик. Выписка ВСД и инвентаризация по сохранённым шаблонам. Тестовый контур - БЕСПЛАТНО.
https://play.google.com/store/apps/details?id=com.skysent.mercury.rus - Android приложение для группового гашения ВСД по QR-кодам. Новая уникальная возможность: сканируешь QR-код в смартфоне или планшете, а смотришь результаты в том числе на большом экране на сайте Меркурий.рус.
[WWW]
shmuylovich


Зарегистрирован: 29/05/2019 11:09:47
Сообщений: 6
Оффлайн

В GetStockEntryListOperation меняется.
Get....ChangesListOperation попробую, спасибо.
 
Индекс форума » Автоматизированная система МЕРКУРИЙ
Перейти:   

Powered by JForum 2.1.8 © JForum Team