1с создать форму веб интерфейса

Обновлено: 07.07.2024

При разработке приложений с глобальным взаимодействием уже давно известна архитектура SOA (Service Oriented Architecture).

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

Существует достаточно большое количество реализации этой архитектуры. Одним из видов такой реализации является технология основанная на связке специфицированных консорциумом w3c таких технологий, как веб-сервисы и протоколы SOAP, WSDL, WADL и т.п., которые в свою очередь основаны на XML. Уже достаточно длительное время эта технология интегрирована в платформу 1с Предприятие. Благодаря этому 1с предприятие может служить "сервером приложений", поставщиком сервисов, можно организовать взаимодействие между 1с, и приложениями, написанными на других платформах, можно организовать взаимодействие между различными системами на базе 1с и так далее.

web-сервисов и WSDL, каковую архитектуру используют туристические агентства, гостиницы, ритейлеры и т.п.

Часть 1. Здравствуй, Name!

Есть достаточное количество противников SOA и сторонников других технологий, как и тех, кто недолюбливает 1С. Однако существующая технология разработки на платформе 1с позволяет приступить к разработке и получить готовый результат довольно быстро при весьма поверхностном знакомстве с подробностями спецификаций SOA, WSDL и веб-сервисов, по сравнению со многими другими известными продуктами как от гигантов софтверной индустрии, так и с бесплатными open-source решениями, что само по себе не является ни плюсом ни минусом, но может заставить задуматься.

Чтобы окончательно в этом убедиться я твердо решил в качестве примера реализовать при помощи web-сервисов хрестоматийный пример, на котором большинство студентов, изучавших вычислительную технику и программирование, практиковались ещё во время учебы в ВУЗ-ах, а именно игру «Жизнь» - клеточный автомат, придуманный английским математиком Джоном Конвеем в 1970 г.

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

Для начала надо всё же установить веб-сервер, который будет обрабатывать запросы, это может быть Apache или IIS. Я предпочитаю Apache. Поскольку

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

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

Минус файловой версии - невозможность отладки серверных процедур.

Теперь приступим к реализации. В группе web-сервисы создадим новый объект с простым именем WebServiceTest, операцией с именем GetHelloString, которую будет обрабатывать функция Привет(Name) и параметром Name. И операция и параметр добавляются командой "добавить". Тип значения параметра Name - string (берется из пространства имен


Тело функции Привет() модуля сервиса будет содержать только одну строку:

Осталось только опубликовать сервис. Заходим в меню администрирование -> публикация на web-сервере. Откроется форма, в которую мы введем параметры публикации. Имя публикации должно совпадать с именем каталога на web-сервере.

В поле «Каталог» вводим путь к нашему каталогу на web-сервере, который мы создали ранее, то есть C:\Apache24\htdocs\WebServices\

Остальные параметры вы можете рассмотреть на рисунке Рис. 3


перезапустим web-сервер, используя Apache monitor (оснастку служб Windows, закладку «службы» диспетчера задач, командную строку, bash, монитор процессов - что там у вас есть под рукой) чтобы данные публикации были считаны Апачем заново. Обновление публикации и перезапуск веб-сервера нужно делать после каждого сохранения конфигурации, связанного с изменениями веб-сервиса.

Результат должен выглядеть как-то так:

Клиентская часть будет содержать чуть больше кода. Можно обращаться к сторонним сервисам двумя способами:

- использовать ws-ссылку (объект метаданных)

- создать ws-определение программно

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

Создадим новую обработку с реквизитом Name, разместим его на форме, добавим форме команду Тест с двумя поцедурами, на клиенте и на сервере.

Параметры конструктора объекта WSПрокси ИмяСервиса и ИмяТочкиПодключения можно найти в XML-тексте, который возвращает наш сервис по URI А именно в элементе <service name="ИмяНашегоСервиса">

где ИмяСервиса — это атрибут Name этого элемента, то есть <service name="WebServiceTest">

ИмяТочкиПодключения — это атрибуты Name вложенных элементов

Обычно мы имеем две точки для разных версий SOAP, в нашем случае они называются

WebServiceTestSoap и WebServiceTestSoap12 — можно использовать любой из них.

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

В структуре визуального редактора компонент расположен по пути Сервисы > Веб-формы > Веб-форма.

Компонент относится к модулю Веб-формы.

Параметры

  • new - страница добавления результата, т.е. будет представлена выбранная веб-форма для заполнения;
  • list - страница со списком результатов данной формы.
Примечание:количество записей на странице со списком результатов зависит от прав доступа пользователя, установленных в настройках формы и в настройках ее статуса. Примечание: количество записей на странице со списком результатов зависит от прав доступа пользователя, установленных в настройках формы и в настройках ее статуса. Примечание: чтобы поле отображалось в фильтре на странице со списком результатов, для данного вопроса должна быть заполнена закладка Фильтр в форме редактирования вопроса веб-формы в расширенном режиме.
  • new - cтраница добавления результата;
  • list - cтраница списка результатов;
  • edit - cтраница редактирования результата;
  • view - cтраница просмотра результата.
  • A - Авто + Управляемое: автоматически обновляет кеш компонентов в течение заданного времени или при изменении данных;
  • Y - Кешировать: для кеширования необходимо определить время кеширования;
  • N - Не кешировать: кеширования нет в любом случае.

Пример вызова

Пользовательские комментарии

Мы будем рады, если разработчики добавят свои комментарии по практическому использованию методов системы.

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

Также Пользовательские комментарии не являются местом для обсуждения функционала. По подобным вопросам обращайтесь на форумы.

Началось все с вопроса "А можно ли сделать так чтобы любой желающий мог получить доступ к нашему веб-клиенту, и для этого не нужно было бы всех заводить руками?". А дальше начались поиски решения) Задача стояла весьма увлекательная. Я, как человек мельком знакомый с веб-разработкой, и по основному профилю специализирующийся на разработке в 1С, видел свет в конце туннеля, но короткого пути не знал) Для решения моей задачи я обратился в интернет. Результатом поисков, проб и ошибок, стало такое решение.

Тестировалось все на
1. 1С 8.3.8 и 1С 8.3.13, но думаю будет работать и на других релизах 8.3

1. Универсальная форма для входа и регистрации в базе 1С. При логине пользователь не видит стандартного окна аутентификации 1С

3. Восстановление пароля пользователя 1С из веб-формы

4. При регистрации и восстановлении пароля пользователь получает письма с паролями

Для тех кому интересны мытарства с разворачиванием веб-сервера и публикацией, смотрим под кат

Для простоты разворачивания демонстрационной базы будем использовать Apache, великий и могучий. Он прост и понятен в настройке, для наших целей, это его главное преимущество перед всевозможными проблемами IIS.

После этого по экрану побегут строки, для нас главное увидеть, что везде написано Success и не написано Error. Как правило установка сервиса проходит успешно, и ошибки в основном происходят в момент ее тестового запуска. Если увидели ошибки, то как правило все они хорошо гуглятся и быстро решаются.

После того как установка прошла успешно желательно зайти в папку Apache\bin в проводнике и запустить ApacheMonitor. Для того чтобы в трее появился интерфейс быстрого управления службой Apache.

Для того чтобы потом удалить Apache нужно тоже зайти в консоль, выполнить то же самое. но с ключом -k uninstall

8. После установки Apache нужно установить модуль расширения web-сервера 1С. Для этого зайдите в список установленных приложений, выберите 1С, и нажмите "Изменить", после в диалоге установки выберите в списке прочего "Модуль расширения web-сервиса"

9. Установка окружения завершена. Остался только сам процесс публикации, который выполняется в пару кликов. Описывать не буду, надеюсь рядовой одинесник без труда с этим разберется. на этом все.

Архитектура решения такова:

Нам остается только подставить правильный адрес в атрибут action нашей формы. И готово.

С остальными функциями веб-формы логина все не так просто.

Хочется переделать на CURL для расширенной работы с ответом веб-сервиса, и переделать вызовы на AJAX. Но пока так.

3. Следующим по очереди идет файл config.php в папке assets, в нем указаны конфигурационные данные для подключения к нашему веб-сервису. код прост и незатейлив. Но сильно упрощает подключение.

из этого файла выбираются параметры для всех операций

4. и style.css, но это не так интересно. Стили здесь не главное.

Дальше переходим к стороне 1С.

/register и /resetPassword


Оба шаблона содержат POST-методы и устроены однообразно

Листинг функции регистрации в упрощенном виде выглядит так

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

Для тех кто станет это скачивать и пробовать. Нужно сделать следующее

1. .Заполнить параметры подключения к почтовому серверу в процедуре ПочтовыйПрофиль(), тогда почта начнет отправляться.

Одной из приятных особенностей технологии 1С:Предприятие является то, что прикладное решение, разработанное по технологии управляемых форм, может запускаться как в тонком (исполняемом) клиенте под Windows, Linux, MacOS X, так и как веб-клиент под 5 браузеров – Chrome, Internet Explorer, Firefox, Safari, Edge, и все это – без изменения исходного кода приложения. Более того – внешне приложение в тонком клиенте и в браузере функционирует и выглядит практически идентично.
Найдите 10 отличий (под катом 2 картинки):

