На Хабре было несколько статей об интеграции Сайта с 1С. Я предлагаю два новых варианта.
В платформе 1С: Предприятие 8.х реализован механизм обмена данными с любой другой 1С. Объекты базы данных 1С: Предприятие средствами платформы экспортируются в xml-формат. Для регистрации изменений объектов обмена используется объект конфигурации “План обмена”. В Плане обмена содержится информация об узлах, между которыми производится обмен. Для каждого узла обмена ведется нумерация сообщений обмена.
Чтобы гарантировать доставку сообщений до Сайта, 1С повторяет отправку данных до тех пор, пока не получит подтверждения от Сайта в виде номера принятого сообщения. Только после этого обмен считается успешно завершенным.
В обмене всегда участвуют 2 файла. Условно называем:
1)Message_Site_1C.xml — файл отправленный из Сайта в 1С.
2) Message_1C_Site.xml — файл отправленный из 1С на Сайт.
Их структуры аналогичные. Посмотрим пример этих файлов. Комментирую только интересные нам теги.
Как только на Сайте любой обменивающийся объект создается или изменяется, его фиксируем в некой таблице регистрации с соответствующим номером текущего отправленного сообщения (файл Message_Site_1C.xml). В нашем примере 73086. Получив файл Message_1C_Site.xml из 1С, мы извлекаем оттуда номер последнего сообщения, полученного с Сайта. В нашем примере 73082. Далее проверяем. Если номер нашего текущего отправленного сообщения (73086) больше номера последнего полученного сообщения, зарегистрированного в 1С (73082), значит все объекты в сообщениях с номерами до 73082 уже были получены. Удаляем их из очереди для отправки. А объекты с номерами сообщения больше 72083 заново отправим в следующих сообщениях пока не получим ответ от 1С.
Со стороны 1С происходит аналогичный процесс.
Недостатки данного подхода:
Стандартный обмен 1С не уведомляет Cайт об ошибках в процессе обработки файлов, что не позволяет Сайту отправить необработанные объекты в 1С повторно.
Например, отправили в 1С 15 заказов в сообщении № 200. Сообщение было зарегистрировано в 1С как успешно полученное. Из 15 заказов только 12 успешно обработалось, а 3 неудачных просто пропадают. Также нет истории обмена, приходится копить огромный архив XML файлов. В случае разбора ошибок очень тяжело найти нужную информацию.
Негибкость кодов. Каждый раз, когда РНР программист или 1С программист вносит малейшее изменение (например, добавляет новый тэг), приходится писать вручную новый обработчик тэга, потом писать запросы в БД. Это крайне тяжёлая и скучная работа, а также сильная привязка к cron на стороне Cайта. Приходится постоянно проверять FTP сервер на наличие файлов обмена.
Обмен основан на использовании XDTO-пакета. XDTO-пакет является шаблоном, который описывает структуру объектов обмена. Для того, чтобы добавить в обмен новый объект конфигурации 1С, достаточно создать объект с таким же именем в XDTO-схеме и добавить ему свойства, идентичные реквизитам объекта 1С. Регистрация изменений объектов производится с использованием регистра сведений. Это позволяет осуществлять обмен не на уровне сообщений, как в стандартном обмене, а на уровне отдельных объектов обмена. В процессе экспорта объекты 1С преобразуются в XDTO-объекты, выгружаются в xml-формат и отправляются на Сайт.
Схема взаимодействия Сайта и 1С
Для удобства на строне Сайта создан XML-Mapper:
XML-Mapper предоставляет разработчикам возможность описать шлюз и минимально его программировать. Мы его реализовали с помощью ini файла. Ini файл играет роль маппера данных. Он устанавливает соответствие между логическими объектами на Сайте с их XML шаблонами для обмена с 1С. В ini файле так же описываются действия импорта/экспорта данных для каждого тэга.
Простой пример ini маппера.
[Контрагенты:mapper]
; Общее описание объекта
object.name = Контрагенты; Название объекта в XML шаблоне
object.class = buyerDomain; Соответствующий класс на сайте
object.id = Ссылка; Тэг где идентификационное поле (GUID)
object.domain = 1; Флаг является ли объект логической сущностью на Сайте
; Детализация маппера
object.tag[] = ИД; Название тэга XML
object.imp[] = setTransactionStatusId; Действие импорт
object.exp[] = getTransactionStatusId; Действие экспорт
object.guid[] = 0; Является ли данный тэг GUID
object.tag[] = ВремяИзменения
object.imp[] =
object.exp[] = getCurrentTime
object.guid[] = 0
object.tag[] = Ссылка
object.imp[] = setGuid
object.exp[] = getGuid
object.guid[] = 1
object.tag[] = ПометкаУдаления
object.imp[] = disable
object.exp[] = getEnable
object.guid[] = 0
object.tag[] = Наименование
object.imp[] = setName
object.exp[] = getName
object.guid[] = 0
object.tag[] = ИНН
object.imp[] = setINN
object.exp[] = getINN
object.guid[] = 0
object.tag[] = КПП
object.imp[] = setKPP
object.exp[] = getKPP
object.guid[] = 0
object.tag[] = ГоловнойКонтрагент
object.imp[] = setHolding
object.exp[] = getHolding
object.guid[] = 1
P.S
Самописный обмен уже показал свою эффективность на 5 проектах. Удобно настраивать, не надо много и нудно программировать в 1С.
1. Интеграция с Сайтом на базе стандартного обмена между двумя 1С.
В платформе 1С: Предприятие 8.х реализован механизм обмена данными с любой другой 1С. Объекты базы данных 1С: Предприятие средствами платформы экспортируются в xml-формат. Для регистрации изменений объектов обмена используется объект конфигурации “План обмена”. В Плане обмена содержится информация об узлах, между которыми производится обмен. Для каждого узла обмена ведется нумерация сообщений обмена.
Чтобы гарантировать доставку сообщений до Сайта, 1С повторяет отправку данных до тех пор, пока не получит подтверждения от Сайта в виде номера принятого сообщения. Только после этого обмен считается успешно завершенным.
В обмене всегда участвуют 2 файла. Условно называем:
1)Message_Site_1C.xml — файл отправленный из Сайта в 1С.
2) Message_1C_Site.xml — файл отправленный из 1С на Сайт.
Их структуры аналогичные. Посмотрим пример этих файлов. Комментирую только интересные нам теги.
Как только на Сайте любой обменивающийся объект создается или изменяется, его фиксируем в некой таблице регистрации с соответствующим номером текущего отправленного сообщения (файл Message_Site_1C.xml). В нашем примере 73086. Получив файл Message_1C_Site.xml из 1С, мы извлекаем оттуда номер последнего сообщения, полученного с Сайта. В нашем примере 73082. Далее проверяем. Если номер нашего текущего отправленного сообщения (73086) больше номера последнего полученного сообщения, зарегистрированного в 1С (73082), значит все объекты в сообщениях с номерами до 73082 уже были получены. Удаляем их из очереди для отправки. А объекты с номерами сообщения больше 72083 заново отправим в следующих сообщениях пока не получим ответ от 1С.
Со стороны 1С происходит аналогичный процесс.
Недостатки данного подхода:
Стандартный обмен 1С не уведомляет Cайт об ошибках в процессе обработки файлов, что не позволяет Сайту отправить необработанные объекты в 1С повторно.
Например, отправили в 1С 15 заказов в сообщении № 200. Сообщение было зарегистрировано в 1С как успешно полученное. Из 15 заказов только 12 успешно обработалось, а 3 неудачных просто пропадают. Также нет истории обмена, приходится копить огромный архив XML файлов. В случае разбора ошибок очень тяжело найти нужную информацию.
Негибкость кодов. Каждый раз, когда РНР программист или 1С программист вносит малейшее изменение (например, добавляет новый тэг), приходится писать вручную новый обработчик тэга, потом писать запросы в БД. Это крайне тяжёлая и скучная работа, а также сильная привязка к cron на стороне Cайта. Приходится постоянно проверять FTP сервер на наличие файлов обмена.
2. Разработка обмена в 1С настраиваемого без программирования.
Обмен основан на использовании XDTO-пакета. XDTO-пакет является шаблоном, который описывает структуру объектов обмена. Для того, чтобы добавить в обмен новый объект конфигурации 1С, достаточно создать объект с таким же именем в XDTO-схеме и добавить ему свойства, идентичные реквизитам объекта 1С. Регистрация изменений объектов производится с использованием регистра сведений. Это позволяет осуществлять обмен не на уровне сообщений, как в стандартном обмене, а на уровне отдельных объектов обмена. В процессе экспорта объекты 1С преобразуются в XDTO-объекты, выгружаются в xml-формат и отправляются на Сайт.
Схема взаимодействия Сайта и 1С
Для удобства на строне Сайта создан XML-Mapper:
XML-Mapper предоставляет разработчикам возможность описать шлюз и минимально его программировать. Мы его реализовали с помощью ini файла. Ini файл играет роль маппера данных. Он устанавливает соответствие между логическими объектами на Сайте с их XML шаблонами для обмена с 1С. В ini файле так же описываются действия импорта/экспорта данных для каждого тэга.
Простой пример ini маппера.
[Контрагенты:mapper]
; Общее описание объекта
object.name = Контрагенты; Название объекта в XML шаблоне
object.class = buyerDomain; Соответствующий класс на сайте
object.id = Ссылка; Тэг где идентификационное поле (GUID)
object.domain = 1; Флаг является ли объект логической сущностью на Сайте
; Детализация маппера
object.tag[] = ИД; Название тэга XML
object.imp[] = setTransactionStatusId; Действие импорт
object.exp[] = getTransactionStatusId; Действие экспорт
object.guid[] = 0; Является ли данный тэг GUID
object.tag[] = ВремяИзменения
object.imp[] =
object.exp[] = getCurrentTime
object.guid[] = 0
object.tag[] = Ссылка
object.imp[] = setGuid
object.exp[] = getGuid
object.guid[] = 1
object.tag[] = ПометкаУдаления
object.imp[] = disable
object.exp[] = getEnable
object.guid[] = 0
object.tag[] = Наименование
object.imp[] = setName
object.exp[] = getName
object.guid[] = 0
object.tag[] = ИНН
object.imp[] = setINN
object.exp[] = getINN
object.guid[] = 0
object.tag[] = КПП
object.imp[] = setKPP
object.exp[] = getKPP
object.guid[] = 0
object.tag[] = ГоловнойКонтрагент
object.imp[] = setHolding
object.exp[] = getHolding
object.guid[] = 1
P.S
Самописный обмен уже показал свою эффективность на 5 проектах. Удобно настраивать, не надо много и нудно программировать в 1С.
