автоматическая интеграция что это

Интеграция корпоративного приложения с внешними системами

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

Интеграции в корпоративных приложениях

Корпоративные приложения получают, обрабатывают и передают данные. Зачастую для выполнения одного бизнес-процесса компания использует несколько информационных систем, и между ними происходит обмен данными. Одна система получает информацию от пользователя и передаёт в другие через каналы интеграции. Например, для авторизации на сервисном портале пользователь не создаёт новую учетную запись: система получает данные из Active Directory, а приложение контроля доступа загружает справочник сотрудников из базы данных ERP SAP.

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

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

На смену этим архаичным и неудобным способам интеграции пришли современные технологии, использующие API (интерфейсы прикладного программирования) для связи веб-приложений. Разработчики создают свои информационные системы с API-интерфейсами, чтобы приложения могли взаимодействовать и передавать данные друг другу. Существуют два основных стиля API — SOAP и REST, они имеют различные архитектуры, но в большинстве случаев используют общий транспорт — HTTP-протокол.

Технологии интеграции

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

SOAP — протокол, REST — архитектурный стиль

SOAP (Simple Object Access Protocol) — отлично стандартизированный и давно используемый протокол. Это одна из причин, по которой его выбирают как API корпоративных приложений. Он работает поверх протоколов HTTP, SMTP, TCP или UDP, но передаёт данные только в формате XML. Для устаревших систем и тех, которые производят сложные транзакции, а также предъявляют высокие требования к безопасности, SOAP всё ещё хороший вариант. Он широко применяется в банковских и других финансовых приложениях, CRM, коммунальными службами и при оказании телекоммуникационных услуг. Там, где важна стабильность и целостность данных, используют SOAP, например, работа светофоров, канализации и электроснабжения города должна всегда выполняться безотказно и предсказуемо. Возможность асинхронной передачи данных по SMTP делает этот протокол незаменимым для интеграции в системах с нестабильным каналом связи.

REST (REpresentational State Transfer) — довольно молодой, но очень популярный архитектурный стиль для создания интеграционных API. Он приобрёл популярность у разработчиков в 2018 году, и на текущий момент большинство интернет-сервисов его используют как общедоступный API-интерфейс. Twitter, WordPress, Google Maps и другие известные приложения имеют REST API для взаимодействия с другими веб-сервисами и пользовательскими сайтами.

Для обмена данными REST использует только HTTP в качестве транспортного протокола, но форматы сообщений могут быть любыми — HTML, JSON, XML, YAML или простой текст. Универсальным является формат JSON (JavaScript Object Notatio): его легко анализировать, у него простой синтаксис и он не зависит от языка программирования. В JSON используется меньше слов, его проще писать и читать, такие сообщения имеют меньший вес, поэтому скорость их передачи выше, чем с XML.

REST — простой, удобный и универсальный способ интеграции корпоративных приложений, в большинстве случаев веб-сервисы RESTful могут взаимодействовать с любыми другими сервисами.

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

Для чего нужны коннекторы

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

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

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

Способы интеграции в SimpleOne

Интеграция SimpleOne с другими корпоративными приложениями настраивается через REST API, интерфейс позволяет создавать, читать и обновлять данные в таблицах платформы.

REST-клиент

Чтобы связать стороннее приложение с SimpleOne, администратор должен в редакторе REST-запросов (REST Client) создать запрос к внешнему сервису (REST Request), а также запланировать его регулярное исполнение. В панели администрирования создаётся REST-запрос, для него указывается заголовок, дополнительные методы запроса и их параметры при необходимости, а также профили аутентификации.

Настройку REST-запросов и REST Bot Engine может выполнить администратор платформы с помощью GUI без глубоких знаний API и навыков программирования.

Настройка REST API в SimpleOne: пример настройки запроса для интеграции co Slack Настройка REST API в SimpleOne: пример настройки заголовка запроса Настройка REST API в SimpleOne: пример настройки дополнительных методов

Коннекторы

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

REST API

ESM-платформа SimpleOne предлагает задокументированный набор готовых операций с данными для взаимодействия сторонних систем с нашей платформой посредством REST API.

Scripted REST API

Когда готовых методов для работы сторонней системы с данными SimpleOne недостаточно, можно создать свои собственные сценарии обработки запросов с помощью инструмента Scripted REST API. Для этого достаточно создать новый модуль API, с помощью low-code-инструментария настроить действия и параметры, после чего связать параметры запросов к API с созданными модулями и действиями.

Это позволит настроить сложную логику обработки REST-запросов от внешних систем.

Заключение

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

Источник

Способы интеграции с 1С

Какие важнейшие требования предъявляются к бизнес-приложениям? Одними из самых главных являются следующие задачи:

Интеграционные задачи

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

Возможности интеграции с 1С

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

Механизмы интеграции в платформе 1С:Предприятие

Импорт/экспорт файлов

Предположим, перед нами стоит задача двунаправленного обмена данными между приложением 1С и произвольным приложением. Например, нам нужно синхронизировать список товаров (справочник Номенклатура) между приложением 1С и произвольным приложением.

Для решения такой задачи можно написать расширение, которое выгружает справочник Номенклатура в файл определенного формата (текстовый, XML, JSON, …) и умеет считывать этот формат.

В платформе реализован механизм сериализации прикладных объектов в XML как напрямую, через методы глобального контекста ЗаписатьXML/ЧтениеXML, так и с помощью вспомогательного объекта XDTO (XML Data Transfer Objects).

Любой объект в системе 1С:Предприятие может быть сериализован в XML представление и наоборот.

Эта функция вернет представление объекта в виде XML:

так будет выглядеть экспорт справочника Номенклатура в XML при помощи XDTO:

Путем несложной переделки кода экспортируем справочник в JSON. Товары будут записаны в массив; для разнообразия приведем англоязычный вариант синтаксиса:

Далее останется только передать данные конечному потребителю. Платформа 1С:Предприятие поддерживает основные интернет-протоколы HTTP, FTP, POP3, SMTP, IMAP, включая их безопасные версии. Также для передачи данных можно использовать HTTP и/или Web-сервисы.

HTTP- и веб-сервисы

Приложения 1С могут реализовывать свои HTTP- и веб-сервисы, а также вызывать HTTP- и веб-сервисы, реализованные сторонними приложениями.

REST интерфейс и протокол OData

Так, URL вида http:// / /odata/standard.odata/Catalog_Номенклатура вернет нам содержимое каталога Номенклатура в формате XML — коллекцию элементов entry (заголовок сообщения пропущен для краткости):