Окно тонкого клиента на Linux:

image

То же окно в веб клиенте (в браузере Chrome):

image

Зачем мы сделали веб-клиент? Говоря несколько пафосно, такую задачу перед нами поставило время. Уже давно работа через Интернет стала необходимым условием для бизнес-приложений. Вначале мы добавили возможность работы через Интернет для нашего тонкого клиента (некоторые наши конкуренты, кстати, на этом и остановились; другие, напротив, отказались от тонкого клиента и ограничились реализацией веб-клиента). Мы же решили дать нашим пользователям возможность выбрать тот вариант клиента, который им подходит больше.

image

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

Постановка задачи

Итак, требования к проекту: веб-клиент должен делать то же самое, что и тонкий клиент, а именно:

  1. Отображать пользовательский интерфейс
  2. Исполнять клиентский код, написанный на языке 1С

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

И тонкий клиент (при работе через веб), и веб-клиент пользуются одним и тем же набором веб-сервисов для общения с сервером приложений 1С. Реализация у клиентов, конечно, разная – тонкий клиент написан на С++, веб-клиент – на JavaScript.

Немного истории

Проект создания веб-клиента стартовал в 2006 году, в нем (в среднем) участвовала команда из 5 человек. На отдельных этапах проекта привлекались разработчики для реализации специфической функциональности (табличного документа, диаграмм и т.д.); как правило, это были те же разработчики, что делали эту функциональность в тонком клиенте. Т.е. разработчики заново писали на JavaScript компоненты, ранее созданные ими на C++.

С самого начала мы отвергли идею какой-либо автоматической (хотя бы частичной) конверсии C++ кода тонкого клиента в JavaScript веб-клиента ввиду сильных концептуальных различий этих двух языков; веб-клиент писался на JavaScript с чистого листа.

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

Первая версия платформы 1С:Предприятие с поддержкой веб-клиента вышла в 2009 году. Веб-клиент на тот момент поддерживал 2 браузера – Internet Explorer и Firefox. В первоначальных планах была поддержка Opera, но из-за непреодолимых на тот момент проблем с обработчиками закрытия приложения в Opera (не удавалось со 100%-ной уверенностью отследить, что приложение закрывается, и в этот момент произвести процедуру отключения от сервера приложений 1С) от этих планов пришлось отказаться.

Структура проекта

Всего в платформе 1С:Предприятие есть 4 проекта, написанных на JavaScript:

  1. WebTools – общие библиотеки, используемые остальными проектами (сюда же мы включаем Google Closure Library).
  2. Элемент управления ФорматированныйДокумент (реализован на JavaScript и в тонком клиенте, и в веб-клиенте)
  3. Элемент управления Планировщик (реализован на JavaScript и в тонком клиенте, и в веб-клиенте)
  4. Веб-клиент

Структурно веб-клиент по-крупному разделяется на следующие подсистемы:

  • Управляемый интерфейс клиентского приложения
    • Общий интерфейс приложения (системные меню, панели)
    • Интерфейс управляемых форм, включающий, в том числе, около 30 элементов управления (кнопки, различные типы полей ввода – текстовые, цифровые, дата/время и пр., таблицы, списки, графики и т.д.)
    • Работа с криптографией
    • Работа с файлами
    • Технология внешних компонент, позволяющая их использовать как в тонком, так и веб-клиенте

    Особенности разработки

    Реализация всего вышеописанного на JavaScript – дело непростое. Возможно, веб-клиент 1С – одно из самых больших client-side приложений, написанных на JavaScript – около 450.000 строк. Мы активно используем в коде веб-клиента объектно-ориентированный подход, упрощающий работу с таким большим проектом.

    Для минимизации размера клиентского кода мы вначале использовали свой собственный обфускатор, а начиная с версии платформы 8.3.6 (октябрь 2014) стали использовать Google Closure Compiler. Эффект использования в цифрах – размер фреймворка веб-клиента после обфускации:

    • Собственный обфускатор – 1556 кб
    • Google Closure Compiler – 1073 кб

    Google Closure Compiler очень хорошо работает с объектно-ориентированным кодом, поэтому его эффективность именно для веб-клиента максимально высокая. Closure Compiler делает для нас несколько хороших вещей:

    • Статическая проверка типов на этапе сборки проекта (обеспечивается тем, что мы покрываем код аннотациями JSDoc). В итоге получается статическая типизация, очень близкая по уровню к типизации в С++. Это помогает отловить достаточно большой процент ошибок на стадии компиляции проекта.
    • Уменьшение размера кода через обфускацию
    • Ряд оптимизаций выполняемого кода, например, такие как:

    • inline-подстановки функций. Вызов функции в JavaScript – достаточно дорогая операция, и inline-подстановки часто используемых небольших методов существенно ускоряют работу кода.
    • Подсчет констант на этапе компиляции. Если выражение зависит от константы, в него будет подставлено фактическое значение константы

    Для анализа кода мы используем SonarQube, куда интегрируем статические анализаторы кода. С помощью анализаторов мы отслеживаем деградацию качества исходного кода на JavaScript и стараемся ее не допускать.


    Какие задачи решали/решаем

    В ходе реализации проекта мы столкнулись с рядом интересных задач, которые нам пришлось решать.

    Обмен данными с сервером и между окнами

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

    • Код, приходящий с сервера в виде структур данных
    • Код другого окна приложения


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

    We used Virtual DOM before it became mainstream)

    Как и все разработчики, имеющие дело со сложным Веб UI, мы быстро поняли, что DOM плохо подходит для работы с динамическим пользовательским интерфейсом. Практически сразу был реализован аналог Virtual DOM для оптимизации работы с UI. В процессе обработки события все изменения DOM запоминаются в памяти и, только при завершении всех операций, накопленные изменения применяются к DOM-дереву.

    Оптимизация работы веб-клиента

    Чтобы наш веб-клиент работал быстрее, мы по максимуму стараемся задействовать штатные возможности браузера (CSS и т.п.). Так, командная панель формы (расположенная практически на каждой форме приложения) отрисовывается исключительно средствами браузера, динамической версткой на базе CSS.

    image

    Тестирование

    Для функционального тестирования и тестирования производительности мы используем инструмент собственного производства (написанный на Java и C++), а также набор тестов, построенных на базе Selenium.

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

    Инструмент также проводит замеры производительности приложений с точностью до 25 миллисекунд. В ряде случаев мы закольцовываем части сценария (например, несколько раз повторяем ввод заказа) для анализа деградации времени выполнения со временем. Результаты всех замеров записываются в лог для анализа.

    image


    Наш инструмент тестирования и тестируемое приложение

    Наш инструмент и Selenium дополняют друг друга; например, если какая-то кнопка на одном из экранов поменяла свое местоположение – Selenium это может не отследить, но наш инструмент заметит, т.к. делает попиксельное сравнение скриншота с эталоном. Также инструмент в состоянии отследить проблемы с обработкой ввода с клавиатуры или мыши, так как именно их он и воспроизводит.

    Тесты на обоих инструментах (нашем и Selenium) запускают типовые сценарии работы из наших прикладных решений. Тесты автоматически запускаются после ежедневной сборки платформы «1С:Предприятие». В случае замедления работы сценариев (по сравнению с предыдущей сборкой) мы проводим расследование и устраняем причину замедления. Критерий у нас простой – новая сборка должна работать не медленнее предыдущей.

    Для расследования инцидентов замедления работы разработчики используют разные инструменты; в основном используется Dynatrace AJAX Edition производства компании DynaTrace. Проводится запись логов выполнения проблемной операции на предыдущей и на новой сборке, затем логи анализируются. При этом время выполнения единичных операций (в миллисекундах) может не быть решающим фактором – в браузере периодически запускаются служебные процессы типа уборки мусора, они могут наложиться на время выполнения функций и исказить картину. Более релевантными параметрами в этом случае будет количество выполненных инструкций JavaScript, количество атомарных операций над DOM и т.п. Если количество инструкций/операций в одном и том же сценарии в новой версии увеличилось – это почти всегда означает падение быстродействия, которое нужно исправлять.

    Расширения браузеров

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

    • для работы с файлами
    • для работы с криптографией
    • работа с внешними компонентами

    При работе в Safari наши расширения используют NPAPI, при работе в Internet Explorer — технологию ActiveX. Microsoft Edge пока не поддерживает расширения, поэтому веб-клиент в нем работает с ограничениями.

    Дальнейшее развитие

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

    Другие задачи — развитие архитектуры, рефакторинг, повышение производительности и надежности. Например, одно из направлений – дальнейшее движение в сторону асинхронной модели работы. Часть функциональности веб-клиента на настоящий момент построена на синхронной модели взаимодействия с сервером. Асинхронная модель сейчас становится в браузерах (и не только в браузерах) более актуальной, и это заставляет нас модифицировать веб-клиент путем замены синхронных вызовов на асинхронные (и соответствующего рефакторинга кода). Постепенный переход к асинхронной модели объясняется необходимостью поддержки выпущенных решений и постепенной их адаптации.

    Читайте также: