Как мы меняли шину данных, а создали интеграционную платформу / хабр

Как достигается интеграция API

В настоящее время существует несколько способов добиться интеграции API. Они в значительной степени зависят от индивидуальных потребностей вашей системы или бизнеса.

Индивидуальные интеграции

Интеграция, созданная на заказ, включает в себя рукописный скрипт от разработчика программного обеспечения с глубоким пониманием и знанием документации API. Этот метод стал популярным несколько лет назад, но стоимость разработки (и текущего обслуживания) сделала его менее привлекательным по сравнению с новыми методами интеграции. Использование этого подхода также может занять очень много времени.

Платформы интеграции API

Обычно это приложения SaaS, предназначенные для разработки интеграций API, которые помогают присоединиться к другим приложениям и системам SaaS.

Они поддерживают определенный уровень гибкости, поскольку вы можете создавать собственные приложения для интеграции, используя надежные инструменты, доступные на рынке. Некоторые, например RapidQL, могут извлекать и преобразовывать данные в форму, понятную вашему приложению, с помощью всего одного запроса. Он позволяет одновременно делать запросы к различным частным и общедоступным API, а также к базам данных.

Эти службы IPaaS также могут позволить вам подключать и объединять несколько API-интерфейсов, что в значительной степени помогает предприятиям автоматизировать свои рабочие процессы.

Быстрое подключение новых партнеров и приложений

Значит, вы знаете, что хотите интегрировать новые приложения и партнеров, но, возможно, вы не знаете, как это сделать сегодня? Существует так много поставщиков, которые продают возможности подключения в виде интегрированных решений iPaaS или API с чистым воспроизведением. Однако интегрированная платформа, основанная на экосистемах, призванная всесторонне разрешить всем вашим партнерам, системам и приложениям целенаправленный процесс, упрощает интеграцию B2B, облачных вычислений и приложений. Такая интеграционная платформа упрощает настройку, предлагает надежную связь между В2В и приложениями, увеличивает время от времени до технологии, позволяя вам быстрее начать работу и сосредоточиться на основных бизнес-задачах.

Вот шесть способов интеграции экосистемной платформы, основанной на экосистемах, значительно улучшает операции:

Бесшовная интеграция: полная передача данных, преобразование данных, согласования и безопасные процессы перемещения
Ускоренной адаптации: ускорение процессов экосистемного бортового транспорта путем автоматического повторного использования шаблона проекта
Сквозной контроль: мониторинг и управление в режиме реального времени всеми обменом данными, перемещающимися по вашей компании
Возможности гибридной интеграции: развертывание и управление интеграцией как внутри, так и в облаке
Управление данными: уменьшите риск дорогостоящих возвратов SLA и наложите штрафные санкции со всем контролем и управлением, которые требует ваш бизнес
Предоставление DevOps: включение лучшей в своем классе инфраструктуры и расширенного управления DevOps для повышения гибкости бизнеса

Platfrom V Synapse — с чего начали

Мы проанализировали возможные варианты и поняли, что паттерн Service Mesh отлично подходит под наши задачи. В Service Mesh за интеграционную обвязку, включая timeouts, retries, circuit breakers и так далее, отвечают конфигурационные файлы. Они поставляются вместе с исходным кодом, подхватываются контрольной панелью и распространяются на все микросервисы, участвующие в миграции через proxy-компонент (в нашем случае — Envoy).

Так как любая миграция — это всегда риск сломать что-то важное, пошли по пути parallel run. Решили оставить старую шину данных, построить рядом новую и добавить «смарт-топоры», которые отслеживают количество ошибок в мониторинге и в нужный момент переключаются на старую шину

Так выглядела исходная идея. Казалось, мы продумали всё: масштабирование, децентрализацию и даже план отката.

Но нас ждали интересные открытия.

Краткое описание

Сервис-ориентированная архитектура и интеграция информационных систем

На сегодняшний день российские предприятия и организации обладают развитыми ИТ-инфраструктурами, многочисленными прикладными системами (бухгалтерские, кадровые, ERP- и CRM-системы, биллинг, другие прикладные программы, в том числе специализированные). Эти ИТ-системы фиксируют достаточно исходной информации для поддержки оперативного принятия решений. Но сложность заключается в том, что эти «сырые», подробные данные нужно быстро собрать и обработать (проконтролировать и проверить, привести к единым форматам, агрегировать и проанализировать), для чего необходимо использовать интеграционные и аналитические технологии.

Кроме того, по мере возрастания числа используемых прикладных систем в предприятиях и организациих на первый план выходит проблема их интеграции: внедрение новых, замена или модернизация существующих требуют, как правило, либо изменения интеграционных связей между ними, либо установления их с нуля. Более того, постоянное развитие бизнеса, бизнес-процессов предприятия приводит к постоянным же изменениям интеграционных связей между приложениями, даже если новые приложения не появляются.

В настоящее время наиболее проработанным подходом к решению проблем интеграции приложений является развитие корпоративной информационной системы (КИС) предприятия согласно концепции сервисно-ориентированной архитектуры — SOA (Service-Oriented Architecture).

Центральным звеном SOA является корпоративная сервисная шина — ESB (Enterprise Service Bus) (хотя корпоративная сервисная шина не обязательно должна использоваться в случае применения сервис-ориентированной архитектуры).

Основной принцип сервисной шины — концентрация обмена сообщениями между различными системами через единую точку, в которой, при необходимости, обеспечивается транзакционный контроль, преобразование данных, сохранность сообщений. Все настройки обработки и передачи сообщений предполагаются также сконцентрированными в единой точке, и формируются в терминах служб, таким образом, при замене какой-либо информационной системы, подключённой к шине, нет необходимости в перенастройке остальных систем.

Интеграция приложений SimpleOne

Продукты SimpleOne легко интегрируются с любыми программами поддержки коллективной работы, ERP-системами и средами виртуализации, программным обеспечением для аутентификации и инструментами повышения производительности.

В SimpleOne для интеграции используется REST API, которое позволяет настраивать как входящее соединение, так и исходящее. Для этого есть два способа.

RESTful API используется для уведомлений в корпоративных приложениях о событиях во внутренней системе. Во внешней системе создаётся бот, который может отправлять сообщения. Во внутренней системе также необходимо провести настройку, определить условия, при которых бот уведомляет пользователей о каких-либо событиях.

Например, вот так могут выглядеть оповещения об инцидентах в Slack:

Пример интеграции со Slack

JavaScript API используется для настройки определённого поведения на какие-то события во внешней системе. Например, система мониторинга сообщает, что перестал быть доступен инстанс. Автоматически система отправляет запрос на сервер, и создаётся уведомление о проблеме с сервером.

Возможность интеграции корпоративных приложений — важная особенность, которая должна присутствовать в любой современной ESM-системе. SimpleOne может выступать единой сервисной шиной для корпоративных систем, поддерживающих REST API, в этом случае SimpleOne будет являться единой точкой агрегации информации из различных корпоративных систем, предоставляя удобные инструменты ее анализа.

Свежее по теме

Счетная палата подвела итоги цифровизации школ за пять лет

Factory5 стала официальным партнером группы «Борлас»

«Ростелеком» помог «ТЭК СПб» автоматизировать сбор показаний с узлов учета энергоресурсов

Ленэнерго заплатит за систему финансов больше полумиллиарда рублей

Интересные ссылки

Softline Ecommerce разработал для «Лаборатории Касперского» инструмент автоматизации продления заказов
ICL Services разработали бота для классификации электронных писем
ВТБ Лизинг провел автоматизацию контакт-центра для повышения качества обслуживания клиентов
Эксперты компании «Системы компьютерного зрения» расскажут об автоматизации подсчета древесины на конференции WoodTech
Softline помогла компании ОМА повысить качество внутренних и внешних коммуникаций

Вместо заключения

Импортозамещение «в лоб» не работает: замена компонентов «один в один» замедляет развитие бизнес-доработок и не даёт никаких преимуществ, нагружая бюджет компании.

Выход видится таким: использовать текущую ситуацию в IТ как возможность глобально пересмотреть архитектуру. Заменить морально устаревшие legacy-решения на современные технологии, которые могут решить ваши боли.

Важно при этом оставить пути для отступления и продумать, как вы будете действовать, если новая технология сломается. А ещё нужно быть готовым к масштабным доработкам, например к тому, что придётся докручивать функциональность, оптимизировать ресурсы и решать вопросы с поддержкой

Конечно, для этого потребуются силы, время и сильная экспертиза. Поэтому, если вы сомневаетесь в собственных ресурсах, обращайтесь к нам — будем рады поделиться опытом и подробно рассказать о своих решениях.

Полная и частичная бизнес-интеграция

