Стандартний інтерфейс odata.

У 1С:Підприємство, починаючи з версії 8.3.5, платформа автоматично може генерувати REST інтерфейс для всієї конфігурації. Він працює за протоколом OData і дозволяє працювати з довідниками, документами і регістрам через web-сервер. Загалом швидкість отримання даних на кілька порядків швидше, ніж через COM або файли, що не може не тішити.

Для різних операцій використовуються різні запити:

• GET - використовується для отримання даних;
• POST – використовується створення об'єктів;
• PATCH – модифікація наявного об'єкта;
• DELETE - Видалення об'єкта.

Для доступу до різних об'єктів використовуються префікси:

• Довідник – Catalog;
• Документ – Document;
• Журнал документів – DocumentJournal;
• Константа – Constant;
• План обміну – ExchangePlan;
• План рахунків - ChartOfAccounts
• План видів розрахунку - ChartOfCalculationTypes;
• План видів характеристик - ChartOfCharacteristicTypes;
• Регістр відомостей - InformationRegister;
• Регістр накопичення – AccumulationRegister;
• Реєстр розрахунку - CalculationRegister;
• Регістр бухгалтерії – AccountingRegister;
• Бізнес-процес - BusinessProcess;
• Завдання – Task.

Використовуючи протокол ODATA можна використовувати так само і вбудовані методи об'єктів, виконуючи запити POST.

• Для документа – Post() та Unpost();
• Для завдання – ExecuteTask();
• Для бізнес-процесу - Start ();
• Для регістру відомостей – SliceLast() та SliceFirst();
• Для регістру накопичення та регістру бухгалтерії – Balance(), Turnovers() та BalanceAndTurnovers();
• Для регістру розрахунку – ScheduleData(), ActualActionPeriod(),<ИмяПерерасчета>() та Base<Имя базового регистра расчета>().

Щоб почати працювати з цим інтерфейсом, потрібно його опублікувати. Робиться це через меню конфігуратора "Адміністрація" - "Публікація на веб-сервері", ставимо галку "Публікувати стандартний інтерфейс OData" і натискаємо "Опублікувати".

Після публікації роботу протоколу можна перевірити на адресу http://<ИмяСервера>/<ИмяБазы>/odata/standard.odata. У відповіді ми маємо отримати весь склад опублікованих таблиць. Він має бути схожий на малюнок нижче.

Якщо після публікації REST інтерфейсу склад опублікованих даних порожній, потрібно скористатися методом ВстановитиСкладСтандартногоІнтерфейсуOData. На вході він має 1 параметр типу “масив”. До масиву потрібно додати метадані, які потрібно опублікувати.

Склад = новий Масив;
Склад.Додати(Метадані.Довідники.Контрагенти);
Встановити Склад Стандартного Інтерфейсу OData (Склад);

http://<ИмяСервера>/<ИмяБазы><ИмяСправочника>

За запитом можна використовувати такі параметри:

select – у цьому параметрі вказуємо потрібні поля;

format – задаємо формат, в якому ми хочемо отримати відповідь (XML або JSON), за замовчуванням XML

odata – якщо нам у відповіді не потрібний опис метаданих, то пишемо “odata=nometadata”

filter – тут вказуємо відбори.

Як я й писав вище, ми можемо отримати відповідь у двох форматах XML або JSON, за замовчуванням використовується XML. Щоб отримати дані у форматі JSON, потрібно до URL адреси додати “?$format=application/json”.

http://<ИмяСервера>/<ИмяБазы>/odata/standard.odata/Catalog_<ИмяСправочника>?$format=application/json

Здебільшого нам потрібно отримувати конкретний елемент довідника, а чи не всі його записи. Для цього використовуємо чарівне слово "filter".

http://<ИмяСервера>/<ИмяБазы>/odata/standard.odata/Catalog_<ИмяСправочника>?$format=application/json&$filter=Ref_Key eq guid’УІД’

Якщо ви звернули увагу, в URL-адресі вказано два параметри $format і $filter, вони можуть розташовуватися в будь-якому порядку, головне щоб перед першим параметром був знак “ ? ", а перед другим" & “. Логіка тут така, ми вказуємо адресу довідника у першій частині, а параметри у другій. Ці частини поділяються знаком “ ? ", А ось самі параметри між собою поділяються знаком " & “. Якщо зобразити схематично, то це виглядає так

АдресаТаблиці ? $Параметр1=ЗначенняПараметра1 & $Параметр2=ЗначенняПараметра2

Огляд OData

