Интернет-магазин на 1С — webstore-on-1c.ru :)

(299) Ну тогда это шляпа.

(284) Ну вот, значит (278) "При наличии свободных лицензий ждать не будут" не в тему?

Пообщался с представителем 1с, который ведет корпоративный блог 1с на Хабре.

Мой вопрос:

Здравствуйте, в свете существование в платформе таких отличных вещей как веб сервисы и http сервисы многие 1с-ники считают что на 1с можно «писать сайты» и купить для этого надо только одну лицензию независимо от количества пользователей сайта. Для себя я четко понимаю, что это не так, все четко написано в лицензионном соглашении (мультиплексирование), но 1с-ники верят только официальной позиции важных людей из 1с. Вот в ветке на мисте развернулась дискуссия, является ли такой вид использования — нарушением лиц соглашения: Интернет-магазин на 1С — webstore-on-1c.ru :). И очень часто данный вопрос всплывает в других обсуждениях на форумах.
Могли бы вы дать какой-либо комментарий по данному вопросу, который можно предъявить «массам»?

Его ответ:

Здравствуйте!

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

Подробнее тут, пункт 59.

http://v8.1c.ru/predpriyatie/questions_licence.htm#mvv

(303) Полагаю, сейчас ТС запросит ФИО представителя 1С )

(304) Ну да, со сканом паспорта, что-то я об этом не подумал =)

(306) Петр Грибанов, технологический евангелист фирмы «1С»
Вот он https://www.youtube.com/watch?v=adByHP-nY68

(303) Евангелист не может ответить на вопрос, сколько, например, нужно клиентских лицензий на дисконтном сервере? Если доступ к нему осуществляется только через веб сервисы из других 1с баз данных, на которых работают пользователи и уже приобретены все необходимые лицензии?

(309) Это не пост, переписка в личке, сами можете ему написать - я думаю не укусит.

https://habrahabr.ru/users/PeterG/

(308) Сам можешь спросить, лично я вопроса не понял, зачем покупать доп лицензии если "уже приобретены все необходимые лицензии"

(311) Еванглист не может себе представить базу 1С, с которой пользователи интерактивно не работают?

(312) Почему не может? Может наверное, его ответ не был привязан к "интерактивной работе". Сколько одновременных коннектов к базе - столько и лицензий, вот такая простая логика. При этом в обратную сторону можно, запускай 150 фоновых заданий и пущай они хоть эксель файлы сохраняют, хоть в облака пишут.

(313) Ну еще бы за фоновые задания платить. Их иногда несколько десятков одновременно крутится.

(314) ахах, устный конечно и печати синей нету.

Начальник звонит секретарше:
- У меня остро встал вопрос!
Она отвечает:
- Я сейчас немогу, у меня месячный отчет!
После некоторого раздумия заходит в кабинет:
- Могу оформить задним числом или в устной форме!
- Да уже не надо, я от руки набрасал!

(315) Ну за передачу информации с сервера же предлагают платить, как по мне это даже более дико чем платить за фоновые задания  =)

https://wonderland.v8.1c.ru/blog/peredacha-informatsii-s-servera/

eks1985, просьба не публиковать здесь Вашу личную переписку с фирмой 1С или её представителями. Это нарушение правил форума.

(318) Он же явно спросил "Могли бы вы дать какой-либо комментарий по данному вопросу, который можно предъявить «массам»".

(319) Это всё равно остаётся его личной перепиской, которую он может извратить по собственной прихоти, а слова выдать за цитату представителя фирмы 1С, за что мне будет претензия.

(320) Значит автору цитат ил личной переписки надо притащить "Евангелиста" сюда, чтобы он сам ответил на эти вопросы?

(318) ок

(317) Думаю, в данном случае 1С планирует освоить дополнительные деньги на крупных клиентах. Мелким с небольшими базами и малым количеством пользователей уведомления от сервера вряд ли сделают погоду. А крупные для оптимизации вполне будет готов заплатить. Поэтому и идет все это отдельной коробкой.

(321) Ну например так.

