Не работает меркурий

Просто для информации - у нас самописная интеграция на 2.1 API, "APLM0012" последний раз была 19.07.2018, после этого все запросы выполнялись штатно.
Правда ВСД выписываем мало, сотню-две в день, и, соответственно запрос по изменениям делается редко - 3-10 раз в день.

у меня в моменте тоже сыпятся аплмки, но границы запросов потихоньку двигаются
сейчас на синхронизации стоит 3 ХС и 10 площадок

27.07.18 7:59 стабильно APLM0012 при получении ВСД, интеграция самописная (затрудняюсь сказать по мнению Власова на сколько она кривая). Остатки никакие не синхронизируем, просто хотим принять ВСД без всяких зацикливаний запросов.
По ночам и выходным не работаем и не хотим. Рабочий день с 8 до 17.
P.S. Горите в аду архитекторы Мерка!

Уважаемые интеграторы!
Ищу работающую, нормальную, «не кривую», интеграцию. Чтобы «работала в штатном режиме»!
Самое главное чтобы не было APLM0012 при синхронизации и получении всд.
Хоть у кого-то работает?

freezer2008 wrote:Не понял про кривых интеграторов. Есть чья интеграция работает?
С 1 июля невозможно синхронизировать записи складского журнала, постоянная ошибка APLM0012, даже ночью, даже в выходные!
По телефону техподдержки реально говорят что у нас кривая интеграция!
Скажите, чья интеграция работает, любые деньги отдам!

ни за какие денюжки не купить, однако, только если написать сам мерк с нуля

freezer2008 wrote:Не понял про кривых интеграторов. Есть чья интеграция работает?
С 1 июля невозможно синхронизировать записи складского журнала, постоянная ошибка APLM0012, даже ночью, даже в выходные!
По телефону техподдержки реально говорят что у нас кривая интеграция!
Скажите, чья интеграция работает, любые деньги отдам!

Появился спонсор API 3.0

freezer2008 wrote:Ищу работающую, нормальную, «не кривую», интеграцию. Чтобы «работала в штатном режиме»!

Такое надо писать самостоятельно, мне кажется.

Хоть у кого-то работает?

У нас собственная разработка, заявки уходят ровно, склады и документы обновляются корректно. APLM12 и HTTP/500 встречаются, но автоматизация такие вопросы решает самостоятельно. Базы данных кэшируются с начала разработки. Единственное что, после приказов 249-251 у нас объем снизился в десять раз. Но думаю при реальной нагрузке мы 2000-3000 ТВСД делали бы в день легко.

Автоматизация это зацикливание при отбое?

BFT wrote:Автоматизация это зацикливание при отбое?

Анализ ошибок, соответствующая реакция, в том числе и повтор запроса. Помимо APLM12 в Мерке есть другие ошибки, которые требуют соответствующей обработки.

У нас до 01.07 все "штатно" было. А потом появилась эта чертова дюжина.

BFT wrote:У нас до 01.07 все "штатно" было. А потом появилась эта чертова дюжина.

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

Vladimir2017 wrote:

BFT wrote:У нас до 01.07 все "штатно" было. А потом появилась эта чертова дюжина.

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

Да, свое. Размер последнего отета сейчас посмотрел 4,5Мб.

BFT wrote:Да, свое. Размер последнего отета сейчас посмотрел 4,5Мб.

Возможно это значительный фактор, у нас алгоритм работы примерно такой - раз в минуту запрашиваются данные по складам и документам на всех площадках, временной диапазон - дата последнего документа/записи. Раз в час запрашиваются все непустые складские записи. Помимо этого документы и записи получаем после создания через опрос по ApplicationID. Механизм избыточен, но нам важна точность. Максимальный объем документа получается чуть больше 2 мб. За сегодня 8 ошибок HTTP/500 и не одного APLM12.

*Update - про APLM12 соврал, не туда посмотрел. Сейчас проверил и насчитал около 300. Но работе это не помешало.

Спасибо, подумаю над уменьшением размера пересылаемых данных.

Vladimir2017 wrote:

BFT wrote:Да, свое. Размер последнего отета сейчас посмотрел 4,5Мб.

Возможно это значительный фактор, у нас алгоритм работы примерно такой - раз в минуту запрашиваются данные по складам и документам на всех площадках, временной диапазон - дата последнего документа/записи. Раз в час запрашиваются все непустые складские записи. Помимо этого документы и записи получаем после создания через опрос по ApplicationID. Механизм избыточен, но нам важна точность. Максимальный объем документа получается чуть больше 2 мб. За сегодня 8 ошибок HTTP/500 и не одного APLM12.

*Update - про APLM12 соврал, не туда посмотрел. Сейчас проверил и насчитал около 300. Но работе это не помешало.

На встрече последней с разработчиками меркурия это(запросы остатков ежеминутно) было названо плохой практикой и как я понял будет грозить аудитом (сроки не ясны) и какими-то карами я полагаю ))