в чем заключается принцип интеграции в системах

Обзор методов интеграции информационных систем, их преимуществ и недостатков

Рубрика: Информационные технологии

Дата публикации: 11.06.2018 2018-06-11

Статья просмотрена: 12330 раз

Библиографическое описание:

Думченков, И. А. Обзор методов интеграции информационных систем, их преимуществ и недостатков / И. А. Думченков. — Текст : непосредственный // Молодой ученый. — 2018. — № 23 (209). — С. 176-177. — URL: https://moluch.ru/archive/209/51296/ (дата обращения: 02.12.2021).

Развитие информационной сферы повлекло за собой информатизацию общества. В настоящее время активно происходит автоматизация процессов в различных видах деятельности. Яркими примерами являются такие проекты, как «Портал ГосУслуг», «ЕМИАС», «Электронный дневник», которые позволяют выполнять различные действия, такие как оплата коммунальных услуг, запись к врачу, отслеживание успеваемости школьника, не выходя из дома. В связи с этим необходимо понимать, какие из методов интеграции информационных систем являются оптимальными для каждого конкретного случая.

В данной статье будут рассмотрены наиболее популярные и используемые методы интеграции.

‒ Интеграция на уровне брокеров. Преимуществом данного метода является универсальность: как правило, в любой ситуации можно реализовать дополнительный программный модуль, который может обращаться в другие системы различными способами. Например, такой модуль может обращаться к одной системе через базу данных (БД), а к другой с помощью RPC (англ. Remote Procedure Call — Удалённый вызов процедур). Недостатками такого подхода интеграции является трудоёмкость и сложность реализации, и, как следствие, высокая стоимость разработки, внедрения и поддержки.

‒ Интеграция на уровне интерфейсов (физических, программных и пользовательских). Данный вид интеграции разрабатывался как один из видов «лоскутной интеграции», целью которой являлось объединение распределённых программных приложений, реализованных разными разработчиками в разное время, в подобие единой системы. Приложения связывались по принципу «каждый с каждым», что, в конечном итоге, затрудняло их взаимодействие и создавало ряд проблем и ошибок. Также осложнялось использование унаследованных (Legacy Software) и встроенных (Embedded System) систем. Описанный подход интеграции удобен для небольшого количества программных приложений. Для большого числа приложений он является малоэффективным и не обеспечивает построение качественно новых запросов к объединяемым данным. Таким образом, агрегирование данных не принесёт выигрыш. На настоящий момент, проблема интеграции на уровне интерфейсов решается на базе внедрения информационных подсистем, которые реализуются стандартными приложениями с открытыми программными интерфейсами (англ. Open Application Programming Interface, OAPI — Открытый программный интерфейс приложения, Открытый интерфейс прикладного программирования).

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

Недостатком интеграции такого вида является значительная трансформация или комплексный реинжиниринг всей сети процессов, что может повлечь за собой определённые риски. Целесообразно проводить данную интеграцию в случае, если организация готовится к внедрению корпоративной информационной системы (КИС) на платформе популярного решения. Это, в свою очередь, требует унификации и приведения бизнес-процессов к определённому стандарту. Или если организация перестраивает свою деятельность в связи со сменой приоритетов, расширением и освоением новых сегментов рынка.

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

‒ Интеграция при помощи Web-сервисов. Данный вид интеграции является передовым и стремительно развивающимся подходом к интеграции приложений. Он базируется на предоставлении стандартного для Web-служб интерфейса доступа к приложениям и их данным. Примером может являться стандартный протокол доступа к объектам — SOAP (англ. Simple Object Access Protocol — простой протокол доступа к объектам). Так, при помощи SOAP, браузер пользователя может одновременно сравнить данные на нескольких выбранных веб-сайтах и представить клиенту сравнительный отчет. Другой пример: сотрудники одного географически распределенного предприятия могут единовременно использовать корпоративные приложения, доступ к которым осуществляется через соответствующие Web-сервисы (портальное решение). Web-сервисы похожи на подход EAI, но с одним главным отличием — EAI-решения, в своём множестве, выпускаются как частные случаи для связи определённых продуктов. Соответственно, подключить к уже используемому EAI-решению еще одну стороннюю систему будет довольно трудной и длительной задачей. По своей природе Web-сервисы существенно более унифицированы и стандартизованы. Поскольку Web-сервисы базируются на общих и единых для Консорциума Всемирной паутины (англ. World Wide Web Consortium, W3C-консорциум) стандартах, они могут работать везде, где используется сеть Интернет.

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

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

