Как мы перестали размножать BIRT‑шаблоны и собрали блочную платформу self‑service генерации страховых полисов в PDF

В сфере искусственного интеллекта произошло заметное событие. ElisBuh 7 минут назад Как мы перестали размножать BIRT‑шаблоны и собрали блочную платформу self‑service генерации страховых полисов в PDF Средний 7 мин 6 Блог компании АльфаСтрахование Java * Кейс Я Javaразработчик в АльфаСтрахование, в команде Авиа Блока. Мы занимаемся страхованием авиапассажиров, и одна из наших прикладных задач — генерация страховых полисов в PDF. Исторически печать у нас была построена на Eclipse BIRT.

Если коротко, BIRT — это движок отчётности и рендеринга документов, а файл . rptdesign — его шаблон в XMLформате: в нём описаны структура документа, таблицы, параметры, стили и скрипты. Мы внедрили подход, где итоговый документ собирается не из одной «монолитной» .

Технические детали

rptdesign, а из базового шаблона, переиспользуемых блоков и версионированных наборов значений. Поверх BIRT появился backend-слой, который отвечает за композицию документа, каскадное версионирование, импорт/экспорт конфигурации между средами и безопасный рендер итогового PDF через BIRT runtime. Ключевой фокус был не в ускорении рендеринга, а в user experience: изменения в структуре и контенте должны выполнять нетехнические пользователи, а продукт — контролировать качество через управляемый процесс публикации (черновики → product review → публикация версии → откат при необходимости).

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

Хотим:Исправить формулировку;Поменять логотип партнёра;Вынести адрес из статичного текста в параметр;Переставить местами два смысловых блока. Получаем:Разработчик открывает . rptdesign;Правит XML/таблицы/скрипты;Проверяет, что соседние продукты не сломались;Выкатывает новую версию;Через пару недель повторяет всё снова, но уже для другого партнёра.

Отраслевые последствия

Пока документов мало — терпимо. Когда продуктов и партнёров становится много, система расползается: одни и те же куски появляются в десятках копий, версия документа перестаёт быть понятной сущностью, а бизнес оказывается зависим от IT даже в простых изменениях. Почему одного BIRT оказалось недостаточноBIRT хорошо решает задачу рендеринга: берёт .

rptdesign, подставляет параметры и отдаёт PDF. Но BIRT сам по себе не знает о наших бизнес‑инвариантах — правилах, которые важны именно для страховых документов:новые документы должны печататься по новой версии, а старые — по той версии, по которой были выпущены;один и тот же логотип, текст оферты или юридическая вставка должны переиспользоваться между разными документами, но управляться независимо. То есть движок рендеринга уже был — не хватало предметного слоя поверх него.

Правильная единица измененияКлючевой вопрос был простой: «что именно является единицей изменения? » Не документ целиком, потому что в реальности меняются локальные части:шапка;таблица условий;логотип;юридическая вставка;порядок блоков;набор значений для конкретного партнёра.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.