Прибавляя к URL-у строку «?$format=application/json», получим содержимое каталога Номенклатура в формате JSON (URL вида http:// / /odata/standard.odata/Catalog_Номенклатура?$format=application/json ):

Внешние источники данных

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

Механизм обмена данными

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

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

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

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

Внешние компоненты

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

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

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

Устаревшие механизмы интеграции

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

Другой устаревший механизм интеграции – использование технологии COM (доступно только на платформе Windows). Платформа 1С:Предприятие предоставляет два способа интеграции для Windows, использующие технологию COM: Automation-сервер и Внешнее соединение. Они очень похожи, но одним из принципиальных отличий является то, что в случае Automation-сервера запускается полноценное клиентское приложение 1С:Предприятие 8, а в случае внешнего соединения запускается относительно небольшой внутрипроцессный COM-сервер. То есть в случае работы через Automation сервер можно задействовать функционал клиентского приложения, выполнять действия, аналогичные интерактивным действиям пользователя. При использовании внешнего соединения можно использовать только функции бизнес-логики, причем их можно выполнять как на клиентской стороне соединения, где создается внуприпроцессный COM-сервер, так и осуществлять вызов бизнес-логики на стороне сервера 1С:Предприятия.

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

Механизмы интеграции, реализованные в типовых конфигурациях

Формат EnterpriseData

В ряде конфигураций 1С (список ниже) на основе описанного выше платформенного механизма обмена данными реализован готовый механизм обмена данными с внешними приложениями, не требующий изменения исходного кода конфигураций (подготовка к обмену данными делается в настройках прикладных решений):

Обмен данными между приложением 1С и сторонним приложением может происходить:

Квитирование сообщений

Приложения 1С ведут учет отправленных и полученных сообщений синхронизации и ожидают того же от сторонних приложений. Это позволяет задействовать механизм нумерации сообщений, описанный выше в разделе «Механизм обмена данными».

Приложения 1С в ходе синхронизации передают только информацию об изменениях, произошедших с бизнес-сущностями со времени последней синхронизации (чтобы минимизировать объем передаваемой информации). При первой синхронизации приложение 1С выгрузит все бизнес-сущности (например, элементы справочника номенклатуры) в формате EnterpriseData в XML-файл (поскольку все они являются «новыми» для внешнего приложения). Стороннее приложение должно обработать информацию из пришедшего от 1С XML-файла и при следующем сеансе синхронизации поместить в файл, отправляемый в 1С, в специальную секцию XML, информацию, что сообщение от 1С за определенным номером успешно принято. Сообщение-квитанция является для приложения 1С сигналом, что все бизнес-сущности успешно обработаны внешним приложением и информацию о них передавать больше не нужно. Помимо квитанции XML-файл от стороннего приложения также может содержать данные для синхронизации со стороны приложения (например, документы реализации товаров и услуг).

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

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

Упрощенный обмен данными без квитирования

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

Специализированные интеграционные решения

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

Интеграция с банковскими решениями

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

Источник

Интеграции: как настроить передачу данных, если вы не программист

Мы email-агентство и каждый день ищем идеальную интеграцию для клиентов. Идеальной не нашли, но свод правил для упрощённого поиска составили.

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

Существуют приложения, которые облегчают бизнесу работу. Это сервисы смс- и email-рассылок, «ловцы лидов» в соцсетях, кол-трекинги, CRM… Все они по-своему полезны, но у всех есть недостаток — настроить между ними автоматический обмен данными непросто.

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

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

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

Интеграция — это объединение разных систем и элементов в единую среду. Пример — интеграция платформы для рассылок Mailigen с сервисом аmoCRM.

Ключ API — секретный код, который идентифицирует учётную запись. Он открывает сторонним сайтам и программам доступ к информации пользователя. Используя эти данные, сервисы могут интегрироваться.

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

Webhooks — механизм оповещения о событиях. Как правило, он запускается каким-то событием, например, комментарием в блоге. Когда событие происходит, исходный сайт отправляет HTTP-запрос на URL-адрес, указанный для Webhooks.

AMP — технология, делающая рассылки интерактивными. В AMP-письме можно покупать товары, оставлять комментарии, бронировать отель и т. д. без перехода на сайт. Пример — комментарии к статьям в Google Docs. Ответить на них можно прямо в письме.

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

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

Приведём пример интеграции для сбора лидов:

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

В первую очередь нужно было сделать одностраничный сайт с формой подписки. Для этих целей мы выбрали сервис Tilda. Сделали такой лендинг:

Нашей задачей было передавать данные из подписного лендинга в рассыльщик Mailigen, но прямой интеграции между ним и Tilda не было. На помощь пришёл Zapier. Это сервис, который помогает без знаний кода интегрировать сервисы. В нём более тысячи приложений, между которыми можно настроить интеграцию.

Использовав API-ключи, мы связали Mailigen и Tilda с Zapier, настроили интеграцию внутри Zapier, и лиды стали приходить в заранее созданный в Mailigen список. На настройку ушло меньше часа.

Совет: что учесть, если вы решили использовать Zapier для интеграции c Tilda?

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

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

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

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

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

Рынок постоянно растёт и развивается. Вместе с ним меняются и сервисы. Ищите тот, который идёт в ногу со временем.

Например, сейчас активно развивается новая технология на рынке email-маркетинга — AMP. Сервис Stripo является одним из первопроходцев по популяризации этой технологии. К сожалению, не все ставят AMP в приоритет. Например, почта Яндекса (по крайней мере в августе 2020, когда мы писали эту статью) не дружит с Accelerated Mobile Pages — пользователи попросту не видят интерактивных элементов в письмах.

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

Задайте прямой вопрос: «Какие действия и в каком объёме от меня потребуются, чтобы выполнить интеграцию с сервисом X?». Получив ответ, вы сможете сопоставить возможности с поставленными задачами.

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

Баги, косяки и недопонимание — всё это будет усложнять вам настройку. Избежать этого невозможно, потому что идеальной интеграции не существует. К тому же у каждого приложения свои протоколы работы и политика безопасности. Потому приготовьтесь, что легко не будет. Мы предупредили 💁‍♂

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

История из нашей практики. Нужно было объединить два сервиса: Carrot quest и amoCRM. У них была заявлена полная интеграция, но на этапе подключения мы столкнулись с проблемой — не было склейки контактов по ID. Такие проблемы встречаются часто. С помощью разработчика со стороны клиента интеграцию доработали, и она год работала без сбоев.

Но в один момент в CRM посыпались неправильные лиды, стали создаваться ошибочные сделки. Разобраться удалось далеко не сразу. Причину всё же нашли — оказалось, проблема в обновлении amoCRM, из-за которого возникли ошибки. Интеграцию пришлось отключить.

UPD: Связка обновлена, но мы ещё не тестировали новую версию.

Клиент интегрировал Bitrix24 и Unisender через API, чтобы отправлять сервисные сообщения. Проблемы начались, когда он отправил первые письма.

Как и у всех сервисов рассылок, в Unisender есть свои механизмы защиты репутации IP-адресов и клиентов. Один из них — глобальный список отписки. Это список клиентов, которые отписались от всех рассылок из сервиса, независимо от компании.

Оказалось, что часть подписчиков нашего клиента есть в этом списке. Логично, что писем они не получили. Отправить реподписную кампанию по таким контактам невозможно, ведь люди отписаны. Доказать, что клиент хочет получать рассылки, можно только если подписать его через форму подписки Unisender — а для этого их нужно попросить зайти в эту форму не через письмо (напоминаем, письма не доставляются).

Предугадать такую проблему невозможно. Но нужно быть готовым к тому, что придётся решать вопросы с внутренними правилами сервисов.

У каждого сервиса своя система отчётов. Обратите внимание, есть ли все необходимые для анализа данные и можно ли их выгрузить в полном объёме.

В первую очередь обратитесь в поддержку всех звеньев интеграции. Опишите проблему как можно подробнее, приложите скриншоты. Дождитесь ответа. Как правило, на этом этапе решаются 80% проблем.

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

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

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

Источник