Как интегрировать сервисы страховых компаний

Смотрите, у вас есть автомобиль, вы хотите приобрести полис ОСАГО. Как узнать, какая страховая компания предложит наиболее выгодное предложение по вашим параметрам? Для этого надо воспользоваться сервисом Banki.ru, который собирает информацию с нескольких страховых компаний и выдает результаты для сравнения.

Чтобы получать расчеты из разных источников, необходимо с ними интегрироваться. Мы, команда Nord Clan, и реализовывали интеграцию Banki.ru с рядом страховых компаний: Zetta, Согласие, Верна, Либерти Страхование, Астро-Волга, Абсолют Страхование, Югория, Гайде и др.

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

Итак, как это работает

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

Со стороны разработки это также на первый взгляд не вызывает вопросов:

  • запрос документации API
  • подготовка ТЗ
  • разработка интеграции
  • подготовка тестовых данных
  • тестирование
  • техподдержка при релизе

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

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

Как интегрировать сервисы страховых компаний

Нужно учитывать, что на скорость коммуникации будут влиять внешние факторы:

  • разные часовые пояса (даже разница всего в 1 час между Ульяновском и Москвой заметна);
  • загруженность представителей страховых компаний локальными задачами;
  • использование неэффективных каналов взаимодействия (переписка в нескольких мессенджерах или только при помощи e-mail);
  • ожидание согласования начала разработки между заказчиком и страховой компанией (открытый API может изучаться, но переход к техническим этапам должен происходить после заключения договора и NDA).

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

Джульетта, Менеджер проекта

Анализ документации и подготовка ТЗ

Все компании по разному оформляют документацию API. Это факт, с которым нужно смириться. У кого-то параметры запроса перечислены в таблице с описанием характеристик, но без примеров запросов. Кто-то ограничился в документации только кодом запросов. Кто-то подготовил и описание параметров и примеры, но и тут не обходилось без интересностей.

Чтобы убедиться, что запросы работают так, как описано в документации API, мы прогоняли процесс получения полиса от начала до конца с помощью Postman и SoapUI. Это помогло выявить разного рода ошибки:

  • упущенные или избыточные отметки об обязательности параметров;
  • ошибки в названиях и форматах полей запроса;
  • параметры, которые не были описаны в документации.

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

Динара, Аналитик

Ох уж эти правочки

Так как разработка на стороне страховых тоже не стояла на месте (выпускаются обновления в связи с изменением законодательства, улучшения и исправления…) команда была морально настроена на то, что ТЗ будет периодически дорабатываться. Важный момент в такой ситуации — не упустить изменение (лучше внести это сразу, а не быть великим прокрастинатором и повелителем стикеров) и уведомить команду.

Чек-лист для аналитика

  • Получить контакты специалистов со стороны менеджмента и разработки страховых компаний, оговорить удобный всем формат и время коммуникаций;
  • Узнать, какие внутренние справочники есть в системе заказчика, и какие из них используются при формировании запроса на полис ОСАГО;
  • Запросить у страховой компании нужные справочники;
  • Узнать, как должны обрабатываться данные от страховой компании на стороне banki.ru (в нашем случае использовались статусы и из ответных запросов сохранялась лишь часть данных);
  • Оговорить с заказчиком формат ТЗ. Если у заказчика есть шаблон, то необходимо изучить его заранее, до того, как начнете писать новое ТЗ.

Разработка

За основу интеграционного слоя был выбран фреймворк Apache Camel, который имел на борту очень много полезных модулей для работы с очередями activeMQ, camel-jsonpath для преобразования json в blueprint и camel-http4 для вызова web-сервисов страховой компании по REST API. А camel-groovy позволял писать groovy скрипты прямо в xml. Вот такая магия!

Алексей, Team lead

Если углубиться в сам адаптер, то процесс покупки полиса в каждой страховой компании содержал до 10 различных запросов. Мы разделили их на три группы. Первая группа отвечала за проверку данных водителя и предварительный расчет. Вторая — за подтверждение выбора полиса и окончательный расчет. Третья группа — за оплату полиса.

Общая схема взаимодействия​
Общая схема взаимодействия​

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

В процессе работы мы применяли подход TDD (Test Driven Development) в виду того, что актуальный стенд для разработчиков с релевантными данными был один и мы не могли тестировать на нем отдельно каждую нашу интеграционную часть. То есть мы сначала писали тесты, используя модуль camel-test, а потом уже сам код.

