1С:Интеграция КОРП
Программный продукт «1С:Интеграция КОРП» применяется для обмена данными между различными системами в виде канонической модели данных.
Реализация межсистемного взаимодействия осуществляется с помощью механизмов, поддерживаемых платформой «1С:Предприятие 8.3».
Продукт «1С:Интеграция КОРП» не является самостоятельным, для работы необходимо наличие установленной платформы «1С:Предприятие 8.3» версии не ниже 8.3.12. Для развертывания программного комплекса необходима установка «1С:Предприятия» в режиме клиент-сервер.
Продукт не является защищенным. Реализован принцип максимальной открытости кода для обеспечения возможности адаптации продукта под нужды конечных пользователей.
Возможности
Программный комплекс «1С:Интеграция КОРП» включает компоненты:
В подсистеме «Центральная база интеграции» реализованы:
В подсистеме «Универсальный коннектор 1С» реализованы:
Во второй версии продукта реализован ряд доработок и улучшений на основании опыта внедрений системы у наших заказчиков. Рассказываем подробнее о нововведениях
Мониторинг состояния транспортного слоя
В центральной базе интеграции теперь выводится информация о состоянии серверов транспортного слоя и количестве сообщений в очередях. Для серверов выводится информация о загрузке ЦП и аптайм работы сервера. Стало удобнее отслеживать основные метрики работы транспортного слоя и узнавать, не переполнена ли какая-то из очередей.
Переотправка и повторная загрузка пакетов
Реализовали удобный функционал по переотправке пакетов, в котором можно отправить как определенные пакеты (по идентификаторам сообщений), так и все пакеты за определенный период для выбранного получателя.
Существует возможность повторной загрузки ранее полученных пакетов, в том числе, сразу в форме элемента справочника «События» (нет необходимости ручного поиска нужного для повтора пакета в журнале).
Замеры времени и оценка производительности
В универсальный коннектор добавлены замеры времени суммарной длительности обращений к транспортному слою. Замеры считаются в рамках работы одного потока и записываются один раз в конце работы потока при его успешном завершении. В качестве веса замера используется количество обработанных пакетов или иных итераций обработки.
Также был проведен рефакторинг замеров по всем регламентам, например, были добавлены замеры длительности прикладной обработки пакетов и проверки конфигурации на изменение.
Активный режим работы
Повышение юзабилити при работе с форматами и правилами
Реализован импорт объектов формата из объектов метаданных с заполнением описания объектов формата по синонимам реквизитов, а также импорт различий из обработки сравнения форматов, а также автогенерация кода правил для регистров сведений.
Подсветка кода, форматов и правил
Стала доступна подсветка xml и xsd документов (например, в журналах отправки и получения). В универсальном коннекторе 1С подсветка поддерживается и для версий платформы ниже, чем 8.3.14
Также для удобной работы и написания кода правил конвертации реализовали подсветку кода встроенного языка 1С, это помогает программистам быстрее ориентироваться в коде и писать его путем автоматического дополнения.
Доработана обработка по управлению версиями формата и конвертаций, которая упрощает настройку за счет подсветки только несопоставленных форматов и правил.
Редактор маршрутов
Реализовали настройку маршрутов для транспортного слоя в визуальном виде без программирования (по принципам low code). Можно реализовать любой произвольный маршрут (для которого есть нужные библиотеки в транспортном слое).
Отложенное выполнение заданий и их контроль
Теперь в универсальном коннекторе задания интеграционной шины (например, по выгрузке данных) можно либо приостановить, либо запланировать к отправке не ранее указанной даты, не меняя приоритет.
В том числе, в случае ошибки при выполнении задания (например, при переполненности очереди получателя), теперь задания откладываются для выполнения на будущее. Информация о приостановленных по причине ошибки заданиях выводится на специальной странице Панели Администратора (нет необходимости ручного контроля и перехода в отдельную форму), из которой их можно выборочно или все сразу повторить.
Стоп-лист на загрузку отдельных объектов метаданных
В системе с внедренным универсальным коннектором администратор теперь может задать в разрезе метаданных признак блокировки загрузки этих объектов при любых обменах от любых отправителей (это может потребоваться, например, если база является эталонной системой для каких-то определенных объектов).
Уведомления по ответственному и переход в журналы
Также теперь доступен быстрый переход из События к соответствующим записям в журнал отправки или получения (определяется автоматически).
Настройка доступности систем
Полностью переработаны инструменты определения прав на то, какая система каким системам может отправлять сообщения. Реализован специальный АРМ, который в табличном виде отображает и позволяет изменить (с подсветкой внесенных изменений) настроенные права для всех систем, которые доступны текущему пользователю. Теперь только администратор каждой отдельной системы может явно указать, какие системы могут ему передавать пакеты.
Способы интеграции с 1С
Какие важнейшие требования предъявляются к бизнес-приложениям? Одними из самых главных являются следующие задачи:
Интеграционные задачи
Интеграционные задачи могут быть разными. Для решения одних достаточно простого интерактивного обмена данными – например, для передачи в банк списка сотрудников для оформления зарплатных пластиковых карт. Для более сложных задач может быть необходим полностью автоматизированный обмен данными, возможно, с обращением к бизнес-логике внешней системы. Есть задачи, носящие специализированный характер, вроде интеграции с внешним оборудованием (например, торговым оборудованием, мобильными сканерами и т.д.) или с унаследованными или узкоспециализированными системами (например, с системами распознавания RFID-меток). Крайне важно для каждой задачи выбрать наиболее подходящий механизм интеграции.
Возможности интеграции с 1С
Существуют различные подходы к реализации интеграции с приложениями 1С, какой из них выбрать – зависит от требований задачи.
Механизмы интеграции в платформе 1С:Предприятие
Импорт/экспорт файлов
Предположим, перед нами стоит задача двунаправленного обмена данными между приложением 1С и произвольным приложением. Например, нам нужно синхронизировать список товаров (справочник Номенклатура) между приложением 1С и произвольным приложением.
Для решения такой задачи можно написать расширение, которое выгружает справочник Номенклатура в файл определенного формата (текстовый, XML, JSON, …) и умеет считывать этот формат.
В платформе реализован механизм сериализации прикладных объектов в XML как напрямую, через методы глобального контекста ЗаписатьXML/ЧтениеXML, так и с помощью вспомогательного объекта XDTO (XML Data Transfer Objects).
Любой объект в системе 1С:Предприятие может быть сериализован в XML представление и наоборот.
Эта функция вернет представление объекта в виде XML:
так будет выглядеть экспорт справочника Номенклатура в XML при помощи XDTO:
Путем несложной переделки кода экспортируем справочник в JSON. Товары будут записаны в массив; для разнообразия приведем англоязычный вариант синтаксиса:
Далее останется только передать данные конечному потребителю. Платформа 1С:Предприятие поддерживает основные интернет-протоколы HTTP, FTP, POP3, SMTP, IMAP, включая их безопасные версии. Также для передачи данных можно использовать HTTP и/или Web-сервисы.
HTTP- и веб-сервисы
Приложения 1С могут реализовывать свои HTTP- и веб-сервисы, а также вызывать HTTP- и веб-сервисы, реализованные сторонними приложениями.
REST интерфейс и протокол OData
Так, URL вида http:// / /odata/standard.odata/Catalog_Номенклатура вернет нам содержимое каталога Номенклатура в формате XML — коллекцию элементов entry (заголовок сообщения пропущен для краткости):
Прибавляя к URL-у строку «?$format=application/json», получим содержимое каталога Номенклатура в формате JSON (URL вида http:// / /odata/standard.odata/Catalog_Номенклатура?$format=application/json ):
Внешние источники данных
В некоторых случаях обмен данными через внешние источники данных может оказаться оптимальным решением. Внешние источники данных – это прикладной объект конфигурации 1С, позволяющий взаимодействовать с любой ODBC-совместимой базой данных как на чтение, так и на запись. Внешние источники данных доступны как в Windows, так и на Linux.
Механизм обмена данными
Механизм обмена данными предназначен как для создания территориально распределенных систем на основе 1С:Предприятия, так и для организации обмена данными с другими информационными системами, не основанными на 1С:Предприятии.
Этот механизм активно используется во внедрениях 1С, и спектр задач, решаемых с его помощью, весьма широк. Это и обмен данными между приложениями 1С, установленными в филиалах организации, и обмен между приложением 1С и сайтом интернет-магазина, и обмен данными между серверным приложением 1С и мобильным клиентом (созданным с помощью мобильной платформы 1С:Предприятия), и многое другое.
Одно из ключевых понятий в механизме обмена данными – это план обмена. План обмена – это особый тип объекта прикладного платформы 1С, определяющий, в частности, состав данных, которые будут участвовать в обмене (какие именно справочники, документы, регистры и т.п.). План обмена содержит также информацию об участниках обмена (так называемых узлах обмена).
Вторая составляющая механизма обмена данными – механизм регистрации изменений. Данный механизм автоматически отслеживает в системе изменения данных, которые должны быть переданы конечным потребителям в рамках плана обмена. С помощью этого механизма платформа отслеживает изменения, произошедшие со времени последней синхронизации, и позволяет минимизировать объем данных, передаваемый в рамках очередного сеанса синхронизации.
Обмен данными происходит при помощи XML сообщений определенной структуры. Сообщение содержит данные, изменившиеся со времени последней синхронизации с узлом, и некоторую служебную информацию. Структура сообщений поддерживает нумерацию сообщений и позволяет получать подтверждения от узла-получателя о приеме сообщений. Такое подтверждение содержится в каждом сообщении, приходящем от узла-получателя, в виде номера последнего принятого сообщения. Нумерация сообщений позволяет понять платформе, какие данные уже были успешно переданы на узел-получатель, и избежать повторной передачи, передавая лишь данные, измененные со времени приема узлом-отправителем последнего сообщения с квитанцией о полученных узлом-получателем данных. При такой схеме работы обеспечивается гарантированная доставка даже при ненадежных каналах передачи и потере сообщений.
Внешние компоненты
В ряде случаев, при решении задач интеграции приходится сталкиваться со специфическими требованиями, например, протоколами взаимодействия, форматами данных, работа с которыми не предусмотрена в платформе 1С:Предприятие. Для такого круга задач в платформе предусмотрена технология внешних компонент, которая позволяет создавать динамически подключаемые модули, расширяющие функционал 1С:Предприятия.
Типичным примером задачи с подобными требованиями, может служить интеграция прикладного решения 1С с торговым оборудованием, начиная от весов и заканчивая кассовыми аппаратами и сканерами штрих-кодов. Внешние компоненты могут быть подключены как на стороне сервера 1С:Предприятия, так и на клиентской части (включая, в том числе, и веб-клиент, а также следующую версию мобильной платформы 1С:Предприятия). Технология внешних компонент предусматривает достаточно простой и понятный программный (C++) интерфейс взаимодействия компоненты с платформой 1С:Предприятие, который должен реализовать разработчик.
Возможности, открывающиеся при использовании внешних компонент, весьма широки. Можно реализовать взаимодействие по специфическому протоколу обмена данными с внешними устройствами и системами, встроить специфические алгоритмы обработки данных и форматов данных и т.п.
Устаревшие механизмы интеграции
В платформе доступны механизмы интеграции, которые не рекомендуется использовать в новых решениях; они оставлены из соображений обратной совместимости, а также на случай, если другая сторона не может работать с более современными протоколами. Один из них – работа с файлами формата DBF (поддерживается во встроенном языке с помощью объекта XBase).
Другой устаревший механизм интеграции – использование технологии COM (доступно только на платформе Windows). Платформа 1С:Предприятие предоставляет два способа интеграции для Windows, использующие технологию COM: Automation-сервер и Внешнее соединение. Они очень похожи, но одним из принципиальных отличий является то, что в случае Automation-сервера запускается полноценное клиентское приложение 1С:Предприятие 8, а в случае внешнего соединения запускается относительно небольшой внутрипроцессный COM-сервер. То есть в случае работы через Automation сервер можно задействовать функционал клиентского приложения, выполнять действия, аналогичные интерактивным действиям пользователя. При использовании внешнего соединения можно использовать только функции бизнес-логики, причем их можно выполнять как на клиентской стороне соединения, где создается внуприпроцессный COM-сервер, так и осуществлять вызов бизнес-логики на стороне сервера 1С:Предприятия.
Также технологию COM можно использовать для обращения к внешним системам из кода приложения на платформе 1С:Предприятие. В данном случае приложение 1С выступает в качестве COM-клиента. Но следует напомнить, что данные механизмы будут работать только в том случае, если сервер 1С функционирует в среде Windows.
Механизмы интеграции, реализованные в типовых конфигурациях
Формат EnterpriseData
В ряде конфигураций 1С (список ниже) на основе описанного выше платформенного механизма обмена данными реализован готовый механизм обмена данными с внешними приложениями, не требующий изменения исходного кода конфигураций (подготовка к обмену данными делается в настройках прикладных решений):
Обмен данными между приложением 1С и сторонним приложением может происходить:
Квитирование сообщений
Приложения 1С ведут учет отправленных и полученных сообщений синхронизации и ожидают того же от сторонних приложений. Это позволяет задействовать механизм нумерации сообщений, описанный выше в разделе «Механизм обмена данными».
Приложения 1С в ходе синхронизации передают только информацию об изменениях, произошедших с бизнес-сущностями со времени последней синхронизации (чтобы минимизировать объем передаваемой информации). При первой синхронизации приложение 1С выгрузит все бизнес-сущности (например, элементы справочника номенклатуры) в формате EnterpriseData в XML-файл (поскольку все они являются «новыми» для внешнего приложения). Стороннее приложение должно обработать информацию из пришедшего от 1С XML-файла и при следующем сеансе синхронизации поместить в файл, отправляемый в 1С, в специальную секцию XML, информацию, что сообщение от 1С за определенным номером успешно принято. Сообщение-квитанция является для приложения 1С сигналом, что все бизнес-сущности успешно обработаны внешним приложением и информацию о них передавать больше не нужно. Помимо квитанции XML-файл от стороннего приложения также может содержать данные для синхронизации со стороны приложения (например, документы реализации товаров и услуг).
После получения сообщения-квитанции приложение 1С помечает все изменения, переданные в предыдущем сообщении, как успешно синхронизированные. Лишь несинхронизированные изменения в бизнес-сущностях (создание новых сущностей, изменение и удаление существующих) будут отправлены во внешнее приложение при следующем сеансе синхронизации.
При передаче данных от внешнего приложения в приложение 1С картина меняется на обратную. Внешнее приложение должно заполнить секцию-квитанцию в XML файле соответствующим образом и поместить бизнес-данные для синхронизации со своей стороны в формате EnterpriseData.
Упрощенный обмен данными без квитирования
Для случаев простой интеграции, когда достаточно только передавать информацию от стороннего приложения в приложение 1С и обратной передачи данных из приложения 1С в стороннее приложение не требуется (например, интеграция онлайн-магазина, передающего информацию о продажах в «1С:Бухгалтерию»), есть упрощенный вариант работы через веб-сервис (без квитирования), не требующий настроек на стороне приложения 1С.
Специализированные интеграционные решения
Существует типовое решение «1С:Конвертация данных», которое использует механизмы платформы для конвертации и обмена данными между типовыми конфигурациями 1С, но может быть также использовано для интеграции со сторонними приложениями.
Интеграция с банковскими решениями
Стандарт «Клиент банк», разработанный специалистами 1С более 10 лет назад, фактически стал стандартом индустрии в России. Следующий шаг в этом направлении – технология DirectBank, позволяющая отправлять платежные документы в банк и получать выписки из банка непосредственно из программ системы «1С:Предприятия» нажатием одной кнопки в программе «1С»; при этом не требуется установка и запуск дополнительных программ на клиентский компьютер.
Интегрируй это: «1С» в деталях рассказала о способах интеграции со сторонним ПО
В блоге фирмы «1С» на Хабрахабр появился обзор всех – или почти всех – возможностей и инструментов, благодаря которым можно решать разнообразные интеграционные задачи.
«Интеграционные задачи могут быть разными. Для решения одних достаточно простого интерактивного обмена данными – например, для передачи в банк списка сотрудников для оформления зарплатных пластиковых карт. Для более сложных задач может быть необходим полностью автоматизированный обмен данными, возможно, с обращением к бизнес-логике внешней системы. Есть задачи, носящие специализированный характер, вроде интеграции с внешним оборудованием (например, торговым оборудованием, мобильными сканерами и т.д.) или с унаследованными или узкоспециализированными системами (например, с системами распознавания RFID-меток)», – говорится в статье на ресурсе «Хабрахабр».
Для каждой из перечисленных «1С» пытается подобрать оптимальное решение. Насколько это удается в полной мере – вопрос дискуссионный, но, как минимум, ни одна из конкурирующих фирм не может похвастаться таким многообразием инструментария.
Итак, вначале описываются основные подходы, а также их сильные и слабые стороны. Сюда относятся:
Наконец, следует характеристика отдельных способов интеграции, реализованных в той или иной конфигурации. Особняком упоминаются типовое решение «1С:Конвертация данных» и технология DirectBank, «позволяющая отправлять платежные документы в банк и получать выписки из банка непосредственно из программ системы «1С:Предприятия» нажатием одной кнопки в программе 1С».
Предлагаем участникам сообщества «Инфостарт» поделиться своими мыслями, идеями и опытом по вопросу интеграции с 1С.
Что нужно знать программисту про интеграцию сайта и 1С
Нельзя просто взять и интегрировать сайт с 1С. (с) Народное творчество.
Цель написания поста – изложить всю информацию по теме человеческим языком.
Интеграция сайта на 1С-Битрикс: Управление сайтом и 1С — неисчерпаемый источник вопросов и проблем. На сайте идей для Битрикс в соответствующем разделе 16 страниц, на форуме про это больше 23 000 сообщений. В форме обращения в техподдержку Битрикса есть даже отдельный тип заявки «Обмен с 1С».
Считается, что интеграция 1С и сайта на Битриксе должна работать из коробки. Самые простые функции действительно можно запустить за час-два. А вот на доработку обмена можно потратить и 10, и 100 часов.
Доработка обмена сайта и 1С — это уже магия уровня «эксперт», пугает даже бородатого опытного разработчика. В этой статье мы поговорим о том, как происходит обмен данными между этими двумя монстрами и как можно расширять возможности этого обмена. Статья содержит множество технических деталей обмена и будет полезна в основном программистам, которые хотят разобраться в предмете.
В данной статье будет рассмотрена общая теория обмена между двумя IT-системами и два стандартных обмена между 1С и сайтом на 1С-Битрикс: обмен товарами и обмен справочниками.
Немного теории
Интеграция — обмен информацией между двумя IT-системами. Иногда называют просто обмен. Определяется форматом данных, протоколом (стандартом) передачи данных, алгоритмом работы
Формат = как выглядят данные (например, XML, YML, JSON, CSV).
Протокол = как данные оказываются в другом месте (например, HTTP, SIP, SMTP, FTP).
Алгоритм = что при этом происходит. Представляется блок-схемой или диаграммой UML Activity.
обмен товарами между самописной учетной системой и сайтом (протокол FTP, формат CSV);
парсинг курсов валюты с сайта ЦБ РФ (протокол HTTP, формат XML);
интеграция сайта с Яндекс.Маркет (протокол HTTP, формат YML).
Процедуру обмена можно разделить на 3 части:
Экспорт данных из системы А в требуемый формат
Импорт данных требуемого формата в систему Б.
Часто весь обмен называют «импорт» («загрузка») и «экспорт» («выгрузка»). Это не ошибка, по такой формулировкой говорящий показывает, точка зрения какой системы ему ближе. То, что для 1С экспорт товаров, для Битрикса импорт. В дальнейшем тексте статьи мы не будем использовать эти понятия, чтобы не порождать двусмысленности.
Резюме
Интеграция — обмен данными между двумя системами.
Формат — как выглядят данные.
Протокол — как передаются данные.
Стандартные возможности обмена 1С и Битрикса
«Из коробки» (без доработок программиста) работают 4 типа обмена:
товары из 1С на сайт (тип «catalog»);
справочники из 1С на сайт (тип «reference»);
пользователей/контрагентов из 1С на сайт (тип «sale»);
Протокол
Все взаимодействия между 1С и Битриксом проводятся по HTTP, синхронно. Т.о. 1С подобна браузеру, она «открывает» специальную страницу, отправляет данные (методами POST и GET) и получает текстовый ответ. Есть даже способ имитировать выгрузку из 1С браузером (и мы часто используем этот трюк во время разработки и отладки). Подробнее про отладку мы рассказали в предыдущей статье «Типовые ошибки интеграции между 1С и 1С-Битрикс».
В терминах сетевых взаимодействий 1С — клиент, а сайт — сервер. Обращения всегда инициируются на стороне 1С. В 1С есть настройки адреса сайта, сайт про 1С не знает ничего.
Протокол синхронный. 1С отправляет следующий запрос на сайт только после получения ответа на предыдущий (или получения ошибки таймаута).
Формат
Данные передаются в двух форматах.
Первый формат — текстовый для ответов сайта на запросы из 1С. Сайт выводит в первой строке ответа «success», если завершил некую процедуру, «progress», если продолжает ее выполнять и «error» или «failure», если была ошибка. В последующих строках могут быть дополнительные данные (зависит от каждого конкретного запроса).
Алгоритм
Подготовка к обмену
Выше мы уже сказали, что протокол обмена — синхронный HTTP. Все перечисленные типы обмена подразумевают выполнение нескольких запросов (шагов обмена) друг за другом. Первые два шага одинаковы для любого типа обмена, различия начинаются дальше
Как сделать интеграцию (обмен) с интернет-магазином? Пошаговый план действий (Часть 1)
Этап 0: Выбор модели обмена
Нам надо понять, какими объектами мы будем обмениваться с сайтом. Наиболее популярные варианты удобно представить в виде таблицы:
Выгрузка статусов, комментариев, трек-номера заказа
Выгрузка остатков и цен
Выгрузка всех корректировок по заказу
Эта таблица наглядно показывает какими объектами нам предстоит обмениваться, а так же при общении с Заказчиком / Работодателем позволяет максимально быстро прийти к нужной модели обмена. Дело в том, что часто приходилось сталкиваться с заказчиками, которые изначально не совсем понимают что конкретно они хотят получить от обмена. Благодаря этой таблице Вам будет проще понять друг друга.
«Базовый» — это по сути самый простой и самый популярный вариант обмена. При таком варианте обмена нам будет доступен самый широкий выбор способов получения данных
«Расширенный №1» и «Расширенный №2» — часто называют «двухсторонним» обменом с сайтом. И в отличает от «Базового» здесь мы уже имеем некоторые ограничения в доступных методах обмена. На моей практике далеко не у всех сайтов есть API (или какой-ли метод обмена), позволяющий передавать все необходимые данные «культурным» способом
Где же выгрузка каталога? Практика показывает, что чаще всего каталог на сайте формируется альтернативными способами. На это есть множество причин, но об этом речь пойдет в отдельной статье.
Этап 1: Выбор способа обмена данными
Поняв что нам нужно загружать и передавать на сайт, мы можем определяться со способами обмена. Наиболее популярные варианты обмена:
На примере Битрикс это выглядит так:
Нам нужно авторизоваться на сайте
Далее сделать запрос к сайту https://АдресСайта.РФ/bitrix/admin/1c_exchange.php?type=sale&mode=query
В ответ мы получим XML со всеми заказами, который легко можно загрузить в 1с
Подобный формат обмена имеет огромное количество движков, например тот же Insales, NetHouse, CS-Cart, NetCat, Diafan.CMS и т.д.
Аббревиатура API расшифровывается как «Application Programming Interface» (интерфейс программирования приложений, программный интерфейс приложения).
Это тоже отличный способ обмена, с которым работать одно удовольствие. Яркими представителями подобных обменов являются: INSALES, Storeland, AdvantShop.
Суть обмена заключается в том, что у сайта есть программный интерфейс для взаимодействия с внешними системами, который содержит набор команд таких как:
Создания/Удаления товара в каталоге
Как правило сайт «отдает» и «получает» от нас данные в формате JSON или XML.
Это способ обмена, имеющий самые широкие возможности для чтения и записи данных. Однако для чтения и записи данных извне вам понадобиться сделать некоторые настройки на стороне хостинга, где установлен сайт. Пример настройки на примере хостинга Beget:
Хочу обратить внимание, что я поставил доступ для чтения и записи извне с любого IP. Безусловно это не очень безопасно. Когда загрузчик будет переведен в «боевой режим», нужно будет ограничить IP адреса, с которых будет идти чтение и запись данных. Однако для тестирования — это идеальный вариант. Ведь у программиста на рабочем ПК часто нет «статического IP», что может усложнить разработку. Из всех протестированных мной хостинг-провайдеров, beget оказался самым удобным для тестирование/разработки загрузчика, работающего по данной модели обмена.
Обычно при обмене подобным способом я предпочитаю не ждать пока клиент откроет доступ (поверьте это всегда не быстро), а сделать копию базы и уже начать с ней работать (в идеале иметь и копию сайта).
Некоторые хостинг провайдеры не могут дать прямой доступ извне на чтение/запись (например reg.ru), он дают подобный доступ только через ssl, что немного усложняет разработку.
И так, мы закончили «культурные» методы обмена и настало время поговорить про «экзотику».
Бывает так, что у сайта нет красивого способа получения или отправки данных (или данных и возможностей катастрофически не хватает), тогда приходится изобретать велосипед. Я много раз встречался с подобным, особенно на момент когда «движок» сайта находился в процессе развития (стартапа). Пример:
Мегагрупп — загрузка заказов не позволяла забирать все необходимые данные, выгрузка данных о статусе, комментарии отсутствовала
TIU.RU – заказы можно было загрузить по API, однако для выгрузки статусов пришлом делать парсинг и «имитацию» ручного изменения статуса для полной автоматизации выгрузки данных
Alltrades – не было корректной загрузки заказов
Прогресс не стоит на месте, возможно сейчас осталось очень мало движков, которые требуют подобных «сложный» подход для обмена.
Главная проблема подобного обмена в его ненадежности, так как малейшая корректировка верстки сайта (со стороны админки) приводит к тому, что обмен перестанет работать. Ведь по сути для получение/отправки данных мы имитируем заход на сайт (в его админ. панель) и начинаем «программно», ориентируясь на «верстку» читать данные. Если данные располагаются на нескольких страницах — делаем перелистывание страниц. Перед внедрение подобного способа обмена, обязательно нужно предупредить Вашего заказчика о всех возможных последствиях. Естественно ни о какой гарантии не может быть речи. Изменения на сайте могут произойти в любой момент и Заказчик должен понимать, что ему придется оперативно устранять проблему. Поэтому заключайте сразу договор на ТП:)
Это способ гораздо надежнее чем предыдущий, однако с его помощью можно только загружать данные. Практика показывает, что приятнее всего работать с почтовыми ящиками на yandex. С ними все легко и предсказуемо.
Данные удобнее всего получать по протоколу IMAP. Он позволяет идентифицировать «не прочитанные» письма. Выгоднее всего для подобного обмена завести отдельную почту.
Как идентифицировать заказы полученные по электронной почте? Чаще всего уникальный номер заказа будет записан в теме письма после символа «№» или «#».
Когда приходится прибегать к подобным обменам? На моей практики подобные обмены встречались по загрузке данных из:
Скрипты для сайтов типа «купить в 1 клик»
«Самописные сайты» без базы данных (да да и такое тоже встречалось на моем пути)
Этап 2: Идентификация
Клиенты:
Практика показала, что самый лучший вариант идентификации физ. лиц — это Телефон, потом e-mail. При этом телефон для поиска нужно привести в нужный формат (убрать пробелы, доп. символы и разделители, убрать +7 и 8).
ФИО и адрес не являются уникальными идентификаторами, есть огромное количество людей, даже в одного городе с одинаковым ФИО.
Юр. лицо правильнее всего искать по ИНН.
При разработке загрузчика, я всегда предусматриваю возможность настройки полей для идентификации. Ведь всегда бывают исключения.
Товары:
На мой взгляд самый надежный вариант — ИД товара на сайта. Однако не всегда этот вариант доступен. Второй по популярности вариант — это артикул. Но с ним не все так однозначно. Далеко не всегда он уникален. Часто встречаются интернет-магазины, где с одним артикулом может быть множество товаров, с разными характеристиками (например товары с разными цветами имеют один артикул).
Ну если ни первый ни второй вариант нам не подошел, приходится использовать наименование товара. Ну это как вы понимаете абсолютно не надежно.
Заказы:
Для идентификации заказа конечно же нужно использовать номер заказа на сайте. Естественно нужно учесть, что если обмен будет с нескольким сайтами, нам понадобиться добавить Префикс к этому номеру (или иметь в базе дополнительный реквизит «Сайт», чтобы делать поиск заказа в базе в разрезе конкретного сайта).
Этап 3. Синхронизация статусов
Тема статусов очень объемная. Как правило главной сложностью здесь является то, что состав статусов на сайте и в 1С отличается.
Для решения это задачи можно использовать «таблицу соответствия» или привести статусы «к общему знаменателю». Как правило клиенты выбирают первый вариант.
Еще одним решением данной проблемы может быть добавление нового реквизита в 1С «статус на сайте».
Этап 4. Обновление Цен и Остатков
Для выгрузки Цен и Остатков на сайт, на стороне 1С уже должен быть загружен каталог с товарами, содержащий уникальный идентификатор, по которому Вы будете находить товар на сайте.
Как правило данный этап не содержит каких-либо подводных камней. Главное здесь определиться с частотой обмена для будущего фонового задания.
Этап 5. Регламентное задание
Ну и завершающая стадия разработки, после того, как вы закончили тестирование — перевод обработки в работу в «фоновом режиме» по расписанию. Пример настройки обработки (для выполнения по расписанию)
Ну а сама обработка для запуска в ручном режим выглядит так:
По сути мы должны сделать так, чтобы Процедура «ЗагрузитьЗаказы», которую при тестировании запускали простым кликом по одноименной кнопке стала доступна для выполнения в фоновом режиме по расписанию. Данный задача легко решается с помощью БСП, я сделаю отдельную статью с примером подобной обработки. После выполнения фонового задания в журнале регистрации можно увидеть подробности работы обработки:
Часто задаваемые вопросы:
1) Почему бы не писать данные сразу в 1С?
Ответ: На мой взгляд есть ряд причин, почему подобная схема обмена является менее популярной чем перечисленные выше варианты:
Бюджет — как правило при заказе обмена с сайтом, у клиента есть определенный бюджет, в который требуется уложится. Более того, если обмен делает человек или организация, делающее нечто подобное не один раз — сделать подобный обмен можно в четкие сроки и в достаточно скромные бюджеты
Доступность — зачастую у 1С программиста просто нет доступа к сайту, для того, чтобы вносить корректировки в механизм формирования заказа (или за работу сайта уже отвечает какая-то организация). Более того, если это SaaS решение (insales, Мегагрупп, Storeland) — это просто невозможно
Надежность — тут конечно спорный вопрос. Но база хостинга находится в Дата Центре, за ее работой ведется наблюдение и риск отказа хоть и есть, но он значительно ниже чем база на Вашем сервере. Просто представьте что будет, если клиент будет оформлять заказа и в момент записи данных произойдет ошибка или данные по какой-то причине не запишутся?
2) Как часто надо загружать заказы, Какая периодичность выгрузки остатков, и.т.д.
Ответ: На этот вопрос нет однозначного ответа. Все во многом зависит от специфики работы и ресурсов, которые Вам предоставляются. Так например если раз в 5 секунд обращаться к серверу за заказами, вероятно это не очень понравится многим хостинг провайдерам и Вас могут забанить (если речь идет про коннект к базе MYSQL).