Каждый современный человек владеет ноутбуком, но как самому убрать возникающие...
![Пропал звук на ноутбуке — что делать?](https://i0.wp.com/sovets.net/photos/uploads/120/8110495-2razrabotanyi-spetsialnyie-programmyi-kotoryie-testiruyut-audio-drayveryi-soundcheck.jpg)
Какие важнейшие требования предъявляются к бизнес-приложениям? Одними из самых главных являются следующие задачи:
OData — это веб-ориентированный API-интерфейс для доступа к данным и манипулирования ими. Он подобен API-интерфейсам mini-ODBC и JDBC, но в отличие от них специально ориентирован на Интернет. Точнее говоря, OData позволяет клиентам конструировать URI-идентификаторы для именования набора сущностей, осуществлять фильтрацию содержащихся в этом наборе сущностей, а также прослеживать отношения со связанными сущностями и коллекциями сущностей. Для получения дополнительной информации обратитесь к статье Introduction OData: Data Access for the Web, the cloud, mobile devices, and more (Представляем OData: доступ к данным с помощью Интернета, облачной среды, мобильных устройств и т. д.).
В схеме на рисунке 1 показано, как такой ресурс, как база данных, может быть выставлен в Интернете при посредстве OData-поставщика общего назначения. Синтаксис OData позволяет с помощью Web-браузеров подергать данные в вышеупомянутой базе данных различным манипуляциям (создание, обновление, удаление, запрос).
На рисунке 2 показана схема языка CSDL (Conceptual Schema Definition Language). CSDL — это опциональный инструмент, помогающий приложениям-потребителям понимать структуру выставляемых данных. CSDL подобен метаданным в JDBC and ODBC, он помогает клиентским приложениям понимать, к чему именно они обращаются.
В Интернете имеются тысячи веб-ориентированных API-интерфейсов. OData — это один из примеров такого API-интерфейса. Более подробную информацию о веб-ориентированных API-интерфейсах можно получить на веб-сайте: Programmable Web . Стандартизация таких интерфейсов позволит улучшить консолидацию в этом важной технологической области и поможет инновациям идти в ногу с потребностями рынка, в частности поддерживать новые конструкции данных и инициативы в сфере открытых данных.
Проект хартии по OData был представлен в организацию OASIS (Organization for the Advancement of Structured Information Standards). Ниже приведен фрагмент текста из этого документа.
Работа будет ориентирована на достижение следующих целей.
Документы со спецификациями OData, представленные в организацию OASIS, а также проект хартии доступны по следующим ссылкам.
Помимо спецификаций OData в организацию OASIS были представлены следующие четыре документа с расширениями OData.
Эти документы с расширениями призваны инициировать работу в предлагаемом техническом комитете OASIS по OData (OASIS OData Technical Committee). На веб-сайте организации OASIS можно прочитать полный текст хартии по OData и документы с расширениями.
Следующие продукты IBM поддерживают OData.
В данном параграфе приведено несколько простых примеров на OData, обращающихся к сервису Netflix.
В настоящее время используются тысячи веб-ориентированных API-интерфейсов. К числу популярных API-интерфейсов этой категории относятся картографические сервисы . По состоянию на июнь 2012 года на веб-сайте Programmable Web было перечислено более 6000 веб-ориентированных API-интерфейсов (см. заметку под названием: API Business Models Take Center Stage). Недавнее исследование компании Vordel показало, что "половина предприятий внедряет API-интерфейсы для построения новых бизнес-каналов", при этом 25% из этих интерфейсов разрабатывается специально для мобильных приложений.
Одна из интересных областей – какое отношение имеет OData к деятельности в области API-интерфейса Linked Data. Рабочая группа W3C Linked Data Platform (LDP) Working Group и технический комитет OASIS OData Technical Committee стремятся специфицировать API-интерфейсы REST-типа для получения данных и манипулирования ими в Интернете с использованием различных моделей данных. Платформа LDP базируется на модели данных была специфицирована компаний Microsoft и берет свое начало в модели Peter Chen"s Entity Relationship Model сформулированной в 1976 г. (Peter Chen). Модель EDM до сих пор используется при проектировании реляционных баз данных. Модель данных EDM базируется на преобразовании информации в сущности и в отношения. Эта модель использует специфические для определенной области значения, например, номера социального страхования, номера счетов-фактур, номера товаров, для ссылки на ресурсы и на их свойства, а также для связывания информации.
EDM представляет информацию способом, который хорошо знаком многим разработчикам, занимающимся данными. Это существенно облегчает понимание и использование этой модели разработчиками. RDF позволяет связывать данные в масштабе всего мира и поддерживает формирование умозаключений посредством логического вывода, т. е., позволяет выводить новые факты из существующей информации с помощью универсальных идентификаторов, ассоциированных определений и свойств.
Построение адаптеров между гетерогенными веб-ориентированными API-интерфейсами вполне возможно. К примеру, прототип адаптера для связывания рабочих элементов (workitem) решения , получаемых посредством API-интерфейс на базе Linked Data под названием OSLC (Open Services for Life Cycle Collaboration) , и документов Microsoft Sharepoint, получаемых посредством OData, можно найти по следующей ссылке: http://wiki.eclipse.org/Lyo/SharepointAdapter .
По мере расширения рынка появляются все новые API-интерфейсы. Хотя их возможности могут перекрываться до той или иной степени, не вызывает сомнения, что разработчики продолжат создавать инновации в этой перспективной технологической области по мере выявления новых сценариев применения.
Выражаю глубокую благодарность за отзывы и предложения моим коллегам: Elizabeth Cleary, Andrew Eisenberg, Diane Jordan, Arnaud Le Hors.
Давайте на минутку представим, что у нас есть информационные базы на платформе "1С:Предприятие 8", с данными которой нам нужно регулярно работать. Но, к сожалению, у нас нет возможности вносить какие-либо свои правки в их конфигурацию. Возможно это (при наличии полноценной платформы); или бесплатная "1С:УНФ для Украины. Микро "; или из-за преимуществ автоматического обновления не хотим снимать поддержку; или обслуживающая компания назвала стоимость своих услуг, которая не получила одобрения у руководства, а собственного "программиста 1С" нет...
И вот в таких условиях вам ставят задачу по интеграции этой базы и некоторой внешней системы. Что делать и какие у нас есть варианты? Возможно в комментариях меня дополнять, но я пока вижу ровно 5 путей:
Таким образом среди 5 вариантов самым быстрым и самым легким для администратора способом является автоматический доступ через протокол oData. Этот же вариант является кроссплатформенным.
А еще вариант с протоколом oData менее затратен с точки зрения разработки связки с базой 1С. Дело в том, что компания Microsoft усиленно его продвигает. Помимо выпуска OData SDK для разработки под.NET, AJAX, PHP, Java, JavaScript, WebOS и Objective-C, эта компания внедрила данный протокол в свои популярные продукты: Excel, PowerPoint, SharePoint, MsSQL и других. Таким образом вам не нужно создавать свою версию CommerceML и заниматься разбором XML и JSON текстов как на вашей стороне так и на стороне базы 1С, как если бы вы реализовывали свои собственные WEB- и HTTP-сервисы. При использовании OData у вас уже сразу будут готовые библиотеки для получения или модификации данных для применения в вашей внешней системе, в то время как на стороне базы 1С все будет происходит автоматически.
Минутка уже прошла?
Можем выдохнуть - у нас больше нет никаких ограничений и мы можем делать любую интеграцию, какую только захотим! Я специально ограничил нашу фантазия в начале, что бы мучительно долго не перечислять все варианты из известной книги "Технологии интеграции 1С:Предприятия" ISBN 978-5-9677-1462-7 авторства Гончарова Д.И. и Хрусталева Е.Ю (и тем более не тратить время на перечисление слабых сторон этих вариантов). Можете тут поверить мне на слово или можете начать дискуссию в комментариях, но вариант с OData все равно остается самым привлекательным.
Для тех, кто заинтересовался темой, прошу перейти на официальный сайт протокола - www.odata.org . Еще раз обращаю внимание, что не смотря на то, что актуальная версия протокола уже 4.0 и она была стандартизирована консорциумом OASIS еще 17 марта 2014 года , но в платформе "1С:Предприятие 8" по прежнему используется протокол более ранней версии 3.0. Кстати, не забудьте заглянуть в раздел экосистемы протокола и полюбоваться на упоминание нашей 1C:Enterprise, которая идет первой в списке:))
Как я уже упоминал, у вас должен быть веб-сервер. Начиная с версии 8.4 в составе серверной части платформы уже будет свой собственный веб-сервер, но пока нам нужно пользоваться сторонними - IIS или Apache. Как все настроить хорошо описано в желтой книжечке для администратора. Но если вы любите картинки и чужой опыт, то вот надергал в поиске: , и конечно же :) За полноту и актуальность предоставленных данных в указанных статьях не ручаюсь и вообще не знаком с авторами. Если возникнут проблемы, то читайте Руководство Администратора от вашей версии платформы - там есть все, что вам пригодится.
После того, как у вас уже установлен веб-сервер и он уже не падает при запуске из-за проблем с расширением доступа к 1С (давайте угадаю - вы поставили 32-разрядный Apache и 64-разрядную платформу), осталось совсем чуть-чуть. В конфигураторе заходим в меню "Администрирование" и нажимаем на команду "Публикация на веб-сервере...". В появившемся окошке необходимо указать следующие важные моменты:
После нажатия на кнопку "Опубликовать" по указанному в настройке пути будет создан файл default.vrd (XML-файл, который содержит данные, которые вы сделали в настройках публикации), а в конфиге веб-сервера будет добавлена запись о вашей публикации с тем именем, что вы указали. После публикации веб-сервер стоит перегрузить.
Несколько замечаний по выполнению публикации . Если у вас к публикации несколько баз, то для каждой из них должен быть свой каталог. Сразу подумайте о пользователе, которым собираетесь получать доступ к базе - у него должны быть нужные роли и имя латинскими буквами без спецсимволов (если вам в будущем охота воевать с кодировками, то можете сделать имя на русском с пробелами). Если вы работаете на Windows и у вас включен UAC, то перед публикацией конфигуратор следуют запускать от имени администратора. Если вы работаете на Linux - держитесь, мы в вас верим! :)
Вот как выглядит рабочий default.vrd с публикацией интерфейса OData:
Как видно из файла публикации - веб-серверу абсолютно все равно, где физически находится информационная база, путь к ней прописывается точно так же, как вы его прописываете в списке баз начального окна. Главное, что бы на одном компьютере с веб-сервером было установлено расширение доступа и местонахождение базы было по сети физически доступно для службы веб-сервера с правами на изменение. Так же возможны проблемы с получением лицензии и нужно будет покопаться в файле nethasp.ini, но это все стандартные процедуры и для обычной установки платформы.
После того, как вы выполнили публикацию и перезапустили сервер, можем проверить результаты в браузере. Для этого нужно указать имя веб-сервера, далее имя базы из публикации, далее путь /odata/standard.odata/ . У вас должны запросить пароль и вы увидите, что-то похожее на это:
Что бы продемонстрировать возможности рассматриваемой в статье технологии, я взял конфигурацию ""Управление торговлей (базовая)", редакция 10.3", в которой установлен режим совместимости "Версия 8.2.13" и потому все метаданные через REST-интерфейс доступны сразу, а вызов функции УстановитьСоставСтандартногоИнтерфейсаOData() для управления доступностью состава запрещен.
Если же у вас имеется доработанная торговля 10.3, которой вы установили режим совместимости "Версия 8.3.5" или выше, или если у вас есть более современные конфигурации, то все метаданные по умолчанию будут скрыты и вам нужно будет воспользоваться специальной обработкой для указания видимости требуемых данных. Что бы не тратить время на создание своей обработки, можете воспользоваться моей работой, которая годится как для обычного так и для управляемого интерфейсов (см. вложения).
Бурчание...
Если честно, то я не очень понял эту идею с настраиваемым списком метаданных. Какое-то половинчатое решение. Если целью было увеличить безопасность, то почему для разрешаемых данных сразу дают полный доступ на редактирование и удаление, а не сделать более тонкую настройку прав с возможностью предоставить только чтение? Можно конечно решить вопрос прав с помощью специально настроенной роли, но это уже лишняя модификация прикладного решения, и даже в этом случае я не пущу в базу по REST-интерфейсу никого кроме серверных сценариев своего сайта (back-end), который будет принимать решение что отдавать, а что нет.
Если они хотели минимизировать объем передаваемой информации, то еще более сомнительное решение - метаданные смотрят всего несколько раз для изучения функциональности и дальше работают с данными. Логично же было бы делать оптимизации именно в данных? Ведь можно было бы ограничить список запрашиваемых у объектов полей, а особенно актуально ограничить раскрываемую информацию по параметру $expand, который тянет полностью весь связанный объект, в то время когда нам нужны из него всего одно-два поля.
Думаю, что можно вас поздравить - у вас все настроено и работает! Какие же следующие шаги? Все зависит от того, зачем вам нужно было организовывать доступ к базе - для обмена информацией с корпоративным сайтом, для работы мобильного приложения, для связки с корпоративным ПО...
Если требуется сделать на сайте что-то типа кабинета пользователя с предоставлением истории взаиморасчетов, действующих цен с учетом персональных скидок, ввода заказа и прочими плюшками, то к нашим услугам есть несколько готовых библиотек на официальном сайте . Есть даже целый фреймворк OpenUI5 от компании SAP, который на базе данных получаемых по протоколу OData позволяет создать полноценное бизнес-приложение. В общем, раздолье для грамотного JS-программиста.
Предостережение о "велосипедах"
Наверное, после прочтения последней фразы у вас могли загореться глаза - "К черту, стандартный веб-клиент 1С! Я с такими возможностями собственный интерфейс к базе создам с блэкджеком и приятной компанией". Но я бы на вашем месте не спешил конкурировать на этом поле с компанией 1С, где опытные веб-разработчики уже несколько лет создают то, что мы все видим постфактум. Вы действительно хотите повторить печальную славу "проекта Доминикана"?
Мне могут возразить создатели и - риск стоит затраченных усилий и уже созданы почти готовые для коммерческой эксплуатации продукты. Сотрудники Окнософта тут часто любят хвастаться, что на их разработку стоит очередь из клиентов на годы вперед. И я за них искренне рад - ребята нашли свою нишу. Но по их статьям у меня сложилось впечатлением, что их комплекс metadata.js - это вебовская аналогия некогда востребованной программы "Расширения для карманных компьютеров" компании ДИСКо, которая дала возможность обычным программистам 1С писать приложения под смартфоны. И где теперь эта программа? Такой же функционал для разработки мобильных решений (и даже еще более богатый, и на большее количество платформ) сама 1С дала бесплатно в рамках поставки своей платформы.
Из личного опыта. В какой-то момент после моего замечания, "что в веб-клиенте 1С так нельзя сделать", на моей бывшей фирме было принято решение создать собственный альтернативный веб-интерфейс. Наняли несколько JavaScript-разработчиков, взяли за основу для front-end какую-то популярную тогда библиотеку интерфейсов с красивыми гридами и чартами, а для сервера выбрали node.js. Я реализовал для этого проекта SOAP-интерфейс доступа к данным (HTTP-сервисов тогда еще не было) и мы получили красивую форму списков заказов уже через пару недель. Не знаю точно, что там происходило в разработке, но после нескольких месяцев героической битвы против тотальной атаки багов, проект закрыли и с разработчиками попрощались. А вот программисты компании 1С в это самое время не сидели сложа руки, а выпустили ряд обновлений, после которых пользоваться стандартным веб-клиентом стало немного поприятнее.
Допустим, что мы не грамотные JS-программисты, но какой-то списочек повесить на сайт хотим. Я открыл статью с перечнем самых популярных на сегодняшний день библиотек создания таблиц и нашел в нем простенькую библиотечку jsGrid как раз для нашего случая. Изучаем их сайт, берем пример их кода по использованию OData и вставляем туда путь к нашим данным.
Что бы совсем быть ленивым и ничего не программировать для нашего примера, мне нужно запросить полноценную табличку без необходимости по ссылкам догружать строковые представления. В типовой УТ10.3 на этот счет выбор не очень богатый и потому я возьму справочник Контрагенты.
Теперь самое интересное. А как же сформировать строку запроса на чтение нужных нам данных? Это просто! Смотрим по нашему пути к корню OData (для меня это ) как правильно называется этот справочник - Catalog_Контрагенты . Далее открыв в новом окне адрес http://localhost/DemoTrdBase/odata/standard.odata/ Catalog_Контрагенты мы увидим содержимое всего справочника в формате XML. Но для нашего примера нужен JSON и потому к строке нужно добавить параметр: $format=json - получится http://localhost/DemoTrdBase/odata/standard.odata/ Catalog_Контрагенты ? $format=json . Так, группы нам не интересны и давайте их уберем с помощью параметра фильтрации: $filter=IsFolder eq false - получится http://localhost/DemoTrdBase/odata/standard.odata/ Catalog_Контрагенты ? $format=json & $filter=IsFolder eq false . Блок параметров, как вы уже заметили начинается символом "?", а сами параметры между собой соединяются символом "&". Полный список доступных параметров и функций смотрите в документации по платформе.
Полученный файл положим в каталог, который настроен корневым в вашем веб-сервере. Это необходимо, что бы "домены" странички и запрашиваемых данных совпадали, иначе получите бесконечный индикатор обновления и ошибку в логах: " No "Access-Control-Allow-Origin" header is present on the requested resource. Origin "null" is therefore not allowed access. The response had HTTP status code 401. "
Буквально несколько минут затраченного времени и у нас уже приличная табличка, которая даже автоматически размечена на странички. Немного неуклюже смотрится только запрос аутентификации и, что бы не вводить каждый раз логин и пароль, я их прописал сразу в строке доступа. Конечный файлик получился довольно простой и каждый сможет его с легкостью повторить, но на всякий случай я его тоже размещу во вложения.
Сайты, мобильные приложения, шина сообщений и прочие слова для любого айтишника звучат круто, но не находят отклика в сердцах высоких начальников. Их главный рабочий инструмент Excel, к которому они пылают иррациональной любовью даже при наличии мощной подсистемы отчетности из их баз 1С. И в этот момент мы вспоминаем, что именно компания Microsoft придумала стандарт OData и внедрила его в свои программы начиная с Office 2010. В офисных программах мы можем как просто просматривать таблицы с данными, так и воспользоваться механизмами запросов для получения более интересной информации за один раз без необходимости соединять таблицы с разных листов.
К примеру, нас интересуют должники. В УТ10 мы их можем получить из виртуальной таблицы остатков регистра накопления ВзаиморасчетыСКонтрагентами, наложив фильтр что бы сумма долга была больше нуля (иначе это авансы). Задавать дату не буду, так как меня интересуют актуальные данные. Для моей базы это будет следующая ссылка: http://localhost/DemoTrdBase/odata/standard.odata/AccumulationRegister_ВзаиморасчетыСКонтрагентами/Balance?$filter=СуммаУпрBalance gt 0
Просмотрев результат, мы можем заметить, что у нас нет представлений для контрагентов, а только ключи для таблицы справочника контрагентов. Следовательно будем запрашивать и эти вспомогательные данные. Для этого воспользуемся ссылкой без фильтров: http://localhost/DemoTrdBase/odata/standard.odata/Catalog_Контрагенты
А теперь простая последовательность шагов:
Но, как говорится, лучше один раз увидеть, чем сто раз услышать. Я постарался записать эту же последовательность действий на видео. И сразу предупреждаю, что у вас при повторе будет немного не так - будет запрошена авторизация, о чем я выше упомянул. Просто на момент записи видео, Excel уже запомнил мои логин и пароль.
Надеюсь, что моя статья была полезной. Я сообщил о существовании и преимуществах новой технологии платформы. Так же подробно разъяснил настройку доступа в информационную базу по протоколу OData и привел несколько примеров практического использования.
Что бы не было предубеждений, что применять доступ по OData можно исключительно для управляемого интерфейса на последних версиях платформы, я в качестве учебного примера выбрал демо-базу конфигурации "Управление торговлей (базовая), ред 10.3" в режиме совместимости 8.2. Даже на базе данных такой конфигурации, всего несколькими кликами мышки можно получить в книге Excel актуальные данные по долгам и точно так же просто можно было бы получить актуальные остатки на складах, данные по продажам и прочую полезную информацию.
P.S. Продолжение данной статьи, в котором рассмотрены операции создания и изменения данных, опубликовано по адресу
Печать (Ctrl+P)
Вторая часть можно посмотреть
В версии платформы 8.3.5.1068 , опубликованной в сентябре 2015 появился механизм интеграции 1С с внешними программами через технологию REST интерфейс . В качестве протокола доступа платформа использует протокол OData . Это открытый веб-протокол для запроса и обновления данных. Он позволяет оперировать данными, используя в качестве запросов HTTP-команды. Получать ответы в версии 8.3.5.1068 можно было только в формате Atom/XML . Однако, начиная с релиза 8.3.8.1652 в августе 2017 г. появился второй вариант получения данных в формате JSON(англ. JavaScript Object Notation) . По сравнению с XML он легко читается людьми занимает меньше места. Кроме этого все браузеры имеют встроенные средства для работы с JSON.
Работу с протоколом OData на платформе 1С: предприятие можно посмотреть в книге 1С: Руководства разработчика в главе 17 Механизмы интернет-сервисов , параграф 17.2.1 Cтандартный интерфейс OData. Можно также посмотреть примеры расширения поддержки протокола OData ,
Преимущество использования REST интерфейс . заключает в том, что для получения доступа к данным системы из внешнего приложения не требуется модификации кода прикладного решения (например, если прикладное решение стоит на поддержке). Для получения такого доступа необходимо особым образом опубликовать приложение на веб-сервере и указать, какие объекты конфигурации будут использоваться таким образом. После этого сторонние системы могут обращаться к вашему приложению с помощью HTTP запросов.
Публикация стандартного интерфейса OData выполняется с помощью диалога публикации на веб-сервере (Администрирование – Публикация на веб- сервере) и описано в книге 1С:Предприятие 8.3. “Руководство администратора”.
Важно!
Для того чтобы объекты конфигурации стали доступны через стандартный интерфейс OData, необходимо разрешить это с помощью метода глобального контекста УстановитьСоставСтандартногоИнтерфейсаOData()
.
Механизм установки состава объектов, доступных с помощью стандартного интерфейса OData, можно выполнить в виде внешней обработки. Для этого не требуется модифицировать прикладное решение.
Для взаимодействия с внешним REST- веб-сервер из 1С:Предприятия используется имеющиеся в платформе средства работы с HTTP: объекты HTTPСоединение, HTTPЗапрос и HTTPОтвет.
В этой цикле статьей я буду показывать примеры типовых операций, использующих соответствующий HTTP-метод;
1. Примеры получения данных. HTTP-метод GET
В качестве сервера будет выступать опубликованная на веб-сервере БД с именем WebBuh (Демо-база “Бухгалтерия Предприятия 3.0”). В качестве формата обмена данных я буду использовать формат JSON. Подробнее о работе с JSON написано в документации, доступной . Для получения данных из сервера HTTP-методом GET требуется создать объект ЧтениеJSON для последовательного чтения JSON-данных из файла или строки. Для организации последовательной записи объектов и текстов на сервере HTTP-методом POST PATCH PUT требуется создать объект ЗаписьJSON. Отметим, для метода DELETE не требуется JSON.
В качестве иллюстрации потокового чтения и записи JSON при обращении к REST интерфейсу я буду вызывать следующую пользовательскую функцию общего назначения ВызватьHTTPМетодНаСервере :
&НаСервере // <Описание функции> // // Параметры: //Для получения от сервера в формате JSON при обращении к REST интерфейсу прикладного решения нужно в адресе ресурса указать $format=json. Либо указать MIME тип “application/json” в заголовке:
Заголовки = Новый Соответствие (); Заголовки.Вставить("Content-Type", "application/json") ; АдресРесурса ="WebBuh /odata/standard.odata/?$format=json " ЗапросHTTP = Новый HTTPЗапрос(АдресРесурса, Заголовки) ;1. 1 Настройка параметров HTTP соединения
Для организации клиентской части взаимодействия с внешним REST- веб-сервер, я создал “с нуля” конфигурацию клиента на базе БСП. На этой конфигурации я создал справочник настройки параметров подключения (см Рис 1)
Рис 1 Справочник настройки параметров HTTP соединения к внешней ИБ через rest интерфейс
После нажатия кнопки Проверить ответ сервера, вызывается процедура, по которой клиент попытается получать ответ сервера. Программный код процедуры написан ниже:
&НаКлиенте Процедура ПроверитьПодключение(Команда) Адрес = Объект.АдресСервера ; Пользователь = Объект.Пользователь ; Пароль = Объект.Пароль; ИмяБазы = Объект.Наименование ; Порт = ?(Объект.Порт <> 0,Объект.Порт,80) ; HTTPСоединение = Новый HTTPСоединение(Адрес,Порт,Пользователь, Пароль) ; АдресРесурса = ИмяБазы + "/odata/standard.odata/$metadata "; //Вызов пользовательской функции СтруктураОтвета = ВызватьHTTPМетодНаСервере ("GET" ,HTTPСоединение,АдресРесурса ) ; Если СтруктураОтвета <> Неопределено Тогда ОбщегоНазначенияКлиентСервер.СообщитьПользователю("Код состояния "+СтруктураОтвета.КодСостояния) ; Конецесли; КонецПроцедурыЦель этой процедуры – Это проверка работы сервиса и
правильно ли пользователь ввел параметры соединения. Для этого достаточно выполнить GET-запрос:
HTTPСоединение.ВызватьHTTPМетод(“GET”
, ЗапросHTTP) ;
с использованием адреса ресурса:
АдресРесурса
= ИмяБазы
+ “/odata/standard.odata/
“;
Проверить работы сервиса можно также в браузере с использованием
URL
http://host/WebBuh/odata/standard.odata. В результате такого запроса получается только список сущностей. Для получения полного описания стандартного интерфейса OData (список доступных сущностей, их атрибутов и функций в виде XML-
документа.) необходимо выполнить GET-запрос с использованием параметра $metadata.
URL http://host/WebBuh/odata/standard.odata/$metadata. Подробное описание документа можно получить по адресу http://www.odata.org/documentation/ (на английском языке).
Получать ответы можно в формате Atom/XML
или JSON . Коды статусов ответа по протоколу HTTP можно посмотреть Ответы в диапазонах:
1.2 Поиск объекта по идентификатору
Следующая функция предназначена для поиска справочника или документа по уникальному идентификатора на сервере. Если объект найден, то функция возвращает строковое значение идентификатора (Ref_Key) , иначе возвращает неопределено. В функцию передаются следующие параметры:
Параметр АдресРесурса используется для обращения к REST-сервису. Для проверки работы сервиса можно указать ресурс в браузере таким образом
http://{АдресВебСервера}/{ИмяПубликации}/odata/standard.odata/{Элемент}?{Параметры} ,где
1.3 Поиск объекта по полям поиска
Следующая пользовательская функция предназначена для поиска объекта по полям поиска в том случае, когда объект по идентификационному номеру. Функция возражает строку Ref_Key – идентификационный номер.
&НаСервере Функция П оискОбъектПоПолямПоиска(HTTPСоединение,ИмяПубликации, Элемент,ПоляПоиска) Условие = "" ; Для Каждого КлючЗначение из ПоляПоиска Цикл Условие = Условие + КлючЗначение.Ключ + " eq "" + КлючЗначение.Значение + "" and "; КонецЦикла; ТекстЗапроса = Лев(Условие, СтрДлина(Условие)-5) ; // удаляем последние 5 символов АдресРесурса = ИмяПубликации+ "/odata/standard.odata/" +Элемент+ "?$filter=" + ТекстЗапроса + "&$format=json&$select=Ref_Key " ; //Вызов моей пользовательской функции СтруктураОтвета = ВызватьHTTPМетодНаСервере("GET " ,HTTPСоединение,АдресРесурса); Если СтруктураОтвета .КодСостояния >= 400 Тогда //ОбщегоНазначенияКлиентСервер.СообщитьПользователю(Элемент+ " Ошибка "+СтруктураОтвета.КодСостояния); //ОбщегоНазначенияКлиентСервер.СообщитьПользователю(СтруктураОтвета.ОтветСервераНеРасшифрованный); Возврат неопределено; КонецЕсли; Соответствие = СтруктураОтвета. ОтветСервер а; Массив = Соответствие["value" ] ; Если Массив = Неопределено Тогда Возврат Соответствие ["Ref_Key" ] Иначе Возврат Массив ["Ref_Key" ]; КонецЕсли; КонецФункцииКак видно из тела процедуры П оискОбъектПоПолямПоиска , отбор начинается с ключевого слова $filter в адресе ресурса. Формальный параметр ПоляПоиска – это соответствие, которое содержит наименования и значения реквизитов.
Отметим, что наименование реквизитов порой не очевидно. Необходимо запомнить, что для справочников:
Для документов:
Логические операции отбора
Отметим, также, что значение фактического параметра Элемент (или сущность)) , который я передаю на функцию формируется по следующему правилу:
ПрефиксИмени_ИмяОбъектаКонфигурации_СуффиксИмени .
С помощью стандартного интерфейса OData можно получить доступ к следующим объектам (ПрефиксИмени ):
ИмяОбъектаКонфигурации - свойство «Имя» объекта конфигурации так, как оно задано в конфигураторе.
СуффиксИмени - нужен для уточнения имени ресурса, необязателен, может принимать следующие значения:
После формирования имени ресурса нужно определить параметры обращения к ресурсу, например, ?$filter=Значение &$format =json&$select= Ref_Key ,
1.4 Получить массив записей регистра сведений
Посмотрим пример получения массив записей регистра сведения ФИОФизическихЛиц, например историю изменения ФИО физического лица
ИмяПубликации =" WebBuh"; Элемент = "InformationRegister_ФИОФизическихЛиц"; Период = Неопределено ; ДанныеСсылочногоТипа = Новый Структура (); ДанныеСсылочногоТипа .Вставить ("ФизическоеЛицо",ФизическоеЛицо_Key); ДанныеНЕСылочногоТипа = Новый Структура (); ДанныеНЕСылочногоТипа .Вставить ("ФизическоеЛицо_Type", "StandardODATA.Catalog_ФизическиеЛица") Массив = ПолучитьНаборЗаписиРегистраСведений (HTTPСоединение ,ИмяПубликации ,Элемент , Период ,ИзмеренияСсылочногоТипа , ИзмеренияНЕСылочногоТипа )Тело функции ПолучитьНаборЗаписиРегистраСведений, которая вызывается в этом примере показано ниже
Была реализована возможность автоматически формировать REST интерфейс OData для всего прикладного решения. Таким образом у нас появилась возможность предоставить полный доступ стороннему приложению к базе 1С буквально за пару кликов.
Данный механизм предназначен для решения нескольких часто встречающихся задач:
REST интерфейс OData можно использовать для обмена данными между базами 1С, но так как для этого уже существуют другие, более удобные, механизмы, то основное предназначение REST интерфейса OData видится в интеграции со сторонними системами.
И это действительно удобно, если учесть, что клиенты OData существуют на всех основных платформах, соответствующие библиотеки можно скачать .
В этой статья я попробую подробно рассказать о том, что такое REST интерфейс OData и как его можно использовать.
Для использования интерфейса OData его нужно опубликовать, а для этого нам потребуется веб-сервер — Apache 2.2 или IIS (начиная с версии еще и Apache 2.4). Затем, нужно зайти в меню «Администрирование»->»Публикация на веб-сервере…».
В открывшемся окне заполняем нужные поля и жмем «Опубликовать»:
После этого нужно будет определить состав интерфейса OData, т.е. указать — какие объекты конфигурации в него входят, а какие нет (изначально в составе нет ни одного объекта).
Сделать это можно примерно так:
&НаСервере Процедура УстановитьODataНаСервере() тМассив = Новый Массив; тМассив.Добавить(Метаданные.Справочники.Товары); УстановитьСоставСтандартногоИнтерфейсаOData(тМассив); КонецПроцедуры
&НаСервере Процедура УстановитьODataНаСервере() тМассив= Новый Массив; тМассив. Добавить(Метаданные. Справочники. Товары) ; УстановитьСоставСтандартногоИнтерфейсаOData(тМассив) ; КонецПроцедуры |