Рассказ о том, как сделать интеграцию со сторонними сервисами менее болезненной.
Третья сторона — что это?
При создании сайтов мы, как правило, говорим о разработке двух его частей — внешней (frontend) и внутренней (backend). Всё, что видит в своем браузере пользователь (тексты, ссылки, изображения, видеоролики, анимацию и т.д.), является внешней частью. Чаще всего обычный человек даже не задумывается о том, что происходит за его «окном в Европу». А там ведь много всего: программное обеспечение, разработанное нами, сервер баз данных, web-сервер, мощные компьютеры, гигабайты кода, в конце концов.
Всего этого достаточно для того, чтобы получить сайт. Для нас, программистов, любая разработка несложных сайтов сводится именно к такой модели:
Если же мы разрабатываем не просто веб-сайт, а целую систему, в которой задействованы не только база данных и пользователь, но еще и кассовый аппарат с кассиром, продающим билеты в театр, компьютер менеджера по продажам автомобильных запчастей или платежный сервис, то мы начинаем использовать понятие «третья сторона».
Третья сторона — это некий сервис, находящийся за пределами нашей серверной или дата-центра и призванный подключить к нашей бизнес-логике дополнительные ресурсы. Например, сервис, отправляющий SMS на телефон пользователя, или шлюз, через который происходит резервирование товара на складе поставщика с последующим уведомлением менеджера по продажам.
Как только появляется третья сторона и необходимость интеграции с ней, разработка сайта или любой системы сразу усложняется.
Прежде чем приступать к работе, необходимо тщательно продумать и спроектировать интерфейс взаимодействия — некий язык, на котором все стороны смогут свободно общаться и понимать друг друга.
На запрос отвечают знатоки
В первую очередь необходимо определить, чем будет заниматься третья сторона и чем должен заниматься наш сайт.
Например, рассмотрим процедуру бронирования билетов. Все продажи в этом бизнесе осуществляются через билетную систему, поэтому мы, как и остальные сервисы, должны получать у билетного шлюза всю актуальную информацию.
Или возьмем систему лояльности компании, где пользователь активирует подарочный сертификат, и кассовый аппарат должен «опрашивать» нашу систему, проверяя существование принесенного сертификата.
Иногда требуется не просто обмениваться данными, а «заказывать» у третьей стороны выполнение какого-либо действия. Например, резервировать товары по запросу, отправлять уведомление по запросу и т.д.
Таким образом, любое взаимодействие между системами сводится к структуре «запрос» — «ответ». Запрос отправляет сторона, которой необходимо получить данные, а ответ отправляет сторона, у которой эти данные есть. В IT-терминологии потребитель данных называется «клиентом», а поставщик — «сервером».
Как защитить данные?
Определившись со схемой взаимодействия, необходимо подумать о безопасности данных, которые передаются между сторонами системы.
Вариантов защитить информацию множество. Первый и самый распространенный — использование защищенного HTTPS-соединения. Протокол HTTP — самый распространенный и самый незащищенный. Данные по нему передаются в незашифрованном виде. Для обеспечения безопасности можно использовать шифрование данных, например, с помощью SSL-сертификатов.
SSL-сертификаты в общем виде — это некий алгоритм, по которому будет происходить шифрование данных. Об этом алгоритме знает только клиент и сервер в момент передачи данных. SSL-сертификаты могут поставляться самим сервером, но тогда такой сертификат не будет «доверенным». Для того чтобы сертификат стал доверенным, его необходимо заказывать у организации, занимающейся сертификацией, например, у Ru-center.
Второй способ — использование HTTP-Basic-авторизации. Данные доступа (логин и пароль) должны знать только наша система и сервис третьей стороны. Обмен всеми данными должен происходить после авторизации. Для того чтобы злоумышленник не мог перехватить данные доступа, лучше использовать SSL и HTTP-BasicAuth в связке.
Третий способ — разрешить отправку запросов только с определенного IP-адреса. Наш сервер и сервис третьей стороны находятся всегда по одному адресу, поэтому этот вариант — один из самых распространенных и простых способов ограничения доступа к информации.
Какой протокол выбрать?
Теперь необходимо договориться о формате обмена данными и зафиксировать всё документально.
В большинстве случаев выбор протокола обусловлен количеством данных и частотой их передачи. Я приведу только те, с которыми мы чаще всего сталкиваемся.
Первое и самое простое — это, конечно же, SOAP. Этот протокол наиболее часто используется при обмене структурированными данными в формате XML (специальный язык разметки для обмена данными). Если использовать WSDL (стандарт описания веб-сервисов и доступа к ним), то при использовании SOAP вопрос стандартизации обмена информацией будет также закрыт.
При интеграции с 1С этот протокол легко реализуем, так как в стандартной комплектации 1С уже есть поддержка SOAP, необходимо будет только согласовать WSDL.
У SOAP, к сожалению, есть огромный минус — его XML-специфика. С ростом количества данных непропорционально увеличивается сетевой траффик, а вместе с траффиком растет время чтения и обработки запросов. Кроме того, при каждом обмене требуется обрабатывать и WSDL. Всё это делает протокол SOAP неподъемным для bigdata-систем (системы, оперирующие огромным объемом данных и их значительным многообразием).
Для таких систем вместо SOAP можно использовать REST. Ведь зачем автомобилю пятое колесо, если он прекрасно ездит с четырьмя.
И SOAP, и REST могут работать с HTTP-протоколом, но это, пожалуй, единственное их сходство.
Если в SOAP структура запросов и ответов зависит от WSDL, а статус ответа и формат запроса зашиты в тело запроса, то REST эффективно использует протокол HTTP, максимально задействовав его ресурсы (заголовки, статусы и т.д.). За каждый метод в REST отвечает не отдельно взятая запись в WSDL, а URL, например: http://example.com/rest/user — метод, отвечающий за получение данных пользователя, а вот метод, создающий пользователя: http://example.com/rest/user/create. Все максимально просто и не требуется использования дополнительных протоколов (WSDL, SOAP и т.д.).
Для передачи параметров в REST можно использовать тело запроса, а для описания ошибок — статусные заголовки HTTP. Если учесть, что REST не регламентирует, в каком формате передавать запросы, то можно использовать JSON (текстовый формат обмена данными). JSON — наиболее «сжатый» формат обмена структур в текстовом представлении, поэтому его использование практически полностью снимает вопрос объема данных.
Иногда приходится использовать вариации этих двух моделей взаимодействия.
Так, например, в 1С есть формат CommerceML — XML, предназначенный для передачи коммерческой информации. Чистого CommerceML нам может не хватать, тогда приходится «прикручивать» дополнительный функционал. 1С не предусматривает всех вариантов взаимодействия. Если помимо коммерческой информации есть другие данные, то CommerceML дорабатывается с учетом этого.
Если у клиента нет внешнего сервера для взаимодействия, мы выделяем на сервере отдельную папку, куда 1С сохраняет файлы, которые потом по расписанию разбираются скриптами на нашем сайте. Если нужно регулярно актуализировать данные, мы можем связать Rest API и передачу XML воедино. Тогда 1С будет отправлять XML напрямую на сервер, используя стандартные POST-запросы.
При выборе протокола взаимодействия однозначного решения, к сожалению, нет. Все зависит от задачи. Если мы интегрируем небольшой каталог и какие-то небольшие коммерческие данные с 1С, то нужно использовать CommerceML, если мы интегрируем большие неструктурированные данные, нужно использовать RestFul API, если мы непрерывно обмениваемся данными с третьей стороной, то требуется использовать RestFul API или веб-сервисы.
Все вроде бы хорошо, но...
При реализации процесса взаимодействия трех сторон большинство проблем возникает из-за несогласованности действий. Именно поэтому так важно договориться обо всем, находясь еще «на берегу», и зафиксировать эти договоренности документально.
Часто так бывает, что интеграция проводится с сервисом, по которому уже есть готовая модель взаимодействия. Возможность работы в таком случае каждый разработчик оценивает самостоятельно. Можно взять имеющуюся схему за основу, а можно попросить коллег с другой стороны ее доработать или скорректировать под конкретные нужды.
К сожалению, не получится создать нормально работающую систему, если задействовать ресурсы (знания, умения, специалистов) только с одной стороны. Например, для реализации взаимодействия сайта с 1С нам жизненно необходим 1С-программист со стороны заказчика и менеджер, разбирающийся в особенностях работы бизнеса компании.
Не стоит также забывать, что речь идет о максимально автоматизированной системе, поэтому для нее крайне важно наличие логирования. Не каждый программист при разработке будет знать обо всех случаях использования системы, а логи помогут точно и своевременно определить, на чьей стороне и в какой момент произошла ошибка, а затем устранить проблему.
После реализации взаимодействия необходимо тщательно все задокументировать и в дальнейшем поддерживать документацию в актуальном состоянии. Это поможет избежать ситуации, когда для устранения неполадок приходится знакомиться со всем программным кодом. Даже программист, реализовавший систему, через полгода уже не вспомнит, что и как работает или должно работать, что уж говорить о новых разработчиках.
Также важным моментом является масштабирование системы. Даже если после запуска все работает замечательно, это не значит, что так будет всегда. Рост объемов данных в 50 раз, изменение времени пиковых нагрузок, введение новых законов по ограничению работы сотовых операторов — произойти может все, что угодно. Любую систему взаимодействия необходимо поддерживать и улучшать.