Если компания состоит из одного только отдела продаж – достаточно внедрить CRM-систему управления взаимоотношениями с потенциальными и действующими клиентами. В остальных случаях только ей лучше не ограничиваться.

Если компания не только продающая, но и производящая продукт, и уже внедрила CRM, то первый шаг к автоматизации сделан. Остается лишь наладить процесс постановки, выполнения и контроля задач – чтобы они фиксировались не в чьем-то ежедневнике, а в единой системе и выполнялись к назначенному сроку.

Из нашего опыта

В Uplab все задачи фиксируются в корпоративном портале: у каждой задачи есть дедлайн (крайний срок), ответственные, наблюдатели. Не приходится тратить каждое утро массу времени на формирование рабочего плана на день.

Мы долго определялись, какая корпоративная система нам подойдет больше. По многим параметрам выиграл «Битрикс24». Во-первых, он позволяет реализовать все задачи, которые стоят перед нашей компанией. Во-вторых, если какого-то функционала нам недостаточно, мы всегда можем дополнить его инструментами и сервисами, разработанными конкретно под наш бизнес.

Методы интеграции корпоративных приложений

Существует два метода интеграции корпоративных приложений: «точка-точка» и единая сервисная шина. Сейчас мы поговорим о них подробнее и объясним, почему в SimpleOne осуществляется интеграция с использованием единой сервисной шины.

«Точка-точка»

Простейшим способом связывания двух систем является интеграция типа «точка-точка», или простое объединение двух приложений. В таком случае необходимо понять, как взаимодействующие системы будут получать и передавать данные, и создать решение для обращения к этим интерфейсам. В результате такой интеграции возникает обособленный интеграционный модуль с персональными требованиями к обслуживанию и эксплуатации. Когда приложений не очень много, проблем не возникает. Однако в процессе роста ИТ-структуры такое решение принесёт больше проблем, чем пользы.

Интеграция по типу «точка-точка»

Единая сервисная шина

Связующее ПО, обеспечивающее обмен данными между различными информационными системами компании. У такого решения есть масса преимуществ, таких как гибкость, возможность масштабирования и централизация контроля. При этом важным требованием к подобного рода ПО является возможность интеграции с системами других организаций — поставщиками, клиентами, партнёрами.

Интеграция посредством единой сервисной шины

Именно поэтому SimpleOne создаёт единую цифровую среду взаимодействия, которая объединяет разрозненные подразделения и информационные системы. Единая сервисная шина позволяет нашим заказчикам взаимодействовать с любой внутренней системой или внешним сервисом и при этом масштабировать решение по мере роста бизнеса.

Больше информации по теме

Основные сценарии применения сервис-ориентированной архитектуры

Для российской экономики характерны крупные территориально-распределенные компании (холдинги), образовавшиеся в результате слияний и поглощений ранее независимых предприятий и продолжающие претерпевать изменения своей структуры. Эффективное операционное управление таким конгломератом невозможно без создания единого гибкого информационного пространства на базе разнородных унаследованных ИТ-систем
входящих в его состав предприятий.

На уровне ИТ-систем создание единого гибкого информационного пространства холдинга включает решение трех основных задач:

Создание единой точки входа для доступа территориально-распределенных пользователей к интегрированным централизованным приложениям и базам данных.
Интеграция разнородных унаследованных приложений и баз данных и их централизация в корпоративном ЦОД.
Консолидация вычислительных ресурсовхолдинга в корпоративный Центр обработки данных (ЦОД).

Инструментарий SOA, в частности, портал и корпоративная сервисная шина (ESB), является оптимальным для решения первых двух из вышеназванных задач, и значительно повышает эффективность консолидации вычислительных ресурсов.

Управление услугами и обеспечивающими их бизнес-процессами является важнейшей задачей для предприятий и организаций таких сфер деятельности, как телекоммуникации, финансовые услуги, распределение электроэнергии, розничная торговля, транспорт, органы государственной власти, оказывающие услуги населению.

Создание и вывод на рынок новых услуг, собственно оказание услуг потребителям с гарантированным уровнем качества, модификация услуг из-за изменения рыночных условий — является нетривиальной задачей. В том числе и из-за сложности согласования работы задействованных информационных систем, ведь большинство услуг формируются с использованием более чем одной информационной системы, включая и системы сторонних компаний-контрагентов. Поэтому гибкая интеграция этих систем крайне актуальна для сервисных компаний.

