APLM0012 при выполнении требований РСХН

Добрый день, хотелось бы услышать мнение интеграторов - при выполнении требований РСХН уменьшилось ли количество APLM0012? Я вот по логам посмотрел и понял что единственный параметр который влияет на количество APLM0012 - близость приказов о добавлении продукции в список декларируемого через ЭВСД. Чем ближе тем больше, причем какой либо корреляции между выполнением требований РСХН и количества APLM0012 я не нашел.

Vladimir2017 wrote:Добрый день, хотелось бы услышать мнение интеграторов - при выполнении требований РСХН уменьшилось ли количество APLM0012? Я вот по логам посмотрел и понял что единственный параметр который влияет на количество APLM0012 - близость приказов о добавлении продукции в список декларируемого через ЭВСД. Чем ближе тем больше, причем какой либо корреляции между выполнением требований РСХН и количества APLM0012 я не нашел.

Это будет работать, если все участники рынка будут соблюдать требования. Так как ограничение идет не на каждый ХС, а в общей массе на всех.
Это как с перекрестком в час пик. Все спешат проехать и выезжают на сам перекресток, хотя знаю что не проедут. И соответственно с другой стороны тоже не могут проехать, ведь перекресток забит. так все и стоят

О выполнении каких конкретно требованиях идёт речь?

APLM0012 имхо, это ограничитель общей очереди запросов, чтобы очередь не росла до бесконечности.

Вот чем больше таких интеграций, тем больше будет APLM0012 для всех.
http://vetrf.ru/vetrf-forum/posts/list/9130.page;jsessionid=acc5e6062e9ea11aa8c947dd9c7b

Мы заметили если задачи например по запросам новых ВСД стоят на 00 минут или 30 минут, они чаще получают APLM0012, чем в другое время.

dk wrote:О выполнении каких конкретно требованиях идёт речь?

На память, несколько:
1) Не запрашивать каждый раз остатки, а хранить в системе. Загрузка только один раз. Был пример одной интеграции, где при выборе партии, каждый раз шел запрос на остатки в Меркурий

2) Аналогично с входящими ЭВСД, не запрашивать каждый раз все входящие, а подгружать только новые. Хранить дату последнего запроса.
3) Хранить справочники в системе и обновлять их, а не запрашивать каждый раз.

oleg-x wrote:

dk wrote:О выполнении каких конкретно требованиях идёт речь?

На память, несколько:
1) Не запрашивать каждый раз остатки, а хранить в системе. Загрузка только один раз. Был пример одной интеграции, где при выборе партии, каждый раз шел запрос на остатки в Меркурий
2) Аналогично с входящими ЭВСД, не запрашивать каждый раз все входящие, а подгружать только новые. Хранить дату последнего запроса.
3) Хранить справочники в системе и обновлять их, а не запрашивать каждый раз.

Тогда мы даже в какой-то степени помогаем Меркурию, т.к. у нас одни справочники для всех клиентов и ни одного лишнего запроса))

oleg-x wrote:

Vladimir2017 wrote:Добрый день, хотелось бы услышать мнение интеграторов - при выполнении требований РСХН уменьшилось ли количество APLM0012? Я вот по логам посмотрел и понял что единственный параметр который влияет на количество APLM0012 - близость приказов о добавлении продукции в список декларируемого через ЭВСД. Чем ближе тем больше, причем какой либо корреляции между выполнением требований РСХН и количества APLM0012 я не нашел.

Это будет работать, если все участники рынка будут соблюдать требования. Так как ограничение идет не на каждый ХС, а в общей массе на всех.
Это как с перекрестком в час пик. Все спешат проехать и выезжают на сам перекресток, хотя знаю что не проедут. И соответственно с другой стороны тоже не могут проехать, ведь перекресток забит. так все и стоят

Если не ошибаюсь позиция РСХН была именно такой: выполняешь требования - не получаешь aplm0012. Т.е. тут идет конкретная стимуляция на разработку правильного решения. По факту, полагаю, что разработчики корректных решений получают ни чуть не меньше балансировки чем те, кто дергает ВетИС как хочет.

Vladimir2017 wrote:Если не ошибаюсь позиция РСХН была именно такой: выполняешь требования - не получаешь aplm0012. Т.е. тут идет конкретная стимуляция на разработку правильного решения. По факту, полагаю, что разработчики корректных решений получают ни чуть не меньше балансировки чем те, кто дергает ВетИС как хочет.

