Компания
94,35
рейтинг
27 сентября 2011 в 15:01

Разное → Как мы разрабатывали интеграцию интернет-магазина с 1С: Предприятие и почему она стала массовой

Как обеспечить актуальный каталог товаров и их наличие на сайте и обработать заказы покупателей в соответствии с внутренними бизнес-процессами? Многие владельцы интернет-магазинов сталкиваются с данной задачей.

Интегрировать отдельно взятый интернет-магазин с учетной системой предприятия в целом несложно. Реализовать готовую интеграцию в коробочной поставке CMS-системы и сделать ее простой и понятной для массового использования, универсальной для различных задач — непростая и интересная задача. Данный топик — о нашем опыте разработки интеграции интернет-магазина с популярной учетной системой 1С: Предприятие.



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

Итак, очень часто интернет-магазин создаётся в дополнение к уже существующим каналам: магазинам, розничным точкам, дилерским продажам и так далее. И, как правило, все каналы объединены единой торгово-учетной системой предприятия или ERP-системой, в которой осуществляются основные бизнес-процессы компании:
  • управление товарной номенклатурой;
  • продажи, закупки;
  • финансы, отчетность, аналитика и т.п.
В этом случае возникает острая необходимость, чтобы интернет-магазин был интегрирован в единую учетную систему предприятия или ERP-систему.

Первое и главное при разработке интеграции — осознать ее цели и решаемые задачи. И от этого уже планировать что, как и куда передавать. В интеграции сайта с ERP-системой обычно требуется автоматизировать решение трех основных задач:
  • обеспечение выгрузки на сайт каталога товаров (который ведется в ERP) и поддержку его актуальности
  • передача заказа с необходимыми сведениями с сайта в ERP
  • информирование клиентов о ходе исполнения их заказов, обработка которых ведется в ERP.
Все разумно и просто, но, согласитесь, многие из нас были свидетелями того, как сайт живет своей жизнью, а учетная система своей. Заказывая товар в интернет-магазине, после звонка менеджера обнаруживалось, что товара нет на складе, цена не соответствует действительности, новый курс валюты или на сайте опубликован товар не в той комплектации или с картинкой другого цвета.

Разумеется, результат для такого магазина здесь возможен только один: разочарованный и недовольный клиент, который вряд ли захочет вернуться, даже несмотря на старания ваших менеджеров.



Дело было еще в 2007 году. Учитывая растущую популярность интернет-магазинов и увеличивающийся спрос на решение интеграционных задач стало ясно, что нам, как разработчикам CMS системы, нужно было предложить клиентам надежное и готовое решение для такой интеграции: простое в настройке и использовании.

Первое решение — с какой учетной системой строить такую готовую интеграцию? На тот момент, да и сегодня, наиболее популярное решение в России – платформа 1С: Предприятие, большинство клиентов хотят интегрировать свой сайт именно с 1С. В части решения задач торговой компании наибольшим спросом пользуется конфигурация 1С: Управление торговлей. Интеграцию решено было сделать именно с ней.



Разумеется, все написанное здесь также применимо и к решению задачи интеграции других ERP и CMS систем и сайтов. Подходы и идеи — это важно, ведь подходы и идеи универсальные, а код всегда можно адаптировать.

Задача обрела конкретику и мы (в сотрудничестве со специалистами 1С) начали работу. Для начала нужно было решить, какова будет архитектура взаимодействия. Вообще есть два граничных подхода:
  1. Непосредственно обращение сайта к 1С
  2. Регулярный обмен данными между 1С и сайтом
Рассмотрим первый подход — обращения напрямую к системе 1С

При его использовании сайт при необходимости запрашивает у 1С или отдает данные.

Стоит отметить, что показ каталога в интернете и онлайн заказ можно сделать вообще без CMS, у 1С есть такой функционал, как веб-расширения, а не так давно вышла платформа 8.2 и технология «управляемого приложения», которые позволяют достаточно легко отдавать функционал 1С в браузере. Но, это типичный пример первого подхода, который обладает следующими преимуществами и недостатками для наших задач.

Преимущества очевидны:
  • Полная актуальность каталога на сайте в режиме реал-тайм
  • Мгновенное появление нового заказа в 1С
  • Быстрое информирование клиента о результатах обработки заказа
В качестве интерфейса взаимодействия сайта и 1С обычно используется технология веб-сервисов (она кроссплатформенная и является стандартом де-факто для интеграции систем).

Тогда в 1С публикуется веб-сервис с набором методов, сайт туда «стучится» время от времени: забирает или отдает данные. Вроде все красиво. НО …. широкого распространения, к сожалению, такой правильный и технологичный подход не получил. И на наш взгляд вот почему:

1) Сложность в настройке для массового использования.

Для того чтобы опубликовать веб-сервис нужно развернуть веб-сервер, прописать загрузку модуля расширения, опубликовать сам веб-сервис. Кто-то скажет: что за сложность, какая ерунда и будет в целом прав. В 1С даже есть функция автоматической публикации веб-сервиса в установленном веб-сервере. НО… жизнь есть жизнь, массовому потребителю, непрограммисту это сложно и непонятно. А когда начинаются проблемы, веб-сервис не работает, снаружи не виден, алиас не прописан, пользователь не заведен, прав не хватает и т.п. – люди выпадают в осадок. Кроме того, если предприятие достаточно крупное, то необходимость в привлечении ИТ-специалистах очевидна.