Интеграция также важна и в связи с необходимостью повышения оперативности и сокращения затрат по выводу на рынок новых услуг. Для этого нужно, чтобы функциональные возможности существующих информационных систем максимально полно использовались для предоставления новых услуг, минимизируя потребность в покупке или разработке дополнительного функционала. В предельном случае при модификации существующей услуги или создании новой может быть достаточно только существующих информационных систем с созданием (для новой услуги) или перенастройкой (для существующей) интеграционных связей между ними.

Формально работу многих организаций можно определить как обработку множества входящих различных документов, в процессе чего порождаются потоки новых. Эта обработка происходит согласно утвержденным регламентам. Особенно это актуально для предприятий и организаций, имеющих большое количество клиентов и/или поставщиков, производящих широкую номенклатуру продуктов или услуг.

Автоматизация регламентов, документооборота, перевод бумажных документов в электронный вид и организация их хранения в электронном архиве — это актуальный, важный сервис, который должен быть налажен в такой организации. Для качественного предоставления этого сервиса необходима полноценная интеграция приложений, где отдельным компонентом выступает система управления контентом класса ECM (Enterprise Content Management)

Для многих промышленных предприятий не менее важны документы другого типа — конструкторско-технологических данные (КТД), которые порождаются в САПР и в дальнейшем на их основе возникают другие документы, включая административные. В этом случае связка SOA-платформа + ECM дополняется системой САПР. Это позволяет распространить все преимущества и возможности системы документооборота для работы с такими специфичными документами, как схемы и чертежи.

Интеграция 1С с ГИИС ДМДК

ГИИС ДМДК — единая информационная платформа для взаимодействия участников рынка драгоценных металлов и драгоценных камней. с 01.09.21 стартовал обязательный обмен данными с Федеральной пробирной палатой (ФПП) исключительно через ГИИС. А постепенно — с 01.01.2022 и с 01.03.2022 — все данные о продаже драгоценных металлов и камней должны быть интегрированы с ГИИС.
У многих пользователей возникает вопрос как автоматизировать обмен между программой 1С и ГИИС ДМДК.
В настоящей статье ВЦ Раздолье поделится своим опытом о реализации такого обмена.
Автор статьи — Мордовин Антон — архитектор систем на базе 1С Внедренческого центра «Раздолье».

RPC на стороне клиента

Как в этом случае выглядит реализация клиента? В ней строчек чуть больше, но ничего сложного все равно нет.

Мы точно так же мы подготавливаем параметры вызова – номер телефона абонента и текст сообщения.
Создаем объект асинхронного сервиса через подсистему – Сервис.Вызвать().
Больше делать ничего не надо. Дальше мы идем заниматься своими делами.
И потом у вас стартует фоновое задание, в котором вы ждете ответ от сервиса SMS, если он вам нужен.

Предположим, вы хотите отправлять SMS в момент проведения заказа.

Если вы используете синхронный сервис SMS и он не работает, то заказы вы принимать не сможете, и у вас случится простой.
А при использовании асинхронного сервиса отправки SMS все будет работать.

Это очень хорошо работает также с сайтами, когда вам нужно оперативно отражать заказы с сайта в 1С и это должно происходить очень быстро.

Например, на сайте был создан заказ и его нужно сразу же провести в 1С.
Сайт дергает через сервер очередей 1С и продолжает принимать заказы дальше. При этом 1С может находиться очень далеко и связь с ней может быть очень медленная или нестабильная. Но сайт просто делает вызов и когда 1С сможет его обработать, тогда она его и обрабатывает.
Даже если у вас в дата-центре в этот момент пожар, админы восстанавливают бэкапы, никто не работает – на сайте ваши клиенты от вас не убегают, сайт у вас продолжает работать.

В этом весь смысл – развязать системы между собой.

Низкоуровневые методы

Как я уже говорил, в компоненте есть низкоуровневые методы. Если вам недостаточно высокоуровневых абстракций, вы можете построить свои собственные паттерны, используя AMQP в чистом виде.

Дайте две!

Где взять этот замечательный продукт?

Взять его можно на infostart.ru.
Под каждого клиента формируется отдельная персональная именная сборка.
Сюда же входят консультации и техническая поддержка по определенным условиям, которые можно уточнить уже у производителя/
И понятное дело, что мы не одобряем утечки этого инструмента.

Памятка интегратора

Итак, чтобы распутать свою интеграцию, нужно сделать чек-лист.

