Comments 16
А не думали вместо выгрузок таблиц использовать rest -запросы изменений данных?
Извиняюсь, но пока читал, почувствовал, что попал на чужую планёрку, где кто-то кому-то докладывает об успехах :)
Нужные данные выгружаются на сайт, но не туда
Это удивительно и прекрасно одновременно!
Когда вы заходите на страницу с товаром, то его цена с учетом скидки неизвестна. Расчет происходит “на лету” из справочника скидок контрагентов и подставляется в нужном месте по технологии Ajax. Это сделано для ускорения отображения страницы за счет возможности создания ее кэша
Все очень запущено... Все эти "20-30 секунд на расчёт" и последующие костыли -- остаётся только развести руками. А всё только потому, что зачем-то решили использовать Битрикс, который для решения этих задач в принципе не приспособлен.
Вот и получаются Признаки нетрадиционной интеграции с 1С.
тут дело не в Битриксе
дело в расчете цен на стороне 1С, я ниже написал про это
как бы вы решали эту задачу?
Уточните, пожалуйста:
Насколько часто меняются цены?
Цены меняются у всех клиентов единовременно?
На каком сервере это всё работает?
1 - это вне зоны нашего контроля, к сожалению. у клиента торговая сеть, они могут менять это ежечасно. на практике корректировка любой цены происходит с 95% в течение недели, с 20% вероятностью в течение дня
2 - нет, охват по группам, которые тоже частично пересекаются, например "регион Х" или "те кто покупают мало" или "школьный ассортимент"
3 - вы про сайт или про 1С? под сайтом обычный виртуальный (или физический, точно не знаю) выделенный сервер. CentOS, SSD. 1С на серверах заказчика, отдельных конечно
А не пробовали при изменении цены на конкретный товар в 1С делать событие в сервер очередей со всеми необходимыми данными и слушать его на сайте, изменяя соответствующую информацию в БД?
Выгружать индивидуальные цены, серьезно?
3500 клиентов * 10000 един ц sku = большие таблицы, с которыми, мало того что Битрикс работает с трудом, так ещё и 1с грузить такими масштабными выгрузками... Ну нецелесообразно точно =)
Берём матрицу исчисления цен (тупо математика, та же что и в 1с), и считаем на лету при формировании страницы. Не нужно конструировать статического монстра, одновременно нагружая 1с.
тут все дело как раз в математике на стороне 1С
очень часто логика определения цены это далеко не просто коэффициент к базовой. она может зависеть и от других параметров, например от логистики поставщика или объема продаж в прошлом месяце. или "акций", конструктор которых есть в УТ, например
поэтому на практике тащить всю логику определения цены из 1С на сайт – неверно, это дублирование кода и необходимость поддерживать 2 копии логики
тащить всю ценовую матрицу – решение безусловно не самое изящное, но проблем с этим нет. на стороне сайта используются не инфоблоки Битрикса, а физические таблицы, они миллион записей с индексами переваривают как СУДБ позволит, не медленнее
альтернатива – веб-сервис "расчета цен на лету" на стороне 1С, и кеширование этого дела на стороне сайта. сейчас так делаем все чаще
Не знаю, насколько у вас большая и нагруженная база 1С, у нас более 1Тб постоянно в оперативке приходится крутить, так что всегда приходится отталкиваться от постулата "лучше отдать сырые данные и обработать их вовне".
Копию логики создать и поддерживать в актуальном состоянии не так сложно (с учетом собственной команды разработки), и именно из-за необходимости учета не-линейных показателей - это наиболее актуально, т.к. веб-сервер математику исполняет не хуже самой 1С, а вот с выгрузками масштабных данных у 1С проблемы, и, как следствие, возможны проблемы:
в процессе выгрузки гигантского массива происходит сбой:
1.1. со стороны 1С - отрубился интернет
1.2. со стороны веб-сервиса - недоступность
1.3. со стороны веб-сервиса - в процессе приема и разбора данных появились ошибки и некоторые блоки не были записаны / обновлены
1.4. и так далее, вариантов масса
пока на стороне 1С формируются данные на отдачу - могут возникать конфликты блокировок.
пока на стороне 1С формируются данные на отдачу - могут быть произведены изменения в записях самой 1С. И это не будет исправлено до следующего обмена.
любые попытки снизить риски предыдущих трех пунктов без изменения глобального подхода - это временные костыли, которые сломаются в самый неподходящий момент (дело пошло в гору, много пользователей, много заказов - и привет)
По акциям, спецценам, индивидуальным скидкам и т.д. - обычная работа с матрицами, ничего особенного. Работает математика на веб-сервере не хуже чем в 1С, с той разницей, что горизонтально масштабировать его кудааааааа как проще, чем 1С (на случай наплыва пользователей).
Складывается впечатление, что, либо у вас не такая нагруженная система как вы описываете в статье, которая чувствует себя вальяжно, либо вам еще предстоит узнать все "прелести" проблем, о которых я пишу :)
спасибо за мысли
в моей реальности гораздо проще сделать предрасчет и выгрузку на стороне 1С (при не-супер-частых изменениях цен) или веб-сервис, чем дублировать математику
Всегда пожалуйста. С ростом нагрузок, SKU, вариативности продаж, внедрения маркировки, открытия филиалов и точек продаж, РЦ и т.д., вы также узнаете, что битрикс не тянет от слова "совсем", и нужно будет отдельное решение, скорее всего двухкомпонентное. В общем, впереди много нового, если что пишите, подскажу что знаю из практики.
Надеюсь, что вы вскоре с этим столкнетесь, т.к. это будет означать бурный рост ;)
По моему 5ти летнему опыту с редакциями "Магазин" и "Корпортал" коробочными, говорю одно:
1.) Взяли программистов 1С и программистов Битры.
2.) Разработали спецификации обмена в JSON
3.) Написали приемники/передатчики
В битре допилили необходимое также...
4.) Профит всем.
Все остальное извращение слабо конфигурируемое и поддерживаемое.
Нетривиальная интеграция сайта с 1С на примере интернет-магазина канцтоваров