Как интегрировать 1С с библиотекой API на C#?

← На главную

В практике разработчика 1С часто возникает задача интеграции с внешними системами, которые предоставляют API не в виде стандартных веб-сервисов (REST/SOAP), а в виде готовых библиотек классов (DLL), написанных на языке C#. В данной статье мы разберем, как подключить сборку .NET к 1С, проанализируем основные подходы и выясним, какой из них будет наиболее стабильным в современных условиях.

Анализ исходной ситуации

Представим, что у нас есть файл RDMetadataServerClasses.dll и описание классов на C#, например: public class NaturalPerson : Consumer. Напрямую 1С не умеет создавать экземпляры классов из произвольных .NET сборок простым вызовом команды Новый. Нам необходимо создать механизм-посредник, который позволит платформе 1С "увидеть" структуру объектов C#.

Важное наблюдение: Судя по именам классов NaturalPerson и пространству имен RDMetadataClasses, речь идет об интеграции с системой Directum RX. Это специфическая объектная модель, которая требует не только подключения библиотеки, но и наличия всей инфраструктуры сервера приложений Directum на стороне клиента или сервера 1С.

Способ 1: Использование COM-технологии

Это классический метод, который позволяет зарегистрировать библиотеку C# в операционной системе Windows как COM-объект. Разберем этот процесс по шагам:

Подготовка библиотеки: Чтобы 1С могла обратиться к классу, он должен быть помечен атрибутом [ComVisible(true)] в исходном коде C#. Если библиотека чужая и этого атрибута нет, нам придется написать свою "обертку" (Wrapper) на C#, которая будет подключать исходную DLL и транслировать её методы наружу.
Регистрация: Используем утилиту regasm.exe, входящую в состав .NET Framework. Выполним команду в консоли: regasm.exe RDMetadataServerClasses.dll /tlb /codebase.

Вызов в 1С: После регистрации мы можем создать объект стандартным способом:


// Создаем экземпляр объекта из библиотеки C#
Попытка
    ОбъектИнтеграции = Новый COMОбъект("RDMetadataClasses.NaturalPerson");
    // Вызываем метод объекта
    Результат = ОбъектИнтеграции.GetInfo();
Исключение
    Сообщить("Не удалось инициализировать объект: " + ОписаниеОшибки());
КонецПопытки;

Плюсы: Простота использования в коде 1С.
Минусы: Необходимость регистрации в реестре на каждом рабочем месте (или сервере), проблемы с разрядностью (32-битный клиент 1С не увидит 64-битную компоненту).

Способ 2: Использование внешних компонент (Native API)

Рассмотрим более современный подход — создание внешней компоненты 1С на языке C#. Мы можем использовать технологию CLR Hosting, чтобы внутри стандартной DLL (Native API) "поднять" виртуальную машину .NET и исполнять код нашей библиотеки.

Проанализируем преимущества этого метода:

Компонента загружается методом УстановитьВнешнююКомпоненту() и не требует регистрации в реестре Windows.
Она может быть упакована в общий макет конфигурации и автоматически распространяться на рабочие места пользователей.
Позволяет передавать сложные типы данных, преобразуя их в JSON или Структуры 1С внутри кода компоненты.

Способ 3: Готовые решения (.NET Bridge)

Существуют готовые программные продукты, такие как Elisy .NET Bridge или открытые разработки (например, проекты Сергея Смирнова), которые выступают универсальными посредниками. Они позволяют загружать любую .NET сборку динамически прямо из кода 1С.

Посмотрим, как это выглядит на практике:


// Загружаем универсальный мост
библиотека = Новый COMОбъект("NetObjectTo1C.NetObjectTo1C");
// Загружаем нашу DLL
сборка = библиотека.LoadAssembly("C:\Libs\RDMetadataServerClasses.dll");
// Создаем тип данных
типПерсона = сборка.GetType("RDMetadataClasses.NaturalPerson");
// Создаем экземпляр
экземпляр = библиотека.CreateInstance(типПерсона);

Способ 4: Промежуточный веб-сервис (Sidecar архитектура)

Выясним наиболее надежный способ интеграции для крупных систем. Если прямая работа с DLL в процессе 1С вызывает сбои или конфликты версий библиотек, лучшим решением станет создание небольшого сервиса на ASP.NET Core.

Разберем алгоритм реализации:

Разрабатываем на C# веб-приложение, которое подключает нужную нам DLL.
Создаем в этом приложении методы (Endpoint), которые принимают HTTP-запросы от 1С.
В 1С используем объект HTTPСоединение для передачи данных.

Пример кода в 1С для взаимодействия с таким сервисом:


Соединение = Новый HTTPСоединение("localhost", 5000);
Запрос = Новый HTTPЗапрос("/api/metadata/getperson?id=123");
Ответ = Соединение.Получить(Запрос);

Если Ответ.КодСостояния = 200 Тогда
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
    ДанныеПерсоны = ПрочитатьJSON(ЧтениеJSON);
    Сообщить("Имя персоны: " + ДанныеПерсоны.Name);
КонецЕсли;

Технические нюансы и ограничения

Проанализируем критические моменты, которые могут помешать успешной интеграции: 1. Разрядность систем. Если ваш сервер 1С работает в 64-битном режиме, то и все библиотеки C#, вызываемые через COM или Native API, должны быть скомпилированы под платформу x64 или AnyCPU. Это одна из самых частых причин ошибок типа "Класс не зарегистрирован".

2. Зависимости. Библиотека RDMetadataServerClasses.dll, скорее всего, зависит от других файлов (Entity Framework, системные библиотеки вендора). Все эти файлы должны находиться в каталоге исполняемого файла 1С (bin) или быть доступны в системных путях поиска.

3. Иерархия классов. 1С не поддерживает наследование C# напрямую. Если метод API возвращает базовый класс Consumer, а вам нужны свойства наследника NaturalPerson, 1С не сможет выполнить приведение типов (Type Casting). В этом случае использование "обертки" или промежуточного JSON-сервиса становится обязательным.

Профессиональный совет для Directum RX

Если ваша задача — интеграция именно с Directum RX, то вместо манипуляций с DLL крайне рекомендуется использовать штатный OData-интерфейс этой системы. Это позволит вам обращаться ко всем сущностям (включая NaturalPerson) через стандартные веб-протоколы, что гораздо стабильнее и не зависит от обновлений версий библиотек на стороне сервера приложений.