Обязательно нужно назвать свои потоки данных четкими, понятными именами, чтобы в разговоре с коллегами все понимали, что говорят об одном и том же.
Каждый поток данных атрибутировать и задокументировать эти атрибуты.
Зафиксировать интерфейсы, построить диаграммы обмена.
Внедрить в 1С подсистему Yellow RMQ.
И… наслаждаться жизнью!

Планы по развитию

В первую очередь мы планируем развивать 1С-ную часть.
Планируем поддержать сервер очередей Apache Kafka, который немного другой, чем RabbitMQ, но тоже хороший.
Хотим поддержать современный протокол AMQP 1.0, который пока еще находится в черновиках, но скоро будет опубликован. Там много разных «плюшек», которые мы тоже хотим поддерживать.
И потом хотим поддержать deepstream.io – это немного не про очереди, это про быструю интеграцию.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

Больше статей можно прочитать здесь.

Что у нас получилось: Platform V Synapse спустя 2 года

В Platform V Synapse используются наши собственные сборки open-source-продуктов Istio и Envoy, доработанные до корпоративного уровня, к которым был добавлен большой спектр инструментов:

визуализация трафика;
дополнительные валидаторы, предотвращающие проблемы на стенде из-за возможных пересечений конфигурационных файлов многих команд;
SynAI;
SuperMesh;
DevPortal с набором инструментов для автоматической генерации YAML-конфигов, проведения нагрузочного тестирования, а также с готовыми адаптерами для интеграции с внешними системами, компонентами для реализации логирования и т. д.

Platform V Synapse находится в промышленной эксплуатации в Сбере уже более трёх лет. Мы смигрировали более 4 тыс. сервисов с нашей старой шины данных, средняя нагрузка — более 50 тыс. запросов в секунду. Отказоустойчивость платформы — 99,99%. Сегодня любое взаимодействие с банком, вне зависимости от того, смотрите ли вы баланс в СберБанке Онлайн, переводите деньги или звоните в поддержку, основывается на обмене данных через Platform V Synapse.

Миграция на наше решение позволила Сберу снизить стоимость разработки, в 6 раз сократить TCO, существенно сократить time-to-market и, самое главное, обеспечить фундамент для дальнейшего роста на несколько лет вперёд.

Нужные и важные навыки аналитика

Понимание, что такое API
Понимание основных требований к сервисам
Понимание видов интеграционного взаимодействия (синхронно или асинхронно)
Понимание работы очередей сообщений
Понимание работы шины данных

Хочу успокоить, аналитику не обязательно уметь проектировать все это, но обязательно понимать основные принципы их работы и для чего они необходимы и какие документы что описывают. Эти знания позволяют быстро ориентироваться в информации и находить необходимые сведения.

Что же такое API?

Для начала нужно определить на какие вопросы нам отвечает API:

Как ко мне и к моей системе можно обратиться?
«Ко мне можно обращаться так и так, я обязуюсь делать то и это»

API внешней системы сообщает нам каким образом обратиться к этой системе. При каких случаях на стороне смежной системы запустятся те или иные алгоритмы или процессы, которые зависят от набора переданных параметров. Какие данные смежная система готова возвращать в ответ, в каких случаях от них поступит запрос, и в каком виде необходимо направлять ответ.

Основные требования к описанию сервиса

Сохранение единой структуры сообщения При описании веб-сервиса необходимо сохранять структуру иерархии его объектов. (разработчики опираются на нее при формировании сообщения)

Полнота описания данных по каждому значению будущего сообщения
Идентификатор – системное наименование;
Название – бизнес название
Поле таблицы – источник хранения значения в БД. Записывается через точку (значение.таблица)
Тип данных – числовой, текстовый, справочник, дата и т.д.
Размерность – ограничение по количеству символов

Например, если поле представляет собой «чек-бокс», то его размерность будет единицей для обозначения да/нет/пусто

Обязательность может пониматься, как важность наличия тега даже с пустым значением, или как важность заполнения тега в сообщении

Блок может быть разделен на два значения:
Обязательность для системы 1 (отправителя)
Обязательность для Системы 2 (получателя)

Комментарий – для указания дополнительной информации, при необходимости

Обычно используется два типа сообщений:
Запрос (Request) – исходящее сообщение от Системы 1 в Систему 2
Ответ (Response) – входящее сообщение от Системы 2 в Систему 1 в результате полученного запроса (Request).