Сегодня на ваши вопросы, связанные с буферизацией входящих ЭВСД и журнала остатков, отвечает генеральный директор ЗАО АСП Сергей Барышев.
Из писем читателей: «Увидел интервью вашего ген. директора, в котором он рассказал, что для крупных торговых сетей была сделана некая «буферизация» входящих ЭВСД и журнала остатков. После этого «торможение» при запросе ЭВСД и журнала остатков исчезли. Не могли бы вы подробнее объяснить суть этой буферизации ? Мы ищем работоспособные решения для работы с ФГИС «Меркурий»».
Исходя из вопроса эта информация получена из семинара и её надо расшифровать. То есть изначально отталкиваемся от нескольких проблем:
- До первого июля
- Есть проблемы, которые возникли с 1.07 по 10.07, когда была очень большая нагрузка. Основные проблемы: торможение, проблема невозможности работать от проведения каких-то операций, которые возникли со 2-3 июля по 10 число, то нагрузка была очень активная и тут вопрос: как мы это избегали?
Когда начался запуск мы поняли, что есть 3 операции, которые для Меркурия трудоемкие:
- Это получение складских остатков, журнала складских записей Меркурия;
- Получение входящих сертификатов для дальнейшего гашения или приемки на склад;
- История изменения складских записей.
Эти 3 операции дают основное торможение, и для Меркурия являются тяжелыми.
Эти 3 операции дают основное торможение, и для Меркурия являются тяжелыми. Основная проблема, что многие игроки на рынке, когда стали работать начали просто эти операции запрашивать раз в 5 минут, кто-то оправданно, кто-то неоправданно, что в результате дало для всех основное торможение. При чем некоторые даже начали выпускать некие бесплатные мобильные приложения, которые просто эти операции делают раз в 5 минут для того, чтобы дать просто информацию. Что само по себе является очень глупым действием, так как дает неоправданную нагрузку и почему-то РСХН до сих пор их не отключил и пытается как-то с ними жить тоже.
Но, чтобы избежать данную проблему можно было делать выписку — минимизировать остатки, запрос входящих сертификатов и историю изменения складских записей.
Мы в своей интеграции используем только запрос остатков и запрос входящих сертификатов. И для того, чтобы эти операции меньше необходимо было запрашивать — мы эту информацию просто сохраняем на своей стороне. То есть мы сохраняем разово информацию остатков и когда идет операция с ЭВСД- мы эти остатки просто изменяем и храним информацию, которая уже изменилась и нам не нужно дополнительно её запрашивать. Дальше мы можем регистрировать документы. По сути проблем с регистрацией самих документов — нет. Если документ полностью заполнен корректно, то операция проходит. Соответственно, если есть остатки, то можно зарегистрировать документ. Единственная проблема была в том, что в начале очень многие компании восприняли проблему побочную из-за того, что была нагрузка на Меркурий, который не мог корректно вернуть ответ. Какая именно проблема возникла? Меркурий давал возврат с ошибкой APLM 0012, когда даже документ был просто неправильно заполнен: не был указан транспорт, не была указана цель, и из-за перегрузки он не мог возвращать корректный ответ в некоторых ситуациях. Некоторые компании даже днями не могли зарегистрировать документ. Но когда проверка корректности заполнения идет на стороне интеграции документ регистрируется практически моментально. С этим проблем не бывает.
Соответственно, чтобы избежать, как минимум проблем регистрации документов — необходимо было сохранять историю изменения остатков и регистрировать документ по остаткам. Контролировать корректно ли заполнен сам документ.
Второе, чтобы сделать приемку товара по входящим сертификатам. То есть нужно было тоже разово запросить информацию о входящих сертификатах, и после этого сохранить ее и нужный сертификат гасить, а не запрашивать их постоянно.
Это 2 первые меры, которые были сделаны.
Презентация бизнес-сообществу продуктов компании ASP Аналитический центр при Правительстве РФ г. Москва
Далее была сделана мера в том случае, если нам нужно периодически запрашивать остатки, либо периодически запрашивать входящие сертификаты.
Мы сделали так, что если Меркурий возвращает нам APLM 0012, мы запрашивали эту же информацию чуть позже. Автоматически. И возвращенная информация сохранялась на базе интеграционного решения, и дальше все пользователи спокойно работали. То, что мы делали не более нескольких раз в день (до 3-х) другие делали чуть ли не каждую минуту. И, представьте, как своими запросами они нагружали систему ГИС Меркурий и усложняли при этом жизнь не только другим, но и себе в частности.
Проблема с запросом входящих остатков была у тех организаций, у которых входящих остатков было более 2000- 5000 записей в журнале. Проблема возникала в том, что запрос остатков может идти по 1000 один запрос и на одном из 3-х или 5-ти запросов, который нужно было вернуть — возникала какая-то проблема, соответственно, они не могли полностью получить информацию об актуальных остатках, она у них не хранилась и они по 5 запросов отправляли и получали один некорректный, и, из-за этого тоже не могли корректно выписывать. Здесь мы предприняли меру и делаем это до сих пор у клиентов: удаляем и актуализируем информацию по неактуальным складским записям. Как правило, у кого 5000-10 000 складских записей- это те, у кого много просроченной информации, и мы делали уже механизмы, с помощью которых можно было автоматически списать партию некорректных уже товаров.
Это первые меры, которые позволяли продолжить работу не замечая основных проблематик. Потому что без этих двух запросов каждую минуту — можно жить. И если мы их минимизируем, то мы можем спокойно работать. Вторая мера — ввести более детальную проверку корректности документов.Также, о чем косвенно было сказано по поводу буферизации для сетей- это больше склоняется к тому, что необходимо, чтобы работать в системе Меркурий надо сопоставлять хозяйствующих (юридических) лиц Меркурий и вашей учетной системы, и, соответственно, места доставки вашей учетной системы и в Меркурий. И когда какой-то клиент пытался сопоставить информацию своей учетной системы и запросить информацию от Меркурия по поводу всех поднадзорных, допустим Х5 либо Тандера, а у них уже сотни и тысячи получалось количество запросов этих поднадзорных очень большое, и он раньше вызывал затруднения в определенные моменты нагрузки. Чтобы этот вопрос минимизировать тоже — мы информацию о списке торговых сетей, списки поднадзорных вместо доставки Меркурия начали кэшировать их на своей промежуточной шине, которая эту информацию хранила. Получается когда клиенту нужно было запросить информацию по определенному списку больших контрагентов, то он обращался не напрямую в Меркурий, а в наш промежуточный сервис, который возвращал информацию о списке этих клиентов и делал это очень быстро. Это могло храниться как на нашей промежуточной шине, могло также сохраниться непосредственно у клиента в его интеграционном решении: по нажатию кнопки сохранить необходимую информацию. Эти меры может быть не на 100% решили все проблемы, но по крайней мере они на 95% позволили работать без перебоев с какими-то незначительными задержками, от которых никто не застрахован.
Ника Виноградова