Доступ к api что это в 1с
API серверов обеспечивает передачу внешней системе списка измененных объектов данных с указанного момента времени, а не полного списка объектов. Это позволяет существенно экономить вычислительные ресурсы и сетевой трафик, но требует от внешней стороны вести учет меток актуальности данных 1С-Коннект.
API серверов поддерживает следующие действия с объектами системы 1С-Коннект:
- Создание, изменение, удаление и выгрузку списков следующих видов объектов:
- сотрудник своей организации;
- клиент (юр.лицо);
- сотрудник клиента;
- линия поддержки;
- компетенция сотрудника по линии;
- подключение линии поддержки потребителю (сотруднику своей организации/ сотруднику клиента);
- обращение по линии поддержки;
- заявка на обслуживание.
Доступ к API серверов , а также настройка часового пояса, в соответствии с которым будет показана ин формация, получ енная с помощью web - сервисов, настраиваются в Личном кабинете в разделе " Администрирование" подраздел "Настройки API" . Также в этом подразделе вы можете посмотреть статистику по использованию web - сервисов.
- API серверов основан на механизмах Web-сервисов в реализации "1С: Предприятие 8.3".
- Все операции манипулирования данными сгруппированы по-объектно.
- Добавление, изменение и удаление объектов определенного вида можно делать пакетно, т.е. "пачкой за 1 раз".
- Все входные параметры вызова ws-операции передаются одной переменной-массивом ( XDTO - совместимой с типом «Структура» прикладного яз ыка "1С: Предприятие 8") - это позволяет впоследствии расширять перечень передаваемых параметров, сохраняя совместимость с ранее написанными клиентами внешними алгоритмами.
- У всех ws-операций единая структура ответа, она позволяет при успехе выполнения передать результат, а при ошибке выполнения - сведения об ошибке и месте её возникновения.
- Во избежание непреднамеренной DDoS-атаки путём беспрерывной бесконечной цепочки запросов к API, на каждый вид ws-операции наложено ограничение по максимальному количеству вызовов операции в час. Параметры ограничений указаны в таблице.
Пример реализации на платформе 1С
Обработка-пример вызова операции GetHistoryOfServiceCalls: ВызовОперацийPartnerAPI2.epf
Структура результата ws-операции
Каждая операция на выходе выдает структуру из двух полей: ResultCode, ResultData. ResulеCode содержит код выполнения, если код = SUCCESS, то в поле ResultData результат операции, иначе текстовое описание ошибки. Н еобработанная ошибка вызовет исключение, и операция вернет исключение с текстом ошибки.
При пакетной передаче данных поле ResultData будет содержать таблицу значений. Объекты в пакете обрабатываются построчно. При этом н омер строки входного параметра будет соответствовать номеру строки , соответствующей этому запросу на выходе. При возникновении ошибки выполнение операции не прекратится, пока не обработаются все содержимое пакета, либо не будет достигнут лимит.
Ссылка для подключение к web-сервису
Алгоритм выполнения ws-операции
Проверка превышения лимита по количеству вызовов этого вида операции в текущее время суток.
В статье описаны варианты подключения И решение граблей по подключению к REST API через протокол OAuth 2.0 из 1С. При разработке такого подключения для получения данных и загрузки в базу 1С я столкнулся с некоторыми проблемами, решил их и хочу поделиться этими наработками.
Введение
Задача: подключение к REST API по протоколу Oauth 2.0 и получение данных от API для дальнейшего парсинга и загрузки в БД.
Решение состоит из:
* Получение токена авторизации;
* Получение данных с использованием токена авторизации.Получение токена авторизации
Получение токена авторизации выполняется при помощи POST запроса XTTP, при этом есть нюансы реализации этого запроса для x32 и x64 разрядных версий сервера 1С, а также особенности при работе этого запроса в веб клиенте.
XTTP запрос для получения токена OAuth выглядит следующим образом:
Проблемы при работе с POST XTTP подключением авторизации
1. Ошибка при получении токена на x64 разрядном сервере 1С.
Можно столкнуться с проблемой, когда у клиента 1С в развернута в платном облачном сервисе, где возможности изменить параметры сервера или зарегистрировать дополнительные dll нет возможности, либо запрещено выполнять JavaScript, который в нашем коде создается в строке COMОбъект("MSScriptControl.ScriptControl").
То есть, если подключение XTTP описано на сервере, например в модуле объекта обработки и при этом сервер 1С x64 разрядный, то можно получить следующую ошибку:
: Ошибка при вызове конструктора (COMОбъект): -2147221164(0x80040154): Class not registered.
2. Ошибка при получении токена при помощи объекта "WinHttp.WinHttpRequest.5.1" на клиенте при работе в веб клиенте 1С.
Если XTTP подключение описано на клиенте в форме обработки, то при выполнении этого кода в браузере Chrome, можно получить следующую ошибку:
Ошибка связана с особенностями запуска ActiveX объектов в браузерах. В Internet explorer текст ошибки может отличаться.
Решение ошибок
Для решения проблемы с исполнением кода на x64 разрядном сервере нужно перенести код подключения на клиент в форму обработки, так как это представлено в примере кода выше. Но при этом получается что в браузере это решение всё ещё работать не будет. Потому что браузер с нужным нам COM объектом работать не может и углубляться в причины этой проблемы будет просто потерей времени. Гораздо более быстрым решением станет реализация этого запроса при помощи JavaScript помещенного в элемент формы с видом ПолеHTMLдокумента.
Решение получения токена в веб клиенте
Есть различные варианты реализации подхода через ПолеHTMLДокумента. Например можно сделать кнопку "Войти" на форме и по этой кнопке вызывать скрипт описанный в HTML документе, а можно сверстать HTML, поместить его в ПолеHTMLДокумента, то есть кнопка "Войти" будет элементом HTML страницы. Я реализовывал второй вариант.
Токен получен. Соответственно токен нужно положить в какой-нибудь реквизит, либо передать токен в основную форму обработки, если форму авторизации вы сделали как отдельную форму настройки.
Получение данных из API с использованием токена авторизации
Для получения данных с использованием токена нужно описать XTTP запрос, но уже GET. Аналогично получению токена, реализация для веб клиента и тонкого клиента будут различаться. Для веб клиента это HTML+JavaScript, для тонкого клиента это XTTP с использованием COM "WinHttp.WinHttpRequest.5.1".
Есть некоторые общие функции для формирования параметров, которые подставляются в запрос.
Реализация получения данных для тонкого клиента
Есть нюанс в заголовке XTTPЗапрос.setRequestHeader("Origin", "*"), чтобы запрос к API работал с этим заголовком, нужно обсуждать параметры API с теми кто им заведует. Насколько я знаю, в настройку Origin на сервере API нужно устанавливать значение адреса домена с которого осуществляется подключение. Без настройки этого заголовка на сервере и установки этого заголовка в коде 1С может возникать ошибка авторизации 403.
Реализация получения данных для веб клиента
Аналогично авторизации, необходимо при создании формы заполнить содержание HTML документа на форме. При этом не получиться сделать поле HTML на форме 1С невидимым, иначе оно не инициализируется. Поэтому просто делаем все элементы HTML разметки невидимыми при помощи display:none.
Т.к. время запроса к серверу может в зависимости от нагрузки на сервер быть разным, то нужно предусмотреть ожидание получения результата. Поэтому получения данных из HTML+JS у меня реалезовано не через функцию, а процедуру, в которой после выполнения скрипта подключается обработчик ожидания с вызовом функции, и в этой функции после того как мы увидели, что результат запроса был помещен в div "result" JavaScript'ом, мы получаем из этого div'а текст JSON и отправляем его на обработку в другие процедуры и функции.
Проблемы при работе с GET XTTP подключением получения данных
Чуть выше я уже кратко упомянул проблему, которая возникает при попытке получения данных, когда уже вроде бы должно всё работать. У нас есть токен авторизации, но когда мы пытаемся подключиться для получения данных, мы получаем ошибку авторизации 403. Она так же может отображаться в 1С следующим образом:
: Ошибка при вызове метода контекста (Получить): Ошибка работы с Интернет: Couldn't resolve host name.
Чтобы понять, что надо использовать заголовок Origin и настраивать его на сервере API, а не искать причину в чем то другом, нужно сделать следующее:
1. Создать и сохранить у себя на ПК новый HTML документ следующего вида
Заполняем собственные логин, пароль, и другие параметры в скрипте, и сначала нажимаем "Войти", чтобы получить токен в
2. Открываем этот HTML в специальном режиме браузера Chrome:
Открыв браузер таким образом, будет отключена защита браузера CORS, и можно проверить, наш запрос в 1С не работает потому что срабатывает эта защита, или по какой-то другой причине. То есть, если возникнет ошибка в этом режиме браузера и данные мы не получили, то дело НЕ в CORS, а если в этом режиме браузера загружается, а в 1С не грузится с ошибкой "Couldn't resolve host name", то это проблема связана с CORS.
Также можно использовать программу Postman и попробовать выполнить запрос в этой программе.
Дополнительные настройки
Помимо этой проблемы стоит так же предусмотреть возможные проблемы при работе в IE. Рекомендую выполнить следующие настройки в своей системе:
1. IE свойства браузера - зайти в вкладку "Дополнительно" и у становить флаг «Разрешать запуск активного содержимого файлов на моем компьютере»;2. Если установлен Касперский - нужно снять флаг с настройки «Внедрять в трафик скрипт взаимодействия с веб-страницами», который находится в "Настройки"(шестеренка) -> "Сеть".
Итак, начнем сначала.
Что такое REST и зачем он нужен
REST (REpresentation State Transfer) подход является одним из наиболее популярных подходов, использующихся для реализации web-сервисов в Интернете. REST web-сервисы являются более легковесными альтернативами SOAP веб-сервисам.
REST с технической точки зрения не является ни технологией, ни стандартом. Это всего лишь подход, если можно так сказать, набор принципов, которые помогают реализовать "правильный" web-сервис. Под "правильным" здесь понимается масштабируемый, безопасный, надежный, легкий в использовании и т. д.
REST определяет следующие принципы построения web-сервисов:
Преимуществами REST подхода являются:
Недостатки REST'а являются продолжением его достоинств:
Протокол, который основывается на принципах REST, является RESTful протоколом. Два наиболее популярных типа RESTful протоколов - это JSON (JavaScript Object Notation) и POX (Plain Old XML). JSON использует для кодирования данных JavaScript и в основном применяется в Ajax (Asynchronous JavaScript and XML) клиентах для обмена данными с сервером. Поскольку Ajax клиенты работают в браузере, который понимает JavaScript, то использование JavaScript позволяет сэкономить как на объеме передаваемых данных, так и на времени разбора данных. Однако использование JSON в других клиентах проблематично, т. к. клиенты, как правило, не поддерживают JavaScript.
POX использует для кодирования данных XML и поэтому может использоваться практически везде.
REST в 1С
Использовать стандартный интерфейс OData прикладного решения просто:
По умолчанию после публикации объекты конфигурации не доступны. Прежде чем обращаться к ним, необходимо разрешить доступ, например с помощью типовой обработки "Настройка автоматического REST сервиса". В обработке можно задать отдельного пользователя REST сервиса:
и указать доступные объекты конфигурации:
"odata/standard.odata" - "магическое" слово, означающее доступ через odata интерфейс
"Catalog_Контрагенты" - состоит из указания на тип объекта "Catalog" - справочник и типа справочника
"select" - оператор чтения данных, после него через "=" идет описание считываемых данных, в данном случае это "Ref_Key" - уникальный идентификатор
"format=json" - задает формат представления считываемых данных JSON
"odata=nometadata" - заклинание, указывающее не передавать в ответе описание метаданных.
и отправляем его:
Если все хорошо, в ОтветСтрокой находится что-то вроде:
Разобрать ответ можно например так:
Если Ответ.КодСостояния > 299 Тогда ТекстОшибки = "Error, код ошибки: " + Ответ.КодСостояния + " |" + ОтветСтрокой; Иначе КолСтрок = СтрЧислоСтрок(ОтветСтрокой); Для НомерСтроки=1 По КолСтрок Цикл СтрокаАнализа = СтрПолучитьСтроку(ОтветСтрокой, НомерСтроки); Если СтрНайти(СтрокаАнализа,"Ref_Key") > 0 Тогда ПозицияДо = СтрНайти(СтрокаАнализа, """",НаправлениеПоиска.СКонца); ПозицияС = СтрНайти(СтрокаАнализа, """Ref_Key"": """); Если (ПозицияС > 0) И (ПозицияДо = (ПозицияС + 48)) Тогда НачалоID = ПозицияС + 12; GUID = Сред(СтрокаАнализа, НачалоID, 36); РезультатМассив.Добавить(GUID); КонецЕсли; КонецЕсли; КонецЦикла; БулевРезФун = Истина; ТекстОшибки = "OK. Считано элементов: " + Формат(РезультатМассив.Количество(), "ЧН=0; ЧГ &$filter=Ref_Key eq guid'" + KeyID + "'";
где в KeyID строковое представление УИД
Наименование реквизитов как видите порой неочевидно. Необходимо запомнить:
DeletionMark - пометка удаления,
IsFolder - признак группы,
Если реквизит ссылочного типа, к его имени следует добавить суффикс _Key, например Организация_Key.
Для документов используется схожий синтаксис:
/Base1C/odata/standard.odata/Document_СчетНаОплатуПокупателю?$select=Ref_Key, Number, Date&$format=json;odata=nometadata
Number - номер документа,
Date - дата документа.
Создание и изменения объектов через REST будет в следующей части.
Специальные предложения
Еще, как недостаток, крайняя нестабильность при использовании в системах бизнес-аналитики. Может положить весь кластер "1С:Предприятие" (конфигурация, что падала: 40 Core\192GB RAM\RAID SSD DB\2xSSD tempdb).
(1) Не советую использовать REST в бизнес-аналитике. REST в 1с использует оптимистическую блокировку данных. С одной стороны такой подход повышает скорость работы, с другой можно получить не корректные цифры в отчете. Положить кластер у меня пока не получалось, хотя глюков наловил не мало.
(2) Хорошая статья, жаль что я не прочитал ее раньше, когда только осваивал работу с веб-сервисами. Основное достоинство REST - производительность. После "прогрева" системы REST сервис работал в 3-10 раз быстрее чем аналогичные по функционалу SOUP сервис. Такая разница стоит мучений.
Вызов Web-сервиса происходит следующим образом:
? из пула соединений выбирается подходящее соединение с информационной базой; при отсутствии необходимого соединения соединение создается;
? создается новый сеанс и для созданного сеанса вызывается событие УстановкаПараметровСеанса (в модуле сеанса);
? выполняется вызов затребованного метода Web-сервиса, при этом происходит вызов обработчика УстановкаПараметровСеанса() (в модуле сеанса) каждый раз, когда происходит обращение к неинициализированному параметру сеанса.
Если в пуле нет соединений, то создается новое соединение с загрузкой метаданных, что аналогично запуску 1С с нужной конфигурацией.
В новых версиях, программа может выбирать нужный сеанс из пула при этом УстановкаПараметровСеанса производиться не будет.
(22) В (24) подробно описано. Первое обращение к сервису вызывает загрузку и инициализацию используемых библиотек. Оно всегда долгое и учитывать его в замере производительности неверно.
Эх, не дошли до самого интересного - до записи. Будете продолжать? Почему-то когда я читаю из базы документ, меняю в ответе один реквизит и пытаюсь записать, то в ответ возвращается всякая ерунда (обычно что не заполнена дата).
(8) Я скорее практик чем теоретик. Состояние реализуется элементарно, на глобальных переменных или РС. Если выполнение кода сервиса зависит от значения глобальной переменной, эта переменная хранит состояние сервиса.
(9)Глобальные переменные не подойдут - при работе с REST-Сервисом их нет. А хранение состояния в регистре сведений возможно - указано мной в (14), но это не то состояние, которое закладывается в определении REST-Сервиса
До не давних пор WEB-Сервисы в 1С не имели возможности хранить состояния сеанса (теперь могут) + необходимость их предварительно кодить на 1С, чтобы использовать - это их главное отличи от REST-Сервисов (но зато WEB-Сервисы более универсальны (ведь в их реализации можно написать любой алгоритм); а области данных, доступ к которым можно получить в ИБ через REST-сейчас очень ограничены, например управлять пользователями нельзя).
(13)В простейшем виде. Состояние - любая управляемая (на которую клиент может целенаправленно влиять) информация, которая сохраняется на сервере после выполнения последней команды, и может быть получена (учтена) при выполнении следующей команды (при этом, при параллельном выполнении множества команд, в т.ч. от разных клиентов) нужная информация (созданная первой командой) будет автоматически (не важно как) сопоставляться со второй командой и соотноситься с исходным клиентом (когда это требуется).
За исключением тривиального примера: когда целем выполнения первой команды есть ТОЛЬКО создание этой информации. А второй команды - только её получение!
Путь будет так, простите, коли запутанно или не точно раскрыл термин. Я не профессор. Понятн, что за уши к этму определению можно приникнуть многое, но делать это не стоит.(8)Дополнительно поясняю: описанный вам пример является требует наличия состояния на сервере, но не соответствует определению REST-сервиса. Насколько я понимаю, REST-Сервисы вообще не предназначены для запуска выполнения таких фоновых процессов. Но если они уже запущены, или запускаются косвенно после внесения изменений в данные, то формально, можно организовтаь что вы хотите, например так (как уже было предложено в (9)):
1. Допустим на сервере 1С есть регл. задание - которое выполняет какую-либо фоновую обработку (возможно через запуск отдельных фоновых заданий - это не принципиально).
2. Это регл задание, например, мониторит рег. сведений - на наличе записи с запросом на выполнение регл задачи (например произвольного алгоритма из строкового ресурса)
3. Тогда REST запросом - можно внести в этот регистр эту запись + некий ключ
4. Регл. задание это увидит и запусит фоновое выполнение этой задачи, передав ей этот ключ
5. Фоновое задание выполнит переданный алгоритм, например, некоторую часть (как это определяется к сути данного вопроса не относится) и запишет в тот же или другой рег. сведений по имеющемуся ключу результат (окончательный или промежуточный)
6. Внешний процесс через REST-Сервис будет опрашивать этот регистр по тому же ключу на наличие результата.
7. При необходимости через REST-сервис можно внести запись в регистр сведений, что выполнение нужно прервать (или внести изменения)
8. Эту запись то же регл задание может увидеть и прервать выполнение фонового задания с соответствующим ключём (или это может сделать само фоновое задание, тогда оно может внести любое изменения в ход своего выполнения).Формально говоря, REST-Сервисы можно использовать и для выполнения каких-то фоновых процессов и опроса их результатов. И даже состояние в этом случае сохраняется в информационной базе. Но это лишь обходные уловки, реализация которых требует внесения изменений в конфигурацию. А сами данные состояния клиента, просто хранятся в базе данных. Но тем не менее, описанный мной выше алгоритм взаимодействия вполне может быть использован в рабочих системах.
По-другому запустить выполнение алгоритма через REST-Сервис в 1С (это ограничение текущей реализации 1С 8.3.9) пока нельзя. Но, думаю, со временем это изменится. И тогда, запустить, скажем фоновое выполнение задания можно будет и через REST. Но хранить состояния всё равно нужно будет в ИБ во вспомогательных хранилищах. И это не будет текущим состоянием сеанса. Это буду данные в базе данных.Варианты хранения такого состояния ограничены лишь тем, что можно сохранить в БД. Например, не удастся так хранить состояние COM -Соединения, или иного сетевого соединения с другим ресурсом (в сети, интернете, или файлом); или оборудованием (подключенном через компоненту). Для многих задач хавтит и описанного способа, но не для всех.
(14) Вспомнил, что у ряда объектов метаданных (связанных с хранением данных) есть события изменения данных (в самих объектах и в приписках на события). В описании REST-Сервисов про них не сказано, но надо полагать они буду срабатывать, при изменении данных через REST. Соответственно, в предложенном мной примере запуска фонового процесса через REST-сервис регл. задании лишнее - если, скажем в модуле набора записей указанного в (14) регистра сведений в событии "ПриЗаписи" разместить алгоритм, который сам будет запускать фоновые задания, то фоновый процесс будет сразу же запускаться после окончания записи в регистр сведений через REST-вызов. Далее достаточно лишь опрашивать через REST регистр сведений с результатом (по тому же ключу).
Формально, состояние клиента есть, и оно хранится в базе данных (получается по ключу, который сформировал клиент в первом обращении), как и есть возможность периодически опрашивать сервер, для получения промежуточных или итоговых данных.Там не только подписки, но и выполнение на сервере итд.
И делать проверку модулей с галками внешнее соединение, сервер(17) Там один какой-то срач от неправильного применения REST, до неправильно написанных конфигураций 1С.
А вот стыбзенная мистой (или Вами переложенная на мисту) Ваша публикация LINQ to oDATA интересна, хоть и очень коротка (но это уже немного о другом)!
Видимо я что-то пропустил. О каких состояниях сеанса, которые хранятся на сервере между клиентскими вызовами, вы говорили? Если о возможности реализовать собственные состояния на базе РС, то такая возможность была в платформе изначально. А про возможность устанавливать значения параметрам сеанса или создавать глобальные переменные, значения которых не будут пропадать между вызовами, я что-то не слышал.(33)Вот тут была инфа.
Там всё очень расплывчато. Хотите - поищите ещё, т.к. это ещё год назад появилось, может есть более толковые статьи на эту тему. Лично сам не проверял :-((34) спасибо. Разобрался с заголовком IBSession. Не для массового использования, но некоторые задачки интеграции закрыть можно. В принципе все понятно, нужно бы только на каком-то тестовом примере опробовать, прежде чем брать в реальную работу.
(35)Когда окончательно разберётесь и опробуете на практике - напишите на инфостарте статью - будет Вам плюсик в карму.
Вообще использование web сервисов для меня это массовость, т.е. ты пишешь какой-то проект на web, а базу 1с используешь как backend. И тут вырисовывается проблема, при этом очень большая, каждое соединение через REST сервис съедает одну лицензию, если не ошибаюсь. Поэтому хорошие люди пишут свои костыли типа metadata.js, реализуя фактически легкий web клиент для высоко нагруженных сервисов обходя проблему лицензирования и не совсем web интерфейса тонкого клиента.
В открывшемся окне следует открыть последнюю ошибку события «Электронное взаимодействие. Обмен с контрагентами».
Типичные ошибки и способы их исправления:
Причина ошибки: Пользователь является должником по расчётам за использование сервиса. Доступ к 1С-ЭДО для данного клиента заблокирован. Информация по оплате приведена в пользовательском соглашении. Счет до 10 числа месяца, следующего за расчетным, выставляет официальный партнер Фирмы "1С". Если у пользователя нет договора с партнером Фирмы "1С", счет и договор будут выставлены на электронную почту от лица ООО "1С-Онлайн".
Решение: Пользователю необходимо оплатить выставленный счёт, после чего обратиться в техническую поддержку 1С-ЭДО для разблокировки.
Решение: добавить в Учётную запись ЭДО сертификат аккредитованного Удостоверяющего Центра согласно инструкции.
Причина ошибки: для работы в 1С-ЭДО используется сертификат юридического лица в субъекте которого отсутствует должность владельца сертификата. Для просмотра полной информации об электронной подписи необходимо открыть интересующий сертификат и нажать иконку «Показать данные сертификата, которые сохраняются в файле», затем перейти на вкладку «Субъект».
Решение: добавить в Учётную запись ЭДО сертификат электронной подписи, в котором присутствует необходимый атрибут согласно инструкции.
Причина ошибки: ОГРН в карточке Организации не совпадает с ОГРН в сертификате электронной подписи. Возможно, допущена опечатка.
Решение: указать корректный ОГРН в карточке Организации после чего повторно добавить сертификат электронной подписи в Учётную запись ЭДО согласно инструкции.
Взаимодействие с базой данных 1С возможно следующими методами:
Подготовка базы для взаимодействия по API.
Публикация на web-сервере.
Настройка сквозной авторизации.
При обращении к базе данных по API потребуется сквозная авторизация. Для ее обеспечения следует создать в базе пользователя с логином и паролем аналогичными учетным данным для основного или дополнительного пользователей. Также следует дать данному пользователю полные, либо необходимые для взаимодействия права.
Проверка наличия сервиса в конфигурации.
По умолчанию будут опубликованы все стандартные web-сервисы конфигурации. В таком режиме публикации к web-сервисам следует обращаться по ALIAS.
Узнать наименования сервисов, доступных для взаимодействия с данной конфигурацией, можно следующим образом:
Проверить правильность выполняемых действий можно следующим образом.
В любой конфигурации есть стандартный WS «EnterpriseDataExchange», к нему можно обратиться следующим образом.
Открыть подраздел Web-сервисы выбрать «EnterpriseDataExchange», в примере это «EnterpriseDataExchange_1_0_1_1» проверяем во вкладке «Прочее» его ALIAS – «EnterpriseDataExchange_1_0_1_1.1cws».
Теперь обращаемся к сервису через браузер добавив к ссылке на базу /ws/EnterpriseDataExchange_1_0_1_1.1.1cws?wsdl
При запросе логина и пароля следует ввести учетные данные пользователя, которые использовались для настройки сквозной авторизации.
Если при ответе на запрос получаем xml данные, значит предварительная настройка произведена корректно.
Взаимодействие посредствам web-сервисов.
Перед началом обращения к web-сервисам баз данных по API следует предварительно выполнить условия, указанные в предыдущем пункте данной статьи, это публикация информационной базы и настройка сквозной авторизации.
Для взаимодействия с базой данных через web-сервисы (WS). Просмотреть доступные для работы сервисы можно открыв базу в режиме конфигуратора, раскрыть раздел «Общие», раскрыть подраздел «Web-сервисы».
Как говорилось ранее, все WS по умолчанию уже опубликованы, к ним следует обращаться по alias, синтаксис можно посмотреть в конфигураторе через свойства конкретного сервиса, раздел «Прочее».
Как говорилось ранее, все WS по умолчанию уже опубликованы, к ним следует обращаться по alias, синтаксис можно посмотреть в конфигураторе через свойства конкретного сервиса, раздел «Прочее».
В запросе расширение «.1cws» меняем на «?wsdl»
При запросе логина и пароля следует ввести учетные данные пользователя, которые использовались для настройки сквозной авторизации.
Для публикации нестандартных сервисов, следует создать обращение в техническую поддержку, указать базу и сервис, который следует опубликовать.
Далее следует составить обращение в техническую поддержку, указать базу и сервис, который следует опубликовать. Инженеры внесут правки в публикацию, после чего её можно проверить, сделав соответствующий запрос через браузер, запрос должен иметь следующую форму:
Также необходимо учитывать тот факт, что для работы некоторых сервисов (например, для телефонии) необходима анонимная аутентификация, в рамках сервиса её допускается включать только для баз, работающих на SQL.
Взаимодействие по средствам стандартного интерфейса ODATA
Перед началом обращения к интерфейсу ODATA следует предварительно выполнить условия публикации информационной базы и настройку сквозной авторизации (описаны выше). Далее следует составить обращение в техническую поддержку, указать базу в которой следует опубликовать интерфейс ODATA.
После внесения правок в публикацию можно будет проверять обращение к базе через стандартный интерфейс, в формате json, пример:
Odata работает.
Теперь нужно обратиться к объекту к базе, сделаем на примере справочника Контрагенты:Следует войти в режим «Предприятие», открыть «Все функции» - «Обработки» и найти «Настройка автоматического REST-сервиса».
Теперь при выполнении запроса
Мы получаем ответ:
Запрос отработан корректно.
Взаимодействие с базами через FTP
Помимо вышеперечисленных вариантов с файлами и папками на облачном диске w можно взаимодействовать напрямую через ftp.
Читайте также: