Поехали.
Этап 0: Выбор модели обмена
Нам надо понять, какими объектами мы будем обмениваться с сайтом. Наиболее популярные варианты удобно представить в виде таблицы:
|
|
Базовый |
Расширенный №1 |
Расширенный №2 |
Полный |
|
Загрузка заказов |
+ |
+ |
+ |
+ |
|
Выгрузка статусов, комментариев, трек-номера заказа |
|
+ |
+ |
+ |
|
Выгрузка остатков и цен |
|
|
+ |
+ |
|
Выгрузка всех корректировок по заказу |
|
|
|
+ |
Эта таблица наглядно показывает какими объектами нам предстоит обмениваться, а так же при общении с Заказчиком / Работодателем позволяет максимально быстро прийти к нужной модели обмена. Дело в том, что часто приходилось сталкиваться с заказчиками, которые изначально не совсем понимают что конкретно они хотят получить от обмена. Благодаря этой таблице Вам будет проще понять друг друга.
-
«Базовый» — это по сути самый простой и самый популярный вариант обмена. При таком варианте обмена нам будет доступен самый широкий выбор способов получения данных
-
«Расширенный №1» и «Расширенный №2» — часто называют «двухсторонним» обменом с сайтом. И в отличает от «Базового» здесь мы уже имеем некоторые ограничения в доступных методах обмена. На моей практике далеко не у всех сайтов есть API (или какой-ли метод обмена), позволяющий передавать все необходимые данные «культурным» способом
-
«Полный» - это пожалуй самый сложный и трудоемкий способ обмена. Зачастую для полноценного решения это задачи приходится читать и писать прямо в базу данных MYSQL сайта. Однако у многих современных движков есть API, позволяющее красиво решить данную задачу
Где же выгрузка каталога? Практика показывает, что чаще всего каталог на сайте формируется альтернативными способами. На это есть множество причин, но об этом речь пойдет в отдельной статье.
Этап 1: Выбор способа обмена данными
Поняв что нам нужно загружать и передавать на сайт, мы можем определяться со способами обмена. Наиболее популярные варианты обмена:
CommerceML
На примере Битрикс это выглядит так:
-
Нам нужно авторизоваться на сайте
-
Далее сделать запрос к сайту https://АдресСайта.РФ/bitrix/admin/1c_exchange.php?type=sale&mode=query
-
В ответ мы получим XML со всеми заказами, который легко можно загрузить в 1с
Подобный формат обмена имеет огромное количество движков, например тот же Insales, NetHouse, CS-Cart, NetCat, Diafan.CMS и т.д.
API
Аббревиатура API расшифровывается как «Application Programming Interface» (интерфейс программирования приложений, программный интерфейс приложения).
Это тоже отличный способ обмена, с которым работать одно удовольствие. Яркими представителями подобных обменов являются: INSALES, Storeland, AdvantShop.
Суть обмена заключается в том, что у сайта есть программный интерфейс для взаимодействия с внешними системами, который содержит набор команд таких как:
-
Получения заказам
-
Выгрузки остатков
-
Обновления цен
-
Корректировки заказа
-
Выгрузки трек-номера
-
Создания/Удаления товара в каталоге
-
и. т. д.
Как правило сайт «отдает» и «получает» от нас данные в формате JSON или XML.
MYSQL
Это способ обмена, имеющий самые широкие возможности для чтения и записи данных. Однако для чтения и записи данных извне вам понадобиться сделать некоторые настройки на стороне хостинга, где установлен сайт. Пример настройки на примере хостинга Beget:
Хочу обратить внимание, что я поставил доступ для чтения и записи извне с любого IP. Безусловно это не очень безопасно. Когда загрузчик будет переведен в «боевой режим», нужно будет ограничить IP адреса, с которых будет идти чтение и запись данных. Однако для тестирования — это идеальный вариант. Ведь у программиста на рабочем ПК часто нет «статического IP», что может усложнить разработку. Из всех протестированных мной хостинг-провайдеров, beget оказался самым удобным для тестирование/разработки загрузчика, работающего по данной модели обмена.
Обычно при обмене подобным способом я предпочитаю не ждать пока клиент откроет доступ (поверьте это всегда не быстро), а сделать копию базы и уже начать с ней работать (в идеале иметь и копию сайта).
Некоторые хостинг провайдеры не могут дать прямой доступ извне на чтение/запись (например reg.ru), он дают подобный доступ только через ssl, что немного усложняет разработку.
И так, мы закончили «культурные» методы обмена и настало время поговорить про «экзотику».
Парсинг сайта
Бывает так, что у сайта нет красивого способа получения или отправки данных (или данных и возможностей катастрофически не хватает), тогда приходится изобретать велосипед. Я много раз встречался с подобным, особенно на момент когда «движок» сайта находился в процессе развития (стартапа). Пример:
-
Мегагрупп — загрузка заказов не позволяла забирать все необходимые данные, выгрузка данных о статусе, комментарии отсутствовала
-
TIU.RU – заказы можно было загрузить по API, однако для выгрузки статусов пришлом делать парсинг и «имитацию» ручного изменения статуса для полной автоматизации выгрузки данных
-
Alltrades – не было корректной загрузки заказов
Прогресс не стоит на месте, возможно сейчас осталось очень мало движков, которые требуют подобных «сложный» подход для обмена.
Главная проблема подобного обмена в его ненадежности, так как малейшая корректировка верстки сайта (со стороны админки) приводит к тому, что обмен перестанет работать. Ведь по сути для получение/отправки данных мы имитируем заход на сайт (в его админ. панель) и начинаем «программно», ориентируясь на «верстку» читать данные. Если данные располагаются на нескольких страницах — делаем перелистывание страниц. Перед внедрение подобного способа обмена, обязательно нужно предупредить Вашего заказчика о всех возможных последствиях. Естественно ни о какой гарантии не может быть речи. Изменения на сайте могут произойти в любой момент и Заказчик должен понимать, что ему придется оперативно устранять проблему. Поэтому заключайте сразу договор на ТП:)
Парсинг почты
Это способ гораздо надежнее чем предыдущий, однако с его помощью можно только загружать данные. Практика показывает, что приятнее всего работать с почтовыми ящиками на yandex. С ними все легко и предсказуемо.
Данные удобнее всего получать по протоколу IMAP. Он позволяет идентифицировать «не прочитанные» письма. Выгоднее всего для подобного обмена завести отдельную почту.
Как идентифицировать заказы полученные по электронной почте? Чаще всего уникальный номер заказа будет записан в теме письма после символа «№» или «#».
Когда приходится прибегать к подобным обменам? На моей практики подобные обмены встречались по загрузке данных из:
-
Landing Page - так называемые одностраничные сайты с каким-то горячим предложением. Раняя версия конструктора одностраничных сайтов LPMOTOR при создании заявки отправлял данные либо на почту, либо на мобильный телефон
-
Скрипты для сайтов типа «купить в 1 клик»
-
«Самописные сайты» без базы данных (да да и такое тоже встречалось на моем пути)
Этап 2: Идентификация
Клиенты:
Практика показала, что самый лучший вариант идентификации физ. лиц — это Телефон, потом e-mail. При этом телефон для поиска нужно привести в нужный формат (убрать пробелы, доп. символы и разделители, убрать +7 и 8).
ФИО и адрес не являются уникальными идентификаторами, есть огромное количество людей, даже в одного городе с одинаковым ФИО.
Юр. лицо правильнее всего искать по ИНН.
При разработке загрузчика, я всегда предусматриваю возможность настройки полей для идентификации. Ведь всегда бывают исключения.
Товары:
На мой взгляд самый надежный вариант — ИД товара на сайта. Однако не всегда этот вариант доступен. Второй по популярности вариант — это артикул. Но с ним не все так однозначно. Далеко не всегда он уникален. Часто встречаются интернет-магазины, где с одним артикулом может быть множество товаров, с разными характеристиками (например товары с разными цветами имеют один артикул).
Ну если ни первый ни второй вариант нам не подошел, приходится использовать наименование товара. Ну это как вы понимаете абсолютно не надежно.
Заказы:
Для идентификации заказа конечно же нужно использовать номер заказа на сайте. Естественно нужно учесть, что если обмен будет с нескольким сайтами, нам понадобиться добавить Префикс к этому номеру (или иметь в базе дополнительный реквизит «Сайт», чтобы делать поиск заказа в базе в разрезе конкретного сайта).
Этап 3. Синхронизация статусов
Тема статусов очень объемная. Как правило главной сложностью здесь является то, что состав статусов на сайте и в 1С отличается.
Для решения это задачи можно использовать «таблицу соответствия» или привести статусы «к общему знаменателю». Как правило клиенты выбирают первый вариант.
Еще одним решением данной проблемы может быть добавление нового реквизита в 1С «статус на сайте».
Этап 4. Обновление Цен и Остатков
Для выгрузки Цен и Остатков на сайт, на стороне 1С уже должен быть загружен каталог с товарами, содержащий уникальный идентификатор, по которому Вы будете находить товар на сайте.
Как правило данный этап не содержит каких-либо подводных камней. Главное здесь определиться с частотой обмена для будущего фонового задания.
Этап 5. Регламентное задание
Ну и завершающая стадия разработки, после того, как вы закончили тестирование — перевод обработки в работу в «фоновом режиме» по расписанию. Пример настройки обработки (для выполнения по расписанию)
Ну а сама обработка для запуска в ручном режим выглядит так:
По сути мы должны сделать так, чтобы Процедура «ЗагрузитьЗаказы», которую при тестировании запускали простым кликом по одноименной кнопке стала доступна для выполнения в фоновом режиме по расписанию. Данный задача легко решается с помощью БСП, я сделаю отдельную статью с примером подобной обработки. После выполнения фонового задания в журнале регистрации можно увидеть подробности работы обработки:
Часто задаваемые вопросы:
1) Почему бы не писать данные сразу в 1С?
Ответ: На мой взгляд есть ряд причин, почему подобная схема обмена является менее популярной чем перечисленные выше варианты:
-
Бюджет — как правило при заказе обмена с сайтом, у клиента есть определенный бюджет, в который требуется уложится. Более того, если обмен делает человек или организация, делающее нечто подобное не один раз — сделать подобный обмен можно в четкие сроки и в достаточно скромные бюджеты
-
Доступность — зачастую у 1С программиста просто нет доступа к сайту, для того, чтобы вносить корректировки в механизм формирования заказа (или за работу сайта уже отвечает какая-то организация). Более того, если это SaaS решение (insales, Мегагрупп, Storeland) — это просто невозможно
-
Надежность — тут конечно спорный вопрос. Но база хостинга находится в Дата Центре, за ее работой ведется наблюдение и риск отказа хоть и есть, но он значительно ниже чем база на Вашем сервере. Просто представьте что будет, если клиент будет оформлять заказа и в момент записи данных произойдет ошибка или данные по какой-то причине не запишутся?
2) Как часто надо загружать заказы, Какая периодичность выгрузки остатков, и.т.д.
Ответ: На этот вопрос нет однозначного ответа. Все во многом зависит от специфики работы и ресурсов, которые Вам предоставляются. Так например если раз в 5 секунд обращаться к серверу за заказами, вероятно это не очень понравится многим хостинг провайдерам и Вас могут забанить (если речь идет про коннект к базе MYSQL).
