⚡ Всем привет! Поделюсь новым кейсом из нашей практики: +1 проект по DATAREON.

Заказчик — компания из нефтяной отрасли. На фоне импортозамещения переходили с зарубежных систем на российский стек, в основном на решения на базе 1С.

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

В контуре участвовали MDM, две инстанции 1С для разных видов учета, система согласования документов, расчет зарплаты, внешние сервисы и веб-порталы. Целевая нагрузка — до 3000 пользователей в 1С.

Ключевая сложность была в управлении переходом. Нужно было точечно переносить обмены, сохранять порядок обработки сообщений при многопоточности, учитывать legacy-логику на стороне смежной системы расчета зарплаты и не перегружать 1С прямыми запросами от внешних порталов.

Что сделали:

▫ выстроили централизованный обмен через DATAREON Platform;

▫ закрепили MDM как источник мастер-данных;

▫ использовали DATAREON как диспетчер и маршрутизатор потоков;

▫ разработали около 50 бизнес-процессов обработки сообщений;

▫ подготовили около 120 обработчиков 1С для выгрузки и загрузки данных;

▫ подключили внешние системы через REST API;

▫ реализовали постраничную выборку данных из 1С для веб-порталов;

▫ добавили валидацию входящих запросов по итогам нагрузочного тестирования;

▫ вынесли часто запрашиваемые данные в Банк Данных DATAREON, чтобы снизить прямую нагрузку на 1С и дать порталам единую точку доступа.

Результат:

▫ на 60% сократили время запуска новых интеграционных сценариев;

▫ на 45% снизили количество ошибок ручного ввода и конфликтов в справочниках;

▫ на 30% снизили нагрузку на одну из систем 1С за счет Банка Данных.

🌟 Интересно, какой подход вы считаете более надежным в таких проектах: сначала максимально детально картировать все существующие обмены или переносить их итерационно, фиксируя конфликты уже на пилотных потоках?