AXELOT WMS X5

Для решения этих и других проблем было решено разработать WMS 5-ого поколения. Система подверглась 100% технической переработке всех ее компонент, так как, в противном случае, невозможно было добиться поставленных целей. 

Ниже перечислены основные нововведения в AXELOT WMS X5 относительно предыдущего поколения WMS, разработанного AXELOT. Анализ проводился относительно функциональности межотраслевого релиза 1С:WMS, который содержит расширенный функционал по сравнению с версией коробочного решения, поставляемой фирмой 1С.

AXELOT WMS X5 в настоящий момент активно развивается, и лючает в себя все больше новой функциональности. Актуальный список нововведений можно получить в компании AXELOT по запросу. 

Архитектура WMS 3

В WMS 3 для хранения остатков используются Регистры сведений. С точки зрения практики использования платформы 1С, это не совсем стандартное решение, т. к. для такого рода задач традиционно используются Регистры накопления. Тем не менее, решение использовать Регистры сведений для хранения остатков было обусловлено гораздо более высокой производительностью системы в реальном времени, чем это возможно в случае использования Регистров накопления. Логика построения архитектуры в этом случае опиралась не на бизнес-суть объектов метаданных, а рассматривала, каким образом эти объекты метаданных будут отражены в СУБД.

В конечном итоге данный подход показал отличные показатели производительности и доказал, что на платформе 1С можно строить системы управления технологическими процессами в реальном времени, которые могут эксплуатироваться на интенсивных и очень интенсивных складских комплексах.

Минусом архитектуры WMS 3 является то, что данная система работает с многострочными документами, в которые объединяются строки с задачами, и исполнитель работает с этими документами как с чем-то единым. Такой подход не дает нужной гибкости в настройке и управлении складскими процессами, особенно там, где процессы довольно сложны.

Таким образом, именно нехватка функционала в WMS 3, обусловленная архитектурными ограничениями, поставила вопрос о необходимости разработки нового поколения WMS-системы, более гибкой, которая работала бы с потоками единичных задач и имела в своей основе событийную модель – WMS 4.

Архитектура WMS 4

По причине необходимости существенных архитектурных изменений в 2010 году было принято решение разрабатывать WMS 4 с нуля, без использования каких-либо компонент WMS 3.

При начале разработки WMS 4 встал вопрос о выборе архитектуры хранения остатков. Анализировались 2 варианта: оставить проверенное решение с Регистрами сведений или рассмотреть новую архитектуру с Регистрами накопления.

В конце 2009-ого года фирма 1С выпустила новую платформу 8.2.9, в которой появился функционал Агрегатов. Этот функционал позволял построить Таблицу итогов нужной структуры, которая обеспечивала нужную производительность системы при использовании Регистров накопления. В итоге было принято решение использовать новые возможности платформы 1С и вернуться к более классической схеме хранения остатков на Регистрах накопления. Такое решение позволило использовать стандартные механизмы и проверки при формировании движений по остаткам, уже реализованные внутри платформы, и не требовало написания их аналога на уровне прикладного кода (как это требовалось в случае использования Регистров сведений).

В 2012 году была выпущена финальная версия WMS 4, которая не только покрывала необходимый новый функционал, но и показывала хорошую производительность при работе. Данная система успешно внедрялась и эксплуатировалась на десятках складов под управлением платформы «1С:Предприятие 8.2».

В 2013-ом году фирма 1С выпустила платформу 8.3, которая несла большое число новых возможностей, но кроме того в данной платформе были пересмотрены некоторые уже существующие механизмы, в т. ч. механизм Агрегатов. Эти изменения привели к тому, что использование Агрегатов для целей WMS 4 стало гораздо менее эффективным, а после выхода версии платформы 8.3.8 в 2016 году полностью невозможным.

После проведенного анализа различных вариантов найти полноценную замену механизму Агрегатов без полного переписывания WMS 4 оказалось невозможно. Это сказалось существенным образом на производительности системы WMS 4 на интенсивных складах.

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

Технические особенности работы агрегатов в разных версиях платформы 1С

В контексте WMS 4 есть ситуация, когда нам нужно посмотреть общий оборот по заказу на отгрузку или ожидаемому поступлению, чтобы понять: «а на сколько мы уже отгрузили, собрали или спланировали по заказу?». При этом нам не интересно, когда был сделан данный оборот по заказу – в прошлом месяце или в текущем, нам надо увидеть сколько всего было.

Для решения данной задачи было принято решение использовать настроенный вручную непериодический Агрегат. Как известно, у Таблицы агрегата строится следующий индекс: 

Период+Измерение1+Измерени2+…+ИзмерениеN

В нашем случае мы не включали Период в Агрегат, остальные измерения включались в порядке следования. В итоге мы получали кластерный составной индекс Заказ на отгрузку + Номенклатура + Состояние + … . В нашей системе 90% запросов строится по связке Заказ на отгрузку + Номенклатура, а остальные 10% — это запросы с отбором только по Заказу на отгрузку, тем самым мы имели идеальный индекс для решения наших задач.

Именно такой подход использовался в WMS 4 при работе в платформе 8.2.

