Третий лишний?

Третий лишний?

Рассказ о том, как сделать интеграцию со сторонними сервисами менее болезненной.

Третья сторона — что это?

При создании сайтов мы, как правило, говорим о разработке двух его частей — внешней (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 раз, изменение времени пиковых нагрузок, введение новых законов по ограничению работы сотовых операторов — произойти может все, что угодно. Любую систему взаимодействия необходимо поддерживать и улучшать.



  • Как самостоятельно настроить учет данных о рекламных расходах в Google Analytics с точностью до копейки

    Если вы тратите деньги на рекламу в интернет, можете ли вы с точностью до копейки сказать, сколько потратили за сегодня или за прошлую неделю? А сколько переходов получили за эти деньги? Или к каким продажам это привело?

    Мы в своих проектах такой учет ведем. И сегодня генеральный директор агентства интернет-маркетинга «Топ Спот», входящего в нашу группу компаний, Дмитрий Губанов написал специально для vc.ru колонку с практическими советами о том, как автоматизировать учет данных о рекламных расходах в Google Analytics.

  • Итоги уходящего года

    2015 год подходит к концу, и мы по традиции подводим итоги и вспоминаем всё, чего достигли за это время. А достижений было немало!

  • Как победить в схватке за кадры с лидерами индустрии?

    Издание Cossa.Ru опубликовало статью Валерия Комягина о том, как противостоять хантингу со стороны IT-гигантов. В издании вышла редакционная версия материала. Мы, в свою очередь, публикуем «режиссерскую версию» текста, не подверженную цензуре.

  • Мы в десятке лучших разработчиков интернет-магазинов Москвы

    Мы в десятке лучших разработчиков интернет-магазинов Москвы

  • Перестаньте делать обычные сайты. Адаптив — это не страшно

    Перестаньте делать обычные сайты. Адаптив — это не страшно

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

  • Тэглайн 2015: +22 позиции в рейтинге ведущих digital production России

    Тэглайн 2015: +22 позиции в рейтинге ведущих digital production России

    Крупнейшее аналитическое агентство Тэглайн опубликовало рейтинг ведущих разработчиков Рунета. В этому году мы поднялись сразу на 22 позиции и заняли итоговое 71 место.

  • Презентация к докладу «Ключевые показатели digital-производства»

    Все говорят, что в студийном бизнесе важно следить за показателями эффективности. Но никто не говорит, за какими именно. На РИФ+КИБ 2015 мы рассказали о личном опыте внедрения базового управленческого учета. Публикуем презентацию к этом докладу.

  • Эволюция: из маленькой веб-студии в опытного интегратора

    Мы быстро поняли, делать простые сайты — невыгодно. Конкуренция возрастала, рынок наводнялся небольшими компаниями. Всё это привело к снижению цен на проекты и падению прибыльности бизнеса.

  • Сказ о том, как старый год провожали

    Однажды решили добры молодцы и красны девицы Студии Комягина праздник себе устроить. Да не простой, а корпоративный новогодний. Стали снедь собирать да в путь-дорогу собираться.

  • Как это было: новый логотип и фирменный стиль Студии

    Как это было: новый логотип и фирменный стиль Студии

    В этом году Студии исполнилось 15 лет. Всё это время мы прожили с логотипом, придуманным в 2002 году первым арт-директором и совладельцем компании Олегом Нагурским. Настало время его поменять.

  • Срочно... в вёрстку!

    Срочно... в вёрстку!

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

  • Стратегическое партнёрство с Caparol

    2014 год для нашей компании становится знаковым сразу по нескольким причинам. В этом году Студии исполнилось 15 лет. Для веб-разработчика, с учётом молодости самой индустрии, это солидный возраст. Когда мы начинали в 1999 году, Рунету было всего 5 лет, а веб-студий по стране насчитывалось не больше сотни.

  • Интервью SeoPult

    Интервью SeoPult

    25 сентября состоялись съемки интервью Вaлерия Комягина для SeoPult.TV. Публикуем видеозапись передачи.

  • Браузеры в браузере

    Браузеры в браузере

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

  • Еженедельные планерки...

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

  • Как выбрать подрядчика для создания сайта? Часть 2

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

  • «Цель» Элияху Голдратта

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

  • Как выбрать подрядчика для создания сайта? Часть 1

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

  • Первый опыт на Yii

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

  • Мобильное приложение хоккейного клуба «Динамо» доступно в App Store

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

  • V Russian Digital Week, день первый

    В эти дни в Digital October проходит мероприятие под названием «V Russian Digital Week», которое, как написано на сайте мероприятия, «определяет вектор развития российской digital-индустрии на ближайшие годы». Мы почитали темы докладов, подумали и решили съездить в качестве слушателей. Первый день под названием «digital&design» был посвящен, собственно, digital и дизайну.

  • Сайт коллекционного журнала «WinX Club — Волшебная комната»

    Вчера вышел наш новый проект — сайт коллекционного журнала «WinX Club — Волшебная комната». Проект получился маленький, но аккуратный. Примечательно то, что собран он был в рекордные просто сроки даже с учетом необходимости согласования материалов не только с представителями заказчика — наших старых друзей из издательства «Эгмонт-Россия», но и с представителями правообладателя — итальянской компанией Rainbow S.r.I. Собственно, не без удовольствия и гордости, представляем вашему вниманию проект. Будем рады критике, похвалам, восторженным возгласам ... Тухлым помидорам рады, конечно же, не будем, но обещаем воспринять, как это положено настоящим профессионалам... с гневной истерикой :-)

  • Еженедельные планерки...

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