Форум 1С
Программистам, бухгалтерам, администраторам, пользователям
Задай вопрос - получи решение проблемы
28 янв 2023, 10:12

Интеграция стороннего кода в 1с

Автор grisha, 24 авг 2022, 07:55

0 Пользователей и 1 гость просматривают эту тему.

grisha

Всем привет! такой вопрос, мне нужно разработать внутренний чат в 1С. могу ли я написать чат на стороннем языке (например, C#, C++, другом) и подключить его к 1с? Возможно ли это? Если да, то как сложно будет интегрировать чат в 1с? уже есть готовая конфигурация.

antoneus

Это подойдет?

NativeAPI. Внешние компоненты на С++ "для чайников"

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

Предисловие

В заголовок статьи вынесена фраза "для чайников". Под чайником я имел в виду в первую очередь себя. Все мои знания С++ остались на уровне 3-4 курса ВУЗа, когда я встал на кривую дорожку 1С. И все бы хорошо, но недавно встала задача, требующая написания внешней компоненты. Пришлось поворошить воспоминания и стряхнуть пыль со знаний C++. Оказывается, все не так страшно. Краткий ликбез написания внешних компонент я и хочу вам предложить.

Шаблон компоненты на ИТС

На диске ИТС имеется полная документация по механизму внешних компонент, дополненная примером проекта и шаблоном для собственной разработки. Материал так и называется "Технология внешних компонент". Документация - это прекрасно, но в ней еще надо разобраться, а времени, как обычно, мало. На самом деле, существует всего несколько ключевых моментов, на которые стоит обратить внимание, остальное - тлен и суета:)

Необходимые материалы

Для создания внешней компоненты нам понадобятся:

  1. Материал «Технология создания внешних компонент», расположенный на ИТС
  2. Шаблон пустой внешней компоненты, прилагающийся к материалу
  3. MS Visual Studio. Версия Express бесплатна и более чем достаточна для наших нужд.
  4. Наличие базовых знаний синтаксиса C++, а именно:
  • Умение отличить объявление переменной от цикла или условия
  • Понимание того, что строк в чистом виде в C++ не существует, есть массивы, под которые явно требуется заморачиваться с памятью
  • Ну и само собой, требуется умение реализовать поставленную задачу на указанном языке. Как минимум, умение вызвать из C++ какую-то стороннюю библиотечку, которая сама все сделает.

Начинаем копать

Документация на Native API достаточно подробна. Если подвести резюме, то она говорит о следующем:

  1. Внешняя компонента позволяет расширить встроенный язык новым объектом (или несколькими). Т.е. мы создадим некий класс, который сможем создавать через оператор «Новый» и вызывать методы этого объекта из встроенного языка.
  2. Для того, чтобы наш объект работал, платформа будет «общаться» с ним по определенному протоколу, который мы и обязаны обеспечить.
  3. Собственно код компоненты условно состоит из двух частей: первая - регистрация самой компоненты в системе, вторая - работа нового класса и его взаимодействие с платформой.

Мы не будем залезать в особенности реализации, у нас сроки горят, да и компетенции маловато. Нам нужно быстро понять - в какое место нужно вписать свои строчки, чтобы компонента заработала. Для этого, берем шаблон компоненты с ИТС и открываем его в Visual Studio. Шаблон находится в папке template распакованного архива. Посмотрим, что у нас тут есть.

solution

Нас интересует файл AddInNative.cpp. Вся реализация заложена в нем. Он содержит заготовки всех нужных методов, нужно только их слегка настроить. Однако оказалось, что проще взять за основу не пустой шаблон, а разобраться с рабочим примером. В нем есть несколько полезных примочек, которых нет в пустом шаблоне. Когда придет понимание - нужно будет взять пустой шаблон и уже со знанием дела его доработать. Пример рабочей компоненты расположен в папке example\NativeAPI, а пустой шаблон - в папке template.

Откроем проект из папки example и в нем - файл AddInNative.cpp

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

1

Наш объект, как «настоящий» будет поддерживать методы, написанные, как на русском, так и на английском языке. Для этого объявлены написания имен свойств и методов на двух языках. Синяя рамка - английские термы, красная, соответственно - русские. На картинке видно, что в примере уже реализован ряд методов и свойств. Наша задача - их убрать и вставить свои.

Зеленой рамкой выделена строка, в которой объявлено имя класса. Честно признаюсь, я не вникал, что оно означает. Если его поменять, то ничего не работает. Поскольку изначально оговорились, что я «чайник», то мне простительно. :)

Таким образом, если наш объект будет содержать метод «ВыполнитьРасчет» и свойство «Адресат», то нам нужно описать это имя в массиве g_MethodNamesRu и g_PropNamesRu, соответственно.

Вызовы из языка 1С

Итак, наш объект будет содержать один метод и свойство, доступное для чтения и записи.

Пусть будет следующий сценарий использования:

НашОбъект = Новый("AddIn.MyComponent.DataSender"); // DataSender - это имя из ф-ции RegisterExtensionAs (рассмотрена ниже).
НашОбъект.Адресат = «somemail@server.com»;
НашОбъект.ВыполнитьРасчет(СуммаПлатежа, «За коммунальные услуги»);

Имеется строковое свойство и метод с числовым и строковым параметром. Для того, чтобы все это заработало 1С выполняет примерно следующий протокол общения с компонентой:

2

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

Вернемся к нашему коду. Во избежание «волшебных чисел» в классе CAddInNative объявлены два перечисления, отвечающие за определение номеров методов и свойств. Откроем файл CAddInNative.h и увидим их в самом начале:

3

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

Строки Unicode

Многие, наверное, знают, что платформа оперирует двухбайтовыми символами в формате Unicode. В шаблоне для этого объявлен специальный тип WCHAR_T. Этот тип является кросс-платформенной оберткой и обеспечивает одинаковый размер символа на Windows и на Linux. Стандартный тип wchar_t по размеру может отличаться на разных системах. Обратите также внимание, все строковые литералы объявляются с префиксом в виде буквы L. Это означает, что такая строка имеет тип wchar_t.

Есть простое правило: внутри компоненты строки обрабатываются как wchar_t (на Linux может быть 4 байта, в Windows - 2), но как только мы передаем строку в 1С или принимаем ее оттуда, то нужен WCHAR_T (строго 2 байта на всех системах).

Для преобразования одного типа строк в другие в шаблоне предусмотрены вспомогательные функции:

Первая - формирует WCHAR_T из стандартного wchar_t:

uint32_t convToShortWchar(WCHAR_T** Dest, const wchar_t* Source, uint32_t len = 0);

Вторая - наоборот. Формирует wchar_t из WCHAR_T.

uint32_t convFromShortWchar(wchar_t** Dest, const WCHAR_T* Source, uint32_t len = 0);

При взаимодействии с платформой всегда используется только WCHAR_T.

Тип Variant

Еще одна интересная вещь - это универсальный тип данных Variant. Он позволяет нам взаимодействовать с языком 1С, который, как известно, не типизирован и каждая переменная в нем может содержать что угодно. При обмене значениями используется именно этот тип. Мы передаем в метод ВыполнитьРасчет два параметра - число и строку. В компоненту «приедут» два значения Variant. На нас возлагается обязанность проверить их действительный тип. Никто не помешает передать в компоненту не число, а скажем, таблицу значений.

Хотя, я похоже, ошибаюсь. Мне кажется, что ТаблицуЗначений в NativeAPI передать все-таки не получится, т.к. ее нет в списке допустимых типов, но, тем не менее, можно передать Дату вместо Cтроки. Это тоже не есть хорошо. Мы должны проверить реальный тип переменной, приехавшей из 1С.

Тип Variant устроен несложно. Это структура, свойствами которой являются значения разных типов. Там есть свойства типа DATE, wchar_t, int и прочие. Главной частью Variant является свойство «vt» которое хранит настоящий тип переменной, и по которой можно понять, как именно трактовать данный Variant. Кроме того, объявлен ряд вспомогательных макросов, упрощающих работу с типом Variant.

Ближе к делу

Вроде бы, со вступлением всё. Предлагаю рассмотреть пример реализации внешней компоненты. В качестве ТЗ выступит пример компоненты с диска ИТС. Этот пример описывает следующие возможности:

  • Вывод текста в строку состояния главного окна;
  • Посылка внешнего события по таймеру;
  • Передача двоичных данных в 1С:Предприятие;
  • Реализация свойств;
  • Реализация процедур;
  • Реализация функций;

Компонента имеет следующий API:

  • Свойства:
    • Включен/IsEnabled;
    • ЕстьТаймер/IsTimerPresent;
    • Методы:
      • Включить/Enable;
      • Выключить/Disable;
      • ПоказатьВСтрокеСтатуса/ShowInStatusLine;
      • ВключитьТаймер/StartTimer;
      • ВыключитьТаймер/StopTimer;
      • ЗагрузитьКартинку/LoadPicture;

По таймеру возникает внешнее событие, на которое можно подписаться из кода 1С.

Руководствуясь имеющимися у нас знаниями, рассмотрим компоненту с самого начала.

Регистрация компоненты

Наш объект реализуется в виде отдельного класса C++, в данном случае - CAddInNative. Чтобы 1С смогла увидеть наш класс, библиотека dll должна экспортировать 3 функции:

  • GetClassObject
  • DestroyObject
  • GetClassNames

Эти экспорты можно увидеть в файле AddInNative.def в дереве проекта VisualStudio. Посмотрим на код этих функций:

4

Самая простая - функция GetClassNames - сообщает платформе 1С какие классы есть в нашей компоненте. Пусть гуру C++ меня поправят, мне кажется, что здесь нужно ответить платформе именами классов C++, чтобы она могла их к себе импортировать. Именно для этого служит массив g_kClassNames, тот самый, с зеленой «рамочкой». Специально не проверял, если нужно просто заставить компоненту работать, то следует оставить все, как есть в примере. Он и так рабочий, не стоит его ковырять до поры до времени.

Итак, GetClassNames, возвращает в платформу массив имен классов, реализующих полезные объекты внешней компоненты. В нашем примере компонента вернет в платформу массив из одного элемента с именем класса CAddInNative.

Обратите внимание, в платформу пойдет значение типа WCHAR_T, а имя класса в массиве g_kClassNames имеет тип wchar_t. Поэтому, выполняется приведение с помощью вспомогательной функции, о которой говорилось выше.

Следующая функция - GetClassObject. Вызывается, когда в коде предприятия мы написали «Новый». Платформа требует от нас создать новый экземпляр класса и вернуть ей указатель на новый объект.

Опять же, обратите внимание, первым параметром платформа говорит нам - какой именно класс создать (из тех, что дали ей методом GetClassNames). Поскольку у нас только один класс, то это имя здесь вообще не проверяется, просто создается объект через new и возвращается через выходной параметр pInterface.

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

Описанные реализации достаточно универсальны. Если наша компонента реализует только один класс (как в примере), то эти функции нужно тупо скопировать к себе. Единственное условие - создать правильный класс в функции GetClassObject, если у вас он называется не CAddInObject, а как-то иначе.

Инициализация/завершение существования компоненты

После создания класса, реализующего компоненту, платформа вызывает методы этого класса. Перед началом работы платформа сообщит нам объект «самой себя», с которым мы можем вызывать те или иные методы самой платформы. Происходит это в методе Init. В примере объект платформы сохраняется в переменной m_iConnect.

idone

Далее, метод GetInfo должен вернуть номер версии «Технологии внешних компонент». На данный момент, это всегда версия 2.0, а метод всегда возвращает значение 2000.

Еще один важный метод - setMemManager. Позволяет выделять блоки памяти, которые будет освобождать сама платформа. Реализуется следующим образом:

mm

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

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

Полезная нагрузка. Методы и свойства объекта компоненты

Регистрация

Ну и разумеется, мы создавали компоненту не ради ее инициализации, а ради какого-то полезного функционала. Настало время рассмотреть, как он реализуется.

Во-первых, мы должны зарегистрировать объект, который может быть создан и вызван из языка 1С. Данный объект регистрируется в методе RegisterExtensionAs.

ras

В этом методе мы сообщаем платформе имя нашего класса, как оно будет видно из языка 1С. Именно по этому имени мы будем его создавать через «Новый». В данном случае, создание объекта будет выполняться следующим кодом:

ПодключитьВнешнююКомпоненту(Файл, "МояКомпонента", ТипВнешнейКомпоненты.Native);
ОбъектКомпоненты = Новый("AddIn.МояКомпонента.AddInNativeExtension");

Согласно документации, память для строки с именем класса выделяется менеджером памяти, и по этому адресу записывается имя - «AddInNativeExtension». Здесь можно безболезненно написать свое имя. Обратите внимание, опять происходит преобразование из wchar_t в платформенный WCHAR_T.

Использование

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

НашОбъект = Новый("AddIn.MyComponent.DataSender"); // DataSender - это имя из ф-ции RegisterExtensionAs (рассмотрена ниже).
НашОбъект.Адресат = "somemail@server.com";
НашОбъект.ВыполнитьРасчет(СуммаПлатежа, "За коммунальные услуги");

то будет выполнен следующий опрос:

  1. Есть ли свойство «Адресат»
  2. Поддерживает ли оно запись
  3. Есть ли метод ВыполнитьРасчет
  4. Сколько у него параметров
  5. Есть ли у него возвращаемое значение
  6. Какие умолчания у необязательных параметров (если есть)

Здесь полезнее всего смотреть в пример и сверяться с документацией. Реализация всех этих опросов довольно прямолинейна. За взаимодействие отвечает целый зоопарк методов. Все рассматривать не буду, они довольно хорошо документированы, а кроме того, реализуются просто. Рассмотрены будут только наиболее значимые моменты, в которые нам, как «чайникам», надо будет залезть своими ручонками :). Основной подход следующий: при первом упоминании того или иного свойства или метода платформа попросит нас поискать его по имени. Мы должны будем ответить уникальным номером данного свойства (метода). Все дальнейшее общение будет происходить только по номерам. Здесь-то и помогут упомянутые перечисления, хранящие эти номера.

Свойства

Первое, что стоит рассмотреть - это инфраструктура свойств. Платформа запрашивает существование свойства методом FindProp

fp

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

Далее, метод GetPropName выполняет обратную задачу, получает имя свойства по его номеру. Строка с именем также выделяется через менеджер памяти предприятия. Подозреваю, что метод GetPropName совместно с GetNProps используется, когда мы разворачиваем свойства объекта «плюсиком» в отладчике. Тогда платформа получит общее число свойств и для каждого из них запросит имя.

Следующая пара методов IsPropReadable/IsPropWritable. Здесь все просто, для указанного номера свойства мы должны сказать можно ли его читать/писать.

Получение и запись значений выполняются методами GetPropVal/SetPropVal. Здесь стоит остановиться подробнее. Мы начинаем работать с типами 1С:Предприятия, а значит, на сцену выходит Variant.

dd

Шаблон компоненты определяет набор вспомогательных макросов для упрощения работы с Variant. Первый из них - это проверка типа значения. Например, макрос TV_VT позволяет проверить/установить тип значения. Определены также именованные константы для каждого из поддерживаемых типов. Эти константы и их соответствия типам 1С:Предприятия перечислены в документации.

Макрос TV_BOOL получает из варианта булево значение, с которым можно работать. По аналогии получаются целые значения (TV_INT), строки (TV_WSTR) и другие. Точные значения есть в коде, их всегда можно посмотреть.

Важный момент - мало присвоить варианту какое-то значение, нужно также присваивать и действительный тип. Обратите внимание на GetPropVal. Помимо присваивания TV_BOOL = true идет присваивание типа: TV_VT = VTYPE_BOOL. Если тип не присвоить, платформа не будет знать - какой тип значения ей вернули. Разумеется, можно накосячить и задать неверный тип. Часто это сопровождается падением платформы.

Подведем итог вышесказанного:

Получаем значение из варианта:

bool someVariable = TV_BOOL(pVariant);

Записываем значение в вариант:

TV_VT(pVariant) = VTYPE_BOOL; // действующий тип данных

TV_BOOL(pVariant) = someBooleanVariable; // устанавливаем само значение

А теперь - горбатый методы!

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

  • Если метод может возвращать значение, значит, его можно использовать в «Вычислить» и записывать справа от операции присваивания в языке 1С. Если нет, то это процедура и подобные вещи будут приводить к исключению «Использование процедуры как функции»
  • У метода есть параметры. Платформа должна знать их количество. Если при вызове указано аргументов больше чем в сигнатуре метода, то возникает ошибка «Слишком много параметров»
  • Если методу передано недостаточное количество аргументов, значит, некоторые из них могут быть необязательными, а если необязательных параметров нет, то возникает ошибка «Недостаточно параметров».
  • При вызове, если это процедура, то возвращаемого значения быть не может. Если это функция, то есть возвращаемое значение. Его тоже нужно обработать.