2) Зависимость сайта от работы 1С

Внутренняя учетная система по разным причинам может не работать: идет обновление ПО, замена оборудования, восстановление резервной копии и т.п. В эти периоды ваш сайт не сможет корректно работать, так как целиком завязан на 1С. Конечно, вы можете эти ситуации учитывать, и реализовать определенную защиту на сайте, которые бы учитывали факт неработоспособности базы, но это лишний код, лишняя логика, которая усложняет веб-систему.

3) Зависимость 1С от работы сайта

Популярный интернет-магазин может иметь очень большую посещаемость, высокие пиковые нагрузки, много заказов в единицу времени. Если за каталогом товаров, ценами и наличием постоянно ползать в 1С, то это будет банально медленно! Веб-сервисы – удобный, технологичный, но далеко не быстрый способ обмена. И это даже при условии, что сервер 1С будет работать на приличном оборудовании. А высокие пиковые нагрузки с сайта могут вообще парализовать работу базы. Конечно, каталог товаров можно кэшировать, и запрашивать его время от времени, но, во-первых теряется первое преимущество подхода (постоянный реалтайм), а во-вторых, остается последняя, но на наш взгляд, наиболее существенная проблема: психологическая…

4) Потенциальная угроза со стороны сайта

Вспомним, что 1С является главной учетной системой предприятия, где хранится вся жизнь. 1С: Управление торговлей обычно интегрировано с бухгалтерией, кадрами и т.п. Есть и комплексные конфигурации, где все в одном флаконе. Обычно вопрос безопасности этой системы ставится во главу угла, и, зачастую, решается очень просто: отрубанием кабеля “с интернетом” от сервера в принципе (физическим способом, если по-научному). Теперь поставим себя на место руководителя, которому сообщают, что теперь сайт будет постоянно ползать в 1С за данными: записывать, получать, обновлять. И хоть мы с вами знаем, что сайт лезет не напрямую в 1С, а через веб-сервисы, у которых определенный ограниченный набор прав, психологически это тяжело принять. Как? Сайт, который могут взломать и заразить вирусом ИМЕЕТ ДОСТУП В НАШУ 1С? Ну щас, разбежались…!?



Поэтому мы применили второй подход.

Синхронизация данных между 1С и сайтом по расписанию

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

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

Преимущества по сравнению с первым подходом очевидны:
  • Сайт работает самостоятельно, со своими данными, не зависит от доступности данных в 1С
  • 1С не принимает запросы с сайта, не испытывает дополнительных нагрузок
  • В случае нарушения безопасности сайта, безопасность 1С не нарушается
У текущей архитектуры есть только один недостаток по сравнению с первым подходом: задержка обновления данных. Если, например, кроме сайта вы еще торгуете в розницу, то товар, который еще есть на сайте в наличии, уже может отсутствовать на складе. Вероятность коллизии, разумеется обратно пропорциональна интервалу обновления. Для небольших интервалов обновления (несколько минут) и среднестатистического магазина она очень невелика

Но, во-первых, мы приняли допущение, которое потом было доказано жизнью: для массовой интернет-торговли этот недостаток НЕ ЯВЛЯЕТСЯ КРИТИЧНЫМ. Вероятность такой ситуации невелика и уменьшается с уменьшением интервала обмена, а кроме того масса интернет-магазинов вообще торгуют не по реальным остаткам, скрывая наличие от посетителей. Да и если такая ситуация все таки произошла, в большинстве случаев товар можно найти достаточно быстро.

А во вторых? А во-вторых были использованы некоторые технологические решения, чтобы можно было без последствий сделать достаточно небольшой интервал задержки обновления.

Еще раз повторюсь, мы решали задачу создания интеграции, которая была бы из коробки готова в максимальном числе случаев. Конечно, есть магазины, для которых это критически важно, но ведь и автомобили многих тоже не устраивают в стоке и хочется тюнинг?! ) А тюнинг уж мы позволяем…

Кстати, о транспорте…

А что же с веб-сервисами, спросите вы? Ведь если не на стороне 1С, то теперь на стороне сайта их придется публиковать? А на веб-сервисы мы, хорошо подумав, забили. И вместо них решили реализовать обмен по старому доброму протоколу HTTP с применением обмена файлами по стандарту CommerceML.

Обмен по HTTP означает, что 1С обращается к некоторому скрипту на сайте и методом POST передает ему файлы данных. Это хорошо тем, что здесь не надо ничего дополнительно настраивать. 80й порт открыт в большинстве брандмауэров, т.к. через него вся контора пользуется инетом и 1С очень часто точно также в инет и глядит. Скрипт на сайте входит в коробочную поставку CMS, и его тоже не надо нигде дополнительно публиковать.

А CommerceML хорош тем, что это открытый стандарт на базе XML, который специально предназначен для обмена коммерческой информацией: классификатором каталога, группами и свойствами товаров, товарами, заказами. Передача данных возможна между разными системами, в том числе между сайтом и бэкофисом. Этот стандарт на момент начала работ уже существовал и развивался. На сегодня доступна уже версия 2.05, где появилось несколько приятных нововведений. Ну и, конечно, нас очень радовало, что такой стандарт уже на тот момент штатно поддерживался в 1С: Предприятие.

Примеры CommerceML файлов: файл с информацией о товарах, файл с ценовыми предложениями, файл с информацией о заказах с сайта, и на сайт.

В итоге получилась следующая архитектура нашей интеграции:



В состав 1С: Предприятие входит специальный модуль для обмена с сайтом, в котором настраиваются параметры обмена данными. Из корпоративной сети происходит обращение к удаленному сайту (размещенному на некоторой хостинг-площадке) по протоколу HTTP. Стрелки, ведущие к сайту отображают направление запросов, инициатором которых всегда выступает 1С.

Протокол обмена 1С с сайтом

Протокол полностью открытый, его можно дорабатывать и модицифировать. Информация о протоколе опубликована как в документации к 1С-Битрикс, так и на сайте 1С.

Итак, как все сказанное выше на словах выглядит технически:

1С отправляет http-запрос вместе с http-авторизацией следующего вида:
http://<сайт>/bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth
Сайт отвечает тремя строками (с разделителем "\n"):
1. слово "success";
2. имя Cookie;
3. значение Cookie.
Примечание:
Все последующие запросы к сайту сопровождаются выставлением со стороны 1С имени и значения Cookie, полученными по команде "checkauth".


Следующим этапом 1С запрашивает у сайта некоторые параметры, чтобы в дальнейшем вести обмен:

http://<сайт>/bitrix/admin/1c_exchange.php?type=<режим>&mode=init (режимы: catalog или sale, для выгрузки товаров и загрузки заказов соответственно)

В ответ сайт выдает две строчки:
1. zip=yes/no, сообщая о поддержке обмена в zip-формате.
2. file_limit=<число>, где <число> - максимально допустимый размер файла в байтах для передачи за один запрос. Если размер файла больше, то он должен быть порезан на части.


Когда соединение установлено и параметры определены, начинается основная обмена файлами CommerceML. В зависимости от режима обмена 1С:

а) передает сайту данные по товарной номенклатуре

http://<сайт>/bitrix/admin/1c_exchange.php?type=catalog&mode=file&filename=<имя файла>
1C загружает на сервер файлы обмена в формате CommerceML 2, посылая содержимое файла или его части в виде POST. В случае успешной записи файла сайт выдает "success".


б) запрашивает с сайта заказы покупателей

http://<сайт>/bitrix/admin/1c_exchange.php?type=sale&mode=query

Сайт отдает заказы в формате CML 2. В случае успешного получения и записи заказов в 1С совершается запрос вида:
http://<сайт>/bitrix/admin/1c_exchange.php?type=sale&mode=success


в) передает сайту данные о результатах обработки ранее полученных заказов

http://<сайт>/bitrix/admin/1c_exchange.php?type=sale&mode=file&filename=<имя файла>
загружает на сервер файл обмена, посылая содержимое файла в виде POST. В случае успешной записи файла 1С-Битрикс выдает "success". Дополнительно на следующих строчках могут содержаться замечания по загрузке.


Если в ходе какого-либо запроса произошла ошибка, то ответ системы 1С-Битрикс будет иметь вид: в первой строке слово «failure», а на следующих — описание ошибки, произошедшей в процессе обработки запроса. Если произошла необрабатываемая ошибка уровня ядра продукта или sql-запроса, то в таком случае будет возвращен html-код с сайта.

Вот такая нехитрая, но надежная процедура обмена, которая, повторюсь, основана на трех китах:
  • Обмен данными по протоколу HTTP
  • Инициатор обмена всегда 1С
  • Отрытый формат и протокол обмена
Кстати, спустя некоторое время протокол поддержали и разработчики других CMS, и на сегодня это по сути стандарт де-факто по взаимодействию 1С с сайтами. Это очень важно, поскольку изначально и ставилась такая задача: не монополизировать, не сделать закрытым обмен, а предоставить возможности для дальнейшей доработки, совершенствования обмена и его адаптации под конкретные внедрения. А значит цель по выбору оптимальной архитектуры, на наш взгляд, была достигнута.

Чтобы топик не получился очень длинным, на сегодня все.

Во второй части статьи мы расскажем:
  • Как была оптимизирована передача данных между 1С и сайтом
  • Как передаются большие объемы данные и преодолеваются с типовые ограничения хостеров
  • Какой интерфейс настройки интеграцию под конкретные задачи как в 1С, так и на сайте
  • Как предоставляется возможность дорабатывать обмен и делать нестандартные вещи

Продолжение следует…

С уважением, руководитель отдела развития бизнеса
Артем Рябинков
Автор: @Ryabinkov
1С-Битрикс
рейтинг 94,35

