в моей реальности гораздо проще сделать предрасчет и выгрузку на стороне 1С (при не-супер-частых изменениях цен) или веб-сервис, чем дублировать математику
1 - это вне зоны нашего контроля, к сожалению. у клиента торговая сеть, они могут менять это ежечасно. на практике корректировка любой цены происходит с 95% в течение недели, с 20% вероятностью в течение дня 2 - нет, охват по группам, которые тоже частично пересекаются, например "регион Х" или "те кто покупают мало" или "школьный ассортимент" 3 - вы про сайт или про 1С? под сайтом обычный виртуальный (или физический, точно не знаю) выделенный сервер. CentOS, SSD. 1С на серверах заказчика, отдельных конечно
тут все дело как раз в математике на стороне 1С очень часто логика определения цены это далеко не просто коэффициент к базовой. она может зависеть и от других параметров, например от логистики поставщика или объема продаж в прошлом месяце. или "акций", конструктор которых есть в УТ, например
поэтому на практике тащить всю логику определения цены из 1С на сайт – неверно, это дублирование кода и необходимость поддерживать 2 копии логики
тащить всю ценовую матрицу – решение безусловно не самое изящное, но проблем с этим нет. на стороне сайта используются не инфоблоки Битрикса, а физические таблицы, они миллион записей с индексами переваривают как СУДБ позволит, не медленнее
альтернатива – веб-сервис "расчета цен на лету" на стороне 1С, и кеширование этого дела на стороне сайта. сейчас так делаем все чаще
минимизируем время показа клиенту. иногда это долго, особенно если разрешить видеть сразу список сделок с их временем или строить отчет. решили что глядя в будущее правильно считать и хранить. некая денормализация
откровенно говоря не знаю бесплатных продуктов, на которых стоит сделать корпоративный интранет-портал, если не пытаться написать все с нуля на каком-нибудь языке
реалтайм обмен в этом мире существует
это большая отдельная тема, но грубо говоря есть 2 варианта:
— этот вот файловый обмен превращается в атомарный (без гигабайт) и все микропорции идут постоянно в обмене
— сами пишем веб-сервисы с хуками на обеих сторонах. если сайт и 1С сильно нестандартный – это хороший путь
это антипример. так нельзя делать. обмен должен идти строго в 1 поток
если удастся запустить 2 обмена сразу и они будут писать в 1 место — они друг другу мешают
спасибо за мысли
в моей реальности гораздо проще сделать предрасчет и выгрузку на стороне 1С (при не-супер-частых изменениях цен) или веб-сервис, чем дублировать математику
1 - это вне зоны нашего контроля, к сожалению. у клиента торговая сеть, они могут менять это ежечасно. на практике корректировка любой цены происходит с 95% в течение недели, с 20% вероятностью в течение дня
2 - нет, охват по группам, которые тоже частично пересекаются, например "регион Х" или "те кто покупают мало" или "школьный ассортимент"
3 - вы про сайт или про 1С? под сайтом обычный виртуальный (или физический, точно не знаю) выделенный сервер. CentOS, SSD. 1С на серверах заказчика, отдельных конечно
тут дело не в Битриксе
дело в расчете цен на стороне 1С, я ниже написал про это
как бы вы решали эту задачу?
тут все дело как раз в математике на стороне 1С
очень часто логика определения цены это далеко не просто коэффициент к базовой. она может зависеть и от других параметров, например от логистики поставщика или объема продаж в прошлом месяце. или "акций", конструктор которых есть в УТ, например
поэтому на практике тащить всю логику определения цены из 1С на сайт – неверно, это дублирование кода и необходимость поддерживать 2 копии логики
тащить всю ценовую матрицу – решение безусловно не самое изящное, но проблем с этим нет. на стороне сайта используются не инфоблоки Битрикса, а физические таблицы, они миллион записей с индексами переваривают как СУДБ позволит, не медленнее
альтернатива – веб-сервис "расчета цен на лету" на стороне 1С, и кеширование этого дела на стороне сайта. сейчас так делаем все чаще
жанр такой )
конечно, часто так и делаем. это более изящный способ
но файлы – более традиционный для 1С
выбираем "по месту"
пардон, статья действительно написана несколько лет назад
указали это в тексте
сути не меняет вроде как
минимизируем время показа клиенту. иногда это долго, особенно если разрешить видеть сразу список сделок с их временем или строить отчет.
решили что глядя в будущее правильно считать и хранить. некая денормализация
скорее не влияет. это внутренний механизм сайта, было бы странно его применять как критерий
но влияет на общее качество работы поиска, что косвенно влияет на репутацию, поведенческие и все что мы любим
корпоративный портал – это не сайт.
это внутренний софт с довольно большим объемом функциональности, заточенной на бизнес-процессы
на cms/фреймворке конечно теоретически сделать это можно, но это будет "почти с нуля"
примеры платформ для корпоративных порталов это например MS Sharepoint или Битрикс24
откровенно говоря не знаю бесплатных продуктов, на которых стоит сделать корпоративный интранет-портал, если не пытаться написать все с нуля на каком-нибудь языке
Мы в своих статьях старательно вычищаем, и только так они тут проходят.
это следствие изменений в законодательстве и развития продуктов
вам совершенно ничего не мешает перестать обновлять обе системы
многие так и делают
у нас на поддержке живы Битриксы например 2014 года, не обновленные
и 1С-ка 8.1 не такая уж редкость
кроме того, а с какой другой «связкой» вы сравниваете?
1С не занимается полной поддержкой обратной совместимости, в отличие от Битрикса кстати
действительно приходится
однако за 1-2 обновления соответствующие объекты сначала помечаются на удаление, и только потом удаляются
есть время
некоторые крупные компании имеют целый процесс отслеживания такого (как правило не в УТ, а в ЗУП)
rabbitmq или gearman применяются примерно в равных долях
конкретно между 1С и Битриксом нужно просто настроить (при необходимости доработав и дополнив) стандартный обмен
релиз БУС 14.5, 2014 года
dev.1c-bitrix.ru/community/blogs/product_features/exchange-with-1c-analyze-typical-operations.php
www.youtube.com/watch?v=q5BoMXsV-Po
пожалуй про нее тоже надо написать
это большая отдельная тема, но грубо говоря есть 2 варианта:
— этот вот файловый обмен превращается в атомарный (без гигабайт) и все микропорции идут постоянно в обмене
— сами пишем веб-сервисы с хуками на обеих сторонах. если сайт и 1С сильно нестандартный – это хороший путь
kolabaister мы пишем это сами, если надо
целый день — не дело. пора оптимизировать, передавать меньше данных, делать атомарно
в тяжелых случах — переписывать
если удастся запустить 2 обмена сразу и они будут писать в 1 место — они друг другу мешают
все остальное (скидки и ПЛ) приходится дописывать в обмен, как правило «справочниками» или реалтайм-режимом
в 1С ПЛ есть, можно на ее базе строить