Интеграция с 1C — готовьте напильник25.05.2016 11:33

Считается, есть две вечные темы для обсуждения — любовь и смерть. А мы нашли третью — интеграция с ERP клиента. Мы уже писали о ней, и не раз. И всегда остаётся, что добавить.

Интеграция — космически важная штука, потому что она делает возможным:

1. Автоматически выгружать существующие товары из системы на сайт. Номенклатуру, остатки, цены.

2. Забирать оформленные пользователями заказы с сайта в систему.

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

Тип интеграции	Плюсы	Минусы	В каком случае подойдет
Текстовый файлик (или CSV) $—$$$	Простая структура данных. Почти всегда ERP может выгрузить данные таким образом. Легко воспринимается человеком (другой вопрос — зачем человеку это нужно).	Простая структура данных. Чтобы передать информацию сложнее «Название — Описание — Характеристика — Цена», придется сильно напрячься. Простая структура данных в одном файле выльется в набор файлов, и это всё надо будет кодить — время, деньги, ветер. Чтобы сделать иерархию категорий товаров и сами товары, скорее всего, придется делать несколько файлов. Даже сложную структуру можно вложить в данный формат —, но будет трудно.	Передаются плоские данные, структура максимально проста. Есть поддержка данного формата в ERP. (Если нет, то нужен специалист по системе для создания такого функционала). Если вам захочется использовать справочники или любые другие усложнения структуры данных (например, цвет в товарах с иконкой цвета, бренд с логотипом и т.п.) — это увеличит время и стоимость разработки.
CommerceML $$	Открытый формат, разработанный для российского рынка. Легко расширяем. Теоретически. Является штатной интеграцией 1С с сайтом. Фактически — это хорошо документированный вариант передачи коммерческих данных в XML. Доработка функционала возможна, но лучше её избегать. Иначе можно потерять возможность обновлять платформы и модули интеграции. Мелкие доработки не ломают возможность апдейта систем. Хотя это всё индивидуально.	Нужно тщательно следить за версиями формата в ERP и CMS. Например, в ERP будут необходимые данные, но CMS не сможет эти данные «понять» из-за разности форматов. Так как формат открыт, некоторые решения строят на нём с собственными доработками. И, хотя утверждается, например, поддержка формата cml2, нужно «вчитываться в мелкий шрифт». Доработанный формат накладывает свои требования на передаваемые данные. Формат наворочен, с нуля писать его поддержку — серьёзно упороться по времени. Несмотря на мощь — «тонкости» могут не учитываться, и всё равно потребуется доработка. Формат для большинства решений избыточен.	Есть модули для платформ участвующих в обмене. Если нужны доработки, то понадобится программист ERP системы.
Нештатный обмен XML/JSON $$$	Собственная структура данных, поэтому в ней содержатся только необходимые данные. Никогда не надо писать с нуля, т.к. через XML всегда есть сторонние минимальные решения.	Нужно проработать формат данных. Если формат получается сложным, стоит подумать об использовании СML.	СML не удовлетворяет требованиям и избыточен. Сложная структура данных. Есть программист на стороне ERP системы.
Промежуточная база (mysql/ms sql) $$ — $$$	Относительно высокая скорость обмена. ERP-система изолирована от сайта/	Сложная поддержка консистентности баз. Трудоемко вносить структурные изменения, т.к. требуется одновременная модификация сразу нескольких баз данных и протоколов.	В случаях, где требуется наибольшая производительность, а структуры данных меняются редко.
Web-сервисы (SOAP/REST) $ — $$$	Протокол уже существует.	Если поддержка в CMS отсутствует, то придется её реализовывать.	В ERP системе есть веб -сервисы, и их использование в приоритете. Если уже есть поддержка в CMS. Бывает как просто и дешево, так и сложно и дорого — цена индивидуальна и зависит от сложности протокола.
NoSQL-решения $$$	Атомарность данных. Пример: каждый товар — это отдельный документ. Очень быстро — данные каждого товара собраны в одном месте, нет необходимости собирать по всей базе. Аналогично с заказами.	Для пользователей и заказов могут существовать свои структуры данных в CMS. Сделать всю интеграцию через одно NoSQL решение, скорее всего, не получится. Не подходит, чтобы использовать NoSQL как хранилище промежуточной информации, и в дальнейшем синхронизировать эти данные со стандартной структурой. В таком случае придётся отказаться от части функционала CMS и хранить данные контрагентов и заказов только в noSql хранилище.	Есть программист на стороне ERP системы. Большое количество связанных данных для большинства передаваемых элементов — когда классический подход с реляционными хранилищами отпадает из-за медлительности.

Интеграция из коробки: коробка в яйце, яйцо в утке, утка улетела на юг