Комментарии (81)

  • –4
    Очень актуальная тема, спасибо. Состыковка внутренней ERP-системы с веб-сайтом и связанные дико геммороидальные вещи:
    — синхронизация и ее формат (вебсервисы, хмлки, цсвшки и т.п.)
    — действия в случае обрывов синхронизации, попосылка пакетов
    — объектная мастер-мастер репликация данных
    — разрешение конфликтов синхронизации

    Нужно добивать это направление, оно очень востребовано на рынке.
    • +13
      Да, давайте будем писать положительные отзывы на свои же посты.
      • +5
        Тема синхронизации веб-проекта с внутренней системой типа 1С — одна из наиболее распространенных, сложных и актуальных задач. Кто не занимался этой проблемой серьезно — не поймет :-)
        • 0
          3 года назад синхронизировал прайс-лист из 1С 7.7 аналит-фармация с внешним приложением на .Net через интернет, ничего особенного, если оставить в стороне критику 1С. Хотя, безусловно, эта задача одна из самых частых в Российском бизнесе.
    • –4
      Какие же дебильные решения приходится выдумывать, когда нет прямого доступа к базе. нормальной базе. а не то что формирует 1с.
      • +6
        Про прямой доступ к базе я писал выше. Есть проблемы. Кроме того, если сайт стоит на хостинге а ERP система внутри конторы, то лазать в базу, будь она самая распрекрасная — не самая хорошая идея.
        Также рекомендую попробовать массово продавать решение, когда сайт ползает в базу ERP с финансами, бухгалтерией и т.п. Я пробовал.
        Даже когда нарисуешь все технические моменты и распишешь, что проблемы исключены, у руководства всегда есть подсознание того, что вы не идеальны, и если что-то накосячите, то могут быть мегапроблемы.
        • –5
          а создавать пользователя, который может производить чтение только в определенных таблицах, только определенных колонок не пробовали?
          вы переводили базу на postgre? видели, что внутри получается?

          ваш подход на базу с более миллионом товаров актуален? не верю.
          • +4
            > а создавать пользователя, который может производить чтение только в определенных таблицах, только определенных колонок не пробовали?

            Я еще раз повторюсь. Сделать технически можно, и без проблем. Доступ, права и так далее. Вопрос не в этом. Сложно такое продать из-за психологического барьера и сложно будет настроить неайтишнику и из коробки работать не будет.

            > вы переводили базу на postgre? видели, что внутри получается?
            С PostgreSQL мы не работаем, работаем с MySQL, Oracle, SQL Server.

            > ваш подход на базу с более миллионом товаров актуален? не верю.
            Во-первых, базы на миллион товаров это не массовый спрос. А во-вторых наш подход здесь актуален. Миллион товаров передается не одним куском, а порциями. Да, первая загрузка каталога будет долгой. Далее выгружаться будут только изменения. Обо всем этом я напишу в продолжении статьи.

            Если захочется миллион товаров в первый раз выгрузить быстрее, нет проблем. Поставьте рядом базы сайта и ERP, и выкачайте товары прямыми запросами или через CSV. Далее обменивайтесь изменениями по стандартной схеме. Такие доработки — пожалуйста.
  • +11
    Я как раз недавно сделал интеграцию со своей cms по этой схеме.
    И несколько дней потратил на то, чтобы 1С начал воспринимать кодировку UTF8.
    Уже какие только заголовки в ответ не отвравлял, 1С упорно считал что мой ответ в cp1251 (хотя сам же по умолчанию отправляет UTF8)
    Как оказалось, нужно в начале ответа сперва отправить UTF8-BOM. Хоть бы указали это в документации!
    • +2
      Кстати, сам 1С BOM не отправляет, а в ответ требует!
      • 0
        Плавали, знаем) я намучился с автоматическим добавлением новой номенклатуры… в итоге при импорте менял кодировка входящего файла!
        • 0
          А я не плавал, и вообще 1С первый раз в жизни увидел. Мне чуть мозг не взорвало )))
          • 0
            У нас слава богу есть программист 1с, то есть в 1с саму мне не пришлось лезть. По моей просьбе сделана была выгрузка в текстовый файлик с набором полей, которые мне надо, а я уж просто скриптом по крону хватал товары в бд)
  • +18
    Не обижайтесь, но любые задачи, связанные с «1С предприятие» и «1С бухгалтерия» вовсе не выглядят интересными и попахивают хорошо ферментированным коболом.
    • –3
      Конечно без обид :) На самом деле задача для нас была интересной прежде всего не из-за 1С как таковой. Это самая массовая система и с точки зрения востребованности на рынке это было плюсом. Вместо 1С может быть любая другая система, и наши партнеры писали нам об интеграции и с Navision, и с SAP, и со своими внутренними самописными системами — основываясь на готовой интеграции с 1С. Интерес как раз в сложности сделать так, чтобы из коробки интеграция подходила как можно большему числу клиентов, без доработок и работала без доработок и особой хитроумной настройки.
      • 0
        Не знаю как у Navision но у SAP в отличие от 1С своих средств по интеграции хоть отбавляй: Business (java, .net, dcom) Connector, RFC, LSMW, выход через BSP, WDP и еще куча страшных слов и методов ;)
    • –1
      Но их нужно решать, блин :-) А решений сейчас очень мало и они попахивают слоновым навозом. А задача сложная, нестандартная. Мне приходилось один раз битрикс синхронизировать с SAP — задача сложнейшая, но очень интересная.
  • +8
    Ну а формат CommerceML это вообще анекдот какой-то
    • +2
      Поясните, в чем вы видите недостатки? И что предпочитаете в качестве аналога (ну разве что, кроме CSV — его преимущества и недостатки очевидны).
      • +5
        Хотя бы то что не все XML-парсеры умеют работать с русскими тегами. Или то, что он преподносится как «международный формат».
        Да и разве не смешно выглядит следующее?
        <БазоваяЕдиница Код="796" НаименованиеПолное="Штука" МеждународноеСокращение="PCE">шт</БазоваяЕдиница>
        • +1
          Преимущество или нет русскоязычных тегов — это да, вопрос. Выглядит действительно уж очень необычно, после того, как программишь и пишешь все на английском.
          Например есть стандарт HL7 для медицины, многие жалуются что полностью все буржуйское и вроде как делаются или делались даже переводы. В качестве преимуществ русскоязычных тегов обычно сразу называют понятность того или иного тега, без перевода, без разъяснений. Просто перевод слова в разной предметной области тоже разный.
          Насчет парсеров — не уверен, мне кажется большинство уже поддерживает.
          Я думаю какую то аналогию можно провести с доменами. Ну уж очень непривычно писать по русски, просто рука не поднимается. Но как бы есть и плюсы, с той же транслитерацией.

          В общем и целом если с точки зрения решения задачи — наверное, особо не имеет значения.

          Насчет международного стандарта — мне сложно прокомментировать. На сайте 1С написано, что разрабатывался стандарт при участии специалистов Microsoft, может поэтому решено было так заявить. Не знаю.

          Когда мы начинали, мы посмотрели формат, поняли что годится, поддержали.
          • +2
            >Выглядит действительно уж очень необычно, после того, как программишь и пишешь все на английском.
            Для 1С-программистов вполне даже себе обычно и привычно работать с «русским» xml )

            Кстати, год назад отдаваемый 1С commerceML даже не проходил валидацию по xsd-схеме на сайте «стандарта».

            А расширенная версия интеграции от Битрикса «пихает» туда свои тэги, которых просто не хватает в стандарте. Как можно после этого это вообще стандартом называть??
            • +1
              > Для 1С-программистов вполне даже себе обычно и привычно работать с «русским» xml )
              это да )

              > А расширенная версия интеграции от Битрикса «пихает» туда свои тэги, которых просто не хватает в стандарте. Как можно после этого это вообще стандартом называть??

              Не строится мертвый город. Не развивается мертвый стандарт. Кстати некоторые теги, которые мы туда «пихали» сами, уже вошли в стандарт. И еще планируется добавить. Просто согласование изменений стандарта — достаточно долгая процедура, за день и за месяц не решить.
              • +2
                Ну на мой взгляд, это стандарт должен был умереть сразу после зачатия. Уж слишком много чего не продумано в нем. Пришлось помучиться когда-то с ним основательно и поплеваться, поэтому не могу спокойно слышать что CML — это стандарт =)

                Ну а если объективно, то хорошо что хоть как-то 1С данные отдавать — принимать умеет.
                • 0
                  если бы должен был умереть, наверное, умер бы :) Возможно вы работали еще с версией 1.0, вторая редакция сильно лучше… С чем мучались то — расскажите.
                  • +2
                    Все мои проблемы были исключительно с документацией формата и расхождениями «настоящего» CML, который отдает 1С и CML на сайте формата.
                    • 0
                      ок, понял. спасибо.
        • 0
          Так пусть учатся понимать UTF, рано или поздно это произойдет :-). XML словарь можно определять на любом языке, в этом суть технологии.
          • +2
            Тогда пусть сперва 1С научится понимать UTF
        • +5
          Язык 1С не менее смешной)
      • +4
        85-90% избыточности данных, в итоге объёмы выгрузки просто колоссальные.
        • –1
          Любой XML это избыточность. И это плата за преимущества которые он дает: не привязанность к приложению, адаптация к предметной области (терминология и т.п.), метаданные.

          Возможно, для английских тегов избыточность меньше, хотя может и не факт.
          • +2
            XML сам по себе избыточен, это да. Но никто не отменяет продумывать стандарты так, чтобы они содержали как можно меньше избыточных данных.

            А называть элементы в стандарте типа «БазоваяЕдиница», а атрибуты «МеждународноеСокращение» это уж слишком…
            • 0
              Зато понятно что это за тег или атрибут без всякого описания.

              Кстати, на скорость обработки XML, это не влияет, а сам XML зипуется при передаче со степенью сжатия мама не горюй (именно за счет множества повторов). А если нет разницы — то зачем называть БазЕд вместо БазоваяЕдиница?!
              • +1
                На самом деле для описания структуры как раз существуют xsd-схемы, которые позволяют разработчику не в двух словах понять что это за атрибут и на что он влияет.
                Ну тут как раз проблема в том, что xsd схема не обновляется с развитием формата и пользователю даже сообщение об ошибке не вывести, что xml документ не соответствует стандарту и по каким причинам не соответствует…

                A gzip не на каждом хостинге есть или включен)
                • –1
                  > На самом деле для описания структуры как раз существуют xsd-схемы, которые позволяют разработчику не в двух словах понять что это за атрибут и на что он влияет.
                  xsd есть и в commerceml, одно другому не мешает а дополняет.

                  > A gzip не на каждом хостинге есть или включен)

                  Теоретически да, и кстати в протоколе как я написал в посте это учитывается. Но в настоящее время почти у всех он есть. А если у кого то их хостеров не включен и это важно — сообщите нам, мы поговорим с ними. Очень многие легко идут на контакт. Да и сменить хостинг не проблема.

                  > Ну тут как раз проблема в том, что xsd схема не обновляется с развитием формата и пользователю даже сообщение об ошибке не вывести, что xml документ не соответствует стандарту и по каким причинам не соответствует…

                  Коллега, мы ударились в спор о формате. Хотя статья не об этом. Еще раз подчеркну — если есть другой готовый XML формат передачи о товарах и услугах, скажите. У нас был выбор — взять готовое или писать что-то свое. Мы выбрали первое. Да, возможно, были какие-то ошибки с самой схемой, но сам формат мы не разрабатываем и не отслеживаем. Насколько я знаю, сейчас с xsd все в порядке, если нет — напишите в личку, попробуем разобраться и исправить ситуацию.
                  На наш взгляд — формат, особенно в текущей редакции очень хорошо приспособлен для решения поставленных задач. И имеет больше достоинств, чем недостатков.
        • 0
          так вы в xml не все пихайте, а только то что нужно.
          • 0
            Разумеется, задействуются только те теги, которые нужны.
    • –1
      Анекдот — это когда смотришь, а когда пытаешься работать — полный мрак. Мало того, что половина валидаторов отваливается, так к этому документация, написанная уж очень специфическим языком (от такого русского хочется к английскому бегом бежать), крайне скудное коммьюнити, с UTF-8 тоже порядком наимелся. Документацию о том что как проходит авторизации для заливки, вообще пришлось получать методом народного тыка и ковырянием в исходниках обновлялки bitrix.

      Ну ок, долго думали и надумали сделать все с русскими тегами. Понятно, что у 99% кроме ребят из bitrix, а может и у них, возникают с этим проблемы. Так блин, неужто так тяжело сделать и выложить в общий доступ файл для трансформации или консольные утилиты для перевода в валидаторо-человеко-не1Со-подобный вид. Ладно компании, пишущие специфические софты, они могут и в командировку спецов заслать, чтобы «разбирались», но ведь основная часть разработчиков, которым нужен CommerceML — это веб-девелоперы. И нужен он им чтобы цены поменять, да заказики с сайта забрать. Может специальный протокол для «простых» людей сделали бы…

      Ну и в добавок, поправьте если я неправ, весь этот CommerceML тупо довеска к 1С Управлению торговлей и в других конфигурациях практически не используется.

      Вообще, складывается впечатление, что весь этот протокол сделан просто для ребяток из Bitrix. Немного кто его полностью победил. Большинству проще дать денег одной из студий продвигающих Bitrix, чем занимать время своих разработчиков, на разбирательство что цэ да как. Т.е. сделаем специально, чтобы разобраться было посложнее…
  • +4
    Никак не пойму, почему имея в 1С модуль обмена с сайтом приходится его вручную еще обновлять?
    • 0
      потому что это 1с
  • 0
    Наверное вы имеете в виду модуль для 1С: Управление торговлей 10.3. В ней уже есть интеграция, но с нашего сайта мы поставляем дополнительный модуль, расширяющий возможности. К сожалению этот дополнительный функционал не удалось включить в типовую поставку (1С не наш продукт).
    Но для новой УТ11 почти весь этот расширенный функционал есть в типовой поставке.

    Согласен, что несколько неудобно, мы даже сделали спец.табличку на нашем сайте, которая иллюстрирует где чего есть в продуктах 1С: 1c.1c-bitrix.ru/ecommerce/require_1C.php. Но поскольку это не наш продукт, мы разумеется не можем принимать окончательное решение что и куда включать.
  • 0
    Со стороны разработчика на Битрикс вставлю свои 5 копеек.
    Модуль обмена данными был внедрён в стандартную поставку 1С только с версии 8.0
    Одновременно с тем 95% клиентов, которым нужна интеграция (у нас по крайней мере, может кому-то больше везёт) используют версию 7.7.
    Для «семёрки» же интеграция с Битрикс представляет собой элементарный обмен данными через CSV (один из примеров: 1c.1c-bitrix.ru/blog/blog1c/1542.php) то есть, если смотреть глобально, то обыкновенный «костыль».
    Давно уже армию разработчиков будоражит вопрос: «Доколе!?»
    • +2
      Да, вопрос по 7.7 один из самых популярных.
      Во-первых, 7.7 только поддерживается 1С, и они настоятельно рекомендуют обновлять. Со своей стороны (я не продаю 1С и не зарабатываю на этом) переход — вопрос очевидный, по возможностям и удобству платформа 8 явно лучше, это общее мнение специалистов кто с этим плотно работает.
      Новые клиенты почти все покупают решения на платформе 8.1 и 8.2.
      Во-вторых, если посмотреть на реальные инсталляции 7.7, то огромное количество вдоль и поперек допиленные и перепиленные (кстати во многом именно вследствие ограниченности штатного функционала). Если даже выпустить модуль — то 90% он нормально не встанет.
      То есть если мы выпустим такой модуль — то умрем отвечать на вопросы как его инсталлировать на нестандартную конфигурацию, но и пойдем вразрез с общей тенденцией развития функционала в 1С.
      • 0
        Во-вторых, если посмотреть на реальные инсталляции 7.7, то огромное количество вдоль и поперек допиленные и перепиленные

        Вот потому и не переходят на «восьмёрку» — слишком много эксключивно под предприятие дописанного функционала, перенос которого в новую версию связан с колоссальными трудозатратами. Причём, чем крупнее предприятие, тем такого функционала больше.
        Замкнутый круг =(
        • 0
          Да, это проблема, и я с вами полностью согласен. Но если предприятие пошло по пути разработки уникального кода, то возможно будет проще написать аналогичный модуль с поддержкой формата и протокола, чем пытаться адаптировать тот, который предложим мы.

          Кроме того, я забыл еще одну причину по 7.7 сказать, и, думаю основную. Разработка под 1С — совсем не наш бизнес и профиль. Мы аутсорсим разработчиков 1С для этого, мы также оказываем техподдержку по вопросам 1Совским модулям, где отвечают те же специалисты. Хотя в принципе это не наша стезя, мы CMS делаем. Но вынуждены, ибо спрос на интеграцию очень большой, а это всегда порождает нагрузку на саппорт.
      • 0
        Выпустите уже модуль под стандартную конфигу. А мы уж допилим…
  • 0
    Как-то не раскрыта тема скорости получения заказов с сайта. Логичо предположить, что имеем нехорошую зависимость — скорость реакции на заказ обратно пропорциональна частоте «опроса».

    Чтобы побороть это, лет 10 назад пришлось использовать промежуточное звено, которое таки сидело на 80м порту, ждало зеленый гудок от сайта (тоже XML через HTTP) и пинало 1С когда надо.

    Так что видимо ничего нового за последние 10 лет не придумано. Идея «чтобы сайт не задосил 1С — пусть 1С задрючит сайт запросами раз в пол минуты» както уж не очень красива.
    • +1
      > Идея «чтобы сайт не задосил 1С — пусть 1С задрючит сайт запросами раз в пол минуты» както уж не очень красива.

      Я в целом я не вижу ничего плохого чтобы раз в полминуты дернуть сайт. У вас на сайт за 10 секунд может зайти 50 человек, и лишний запрос раз в полминуты погоды не сделает.

      Кстати какое терпимое время реакции на заказ клиента? вряд ли полминуты. Представьте, вы сделали заказ, еще опомниться не успели, а вам уже звонят. По моему комфортное и тактичное время — 5-10 минут. Сделайте обмен раз в 5 минут — вполне достаточно и сайт не надо «дрючить».

      А если заказы уж такие прямо частые и невмоготу ждать, либо надо сразу резервировать товар в 1С, можно сделать доработку. Открыть тот же веб-сервис на стороне 1С, и заставить сайт туда стучаться, повесив обработчик на событие создания заказа. Я не говорил, что веб-сервисы это плохо. Это очень хорошо, но для конкретной задачи, а не для «широких слоев» =).
      • 0
        Я в целом я не вижу ничего плохого чтобы раз в полминуты дернуть сайт. У вас на сайт за 10 секунд может зайти 50 человек, и лишний запрос раз в полминуты погоды не сделает.

        Ну поэтому я и не говорю, что она плохая, говорю, что «не красивая». Это как иногда пишут взаимодействие 2х виндовых программ через папку с файлом, одна постоянно его читает, вторая тужа что-то кидает. И это в век инноваций и модернизаций!

        Кстати какое терпимое время реакции на заказ клиента? вряд ли полминуты.

        В случае, если это пиццерия — это как раз одна минута. 5 минут там — непростительная роскошь.
        • +1
          > говорю, что «не красивая».

          Да, согласен. Красиво веб-сервисы, но каких жертв требует эта красота я написал :)

          > В случае, если это пиццерия — это как раз одна минута. 5 минут там — непростительная роскошь.

          Спасибо, реальный опыт интересен.
  • –3
    <зануда mode>
    Процент полезных картинок — ровно 15%.
    </зануда mode>
  • 0
    Я только хочу спросить для чего надо было делать iblock и туда все впихивать? При выгрузке у меня Mysql выдает 3500 запросов в минуту (это примерно в 27 раз больше чем все остальные 14 сайтов на этом сервере)?
    • 0
      Инфоблоки — универсальное хранилище платформы. С ними работает большинство функционала продукта. Вы, наверное, знаете как устроен модуль и из каких таблиц. Да, если много свойств, будет много joinов. Если использовать режим хранения свойств в отдельной таблице, то число запросов будет намного меньше.
      Еще раз повторюсь — это первичная выгрузка каталога. Далее пойдут только изменения, а это ерунда.

      Если не инфоблоки, то куда? городить отдельную сущность с которой работу организовывать — тоже нелогично.
      • 0
        Универсальное не всегда быстрое. Логично что отдельно, разве каталог это не одно из основных ваших направлений?
        • +1
          У инфоблоков очень много преимуществ, которые также придется реализовывать в новой сущности. Это большое и гибкое API, куча событий, кастомизация карточек объектов и разделов, автообработка изображений и еще много всего. Это и позволяет из коробки решать многие задачи сразу и быстро, сокращая срок разработки проекта и решать бизнес-задачи.

          Еще раз повторюсь, режим инфоблоки+ снижает число запросов, чтобы за универсальность дорого не платить. А проекты с большой посещаемостью и большими каталогами на нашей системе есть и работают.
          • –1
            Я вас понял. Главное быстро, серваки пусть мучаются.
            • 0
              все же мой ответ был из 2х абзацев, вы прочитали первый, но не второй :)
              • 0
                Ничего против битрикса не имею. Перерыл его вдоль и поперек и нашел очень много старого кода. Видимо программисты менялись чаще чем код. Но все равно вы молодцы.
  • –5
    Особенно мне нравится то, что приходится танцевать с бубном, чтобы интегрировать продукты одной и той же компании
    • +1
      Битрикс (где разрабатываются продукты) и 1С совершенно разные компании, особенно в части технологической. 1С-Битрикс — это совместное предприятие 50:50 между Битрикс и 1С для продажи продуктов, не более.
      Для большинства задач интеграции бубен не требуется. Берется 1С, берется битрикс, и настраивается обмен.
      • 0
        Вы меня простите, но я называю это бубном )
        А за то, что прояснили, что это разные компании — спасибо. Не знал.
        • 0
          > я называю это бубном )

          прошу прощения, «это», это что?
  • –1
    Мои 5 копеек ненависти к битриксу.

    Вот я 1с программист, за последние несколько лет сделал успешную интеграцию 1с с несколькими крупными интернет-магазинами. Кроме этого я видел как устроены другие интернет магазины и их связки с 1с. Мой вердикт, битрикс — УГ, стандартная связка битрикса с 1с через всякие CommerceML и прочие xml — кошмар.

    Простите, не мог сдержаться.
    • +3
      > Кроме этого я видел как устроены другие интернет магазины и их связки с 1с

      Если вы имеете в виду другие тиражные CMS для интернет-магазинов, то давно всем широко известно, что многие из них используют не только нашу концепцию обмена, но еще и разработанный нами вместе со специалистами 1С модуль для 1С: Управление торговлей (хорошо если тот, что в типовой поставке — он все таки принадлежит 1С, но особо умные предлагали своим клиентам и чисто наше расширение интеграции, выдавая его за своё). В этом заключается их ноу хау.

      А если вы имеете в виду решение какой то конкретной задачи интеграции для конкретного сайта, то вы просто не прочитали пост. Я не зря долго распространялся на тему массовости, универсальности и простоты настройки.
      • 0
        Незнаю, незнаю, лично я нигде не видел в больших интернет магазинах что-то от битриксовского обмена. И уж тем более если стоит не битрикс, то никто ничо битриксовского не использует, ибо — кочмар. :0)
      • 0
        Ваша концепция обмена это единственная концепция (не считая танца с бубном и настройкой 1С в качестве веб сервера), предлагаемая 1С для обмена данными «из коробки».
        Если бы 1С думала немного о веб-разработчиках, они бы сделали общее решение и общий протокол обмена данными. Но им это не нужно, без этого хорошо живется без конкуренции =)
        • 0
          > Если бы 1С думала немного о веб-разработчиках, они бы сделали общее решение и общий протокол обмена данными.
          Это и было сделано — общее решение, протокол обмена, и 1С позиционирует это решение именно как универсальное и общее для всех CMS систем и отдельных решений.
          • 0
            Ну согласитесь, что настройки для Битрикса и лого в модуле как бы напоминает, что оно не совсем «общее» и универсальное.
            • +1
              Лого есть только в версии УТ 10.3, в 11й отсутствует.
              • 0
                вот это уже правильно.
                А сам встроенный модуль развивается хоть как-то? А то я помню, что там даже типы полей в свое время не приходили. Все можно было только «как строки» импортировать на сайт и со справочниками беда была.
                • +1
                  Да, развивается. Но развивается тот, который идет в типовой УТ11, а для УТ10.3 развивается наш модуль расширения.

                  По поводу справочников — проблема давно решена в модуле расширения для 10.3 и после расширения CommerceML — в последнем обновлении для УТ11 (выйдет вместе с новой версией в середине октября)
                  • 0
                    Можем быть прокомментируете, зачем в новых конфигурациях выгружается два файла import.xml и offers.xml вместо одного, особенно если от них надо только две вещи (с включенными галочками) — артикул и остатки.
                    И жаль что из коробки нет выгрузки на FTP по расписанию.
  • 0
    Не хочу комментировать все написанное в статье и комментарии как пользователей, так и сторонних наблюдателей. От себя лишь добавлю, что причины минусов подхода развертывания приложения средствами самого 1С только 2, а не все эти перечисленные, которые актуальны как для первого варианта, так и для второго:
    1. Уязвимость. Бред давать доступ к тому, где есть общая информация, к которой посетитель сайта не должен иметь доступ, ведь в 1С помимо управленческого учета часто ведется и финансовый (если фирма небольшая, для больших финансовый ведется в другой базе)
    2. Заведение новых пользователей. Сами пользователи себя зарегестрировать не смогут. Т.е. все заказы идут или от одного «лица» на сайте, или персонал фирмы должен оперативно регистрировать в 1с, или писать сторонний скрипт, который это будет делать сам.

    Это всё.
    • 0
      Спасибо, за прочтение и ответ.
      Да, это основные минусы: безопасность и сложность в настройке. Насчет зависимости работы сайта от 1С и наоборот, то частично с вами согласен — это также сильно зависит от реализации интеграции.

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

      В любом случае благодарю за конструктив.
      • 0
        Про безопасность я писал.
        С нагрузкой не соглашусь, т.к. во-втором случае к нагрузке на сервер добавляется дополнительная база под сайт (пусть это снижает нагрузку на базу 1с), дополнительная нагрузка на обмен, ведь теже данные все равно должны обменяться.
        • 0
          ну полностью запрашивать товары из ERP, даже при условии кэширования, это очень существенная нагрузка на базу, ни в какой степени не сравнимая с нагрузкой на обмен (кроме первого импорта всего каталога, который можно сделать ночью).
  • 0
    Пока эта связка всё-равно выглядит кривой, да и дебажить очень сложно, тестов нет, настройки не интуитивные.
    Недавно описывал проблему интеграции: lin-id.livejournal.com/70904.html
    • 0
      Мы явно content-length не указываем, это делает платформа 1C автоматом. Если делает криво в каких-то случаях и данный код помогает – то можно взять на вооружение. Спасибо!
      Над улучшением механизмов отладки и удобства доработки функционала мы работаем.
  • 0
    Интересно каким образом вы выгружаете изображения товаров в интернет-магазин — этот вопрос планируется осветить в следующих частях?
    • 0
      Выгружаем файлами, которые передаются вместе с xml файлами. Да, во второй части покажу схему выгрузки.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное