Заявката за 1s публикация не запазва данни. Търсене на обект чрез полета за търсене
Прочетете също
При разработването на процедурата за изпращане на информация към сайта от 1C с платформа версия 8.3.9.2170 се натъкнах на проблем: разработчикът на сайта ми даде възможност да запиша необходимата информация само с помощта на HTTP заявка, използвайки метода PUT.
Без да мисля два пъти, скицирах прост код:
Connection = New HTTPConnection("www.mysite.ru"); Заглавки = Ново съвпадение; Headers["Content-Type"] = "application/x-www-form-urlencoded"; Заявка = Нов HTTPRequest("/api/order_items/93076?order_item=30", Headers); Connection.Write(Request);
Въз основа на резултатите от изпълнението съответният ред на поръчката на купувача на уебсайта трябва да посочи количеството стоки, получени в склада.
Но както вероятно вече разбрахте, нищо не се случи. След като се уверих, че няма грешки в сайта (като изпратих подобна заявка през приставката за Chrome), стартирах моя локален компютъруеб сървър и започна да експериментира.
Веднага стана ясно нещо странно: горният код генерира не PUT, а HEAD заявка!
В регистрационните файлове на Apache видях следното:
127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"
Бях малко изненадан (в края на краищата беше написано черно на бяло в ръководството PUT), но не бях на загуба - в края на краищата можете да извикате метода директно:
Connection.CallHTTPMethod("PUT",Request);
Дневниците са същите:
127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"
— Може би правя нещо нередно? – зададох си въпрос. Но в интернет и в ръководствата нямаше улики. Е, никой все още не е отменил метода на научното мушкане. Като начало се опитах да направя следното:
Connection.CallHTTPMethod("fwfw", Request);
В регистрационните файлове, които получих:
127.0.0.1 - - "?????? /api/order_items/93076?order_item=30 HTTP/1.1"
Любопитно е, че това означава, че 1C специално замества метода PUT (защо той не угоди на 1C?).
След още няколко опита стигнах до това:
Connection.CallHTTPMethod("PUT", Request);
В регистрационните файлове, които получих:
127.0.0.1 - - "ПОСТАВЕТЕ /api/order_items/93076?order_item=30 HTTP/1.1"
И тази опция вече работи на сайта и всички останаха доволни.
Той предложи по-правилно решение на проблема: трябва да посочите тялото на заявката, всяко, дори празно. Например това би свършило работа:
Connection = New HTTPConnection("www.mysite.ru"); Заглавки = Ново съвпадение; Headers["Content-Type"] = "application/x-www-form-urlencoded"; Заявка = Нов HTTPRequest("/api/order_items/93076?order_item=30", Headers); Query.SetBodyFromString("", TextEncoding.UTF8, UseByteOrderMark.Don't Use); Connection.Write(Request);
И вече е съвсем правилно, вероятно, самите стойности на параметрите да се прехвърлят в тялото на заявката.
Изводът е следният: платформата 1C счита PUT заявка без тяло за погрешна и замества метода с HEAD.
Любопитно е, че 1C не проследява POST заявка без тяло и не я превръща в GET, беше проверено в името на спортния интерес.
Както би казал добре познатият Вовочка от известния виц: "Къде е логиката?".
Надявам се публикацията ми да спести на някого няколко часа живот в търсене на отговор. =)))
При разработването на процедурата за изпращане на информация към сайта от 1C с платформа версия 8.3.9.2170 се натъкнах на проблем: разработчикът на сайта ми даде възможност да запиша необходимата информация само с помощта на HTTP заявка, използвайки метода PUT.
Без да мисля два пъти, скицирах прост код:
Connection = New HTTPConnection("www.mysite.ru"); Заглавки = Ново съвпадение; Headers["Content-Type"] = "application/x-www-form-urlencoded"; Заявка = Нов HTTPRequest("/api/order_items/93076?order_item=30", Headers); Connection.Write(Request);
Въз основа на резултатите от изпълнението съответният ред на поръчката на купувача на уебсайта трябва да посочи количеството стоки, получени в склада.
Но както вероятно вече разбрахте, нищо не се случи. След като се уверих, че няма грешки в сайта (като изпратих подобна заявка през приставката на Chrome), стартирах уеб сървър на локалния си компютър и започнах да експериментирам.
Веднага стана ясно нещо странно: горният код генерира не PUT, а HEAD заявка!
В регистрационните файлове на Apache видях следното:
127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"
Бях малко изненадан (в края на краищата беше написано черно на бяло в ръководството PUT), но не бях на загуба - в края на краищата можете да извикате метода директно:
Connection.CallHTTPMethod("PUT",Request);
Дневниците са същите:
127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"
— Може би правя нещо нередно? – зададох си въпрос. Но в интернет и в ръководствата нямаше улики. Е, никой все още не е отменил метода на научното мушкане. Като начало се опитах да направя следното:
Connection.CallHTTPMethod("fwfw", Request);
В регистрационните файлове, които получих:
127.0.0.1 - - "?????? /api/order_items/93076?order_item=30 HTTP/1.1"
Любопитно е, че това означава, че 1C специално замества метода PUT (защо той не угоди на 1C?).
След още няколко опита стигнах до това:
Connection.CallHTTPMethod("PUT", Request);
В регистрационните файлове, които получих:
127.0.0.1 - - "ПОСТАВЕТЕ /api/order_items/93076?order_item=30 HTTP/1.1"
И тази опция вече работи на сайта и всички останаха доволни.
Той предложи по-правилно решение на проблема: трябва да посочите тялото на заявката, всяко, дори празно. Например това би свършило работа:
Connection = New HTTPConnection("www.mysite.ru"); Заглавки = Ново съвпадение; Headers["Content-Type"] = "application/x-www-form-urlencoded"; Заявка = Нов HTTPRequest("/api/order_items/93076?order_item=30", Headers); Query.SetBodyFromString("", TextEncoding.UTF8, UseByteOrderMark.Don't Use); Connection.Write(Request);
И вече е съвсем правилно, вероятно, самите стойности на параметрите да се прехвърлят в тялото на заявката.
Изводът е следният: платформата 1C счита PUT заявка без тяло за погрешна и замества метода с HEAD.
Любопитно е, че 1C не проследява POST заявка без тяло и не я превръща в GET, беше проверено в името на спортния интерес.
Както би казал добре познатият Вовочка от известния виц: "Къде е логиката?".
Надявам се публикацията ми да спести на някого няколко часа живот в търсене на отговор. =)))
Възникна задачата за прехвърляне на данни между 1C (разработката и конфигурацията бяха възложени на външни изпълнители), която се планира да се използва като основна система за управление на електронни документи (EDM) и B2B система (вътрешна разработка), която е написана на PHP (Symfony) и изпълнява функциите по въвеждане на първична информация във фирмите.
Вече имах опит в интегрирането на B2B с друг B2B. Основното беше да се прехвърли JSON с помощта на cURL. Тогава възниква задачата за интегриране на системата Borlas, базирана на Oracle, където също е приложен този подход. От страна на Oracle обаче използваха собствен пакет - аналог на cURL в PHP (ако е интересно, мога да го опиша в нова статия).
Както разбрах, 1C 8.2 може също да изпраща GET и POST заявки. Предположих, че ако всичко вече е настроено и работи с други системи, тогава трябва да работи и тук. JSON беше отхвърлен от разработчиците на 1C, като казаха, че форматът не е подходящ и те разпознават само XML. Коментарите, че това ще ни даде минимален размер при прехвърляне на данни и наистина имаше много данни, бяха отхвърлени. В резултат на това започнахме подготовката на 2 системи, базирани на XML.
От своя страна написах акцептор на заявка от 1C и върнах резултатите. Функция за получаване на променлива в POST, в която 1Sniki трябваше да замести XML.
Форматът е нещо подобно:
Манипулатор, който връща вече избрани записи според условията и генерира XML на формата:
Данните могат да се прехвърлят само чрез HTTPS връзка.
На пръв поглед изглежда, че всичко е просто, но в процеса възникнаха няколко проблема:
1) външните изпълнители съобщиха, че не са запознати с искания от този вид и се опитаха да предложат стара доказана схема:
1. импортиране на файл от B2B,
2. Зареждане в 1C,
3. Експортиране на файл, показващ какво са успели да обработят, какво не е от 1C,
4. Импортиране към B2B,
5. и от самото начало...
Схемата беше отхвърлена, тъй като се наложи бързо и без човешка намеса и каквито и да било „бутони“.
След това поискаха примерен код. В интернет "гугълнах" следния пример:
Сървър = "test.com"; Порт = "443"; HTTP опит = Нова HTTP връзка (сървър, порт, вярно); Друго HTTP = Нова HTTP връзка (сървър, порт); EndIf; ScriptAddress = "/gateway/GetData1C/"; Опит за HTTP.SendToProcess(SendFileName, ScriptAddress, ResponseFileName, HTTP Header); Доклад за изключение ("Неуспешен опит за свързване: " + ErrorDescription()); ElseLoginLogWrite("HTTPConnection",LogLogLevel.Error, "Неуспешен опит за свързване: " + ErrorDescription()); EndIf Връщане; Край на опита;
Данните започнаха да идват на сървъра, но празни, тоест GET и POST бяха празни. Добавих запис към регистрационните файлове и успешно го забравих. След 4 месеца ми беше дадена спешна задача - да доведа интеграцията до резултат (тъй като мина много време, разработчиците на 1C работят, работят, но нищо не идва в отговор). Дадоха ми 1C и започнах да "ровя".
Първо реших да сложа Fiddler, за да разбера какво се случва. Забелязах, че връзката минава през HTTP и след това сървърът пренасочва към HTTPS. Предположих, че поради тази причина данните са празни. Опитах се да възпроизведа в Chrome и получих потвърждение, че данните в POST заявката са изгубени по време на пренасочването.
Тъй като е невъзможно да се разреши работа през HTTP, започнах да проуча защо, защото е посочено, че:
HTTP = Нова HTTP връзка (сървър, порт, вярно); Параметърът "True" означава да се използва HTTPS и след това стана ясно, че HTTP = New HTTPConnection(Server, Port);
В резултат на това това „Иначе“ беше изхвърлено и получи грешка, която невалиден сертификат. Сертификатът беше самоподписан. Разработката на интеграция беше извършена на вътрешни сървъри, където официално закупеният сертификат беше от Thawte SSL CA, за разлика от PROD сървъра. Импортирането на сертификата във всички възможни магазини не доведе до резултат.
Търсенето на ресурси доведе до факта, че 1C има свои собствени основни сертификати и въз основа на тях вече проверява останалите. Те се намират в тестова форма във файла "cacert.pem", който се намира в папката "bin", където се намира 1C. Вносът не е толкова прост, колкото се оказа.
Първо трябва да експортираме необходимия сертификат във файл (вече го имах в личното си хранилище). Като стартираме "certmgr.msc", намирайки сертификата, ние го експортираме във файла *.cer.
C:\OpenSSL-Win64\bin>openssl x509 -inform der -in C:\fiddler.cer -out C:\fiddler.pem -text -fingerprint -md5 ПРЕДУПРЕЖДЕНИЕ: не мога да отворя конфигурационен файл: /usr/local/ ssl/openssl.cnf MD5 пръстов отпечатък=13:BF:73:43:BB:69:19:BA:22:5D:C7:2E:44:85:91:7F
Спестяваме MD5, ще ни трябва.
След това отворете файла "cacert.pem".
Слизаме до самото дъно и добавяме първо MD5, а след това цялото съдържание, което се оказа във файла fiddler.pem.
Запазваме файла.
Рестартираме 1C (може би не е необходимо, но не работи за мен, така че рестартирах всичко.
Изходният файл в 1C беше даден в следната форма:
Процедура SendRequestClick(Element) Connection = GetHTTPConnection(); If Connection = Undefined Then Report("Не може да се свърже със сървъра, посочен в настройките за обмен! Обработката е прекратена!"); Друг източник = FileAddr; EndIf; FileName = FileResult; PostFileName = PostFile; SubmissionFile = Нов файл (PostFileName); SendFileSize = XMLString(SendFile.Size()); Заглавки = Ново съвпадение(); Headers.Insert("Content-Type", "application/x-www-form-urlencoded"); Headers.Insert("Content-Lenght", SubmissionFileSize); Опит за свързване.SendForProcessing(PostFileName, Source, FileName, Headers); Доклад за изключение (Описание на грешка ()); Край на опита Край на процедурата Функция GetHTTPConnection() Експортиране на опит за връзка = Нова HTTP връзка(HTTPServer,"443",True); Доклад за изключение (Описание на грешка ()); Връзка = недефинирана; Край на опита; Връзка за връщане; EndFunction Процедура OnOpen() HTTPServer = "test.com"; FileAddress = "/gateway/GetData1C"; PostFile = "C:\POST_1C\post.txt"; FileResult = "C:\POST_1C\result.xml"; EndProcedure
След като щракнете върху бутона, заявка премина през HTTPS и на изхода беше получен правилният XML.
Търсих как 1C работи през HTTPS, много материали, но не намерих как да работя със самоподписан сертификат.
Печат (Ctrl+P)
Втората част може да се види
Главна информация
В платформен вариант 8.3.5.1068 , публикуван през септември 2015 г., механизъм за интегриране на 1C с външни програмичрез технологията REST интерфейс. Платформата използва протокола OData като протокол за достъп. Това е отворен уеб протокол за заявки и актуализиране на данни. Тя ви позволява да манипулирате данни, като използвате HTTP команди като заявки. Отговорите във версия 8.3.5.1068 могат да бъдат получени само във формат Atom/XML . Въпреки това, започвайки от версия 8.3.8.1652 през август 2017 г., се появи втора опция за получаване на данни във формат JSON (JavaScript Object Notation). . В сравнение с XML, той е лесен за четене от хората и заема по-малко място. Освен това всички браузъри имат вградени инструменти за работа с JSON.
Работата с протокола OData на платформата 1C: Enterprise може да бъде намерена в книгата 1C: Ръководство за разработчици в глава 17 Механизми за интернет услуги, параграф 17.2.1 Стандартен интерфейс OData.Можете също да разгледате примери за разширяване на поддръжката на OData протокол,
Използвайте предимство REST интерфейс. заключава, че за да се получи достъп до системни данни от външно приложение, не е необходима модификация на кода на решението на приложението (например, ако решението на приложението се поддържа). За да получите този достъп, трябва да публикувате приложението на уеб сървъра по специален начин и да посочите кои конфигурационни обекти ще се използват по този начин. След това системи на трети страни могат да имат достъп до вашето приложение с използвайки HTTPзаявки.
Публикуването на стандартния интерфейс OData се извършва с помощта на диалоговия прозорец за публикуване на уеб сървъра (Администриране - Публикуване в уеб сървър) и описан в книгата 1C: Enterprise 8.3. "Ръководство на администратора".
важно!За да могат конфигурационните обекти да станат достъпни чрез стандартния интерфейс OData, трябва да активирате това чрез метода на глобалния контекст Задайте състав на StandardODataInterface().
Механизмът за задаване на състава на обектите, налични чрез стандартния интерфейс OData, може да се направи във формуляра външна обработка. Това не изисква модификация на приложеното решение.
За взаимодействие с външен REST уеб сървър от 1C:Enterprise се използват наличните в платформата инструменти за работа с HTTP: обекти HTTPConnection, HTTPRequest и HTTPResponse.
В тази поредица от статии ще покажа примери за типични операции, използващи съответния HTTP метод;
- Събиране на данни – метод ВЗЕМЕТЕ;
- Създаване на обект – метод ПУБЛИКУВАНЕ;
- Актуализация на данните: метод КРЕПКА- в този случай можете да посочите само тези свойства, които трябва да бъдат актуализирани; метод СЛАГАМ– в този случай е необходимо да се уточнят всички свойства на обекта;
- Изтриване на данни - метод ИЗТРИЙ.
1. Примери за събиране на данни. HTTP метод GET
Сървърът ще бъде база данни, публикувана на уеб сървъра с името webbuh(Демо-база „Счетоводство на предприятието 3.0“). Ще използвам формата JSON като формат за обмен на данни. Повече информация за работа с JSON е написана в наличната документация. За да получавате данни от сървъра чрез метода GET HTTP, трябва да създадете обект Четене на JSONза последователно четене на JSON данни от файл или низ. За да организирате последователно записване на обекти и текстове на сървъра с помощта на метода POST PATCH PUT HTTP, трябва да създадете обект Запис в JSON.Имайте предвид, че методът DELETE не изисква JSON.
Като илюстрация на поточно четене и писане на JSON при достъп до интерфейса REST, ще извикам следната персонализирана функция с общо предназначение Обадете се на HTTPMethodOnServer :
&На сървъра // <Описание функции>// // Настроики: //За да получите от сървъра във формат JSON, при достъп до REST интерфейса на приложението трябва да посочите в адреса на ресурса $format=json.Или посочете MIME тип приложение/jsonв заглавието:
заглавия = нов мач(); Headers.Insert("Content-Type", "приложение/json") ; ResourceAddress =" webbuh/odata/standard.odata/ ?$format=json" HTTP заявка = Ново HTTPRequest(ResourceAddress, Headers);Функция за глобален контекст ReadJSON(ReadJSON, True )
- Ако стойността на втория параметър е зададена на True, четене на обекта JSONще бъде направено в Кореспонденция.Ако е зададено на False, обектите ще бъдат прочетени в обект от тип Структура.
- Когато десериализирате JSON обекти в структура, имайте предвид изискванията за ключ на структурата. Ако десериализацията на обект открие име на свойство, което не е валидно за структурен ключ, ще бъде хвърлено изключение.
1. 1 Конфигуриране на параметри на HTTP връзка
За да организирам клиентската част от взаимодействието с външен REST уеб сървър, създадох клиентска конфигурация, базирана на BSP от нулата. В тази конфигурация създадох директория за настройка на параметрите на връзката (вижте Фиг. 1)
Фигура 1 Справочно ръководство за конфигуриране на параметри на HTTP връзка към външен IB през интерфейса за почивка
След натискане на бутона Проверете отговора на сървъра извиква се процедура, чрез която клиентът ще се опита да получи отговора на сървъра. Програмният код за процедурата е написан по-долу:
&OnClient Процедура CheckConnection(Command) Address = Object.ServerAddress; Потребител = Object.User; Парола = Object.Password; Базово име = Обект.Име; Порт = ? (Object.Port<>0,Object.Port,80); HTTPConnection = Ново HTTP връзка (адрес, порт, потребител, парола); ResourceAddress = BaseName + "/odata/standard.odata/ $метаданни "; //Извикване на персонализирана функция Структура на отговора= Б callHTTPMethodOnServer("ВЗЕМИ", HTTP връзка, адрес на ресурс) ; Ако Структура на отговора <> Недефиниран Тогава General PurposeClientServer.InformUser("Код на състоянието "+Структура на отговора.Код на състоянието); край ако; EndProcedureЦелта на тази процедура е сервизна проверка идали потребителят е въвел правилно параметрите на връзката. За да направите това, просто направете GET заявка:
HTTPConnection.CallHTTPMethod( "ВЗЕМИ", Заявка HTTP);
използвайки адрес на ресурс:
Адрес на ресурса
=BaseName+ “/odata/standard.odata/
“;
Можете също да проверите работата на услугата в браузъра, като използвате
URL адрес http://host/WebBuh/odata/standard.odata. В резултат на такова запитване се получава само списък с обекти. За получаване пълно описаниестандартен интерфейс OData (списък на налични обекти, техните атрибути и функции под формата на XML-
документ.) трябва да направите GET заявка, като използвате параметъра $метаданни.
URL адрес http://host/WebBuh/odata/standard.odata/$metadata. Подробно описаниеДокументът е достъпен на http://www.odata.org/documentation/ (на английски).
Можете да получите отговори във формата Atom/XMLили JSON. Кодовете за състояние на HTTP отговор могат да се видят Отговори в диапазоните:
- 100-199 – информационни отговори, показващи, че заявката на клиента е приета и се обработва.
- 200-299 – означава, че заявката на клиента е обработена успешно.
- 300-399 означава, че заявката е неуспешна и клиентът трябва да предприеме някакво действие, за да удовлетвори заявката.
- 400-499 - информира за грешки от страна на клиентското приложение. Тези кодове може също да показват, че се изисква допълнителна информация от клиента.
- 500-599 - Информира за грешка от страна на сървъра, показва, че сървърът е срещнал грешка и вероятно няма да може да изпълни заявката на клиента.
1.2 Търсене на обект по ID
Следната функция е предназначена за търсене на директория или документ по уникален идентификатор на сървъра. Ако обектът бъде намерен, тогава функцията връща стойността на низа на идентификатора (Ref_Key), в противен случай връща недефиниран.Следните параметри се предават на функцията:
- HTTPConnection – Обект от тип HTTPConnection
- PublishName - Името на публикуваната сървърна база данни
- Елемент - идентификатор на обекта, например, Каталог_Организацииили Документ_ - директория на Организацията.
- Идентификатор - идентификаторът на обекта, който трябва да се търси на сървъра, например, Организация.UniqueIdentifier()
Параметър Адрес на ресурса се използва за достъп до услугата REST. За да проверите работата на услугата, можете да посочите ресурса в браузъра по този начин
http://(WebServerAddress)/(PubName)/odata/standard.odata/(Item)?(Параметри) ,Където
- Адрес на уеб сървъра– Адресът на уеб сървъра, където е публикувана услугата, например Localhost
- Име Публикации- Име информационна базапосочени към момента на публикуване на решението
- /odata/standard.odata/ – Знак за достъп до стандартния OData интерфейс
- елемент – идентификатор на ресурс или предварително дефинирани ресурси. Например Catalog_Account(guid'value').
- Настроики– ресурсни параметри. Използва се например за избор в приетите за HTTP заявки: ?key=value&key2=value2
1.3 Търсене на обект чрез полета за търсене
Следната дефинирана от потребителя функция е предназначена за търсене на обект по полета за търсене в случай, че обектът е по идентификационен номер. Низ на функционален обект Ref_Key-идентификационен номер.
&AtServer функция P searchObjectBySearchFields(HTTPConnection,PublicationName, Element,SearchFields)Условие = "" ;За всяка ключова стойност от цикъла на полето за търсене Състояние = Състояние + KeyValue.Key+"eq""+ KeyValue.Value+ "" и "; EndCycle; RequestText =Lion(Условие, StrLength(Условие)-5); // премахнете последните 5 знака Адрес на ресурса= Име на публикация+ "/odata/standard.odata/" +Елемент+ "?$filter=" + RequestText+ "&$format=json& $select=Ref_Key" ; // Извикване на моя персонализирана функция Структура на отговора= callHTTPMethodOnServer( "ВЗЕМИ",HTTPConnection,ResourceAddress);Ако Структура на отговора .StatusCode >= 400 Тогава //ClientServer с общо предназначение.InformUser(Element+ "Error"+Response Structure.StatusCode); //ClientServer с общо предназначение.NotifyUser(ResponseStructure.ServerResponseUndecrypted); връща недефиниран; EndIf; Съвпадение = Структура на отговора. ResponseServer a; Масив = Съвпадение ["стойност" ]; If Array = Undefined Then Return Match ["Ref_Key" ] Else Return Array ["Ref_Key" ]; EndIf; Крайни функцииКакто се вижда от тялото на процедуратаП SearchObjectByFieldsSearch, изборът започва с ключова дума$филтърв адреса на ресурса. Формален параметърПолета за търсене -това е кореспонденция, която съдържа имената и стойностите на атрибутите.
Обърнете внимание, че името на детайлите понякога не е очевидно. Трябва да се помни, че за директории:
- код - код,
- Описание
- DeletionMark - знак за изтриване,
- IsFolder - знак за група,
- Parent_Key е родителят.
- Ако атрибутът е от референтен тип, добавете суфикса _Key към името му, например Contractor_Key.
За документи:
- Номер – номер на документ,
- Дата - дата на документа.
Операции за логически избор
- eq - Равно на; /Catalog_Cities?$filter=Име eq ‘Главен’;
- ne - Не е равно; /Catalog_Cities?$filter=Име ne ‘Перм’;
- gt - повече; /Catalog_Products?$filter=Цена gt 10;
- ge - По-голямо или равно на; /Catalog_Products?$filter=Цена ge 10;
- lt - по-малко; /Catalog_Products?$filter=Цена lt 10;
- le - По-малко или равно на; /Catalog_Products?$filter=Цена le 10;
- или - Логическо ИЛИ; /Каталог_ Продукти ?$filter= Цена lt 10 или Цена gt 100;
- и - Логическо И; / Каталог _Продукти?$ filter =Цена g t 10 и Цена l t 100;
- не - Отрицание; /Каталог_ Продукти ?$filter=not (Цена eq 10);
Обърнете внимание също, че стойността на действителния параметър елемент(или обект)), който предавам на функцията формира се по следното правило:
PrefixName_ConfigurationObjectName_SuffixName.
Използвайки стандартния интерфейс OData, можете да получите достъп следващи обекти (Префикс на име):
- Справочник – Каталог;
- Документ - Документ;
- Журнал за документи - DocumentJournal;
- Константа - Константа;
- План за обмен - ExchangePlan;
- Сметкоплан - ChartOfAccounts
- План тип изчисление - ChartOfCalculationTypes;
- Диаграма на видовете характеристики - ChartOfCharacteristicTypes;
- Информационен регистър - InformationRegister;
- Регистър за натрупване - AccumulationRegister;
- Изчислителен регистър - CalculationRegister;
- Счетоводен регистър - AccountingRegister;
- Бизнес процес – BusinessProcess;
- Задача - Задача.
ConfigurationObjectName- свойство "Име" на конфигурационния обект, както е зададено в конфигуратора.
Име на суфикса- необходим за указване на името на ресурса, по избор, може да приема следните стойности:
- Името на табличната част на обекта;
- Име виртуална масаобект;
- RowType - ред от табличната част на обекта;
- RecordType е един запис в регистъра.
Опции за достъп до ресурси
След като формирате името на ресурса, трябва да дефинирате параметрите за достъп до ресурса, напр. ?$filter= Значение &$формат=json& $select= Ref_Key ,
- $филтър- избор при получаване на данни
- $формат- определя формата на върнатите данни,
- $избор- изброяване на свойствата на обекта, които ще бъдат включени в резултата от заявката;
- $метаданни- връща описание на стандартния OData интерфейс (използван без посочване на суфикс на име, пример е в едно от изображенията по-горе);
- $отгоре- ограничаване на броя на върнатите записи;
- $пропускане- премахва посочения брой записи от резултата на заявката;
- $брой- връща броя на записите в селекцията на заявката;
- $inlinecount=allpage(=няма)- добавя информация за броя на записите към резултата от заявката
- $orderby=<Реквизит1>възходящ,<Реквизит2>дес- сортиране на резултата от заявката
- allowOnly- само позволено (използвано без знака "$").
1.4 Вземете масив от записи в регистъра с информация
Нека да разгледаме пример за получаване на масив от записи на регистъра с информация за пълното име на лицата, например историята на промяна на пълното име индивидуален
Име Публикации ="WebBuh";Елемент = "InformationRegister_Name of Individuals"; Период = Недефиниран; ReferenceType данни= Нова структура (); д DataReferenceType.Insert("PhysicalPerson",PhysicalPerson_Key); DataNonReferenceType= Нова структура (); DataNonReferenceType.Insert("PhysicalPerson_Type", "StandardODATA.Catalog_PhysicalPersons") Масив = GetRegisterRecordSetDetails(HTTP връзка, име на публикация, елемент, период, DimensionsReferenceType, Измервания на Non-ReferenceType)Тялото на функцията GetRegisterRecordSet, която се извиква в този пример, е показано по-долу.