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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В любом случае благодарю за конструктив.
Про безопасность я писал.
С нагрузкой не соглашусь, т.к. во-втором случае к нагрузке на сервер добавляется дополнительная база под сайт (пусть это снижает нагрузку на базу 1с), дополнительная нагрузка на обмен, ведь теже данные все равно должны обменяться.
ну полностью запрашивать товары из ERP, даже при условии кэширования, это очень существенная нагрузка на базу, ни в какой степени не сравнимая с нагрузкой на обмен (кроме первого импорта всего каталога, который можно сделать ночью).
Пока эта связка всё-равно выглядит кривой, да и дебажить очень сложно, тестов нет, настройки не интуитивные.
Недавно описывал проблему интеграции: lin-id.livejournal.com/70904.html
Мы явно content-length не указываем, это делает платформа 1C автоматом. Если делает криво в каких-то случаях и данный код помогает – то можно взять на вооружение. Спасибо!
Над улучшением механизмов отладки и удобства доработки функционала мы работаем.
Интересно каким образом вы выгружаете изображения товаров в интернет-магазин — этот вопрос планируется осветить в следующих частях?
Выгружаем файлами, которые передаются вместе с xml файлами. Да, во второй части покажу схему выгрузки.
Only those users with full accounts are able to leave comments. Log in, please.