Импортозамещение со звездочкой: как мы реализовали загрузку транзакционных данных в 1С

Руководитель практики технических экспертиз ALP Group Валерий Лямо — об одном из самых сложных архитектурных решений из практики компании.

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

Изначально функциональность загрузки данных разрабатывалась для взаимодействия 1С с системой управления базами данных (СУБД) Microsoft SQL Server под управлением операционной системы Windows Server. Решение было выполнено через технологию Component Object Model (COM) — стандарт Microsoft, который позволяет разработчикам использовать в коде независимые компоненты ПО, даже если они написаны на разных языках программирования, и не волноваться насчет их совместимости.

Всё работало быстро и стабильно. Но в рамках импортозамещения архитектуру требовалось полностью переделать: теперь все те же бизнес-задачи должны были решаться на Astra Linux и PostgreSQL. Классический механизм интеграции Microsoft в этом окружении попросту отсутствует. При этом требования со стороны заказчика по скорости загрузки больших объемов данных никто не отменял.

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

Мы оценили три возможных решения проблемы:

1. Использовать механизм «Внешние источники данных» платформы 1С.

Казалось бы, готовое решение. Но при тестировании стало ясно: показатели производительности вряд ли в полной мере устроят заказчика.

2. Использовать внешние компоненты при взаимодействии с СУБД.

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

3. Придумать собственное решение.

Рискованный, но единственно рабочий путь.

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

Такой подход позволил обойти проблемы с безопасностью (все оставалось внутри допустимого стека), обеспечить высокую производительность и при этом не выйти за рамки лицензий и требований заказчика.

Работа над кастомной системой коммерческого учета велась на территории клиента, и это добавило остроты. У заказчика — закрытый контур, а у нас — нет прав администратора и root-доступов для проведения экспериментов. Сразу возник вопрос: как же нам тогда настраивать окружение для корректного взаимодействия 1С и PostgreSQL в операционке Astra Linux?

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

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

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