Интеграции с маркетплейсами, оборудованием, другими конфигурациями, CRM-системами и сайтами часто оказываются сложнее, чем кажется на этапе проектирования. Работа с ними приносит разный опыт – иногда положительный, иногда болезненный, но по большей части он складывается из набивания шишек. В этой статье разберем основные детали, которые важно учитывать новичкам и тем, кто только приступает к работе с интеграциями, чтобы избежать распространенных ошибок уже на этапе проектирования.
Бардак интеграций
В начале своей карьеры я пришел на проект, где внедрялась система для магазина и оптового представителя, занимавшегося торговлей сантехникой и различным оборудованием. С системой было интегрировано множество маркетплейсов, отдельная CRM-система и сайты.
Эти интеграции были вроде бы автономными, но в то же время иногда переплетались. Из-за отсутствия документации поддерживать и развивать эту систему было очень сложно. В конечном счете все ложилось на группу поддержки, которая часто прибегала в отдел разработки и спрашивала: «А почему у нас все сломалось? Как это исправить?»
Пока система просто работала, всем было хорошо, но любое развитие предвещало очень большое количество человеко-часов. Поэтому я расскажу, как делать не стоит или как я не советовал бы делать, а также как можно организовать все так, чтобы интеграции работали красиво и дружно жили с 1С.
Я разделил статью на две части. Первая часть – это 1С как клиент, когда мы потребляем данные. Вторая часть – 1С как сервер, когда мы уже непосредственно предоставляем данные внешним системам.
Рассказывать я буду на одном эталонном примере. Это был проект розничной сети из 70 магазинов. Заказчик пришел к нам с идеей оптимизировать процессы, унифицировать розничную торговлю и получать как можно больше статистики. При этом основное требование состояло в том, чтобы каждый магазин в этой сети был автономным. Тогда в любой момент его можно было бы отделить от сети, продать или сдать в аренду.
Почему это важно? Потому что данное требование легло в основу того, как центр мог собирать данные. В каждом магазине было по несколько касс, требовались терминалы сбора данных и другое основное оборудование.
1С как клиент
Что мы рассматривали в качестве вариантов? Первое, что приходит в голову, когда мы думаем о том, как забирать данные, – это типовые решения: синхронизация однородных программ либо распределенные информационные базы, если мы говорим об однородных базах.
Но типовые решения не очень подходили из-за требования автономности. Поэтому нужно было разрабатывать собственный формат обмена, собственную интеграцию и уходить в разработку требований, поскольку система также была доработанной.
Ошибка 1. Файловый обмен
Файловый обмен – очень простой и легко настраиваемый вариант. В подобном кейсе мы реализовывали его через FTP-сервер, и центр всю ночь забирал данные из множества магазинов.
Минусы такого подхода состоят в том, что мы не можем забирать данные быстро, файлы могут быть заблокированы, а кроме того, возникают все возможные ошибки, характерные для файлового обмена. Поэтому при проектировании интеграции я советовал бы избегать работы с файлами.
Ошибка 2. Зацикливание обмена
Когда мы проектируем логику обмена данными, не стоит забывать, кто является потребителем, а кто – продюсером наших сообщений. Здесь важно учесть, чтобы две стороны не передавали друг другу одни и те же данные.
К чему это обычно приводит? К тому, что учет рушится, а поддержка не может справиться с наплывом сообщений, если системе оставили возможность самостоятельно обмениваться данными в том порядке, в котором она захочет.
В основном это ошибка проектирования. Она быстро устраняется, но сделать это хорошо получается не всегда.
Ошибка 3. Надежда на ответственность пользователей
Нельзя проектировать решение так, чтобы интеграция была завязана на ручные действия пользователя. У пользователя не должно быть необходимости нажимать множество кнопок. Он также не должен иметь возможность влиять на обмен между системами или вручную вводить данные, чтобы этот обмен запустить.
Здесь основная причина кроется в том, как выстроена работа с пользователями и заказчиком. Необходимо предоставлять документацию, которая позволит пользователю работать автономно и не зависеть от системы. При этом пользователь не должен влиять на созданную нами интеграцию.
Как избежать ошибок проектирования
В первую очередь необходимо анализировать бизнес-процессы и учитывать цель, которую решает интеграция. Клиенты обычно смотрят на все с позиции того, что им нужно прямо сейчас, а мы при этом не закладываем решений для будущего развития системы. Если упустить этот момент, масштабировать и развивать ее будет очень сложно.
Необходимо учитывать, какие системы могут появиться в дальнейшем. Здесь важны специфика бизнеса и особенности обслуживания клиента. Это позволит заложить возможность развития нашей интеграционной системы.
К чему мы пришли в описанном кейсе? Мы использовали интерфейс OData, который позволил нам оперативно получать данные об остатках и движении товаров. Центр при этом отдавал только минимальные данные об изменении цен.
На этапе, когда 1С выступает потребителем, необходимо учитывать возможные последствия и разные сценарии: что будет, если наш сервис упадет, что произойдет, если пользователь ошибется, и так далее. Эти вопросы нужно прорабатывать и закладывать ответы на них в техническое задание.
1С как сервер: предоставление данных внешним системам
Система развивается, и мы добавляем новые интеграции. Теперь центральной 1С нужно отдавать данные дальше.
В приведенном примере у клиента помимо розничной сети открылся интернет-магазин. Он существовал уже некоторое время, но был отделен от общей учетной системы. Нам было необходимо интегрировать центр с сайтом и системой «Комплексная автоматизация», в которой было очень много доработок и которой тоже нужно было каким-то образом получать данные.
Разрабатывать правила обмена самостоятельно с нуля и снова использовать типовые средства 1С не представлялось возможным, потому что это было экономически невыгодно. Поэтому нам требовалось создать собственный API. При его разработке мы учитывали опыт предыдущих создателей систем и то, что уже находилось у нас на поддержке.
А на поддержке у нас было множество клиентов с сайтами, которые получали данные по API.
Первое, что нужно учитывать, – это несогласованное изменение данных, которые мы отдаем, в том числе возможное изменение объектов метаданных.
У нас был случай, когда мы в спешке изменили ключи, по которым API забирал данные. Речь шла о справочнике номенклатуры. В результате обмен с сайтом упал, а обнаружили эту ошибку только спустя два дня. На сайте исчезла возможность создавать заказы, потому что закончились остатки.
Разбирательство тоже шло не очень быстро. В итоге мы чуть не потеряли клиента и немного испортили свою репутацию.
Главная ошибка была в проектировании и в том, как мы в принципе организовали работу. Отсутствие документации и несогласованные действия с другими командами приводят к подобным историям.
Версионирование API
К чему мы пришли после этого и что использовали в следующем кейсе? Мы внедрили версионирование API. В нашем случае версия указывалась в заголовках, но ее также можно было указывать в URL. Главное, чтобы версионирование существовало.
Что оно нам дает? Возможность откатиться и проработать алгоритм безопасных изменений. Этот алгоритм разбивается на три этапа.
Первый этап – расширение. Мы договариваемся с бизнесом и другими командами и дорабатываем API с учетом того, что будут добавлены новые поля или изменены типы объектов, которые мы отдаем. При этом старая версия все еще работает, а новую мы тестируем.
Далее мы уведомляем другие команды о том, что новая версия готова и теперь им нужно подстроиться под нас. Мы планируем переход вместе с другими командами и ждем.
Когда подходит срок перехода на новую версию, мы информируем об этом другие команды и проверяем, кто еще обращается к нашему API. Если другие команды не готовы, мы оттягиваем срок и сдвигаем дедлайн. Это позволяет избежать инцидентов, которые могут возникнуть в дальнейшем.
Безопасность API
Следующее, что мы проработали, – безопасность API.
В первую очередь необходимо всегда использовать отдельных пользователей для каждого внешнего сервиса. До этого у нас были случаи, когда использовалась учетная запись сотрудника. Сотрудника увольняли, пользователь становился неактивным, и API просто переставал работать.
Отсюда вывод: для каждого внешнего сервиса мы создаем отдельного пользователя API.
Также необходимо использовать аутентификацию – желательно через токены либо через логин и пароль – и обязательно устанавливать защищенное соединение. Незащищенное соединение легко скомпрометировать. В результате можно столкнуться, например, с тем, что на экранах в магазинах появится свастика, как это произошло в одном из наших кейсов.
Решение проблемы было небыстрым, а клиенты остались недовольны. Поэтому в новых проектах защищенное соединение используется обязательно.
Не стоит забывать и о логировании всего, что происходит в обмене. При возникновении любой проблемы, расследовании инцидентов или разборе сценарных ошибок без достаточного объема логов становится трудно что-либо выяснить и улучшить. Мы неизбежно потеряем какие-то важные нюансы.
Ограничение запросов
Следующее, о чем стоит поговорить, – ограничение запросов. Это тоже связано с безопасностью.
Таким образом мы защищаем систему от непреднамеренных или намеренных перегрузок и обеспечиваем ее стабильность. Можно рассмотреть несколько уровней организации защиты.
Первый уровень – веб-публикация на базе Nginx или IIS, где ограничения можно прописать в конфигурации. Также их можно реализовать на уровне самой 1С или еще глубже – на уровне нашего кода.
Что это дает? Защиту от возможных DDoS-атак и от ситуаций, когда пользователь каким-то чудом нажал кнопку и запросил все данные, накопленные в базе за год.
Документация и тестирование
В разработке мы используем документацию OpenAPI и mock-серверы для тестирования.
Документация очень важна. Желательно составлять ее непосредственно в процессе разработки, чтобы информацию видели и знали не только мы сами и чтобы она не хранилась исключительно в наших головах. Смежные команды и потребители тоже должны иметь возможность обратиться к этой документации, не тратя свое и наше время на разбор вопросов, ответы на которые знаем только мы.
Mock-серверы необходимы для тестирования. Тесты интеграций обычно проходят проблематично, потому что команды работают асинхронно и разработка одной команды может не успевать за разработкой другой. Поэтому необходимо тестировать решение до того, как оно выйдет в продакшен.
Три принципа надежных интеграций
Первое – начинайте с цели. Для чего это нужно бизнесу? Куда мы вообще идем? Чего от нас ожидает заказчик?
Второе – необходимо управлять жизненным циклом интеграции и не пускать все на самотек. Не нужно поддаваться быстрым желаниям клиента и внедрять в систему непродуманные решения.
Третье и, наверное, самое сложное – необходимость договариваться с другими командами, а не диктовать им свои условия. Роль аналитика – быть переводчиком между бизнесом и смежными командами.
Работать с интеграциями достаточно интересно. Можно дополнительно рассмотреть, какое окружение бывает у интеграций, какие объекты и где необходимо использовать при проектировании, а также как связать несколько интеграций воедино, чтобы систему было легко поддерживать и развивать.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
