Ссылки на статьи
Следующие части статьи здесь:
А вот и шина подъехала! Часть 2
А вот и Шина подъехала! Часть 3. Итоги
Ну, не то чтобы только что "подъехала"...
На ИС уже есть публикации по теме:
- Разворачиваем 1С:Шину на Ubuntu и Windows [Шпаргалка]
- Переход с 1С:Шины 2.1.1 на 3.1.1 по Ubuntu [Квест]
- 1С:Шина. Пример синхронизации справочника
- Об 1С:Шине
- Как я из 1С:Шины к MySQL подключался
Со всем уважением к "первопроходцам"... Но!
В большинстве случаев в статьях приводится или достаточно ограниченные примеры использования продукта с трансляцией информации из справки, или техническое описание попыток и проблем установки 1С:Шины или перевода ее на другую версию...
Или я что-то пропустил, или статей, так или иначе раскрывающих назначение и возможности продукта, на ИС еще не было.
Об этом говорят и некоторые комментарии к относительно недавней статье "Об 1С:Шине" - не хватает общего понимания назначения продукта.
Надо отдать должное автору статьи - он зашел дальше всех предыдущих в описании работы с Шиной, включая отладку и преобразование сообщений в проекте Шины. Он также представил свое видение потребности в этом продукте.
Немного теории
Я не хочу копипастить в статью всего того, что о возможных причинах использования 1С:Шины говорит сама 1С. Эта страничка содержит основную информацию для тех, кто вообще не представляет, о чем идет речь, или имеет самое поверхностное представление. "Паучок" на рисунке оттуда призван показать вам, как может использоваться Шина:
Главное, что нужно понять, глядя на эту картинку - совершенно не обязательно иметь у себя в организации все изображенные на ней системы, чтобы внедрение 1С:Шины стало актуальным.
Иногда вполне достаточно иметь две-три базы 1С, которые активно обмениваются различными данными по различным протоколам и управлять этими обменами с какого-то момента становится проблематично...
Все далее сказанное не является истиной в последней инстанции и может и даже должно восприниматься с хорошей долей скептицизма и подвергаться аргументированной критике. Так что, как говорится, - прошу высказываться: лайки и комменты внизу :-)
Я бы хотел остановиться на трех основных, на мой взгляд, моментах, описанных в разделе "Преимущества" на презентационной страничке 1С:
- Единая точка входа/выхода для всех систем
- Удобство администрирования и поддержки
- Гарантированная доставка сообщений
Если действительно возможно реализовать первое "преимущество" для всех или, хотя бы, для большинства возможных интеграций в вашей информационной инфраструктуре, то второе "преимущество" просто вытекает из первого.
Основная функция Шины - транспорт сообщений между информационными системами. И всё!
Некоторые возможности по преобразованию самих сообщений в расчет можно не принимать. Проще и привычней это реализовывать в самих системах или в специальных продуктах типа Конвертация данных 2.
Шина не решает вопросы интеграции "комплексно". Она не обладает волшебной кнопкой "Интегрировать все!". Всю механику обмена, все нюансы перетекания данных из одной системы в другие все равно реализовывают разработчики-интеграторы. И они при этом используют привычные инструменты: КД2, Enterprise Data (КД3), JSON и т.д. и т.п.
Шина же просто должна "правильно" переправить данные, не потеряв их ("преимущество" № 3) и не отправив "не по адресу".
И если потерю данных вроде как предотвращает "гарантированная доставка", то адресацию данных также должен обеспечить разработчик и/или администратор данных.
А если в информационной инфраструктуре организации задействовано более чем две-три различные информационные системы, то и здесь можно дровишек наломать.
Уже всего три системы, активно обменивающиеся несколькими наборами данных по различным протоколам как синхронно, так и асинхронно, используя при этом и КД2, и КД3 и еще что-нибудь, могут породить такое хитросплетение интеграционных потоков, что описать их будет достаточно сложно, а актуализировать описание при доработках нисколько не проще.
Про необходимость документирования разработчики-интеграторы вообще могут не помнить или даже не знать. С одной стороны, потому что интеграционные доработки могут быть не столь частыми (сделал-забыл), с другой - самого первичного описания системы интеграции, которое нужно актуализировать, вообще может не быть или оно может быть в очень невнятном виде.
После нескольких лет работы различных систем и работы с этими системами интеграторов они (системы) так опутываются паутиной "блуждающих данных", что поддерживать да еще и развивать все это становится нетривиальной задачей. Неактуальные уже интеграции зачастую даже не отключаются просто из-за того, что о них никто не помнит, а если и помнят, то не решаются тронуть - "как бы чего еще не задеть"...
Понятно, что на самом деле это все больше к вопросу организации процесса разработки. Если процесс поставлен и четко соблюдается, то подобные проблемы будут минимизированы.
Но, как показывает практика, целостность описания интеграционных систем зачастую имеет достаточно плачевный вид. Особенно в организациях, интеграцию в которых реализуют сразу несколько подрядчиков: с сайтом одни, с ЗУПом другие, с CRM третьи.
Технологии интеграций могут использоваться разные, подходы в разработке разные, отсюда и различие в подходах к описанию систем. Даже если документация предоставляется интеграторами-подрядчиками, то пойди собери все это в кучу и попробуй использовать для анализа когда понадобится что-то модифицировать или добавить...
Даже если говорить только про конфигурации 1С.
Настройка адресации транспортировки информационных сообщений для каждой пары отправитель-получатель настраивается чаще всего в узлах планов обмена в каждой информационной системе-источнике отдельно. Настройка работы различных http-сервисов или веб-сервисов хорошо если хоть как-то описана в данных (константах или регистрах сведений), которые можно изменить. А зачастую можно и в программном коде прямое обращение "по адресу" увидеть...
Тут даже просто найти и изменить источник данных при необходимости может быть затруднительно. А про полноценную настройку тестового контура, если у вас таковой имеется, даже говорить неохота. Это есть страшная головная боль для ответственных за тестовый контур лиц...
И тут вот она - 1С:Шина! Я, говорит, обеспечу вам "Единую точку входа/выхода для всех систем"!
И это, безусловно, уже интересно. Хорошее объединяющее все информационные системы начало. Но само по себе - пока бесполезное...
К этой "единой точке" необходимо еще приложить и некую единую систему управления интеграциями. В которой все достаточно просто и понятно. В которой можно в любой момент получить информацию о том, какими сущностями данных какие системы и в каких направлениях обмениваются. В которой можно легко и в одном месте менять настройки, включать, отключать и перенаправлять информационные потоки. В которой... впрочем, давайте отложим некоторые "хотелки" на будущее.
Также немного отложим общие принципы построения подобной системы: где и как должны храниться ее данные, каким образом участники обмена должны получать от нее информацию, как она должна помогать в маршрутизации информационных потоков и т.п.
Собственно, наличие подобной управляющей системы, как надстройки над приложением Шины, и есть та самая большая, на мой взгляд, проблема, которую придется решать при появлении у вас 1С:Шины.
Или будете опять городить огород из неуправляемой кучи систем с индивидуальными настройками в каждой из них по отдельности и еще немного в Шине.
В итоге выхлоп от Шины будет нулевой, если не отрицательный...
В БСП никаких намеков на подобный функционал я не нашел... а может, так и не найду никогда - есть сервисы интеграции в конфигурации для работы с Шиной и будя с вас...
Значит, писать опять самим :-)
Пока же перейдем, как я и обещал в анонсе, к некоторым практическим моментам, с которыми я столкнулся, экспериментируя с Шиной и сервисами интеграции в 1С. Эти моменты должны помочь в понимании работы Шины и сервисов 1С, с ней связанных, тем кому тема интересна, но он еще не окунался в нее "поглубже"...
Практические моменты
Сообщения обмена данными
Информационные сообщения, которыми обмениваются системы с помощью Шины, в 1С имеют тип СообщениеСервисаИнтеграции, а в самой Шине - СообщениеИнтеграции.
Вдаваться в подробности не буду - для этого есть справка.
Но, если вкратце, в целях быстрого ознакомления...
Помимо, собственно, Тела сообщения, несущего основную его информацию в виде двоичных данных, в сообщении присутствуют свойства адресации КодОтправителя и КодПолучателя, в которых можно задать коды систем-получателей (через запятую) и отправителя (для дополнительной информации получателю).
Если сообщение в схеме приложения Шины дойдет до коннектора, подключенного к группе информационных систем-получателей, то оно будет доставлено только тем из них, коды которых будут указаны в соответствующем свойстве.
То есть, создавая сообщение на стороне отправителя, мы полностью управляем его адресацией.
Но, кроме этого, у сообщения есть свойство Параметры, в которое можно "зашить" любую необходимую получателю или приложению Шины информацию. На стороне 1С это свойство имеет тип Соответствие, в котором ключи и значения должны быть строками.
С помощью зашитой в Параметрах информации можно указать назначение данных, которые несет сообщение, какого формата информация "сидит" в теле, как маршрутизировать сообщение в схеме приложения Шины и т.п.
Таким образом, если при формировании сообщения в системе-источнике есть доступ к неким общим настройкам обмена данными в информационной инфраструктуре, мы можем целиком и полностью снабдить сообщение как настройками адресации, так и дополнительными данными, позволяющими реализовать бизнес-логику обработки сообщения на стороне получателя.
Можно, например, сформировать тело сообщения с помощью КД2 и передать эту информацию получателю, который будет знать что именно с этим сообщением сделать - загрузить с помощью обработки УниверсальныйОбменДаннымиXML.
Собственно, это один из основных моментов, позволяющих объединить все или почти все действия по обмену сообщениями в развитой информационной инфраструктуре...
Несанкционированный обмен
Этот момент, в общем-то, неочевидный. Но сотрудникам организаций, в которых практикуется наличие своего тестового контура или просто создание тестовых баз как копий с продакшена, про него помнить следует.
При настройке параметров сервиса интеграции в базе 1С необходимо указать адрес сервиса интеграции и ключи доступа, выдаваемые приложением Шины, а также включить флаг использования сервиса:
При развертывании копии с базы, в которой все это настроено, в файловую базу или в серверную при не выключенных в ней регламентных заданиях, тестовая база вполне может начать обмениваться с рабочим контуром информацией вместо или даже вместе с "боевой" базой.
Просто потому, что валидные настройки сервисов интеграции продолжают действовать и в тестовой базе без каких-либо проблем.
Для предотвращения подобных коллизий я предлагаю использовать дополнительный параметр, который ориентировался бы на строку, возвращаемую функцией СтрокаСоединенияИнформационнойБазы(), или на ее хеш.
Параметр проверялся бы каждый раз при попытке обмена через сервис интеграции и при обнаружении другой локации базы этот сервис интеграции отключался бы автоматически.
Реализация параметра не важна - константа ли это будет, или некий регистр сведений, или еще что - решайте сами в контексте своей задачи.
Синхронный обмен
Возможен ли синхронный обмен через Шину?
Этот вопрос я слышал чуть ли не на каждом вебинаре, посвященном Шине, на котором присутствовал сам.
Положительного ответа не звучало никогда.
Дело в том, что в Шине "штатный" обмен асинхронный. Подробнее к его нюансам я вернусь во второй части статьи, там тоже есть о чем поговорить...
К теме: реализовать синхронный обмен через Шину все-таки возможно! Подробнее чуть ниже...
Пока же можно поднять вопрос о целесообразности синхронного обмена - нужен ли он в принципе? Уже предвижу возмущенные возгласы "из зала": да как же без него? у нас тут столько http- и веб-сервисов во всех базах по кругу! Это же так удобно: спросил здесь и сейчас соседнюю систему, получил быстрый ответ, реализовал по ответу бизнес-логику и вуаля! Быстро, качественно и недорого)...
Да, конечно, спорить сложно, удобно.
Но реализация синхронного сервиса подразумевает все-таки кое-какие затраты времени разработчиков. А сам сервис подразумевает работоспособность системы в тот момент когда ее спрашивают.
И, если запрашиваемая система недоступна, то текущая операция в запрашивающей системе не сможет быть выполнена. Таким образом, "неработающими" станут уже две системы, пусть одна из них только частично.
Тут вопрос в критичности запрашивающей данные операции - насколько она важна для текущей работы? А если очень важна?
Вот в таких случаях я точно не рекомендовал бы использовать синхронный обмен. И, вообще, без него вполне себе можно обойтись! Как?
Ну, например.
В одной системе порождаются некие документы и вторичная их обработка производится уже во второй системе, в которую они попадают...даже неважно как. Важно, что после обработки во второй системе они должны быть заблокированы для изменения в первой.
Можно при каждой попытке изменения документа в первой системе спрашивать "синхронно" вторую - не обработан ли там этот самый документ?
А можно при обработке документа во второй системе асинхронно отправлять информацию об этом в первую и сохранять там в каком-то блоке данных. Если это 1С, то в регистре сведений, например. Причем в расширении. Что позволит даже не снимать типовую конфигурацию с поддержки.
Ну, и, соответственно, запрашивать нужную информацию в системе нужно уже у "своего" регистра.
Да, есть определенная задержка информации в таком варианте. Но правильной настройкой регламентов обмена, использующихся в 1С для сервисов Шины, можно свести такую задержку чуть ли не до нуля. А в разработке такая система может быть нисколько не дороже разработки синхронного обмена.
Минусом такого асинхронного подхода может являться некоторая избыточность данных - данные о факте обработки документа во второй системе будут храниться дополнительно в первой системе. Но кто в наше время смотрит на дисковое пространство?) Плюс объем этих данных не будет очень уж большим при правильном подходе.
Вернемся к основному вопросу: как, все-таки, можно организовать синхронный обмен данными через Шину?
Обмен этот будет именно что через Шину. То есть, Шина выступит в роли прокси-сервера.
Изобретать http- или веб-сервис в запрашиваемой системе все-таки придется. Ну, или использовать уже готовый.
Как реализовать на практике? Разберем на примере реализации http-сервиса в некой базе 1С.
Предположим, что база эта подключена к некоему приложению Шины. В общем и целом, это, конечно, необязательно. Но если мы не используем шину, то зачем она нам вообще в качестве какого-то прокси? Можно же "спросить" напрямую.
А если используем, то такими синхронными запросами также можно управлять, а заодно и документировать их использование, с помощью все той же единой системы управления обменом данными.
Итак, база 1С подключена к приложению Шины.
Теперь немного трэша со скриншотами и кодом, хотя и не хотел раздувать этим статью (закрываю под спойлер)
Все это, несомненно, имеет право на жизнь. Но, по факту, это костыль, без которого вполне можно обойтись, если использовать все-таки всегда асинхронный обмен.
Продолжение следует...
На этом я завершу первую часть статьи. Она и так получилась несколько больше, чем я рассчитывал.
Во второй части будет продолжено рассмотрение некоторых практических аспектов работы с Шиной и сервисами интеграции в конфигурации 1С. А также вернемся к построению концепции системы управления обменом данными с использованием 1С:Шины.