У всей этой затеи есть несколько два глобальных минуса:
1.
> Может работать, естественно, на любой конфигурации, где есть что продавать :)
Тут нужно начать с того, что Http-сервисы доступны только начиная с платформы 8.3.5.1068, а это значит что конфигурация должна иметь "Режм совместимости" не ниже 8.3.5 - а большинство типовых конфигураций перевести в этот режим будет ОЧЕНЬ болезнено, а иногда практически невозможно.
Это большая проблема с веб-сервисами!

2. Самое главное - сервер 1С, на базе которого будет построен сайт должен быть онлайн 24/7 - иначе продвигать сайт в SEO (а это очень дорогое удовольствие) будет бесполезным занятием (деньги на ветер), потому что поисковики из-за 404-ых 500-ых ошибок (из за недоступности 1с сервера) будет просто выбрасывать проиндексированные страницы из своей базы.
      
Звездочёт, если я не прав, поправьте меня.

(325) По обоим пунктам все решаемо, причем быстро и достаточно просто. С планшета писать неудобно, завтра расскажу подробнее.

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

Я с год назад тоже вначале был воодушевлен такой идеей, сделал пару магазинов на 1-С HTTP-сервисах. В итоге один через пол года переписал под обмен данными между 1-С и магазином, второй поисковик уже несколько раз выбрасывал (по 100-200 страниц) из поиска по причине 2.

(330) >> разобрался в чем причина тормозов? я делал замеры - 1С-ка формирует ответ меньше секунды. Конечно, запрос запросу рознь, но я не встречал, чтобы запрос технологически, а не логически, был тормозом.

Как выше сказал, сама по себе обработка запросов в 1-С происходит гораздо гораздо медленнее, в сравнении с обработкой запросов через тот же PHP+MySql на стороне сайта. Не стоит забывать так же, что в случае магазина, построенного на HTTP-сервисах, то когда происходит обращение к странице магазина, происходит запрос на сторону 1С-сервера (Apache, IIS), формирование запроса на стороне 1С-сервера, пересылка результата на сторону сайта и только потом отображение на основании полученных данных (все это ТОРМОЗА, особенно в случаях с непростыми запросами или получением ип ередачей большого объема данных), тут и сравнивать нечего с вариантом, когда идет запрос к странице магазина и тут же на месте PHP получает данные от MySql и формирует страницу на основании полученных данных.  

(331) >> почему база была недоступна? как часто и как долго? есть статистика?

Windows сервера, где практически всегда крутится 1С, как не крути требуют 2-3-4 раза в месяц обслуживания (обновление ПО, обслуживание SQL-сервера и т.д.) поэтому 2-3-4 раза в месяц такие сервера бывают недоступны по причине технического обслуживания. Поисковик раз пришел, попал в такую ситуацию, когда страницы 404, или 500, второй раз пришел когда все работает, в третий/четвертый-десятый раз пришел когда все работает, в одиннадцатый раз пришел, когда страницы 404 или 500, в двадцать первый раз пришел когда страницы 404 или 500 - все, выкинул страницы пачкой из выдачи.

Когда сайт зависит не от одной железки (Linux, где непосредственно располагается сайт), а от двух, где второй железкой выступает Windows-сервер, который в разы и в разы чаще требует технического обслуживания, то это ....

Так же понятен такой факт, что поисковик не любит тормознутые страницы.

> Windows сервера, где практически всегда крутится 1С, как не крути требуют 2-3-4 раза в месяц обслуживания (обновление ПО, обслуживание SQL-сервера и т.д.) поэтому 2-3-4 раза в месяц такие сервера бывают недоступны по причине технического обслуживания. Поисковик раз пришел, попал в такую ситуацию, когда страницы 404, или 500, второй раз пришел когда все работает, в третий/четвертый-десятый раз пришел когда все работает, в одиннадцатый раз пришел, когда страницы 404 или 500, в двадцать первый раз пришел когда страницы 404 или 500 - все, выкинул страницы пачкой из выдачи.

Так не редки сюрпризы, когда внезапно что-то отваливается на стороне 1С-сервера.