OData – це веб-орієнтований API-інтерфейс для доступу до даних та маніпулювання ними. Він подібний до API-інтерфейсів mini-ODBC і JDBC, але на відміну від них спеціально орієнтований на Інтернет. Точніше кажучи, OData дозволяє клієнтам конструювати URI-ідентифікатори для іменування набору сутностей, здійснювати фільтрацію сутностей, що містяться в цьому наборі, а також простежувати відносини з пов'язаними сутностями і колекціями сутностей. Для отримання додаткової інформації зверніться до статті Introduction OData: Data Access for the Web, the cloud, mobile devices, and more (Надаємо OData: доступ до даних за допомогою Інтернету, хмарного середовища, мобільних пристроїві т.д.).

Рисунок 1. Виставлення бази даних в Інтернеті за допомогою OData-постачальника загального призначення

У схемі на малюнку 1 показано, як такий ресурс, як база даних, може бути виставлений в Інтернеті за допомогою OData-постачальника загального призначення. Синтаксис OData дозволяє за допомогою Web-браузерів посмикати дані у вищезгаданій базі даних різним маніпуляціям (створення, оновлення, видалення, запит).

Рисунок 2. Мова CSDL (Conceptual Schema Definition Language)

На малюнку 2 показано схему мови CSDL (Conceptual Schema Definition Language). CSDL - це опціональний інструмент, що допомагає додаткам-споживачам розуміти структуру даних, що виставляються. CSDL подібний до метаданих у JDBC and ODBC, він допомагає клієнтським додаткам розуміти, до чого саме вони звертаються.

В Інтернеті є тисячі веб-орієнтованих API-інтерфейсів. OData – це один із прикладів такого API-інтерфейсу. Докладнішу інформацію про веб-орієнтовані API-інтерфейси можна отримати на веб-сайті: Programmable Web . Стандартизація таких інтерфейсів дозволить покращити консолідацію у цій важливій технологічній галузі та допоможе інноваціям йти в ногу з потребами ринку, зокрема підтримувати нові конструкції даних та ініціативи у сфері відкритих даних.

OData в організації OASIS

Проект хартії OData був представлений в організацію OASIS (Organization for the Advancement of Structured Information Standards). Нижче наведено фрагмент тексту цього документа.

Робота буде спрямована на досягнення наступних цілей.

• Створення RESTful-сервісів даних на базі HTTP, можливість ідентифікації ресурсів за допомогою URI-ідентифікаторів (Uniform Resource Identifier) ​​та визначення ресурсів за допомогою абстрактної моделі даних, можливість опублікування та редагування веб-клієнтами з використанням простих HTTP-повідомлень.
• Виставлення та отримання інформації з різних джерел, включаючи, але не обмежуючись, реляційні бази даних, файлові системи, системи управління контентом та традиційні веб-сайти.

Документи зі специфікаціями OData, представлені в організацію OASIS, а також проект хартії доступні за такими посиланнями.

Крім специфікацій OData в організацію OASIS було представлено такі чотири документи з розширеннями OData.

Ці документи з розширеннями покликані ініціювати роботу в запропонованому технічному комітеті OASIS з OData (OASIS OData Technical Committee). На веб-сайті організації OASIS можна прочитати повний текстхартії по OData та документи з розширеннями.

OData та продукти IBM

Наступні продукти IBM підтримують OData.

• Продукт для підтримки доступу різних клієнтів.
• Продукти DB2 та Informix здатні використовувати OData за допомогою Microsoft Visual Studio. Більше Детальна інформаціяна цю тему міститься .

Приклади OData

У цьому параграфі наведено кілька простих прикладів на OData, що звертаються до Netflix.

OData та інші веб-орієнтовані API-інтерфейси

В даний час використовуються тисячі веб-орієнтованих 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 шляхів:

1. Доступ до бази через сімейство COM-об'єктів(V83.ComConnector і раніше). Обмеження: платформа має бути встановлена ​​на Windows.
2. Безпосередній доступтаблиці бази даних. Ось приклад для СУБД. . Обмеження: заборона безпосереднього доступу до даних ліцензійній угоді; нестабільність отриманого доступу; Зміна даних може призвести до порушення логічної цілісності бази.
3. Починаючи з версії платформи 8.3.5, з'явилася можливість надати доступ до даних через автоматичний REST-інтерфейсз урахуванням протоколу OData v.3.0. Обмеження: необхідно встановити веб-сервер та модуль розширення веб-сервера з постачання платформи.
4. Починаючи з версії платформи 8.3.6, з'явився механізм розширеньщо дозволяє "пристебнути" нову функціональність без внесення змін до основної конфігурації. Серед нової функціональності є цікаві нам WEB- та HTTP-сервіси. Починаючи з версії платформи 8.3.11, стала доступною можливість розширення структури таблиць бази даних (додавання нових реквізитів для зберігання службових даних з метою інтеграції). Обмеження: необхідна наявність програміста, який розробить розширення та стежитиме за його працездатністю при оновленнях; для сервісів необхідно встановити веб-сервер та модуль розширення веб-сервера з постачання платформи.
5. Можна відмовитися від "миттєвого доступу" і тоді можемо використати запуск зовнішніх обробок за допомогою параметра командного рядка/Execute. У такому сценарії можна зробити регулярний запуск за розкладом деякої обробки, яка перевірятиме зовнішній ресурс на наявність інструкцій до виконання та поміщатиме туди результати своєї роботи. Так само можна самостійно запускати клієнтський додаток 1С на відпрацювання своїх команд, якщо є доступ до ОС, де знаходиться база. Обмеження: потрібна наявність програміста, який створить обробку; наявність тимчасового лага в реакції системи на значення проміжку між запусками у планувальнику або на час старту клієнтської програми.

Таким чином, серед 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-розрядну платформу), залишилося трохи. У конфігураторі заходимо в меню "Адміністрування" та натискаємо на команду "Публікація на веб-сервері...". У віконці необхідно вказати наступні важливі моменти:

• Назва вашої бази в полі "Ім'я", за якою веб-сервер надаватиме до неї доступ (якщо не хочете проблем, то не пишіть на кирилиці);
• Вкажіть веб-сервер, який встановлено на даному комп'ютері(якщо у вас встановлено цілих два веб-сервери, то у списку, що випадає, буде вибір);
• Шлях до каталогу публікації, до якого має бути доступ у вибраного веб-сервера;
• І найголовніше – галочка "Публікувати стандартний інтерфейс OData"!

Після натискання на кнопку "Опублікувати" за вказаним у налаштуванні шляху буде створено файл 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 thefore 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_Контрагенти

А тепер проста послідовність кроків:

1. Відкриваємо Excel (у мене версія 2016; якщо у вас 2010 чи 2013, то меню може трохи відрізнятися)
2. Переходимо навігаційним шляхом: "Дані" / "Створити запит" / "З інших джерел" / "З каналу ODATA".
3. Вказуємо наше посилання на регістр взаєморозрахунків
4. На формі авторизації виберемо третій варіант "Базовий" та вкажемо логін/пароль. Натискаємо "Підключення".
5. У вікні редактора запиту замість імені "Запрос1" дамо щось більше для нас цікаве - "Взаєморозрахунки"
6. У центрі вікна редактора запиту бачимо колонку "Список", де у кожному рядку слово "Record". Ми можемо або скористатися контекстною командою "В таблицю" або натиснути відповідну кнопку в меню "Перетворення" редактора. На запитання дайте відповідь "Ок".
7. Тепер колонка називається Column1 і поруч з нею з'явилася кнопочка зі стрілками в різні боки. Натисніть на неї. Із сервера підтягнеться опис існуючих колонок. Зніміть всі галочки та залиште їх тільки на колонках "Контрагент_Key" та "СумаУпр Balance". Натисніть на "Ок" і з'явиться таблиця з двох вибраних стовпчиків з потрібними нам даними.
8. За межами нашої уваги залишилися такі виміри як організація, договір та правочин, але вони все одно були запрошені. В результаті ми зараз маємо рядки контрагентів з різними сумами. Їх можна згорнути за допомогою угруповання. Для цього або з меню або контексту викликайте команду "Групувати по". У групувальних полях залиште лише контрагента, а поле із сумою видаліть. Назвіть нову колонку "Долг", в операції виберіть "Сума", а в стовпці вкажіть поле нашої суми. Натисніть на "Ок" і отримаємо трохи менше записів.
9. Тепер нам слід розшифрувати контрагентів. Для цього в лівій панелі "Запити", де вже є поточний запит "Взаєморозрахунки", викличте контекстне менюта виберіть "Новий запит" / "Інші джерела" / "Канал ODATA". У віконці вкажемо шлях до довідника контрагентів. Далі знову вказуємо логін/пароль авторизації, у попередньому перегляді натискаємо "Ок" та задамо новому запиту ім'я "Контрагенти".
10. Повернемося до запиту "Взаєморозрахунки" (клік за назвою на панелі запитів).
11. Тепер виконуємо поєднання наших двох запитів. Для цього в основному меню редактора викличте "Комбінувати" / "Об'єднати запити". У вікні конструктора поєднання буде наша таблиця взаєморозрахунків. У центрі у випадаючому вікні виберіть запит "Контрагенти". Вигляд з'єднання залишається тим, що за промовчанням (ліве зовнішнє). Далі кліками вибираємо стовпчики для умови об'єднання. Погоджуємося з усім, що нам далі пропонують.
12. Після об'єднання ми отримали нову колонку "Контрагенти" зі знайомою кнопкою з різноспрямованими стрілочками. Клікаємо по цій кнопці і вибираємо колонки, що нас цікавлять. Для інтересу виберемо "Найменування Повне" та "Parent" (група). Колонка "Parent" також пропонує нам розкритися - виберемо в ній поле "Description" (звичайне найменування довідника).
13. Зробимо гарно. Першу колонку із ключем контрагента можемо видалити. Колонку групи так і назвемо "Група", колонці з ім'ям контрагента дамо назву "Контрагенти", а колонку боргу перекинемо в кінець таблиці, що отримується.
14. Тепер можемо натиснути на головну кнопкуредактора - "Закрити та завантажити".
15. Далі можна використовувати завантажену таблицю як дані для зведеної таблиці або зведеної діаграми. Або при створенні цих нових об'єктів вказуємо як джерело даних наш запит "Взаєморозрахунки".

