интеграция сайта что это такое
Проектирование интеграции с веб-сервисом
Все больше и больше аналитиков, проджектов и продактов приходят в айти из маркетинга, консалтинга, продаж и других нетехнических индустрий, да и вообще без опыта работы. И я тут не стал исключением. Существует проблема, что в первые годы на тебя падает немерено технических терминов и концепций, ты пытаешься в них разобраться, но не понимаешь до какого уровня деталей тебе надо опускаться в каждой из них. Надо ли разбираться, что значит обнаруженный тобой термин WSDL и какие бывают виды асинхронного выполнения запроса, или достаточно знать, что у веб-сервиса просто есть запрос и ответ? Статья нужна, чтобы решить эту проблему для одной из самых частых фичей – научиться работать с веб-сервисом для обмена данными, выполнения целевых действий в других системах и прочих интеграций.
На русском и английском есть куча материала про то, зачем нужны веб-сервисы, какие они бывают, как их спроектировать, есть прикольные кейсы. Но про то, как взаимодействовать с ними на практике, особенно на сложных корпоративных системах, я не нашел ничего исчерпывающего. А как показывает опыт, черт кроется именно в деталях и подпунктах, большинство из описанных в этой статье – мои собственные «шишки».
Представь, что тебе надо сделать такую штуку: в зависимости от ответа веб-сервиса, который угадывает зарплату человека, отобразить пользователю кнопку разного цвета. Скажем если зарплата до 20 тыс. рублей, ты делаешь красную кнопку, если от 20 до 100 тыс., то желтую, и если она больше 100 тыс., то зеленую. Казалось бы, что может быть проще! Но чтобы описать эту задачу для разработки и разобраться во всем самому, тебе будет не лишним обратить внимание на 15 разных вопросов, а если фича безумно важная, то еще на 8 других.
Ну чего, погнали, программа минимум:
Найди или попроси страницы с описанием веб-сервиса и задачи, в которых кто-то описывал интеграцию с ним. Проверь наличие всех пунктов ниже, чтобы не раздражать человека, спрашивая лишний раз 🙂
Продовые и тестовые ссылки / адреса (англ. Endpoints PROD, QA / TEST). Веб-сервис доступен именно по этим адресам. Ссылка на тестовый контур будет полезна, чтобы проверить работу сервиса, не внося изменений и не нагружая прод. Ссылки очень похожи на адреса обычных сайтов по формату, часто в них будет содержаться слово “api”. Можно попробовать открыть их в браузере, и иногда что-то отобразится.
Тут веб-сервис поиска в Youtube выдал ошибку, поскольку ожидал, что в запросе мы передадим ключ API (выдается на их сайте, индивидуальный для каждого)
Аутентификация. Как мы будем авторизоваться в веб-сервисе, чтобы он нам отдал нужные данные? Тут много разных вариантов: по ключу API, токену, логину и паролю в теле запроса, бывают и другие.
Примеры запросов: что передавать в веб-сервис для разных случаев, чтобы получить нужные тебе данные? Все ли эти данные у тебя есть?
Запрос в Swagger
Ответ в Swagger
Что мы делаем во время ожидания ответа от сервиса? Особенно актуально, если имеем дело с сервисами, которые долго отвечают, и это заставляет ждать живого пользователя, как в примере с разноцветной кнопкой. Пользователь может не понять, почему ничего не происходит.
Таймаут (максимальное время ожидания ответа) и реакция на него. После таймаута мы перестаем ожидать ответ и происходит определенное поведение твоей системы, к примеру отправка запроса в другой сервис. Почему перестаем ожидать ответ: либо из-за того, что не можем больше ждать, надо уже как-то реагировать, либо если спешить некуда, но мы достаточно уверены, что сервис уже не ответит. Будет круто, если сможешь получить распределение времени ответа сервиса. Можно будет поставить таймаут, к примеру, как 99 перцентиль, но чаще это уже будет описано / можно спросить разработчиков сервиса.
Характеристики полей: тип поля, обязательность и длина строки.
Тип поля. Надо следить, чтобы мы передавали в запросе поля в том же формате, который ожидает получить сервис. Самые частые кейсы тут: передаем число как строку текста “2007”, вместо 2007 и разные форматы дат и времени, к примеру Date “2007-01-01” вместо DateTime “2007-01-01 11:00:00”. Когда получаем ответ от сервиса, тоже лучше следить, что данные из ответа запроса приходят в том же типе/формате, который мы ожидаем, иначе их надо будет конвертировать (переводить) в нужный тип.
SOAP UI Swagger
Длина строк – лучше проверить, что строки текста, которые мы передаем в запросе не сожмутся. Для SOAP есть возможность посмотреть в WSDL мин / макс длину строк в символах, ищи поля minLenght / maxLength. Для REST длина строк определяется на стороне сервиса и обычно само собой подразумевается, что строки не сожмутся. Однако если ты делаешь важную фичу или передаешь текстовую строку длиной в абзац в поле, которое по смыслу должно быть коротким (Имя, Телефон, Адрес), лучше уточнить это у разработчиков сервиса.
Поведение твоей системы в случае ошибок от сервиса (англ. exception flow). Надо продумать, как реагировать на ошибки от сервиса, к примеру можно делать перезапросы по такому правилу: сервис запрашивается раз в 20 минут, суммарно до 10 раз, после чего забиваем.
Поведение твоей системы, если важные поля в ответе придут пустыми / с некорректным значением (к примеру, писать сообщение об этом). На практике такое случается частенько, пример: сервис начинает возвращать не валидированные данные из новых источников.
Полностью проверь работу интеграции на PROD / QA контуре, если есть такая возможность. Обрати внимание, что на QA контуре часто бывают моки или заглушки – когда сервис возвращает в ответе одно и то же подстановочное значение вместо нормальной обработки запроса. Если веб-сервис должен что-то сделать в другой системе, проверь, что это целевое действие выполнено, покажи запросы владельцу сервиса. На практике довольно часто всплывают проблемы именно на этом этапе.
Нагрузка. Обсуди с владельцем сервиса частотность вызова его сервиса, изменение нагрузки в течение суток / недели, а также ее потенциальные изменения в будущем.
Делать ли логирование запроса и ответа. Есть много плюсов: можно отслеживать баги, фрод, смотреть сколько было запросов сервиса суммарно.
интерфейс для просмотра логов Kibana
Кэширование ответа сервиса. Если есть вероятность, что в течение короткого времени потребуется вызов сервиса с такими же параметрами запроса и предполагается, что ответ не будет меняться, то можно этот ответ сохранить, чтобы не вызывать сервис еще раз. Особенно актуально, если вызов сервиса является небесплатным и небыстрым.
Левел 2. Эти моменты лучше проверить, если фича важная:
Доступность сервиса в зависимости от времени. Если у сервиса есть “часы пик” во время которых он становится менее доступным, следует это учесть во время планирования работы с ним: предупредить пользователей, внимательно продумать реакцию на таймаут и ошибки в ответах.
Алерты. Если успешный ответ от сервиса является критичным, можно настроить алерты на ошибки, доступность или резкое изменение среднего значения в ответе / доли определенных значений.
Надо ли реализовать логику обработки ответа на стороне веб-сервиса. На нашем примере с разноцветной кнопкой в зависимости от полученной в ответе зарплаты: можно сделать эту логику в твоей системе (часто самый простой вариант), однако если границы 20 и 100 тыс. предполагается часто менять, а также классификацией красный / желтый / зеленый будут пользоваться другие люди и системы, может иметь смысл доработать сервис и передавать в ответе сразу цвет кнопки. Иначе запросто может возникнуть рассинхронизация и одинаковые по зарплате люди будут с разными кнопками.
Меняется ли структура ответа в зависимости от параметров запроса? К примеру, в запросе есть параметр “strategy”, в зависимости от которого в ответе возвращается разное число параметров. Наша система должна учитывать это.
Логика обработки ответа. Если ты меняешь существующую интеграцию с веб-сервисом, не забудь о том, что на вашей системе может быть логика, которую надо обновить. К примеру, вы считываете только определенные поля из ответа и надо добавить новые.
Левел 3. Самый важный проект за год, баги недопустимы!
Примеры ошибок. Возможно, потребуются сценарии и алерты на разные ошибки. Так ошибки описаны у Яндекс.Толоки
Невыполнение целевого действия при успешных ответах. Бывают случаи, когда сервис в случае невыполнения целевого действия возвращает 200 OK (код об успешном выполнении). Пример: сервис сам передает запрос в другой сервис после нашего запроса, но не дожидается ответа от него и сразу шлет 200 OK, но на самом деле целевое действие еще могло не успеть произойти и должен быть ответ с кодом 201 Created.
Синхронное / Асинхронное выполнение запроса. При Синхронном выполнении запроса, он обрабатывается сразу при получении. При асинхронном взаимодействии запросы попадают в очередь на стороне сервиса и целевое действие сразу не выполняется. У владельцев или пользователей сервиса можно узнать, сколько в среднем событие лежит в очереди и сколько еще требуется времени на обработку запроса. Успешные коды 201 и 202 намекают на асинхронность. Если ты их получил, лучше проверить, что целевое действие выполнится.
Самые популярные HTTP статус коды
Спасибо за внимание! Делитесь в комментах своими кейсами.
Интеграция сайта с внешними сервисами
В современном интернет-бизнесе внедрение автоматизации различных процессов стало обычным делом. Сложно представить себе сайт без подписки на рассылку, возможности онлайн-оплаты и других привычных услуг. Но есть и более сложные задачи, которые позволяет решить интеграция: учет товара, контроль за исполнением, оформление документации.
Какие бывают интеграции?
Есть несколько различных систем, с которыми мы обычно сталкиваемся:
Эти основные типы интегрирования с развитием технологий становятся не просто дополнительным функционалом, а обязательным условием эффективности и прибыльности онлайн-бизнеса. Ведь в итоге они дают возможность получить свое комплексное и автоматизированное решение поставленных задач.
Теперь подробно о каждом пункте.
E-mail-рассылка
Рассмотрим классический вариант получения e-mail-рассылок. Допустим, вы что-то искали в Интернете и случайно попали на наш сайт. На нем много интересного материала по интересующей вас тематике, и вы хотели бы регулярно читать наши статьи.
Конечно, можно время от времени заходить на сайт и искать в его глубинах новые материалы. Но есть способ проще — подписаться на рассылку, и тогда новая информация сама будет приходить на электронную почту.
Интерес пользователя понятен, а вот зачем это нужно администратору?
Правильно сделанная интеграция значительно упрощает работу с рассылками — автоматически добавляет всех новых покупателей в список рассылки, подписывает на триггерную цепочку рассылки в зависимости от актуальности для пользователя, позволяет сохранить адрес пользователя в базе для дальнейшей плановой рассылки.
Удобство также состоит в отслеживании регистраций или событий на сайте, создании клиентской базы и контроле над заявками.
Простой пример — посетитель заказывает обратный звонок по интересующей его услуге или товаре. E-mail сообщение администратору сигнализирует о контакте и помогает вовремя продолжить работу с клиентом. То же самое происходит и с заявкой, администратор получает извещение о заявке на почту, что облегчает ее контроль и дальнейшее исполнение.
Некоторые сервисы включают в себя не только e-mail, но и SMS-рассылку: UniSender, SMS-Fly и другие.
SMS-рассылка становится все более популярна среди пользователей. Действительно, показать телефон с трек-номером на экране при получении удобнее, чем распечатывать его с почты и потом искать этот листик.
Еще часто используют SMS-рассылку при авторизации на защищенных сайтах.
Помимо соображений безопасности, такая интеграция позволяет вам напомнить клиенту о себе, информировать о проводимых акциях или скидках в вашем магазине, дает возможность показать заботу о клиентах поздравляя с праздниками.
В этих случаях вы можете подключить такие виды SMS систем, как Альфа-СМС, SMS-Fly, UniSender, SMS-центр Киев и многие другие.
Системы доставки
Автоматизация системы — вот главное удобство этой интеграции.
Если проведена интеграция с сайтом, клиент всегда будет вводить актуальные данные по доставке, так как происходит моментальное получение информации с сервера перевозчика — выбор отделений и города доставки, возможность просчитать ее стоимость.
Также в Личном Кабинете пользователя отображается трек-номер почтового отправления, который позволяет на сайте перевозчика отследить статус доставки. В этом случае осуществляется автоматизация, направленная на упрощение управления доставкой.
Помимо удобства для пользователя, такая интеграция упрощает работу администратора ресурса. Введенные клиентом корректные данные по доставке со стороны панели администратора позволяют автоматически создать товарно-транспортную накладную, получив трек-номер заказа, что значительно сокращает процесс формирования и последующего оформления в почтовом отделении.
Системы доставки дают возможность контролировать статусы заказов, видеть какие из них оплачены, условия доставки, а также контролировать, что уже отправлено, а что только готовится к отправке.
Система имеет возможность информировать покупателя о необходимости забрать или оплатить товар в виде SMS сообщения, напоминать адрес доставки и трек-номер.
Главная задача заключается в упрощении всего процесса по доставке, включая работу тех людей, которые с этой системой связаны — возможность отслеживать, не терять заказы, помнить о них, правильно построить логистику с наименьшей потерей времени.
Платежны е системы
Без использования онлайн-платежей сейчас не обходится ни один сайт. Они позволяют организовать круглосуточный автоматический прием платежей за товары и услуги через популярные электронные платежные системы.
Покупатель совершает оплату быстро и без затруднений, не покидая сайт, получая удобство и сервис. А со стороны административной панели денежные средства заходят автоматизировано на счет, что в данном случае дает возможность не тратиться на менеджмент и отслеживание оплаты в ручном режиме.
Платежные системы позволяют полностью автоматизировать три основных этапа продаж в Интернете:
Системы учета товаров
Как правило, интернет-магазины или продуктовые компании имеют в своем распоряжении много товара и свою программу учета.
Представим себе процесс контроля товаров на сайте. Большое количество товаров отнимает много времени для сопоставления количества или наличия товара на сайте и в базе данных, а еще нужно вносить новый товар и удалять закончившийся. Такую процедуру нужно проводить каждый день. Представить ситуацию, когда сотрудник может отвлечься и что-то пропустить или просто устать, очень легко. И тогда компания начинает терять прибыль. Ведь как отправить оплаченный товар, когда его нет на складе?
Система автоматизированного учета товаров позволяет отслеживать остатки, добавлять новые позиции и скрывать закончившийся товар. В этом случае нужно вести только одну базу данных, а система автоматически подтягивает ее на сайт, что экономит массу времени для сотрудника, который может в это время выполнять другую работу. В актуальности базы принимают участие также бухгалтер и кладовщик, что сводит количество ошибок с количеством и наличием товара на минимум и оберегает репутацию поставщика от неприятных моментов с отсутствием заказанного продукта.
Термин «Customer Relationship Management» можно перевести на русский язык как «управление взаимоотношениями с клиентами».
CRM-системы – специальные компьютерные программы, позволяющие планировать задачи и контролировать их выполнение, вести учет клиентов, хранить документацию по проектам, автоматизировать ее создание и многое другое. С помощью этих систем вы можете рассчитать время от звонка до сделки, провести расчет ее стоимости. Они дают вам возможность не потерять клиента и контролировать исполнителей не пуская всю работу на самотек.
Ведь, если не контролировать цикл продаж, каждый менеджер по продажам работает так, как ему удобнее и ведет фиксацию звонков или других видов взаимодействия с клиентами по собственному усмотрению. Кто-то – на бумаге, кто-то – в таблицах, а кто-то вообще не считает нужным фиксировать процесс своей работы.
Приведем пример: вы создали сайт, привлекли маркетологов и менеджеров по рекламе, а продажи не идут. И все сделано правильно, ведь ваш сайт в топ-10, а клиент не останавливает свое внимание на предлагаемой вами услуге. Открываем отчет и видим, что из 50 входящих заявок отвечено лишь на несколько. Почему так произошло? Кто-то из сотрудников плохо выполняет свои обязанности. Значит вам, как руководителю, надо разобраться в сложившейся ситуации.
Поэтому стоит помнить, что разрабатывая сайт и добавляя к нему CRM, вы не гарантируете моментальный рост прибыли, если перед этим не наладили обработку заявок сотрудниками, не обучили их и не снабдили четкими инструкциями. Для компаний, которые предлагают услуги, CRM-системы — по сути аналог обеспечения бизнес-процессов. Если не считаешь, то не управляешь. А не управляешь, значит не контролируешь. Ведь в этом случае даже простой вопрос «А сколько стоит ваша услуга?» может привести к прибыли для вашей компании.
CRM-системы — это связь с сайтом, которая позволяет вам вести учет контактов и совершенных по ним сделок, планировать повышение качества работы и разрабатывать стратегию развития бизнеса.
Особенная интеграция
Особенная интеграция — это внедрение специфических программ. Существуют уникальные бизнес-процессы, которые требуют индивидуального подхода.
Например, налаживание системы по управлению кухней: заказ приходит уже в развернутом виде, где указаны необходимое количество ингредиентов для блюда, учитывается ужарка, усушка и тому подобное. Сюда же подключено меню, отслеживаются заказы на вынос, и так далее.
Еще один пример особой интеграции — производство ювелирных изделий. Большое количество параметров собирается и формируется в один заказ и отправляется на нужного мастера.
Каждый случай рассматривается отдельно и решается с учетом специфики.
Заключение
Вот вкратце все, что мы хотели рассказать об интеграции сайта. Каждый из приведенных примеров помогает и облегчает работу администратора сайта, позволяет автоматизировать процессы и служит инструментом контроля, а пользователю показывает высокий уровень сервиса по отношению к нему.
Как интегрировать сайт с внешними сервисами
Современные приложения и сайты не могут быть изолированы. Через внешнюю интеграцию настраивается авторизация через соцсети, оплата онлайн, заказ доставки на постоянной основе. Для оптимизации бизнес-процесса сайт и интегрированные сервисы должны автоматически обмениваться данными в режиме реального времени.
Оптимальный способ интеграции — это API (application program interface) или программный интерфейс приложения. Мы привыкли, что купленный билет в кино автоматически добавляется в календарь, а моментально авторизовавшись через google-аккаунт можно оставить комментарий. Именно API соединяет сайт с внешним миром и позволяет совершить необходимое действие – регистрацию, покупку, подписку, не уходя с сайта.
Можно с нуля разработать внутреннюю интеграцию, например, интегрировать CRM с сервисом имейл-рассылок и импортировать все адреса клиентов.
А самые востребованные сервисы разрабатывают свои API, делают их публичными и сразу составляют документацию, описывающую процесс интеграции. Таким образом можно подключить сервисы по бронированию, голосовой поиск и другие приложения для удобства пользователей.
Разработчик сайта сможет обратиться к существующему API в своем коде, а дальше все будет зависеть только от функциональностей приложения. Например, авиакомпании передают на сайт-агрегатор информацию о своих предложениях, что делает возможным бронирование авиабилета в несколько кликов.
Несмотря на то, что здесь решение необходимо создавать под каждый вид интеграции и каждую бизнес-задачу, это упрощает работу программиста и разработку продукта.
Какие функциональности можно таким образом добавить на сайт
А также сервисы для быстрой отправки имейла, использования электронной подписи, карты Google Maps, стриминговые платформы или Wikipedia.
Вот как мы интегрировали внешние сервисы на своих проектах.
МегаФон
Бизнес-задача:
Подключить на сайте megafon.ru оплату банковской картой. Для этого был выбран сервис онлайн-платежей InPlat.
В документации от сервиса Inplat прописаны сценарии оплаты с подтверждением или без, единичная оплата или привязка карты. Когда абонент собирается оплатить услуги на сайте МегаФона, он получает ответ системы:
Реализация:
Интеграция – это организация обмена информацией с сервисом-поставщиком данных. Поставщик данных определяет способ взаимодействия со своим сервисом и описывает ее в документации. Это запросы к интерфейсу API по протоколу http различного предназначения — получение информации, изменение, удаление, добавление сущности. Разработчик сайта МегаФон видит API и пишет код, который обращается к API. Сайт МегаФона предоставляет форму, после того, как пользователь ее заполняет, запрос отправляется к API InPlat. Дальше запрос обрабатывается на стороне InPlat.
Nikon
Бизнес-задача:
Провести розыгрыш призов, с механикой, основанной на верификации чеков.
Мы создали несколько лендингов для акций Nikon. Их механика отличалась, например, в акции Я свобода творчества после покупки техники Nikon, покупатель может зарегистрировать чек и получить годовую подписку на пакет программ Adobe Creative для фотографов. Пользователь отправляет номер и фотографию чека, серийный номера проверяется на официальном сайте Nikon, после чего пользователь получает ключ доступа к программам. В этом случае сначала необходима интеграция с API Nikon, а потом с API Adobe.
В акции Я объективно лучший подарок пользователь регистрирует свой чек на покупку и может получить подарок в фирменном магазине Nikon. Чтобы сразу на лендинге акции узнать адреса магазинов, мы подключили интерактивную карту.
Реализация:
Пользователь загружает фото чека. Данные Nikon отправляет на внешний сервис – официальный сайт Nikon. Он обрабатывает эти данные и проверяет серийный номер. После чего сайт Adobe отправляет пользователю ключ доступа к программам.
Но не для всех задач достаточно интерактивного обмена данными. Существуют кейсы, требующие комплексного решения. Для каждой задачи необходимо выбрать свой механизм: например, интеграция с сервисом карт будет в каждом разрабатываться по-разному и это займет разное время.
PepsiCo
Бизнес-задача:
PepsiCo часто проводит акции, в рамках которых пользователь вводит на промо-сайте код с крышечки или пачки. Он получает гарантированные призы или участвует в розыгрыше большого еженедельного приза.
Раньше сайты акции напрямую интегрировались с CRM-системой и другими отдельными инструментами, нужными для промомеханик, таких как сервис регистрации чека или программы лояльности. Регистрация, авторизация пользователей, валидация кодов происходили с помощью интегрированной CRM. А розыгрыш и отбор победителей — на странице сайта.
Реализация:
Мы разработали единый инструмент розыгрыша, чтобы создавать новые промосайты было проще, перенести розыгрыши с сайта и внедрить единую систему. После его разработки сайту больше не требуется напрямую подключаться к отдельным инструментам и проводить на своей стороне розыгрыши. Теперь эти функции выполняет единый инструмент розыгрышей, достаточно того, что сайт подключен к нему. Сам сайт только отправляет запрос и получает ответ.
Благодаря этому инструменту повысилась общая стабильность проектов: единая платформа задает стандарт разработки промосайтов, экономит время и упрощает задачу для разработчиков. Механики, разработанные для одного розыгрыша, применимы на другом, поэтому новые промо запускаются гораздо быстрее.
Персональные данные, полученные в каждом розыгрыше, хранятся и обрабатываются в одном месте, и пользователям не нужно повторно регистрироваться для участия в новом розыгрыше. Кроме того, это снижает юридические риски.
Новым подрядчикам легче включиться в работу, т.к. они могут пользоваться единой платформой, чтобы создавать новые механики розыгрышей. А PepsiCo получили возможность выбирать подрядчиков из более широкого круга агентств, т.к. на них осталось мало технических задач и можно ориентироваться на экспертов в креативе.
Особенности интеграции
С помощью внешней интеграции можно значительно расширить возможности сайта, улучшить UX, автоматизировать обмен данными. Кроме того, интеграция с внешним сервисом может стать элементом партнерского маркетинга.
Но нужно учитывать, что интеграция с внешним сервисом – это дорогой процесс, поскольку готовых решений очень мало. Все проекты индивидуальны и многое зависит от бизнес-задач. Поэтому каждый раз разработчик сопоставляет бизнес-задачу с возможностями сервиса и вырабатывает решение.