(325) Пункт 1. Отсутствие http-сервисов в старых релизах не проблема, потому что там как минимум есть веб-сервисы, значит, все можно сделать и на них, хоть они и менее удобные и более тормознутые. Если очень хочется, то можно и из 7.7 данные тянуть. Для этого на серваке поднимается пустая база-репитер с http-сервисами, которая принимает запросы посетителя и путем подключения к рабочей базе (через веб-сервисы, COM или еще как угодно) вытаскивает одни данные и кладет другие. Понятно, что скорость будет чуть ниже, чем при прямом подключении, зато такой вариант улучшает безопасность данных: даже если кто-то подключится к базе-репитеру, то вытаскивать с нее все равно будет нечего. Вообще, существование посредника между браузером пользователя и рабочей базой, это большой плюс в таких проектах.

(325) Пункт 2. Проблему легко решает посредник между пользователем и рабочей базой 1С, размещенный на сайте (набор скриптов на php, например). Совсем необязательно всю страницу сайта формировать в 1С - даже лучше, если статика будет генериться на сайте php-шными скриптами (и отдаваться из кэша), а динамические данные тянуться из 1С.
Формируем статику на php, возвращаем ее с ответом "200" браузеру пользователя и ботам яндекса и гугла. Далее аяксом вытаскиваем из 1С нужные данные и показываем посетителю. Если 1С в этот момент недоступна, то скрипт php отработает исключение и покажет сообщение "У нас беда, зайдите позже". Пользователь-человек поймет, что идет профилактика и придет позже. Бот не выбросит страницу из базы.
Конечно, тут есть еще много нюансов, про которые я тут рассказывать не буду, но принцип, думаю, понятен.

(329) Пункт 3. Понятно, что при прочих равных большинство сайтов на 1С будут работать медленнее, чем сайт на php. Хотя бывает и такое, что 1С показывает лучший результат. Но тут надо учитывать, что ТС выбрал в качестве демонстрационного примера наверное самый неподходящий вариант использования 1С в качестве бэка для сайта: розничные интернет-магазины и так нормально работают с настроенным обменом между БД сайта и БД 1С. Поэтому данную технологию лучше использовать для решения других задач - когда нужен альтернативный типовому веб-клиенту интерфейс.

(336) По Пункту 1 - веб-сервисы, промежуточные базы, а уж тем более COM - это вообще будут жуткие тормоза.
Так же такой подход будет очень трудозатратен, как следствие более дорогой и при этом тормознутый, не понятно зачем тогда все это.
Напмного проще, дешевле и правильнее во всех отношениях написать обмен между сайтом и 1С. А если еще и учесть что при этом 1С-сервер должен быть постоянно онлайн, статический IP и другие минусы - то и подавно.

(337) По Пункту 2
>> Совсем необязательно всю страницу сайта формировать в 1С - даже лучше, если статика будет генериться на сайте php-шными скриптами (и отдаваться из кэша), а динамические данные тянуться из 1С.
Не знаю, что имели ввиду под выражением "Статику", если это про html, то никто и не формирует полностью готовую стороне 1С - это было бы вообще тогда. ))
Из 1С тянутся только данные в JSON, и на их основании уже формируем страницу на сайте. Но если 1С-сервер недоступен, то и данных не будет, соответственно и страницы тоже.

>> Формируем статику на php, возвращаем ее с ответом "200" браузеру пользователя и ботам яндекса и гугла. Далее аяксом вытаскиваем из 1С нужные данные и показываем посетителю.  Если 1С в этот момент недоступна, то скрипт php отработает исключение и покажет сообщение "У нас беда, зайдите позже"
Уд простите, но это бредовая идея. Показывать поисковикам ранее проиндексированные страницы без контента - он так и заиндексирует их в том виде, в котором покажите. Аяксом подгружать из 1С контект после основной загрузки страницы - еще бредовее идея, поисковики еще очень плохо понимаю такие асинхронные JS вызовы.

Единственным правильным решением в такой ситуации является 302 редирект - и то это не айс как хорошо.


(338) По пункту 3
>> Хотя бывает и такое, что 1С показывает лучший результат.
Не бывают таких случаев. )) 1С запросы медленнее отрабатывают в сравнении с MySql запросами - это факт.