Чтобы не зависеть от разработчиков страховых компаний в плане обмена данными на ранних этапах проекта мы использовали библиотеку mockito, с помощью которой создавали имитации нужных запросов и web-сервисов. И это решение помогало нам не раз в дальнейшем, так как тестовые стенды страховых компании порою не работали, но это уже не могло повлиять на сроки сдачи проекта.

Ты интегрируешься со мной, но делаешь это без уважения

Иногда даже при наличии необходимой информации могут возникнуть сложности. У нас был набор данных для авторизации в сервисе страховой компании. Но были какие-то проблемы с API, поэтому чтобы протестировать разработанный код необходимо было каждый день использовать разные параметры для авторизации на тестовом стенде: ежедневно мы пробовали разные комбинации данных, причем иногда срабатывали и те, которые предназначались для боевого стенда.

ПП — правильный подход

Каждая страховая имеет уникальный набор технологий и данных. Разработчики подходили к реализации задач индивидуально, учитывая специфику API. Например, одна страховая использовала стиль взаимодействия REST, другая — SOAP-протоколы, но архитектура решения позволяла легко управлять этим многообразием. Или у одной страховой компании было заложено 30 минут на подсчет стоимости полиса. Для этого кейса мы разработали логику, которая периодически опрашивала внешний сервис на предмет готовности расчета, отправляла его на почту заказчику или по истечению определенного времени отменяла запрос.

Нельзя так просто взять и закрыть задачу

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

Чек-лист для разработчика

  • Основываясь на ТЗ, отослать все запросы через Postman или SOAP UI на тестовый стенд страховой компании;
  • Если есть вопросы, то обсудить совместно с аналитиком. По необходимости подключиться к общению со страховой компанией для выяснения требований;
  • Перед началом реализации убедиться в работоспособности стенда для разработки;
  • Реализовать необходимую функциональность, по методологии TDD (с использованием тестов).
Как интегрировать сервисы страховых компаний

Тестирование

Ты не пройдешь!

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

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

Илья, QA lead

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

Чек-лист специалиста по качеству

  • Подключиться к тестовому стенду страховой компании и уточнить возможные ограничения.
  • Узнать следующее:
    - Возможно ли провести оплату на тестовом стенде;
    - К какому стенду РСА (тестовому или рабочему) обращается тестовый стенд страховой компании;
    - Есть ли у страховой компании готовый набор тестовых данных (если нет, надо подготовить свой);
    - Технические уточнения (IP white-list, особенности авторизации и запросов и т.д.).

Управление проектом

Как и любой другой специалист команды, менеджер проекта (PM) присутствует на любом этапе процесса разработки. Но именно присутствие РМ делает разработку проекта продуктивнее, т.к. в основном вся коммуникация проходит через нас.

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

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

Чем мотивировать команду? Кексиками! Был момент, когда коммуникация затянулась: мы ожидали важную информацию от страховой компании. Поэтому для приободрения команды я пообещала приготовить кексы, как только очередная интеграция будет успешна добавлена на основной сайт Banki.ru. Ребята заценили мои домашние маффины: )

Джульетта, Менеджер проекта

Чек-лист менеджера проекта

  • Создать канал связи с представителями заказчика и страховой компании;

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

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

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

Мы обратились в компанию Nord Clan за помощью в реализации интеграционной части проекта. Работа заключалась в подготовке и нормализации персональных данных пользователей под стандарты интегрируемых систем, формировании запросов к сервисам страховых компаний и обеспечении информационной безопасности обмена данными, предварительного расчета стоимостей полисов, сохранении полученных котировок до момента оплаты, интеграции с платежными системами и отправки полиса клиенту. Специалисты компании реализовали проект под ключ точно в срок. Хотелось бы отдельно отметить деликатное взаимодействие команды Nord Clan со всеми страховыми компаниями, а также соблюдение договоренностей и попадание в наши ожидания. Результатом работ уже можно пользоваться и, если вас интересует страхование автомобиля, можно с легкостью это сделать на сайте финансового супермаркета Banki.ru

Спасибо, Nord Clan, рекомендуем и готовы обратиться вновь!

Багиров Александр, руководитель управления развития бизнес систем Banki.ru
33
Начать дискуссию