Все изменилось после выхода платформы 8.3, в которой фирма 1С оптимизировала хранение данных в агрегатах. Платформа позволяет построить большое число агрегатов к одному регистру, это увеличивает объем хранимой информации. Чтобы уменьшить этот объем была изменена структура хранения агрегата. Таким образом, если в платформе 8.2 в измерениях хранились настоящие ссылки на объекты или значения, а это в большинстве случаев тип Binary(16), то начиная с платформы 8.3 значения в измерениях агрегатов изменились на числовые (это более легкий тип данных), также добавились таблицы словарей (_AccumRgAggDict*), в которых прописываются соответствия между числовым значением и настоящей ссылкой на значение в таблице.

В итоге запрос к агрегату вида (в 8.2):

Заменился на следующий (в 8.3):

И если в первом случае работал составной индекс, который сразу находил нужные строки по сочетанию Заказ на отгрузку + Номенклатура, то теперь поиск стал работать только по одной из таблиц-словарей, либо по Заказу на отгрузку, либо по Номенклатуре. В таких условиях использование агрегатов стало бессмысленным, и было решено вернуться к Таблице итогов Регистра накоплений.

Действительно, таблица итогов Регистра накопления (оборотного) имеет в 8.2 и первых версиях 8.3 (8.3.1 – 8.3.7) подходящие индексы:

Поставив свойство «Индексировать» измерениям Заказ на отгрузку и Номенклатура, мы получили на Регистре накоплений полный аналог того, что начал предоставлять нам Агрегат, начиная с версии 8.3. Такое решение хуже того, которое было описано выше для платформы 8.2, т. к. в этом случае приходилось искать нужную номенклатуру в заказе простым перебором, однако при заказах, не превышающих 1000 строк, это было вполне удовлетворительно.

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

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

Как говорилось ранее, наша задача подразумевает, что мы будем смотреть обороты по заказу целиком без разреза периода. И WMS 4 ни в одном из обращений не накладывается условие по периоду. Итого, мы получили глобальную проблему: теперь у нас нет ни одного подходящего индекса для наших запросов. И чтобы прочитать любые данные из данной таблицы, нам надо перебрать каждую запись (сделать полный «scan» таблицы). На таблице в 20-30 млн. записей это занимает порядка 30 секунд. А выполняются такие операции на каждом шагу: при планировании отбора (считаем, сколько еще надо планировать), при выполнении отгрузки каждой палеты (проверяем, что не отгружаем больше плана), при контроле отгрузки, при упаковке и т. д.

При проектировании WMS 4 под платформу 8.2. предполагалось, что обращение к данной таблице будет длиться 0.02-0.04 секунды. Но после описанных выше изменений в платформе 1С, начиная с версии 8.3, с ростом таблицы скорость начинает падать все сильнее и сильнее. Допустим, за первый месяц работы системы в таблице накопились 100 000 записей, и запрос длится 0.1 секунду, что не так критично. Но уже через год в таблице будет 1.2 млн записей, и запрос будет длиться 1-2 секунды, что уже может создать определенные неудобства. Окончательно система встанет, когда запрос будет достигать 20 секунд.

Оценить, когда таблица достигнет критического размера, можно следующим образом. Нужно умножить количество строк в заказах на отгрузку на 2 – это и будет примерно то число, на сколько увеличится таблица контроля отгрузки. Если вы ежедневно отгружаете 10 000 строк заказов (200 заказов в среднем по 50 строк), то 1 млн строк вы получите через 50 дней работы, а 20 млн через 3 года. Если же вы отгружаете ежедневно 100 000 строк заказов, то уже через 3 месяца WMS 4 встанет окончательно.

Бороться с этой проблемой можно регулярной «срезкой» базы данных, однако это сложная и ресурсоемкая процедура, которая требует значительного времени и невозможна при коротких технологических окнах современных складов.

Варианты оптимизации, которые можно было бы реализовать настройкой базы на уровне СУБД, приводят к нарушению лицензионного соглашения по платформе «1С:Предприятие». Согласно лицензионному соглашению, лицензиат обязуется не вносить какие-либо изменения в содержимое баз данных и других наборов данных, в которых система хранит информацию, за исключением тех изменений, которые вносятся штатными средствами, входящими в состав «1С:Предприятие» и описанными в сопроводительной документации. Это требование обусловлено в т. ч. контролем со стороны платформы за структурой БД. В случае изменения структуры БД на уровне СУБД платформа автоматически приводит ее к изначальному виду, требуемому платформой.

Все остальные варианты оптимизации WMS 4 сводились к необходимости полного изменения архитектуры системы – де-факто ее полному переписыванию.

Архитектура WMS 5

Решение о создании WMS 5 было принято в 2016 году после того, когда стало окончательно понятно, что архитектура, реализованная в WMS 4, зашла в технологический тупик и не дает дальше развиваться продукту по причине быстрой деградации производительности. В целом, это нормальный процесс – если развивается технологическая платформа, то должны развиваться и продукты, построенные на этой платформе.

Как и ранее, по причине необходимости существенных архитектурных изменений было принято решение разрабатывать WMS 5 «с нуля», без использования каких-либо компонент WMS 4. Надо сказать, что и сама фирма 1С часто использует такой подход написания «с нуля» при глобальных изменениях платформы. Например, «1С:Управление производственным предприятием 1.х», созданное для платформы 8.1, 8.2, которому на смену пришло написанное с нуля «1С:ERP 2.х», созданное для платформы 8.3.