Градация должна быть, но не по ХС, так как, тогда надо будет анализировать каждый ХС и хранить статистику, а по запросам. То есть чем больше запрос, тем дальше он в очереди, тем больше шанс в пик получить отказ. Но опять же, это все было на словах, как сделали в итоги и сделали вообще, ни кто не знает, кроме разработчиков.

oleg-x wrote:

dk wrote:О выполнении каких конкретно требованиях идёт речь?

На память, несколько:
1) Не запрашивать каждый раз остатки, а хранить в системе. Загрузка только один раз. Был пример одной интеграции, где при выборе партии, каждый раз шел запрос на остатки в Меркурий
2) Аналогично с входящими ЭВСД, не запрашивать каждый раз все входящие, а подгружать только новые. Хранить дату последнего запроса.
3) Хранить справочники в системе и обновлять их, а не запрашивать каждый раз.

Тестовый контур.
Как верно поступить в таком случае? - запрос списка ВСД. Пример партии во входящем ВСД:
<ns5:batch>
<ns5:productType>5</ns5:productType>
<ns5:product>
<ns4:uuid>31c94ff1-a217-f38d-6005-1aa5ca67e146</ns4:uuid>
<ns4:guid>d34504bb-7a93-e1c8-4859-339eafd97c6c</ns4:guid>
</ns5:product>
<ns5:subProduct>
<ns4:uuid>47751a40-18ac-36c7-0bfb-d9c48b4e1f79</ns4:uuid>
<ns4:guid>8563650a-c1e1-11e8-e641-179e41a60918</ns4:guid>
</ns5:subProduct>
<ns5:productItem>
<ns6:name>йогурт (0403)</ns6:name>
</ns5:productItem>
<ns5:volume>13.0</ns5:volume>
<ns5:unit>
<ns4:uuid>069792f0-053d-11e1-99b4-d8d385fbc9e8</ns4:uuid>
<ns4:guid>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</ns4:guid>
</ns5:unit>

В случае, если в справочнике учетной системы еще нет таких идентификаторов, приходится запрашивать все отдельно, иначе получается, что имеем только uuid и guid - пользователю системы это ничего не даст.
Аналогично и с другими справочными данными: Отправитель, Получатель, то есть ХС+обслуживаемые предприятия - соответствующие методы. В итоге получается, что только при обработке 1-го нового ВСД от нового поставщика имеем ряд каскадных вызовов методов.

Как быть с актуальностью данных?:
Так как данные справочники хранятся в учетной системе, то с какой периодичностью необходимо их обновлять или можно в исключительных случаях подтягивать актуальные данные непосредственно при получении ВСД?

Как быть с такой продукцией?, - отсутствует UUID:
<ns5:productItem>
<ns6:name>йогурт (0403)</ns6:name>
</ns5:productItem>

Есть ли отличия тестового контура от продуктивного с точки зрения заполнения структуры данных? - может там все заполнено, и действительно, нет необходимости обращаться к доп. методам.

Если говорить про справочники, то на мой взгляд
адресов, номенклатуры 4 ур., площадки, ХС, производители запрашивать по мере поступления информации ибо это самые большие справочники и нет смысла хранить весь справочник в базе. Если надо обновить, то при возникновение ошибок или принудительном запросе пользователя.
Всякие условия регионализации, условия перевозки, цели, номенклатуры 2-3 ур, можно загрузить разово и обновлять запросом изменения за интервал раз в месяц или по запросу пользователя или при возникновение ошибок.
Различий между тестовым и рабочим контуром, по структуре не должно быть, только по заполнению информации.
А вообще, работа со справочниками не вызывает сильной нагрузки, так как эти данные обрабатывает отдельная подсистема и к ней нет, такого большого количества запросов, как обработке заявок.
Покрайне-мере ни разу не было ошибок при обращение к справочникам.

oleg-x wrote:

dk wrote:О выполнении каких конкретно требованиях идёт речь?

На память, несколько:
1) Не запрашивать каждый раз остатки, а хранить в системе. Загрузка только один раз. Был пример одной интеграции, где при выборе партии, каждый раз шел запрос на остатки в Меркурий
2) Аналогично с входящими ЭВСД, не запрашивать каждый раз все входящие, а подгружать только новые. Хранить дату последнего запроса.
3) Хранить справочники в системе и обновлять их, а не запрашивать каждый раз.

А если не по памяти, есть какая-нибудь ссылка какой-нибудь документ или письмо или новость на этот счёт.

не статья, а встреча, где это разбирали
https://vk.com/mercuriy_rf?z=video-167196368_456239025%2F350e901c2b572da86c%2Fpl_wall_-167196368