Блог → Стыковка базы V7 с витриной интернет магазина. Часть 2

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

Но для ведения "электронного" бизнеса использовать "Web-расширение" относительно безболезненно могут только солидные фирмы, уже имеющие все необходимое - толстый канал, необходимый софт, а также квалифицированный персонал. Другими словами, те, для которых дополнительная пара тысяч долларов в расходной части бюджета - что слону дробина. А что делать не входящим в категорию таких "слонов" небольшим и небогатым компаниям, которым тоже страсть как хочется покататься на модном аттракционе под названием "электронный бизнес"?

Разумеется, есть и альтернативное решение. Его концепция прямо противоположна концепции "Web-расширения". Идея, в общем-то, проста, как перпендикуляр, и состоит в следующем:
• web-витрина и учетная система являются абсолютно независимыми приложениями и могут быть расположены хоть в разных концах планеты;
• каждое из приложений работает со своей собственной базой данных;
• стыковка приложений осуществляется путем асинхронного обмена данными в заранее определенном формате;
• процесс обмена данными максимально автоматизирован и не требует вмешательства пользователя.

Нельзя сказать, что эта концепция является откровением, и на рынке уже имеются похожие готовые решения. Но как правило, все они ориентированы на самый что ни на есть low-end. Почему? Да потому, что:
• электронная торговая площадка взаимодействует только с типовыми конфигурациями V7;
• web-витрина не блещет обилием функциональных возможностей, их набор жестко определен и не может быть изменен пользователем;
• пользователь системы, строго говоря, покупает не полноценный web-магазин, а всего лишь место в каталоге, плюс возможность загрузки туда своих прайс-листов и выгрузки оттуда своих заказов;
• операции экспорта-импорта данных требуют "ручной работы" от пользователя.

Таким образом, на рынке представлены готовые решения для верхнего (собственный двухэтажный супермаркет) и нижнего (аренда павильончика на колхозном рынке) уровней. А как быть тем, кто находится посередине - не может позволить себе самое дорогое решение, но и не хочет довольствоваться самым дешевым? По всей видимости, решение придётся делать руками!

Наша система состоит из двух абсолютно независимых частей: web-магазина, расположенного где-то в интернете, и учетной системы, расположенной в нашем офисе. У каждой части - своя собственная база данных, своя собственная бизнес-логика и свой интерфейс. Конкретная реализация web-магазина и учетной системы особой роли не играет: это может быть нечто типовое, коробочное, а может быть и нечто оригинальное, собственной разработки. Нам важно только то, что на стороне офиса работает V7, а на стороне web-магазина есть какой-то из популярных в Сети языков - ASP, Perl, РНР - неважно.

Обмен данными производится в асинхронном режиме. Принцип действия системы показан на рисунке ниже.



Как работает система? Обе стороны равноправны и, по сути, являются партнёрами. Алгоритм синхронизации предельно прост и одинаков для обоих сторон:
• Пользователь системы производит некое действие (покупатель заказывает товар, менеджер изменяет цену и т.п.), результат которого необходимо довести до сведения партнера. Все эти действия записываются куда-то в лог.
• Периодически на основании лога формируется пакет задач для партнера. Если партнер забирает эти задачи, значит, он функционирует. Если не забирает - значит, он "в дауне" (попросту говоря, лежит). Это не страшно, пусть задачи накапливаются.
• Периодически проверяется, не поступило ли от партнера новых задач. Если поступили, то они выполняются (изменить что-то в базе данных, отправить покупателю отчет о состоянии заказа и т.д.) Если задач долго нет, это еще не значит, что партнёр "в дауне" - возможно, на сайте уже неделю как не было покупателей, или, к примеру, менеджеры в офисе еще не закончили праздновать День Солидарности Трудящихся.

Учётная система и web-магазин не имеют постоянной связи, а просто обмениваются друг с другом задачами в заранее определенные расписанием моменты. Задачи записываются в файл в неком формате, который понятен обеим сторонам. Для этих целей вполне подойдет, к примеру, язык XML - записать и прочитать XML-файл можно практически в любой среде. XML-документ, в отличие от многих других форматов, вполне пригоден для чтения глазами и его очень просто преобразовать в HTML. Для ускорения процесса обмена данными файл заданий можно сжимать, а для пущей безопасности - шифровать. Собственно формат может быть любым. Скажем, фрагмент файла заданий мог бы выглядеть вот так:

task
action_uid="C25CE438-FC3C-4EA9-9DA5-03FD10993572"
action="create_new_item"
item_code="521H"
item_name="Miller"
item_type="beer"
item_price="0.79"
need_report="yes"


В переводе на русский это значит: "слушай, товарищ web-магазин, добавь в свою базу данных пиво Miller, код 521H, по 79 центов за банку, а как добавишь - свистни мне". Web-магазин, получив такую задачу, дополняет свою номенклатуру новой позицией - а уж как он это сделает технически, учётную систему не волнует.

Зачем "свистеть" обратно? Разумеется, можно обойтись и без этого, но хорошо бы всё-таки предусмотреть в системе механизм отчётности между отдельными частями: если один из партнёров получил задачу, но не отчитался об исполнении за какое-то разумное время, то задачу можно выслать ещё раз (да еще и администратора неплохо бы оповестить). Ответный "свист" мог бы выглядеть так:

report
action_uid="C25CE438-FC3C-4EA9-9DA5-03FD10993572"
status="complete"
timestamp="2002-09-13 15:41"


Можно сделать отчёт о выполнении задач опциональным - скажем, только в случае возникновения ошибок, или для задач определённого класса и т.п. Вполне логично будет поместить отчёты о выполненных задачах в файл со своими собственными задачами - тогда файл будет состоять из двух секций, "задачи" и "отчёты".