Интеграция систем, CRM и внешних API

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

Две системы и один нужный результат

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

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

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

Когда достаточно готового коннектора

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

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

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

Состав полного обмена

До разработки фиксируем не только технический формат сообщения, но и полный полезный результат:

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

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

Отказ, повтор и неизвестный исход

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

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

Учебный пример и наш опыт

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

Этот пример не является историей внедрения у вымышленного клиента. Собственный опыт серверной разработки показывает другой подтверждённый состав — Text-Flow:

Редактор, серверная часть и сервисы публикации. В работе с материалом учитываются версия черновика и ключ повторной операции.

Описание нашей разработки есть на главной странице. Такой опыт не равен готовому подключению любой CRM: ваши интерфейсы, данные и полный путь приёмки проверяются отдельно.

Что исключено

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

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

Цена привязана к составу

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

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

Поддержка принятого результата обсуждается по отдельному договору. Собственную ошибку в прежнем согласованном задании не переводим в платное дополнительное обращение.

Назовите системы и операцию

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

Первый разговор — бесплатно. Готовое ТЗ не обязательно. Уточним результат и следующий шаг; исследование кода, испытания и полный отчёт согласуем отдельно, если они понадобятся.

Обсудить один обмен или написать на info@aissokol.ru. Можно воспользоваться действующим контактным путём сайта.