‒ Интеграция на уровне пользователя. Данный вид относится к неавтоматизированной интеграции, и основан на взаимодействии пользователей друг с другом: обмен данными и файлами между системами через ручное копирование, оправку почты и т. д. Является наиболее простыми видом\подходом, и часто применяются в тот момент, когда происходит подготовка внедрения программных систем, а деятельность компании не может прерываться.

Источник

Методы и подходы к интеграции систем

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

Интеграция систем в большинстве случаев – мера вынужденная, направленная на повышение эффективности бизнес-процессов компании, в которых используются информационные системы [http://citcity.ru/16663/].

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

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

Общие подходы к интеграции систем

1. Нет интеграции между системами

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

Это приводит к тому, что менеджеры по продажам после выставления счетов клиентам вынуждены печатать их копии и нести в бухгалтерию. В бухгалтерии они регистрируются в бухгалтерской системе. Бухгалтерия регистрирует поступление денег на счет. Менеджеры по продажам, не имея возможность получить оплаты автоматически в CRM-систему, вынуждены ежедневно осведомляться в бухгалтерии о поступлении денег от клиентов. В такой ситуации присутствует большой документооборот между менеджерами, бухгалтерией и складом, а также двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской).

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

2. Вертикальная интеграция

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

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

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

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

3. Интеграция «многие ко многим» (звезда, спагетти)

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

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

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

4. Горизонтальная интеграция

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

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

5. Отсутствие необходимости в интеграции

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

Объекты и методы интеграции систем

Ранее при описании подходов к интеграции систем мы рассматривали каждую информационную систему как «неделимый» объект. Однако, информационная система представляет из себя совокупность нескольких компонентов, поэтому, говоря об интеграции информационных систем, правильнее говорить об интеграции составляющих их компонентов.

1. Интеграция платформ

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

Концепция хранилищ данных состоит в создании корпоративного хранилища данных. Хранилище данных – база данных, хранящая в себе данные, собираемые из баз данных различных информационных систем, для целей их дальнейшего анализа. Например, может быть создано единое хранилище данных компании, в которое собрана информация из бухгалтерской, оперативной системы, внешних систем партнеров компаний. Для создания хранилищ данных используются технологии (OLAP), отличные от технологий создания оперативных БД (OLTP). В основном это делается для повышения производительности выполнения сложных аналитических запросов по многим параметрам (многомерные запросы). Подходы к созданию и наполнению хранилищ данных отражены в парадигме ETL (extraction, transformation, loading = извлечение, преобразование и загрузка). Технологии и инструментальные средства анализа больших массивов данных с целью выявления закономерностей предметной области объединяются понятием «Data Mining». Термин для совокупности технологий хранилищ данных и инструментальных средств, обеспечивающих перевод транзакционной деловой информации в человекочитаемую форму, пригодную для бизнес-анализа – «Business Intelligence».

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

Интеграция на уровне приложений подразумевает использование готовых функций приложений другими приложениями. Например, разрабатывая систему электронного документооборота, существует возможность использовать в рамках этой системы в качестве текстового редактора MS Word вместо того, чтобы разрабатывать свой собственный текстовый редактор. Или, например, ПО Call-центра, получив входящий звонок от клиента, имеет возможность обратиться к функции биллинговой системы по проверке баланса (на входе – номер телефона абонента, на выходе – его текущий баланс) и, в зависимости от состояния баланса соединить его с оператором или автоматически проинформировать о необходимости пополнить свой счет. При этом структура база данных биллинговой системы является ее внутренней информацией, публикуются конкретные функции, позволяющие другим системам работать с конкретными данными.

Программный интерфейс конкретной системы представляет собой «опубликованный» функционал этой системы, который может быть использован извне. Функционал может публиковаться в виде набора функций (пример – Windows API) или в виде объектной модели (объекты со свойствами и методами, пример – объектные модели приложений Microsoft Office).