Есть ряд простых методов, назначение которых понятно из их имен и из документации. Сюда относятся HasRetVal, GetNParams, GetParamDefValue. Их предлагаю не рассматривать, примера более чем достаточно. Наш интерес будет направлен в сторону непосредственной реализации полезной нагрузки. Она реализуется в методах CallAsProc и CallAsFunc. Первый отвечает за вызов процедур, второй - за вызов функций. Отличаются они тем, что CallAsFunc имеет дополнительный выходной параметр, в котором мы передадим платформе возвращаемое значение функции.

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

p

В примере номер метода анализируется в switch/case и в зависимости от номера выполняется логика метода. Для методов Включить/Выключить просто устанавливается флажок. Интересен метод ПоказатьВСтрокеСтатуса. Он показывает то, что ему передали в строке состояния окна 1С:Предприятия. Для этого используется объект подключения к платформе m_iConnect, тот, что был «выдан» нам при регистрации компоненты. Полный перечень его возможностей описан в документации.

Интересный момент. Здесь, в примере, не проверяется тип приехавшего из 1С значения, а просто вызывается SetStatusLine со строковой частью Variant. Я подозреваю, что если вызвать метод компоненты из языка 1С, передав туда число или дату (вместо строки), то работать ничего не будет… Опять же, пусть гуру поправят, но кажется, что указатель pwstrVal будет указывать неизвестно куда, если из предприятия приехало скажем, число, а не честная строка. При вызове SetStatusLine, платформа попытается прочитать с неизвестного адреса строку и, скорее всего, упадет. Лучше всегда проверять ожидаемый тип. Мало ли чего.

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

1

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

Далее, здесь проверяется тип переданного параметра. Если это узкая строка (VTYPE_PSTR), то используется char-овая часть варианта. В примере написано paParam->pstrVal, но можно воспользоваться макросом TV_STR, будет то же самое, но еще и соблюдено единообразие работы с вариантом.

Если это широкая строка (VTYPE_PWSTR), то выполняется преобразование сначала к wchar_t, а затем к char. Дело в том, что нам из языка 1С в данный метод передается путь к файлу, который затем используется в функции fopen(char*). Эта функция на вход требует тип char*, а из платформы к нам придет WCHAR_T. Для корректной работы и выполняются преобразования строк.

Ну и последнее, если это вообще не строка, то вызов признается неудачным, возвращается false.

Далее будет открыт файл, и в случае ошибки будет выдано сообщение (это код для краткости пропущен). Если все хорошо, то в 1С возвращаются двоичные данные картинки.

2

Мы выделяем память под двоичные данные менеджером памяти. Это логично, двоичные данные станут полноценным объектом внутри платформы, и распоряжаться ими должна именно она. Память выделяется для варианта pvarRetValue, представляющего собой возвращаемое значение функции внешней компоненты.

В выделенный буфер считывается файл целиком, кроме того, обязательно указывается байтовый размер в свойстве варианта strLen и тип данных варианта VTYPE_BLOB. Если память выделится удачно, то возвращаем true, как признак удачного вызова всей функции.

Таким образом, когда в языке 1С будет написано:

ДвоичныеДанные = Компонента.ЗагрузитьКартинку("C:\pic.jpg");

будет вызван метод CallAsFunc объекта компоненты с передачей пути и возвратом двоичных данных, как описано выше.

В случае успеха переменная ДвоичныеДанные будет содержать полноценный объект языка 1С. Когда он выйдет из области видимости вся занятая им память будет освобождена платформой. Именно поэтому выделялась она через менеджер памяти.

Заключение

Рассказ писался чайником для чайников, поэтому, скорее всего, пестрит терминологическими неточностями. Тем не менее, цель статьи - быстрое введение во внешние компоненты. Если в сжатые сроки, без лишних заморочек, без долгих разбирательств нужно быстро сделать компоненту, то я надеюсь, что эта статья вам поможет. Если от каких-либо моих ошибок вам, как гуру C++, стало плохо - сообщайте в комментариях, будем исправлять.

Спасибо за внимание.


Теги:  

Похожие темы (5)

Рейтинг@Mail.ru Rambler's Top100

Поиск