Але, як кажуть, краще один раз побачити, ніж сто разів почути.Я постарався записати цю послідовність дій на відео. І відразу попереджаю, що у вас при повторі буде трохи не так - буде запитана авторизація, про що я згадав вище. Просто на момент запису відео, Excel вже запам'ятав мої логін та пароль.

Підсумки

Сподіваюся, що моя стаття була корисною. Я повідомив про існування та переваги нової технологіїплатформи. Також докладно пояснив налаштування доступу в інформаційну базуза протоколом OData і навів кілька прикладів практичного використання.

Що б не було упереджень, що використовувати доступ по OData можна тільки для керованого інтерфейсу на останніх версіяхплатформи, як учбовий приклад вибрав демо-базу зміни "Управління торгівлею (базова), ред 10.3" як сумісності 8.2. Навіть на базі даних такої конфігурації, всього кількома кліками мишки можна отримати в книзі Excel актуальні дані по боргах і так само просто можна було б отримати актуальні залишки на складах, дані з продажу та іншу корисну інформацію.

P.S.Продовження цієї статті, в якій розглянуто операції створення та зміни даних, опубліковано за адресою

Була реалізована можливість автоматично формувати REST інтерфейс OData для прикладного рішення. Таким чином, у нас з'явилася можливість надати повний доступ сторонньому додаткудо бази 1С буквально за пару кліків.

Даний механізм призначений для вирішення кількох часто зустрічаються задач:

• Вивантаження/завантаження даних з прикладного рішення;
• Інтеграція з інтернет-сайтами (інтернет-магазинами);
• нарощування функціональності прикладного рішення без зміни конфігурації;
• Інтеграція з іншими корпоративними системами(Іноді і без додаткового програмування).

REST інтерфейс OData можна використовуватиме обміну даними між базами 1С, але оскільки цього вже є інші, зручніші, механізми, то основне призначення REST інтерфейсу OData бачиться в інтеграції зі сторонніми системами.

І це дійсно зручно, якщо врахувати, що клієнти OData існують на всіх основних платформах, відповідні бібліотеки можна завантажити.

У цій статті я спробую докладно розповісти, що таке REST інтерфейс OData і як його можна використовувати.

Публікація REST інтерфейсу OData

Для використання інтерфейсу OData його потрібно опублікувати, а для цього нам буде потрібно веб-сервер - Apache 2.2 або IIS (починаючи з версії Apache 2.4). Потім потрібно зайти в меню «Адміністрування»->»Публікація на веб-сервері…».

У вікні заповнюємо потрібні поля і тиснемо «Опублікувати»:

Після цього необхідно буде визначити склад інтерфейсу OData, тобто. вказати - які об'єкти конфігурації до нього входять, а які ні (спочатку у складі немає жодного об'єкта).

Зробити це можна приблизно так:

&НаСервері Процедура ВстановитиODataНаСервері() тМасив = Новий Масив; тМасів.Додати(Метадані.Довідники.Товари); ВстановитиСклад СтандартногоІнтерфейсуOData(тМасив); КінецьПроцедури