В большинстве случае интеграция нескольких систем заключается в передаче информации между ними, например, в форме запрос-ответ. Если системы функционируют в гетерогенных распределенных средах, то принципиальное значение имеет обеспечение гарантированности, безопасности, управляемости доставки информации между приложениями. Эти и другие принципы реализуются в корпоративных системах обмена сообщениями. В данном случае речь идет об обмене сообщениями между приложениями, а не людьми, как, например, в случае E-mail или мессенджеров. Функциональность этих систем достаточно прозрачна – прием сообщения от одного приложения, транспортировка по заданным правилам и передача этого сообщения другому приложению. При этом может производиться шифрование сообщений (для невозможности прочтения данных в процессе транспортировки), цифровая подпись (для защиты от умышленного изменения данных во время пути сообщения), настройка подписки (для отправки одного сообщения сразу нескольким приложениям), определение метаданных для сообщений (для облегчения использования сообщений со сложной структурой содержимого) и др [https://ru.wikipedia.org/wiki/Сервисная_шина_предприятия].

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

Например, в компании (оператор связи) существует система Service Desk (техническая поддержка абонентов) и биллинговая система (тарификация услуг). Перед компанией стоит задача сделать новую систему «Личный кабинет абонента», в которой абонент мог бы через Интернет просмотреть состояние своего счета и сообщить о неисправности. Для этого компания вместо того, чтобы создавать «Личный кабинет» с собственной базой данных, синхронизируемой с БД биллинговой системы и системы Service Desk, использует готовые Web-сервисы «Карточка абонента» (опубликованный функционал биллинговой системы) и «Создать заявку в техподдержку» (опубликованный функционал системы Service Desk). Очевидно, что вся работа по новому приложению «Личный кабинет» состоит лишь в создании Веб-интерфейса пользователя на сайте компании.

Также часто используется следующий подход – интеграция пользовательских интерфейсов. Например, для создания приложений «одного окна». Простейший пример – фреймы на Веб-странице. Внутри каждого фрейма содержится отдельное Веб-приложение. Благодаря фреймам, все эти приложения отображаются на экране одновременно. Пользовательские интерфейсы Веб-приложений легко интегрируются, однако, существуют возможности интегрировать и «классические» пользовательские интерфейсы и их фрагменты (ActiveX).

4. Интеграция бизнес-процессов

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

Источник

Интеграция программного обеспечения. Описание процесса от бизнес консультанта

Синерги́я (греч. συνεργία — сотрудничество, содействие, помощь, соучастие, сообщничество; от греч. σύν — вместе, греч. ἔργον — дело, труд, работа, (воз)действие) — суммирующий эффект взаимодействия двух или более факторов, характеризующийся тем, что их действие существенно превосходит эффект каждого отдельного компонента в виде их простой суммы[1], эмерджентность.

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

Мне постоянно приходится сталкиваться с одними и теми же проблемами и решениями многие из которых приходится пояснять в каждом новом проекте заказчикам, некоторые – программистам. А потому я считаю, что о процессе интеграции стоит поговорить подробно. В большинстве примеров я выбрал различные случаи интеграции 1С и CRM, так как сегодня именно этот вопрос, как показывает моя практика, наиболее актуален. Хотя данная статья подойдет при интеграции практически любого программного обеспечения. Итак начнем.

Интеграция – это очень важная часть работы по автоматизации бизнес-процессов, так как требуется она постоянно. В разных ситуациях возникает потребность оперативно обмениваться данными между различными конфигурациями 1С, между программными продуктами 1С и сайтом, между 1С и CAD системами, а также системами биллинга и т.д. Также достаточно часто требуется интегрировать между собой различные веб сервисы, например, интернет-магазин и CRM-систему. В общем, объединить работу различных подразделений компании и автоматизировать рабочий процесс без использования интеграции в большинстве случаев невозможно.

Что такое интеграция?

Википедия дает нам такое определение:

Я считаю, что в данном случае Вики абсолютно права. И дополнить ее можно только одним определением:

Интеграция программных систем и продуктов — это обмен данными между системами с возможной последующей их обработкой.

Смысл интеграции заключается в том, чтобы данные, которые пользователь вводит в одну систему, автоматически переносились в другую. Продукт, в который пользователь вводит данные, называется источник. А получатель данных, соответственно, приемник.

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

Например, если вы объединяете конфигурацию 1С: Торговля с 1С: Бухгалтерией, вам может потребоваться передать данные по всем продажам в бухгалтерию, а обратно получить сведения об оплате по этим продажам.

Важно: при интеграции различных программных решений нужно хорошо понимать их функционал.

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

В принципе, в процессе интеграции вам может потребоваться и более сложный обмен, и придется вводить, например, трех- или четырехстороннюю интеграцию. Но, по сути, эти процессы ничем не отличаются от обычного одно- или двухстороннего процесса. А потому я буду говорить об интеграции односторонней. А в конце скажу пару слов об особенностях двухсторонней. Все остальные направления вы всегда сможете выстроить по аналогии.

Выбираем источник и приемник

Для каждого случая интеграции данных важно четко определить, какая система будет источником, а какая – приемником.

Например, у вас есть система CRM и программа 1С: Торговля. В обеих системах существует такое понятие, как контактное лицо. В принципе, вводить его вы можете и с одной, и с другой стороны. В данном случае, очевидно, что источником стоит назначить CRM, так как этого требует логика работы с любой CRM-системой.

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

Сопоставление объектов (данных)

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

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

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

Например, при выгрузке контактного лица из CRM нужно четко сопоставить этот контакт партнеру или покупателю.
Также очень важно понимать, какие преобразования потребуются для выгружаемых данных. Например, нужные для интеграции данные в источнике хранятся в качестве перечисления в виде текста. А в приемнике (пусть это будет 1С) аналогичное перечисление имеет ссылочный тип. Следовательно, вам потребуется преобразовать текст в ссылку, и уже ссылку передать в документ.

И здесь возникает проблема: требуются правила сопоставления.

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

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

В результате возникают самые разные казусы. Например, вы используете в качестве ключевого слова для поиска при сопоставлении слово «дилер». Клиент по каким-то причинам меняет его в программе-источнике на слово «дилеры». Казалось бы, мелочь! Но эта мелочь приведет к тому, что поиск в 1С перестанет работать.

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

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

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

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

Обмен данными: писать самому или применять типовое решение?

Лично я предпочитаю всегда разрабатывать решение под заказчика. Здесь можно спорить, можно обсуждать различные варианты, но есть факт: типовые обмены данными всегда сильно перегружены возможностями, которые вашему клиенту не нужны. В результате процесс обмена значительно замедляется, а число возможных ошибок вырастает в разы.

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

А потому при выборе между самостоятельным написанием обмена данными и типовым решением, которое не на 100% подходит для данной ситуации, лучше писать обмен самому.

В некоторых случаях, когда типовое решение действительно на 100% удовлетворяет потребности клиента, а скорость работы для него не критична, я также применяю готовые продукты. Например, при выгрузке номенклатуры и фотографий на сайт я не редко использую готовый обмен данными от Битрикс. Но только для выгрузки. Для работы с заказами я применяю самописный обмен.

Метод подключения: REST API, SOAP или прямое подключение к базе приемника

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

Вопросы клиентского доступа: почему не работает обмен?

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

Вы внедрили интеграцию, все проверили, протестировали, убедились, что система работает. После чего пользователь обнаруживает, что обмен данными не происходит.

В случае работы с CRM-системой ограничения обычно обусловлены оплаченным пакетом услуг. Здесь достаточно оповестить клиента о наличии такого ограничения, и, при необходимости, помочь оплатить и настроить расширенный пакет.

1С идентификаторы и ошибки, связанные с ними

При интеграции с 1С очень часто ошибки обмена данных возникают из-за неверного выбора УИ (уникального идентификатора). Суть проблемы заключается в том, что объекты в 1С имеют два типа УИ: один уникален внутри выбранного типа объектов. Второй используется для работы со всей базой данных.

Если вы будете проводить поиск по всему справочнику с использованием идентификатора, который предназначен для работы внутри определенного типа данных, возникнет ошибка. Объект может быть вообще не найдет, либо система найдет сразу несколько разных объектов. К этой особенности 1С нужно относиться очень внимательно.

Еще одна проблема: нет возможности привязаться к уникальному идентификатору.

Например, системой-источником является сайт, и на нем не предусмотрено отдельное поле для информации о клиенте, она идет в общем тексте заказа. В этом случае придется выбрать какой-то другой вариант идентификации, например, по email.

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

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

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

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

Формат выгрузки

Для обмена данными используются самые разные форматы. Это может быть JSON, XML, CSV, TXT, прямой доступ к базе и т.д. У меня в этом вопросе нет каких-то определенных предпочтений. Я считаю, что здесь нужно исходить из рациональных требований проекта.

Постобработка

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

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

Например, это может быть уведомление клиента о том, что его заказ успешно прошел выгрузку и отправлен в обработку. И здесь также может быть использовано sms, электронное письмо или просто изменение статуса заказа в системе.

Тестирование интеграции

С моей точки зрения интеграция – это часть (иногда частный случай) внедрения программного обеспечения. И здесь, как и для любой другой работы по внедрению ПО, потребуется тестирование программистом, потом – лично консультантом, а также различные варианты тестирования вместе с пользователями. Об этом я подробно писал в статье Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть III. Финальная.

Отличие односторонней и двусторонней интеграции

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

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

Источник