Предприятие любого уровня нуждается в программном обеспечении, отдельные компоненты которого будут синхронно работать из любой точки. Для этих целей и проводится интеграция программных модулей. Далее рассмотрим более подробно виды, цели и уровни интеграции программных модулей.
Цели и задачи
Интеграция – процесс разработки и внедрения программного обеспечения, с помощью которого отдельные компоненты могут быть связаны в единую систему. Такое объединение позволяет поддерживать бизнес-процессы и оперативно обмениваться информацией.
Главная задача процесса – обеспечение безопасного и бесперебойного обмена информацией между программными продуктами, которые изначально не предназначены для совместной работы. Например, программное обеспечение для электронного документооборота между предприятием и его клиентами, организация цепей поставок, ERP-системы, облачные технологии, аналитические модули, системы самообслуживания и т. д.
С помощью интеграции программных модулей обеспечивается не только оперативность и автоматизация работы с данными. Решается ряд более широких задач:
Что такое интеграция
- оперативное внедрение новых программных продуктов в работу предприятия;
- улучшения качества работы с клиентами;
- прозрачность процессов;
- сокращения количества ошибок при обработке данных и т. д.
Принципы работы
Прежде, чем настраивать интеграцию модулей, нужно определиться с принимающей и передающей стороной – источником данных. Если изначально источник информации не определен, сделать это нужно до начала загрузки данных в систему, так как в ней могут присутствовать приложения с идентичным функционалом. Например, ПО 1С: Торговля и любая стандартная CRM позволяют вносить данные контрагентов. Разрозненный ввод повлечет за собой проблемы задвоенных данных, их несвоевременную синхронизацию, потерю и т. д.
Возможна и двусторонняя интеграция. В этом случае источник и принимающая сторона могут меняться.
Одно из главных преимуществ интеграции программных модулей – постоянный доступ к обновляющимся данным. Именно за счет этого удается создавать инструменты и сервисы, которые оперативно адаптируются под конкретные задачи.
Основной принцип работы процессов – взаимодействие модулей друг с другом, каждый из которых выполняет конкретную задачу. При завершении работы одного из компонентов все обработанные данные должны быть оперативно синхронизированы с другими модулями и доступны для дальнейших действий.
Чтобы гармонично объединить все элементы системы, важно придерживаться следующих принципов.
Настройка API
API – комплекс правил, на основании которых взаимодействуют отдельные части ПО. Именно за счет API программистам удается оперативно настроить компоненты, предупредить и устранить возможные ошибки в работе модулей.
Запись на программу интеграции 사회통합프로그램
Настройка событийных действий
Настраивается специальный комплекс действий, которые запускаются после произведения другого, заранее определенного действия. Например, при завершении оформления заказа клиентом система автоматически генерирует ему счет на оплату, то есть одно действие является триггером для последующего.
Сопоставление данных
Правильная настройка обмена данными между разными модулями системы позволяет ускорить обмен и синхронизацию данных.
Виды интеграции
В зависимости от цели внедрения интеграцию, в первую очередь, подразделяют на внутреннюю и внешнюю. Внутренняя подразумевает добавление конкретных программных модулей без привлечения внешних ресурсов. Внешняя интеграция позволяет внутренние процессы синхронизировать с более глобальными, например, подключение к Google Maps для логистических компаний.
Доступны 3 вида интеграции:
- облачная;
- локальная;
- гибридная.
Каждый из видов, в свою очередь, различается по следующим методам:
- На уровне брокеров. Данный вид интеграции считается универсальным. При необходимости задействуется дополнительный модуль – брокер. Он подключается к другим необходимым модулям. Такой вид интеграции считается сложным в реализации, требует определенных знаний.
- На уровне интерфейсов. Целью данного вида интеграции изначально было объединение разноплановых приложений. Сложность такого типа в последовательном подключении элементов. Это вызывает ряд ошибок в процессе взаимодействия. К тому же часто встречаются Legacy софт.
- На уровне сервисов. Здесь при помощи программного обеспечения осуществляется фиксация данных и интерфейсов с двух сторон. Это один из немногих видов неавтоматизированной интеграции, то есть участие человека здесь остро необходимо.
- Функционально-прикладная и организационная интеграция. Ключевым моментом здесь является объединение нескольких схожих или однотипных приложений. Этот вид наиболее удобен для крупных предприятий, корпораций. Именно за счет интеграции этого вида удается снизить затраты на обслуживающий персонал, так как практически все процессы максимально доступны.
- Корпоративные программные приложения. Здесь используются не только приложения внутри системы, но и сам исполняемый код. Специализированное ПО и API позволяют использовать отдельные компоненты приложений в единое ядро. Такую систему легче администрировать и масштабировать при необходимости. Доступ к ядру осуществляется при помощи стандартных протоколов доступа, например, SOAP.
Взаимодействие интегрированных модулей
Интеграция программных модулей включает в себя задачу обеспечения оперативного взаимодействия всех входящих в систему компонентов. Не всегда удается достичь нужного взаимодействия полностью автоматизированным способом.
Обмен данными
Обмен актуальной информацией внутри одной системы – одна из главных задач интеграции программных модулей. Чем проще будет настроена форма обмена, тем быстрее будет происходить обмен. Следует учитывать, что для разных задач может использоваться разный формат данных: pdf, xls, CSV и др. Дополнительным преимуществом будет возможность интегрировать модуль для автоматической загрузки и выгрузки данных.
База данных
Все интегрируемые приложения в системе должны иметь доступ к единой базе данных. Это может вызвать некоторые сложности. Не всегда есть возможность оперативно определить какой-либо конкретный модуль. Все компоненты системы тесно переплетены и образуют один общий привязанный к единой базе элемент внутри системы. Помочь в такой ситуации может дополнительная интеграция модулей для работы с базами данных.
Удаленный вызов
В каждом из модулей интегрированной системы прописываются специальные протоколы. Благодаря им удается задать команды для сообщения между несколькими модулями, то есть для того, чтобы два или несколько компонентов оперативно выполнили одну задачу, первый должен отправить удаленный вызов второго и последующих.
В таком взаимодействии есть очень существенный недостаток. Чтобы не нарушать единовременную синхронизацию всех данных, важно следить за тем, чтобы все системы внутри предприятия в одно и то же время были включены в работу. Если отследить одновременный запуск всех систем не представляется возможным, подобную интеграцию следует рассматривать внутри небольших организаций. Здесь за результативность процесса отвечает человек. Автоматизировать удаленный вызов в системах большего масштаба пока не удалось.
Асинхронный обмен сообщениями
Принцип асинхронного обмена сообщениями внутри одной системы – наиболее оптимальный вариант автоматического взаимодействия модулей. При таком принципе одно из интегрированных приложений просто отправляет запрос другому. При этом не нужно ждать ответа от принимающего приложения. Все запросы доставляются и обрабатываются им в порядке очереди.
Организация маршрутов взаимодействия
Кроме способов взаимодействия особое внимание следует уделить непосредственной организации маршрутов. Различают 2 подхода:
- прямое взаимодействие – точка-точка;
- звездообразная архитектура – хаб-спицы.
От выбранного маршрута напрямую зависит скорость и легкость обмена данными внутри системы.
Точка-точка
Этот подход характеризуется прямым взаимодействием. «Точка-точка» считается самым простым подходом и чаще всего используется для передачи большого объема данных. Важно следить за тем, чтобы приложения использовали одинаковые методы сообщения друг с другом. Изменение интерфейса взаимодействия одного элемента неизбежно повлечет за собой перенастройку всей системы. Кроме этого возможны замедления в работе системы, так как есть риск попасть в момент репликации данных.
Хаб-спицы
Ключевым моментом взаимодействия приложений при подходе «хаб-спицы» является наличие единого центрального узла. Он сам организует взаимодействие между интегрированными компонентами при помощи различных протоколов и методов, контролирует базу данных системы. Приложения связаны с хабом и не взаимодействуют друг с другом. Преимущество такого подхода заключается в отсутствии необходимости модифицировать всю систему, если приходится изменять работу одного из приложений.
Интеграция программных модулей – сложный процесс, требующий определенных знаний на каждом этапе его разработки, внедрения, запуска, дальнейшего использования и обслуживания. Поэтому важно уделить внимание не только задачам, которые стоят перед внедрением. Любая работа по внедрению программного обеспечения включает в себя обязательное тестирование и дальнейшее обучение пользователей.
Источник: dynamicsun.ru
Интеграции: как настроить передачу данных, если вы не программист
Если вы бизнес и контактируете с клиентами не только в режиме реального времени (например, у вас шаурмичная у метро), вам приходится работать с большим количеством данных. Обработать всю информацию и ничего не забыть практически нереально. А в 2020, если не настроить автоматическую пересылку данных из одного сервиса в другой, маркетинг не будет достаточно эффективным.
Существуют приложения, которые облегчают бизнесу работу. Это сервисы смс- и email-рассылок, «ловцы лидов» в соцсетях, кол-трекинги, CRM… Все они по-своему полезны, но у всех есть недостаток — настроить между ними автоматический обмен данными непросто.
Омниканальность стала реальностью — если действия всех каналов общения с клиентом не связаны, вы недополучаете прибыль. Только из-за того, что ваша коммуникация не персонализирована и не учитывает всех факторов и точек касания. Теоретически все сервисы можно интегрировать между собой. Фактически — есть много подводных камней, о которых лучше знать заранее.
Разбираемся, зачем нужны интеграции, на что обратить внимание, какие бывают проблемы и о чём спросить у техподдержки.
Мини-словарь терминов, которые помогут вам во всём разобраться
В статье встречаются понятия, которые помогут вам быстрее сориентироваться, если вы их раньше не слышали. Дадим их краткое определение.
Интеграция — это объединение разных систем и элементов в единую среду. Пример — интеграция платформы для рассылок Mailigen с сервисом аmoCRM.
Ключ API — секретный код, который идентифицирует учётную запись. Он открывает сторонним сайтам и программам доступ к информации пользователя. Используя эти данные, сервисы могут интегрироваться.
HTTP — это протокол передачи данных, необходимый для передачи гипертекстовых документов. Под гипертекстовыми документами, в свою очередь, понимают документы, которые могут содержать ссылки на другие документы. HTTP позволяет пользовательскому приложению и веб-серверу обмениваться данными. Благодаря протоколу возможна работа Интернета.
Webhooks — механизм оповещения о событиях. Как правило, он запускается каким-то событием, например, комментарием в блоге. Когда событие происходит, исходный сайт отправляет HTTP-запрос на URL-адрес, указанный для Webhooks.
AMP — технология, делающая рассылки интерактивными. В AMP-письме можно покупать товары, оставлять комментарии, бронировать отель и т. д. без перехода на сайт. Пример — комментарии к статьям в Google Docs. Ответить на них можно прямо в письме.
Задача и варианты интеграции
Итак, вам нужно настроить автоматическую передачу информации между сервисами. Есть три способа, как это сделать:
- Зайти на сайт сервиса, который вас интересует, и проверить, есть ли у него прямая интеграция с платформой, с которой вы хотите его соединить. У крупных сервисов, как правило, такое есть. Плюс: скорее всего, интеграцию писали внутренние специалисты, потому она сделана качественно. Минус: обычно интеграций немного.
- Прописать интеграцию с программистами. Плюс: вы можете сами прописать необходимые условия передачи данных. Минусы: это долго, сложно и не факт, что окупится.
- Использовать универсальный онлайн-конструктор интеграций. Например, Zapier. Плюс: множество сервисов, которые можно объединить, и для этого достаточно знать только ключ API. Минус: это программа, которую вы не можете доработать.
Подходящий способ нужно подбирать в зависимости от ваших целей: как быстро и насколько глубокая нужна интеграция.
Приведём пример интеграции для сбора лидов:
Клиент хотел собрать лиды в базу для рассылок, но по определённым причинам не хотел использовать для этих целей основной сайт. При этом он хотел быстро увеличить базу.
В первую очередь нужно было сделать одностраничный сайт с формой подписки. Для этих целей мы выбрали сервис Tilda. Сделали такой лендинг:
Лендинг Агентство email-маркетинга CХЕМА
Нашей задачей было передавать данные из подписного лендинга в рассыльщик Mailigen, но прямой интеграции между ним и Tilda не было. На помощь пришёл Zapier. Это сервис, который помогает без знаний кода интегрировать сервисы. В нём более тысячи приложений, между которыми можно настроить интеграцию.
Zapier Агентство email-маркетинга CХЕМА
Использовав API-ключи, мы связали Mailigen и Tilda с Zapier, настроили интеграцию внутри Zapier, и лиды стали приходить в заранее созданный в Mailigen список. На настройку ушло меньше часа.
Совет: что учесть, если вы решили использовать Zapier для интеграции c Tilda?
- Интеграция с Tilda пока находится в бета-версии. То есть она доступна только по ссылке. Возможны баги.
- Чтобы не пропустить ошибки, придётся создать аккаунт в Zapier с указанием рабочей почты, чтобы хотя бы раз в день кто-то её проверял. Так вы вовремя узнаете, если интеграция сломалась, и сможете быстро решить проблему.
Как выбрать сервис с учётом интеграции?
Вам предстоит попробовать новое направление, например, рассылки (они нам ближе). Вам нужно не только найти сервис, который удовлетворит все ваши потребности в письмах, но и посмотреть, если ли у него интеграция с вашей CRM или CMS, подумать, как вы будете собирать подписчиков на сайте, решить, как и через кого вы будете делать поп-апы, и т. д. Вы выбираете, предположим, рассыльщик. Вот на что нужно обратить внимание.
1. Репутация и востребованность в профессиональном сообществе
Если сервис малоизвестный, скорее всего, вы столкнётесь с бесконечными задержками в решении вашего вопроса. Или вообще не получите от техподдержки обратной связи. Это впустую потраченное время, а время, как мы знаем, — это деньги.
2. Функционал
Убедитесь, что у сервиса есть все функции, которые нужны вам сейчас или могут понадобиться в будущем. Переход от одной интеграции к другой может быть лёгким в самом начале, но потом, когда вы уже потратили время и силы на текущую интеграцию, может быть долго и трудно.
3. Прямая интеграция
Если хотите пойти по пути наименьшего сопротивления, ищите сервисы, которые уже интегрированы между собой. Если у них уже есть двухсторонняя связка, с настройкой интеграции возникнет меньше проблем и потребуется меньше сложных действий с вашей стороны.
Прямая интерация сервисов
4. Виджеты и сервисы-посредники
Если прямой связки между сервисами нет, поищите сторонние решения. Возможно, с их помощью вы сможете решить ваши задачи без привлечения IT-специалистов. То есть, если есть виджеты или сторонние сервисы, вам не придётся отказываться от понравившегося сервиса, даже если у него нет прямой интеграции.
5. Современные решения
Рынок постоянно растёт и развивается. Вместе с ним меняются и сервисы. Ищите тот, который идёт в ногу со временем.
Фрагмент AMP-письма
Например, сейчас активно развивается новая технология на рынке email-маркетинга — AMP. Сервис Stripo является одним из первопроходцев по популяризации этой технологии. К сожалению, не все ставят AMP в приоритет. Например, почта Яндекса (по крайней мере в августе 2020, когда мы писали эту статью) не дружит с Accelerated Mobile Pages — пользователи попросту не видят интерактивных элементов в письмах.
Прежде чем принять решение, изучите раздел помощи сервиса. Он должен быть подробным и актуальным. Если создатели приложения не удосужились подготовить раздел помощи по своему детищу, чего тогда ждать от поддержки?
О чём спросить техподдержку, чтобы определиться с сервисом?
Задайте прямой вопрос: «Какие действия и в каком объёме от меня потребуются, чтобы выполнить интеграцию с сервисом X?». Получив ответ, вы сможете сопоставить возможности с поставленными задачами.
Оцените, насколько активно вам отвечают и достаточно ли хорошо погружаются в вашу проблему. Поверьте, отзывчивая техподдержка — первый шаг к успешной интеграции.
Какие возможны подводные камни?
Баги, косяки и недопонимание — всё это будет усложнять вам настройку. Избежать этого невозможно, потому что идеальной интеграции не существует. К тому же у каждого приложения свои протоколы работы и политика безопасности. Потому приготовьтесь, что легко не будет. Мы предупредили ♂
Первый камень. Баги
Самая досадная и в то же время распространённая проблема. К сожалению, о ней невозможно узнать заранее, потому что баги происходят внезапно.
История из нашей практики. Нужно было объединить два сервиса: Carrot quest и amoCRM. У них была заявлена полная интеграция, но на этапе подключения мы столкнулись с проблемой — не было склейки контактов по ID. Такие проблемы встречаются часто. С помощью разработчика со стороны клиента интеграцию доработали, и она год работала без сбоев.
Но в один момент в CRM посыпались неправильные лиды, стали создаваться ошибочные сделки. Разобраться удалось далеко не сразу. Причину всё же нашли — оказалось, проблема в обновлении amoCRM, из-за которого возникли ошибки. Интеграцию пришлось отключить.
UPD: Связка обновлена, но мы ещё не тестировали новую версию.
Второй камень. Внутренние правила и установки сервиса
Клиент интегрировал Bitrix24 и Unisender через API, чтобы отправлять сервисные сообщения. Проблемы начались, когда он отправил первые письма.
Как и у всех сервисов рассылок, в Unisender есть свои механизмы защиты репутации IP-адресов и клиентов. Один из них — глобальный список отписки. Это список клиентов, которые отписались от всех рассылок из сервиса, независимо от компании.
Оказалось, что часть подписчиков нашего клиента есть в этом списке. Логично, что писем они не получили. Отправить реподписную кампанию по таким контактам невозможно, ведь люди отписаны. Доказать, что клиент хочет получать рассылки, можно только если подписать его через форму подписки Unisender — а для этого их нужно попросить зайти в эту форму не через письмо (напоминаем, письма не доставляются).
Статусы подписчиков
Предугадать такую проблему невозможно. Но нужно быть готовым к тому, что придётся решать вопросы с внутренними правилами сервисов.
Третий камень. Проблемы со статистикой
У каждого сервиса своя система отчётов. Обратите внимание, есть ли все необходимые для анализа данные и можно ли их выгрузить в полном объёме.
Что делать, если возникли проблемы с сервисом?
В первую очередь обратитесь в поддержку всех звеньев интеграции. Опишите проблему как можно подробнее, приложите скриншоты. Дождитесь ответа. Как правило, на этом этапе решаются 80% проблем.
Если решить проблему не удалось, подключите тыжпрограммиста человека из IT-сферы, если он у вас есть. Если его нет, скажите об этом техподдержке — пусть они подключат технического специалиста, который доступно вам всё объяснит. Не стесняйтесь задавать вопросы, даже если они кажутся вам глупыми.
Вместо итога
Интеграции — дело сложное, но очень полезное. Да, мы тоже столкнулись с трудностями, когда решили впервые связать сервисы. Но поверьте, оно того стоит: передача информации из разных приложений между собой позволяет автоматизировать процессы и освободить уйму времени для других задач.
Идеальных сервисов и интеграций не существует. Но вы можете найти решение, с которым будет минимум проблем. Или можете доверить дело нам. Поможем интегрировать сервисы и сделать ваш бизнес более прибыльным.
Источник: vc.ru
ТЗ на интеграцию информационных систем: 5 главных вопросов аналитика
Системные и бизнес-аналитики довольно часто участвуют в проектах интеграции информационных систем. Сегодня рассмотрим, с чего начать предпроектное исследование, чтобы успешно разработать требования к интеграции и оформить их в виде технического задания (ТЗ) по шаблонам российских ГОСТ’ов (34.602-89 и 19.201-78) или международных стандартов спецификации. Также разберем, чем пакетный парсинг отличается от потоковой передачи событий и каковы сложности интеграции нескольких информационных систем с разными моделями данных.
Что такое интеграция информационных систем: краткий ликбез для бизнес-аналитика
Когда речь идет об интеграции информационных систем (ИС), под этим подразумевается односторонняя передача или взаимный обмен данными, которые в них хранятся. Выполнять такую передачу или обмен данными будет программное обеспечение (ПО), внешнее по отношению к связываемым информационным системам, или внутренние компоненты их самих.
Как именно это будет происходить, решает ИТ-архитектор или ведущий разработчик, который отвечает за техническое решение. Чтобы корректно разработать требования к реализации такого ПО, аналитик должен понимать ключевые аспекты интеграции, которые мы и рассмотрим далее. С учетом современной тенденции российского (и не только) рынке к слиянию ролей системного и бизнес-аналитика, такой краткий ликбез по интеграции информационных систем пригодится начинающим специалистам обеих профессий. Итак, разработать требования к интеграции помогут точные ответы на следующие 5 вопросов.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
24 июля, 2023
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.
Зачем?
Поскольку любое исследование в бизнес-анализе начинается с определения потребности, неудивительно, что «Зачем?» – это первый вопрос при интеграции ИС. Зная ответ, аналитик сможет определить полезность и нужность, т.е. ценность интеграции для бизнеса: решает ли она реальную проблему и действительно ли эту проблему стоит решать.
Например, сотрудники компании тратят 2 часа рабочего времени на внесение данных из одной информационной системы в другую. Зная количество этих сотрудников и их почасовую ставку, нетрудно рассчитать экономию от автоматической передачи данных между разными системами. Это и будет ценность интеграции в денежном выражении. Сопоставив потенциальную выгоду интеграции с затратами на ее реализацию, можно сделать выводы о периоде окупаемости интеграционного решения и его целесообразности. Подробнее о бизнес-проблемах, их причинах и следствиях мы говорили в прошлой статье.
Кроме того, понятные ответ на вопрос «Зачем нужна интеграция ИС» поможет определить сценарии обмена данными между ними, причем как в плане бизнес-процессов, так и с технической точки зрения. Иначе говоря, «Зачем?» является главным и первым вопросом аналитика в любом проекте, позволяя определить дальнейший путь выявления требований к решению и ключевые аспекты его реализации. В техническом задании на разработку ПО для интеграции информационных систем или спецификации требований ответ на вопрос «Зачем?» располагается во введении или разделах, которые описывают назначение и цели создания программного продукта.
Сколько?
Хотя главным вопросом для бизнеса являются деньги и то, что с ними связано, здесь речь идет не о стоимости интеграционного решения, а о том, какое количество ИС необходимо связать между собой. Если нужен обмен данными между всего 2-мя «коробочными решениями», а бизнес не планирует строить полноценную инфраструктуру данных, добавляя десятки специфических ИС для поддержки различных процессов и направлений деятельности, то границы проектируемого интеграционного ПО могут располагаться внутри 2-х связываемых систем. Когда речь идет о создании корпоративной дата-магистрали, к которой подключено много ИС, при разработке ТЗ аналитику нужно тщательно проработать требования к внешним интерфейсам, которые будут обеспечивать многосторонний обмен данными.
На основании этих требований и особенностей самих связываемых систем ИТ-архитектор принимает решение о модели интеграции. Например, это может быть общая шина предприятия (ESB, Enterprise Service Bus) с очередью сообщений, набором коннекторов к источникам и приемникам данных, а также объединяющей программной платформы.
Или реализация CDC-подхода, когда с помощью триггеров отслеживаются и обрабатываются изменения в базах данных прикладных систем (Change Data Capture), сливаясь в единое корпоративное хранилище (DWH, Data WareHouse). Или же обмен данными по запросу через удаленный вызов процедур из одной системы и обращение к конечной точке другой методами RESTful-API. Подробнее о способах интеграции ИС с технической точки зрения мы поговорим в следующий раз. А пока отметим, что при разработке ТЗ или спецификации требований информация о количестве связываемых ИС и их архитектурных особенностях будет отражена в разделе «Ограничения дизайна и реализации».
Какие данные?
Этот вопрос касается структуры данных, которыми будут обмениваться связываемые системы. Каждая ИС имеет свою модель данных – чаще всего она является реляционной, где информация структурирована в связанные таблицы. В реляционной модели каждая таблица имеет заранее определенное количество столбцов для хранения данных конкретного типа: целочисленных, символьных и пр.
Некоторые СУБД поддерживают не только реляционную парадигму – они называются NoSQL и хранимые в них данные могут иметь различную структуру, например, как JSON-файл со множеством ключей. Поскольку каждая ИС имеет свою уникальную модель данных, интеграция – это не просто передача записей (или значений отдельных полей) из одной таблицы в другую. Поэтому в функциональных требованиях к интеграционному решению аналитик указывает, какие данные будут передаваться, в каком виде они изначально хранятся в источнике и как будут ложиться в приемник. При этом в функциональные требования также включается преобразование значений, например, приведение к единообразной форме отображения адресов, личных данных клиентов или названий предприятий.
Например, в одной системе адрес хранится в одном поле таблицы строкового типа, а в другой – разбит на несколько отдельных полей с разными типами данных: индекс, область, город, улица, номер дома, корпус, квартира. В этом случае интеграционное решение будет выполнять синтаксический анализ (парсинг) исходных данных, чтобы выделить разные значения из единой строки и записать их в различные поля модели данных системы-приемника.
Аналогичный парсинг будет выполняться и для сложных типов данных в случае интеграции нескольких систем, например, при разборе сообщений, хранящихся в очереди корпоративной ESB-шины. Описать данные, которыми будут обмениваться интегрируемые системы, а также сопоставить компоненты одной модели данных и другой поможет техника под названием «Словарь данных», которую мы недавно разбирали здесь. В дополнение к этому будет полезно показать источники и приемники данных с процессами их преобразования. Сделать это можно с помощью диаграмм потоков данных (DFD, Data Flow Diagram), которые мы разбирали в этой статье.
Источник: babok-school.ru