Интеграция
Система «1С:Предприятие 8» является открытой системой. Она предоставляет возможность для интеграции практически с любыми внешними программами и оборудованием на основе общепризнанных открытых стандартов и протоколов передачи данных.
С помощью средств платформы «1С:Предприятие 8» можно организовать обмен файлами различных форматов, осуществлять доступ ко всем объектам системы из внешних приложений, поддерживать различные протоколы обмена и стандарты взаимодействия с другими подсистемами (XML, JSON и т. п.), работать с Интернетом и электронной почтой.
Платформа «1С:Предприятие 8» поддерживает в прикладных решениях возможность создания web- и HTTP-сервисов и работу с внешними web- и HTTP-сервисами. Поддерживается доступ внешних систем к данным приложений 1С по протоколу OData.
Решения на платформе «1С:Предприятие 8» могут интегрироваться с различным оборудованием, в том числе торговым и складским (терминалы сбора данных, терминалы обслуживания пластиковых карт и т. п.). Интеграция с популярным торговым и промышленным оборудованием доступна во многих типовых решениях «из коробки».
Механизм распределенных информационных баз позволяет быстро создавать территориально распределенные системы на платформе «1С:Предприятие 8».
Универсальный механизм обмена данными позволяет организовать взаимодействие с различными информационными системами, в том числе реализованными не на платформе «1С:Предприятие».
Механизмы интеграции
Конфигурация «1С:Документооборот» редакции КОРП содержит несколько встроенных планов обмена с другими типовыми конфигурациями на платформе «1С:Предприятие».
Редакции ПРОФ и ДГУ не содержат таких планов обмена. Тем не менее, все редакции поддерживают обмен данными с помощью встроенной обработки УниверсальныйОбменДаннымиXML , использующей внешние правила обмена, загружаемые из файла. Собственные планы обмена можно добавить в любую из редакций.
Встроенные планы обмена предназначены для автоматической синхронизации данных в ходе совместного использования разных прикладных решений, но могут использоваться и для первоначального наполнения информационной базы.
Внешние правила обмена, поставляемые в составе дистрибутива, предназначены скорее для первоначального наполнения информационной базы, но могут использоваться и для последующей синхронизации данных. В последнем случае обмен нужно будет запускать регулярно вручную.
Встроенные планы обмена используют подсистему Обмен данными «Библиотеки стандартных подсистем» (далее БСП) редакции 2. Это значит, что в составе каждого плана обмена есть макет с правилами регистрации, а также макеты правил обмена и правил обмена конфигурации-корреспондента:
- Правила регистрации используются в «1С:Документообороте» для определения необходимости регистрации записываемого объекта к выгрузке в конфигурацию-корреспондент.
- Типовые правила регистрации тривиальны (содержат только перечень регистрируемых объектов без дополнительных условий).
- Автоматическая регистрация изменений в планах обмена выключена, для регистрации используется стандартная механика БСП, анализирующая изменения в выгружаемых полях перед регистрацией.
При необходимости комплект правил может быть загружен из файла. Как правило, это делают:
- после обновления конфигурации-корреспондента. В этом случае свежий комплект правил находится в составе дистрибутива обновления, в папке «Синхронизация данных»;
- во время отладки правил обмена, разрабатываемых на основе типовых правил, если они требуют доработки на конкретном внедрении.
После отладки доработанных правил обмена рекомендуется включить их в состав конфигурации, сняв с поддержки макеты, чтобы:
- получить возможность сравнивать доработанные правила с типовыми при обновлении конфигурации;
- избежать проблем, связанных с проверкой правил при обновлении информационной базы после изменения структуры метаданных.
Обратите внимание:
Правила, загруженные из файла и переставшие соответствовать новой структуре метаданных, не дадут довести до конца штатное обновление информационной базы.Правила обмена разрабатываются с помощью конфигурации «Конвертация данных» редакции 2.1. Конфигурация бесплатна и доступна по линии ИТС. Рекомендуется использовать типовые правила как основу для разработки, сохранив их в файлы и загрузив в информационную базу «Конвертации данных».
«1С:Документооборот» не поддерживает обмен данными в формате EnterpriseData. Соответственно, для разработки правил обмена не следует использовать конфигурацию «Конвертация данных» редакции 3.
Расширение плана обмена
При включении новых объектов в существующий план обмена следует:
- Включить эти объекты в состав плана обмена, запретив автоматическую регистрацию изменений.
- Включить эти объекты в состав источников соответствующих подписок на события.
- Для регистров подписка будет называться ОбменДанными<Краткое имя плана обмена>ПередЗаписьюРегистра . Возможно, в обработчик подписки потребуется внести дополнительные условия, если он не рассчитан на появление нового регистра.
- Для ссылочных объектов будет две подписки: ОбменДанными<Краткое имя плана обмена>ПередЗаписьюРегистра и ОбменДанными<Краткое имя плана обмена>ПередУдалением . Как правило, обработчики этих событий не нуждаются в доработке, поскольку передают управление стандартным процедурам БСП.
- Если регистрация не требует дополнительных условий, больше ничего делать не нужно. Если нужно регистрировать документы при изменении их состояния, например, выгружая только согласованные документы, следует внести доработки в модуль набора записей регистра сведений ТекущиеСостоянияДокументов по аналогии с уже имеющимся там кодом для обмена с конфигурациями «1С:Бухгалтерия предприятия» и «1С:Управление холдингом». В последнем случае следует внести проверку на состояние также и в обработчик ПередВыгрузкой правила выгрузки данных с тем, чтобы избежать выгрузки документов, чье состояние изменилось уже после регистрации в плане обмена, либо предусмотреть передачу пометки на удаление в конфигурацию-корреспондент.
- С помощью конфигурации «Конвертация данных» создать для этих объектов соответствующие правила выгрузки данных и правила конвертации объектов.
Добавление плана обмена
При разработке собственных планов обмена следует:
- Создать новый план обмена на стороне обеих конфигураций. Имя плана обмена должно быть одинаковым в обеих конфигурациях. Состав обязательных процедур модуля менеджера плана обмена приведен в документации к подсистеме Обмен данными «Библиотеки стандартных подсистем» соответствующей версии.
- Включить в состав планов обмена объекты, участвующие в обмене, а также регистр сведений СоответствиеОбъектовИнформационныхБаз , запретив авторегистрацию изменений. Использование собственного механизма регистрации БСП позволит избежать выгрузки объектов, изменившихся только в части не участвующих в обмене реквизитов.
- Создать подписки на события, аналогичные описанным выше, и обработчики для них. Лучше создать для этого отдельный общий модуль, не снимая с поддержки общий модуль ОбменДаннымиСобытияДокументооборот .
- Включить новый план обмена в тип параметра общих команд подсистемы Обмен данными . Проще всего найти нужные команды, выполнив в Конфигураторе поиск ссылок на типовой план обмена.
- Включить новый план обмена в код процедуры ПолучитьПланыОбмена общего модуля ОбменДаннымиПереопределяемый .
- При необходимости создать формы настройки плана обмена (см. документацию к «Библиотеке стандартных подсистем», а также примеры в планах обмена с конфигурациями «1С:Бухгалтерия» предприятия и «1С:Управление производственным предприятием»).
- Сохранить описания обновленных конфигураций в файлы с помощью обработки MD8<NNN>Exp.epf , входящей в состав дистрибутива конфигурации «Конвертация данных».
- Загрузить описания конфигураций в информационную базу «Конвертации данных».
- Разработать два набора правил обмена и два набора правил регистрации для каждой из сторон обмена.
- Добавить оба набора правил обмена и по одному набору правил регистрации в каждую конфигурацию в качестве макетов плана обмена.
- Настроить синхронизацию данных и отладить ее.
Обратите внимание:
Правила обмена, зачитанные из макетов в составе конфигурации, кэшируются в регистре сведений ПравилаДляОбменаДанными . При отладке рекомендуется использовать загрузку правил обмена из файла. Для обновления правил из макета следует изменить номер версии конфигурации или выполнить загрузку вручную по команде Загрузить правила… , выбрав вариант Из конфигурации .Веб-сервисы
Типовая конфигурация «1С:Документооборот» содержит набор веб-сервисов.
Некоторые из них специализированы и служат, например, для обмена с мобильными устройствами или для синхронизации данных с другими информационными базами, разработанными с применением «Библиотеки стандартных подсистем».
Два веб-сервиса, однако, предназначены для интеграции с произвольными внешними программами, как разработанными на платформе «1С:Предприятие», так и любыми другими, способными обращаться к веб-сервисам. Речь идет о веб-сервисах:
- Files – простой сервис, поддерживающий работу с файлами и папками «1С:Документооборота» извне.
- DMService – поддерживает работу с основными объектами и функциями «1С:Документооборота». Перекрывает функционал веб-сервиса Files . Используется «Библиотекой интеграции 1С:Документооборота».
Данные веб-сервисы включены во все редакции «1С:Документооборота».
Работа с веб-сервисами из прикладных решений на платформе «1С:Предприятие», как правило, строится следующим образом:
- Определяется способ хранения и редактирования настроек подключения к веб-сервису. Настройки состоят из:
- Адреса веб-сервиса;
- Имени пользователя и пароля (в текущих версиях платформы поддерживается только аутентификация «1С:Предприятия», поэтому следует либо предоставить пользователям интегрируемого прикладного решения возможность ввести имя пользователя и пароль, либо использовать для доступа служебную учетную запись, для которой запрещен интерактивный вход);
- Таймаута при обращении к сервису (при низком качестве соединения, а также при первом обращении к сервису задержки могут быть значительными).
- Определяется способ получения WSПрокси для обращения к веб-сервису. Операции создания WSОпределений и WSПрокси достаточно затратны, поэтому рекомендуется выносить получение реквизитов, в отдельный общий модуль с повторно возвращаемыми значениями.
- Создаются процедуры и функции, являющиеся обертками для функционала веб-сервиса на стороне прикладного решения. Непосредственную работу с объектами XDTO рекомендуется инкапсулировать в них, чтобы облегчить доработки при изменении функционала сервиса.
Примеры использования веб-сервисов можно увидеть в «Библиотеке интеграции 1С:Документооборота», поставляемой в составе дистрибутива «1С:Документооборота».
Веб-сервис Files
Веб-сервис использует всего четыре типа объектов:
- File – файл в папке.
- Folder – папка файлов.
- ShortFileInfo – сведения о файле, возвращаемые сервисом после его создания.
- FileList – список файлов, отобранных по условиям.
- GetFileList – получает список файлов в указанной папке.
- GetFile – получает файл по указанному коду файла.
- AddFile – добавляет файл в указанную папку.
- DeleteFile – помечает файл на удаление.
- FindFolder – находит папку по наименованию в указанной родительской папке.
- AddFolder – создает новую папку в указанной родительской папке.
Все действия, выполняемые этим веб-сервисом, можно выполнить с помощью веб-сервиса DMService. Работа с файлами документов поддерживается только DMService.
Веб-сервис DMService
Сервис использует XDTO-пакет DM. Пакет содержит несколько десятков прикладных объектов, являющихся представлениями таких объектов «1С:Документооборота», как файлы, документы, процессы, задачи и так далее. Все они — потомки абстрактного DMObject и имеют общие свойства objectId и externalObject .
Свойство objectId представляет собой ссылку на объект «1С:Документооборота» и содержит его представление, идентификатор и тип.
Свойство externalObject представляет собой ссылку на объект интегрируемой программы и так же содержит его представление, идентификатор и тип. Свойство заполняется сервисом автоматически, если объект «1С:Документооборота» был ранее связан с объектом интегрируемой конфигурации, например, при создании или записи с заполненным свойством externalObject .
Сервис поддерживает всего одну операцию, execute . В качестве параметра передается объект-потомок DMRequest . Требуемая операция и ее параметры определяются типом переданного объекта и его свойствами. Например, запрос DMGetObjectListRequest получает список объектов типа, указанного в свойстве type по условиям, указанным в свойстве query .
Результат операции возвращается в объекте-потомке DMResponse . В простейших случаях это объект DMOK . В случае ошибки возвращается DMError , содержащий краткое ( subject ) и полное ( description ) описание ошибки.
Для большинства запросов существуют парные им объекты-ответы, содержащие результат выполненной операции. Например, список объектов, полученный вызовом DMGetObjectListRequest , возвращается в объекте DMGetObjectListResponse .
Приведем простейший пример работы с веб-сервисом на встроенном языке платформы «1С:Предприятие». Начнем с получения определений и прокси веб-сервиса (подразумевается, что адрес публикации, имя пользователя и пароль уже получены):
Cоздадим запрос на получение списка внутренних документов:
Определим условие запроса (поиск по наименованию):
Выполним запрос, проверив результат на предмет ошибки:
Разберем ответ, заполнив таблицу названиями и идентификаторами найденных документов:
Подробное описание объектов и операций сервиса дается в составе дистрибутива «1С:Документооборота» (файл «Описание веб-сервисов.html» в каталоге шаблонов). Это описание доступно также из интерфейса демонстрационной конфигурации «Библиотека интеграции с 1С:Документооборотом», которая содержит также более сложные и полезные примеры использования сервиса.
При выпуске новых версий «1С:Документооборота» сервис расширяется и дополняется новыми объектами и свойствами так, чтобы не затронуть работу клиентских приложений, не знающих об этих изменениях. Этого же принципа следует придерживаться при самостоятельном изменении функционала сервиса: например, добавляя новые свойства, устанавливать минимальное количество в 0.
Обработка запросов к сервису сосредоточена в общих модулях:
- ОбработкаЗапросовXDTO – общий вход для всех вызовов
- ОбработкаЗапросовXDTOБизнесПроцессыИЗадачи
- ОбработкаЗапросовXDTOДокументы
- ОбработкаЗапросовXDTOФайлы
Присутствуют только в редакции КОРП:
- ОбработкаЗапросовXDTOКорп
- ОбработкаЗапросовXDTOОбмен
- ОбработкаЗапросовXDTOПочта
- ОбработкаЗапросовXDTOУчетВремени
Перед использованием сервиса следует получать его версию и редакцию запросом DMGetVersionRequest и не пользоваться возможностями, которые не поддерживает сервис. Попытка использовать отсутствующие возможности, например, попытка создать исходящее письмо в редакции ПРОФ, приведет к ошибке (возврату DMError ).
Доработки рекомендуется вносить в модуль ОбработкаЗапросовXDTO Переопределяемый . Его процедуры и функции позволяют провести дополнительное изменение объектов XDTO при их создании по объектам «1С:Документооборота» и наоборот.
Библиотека интеграции 1С:Документооборота
«Библиотека интеграции 1С:Документооборота» (далее БИД) не является самостоятельным прикладным решением, хотя и содержит некоторые демонстрационные объекты, и предназначена для встраивания в прикладные решения на платформе «1С:Предприятие».
БИД может использоваться с любыми версиями «1С:Документооборота», начиная с редакции 1.2.
БИД публикуется в составе дистрибутива «1С:Документооборота» и предназначена для работы с «Библиотекой стандартных подсистем» версии, последней на момент публикации. Однако адаптация БИД к конфигурациям, содержащим более ранние версии БСП, не составляет большого труда, поскольку БИД использует функционал БСП в небольшом объеме.
Более подробное описание «Библиотеки интеграции 1С:Документооборота» и порядка ее встраивания содержится в документации, поставляемой в составе дистрибутива (папка DocDMIL ).
Способы интеграции с 1С
Какие важнейшие требования предъявляются к бизнес-приложениям? Одними из самых главных являются следующие задачи:
- Легкость изменения/адаптации логики работы приложения к меняющимся бизнес-задачам.
- Легкость интеграции с другими приложениями.
Интеграционные задачи
Интеграционные задачи могут быть разными. Для решения одних достаточно простого интерактивного обмена данными – например, для передачи в банк списка сотрудников для оформления зарплатных пластиковых карт. Для более сложных задач может быть необходим полностью автоматизированный обмен данными, возможно, с обращением к бизнес-логике внешней системы. Есть задачи, носящие специализированный характер, вроде интеграции с внешним оборудованием (например, торговым оборудованием, мобильными сканерами и т.д.) или с унаследованными или узкоспециализированными системами (например, с системами распознавания RFID-меток). Крайне важно для каждой задачи выбрать наиболее подходящий механизм интеграции.
Возможности интеграции с 1С
Существуют различные подходы к реализации интеграции с приложениями 1С, какой из них выбрать – зависит от требований задачи.
-
Реализация на основе механизмов интеграции, предоставляемых платформой, своего собственного специализированного API на стороне приложения 1С (например, набора Web- или HTTP-сервисов, которые будут вызывать сторонние приложения для обмена данными с приложением 1С). Плюс этого подхода – устойчивость API к изменению реализации на стороне приложения 1С. Особенность подхода — требуется менять исходный код типового решения 1С, что может потенциально потребовать усилий при слиянии исходных кодов при переходе на новую версию конфигурации. В этом случае может прийти на помощь новая прогрессивная функциональность — расширения конфигурации. Расширения – это, по сути, механизм плагинов, который позволяет создавать дополнения прикладных решений, не меняя самих прикладных решений. Вынос интеграционного API в расширение конфигурации позволит избежать сложностей при слиянии конфигураций при переходе на новую версию типового решения.
Механизмы интеграции в платформе 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
Начиная с версии 8.3.5 платформа 1С:Предприятие может автоматически формировать REST интерфейс для всего прикладного решения. Любой объект конфигурации (справочник, документ, регистр сведений и т.д.) можно сделать доступным для получения и модификации данных через REST интерфейс. В качестве протокола доступа платформа использует протокол OData версии 3.0. Публикация сервисов OData выполняется из меню Конфигуратора «Администрирование -> Публикация на веб-сервере», флажок «Публиковать стандартный интерфейс OData» должен быть помечен. Поддерживаются форматы atom/XML и JSON. После того, как прикладное решение опубликовано на веб-сервере, сторонние системы могут обращаться к нему через REST интерфейс с помощью HTTP запросов. Для работы с приложением 1С через протокол OData программирование на стороне 1С не требуется.
Так, 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С (список ниже) на основе описанного выше платформенного механизма обмена данными реализован готовый механизм обмена данными с внешними приложениями, не требующий изменения исходного кода конфигураций (подготовка к обмену данными делается в настройках прикладных решений):
- «1C:ERP Управление предприятием 2.0»
- «Комплексная автоматизация 2»
- «Бухгалтерия предприятия», редакция 3.0
- «Бухгалтерия предприятия КОРП», редакция 3.0
- «Розница», редакция 2.0
- «Управление торговлей базовая», редакция 11
- «Управление торговлей», редакция 11
- «Зарплата и управление персоналом КОРП», редакция 3
Обмен данными между приложением 1С и сторонним приложением может происходить:
- через выделенный файловый каталог
- через каталог FTP
- через веб-сервис, развернутый на стороне приложения 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), написанных на разных платформах и использующие разные протоколы обмена данными. В такой ситуации очевидным и естественным желанием является связать все системы, чтобы быстро и эффективно передавать информацию между ними.
Способы передачи данных между системами
Можно выделить два подхода к интеграции: интеграция данных и функциональная интеграция. В первом случае обеспечивается обмен информацией между системами, во втором ‑ обеспечивается возможность одной системы обращаться к функционалу другой системы для получения и передачи данных. Как можно передавать данные между информационными системами? Существуют следующие способы:
Использование отдельной общей базы данных, где хранится полная информация (Microsoft SQL Server, IBM Db2, PostgreSQL, Oracle Database, MySQL);
Вызов (в том числе удаленный) методов программного интерфейса одной системы из другой системы (API);
Обмен сообщениями систем класса сервисная шина предприятия (Enterprise Service Bus, сокращенно ESB или СШП). В марте 2020 года фирма 1С анонсировала новый продукт такого класса — «1С:Шина».
Почему не всегда устраивают первые три способа передачи данных?
Обмен файлами. При файловом обмене оперативность, с которой передаются данные, зависит от расписания выгрузки и загрузки. Интенсивная работа с большим количеством файлов может привести потере производительности. Файловый обмен позволяет выполнить интеграцию данных, но не позволяет выполнить функциональную интеграцию, то есть сами данные передаются, но системы при этом не взаимодействуют, и существует вероятность, что информация потеряется по дороге.
Наглядно такую информацию можно представить на картинке-паззле или детских кубиках. Когда мы отправляем объемный файл, он передается по частям в строгой последовательности, как кубики с нарисованной картинкой. Если в процессе перемещения кубиков с одного места на другой, кубик потерялся, перевернулся или переместился, картинка получится неполная или не будет понятно, что на ней. Так случается потеря данных при обменах между конфигурациями 1С, например, 1С:Бухгалтерия (БП) и 1С:Зарплата и управлением персоналом (ЗУП). Например, в ЗУП внесли данные нового сотрудника, и по регламентному заданию ЗУП выгружает их в БП, однако, из-за разницы в релизах или ошибке при передаче, БП данные не сохраняет. В итоге для синхронизации обеих баз, требуется полностью выгрузить справочник сотрудников из ЗУП в БП, что приводит к дополнительным нагрузкам на сервер и затратам времени.
Использование СУБД. При организации взаимодействия систем через прямое обращение к СУБД ( Система управления базами данных) работоспособность интеграции может нарушиться из-за изменений в схеме передачи данных, например, из-за переноса программы на другой сервер, или изменений в протоколе передачи данных – такое может случиться, например, при обновлении одного из компонентов системы. Также могут возникнуть сложности с использованием лицензий СУБД, в случае запрета их использования сторонними системами или ограничения числа используемых подключений. Кроме того, нужно понимать, что в реальной жизни создание дополнительной базы данных для обмена с различными системами требует покупки дополнительных лицензий, проектирования архитектуры сети и даже покупки нового оборудования, что приводит к финансовым затратам и отражается на информационной безопасности компании.
Вызов методов программного интерфейса одной системы из другой (API) обеспечивает функциональную интеграцию, так как одна система непосредственно обращается к другой. API обеспечивает простоту использования, экономит время и средства, так как можно использовать один и тот же готовый протокол для большого числа приложений, понимающих его, и позволяет видеть актуальную информацию во всех связанных системах. Однако новые данные не сразу попадают к адресату. Передача данных тоже работает по регламентному заданию.
API – это способ передачи, он не хранит данные. Например, чтобы рассказать, что за дверью сидит кошка, можно написать словами «За дверью сидит кошка», можно нарисовать картинку с кошкой за дверью, можно изобразить кошку, как она сидит за дверью – и в принципе информация передана одна и та же, только способы разные, но сама кошка от этого в комнате не окажется. И если спросить у API про кошку сейчас – сидит ли она за дверью? API даст ответ в прошедшем времени, если его информация еще не обновилась. Кроме того, API одинаков для всех и набор его функций ограничен, поэтому индивидуальные задачи он не решает: например, он не ответит, какого цвета кошка за дверью, потому что этот функционал отсутствует в его программе.
Сервисная шина предприятия «1С:Шина»
Сервисная шина предприятия «1С:Шина» решает вышеперечисленные сложности с кошками. Так как сервисная шина не просто передает информацию о кошке за дверью, она бережно забирает кошку и хранит ее до тех пор, пока о ней не спросит хозяин, а при запросе сразу вручает кошку в руки хозяину, не заставляя ждать. Иными словами, в этот сервис можно загрузить данные, и они в нем будут храниться, пока адресат их совершенно точно не заберет. При этом шина регулярно сама вызывает адресата и проверяет, можно ли уже отдать данные. Таким образом, способ передачи данных с помощью сервисной шины, в том числе конфигурации «1С:Шина», обладает следующими преимуществами :
дает возможность частого и быстрого взаимодействия небольшими сообщениями;
сообщения при необходимости могут быть трансформированы для возможности получения другой системой без участия и уведомления отправителя и получателей;
предоставляет возможность доставить одно сообщение множеству получателей в оригинальном или измененном виде без изменения логики работы отправителя;
отправитель не должен ожидать ответа на свое сообщение, а должен быть готовым в любой момент времени принять сообщение и адекватно на него отреагировать.
В основе работы «1С:Шины» лежит принцип асинхронного обмена сообщениями. Асинхронность подразумевает, что система-отправитель не взаимодействует с системами-получателями, а взаимодействует только с посредником — «1С:Шиной». В свою очередь «1С:Шина» взаимодействует с получателями по мере их доступности и готовности. «1С:Шина» позволяет настраивать маршрутизацию передаваемых через нее сообщений, то есть по содержимому сообщения определять, какие из взаимодействующих систем должны получить это сообщение.
Если вернуться к примеру с кошкой, то можно представить, что в шину загружается несколько кошек для разных хозяев, которые хранятся в шине, как в питомнике, и раздаются хозяевам, по мере того, как они приходят. При этом для некоторых хозяев кошек могут трансформировать: подстричь, покрасить, изменить породу – чтобы хозяин точно узнал свою кошку и забрал. Все это позволяет сделать сервисная шина «1С:Шина».
При работе с пакетами данных разработчик может через специальную среду разработки декларативно настраивать маршрутизацию и трансформацию сообщений с использованием встроенного языка. Система предоставляет возможность получить и удалить сообщения, которые еще не отправлены в другие системы или не обработаны механизмами нашей системы. То есть те, которые непосредственно находятся в сервисе «1С:Шина». Сообщения помещаются в один и тот же канал последовательно и получаются из канала последовательно, но сообщения разных каналов обрабатываются и доставляются параллельно.
Механизм сервисов интеграции «1С:Предприятия» не является альтернативной механизмам обмена между системами, так как отвечает только за транспортировку сообщений, а не за формирование исходящих и интерпретацию входящих сообщений. В то же время, механизм обмена может выступать в качестве источника данных для таких сообщений.
«1С:Шина» гарантирует, что данные не потеряются при транспортировке. Это обеспечивается тем, что отправляемое сообщение сохраняется в информационной базе до тех пор, пока от внешнего сервиса интеграции (системы) не будет получено подтверждение того, что сообщение получено. Если в системе «1С:Шина» есть неполученные сообщения, она будет выполнять попытки доставить сообщения до тех пор, пока не будет получено подтверждение получения сообщения или сообщение не устареет. Подтверждение о получении сообщения происходит только после того, как информация сохраняется в базе получателя. Если во время процесса подтверждения произойдет сбой, то после восстановления работоспособности, система повторно отправит сообщение, поэтому важно, чтобы обработчик получения сообщений позволял получать одно и то же сообщение более одного раза. Если сообщение отправлено удачно ‑ оно удаляется из очереди сообщений. Если отправка не удалась ‑ сообщение остается в очереди до тех пор, пока не будет отправлено или не устареет, при этом оправка остальных сообщения в канал не выполняется, пока не будет выполнена отправка первого сообщения.
При настройке интеграции с «1С:Шиной» внешних сервисов интеграции (других систем) в конфигурации создается нужное количество объектов сервиса интеграции. Один объект – один сервис интеграции. Для каждого созданного сервиса интеграции создается список каналов, указываются имена каналов, направления их использования (входящий, исходящий) и их адреса. Для исходящих каналов необходимо реализовать программный код, для входящих каналов реализуется обработчик, который будет срабатывать при получении сообщения в конкретном канале конкретного сервиса интеграции. Каждая система имеет настройки интеграции, которые можно устанавливать или из встроенного языка 1С, или с помощью стандартной обработки 1С — «Управление сервисами интеграции».
«1С:Шина» работает в файловом режиме, однако это все же решение, предназначенное для клиент-серверного режима работы. В файловом варианте фоновые задания всегда выполняются последовательно. При работе клиент-серверного варианта все фоновые задания для каждого сервиса интеграции запускаются одновременно. Администратор может управлять его работой в удобном графическом интерфейсе (Рисунок 2, источник ).
Процесс настройки и эксплуатации продукта состоит из нескольких шагов, которые позволяют достаточно быстро и относительно просто выполнить настройку обмена сообщениями, а также контролировать уже запущенные к обмену потоки (Рисунок 3).
Целью продукта «1С:Шина» является обеспечить эффективное взаимодействие систем различных производителей. Это современное сервисное решение на платформе «1С:Предприятие», включающее в себя все перечисленные выше способы обмена данными:
обмен сообщениями в виде файлов, сохраненных в файловой системе или на FTP-ресурсах;
обмен сообщениями, используя подключение к СУБД клиентской информационной системы по стандарту JDBC;
обмен данными по протоколу AMQP для подключения к внешним брокерам сообщений, например, Apache ActiveMQ Artemis, RabbitMQ;
выполнение HTTP-запросов к внешним системам для получения или отправки данных, вызовов REST API или WEB-сервисов.
Это снимает с IT-специалистов проблему несовместимости платформы 1С и других информационных систем. При этом обеспечивает высокую скорость работы (тысячи сообщений в минуту), высокую производительность за счет асинхронности обмена, и гарантирует сохранение данных на каждом отрезке пути от системы-отправителя до системы-получателя.
Эти возможности позволяют одинаково успешно решать привычные задачи обмена данными и реализовывать более сложные сценарии взаимодействия между системами.
Со времени первого анонса сервиса «1С:Шина» прошло более 2-х лет, и за это время уже были осуществлены реальные интеграции продукта на предприятиях России. В 2021 году сервис «1С:Шина» был успешно интегрирован в корпоративную информационную систему на базе конфигурации «1С:Управление производственным предприятием» в нефтесервисной отрасли; использован для создания обменов между программными продуктами «1С:Университет», «1С:Бухгалтерия государственного учреждения» и «1С:Зарплата и кадры государственного учреждения» в образовательной деятельности. Также «1С:Шина» также выступила в качестве маршрутизатора и трансформатора сообщений из различных ИТ-систем, включающих информационные базы на платформе «1С:Предприятие», в финансовом секторе экономики.
Использование финальной версии программного продукта «1С:Шина» доступно совместно с платформой «1С:Предприятие» версий 8.3.19.1399, 8.3.20.1590 и выше. С точки зрения лицензирования программный продукт «1С:Шина» имеет 3 вида электронной поставки:
1С:Шина для 100 пользователей. Электронная поставка;
1С:Шина для 500 пользователей. Электронная поставка;
1С:Шина без ограничений на число пользователей. Электронная поставка.
Один экземпляр «1С:Шины» можно установить только на один сервер.
Количество пользователей означает фактическое количество пользователей программных продуктов 1С:Предприятие, которые могут одновременно подключаться к информационным базам 1С и создавать сообщения. Для выполнения требований лицензионного соглашения, количество лицензий, доступное пользователям всех информационных баз 1С, подключённых к «1С:Шина», должно быть не больше, чем в лицензии на «1С:Шина». Пользователи систем, построенных не на платформе 1С:Предприятие, не учитываются. Программный продукт представлен в прайсе 1С.
В состав программного продукта «1С:Шина» (электронная поставка) входят:
дистрибутив, содержащий сервер «1С:Шины» и среду разработки, а также документацию к программному продукту;
именное лицензионное соглашение на использование программного продукта указанным в документе юридическим лицом;
пин-код для регистрации программного продукта на портале информационно-технологического сопровождения 1С:ИТС portal.1c.ru;
купон для оформления договора информационно-технологического сопровождения 1С:ИТС на льготных условиях.
При покупке нескольких лицензий количество пользователей суммируется. При этом фирма «1С» предусмотрела льготный апгрейд для перехода на более емкие лицензии, когда при покупке лицензии, позволяющей подключать больше пользователей, можно получить скидку в размере ранее купленной лицензии, но не более 50%. Приобрести программный продукт «1С:Шина» в настоящее время можно только у официальных франчайзи 1С, выполняющих условия партнерского договора, к которым относится и франчайзинговая сеть «ИнфоСофт» (г.Новосибирск).