А если (как выше сказал) учесть, что тут даже сравнивать нельзя, при варианте магазина на Http-сервисах:
1. Пользователь запрашивает страницу магазина в браузере
2. Сервер получив параметры http-запроса, отправляет запрос на сервер 1С (посредством CURL) - это как еще один, причем более дорогостоящий запрос к сайту.
3. Apache или IIS на сервере 1С получив запрос от сервера Linux перенаправляет его в 1С-Предприятие.
4. 1С-Предприятие формирует запрос, получает результат, преобразует результат в JSON и отдает его Apache, он в свою очередь возвращает его серверу Linux
5. Скрипт сайта разбирает полученные данные в JSON, обрабатывает их, формирует на их основании HTML и отдает его конечному пользовтелю

и теперь просто PHP+MySql:
1. Пользователь запрашивает страницу магазина в браузере
2. Сервер получив параметры http-запроса, формирует запрос к MySql
3. MySql отрабатывает запрос, возвращает ответ
4. Скрипт сайта формирует на основании полученных HTML и отдает его конечному пользователю

>>  Поэтому данную технологию лучше использовать для решения других задач - когда нужен альтернативный типовому веб-клиенту интерфейс.

Вот здесь полностью согласен. Именно к такому выводу и я пришел, что хорошо это использовать там, где:
1. Конфигурация не требует переписывания кода при включении режима совместимости с 8.3.5 и выше.
2. Технические возможности предприятия позволяют держать включенным сервер 1С 24/7, или держать 1С на облачном сервере.
2. Сайт не нужно продвигать в SEO, а так же никто не будет страдать от того, что это будет немного тормозить.

Непосредственно для сайтов (интернет-магазинов), которые продвигаются в SEO, контекстная реклама и т.д., которые должны быть быстрыми и постоянно доступными - лучшиее решением является обмен данными, не прямое получение/отправка данных из/в 1С.

пишу с планшета, уж извините за опечатки.

(339) Ну собственно почти со всем согласен, даже с оценкой "это бредовая идея", потому что это в данном решении (0) это костыль, хотя в других случаях будет оптимальным вариантом. Данную технологию надо применять там, где это действительно имеет смысл.

+(341) Хотя справедливости ради стоит заметить, что мне известен сайт, сделанный по технологии "прямое получение из 1с", он соответствует всем требованиям СЕО, всегда отвечает ботам  и держит несколько сотен сеансов пользователей одновременно. Но стоимость его разработки получилась такая, что неудобно ее даже озвучивать.

(344) Не, на эту уловку я не поведусь )

(0) Вот я понять не могу.
А кто-то реально сможет доказать в суде что лицензий куплено 1, а вот путем мультиплексирования через эту одну лицензию извлекались данные для 1000 пользователей?
Разве это вообще может быть доказуемым? Что предъявит истец? Свои логи? Мол мы одновременно в двух браузерах запрашивали товары, и нам веб-сервер отвечал. А лицензия то гражданин судья то у них одна!!! А вдруг ответчик скажет, мол так и так, истец все выдумал и данные фактически берутся из MemCached, а вовсе не из 1С.
При мультиплексировании 1С поочередно обрабатывает каждую задачу (в нашем случае запрос), и возвращает веб-серверу данные (Ответ). Как некоторые утверждают для каждого клиента чьи данные 1С обрабатывает нужна отдельная лицензия. Так вот есть ряд вопросов:
1) Как понимать «одновременно будут работать с веб-сервисами 1С». Как по мне – так в режиме мультиплексирования (пул=1) к одновременно может работать только одни пользователь. Или 1С уже стала многопоточной?
2) А если это не веб-сервис? А если веб-сервер путем COM-Connector лезет в базу?
3) А если не веб-сервер лезет в 1С, а 1С лезет на веб-сервер и им рулит? (А на веб-сервере ждут своей очереди запросы для обработки)
4) И наконец. А если веб-сервер отправляет на почту запросы пользователей, 1С разгребает эту почту (pop3) и отправляет ответы веб-серверу тоже по почте (SMPT)?

(346) Совесть пассажира - лучший контролёр(с)