Две первые части статьи выходили в тренд на ИС. Чему я, конечно же, рад!
Это говорит о несомненном интересе сообщества как к теме продуктов класса Enterprise Service Bus (ESB) вообще, так и к 1С:Шине в частности.
Кто не успел познакомиться с первыми двумя частями статьи - милости прошу:
А вот и Шина подъехала! Часть 1
А вот и Шина подъехала! Часть 2
Но, как я понимаю, получая обратную связь в комментариях, тема полезности подобных продуктов для многих все еще остается нераскрытой.
Сейчас я все-таки попытаюсь исправить этот момент, даже не будучи уверенным в результате. Не у всех и не всегда получается передать в тексте то, что хочется, да простят меня мои читатели... :-)
Итак, приступим.
Во-первых, я не хотел бы сейчас углубляться в теорию и описывать то, что уже давно описано.
Я прошу тех, кто не знаком с понятиями Шина данных или Enterprise Service Bus (ESB) бегло - на это понадобится совсем немного времени - ознакомиться с их кратким описанием где-нибудь в интернете.
Также, стоит ознакомиться с презентационной страничкой об 1С:Шине.
Просто, чтобы мое дальнейшее изложение было понятнее и не вызывало банальных вопросов.
Во-вторых, стоит принять тот факт, что 1С:Шина (или любой другой продукт на эту тему), сама по себе, не является панацеей от возникающих у вас проблем с обменом данными в вашей информационной инфраструктуре.
Ее приобретение не решит их все и сразу. Это просто первый шаг к построению развитой информационной инфраструктуры, позволяющей относительно легко и быстро управлять информационными потоками в ней, настраивать новые интеграции, модифицировать или отключать "старые".
Для построения такой инфраструктуры понадобится дополнительно много усилий, как организационных, так и технических.
Причем унифицировать и масштабировать (перенести на другие информационные инфраструктуры) подобные усилия вряд ли получится в полной мере - такие инфраструктуры почти всегда уникальны по набору систем и интеграций между ними.
Но мы все равно попробуем, хотя бы частично :-)
Показания к применению
Попробую сейчас, максимально четко и по пунктам, описать набор тех вопросов и вариантов ответов на них, которые должны быть основой для принятия решения о внедрении 1С:Шины (или подобного продукта в принципе). Как я понимаю, именно такого "перечня" ждут от меня многие читатели, вопрошающие "зачем это вообще?".
- Количество интеграций в информационной структуре.
Не информационных систем, так или иначе обменивающихся данными. Понятно, систем должно быть минимум две :-)
Более важным фактором должно стать количество именно интеграций.
Придется немного отвлечься и описать, что же я считаю "интеграцией".
Для меня это структура, однозначно описывающая сущность передаваемых данных (элементы НСИ, различные документы, отчеты), а также систему-отправителя и систему-получателя. То есть, структура "тип данных-отправитель-получатель", так часто упоминаемая мной во второй части статьи.
Еще я бы добавил к этой структуре формат (КД2, EnterpriseData, XML, JSON и т.п.) и способ передачи данных (файловый обмен, http-сервис, электронная почта и т.д.)
Вот если подобных интеграций набирается больше десятка, и, при этом, форматов и/или способов передачи используется больше одного, то лично я уже считаю такую ситуацию "показанием к применению".
Для себя выбирайте критическое количество сами)
- Возможности анализа/модификации/отключения всех существующих интеграций.
Тут, конечно же, можно поспорить. У кого-то этих интеграций полтора-два десятка, все они "на виду", о них все известно. И, в случае потребности в доработках, никаких проблем не будет... Добавим, допилим, отключим!
Тот, кто это будет делать сейчас, через пару лет, несомненно, вспомнит все мельчайшие детали для того, чтобы еще раз , при необходимости, модифицировать эту интеграцию...
Ну, а не вспомнит, - залезет в код и проанализирует. А если это будет не "тот", а "другой"? Ну, тоже проанализирует код. И... настройки планов обмена, и... саму папку обмена и ее доступность системам, и... т.д. То есть, придется анализировать сразу несколько аспектов, связанных как с самими данными и форматами передачи, так и с их транспортировкой.
Работа разработчика-интегратора может быть в разы сложнее работы 1С-ка, допиливающего конкретный функционал в рамках одной конфигурации.
А еще она связана с рисками потери/порчи данных, остановки работы всей инфраструктуры. Хорошо, если все всплывет быстро и удастся избежать глобальных проблем.
А если в процессе доработки "забыли" или "не знали", что дорабатываемая интеграция имеет не одного, а двух получателей? И во втором в результате доработки "сломалась" загрузка данных. Если данные эти критичные, но обращение к ним происходит относительно редко - тут поджидает беда. Не сразу, со временем, бомба замедленного действия...
Структурированное подробное документированное описание всех возможных интеграций между вашими системами, актуальность которого скурпулезно поддерживается в процессе доработок/модификаций. Это то, что должно обязательно быть в любой организации, обеспокоенной целостностью своей информационной инфраструктуры.
И это, как раз, та часть документации, которая, чаще всего, либо отсутствует полностью, либо, если и есть, то в сильно фрагментированном и неактуальном виде.
В итоге - полная зависимость от разработчиков-интеграторов, которые "все знают и умеют". Или необходимость много платить тем, кто способен разобраться.
Само собой, такую документацию вести можно (и нужно) и без всяких шин.
А вот то, что никто или почти никто этого не делает - совершенно неудивительно.
На самом деле, тем самым разработчикам-интеграторам это добавляет забот и при этом снижает их ценность для организации! Кто ж будет по своей воле этим заниматься?) Только "из под палки" IT-директора или при очень хорошо поставленном процессе разработки.
Если "интегрируемся" у аутсорсеров, то требовать документацию придется с них. И платить за это, естественно.
Но, если мы говорим про концепцию построения процессов интеграции на единой Шине и с использованием единой системы управления интеграциями (СУИ), сами настройки которой могут выступать в качестве документированного описания интеграций, то этот вопрос, если не полностью, то в значительной степени будет решен.
То есть - не настроишь, интеграция не взлетит. А настроишь - считай "задокументировал")
- Риски потери данных.
Это про "гарантированную доставку", вопросы которой поднимались мной в первых двух частях статьи.
Если вы их читали, то тут можно коротко. Если в вашей информационной инфраструктуре эти риски и так сведены к минимуму, то для вас аргумент "гарантированной доставки" - не аргумент. И не может являться "показанием к применению" 1С:Шины и подобных систем.
Но, если, например, какие-то ваши обмены идут в файловом формате через некую "общую папку", или вы используете электронную почту, или вы не используете квитирование (подтверждение получение сообщения обмена), или...дополните сами этот перечень ненадежными способами передачи данных - вы подвержены риску потери данных.
Если используется синхронный обмен критичными данными через http-сервис, а система, его предоставляющая "прилегла", то процесс, управляемый обменом, тоже встает "намертво".
Такой момент тоже можно отнести к "потере данных", поскольку любой или почти любой синхронный обмен можно заменить асинхронным.
В общем, "гарантированная доставка" - неоспоримое, предоставляемое "из коробки", преимущество 1С:Шины, поддерживаемое к тому же сервисами интеграции в базах 1С.
Если "оно вам не надо", значит критичность ваших данных и, соответственно, бизнеса, от них зависящего, невысока и до Шины попросту не доросла. Сидите себе дальше на папке обмена - вполне, кстати, жизнеспособная вещь ;-)
- Скорость и объемы обмена данными.
Это про способы передачи данных.
Если количество и/или объем отдельных сообщений обмена ваша существующая система передачи данных (жесткий диск, на котором лежит папка обмена) перестает выдерживать, то самое время обратиться к системам ESB.
1С:Шина декларирует производительность на основании проведенного теста: 20 000 сообщений объемом в 256 Кб в минуту с передачей из сервисов интеграции 1С.
Может быть, на первый взгляд цифры и не впечатляют, но при основательной оценке окажутся более чем достаточными почти для любых потребностей обмена в учетных или управляющих бизнес-процессами системах.
- Готовность к затратам, связанным с приобретением и внедрением 1С:Шины.
Тут все ну очень просто. Если предыдущие 4 пункта вместе или по отдельности (и можете к ним добавить то, что я по вашему мнению упустил) убеждают вас заняться Шиной, но ресурсов на это выделить невозможно - отложите этот вопрос.
И внедрение, однозначно, может встать дороже самой Шины.
Во-первых, это про самостоятельную разработку или приобретение (если на рынке что-то когда-то появится) системы управления интеграциями (СУИ), работающую совместно с Шиной, и реализующую второй пункт из раздела "Показания к применению".
Во-вторых, про перевод тех синхронных интеграций, которые у вас существуют, на асинхронные. Этот пункт можно не делать - работают себе и работают. Но тогда у вас останется неуправляемый "зоопарк". Часть интеграций станут "цивилизованными", часть останется в "каменном веке" (кто бы мог подумать всего несколько лет назад, что я скажу подобное про http-сервисы).
В-третьих, про первичное описание всех интеграций, подлежащих переводу на Шину. Оно должно очень существенно помочь процессу перевода. Но, в принципе, можно переводить интеграции на Шину и "кусочками", постепенно и долго.
Само собой, перечень вопросов о целесообразности внедрения 1С:Шины (или любой другой подобной системы) можно расширить. Я привел те, которые наиболее актуальны, на мой взгляд.
Надеюсь, такое изложение возможных причин использования Шины будет, наконец, более понятно читателям, чем просто неупорядоченные мысли на эту тему в предыдущих частях статьи.
Приступим к практическим вопросам.
Практические моменты
Реализация "неявной маршрутизации" сообщений
В предыдущей части статьи я описывал принцип минимизации количества блоков типа "Группа участников" в проекте Шины.
Одной из проблем такой минимизации может стать то, что к одной группе участников будут присоединены несколько блоков-каналов разных типов: и 1С, и Кролика, и FTP и т.п.
При использовании подключения блоков-каналов через реквизиты справочника Инфосистем (опять же, описанного во второй части статьи), мы получим то, что одна часть Инфосистем окажется неподключенной к одним коннекторам, а другая часть - к другим.
При этом, если мы не предотвратим попадание информационного сообщения, предназначенного для системы Кролика, в канал "Получение1С" (см. рисунок), то такое сообщение "зависнет" в этом канале без перспективы отправится в "свою" систему.
Решение представлено на том же рисунке схемы процесса интеграции. Из каналов отправки ("Отправка1С" или "Отправка RMQ") сообщение попадает в блок типа Транслятор "ОбработкаПолучателей". Это единственный тип блоков в процессе интеграции, где возможно преобразование сообщения, причем включая и тело, и свойства сообщения.
Но, в данном случае, мы будем не только преобразовывать исходное сообщение, но и создавать на его основании новые, меняя в них свойство адресации КодыПолучателей и добавляя параметр "recipienttype", который будет использован для маршрутизации сообщений в схеме процесса интеграции.
В обработчике блока-транслятора мы разбираем свойство сообщения КодыПолучателей, определяем типы Инфосистем, которым предназначено сообщение (а оно может быть предназначено сразу нескольким Инфосистемам). Далее, "клонируем", при необходимости, наше одно сообщение в несколько, добавив в свойства результирующих сообщений информацию о типах подключения систем и оставив в адресатах результирующих сообщений только Инфосистемы "нужного" типа.
Одно из таких сообщений мы просто отправим дальше из текущего блока "ОбработкаПолучателей", переопределив в параметре процедуры-обработчика Сообщение исходное сообщение. Остальные сгенерируем как новые сообщения, скопировав из исходного, и отправим дальше в процесс интеграции через блок "АдресованныеСообщения", имеющий тип ПрограммныйИсточник, как раз для таких действий и предназначенный.
В программе это выглядит так (см. под спойлер):
Метод ОбработкаПолучателей является обработчиком одноименного блока в схеме процесса интеграции. Тут сообщение может быть разбито на несколько.
Метод КодыИнфоСистемПоТипамПолученияСообщений вспомогательный. С его помощью определяется принадлежность систем к тому или иному типу подключения. Да простят меня мэтры за упрощенную реализацию - при определении типа системы я проверяю на заполненность один из ее реквизитов подключения к Кролику :-)
Метод ОтправкаПоТипамВыборПолучателей является обработчиком блока маршрутизации "ОтправкаПоТипам". В обработчике анализируется свойство сообщения recipienttype, сформированное в обработчике блока "ОбработкаПолучателей", в соответствии с чем определяется в какой блок-канал отправить это сообщение.
В более общем случае использования не двух, а более типов подключения, и схема процесса и его программный код незначительно изменятся: добавятся строчки описания новых элементов перечисления ТипыПолученияСообщенийИнформационныхСистем, определения типов подключения по заполненности соответствующих реквизитов справочника Инфосистем и маршрутизации сообщений в новые блоки-каналы.
В общем, все достаточно несложно. Но, как пример использования сразу нескольких типов блоков схемы процесса интеграции, несомненно, полезно.
Нестандартные способы регистрации изменений для регулярного обмена данными
В описании этого практического момента работы с Шиной не будет совсем. Только так горячо всеми любимый 1С. И то без кода!
В общем-то, достаточно очевидно, что какой бы ни была транспортная система передачи данных - 1С:Шина, файловая система или еще что - информационное сообщение не возникает "ниоткуда". Триггером, порождающим сообщение обмена данными, должно являться какое-то событие.
Чаще всего это добавление, изменение или удаление какого-либо элемента данных (элемент справочника, документ и т.п.) или запрос от другой системы.
Здесь рассмотрим как раз "добавление, изменение или удаление".
Для фиксации факта такого события в платформе 1С давным-давно реализованы Планы обмена. Они помогают автоматизировать некоторые действия, связанные с регистрацией изменений данных, отправки измененных данных в другие системы и квитирования отправленных изменений.
БСП существенно дополняет их функционал правилами регистрации изменений, настройкой транспортировки сообщений и другими "плюшками".
Сервисы интеграции, работающие с 1С:Шиной из конфигурации 1С, в настоящее время с планами обмена с помощью БСП не связываются. Будет ли когда-то добавлен такой функционал или нет - неизвестно. А если будет, то непонятно как именно он будет реализован, под какой проект Шины он может быть заточен и какие может иметь ограничения.
Но на ИТС опубликован пример, в котором реализуется обмен данными через приложение 1С:Шины с использованием Плана обмена: Настройка обмена данными между базой на платформе "1С:Предприятие" и интернет-сайтом с использованием "1С:Шины".
Доступ к примеру свободен для всех.
Как и следовало ожидать, план обмена ОбменСИнтернетМагазином используется в примере для авторегистрации объектов к выгрузке.
Вся работа с ним ведется через достаточно простой программный код, осуществляющий выборку зарегистрированных объектов для выгрузки и дальнейшее удаление регистраций.
Собственно, Шина тут может быть вообще ни при чем, транспортом в этом примере может выступать что угодно. Просто сделан он для демонстрации работы именно Шины.
Так же смело мы можем поступись и с планами обмена - сделать их "ни при чем", раз уж все равно никакой помощи в их связке с сервисами интеграции Шины вендор нам пока не предлагает.
Зачем? Чем они мне так не угодили? Почему не продолжать использовать планы обмена именно для тех функций, для которых они предназначены? И "обвязка" в БСП присутствует, и связать их с сервисами интеграции, как показано в примере, в общем-то, несложно, и авторегистрация - это иногда хорошо...
Да нет, использовать их, конечно же, можно. В некоторых случаях, когда на них и так уже настроено много и не хочется "трогать", даже нужно!
Но, в свое время, я наткнулся на великолепную статью Дмитрия Жичкина на ИС - Планы обмена 1С.
Очень рекомендую всем, интересующимся темой. Планы обмена там изучены под микроскопом, рассмотрены их основные проблемы и предложены альтернативные варианты.
Если вы думаете над внедрением 1С:Шины или другого похожего продукта, то, возможно, вы предполагаете использовать его для достаточно интенсивных обменов.
Если у вас высокая интенсивность обменов, то Планы обмена, реализованные в платформе давным-давно и не рассчитанные под современные требования, могут не справиться и стать источником блокировок.
В качестве альтернативы в статье предложено использовать Регистры сведений.
При реализации собственной системы управления интеграциями (СУИ)...
Извините, я упоминал про такой термин, но не упоминал про попытку реализации такой системы. Да, она уже существует, имеет относительно универсальный характер и близка к "полевым испытаниям". Иначе, откуда бы я набрал материала на целых три части этой статьи?.. :-)
Так вот. При реализации собственной системы управления интеграциями (СУИ) я решил оставить реализацию связки сервисов интеграции с планами обмена "на будущее". И то, если возникнет в этом какая-то реальная необходимость.
И начал реализовывать этот блок (регистрации изменений) на регистре сведений. Но и тут с альтернативой в виде справочника.
Зачем? Как ни странно, тесты с массовой записью показали, что запись элемента в справочник происходит несколько быстрее, чем одной записи в регистр сведений - в среднем на 25-30%. Даже с учетом всех приемов, позволяющих ускорить процессы записи платформой.
Это может пригодится для регистрации изменений каких-то отдельных видов документов или справочников, работа с которыми в базе ведется наиболее интенсивно.
Но, каждая медаль, как известно, имеет две стороны. В случае использования регистра сведений для регистрации изменений, процесс очистки "отработанных" регистраций будет происходить уже не на проценты и даже не в разы, а на порядки быстрее, чем в случае использования справочника.
Таким образом, регистрировать изменения в справочнике допустимо только для тех объектов конфигурации, наиболее интенсивная работа с которыми имеет некоторые "технологические окна", когда интенсивность существенно снижается или прекращается вовсе (например, день-ночь). И помещать регламент очистки "отработанных" регистраций именно в эти окна.
В остальном же, работа таких альтернативных подходов в регистрации изменений данных вполне себя оправдывает. Риски получить блокировки минимизируются.
Укрощение "зоопарка" синхронных обменов
Почему мне так не нравится использование синхронных обменов (http- и веб-сервисов) я описывал поподробнее в первой части статьи. Здесь лишь кратко резюмирую, остановившись на двух основных пунктах:
- При недоступности запрашиваемой системы (отправителя) в запрашивающей (получателе) может быть остановлен важный процесс
- При отсутствии интеграционной документации могут быть неизвестны все возможные потребители данных сервиса. Соответственно, при внесении изменений в сервис, какая-то система может "сломаться"
Там же, в первой части, я привожу пример реализации синхронных обменов с помощью Шины, используя http-сервис приложения Шины как обертку для http-сервиса Инфосистемы.
Зачем может понадобиться такой трюк?
Ответ очевиден - для централизации всех возможных интеграций посредством приложения Шины.
Если реализовывать такую централизацию, то, несомненно, придется провести серьезную модификацию программного кода, отвечающего за формирование данных, возвращаемых синхронными сервисами из систем-отправителей. В большей степени это будет рефакторинг, целью которого будет сведение всех возможных http-сервисов в один единственный, который и будет использоваться в обертке сервиса Шины.
То есть, используя дополнительные параметры запроса, можно будет получать из одного сервиса данные, которые получали раньше из разных.
Для чего столько сложностей? Для какой-то "централизации"? Чего она дает?
Если синхронные запросы будут централизованы Шиной, то система управления интеграциями (СУИ) сможет использовать это для целей декларативного описания использования каждого такого единого для отдельной Инфосистемы синхронного сервиса.
Нет, конечно самих сервисов-оберток может быть больше, чем один. Возможно, меньше рефакторить придется. Но тут каждый должен принимать решение на этот счет самостоятельно, опираясь на данные о своих системах и сложность использования в них синхронных обменов.
Что значит "декларативное описание"? Это когда в некой системе вы в виде некоего справочника описываете синхронные запросы, которые можно осуществлять к конкретной Инфосистеме, описываете структуру возможных параметров этих запросов, текстом (для документирования) описываете что эти запросы из себя представляют, что возвращают.
Далее, эта информация используется централизованной функцией в системах-получателях для обращений к сервису и для верификации этих обращений.
Помимо этого, вы получите возможность управлять тем, какие именно системы могут пользоваться этим сервисом.
В итоге, вы получите возможность удобного использование сервиса и документальное его описание, так необходимое при модификациях обменов.
Стоит ли это таких усилий? Решать каждый должен опять сам. Количество синхронных сервисов в каждой отдельной Инфосистеме может быть достаточно большим, чтобы отказаться от такой затеи.
В моем случае принято решение постепенного перевода синхронных сервисов на асинхронные. Опять же - по возможности.
Реализация декларативной работы в СУИ с сервисами-обертками в Шине отложена "на будущее". Это если переделка "на асинхрон" будет в некоторых случаях или невозможна, или исключительно трудозатратна.
Концепция эффективного использования 1С:Шины. Итоги
Так что же необходимо для того, чтобы использование продуктов класса ESB вообще и 1С:Шины, как представителя этого класса, было эффективным?
В каждой системе, которая должна работать с Шиной, необходимо иметь управляющий этой работой программный блок:
- Управляющий формированием, отправкой, получением и обработкой получения информационных сообщений регулярного обмена.
- Поддерживающий требуемый формат сообщений.
- Обрабатывающий возникающие ошибки для предотвращения блокировки каналов.
- Реализующий (желательно) принцип "гарантированной доставки".
- Осуществляющий регистрацию изменений данных
- Осуществляющий построение запросов "пакетных" данных и их формирование и отправку (этот пункт не рассматривался мной в этом цикле статей)
Если систем много и они построены на разных платформах, которых тоже много, то работа предстоит грандиозная!
В некоторых случаях вообще может быть принято решение о нецелесообразности подобных изменений: не трожь то, что работает!
В этом случае тоже есть обратная сторона медали - не трожь, от слова совсем не трожь! При огромном количестве интеграций сверхсложная система становится трудно модифицируемой, неповоротливой. Что, в свою очередь, сказывается на развитии этой системы.
В современном мире все системы стараются сохранять пути своего развития и трансформации. Без этого никуда. Нужно "соответствовать".
Давайте оттолкнемся от чего-то.
Прямо вот все системы, входящие в информационную инфраструктуру, должны иметь такие программные блоки?
Может быть, и нет. Или не так. Не все они должны в обязательном порядке реализовывать все функции, описанные выше.
Некоторые системы вообще могут рассматриваться как второстепенные. Такие системы, в идеале, не должны генерировать никаких "общих" данных и могут выступать только приемниками. И, при этом, принимать ограниченный набор данных - скажем, до трех интеграций.
Остальные наречем основными.
Во второстепенных системах достаточно небольших программных блоков, принимающих и обрабатывающих сообщения, имеющие некий предопределенный формат. Уже чуть проще...
Теперь посмотрим на информационную инфраструктуру с точки зрения используемых платформ.
Если платформ много и представлены они во всем своем разнообразии не только во второстепенных системах, то работы, в любом случае, предстоит много: необходимо реализовывать систему управления интеграциями (СУИ) как отдельную сущность, и, для каждой платформы, использующейся в основных системах, реализовывать собственные программные блоки взаимодействия с СУИ.
То есть, мы предполагаем полную идентичность таких блоков между собой в рамках одной платформы. Иначе совсем уж все грустно будет...
А если разнообразие платформ, использующихся в основных системах, ограничено? Тогда дело приобретает совсем другой окрас!
Случаи, когда в основных системах участвует единственная платформа, можно считать идеальными!
Иногда так и бывает. MDM- и/или CRM-системы снабжают всех потребителей данными НСИ. Некая центральная учетная система (ERP?) является источником данных для систем аналитики, УНФ и/или УТ снабжают данными БП, ЗУП и системы аналитики...
Как-то так получилось, без плавного перехода я пришел к 1С :-)
Ну, вообще-то логично. На ней большинство систем в нашей инфраструктуре и сделано. И в ваших инфраструктурах, скорее всего, тоже, раз вы здесь это читаете :-)
В общем, вывод следующий: если в основных системах используется преимущественно одна платформа, то разработку СУИ вполне естественно делать именно на ней, совмещая в едином программном блоке как, собственно, саму СУИ, так и функции, ею управляемые: регистрацию изменений, формирование, отправку, получение и обработку информационных сообщений. В общем, все то, что описано в начале главы.
При таком подходе на выходе будет единая для большинства ваших систем СУИ, реализующая все необходимые функции. Ее будет относительно легко модифицировать при необходимости и масштабировать.
Конечно же, в каждом отдельном случае возможны собственные решения.
Зарисовка практической реализации концепции на 1С
В моем случае, разработку СУИ и реализацию функций взаимодействия с 1С:Шиной решено было делать именно на 1С.
Правда, есть у нас одна система (СЭД) не на 1С, и она тесно взаимодействует с другими системами, являясь, в том числе, и источником данных для них. То есть, в нашей инфраструктуре она относится к основным системам.
С ней придется "разбираться" отдельно. Но, что уж тут поделаешь. Идеал на то и идеал, что недостижим...
Зато в остальном все представляется вполне осуществимым.
В 1С технически сейчас все есть для реализации подобной затеи: расширения и регламентные задания в них (ждал из-за регламентов 8.3.23).
Если по каким-то причинам нельзя использовать расширения, то внедряем решение в виде отдельной подсистемы в основную конфигурацию.
То есть, разрабатываем весь функционал в виде единого расширения, которое будет интегрироваться в каждую систему 1С.
Если есть "старые" системы на обычных формах, то портируем расширение еще и в отдельную подсистему для основной конфигурации.
Главное, что архитектура и код решения в каждой системе будут абсолютно идентичны, а, значит, само решение будет легко сопровождать!
Расширение (или подсистема) на 1С и проект для приложения 1С:Шины, взаимодействующего с этим расширением, выступают единым решением.
СУИ в решении представляет собой систему настроечных справочников, описывающих все Инфосистемы и интеграции в информационной инфраструктуре.
Так как архитектура решения внутри всех баз 1С идентичная, то никаких проблем с организацией обмена настроечной информацией нет: при ее изменениях в одной системе легко передать их во все остальные через то же приложение Шины, через которое будут передаваться обычные сообщения обмена.
Причем как-то фильтровать эту настроечную информацию и хранить фрагментарно в каждой системе только то, что нужно именно ей, никакого смысла нет. Объемы настроечной информации невелики. Зато в любой системе можно будет увидеть полную картину настроенных интеграций с помощью простейшего отчета по архитектуре СУИ.
Вот только при редактировании этой информации одновременно в двух или более системах можно получить конфликт данных.
Чтобы этого избежать, необходимо ограничить редакцию настроек СУИ только одной системой. Назовем ее мастер-системой.
Только в ней должно быть допустимо редактировать настройки интеграций, в том числе для систем, которые с самой мастер-системой могут быть вообще никак не связаны.
Тем не менее, выбор мастер-системы должен подчиняться определенным критериям. Почему и каким?
Для большей гибкости настроек интеграций можно реализовать в блоке регистрации изменения данных некое подобие правил регистрации, реализованных в БСП. Наиболее просто это может быть реализовано в виде некоего отбора, накладываемого на элементы отдельного объекта метаданных.
То есть, элементы такого-то справочника из такой-то системы должны попадать в другую такую-то систему, но только, если у этих элементов такие-то реквизиты имеют такие-то значения.
Само собой, настраивать в интерфейсе подобные отборы в контексте системы, отправляющей эти данные, наиболее просто.
И логично, что мастер-системой должна быть система, генерирующая наибольший объем "общих" данных, отправляемых в остальные.
Но, как же тогда быть с другими системами, также отправляющими свои данные в другие? Как организовать настройку отборов по ее метаданным?
В общем-то, несложно - включить в состав СУИ специальную обработку, помогающую сформировать отбор в любой системе и передать его в мастер систему для включения в настройки интеграции, например, в виде файла.
Так, правила регистрации изменений настроили. Как насчет самой регистрации?
Как и описывал в этой части статьи, - обращаемся к способу регистрации в регистре сведений или справочнике. Тут ничего особо одаренного нет.
В нашем расширении делаем подписки на события ПередЗаписью и ПриЗаписи ссылочных объектов, регистров сведений и других, подлежащих обмену метаданных. При желании и наличии ресурсов, можно сделать дополнительные проверки на факт изменения объектов, а не просто на факт записи. Если пойти еще дальше, то можно проверять и на изменение конкретных реквизитов объектов.
Ладно, зарегистрировали. Теперь что именно отправлять? Что мы обычно отправляем из баз 1С?
Если получатель - база 1С, то чаще всего это выгрузка КД2 или EnterpriseData (КД3). Если что-то другое, то может быть и XDTO, и XML, и JSON.
Кстати, EnterprseData или, по другому, КД3 очень даже возможно заточить под свои нужды, используя так называемые расширения формата. То есть, добавить в "единый" формат то, что вам необходимо: недостающие сущности данных и реквизиты. И использовать выгрузки КД3 тоже можно не только в базы 1С.
Если тема интересна - обозначьте интерес в комментариях. Постараюсь как-нибудь собраться с силами и написать статейку...но только чуть позже - сериал с Шиной отнял много сил :-)
Вообще, использование КД3 для корпоративных обменов предпочтительней КД2 по причине архитектуры обмена. Один раз настроил формат сущности для передачи в одну систему. Если потом появилась необходимость, то легко настроил выгрузку и в другую. В КД2 для этого придется делать отдельную конвертацию...
Но я опять отвлекаюсь...
Итак, настройки интеграций должны содержать еще и информацию об используемых в каждой интеграции форматах обмена. Чтобы система-отправитель знала как выгрузить данные, а система-получатель - как загрузить.
Вот чего может не содержаться в настройках обмена СУИ, так это описания транспортной системы. Тут у нас все реализует приложение Шины. Сообщение в известном формате, попадая в Шину, само найдет себе путь в системы-получатели через процесс интеграции приложения Шины.
Далее. Информация о форматах обмена должна содержать всю информацию, необходимую для формирования выгрузки данных. Для КД2 - правила обмена, для EnterpriseData (КД3) - версию формата и имя общего модуля выгрузки.
СУИ, обладая всей информацией, должна уметь самостоятельно осуществить выгрузку и дальнейшую отправку данных.
В случае модификации, например, правил обмена КД2, они должны быть загружены в СУИ через мастер-систему, которая передаст эти правила во все остальные.
Можно организовать в СУИ хранение и использование нескольких версий правил обмена для пары отправитель-получатель. Иногда это может быть полезным, если есть одинаковые базы 1С (ЗУП, например), одна из которых уже обновлена на новый релиз, а остальные нет.
Итоги
В общем, "костяк" реализации СУИ я рассмотрел. Дальше можно додумывать самостоятельно, прикручивая управление синхронными обменами, использование существующих регистраций в узлах планов обмена и т.д.
Поле деятельности пока вообще "непаханное"!
Очень надеюсь, что весь "сериал" вам "зашел", а кому-то даже принесет реальную помощь.
Если и не в реализации собственных систем обмена информацией, то, хотя бы, в понимании, нужно оно вам вообще или нет :-)
И если так, то прошу оценить старания! И дать обратную связь под любой частью статьи!
Всем огромное спасибо за внимание! Особенно тем, кто "дожил до конца" :-)