Владельцы интернет-магазинов, которые хотят упростить жизнь менеджеров, любят искать в интернете, как бы устроить интеграцию, да попроще. Первой ссылкой по их запросу выпадает сайт Битрикса (эх, никаких сюрпризов). Он сладко рассказывает про «естественную интеграцию из коробки», «простоту настройки», и что «не нужно обладать специфическими знаниями», чтобы интегрироваться и жить долго и счастливо.

Мы, конечно, можем устроить интеграцию любым способом из таблицы выше, но, так как наш гипотетический заказчик уже по уши зарылся в сайт Битрикса, рассмотрим вариант с 1С. Он, к тому же, самый распространённый.

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

На самом деле, разработчики сильнее остальных мечтают, чтобы интеграция проходила легко и просто. Но так бывает не всегда. По нашему опыту — только в 25% случаев, когда интеграция штатная.

Штатная интеграция подходит только в случае, если конфигурация системы стандартна, 1С-специалист ничего не менял.

Если вашу базу ковыряли и перекраивали, то ситуация нештатная. Такая база будет активно сопротивляться интеграции из коробки. Чтобы заставить её работать с сайтом, придётся потанцевать с бубном. И чем активнее, тем интеграция будет дольше и дороже.

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

Как строится процесс

1Если заказчику нужна интеграция c 1C, то о масштабе задачи нам нужно знать как можно раньше. Поэтому уже на этапе продажи возникают неудобные вопросы вроде «Какая у вас версия 1С?» и «Занимается ли базой какой-нибудь специалист? А что он с ней делает?»

Не всякий топ-менеджер или маркетолог в курсе, что творится с его системой. Но без этих данных дать информацию по стоимости и срокам интеграции невозможно — вилка получается такая, что никакой конкретики: от 8 до 80 часов на описание протокола и от 40 до 200 часов на реализацию интеграции. Поэтому знать, с чем мы имеем дело, нужно уже на этапе прототипа.

Мы просим заказчика вместе с его специалистом заполнить чек-лист. Это помогает понять, чем должны обмениваться сайт и 1C клиента, и в каком состоянии последняя. Так понимаем, насколько всё запущено, сужаем сроки и вилочную стоимость.

2Когда чек-лист заполнен, и масштаб работ примерно понятен, нужна выгрузка. Получить её — отдельный квест. Ждать выгрузку можно дольше, чем делать сайт, интеграцию и праздновать сдачу проекта. Всё потому, что:

• Базу переделывают. Старую показывать смысла нет, а новая пока не готова. Сидим, ждём.

• Специалист со стороны заказчика не умеет/не хочет/просто забыл дать выгрузку. Если проблему не получается решить через заказчика, берём дело в свои руки. Коллами и переписками объясняем специалисту 1C, чего мы хотим и как это сделать. Если результатов нет — просим доступы и решаем все вопросы самостоятельно. Не обходится без фэйлов.

Это весело и забавно, но если хочется всё делать чётко, у нас есть парочка проверенных спецов по интеграции c 1C в Москве. Если у заказчика всё очень плохо — приедут и настроят.

3Выгрузка получена, готовы прототип и ТЗ. Теперь нужно:

• понять, как сделать из нештатного штатное, чтобы по максимуму полетело из коробки;

• разобраться, что из пожеланий заказчика и предложений студии можно сделать в 1C, а что — нельзя;

• выявить, какие есть риски, и дать заказчику точную оценку по интеграции.

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

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

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

Сначала разработчик анализирует выгрузку, соотносит её с прототипами. Выясняет, где нужно будет поработать напильником: на сайте или в 1C. И делает костяк протокола. Все пункты помечаются соответствующими пиктограммами:

Кроме флажков и галочек, в протоколе есть вещи серьёзные. Ради чего проводится интеграция: экспорт товаров на сайт, импорт заказов, если необходим. И папки с файлами выгрузки. К ним и к протоколу доступ есть у всех участников процесса.

Вот так масштабно получается. Руки боятся, да? Успокойте их — не нужно делать всё и сразу. То, без чего сайт не будет сайтом, допиливается в первую очередь. А приятные, но не критические фишки типа тех же скидок за лояльность, можно отложить на второй этап работ над интеграцией.

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

Мнение: Ирина, Руководитель проектов

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

 

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

Это повод менеджеру проекта снова перечитать общее ТЗ и светофором покрасить, что всё-таки будет на сайте, а что реализовать не получится. То же самое сделать с прототипом, и лучше — вместе с заказчиком. Это хороший способ отловить все взаимодействия. Правда, возится с прототипом — процесс долгий и немного занудный, поэтому пользуемся им только на самых хардкорных проектах.

5Когда интеграционный протокол, ТЗ и прототип готовы и покрашены флажками / текстовыделителями, можно наконец ответить на самый важный вопрос заказчика — сколько это стоит. Составляется точная смета, утверждается протокол работ.

Цена зависит от того, насколько интеграция была далека от штатной. Чем дальше — тем дороже.

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

Полный текст статьи читайте на CMS Magazine