Web и http сервисы 1с в чем разница
Ещё один дисклеймер (спустя многие времена)
Вступление
Когда появляется новая версия какого-то программного продукта, то естественно, в первую очередь хочется понять, чего же такого в нем появилось нового. В случае с "1С:Предприятие 8.1" такой новой "фичей" для меня стали web-сервисы. Про web-сервисы написано и сказано много, поскольку существует эта технология по компьютерным меркам достаточно давно. По-этому я повторяться не буду, за справками отправляю всех к Яндексу. Скажу лишь, что с выходом новой редакции платформы "1С:Предприятие 8.1" у 1Сников появилась возможность создавать и использовать технологию web-сервисов, находясь, так сказать, в родной среде. В этой статье я хочу показать, как использовать внешние web-сервисы в своих разработках.
Для тех, кто совсем "не в теме": о web-сервисах "на пальцах"
Откуда ноги, т.е. крылья растут
Он сказал: "Поехали!"
"То взлет, то посадка. "
Для работы с web-сервисом я добавил в конфигурацию обработку "ТаблоВылетов", а в ней - одну форму, которую назначил основной. На форму я положил поле выбора "ВыборАэропорта", поле ввода "ДатаРейса", панель "ПанельТабло" с двумя страницами "Прилет" и "Вылет", при этом я снял флаг "Распределять по страницам" в свойствах панели, и табличное поле "ТаблицаТабло".
Взаимодействие с web-сервисом происходит по принципу "запрос-ответ", при этом для web-сервиса создается специальный объект-посредник. Поэтому я добавил реквизит формы "СервисАэрофлот" произвольного типа.
Если внимательно почитать описание сервиса, то можно увидеть, что web-сервис предоставляет данные о прилетах и вылетах через вызовы методов Arrival и Departure соответственно. При этом оба метода принимают в качестве параметров код аэропорта и нужную дату. Кроме того, web-сервис предоставляет возможность получить список аэропортов, по которым имеются данные в системе. Достаточно очевидным является следующий сценарий взаимодействия с web-сервисом:
1. Получить список аэропортов;
2. Выбрать нужный аэропорт и дату;
3. Получить данные о прилетах или вылетах;
Но прежде чем обращаться к web-сервису, необходимо инициализировать объект-посредник (типа WSПрокси), что я и сделал в обработчике открытия формы:
Первым параметром передается URI пространства имен web-сервиса. Узнать его можно открыв свойства web-сервиса в дереве WS-ссылки. Вторым и третьим параметром параметрами передаются соответственно имя и порт web-сервиса.
(не надо путать понятия "имя", "порт", "прокси" и т.п. в применении к web-сервисам с более привычными понятиями протокола TCP/IP. Соответствие между ними если и есть, то скорее смысловое. В общем случае нужно понимать, что, например порт web-сервиса и TCP-порт - это абсолютно разные вещи).
Таким образом я проинициализировал объект СервисАэрофлот типа WSПрокси, который по-сути своей является "оберткой" web-сервиса. Через него я смогу обращаться к методам web-сервиса как к "родным" методам платформы.
Первым делом я получил список аэропортов и заполнил список поля выбора "ВыборАэропорта":
Тут нужен небольшой комментарий по конструкции СписокАэропортов=СервисАэрофлот.AirportList().ПолучитьСписок("list");
Дело в том, что значения, возвращаемые методами web-сервисов, представляются в платформе объектами типа ОбъектXDTO. Поскольку тематика технологии XDTO выходит за рамки этой статьи, скажу лишь, что для превращения этого объекта в список (чем он и является), я вызвал его метод ПолучитьСписок(). Остальное в коде достаточно очевидно, включая названия полей структуры Аэропорт, которые я нашел на странице описания web-сервиса.
Теперь можно запустить конфигурацию и убедиться, что список поля выбора заполняется названиями аэропортов:
"День отлета, день прилета. "
Теперь у меня практически все готово для того, чтобы заставить мое табло функционировать. Осталось только его "выкрасить и выбросить" :) Чем и займусь:
Для того, чтобы проверить как это все работает, я добавил на командную панель формы кнопку "Обновить" с соответствующей картинкой, а в ее обработчике написал такое:
Сохраняю, запускаю, выбираю, нажимаю, получаю:
В интернете полно всяких описанных случаев, каких хочешь.
Чтобы работник опознавался автоматически нужно на клиенте в обозревателе оставлять печеньки :)
А все остальное вкусовщина. Так что разница просто в документации и в ее способе передачи :)
(3)Конечно не будет отличатся если смотреть очень издалека. Издалека и мальчик от девочки не отличается - человек же.
(5) вы меня прям заинтриговали. Чем же принципиально отличаются эти технологии? Кроме того, что соап дает всдл, в котором описаны типы и функции,а для хттп - надо описывать отдельно это все, и обычно юзают фигнб разную типа свагера для этого.
А теперь мы возьмем реальные нагруженные проекты, где вам валются бинарники на вход (типо зипы, или base64bin), а не голый хмл.
Внимание, вопрос - чем хттп отличается от соапа в данной случае?
Как всегда дьявол кроется в деталях.
Понятно желание автора опубликовать свой опыт, но даже на этом ресурсе прилично материалов с которыми можно состыковаться.
Оочень большие картинки, в которых немного толку.
Что хотели показать первой схемой? То что 1С есть другие веб серверы которые умеют работать с СУБД? Обычно такая же трехзвенка, и NGINX/Apache используют сокеты/сервисы а конкретном языке программирования.
"Такая страничка с двумя полями уже может передавать данные на внешний HTTP сервис: " - описание формата запроса который прилетает в сервис нет.
Откройте для себя тег CODE редактора, в статье еще можно указать язык, для адекватной подсветки (касается и примеров кода на 1С)
"Вот пример документации. Заголовок, ответ, пример, описание полей данных:" - откройте для себя OpenAPI с переиспользованием в тестах postman например.
"Когда отправляем партнеру ответ, пишем в лог." - в каком формате ведете лог?
"это разделение методов обработки самого HTTP запроса и методов обработки данных, которые являются методами бизнес-логики." - возможно дойдете до одной точки входа в сервис и предобработки запроса, наработки по этой теме есть в двух статьях.
Оформите ссылку на код нормально, например на репо github.
Прошлись по верхам, получилась маркетинговая статья.
Irwin; kirillkr; Yashazz; litonchik; dreamadv; alexeyo51; igo1; CSiER; artbear; vano-ekt; rpgshnik; Drivingblind; ardn; + 13 – Ответить
(4) Дык это и есть сбор хайпа и плюсиков - позиционируется как "обзор" или "для новичков" в зависимости от характера упрёков авторам, а реальная полезность весьма низкая. Увы.
* Неопытность автора в данном вопросе следует из отсутствия предваряющего все "коллекции" указания версии. Т.е. грамотно д.б. так: GET/v213/orders/ и т.п.
* Из предыдущего следует, что обработка методов разных версий будет различаться.
* Обязательно должен существовать тестовый стенд новых версий, чтобы партнёры могли выполнять адаптацию и тестирование своих КИС на готовность к новой версии.
* Новые версии апи должны проходить как минимум одну неделю на тестовой среде для возможности партнёрам адаптировать свои системы.
* Должна существовать рассылка с добровольной подпиской на неё о новых версиях апи, чтобы партнёры могли поймать момент, когда вы инициируете процесс выкатки новой версии апи.
* Упоминаются входящие данные в типе структуры и вопрос валидации данных. Это взаимосвязанные вещи и решаются они использованием пакетов XDTO и объектной модели данных - не колхоз из структур и массивов, а объекты XDTO.
* Все объекты XDTO д.б. тщательным образом описаны в пакете. Где есть явные ограничения на значения, везде надо их указывать отдельно в типах XDTO, чтобы точнее валидировать входящие и исходящие данные.
* Почему-то автор избегал упоминания такого распространённого продукта как swagger. Он как раз предназначен для документирования апи и очень удобен для любых платформ партнёров.
И я бы обратил внимание, что GET-запросы уместны только в случае ограниченных данных. Если же вы хотите получить статус по списку заказов, то этот список может не влезть в 4К(зависит от веб-серверов) поля QUERY запроса. Очень хорошо, что вы понимаете изначальную суть GET и POST запросов и разницу между ними, но на текущий момент (кажется, в вики это описано) они утратили изначальный смысл. Обычно все используют запросы POST и информация из QUERY перемещается в BODY запроса в формате json. Там нет ограничений на объём. Попробуйте, это удобнее.
Приведу несколько важных фрагментов из Вики :
С помощью POST запросов можно было бы представлять новых клиентов, каждый из которых содержал бы имя, адрес, контактные данные и тому подобное. Разработчики сайтов отошли от этой концепции по двум причинам. Во-первых, нет никаких технических причин для URI текстуально описывать подчинённые веб-ресурсы, на которых будут сохранены данные, посланные методом POST. В самом деле, последняя часть URI более вероятно опишет страницу обработки веб-приложения и её технологию. Во-вторых, учитывая естественное ограничение большинства веб-браузеров использовать только методы GET или POST, разработчики понимали необходимость добавления дополнительных возможностей в метод POST, включая изменение существующих записей и их удаление.
Одной из приятных особенностей технологии 1С:Предприятие является то, что прикладное решение, разработанное по технологии управляемых форм, может запускаться как в тонком (исполняемом) клиенте под Windows, Linux, MacOS X, так и как веб-клиент под 5 браузеров – Chrome, Internet Explorer, Firefox, Safari, Edge, и все это – без изменения исходного кода приложения. Более того – внешне приложение в тонком клиенте и в браузере функционирует и выглядит практически идентично.
Найдите 10 отличий (под катом 2 картинки):
Окно тонкого клиента на Linux:
То же окно в веб клиенте (в браузере Chrome):
Зачем мы сделали веб-клиент? Говоря несколько пафосно, такую задачу перед нами поставило время. Уже давно работа через Интернет стала необходимым условием для бизнес-приложений. Вначале мы добавили возможность работы через Интернет для нашего тонкого клиента (некоторые наши конкуренты, кстати, на этом и остановились; другие, напротив, отказались от тонкого клиента и ограничились реализацией веб-клиента). Мы же решили дать нашим пользователям возможность выбрать тот вариант клиента, который им подходит больше.
Добавление возможности работы через Интернет для тонкого клиента было большим проектом с полной сменой архитектуры клиент-серверного взаимодействия. Создание же веб-клиента — и вовсе новый проект, начинавшийся с нуля.
Постановка задачи
Итак, требования к проекту: веб-клиент должен делать то же самое, что и тонкий клиент, а именно:
- Отображать пользовательский интерфейс
- Исполнять клиентский код, написанный на языке 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:
- WebTools – общие библиотеки, используемые остальными проектами (сюда же мы включаем Google Closure Library).
- Элемент управления ФорматированныйДокумент (реализован на JavaScript и в тонком клиенте, и в веб-клиенте)
- Элемент управления Планировщик (реализован на JavaScript и в тонком клиенте, и в веб-клиенте)
- Веб-клиент
Структурно веб-клиент по-крупному разделяется на следующие подсистемы:
- Управляемый интерфейс клиентского приложения
- Общий интерфейс приложения (системные меню, панели)
- Интерфейс управляемых форм, включающий, в том числе, около 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.
Тестирование
Для функционального тестирования и тестирования производительности мы используем инструмент собственного производства (написанный на Java и C++), а также набор тестов, построенных на базе Selenium.
Наш инструмент универсален – он позволяет тестировать практически любые оконные программы, а потому подходит для тестирования как тонкого клиента, так и веб-клиента. Инструмент записывает действия пользователя, запустившего прикладное решение «1С», в файл-сценарий. В это же время происходит запись изображений рабочей области экрана — эталонов. При контроле новых версий веб-клиента сценарии проигрываются без пользовательского участия. В случаях несовпадения скриншота с эталонным на каком-либо шаге тест считается провалившимся, после чего специалист по качеству проводит расследование – ошибка это или запланированное изменение поведения системы. В случае запланированного поведения эталоны автоматически подменяются на новые.
Инструмент также проводит замеры производительности приложений с точностью до 25 миллисекунд. В ряде случаев мы закольцовываем части сценария (например, несколько раз повторяем ввод заказа) для анализа деградации времени выполнения со временем. Результаты всех замеров записываются в лог для анализа.
Наш инструмент тестирования и тестируемое приложениеНаш инструмент и Selenium дополняют друг друга; например, если какая-то кнопка на одном из экранов поменяла свое местоположение – Selenium это может не отследить, но наш инструмент заметит, т.к. делает попиксельное сравнение скриншота с эталоном. Также инструмент в состоянии отследить проблемы с обработкой ввода с клавиатуры или мыши, так как именно их он и воспроизводит.
Тесты на обоих инструментах (нашем и Selenium) запускают типовые сценарии работы из наших прикладных решений. Тесты автоматически запускаются после ежедневной сборки платформы «1С:Предприятие». В случае замедления работы сценариев (по сравнению с предыдущей сборкой) мы проводим расследование и устраняем причину замедления. Критерий у нас простой – новая сборка должна работать не медленнее предыдущей.
Для расследования инцидентов замедления работы разработчики используют разные инструменты; в основном используется Dynatrace AJAX Edition производства компании DynaTrace. Проводится запись логов выполнения проблемной операции на предыдущей и на новой сборке, затем логи анализируются. При этом время выполнения единичных операций (в миллисекундах) может не быть решающим фактором – в браузере периодически запускаются служебные процессы типа уборки мусора, они могут наложиться на время выполнения функций и исказить картину. Более релевантными параметрами в этом случае будет количество выполненных инструкций JavaScript, количество атомарных операций над DOM и т.п. Если количество инструкций/операций в одном и том же сценарии в новой версии увеличилось – это почти всегда означает падение быстродействия, которое нужно исправлять.
Расширения браузеров
В случае, когда прикладному решению нужна функциональность, которой нет в JavaScript, мы используем расширения браузеров:
- для работы с файлами
- для работы с криптографией
- работа с внешними компонентами
При работе в Safari наши расширения используют NPAPI, при работе в Internet Explorer — технологию ActiveX. Microsoft Edge пока не поддерживает расширения, поэтому веб-клиент в нем работает с ограничениями.
Дальнейшее развитие
Одна из групп задач для команды разработки веб-клиента – это дальнейшее развитие функциональности. Функциональность веб-клиента должна быть идентична функциональности тонкого клиента, вся новая функциональность реализуется одновременно и в тонком, и в веб-клиенте.
Другие задачи — развитие архитектуры, рефакторинг, повышение производительности и надежности. Например, одно из направлений – дальнейшее движение в сторону асинхронной модели работы. Часть функциональности веб-клиента на настоящий момент построена на синхронной модели взаимодействия с сервером. Асинхронная модель сейчас становится в браузерах (и не только в браузерах) более актуальной, и это заставляет нас модифицировать веб-клиент путем замены синхронных вызовов на асинхронные (и соответствующего рефакторинга кода). Постепенный переход к асинхронной модели объясняется необходимостью поддержки выпущенных решений и постепенной их адаптации.
Написав пару простейших Get-запросов я отлаживал их на опубликованной на веб-сервере IIS файловой базе, набирая адрес запроса в адресной строке.
При этом нужно помнить, что нужно указать авторизацию, причем имя пользователя на русском этот сайт не понимает, завел пользователя на английском:
В адрес я ввожу адрес POST-запроса, выбираю метод POST, ввожу содержимое запроса (JSON) после чего нажимаю SEND и получаю ответ (JSON) в правом окошке.
ДЖ = Новый ЗаписьJSON ();
ДЖ . УстановитьСтроку ();
ДЖ . ЗаписатьНачалоОбъекта ();
ДЖ . ЗаписатьИмяСвойства ( «result» ); ДЖ . ЗаписатьЗначение ( result );
ДЖ . ЗаписатьИмяСвойства ( «message» ); ДЖ . ЗаписатьЗначение ( message );
…
ДЖ . ЗаписатьКонецОбъекта ();
СтрокаДЖ = ДЖ . Закрыть ();//Устанавливаем тело из JSON-строки
Ответ . УстановитьТелоИзСтроки ( СтрокаДЖ );Однако по странному изгибу мысли заказчика у меня возникла проблема. Дело в том, что создание заказа выполнялось через часть URL post, а изменение заказа через часть URL post/guid.
Т.е. если раньше у меня был один шаблон URL на каждый метод, тут пришлось сделать два шаблона и я не сразу понял, как это должно выглядеть. Но потом догадался, в итоге вышло так:
orderCreate имеет шаблон /order, а orderWork имеет шабон /order/. Изначально я все это пытался впихнуть в один шаблон order, не вышло.
Соответственно, для отладки PATCH-запросов я использую тот же сайт, только выбираю метод PATCH.
Со временем я столкнулся с ошибкой, которую не смог выявить без отладки, поэтому написал небольшую обработку, где вводил JSON-текст запроса, а она уже имитировала вызов метода сервиса:
Web-сервис «Клеверенс» — сервис для взаимодействия сторонних приложений между собой (в нашем случае это «1С: Передприятие» и сервер Mobile SMARTS ). Для того чтобы использовать web-сервис «Клеверенс», необходимо предварительно его настроить.
- Через REST (основной метод).
- Через COM-компоненту Mobile SMARTS (устаревший метод, используется как альтернативный).
Схема обмена данными между сервером 1С и сервером Mobile SMARTS с помощью web-сервера через REST
Компоненты схемы:
Проверить расположение серверной базы можно в окне «О программе» в базе «1С: Предприятие». Пункт «Сервер» будет отображать сетевое имя компьютера, на котором установлен сервер 1С.
Сервер Mobile SMARTS — специальная служба для обработки запросов на получение/ отправку документов, номенклатуры и других данных от клиентов с мобильных ТСД. Также на сервере хранятся серверные справочники, локальные справочники ТСД для отправки клиентам, а также документов ТСД.
Как это работает
Схема обмена данными между сервером 1С и сервером Mobile SMARTS с помощью web-сервера с установленной на нем COM-компонентой
Как это работает
Для того, чтобы работать с базой 1С в онлайн-режиме через веб-сервис, необходимо установить на сервер компоненты TerminalConnector и StorageConnector (или скопировать на сервер папку «Connectivity» из папки платформы MS), и запустить файл «COM. bat» от имени администратора.
Настройки подключения в обработке лучше осуществлять по строке подключения и настраивать от имени пользователя, который будет выполнять подключение к 1С во время онлайн-обмена с сервером Mobile SMARTS. Также необходимо указать, что компонента установлена на сервере 1С, и подключение выполняется оттуда.
Интеграционная обработка «вшивается» в справочник дополнительных отчетов и обработок, чтобы она была доступна серверу 1С. Сама папка базы MS серверу 1С недоступна, подробнее об этом в статье .
Читайте также: