Как использовать api сайта на 1с

Tutorial по обмену сайта с 1С. Часть вторая: зачем и как писать свой обмен с нуля на очередях и REST API

Всем привет! Меня зовут Артем, я старший разработчик в ИНТЕРВОЛГЕ. Наконец дошли руки рассказать про «обмен с 1С с нуля».

Типовой интернет-магазин состоит из двух частей: сайт и учетная система. Редко когда это цельный софт.

В статье речь пойдет о написании с нуля обмена сайта и 1С.

Напомню, что типовым обменом называют готовый функционал для передачи данных между учетной системой и сайтом. Битрикс и 1С имеют готовую интеграцию в модуле Интернет-магазин, вся настройка может быть произведена без участия программиста. Модуль позволяет производить обмен большинством типовых сущностей (склады, товары, цены, остатки, заказы, пользователи, справочники). Это решение подходит для 99% сайтов, которым нужна выгрузка и синхронизация данных между 1С и сайтом.

Когда же может понадобиться нетиповой обмен?

Если есть готовое решение, которое работает и покрывает большинство потребностей, что может пойти не так?

Не устраивает скорость обновления данных и реакция. Речь именно о том, что обмен справляется за разумное время, но заказчику хочется быстрее.
Часто ждут пресловутый «реалтайм».
Бизнес-логика настолько специфична, что типовой обмен не вписывается. Например, когда «каждый физический экземпляр товара это уникальный артикул», или «все позиции у нас заказные, ничего типового не продаем» или «цена зависит от объема отгрузок в прошлом месяце».
Типовой обмен не справляется в часы пиковой нагрузки. Черная пятница, вечер 14 февраля могут стать причиной головной боли программистов и операторов.
Особый софт. Не для всех 1С из коробки есть готовый модуль интеграции. Иногда часто дело в том что 1С очень старая, и очень доработанная.

Решать первые 2 пункта переписыванием обмена — плохая идея. Нужно смотреть на конкретные вводные и решать, почему так вышло, и что можно исправить в бизнес-логике, а не в обмене.

Пункты 3 и 4 – более весомые аргументы в пользу написания обмена с нуля, тут даже доработкой типового обмена не всегда получается обойтись. Поэтому это явные триггеры, что вам стоит задуматься о самописном обмене, либо использовать готовые нетиповые решения.

Разберем конкретный пример.

Наш пример самописной интеграции

Для кого все писалось: международная компания Levenhuk, производитель оптического оборудования с собственной сетью продаж в 14 странах.

Как следствие – много языков, много версий, оптовые и розничные сайты. А в сердце всего этого старая, но бодрая и полезная 1С (когда-нибудь мы расскажем о проекте перехода на свежую версию).

схема самописной интеграции 1С

На старте были старые самописные, мультиязычные сайты (b2c) и 1С. Развивать и поддерживать самописные сайты было некому. Были нужны новые языковые версии, новые фичи и еще куча всего. Было решено сделать новые сайты на Битрикс – проверенная платформа с кучей подрядчиков в России, где работает бэк-офис компании.

У старых сайтов была самописная интеграция между 1С и админкой на Django (postgre в качестве контентной БД). В этой админке заполнялись характеристики товаров, картинки, описания на всех доступных языках и прочий контент для отображения на сайтах.

Старая 1С, написанная практически с нуля, не поддерживает обмен, да еще и уникальна настолько, что потребовались недели для изучения всех механизмов и подводных камней.

После исследования 1С было предложено 2 варианта:

Обмен в формате CommerceML (xml), фактически повторение стандартных технологий обмена.
Обмен с использованием веб-сервисов (REST API).

Первый вариант подразумевал доработки на стороне 1С и минимум доработок на стороне сайта. Но он оказался настолько болезненным для 1С, что от него отказались. Тестирование функционала модуля обмена показало, что требуется исправление множества ошибок. Причина — отсутствие необходимых объектов конфигурации.

Пришли к выводу, что для текущей конфигурации целесообразно разработать модуль обмена, а не адаптировать типовой модуль для УТ. Обмен решили делать с использованием REST API, так как мы сами сможем подобрать удобный, понятный и простой формат данных.

Кроме того, стратегически нам казалось (и практика это подтвердила), что REST-обмен будет проще в развитии и будет более готов к нагрузкам.

В нашем случае сайт выступает в роли сервера, принимающего запросы, а 1С в качестве клиента, забирающего или отправляющего какие либо данные.

Что значит сделать обмен с нуля

Новые языковые сайты на БУС b2b.

Обновленные языковые сайты на БУС b2c (замена старым).

Интеграцию 1С и всех сайтов.

Перетащить все переводы и данные по товарам из postgre в БД новых сайтов.

Устройство REST-обмена

Сам обмен потребовал реализации передачи в двух направлениях довольно большого набора данных со связями между ними.

пример Rest обмена

Упрощенно можно сказать что разработка обмена с нуля требует:

разработки на уровне API почти-CRUD-методов для каждой сущности (в реальности не все методы нужны, например почти не используется Read, Update и Create сливаются в один, и крайне редко применяется удаление, чаще деактивация через Update);
реализация многих видов обмена (полного, изменениями, реалтайм, обогащающего) с применением этого API.

Работа эта лишь на первый взгляд проста. Всего было реализовано несколько десятков REST-методов на стороне сайта и 9 больших процедур на стороне 1С:

ВыгрузкаСпискаСкладов;
ВыгрузкаСпискаТиповЦен;
ВыгрузкаСтруктурыКаталогаТоваров;
ВыгрузкаКаталогаТоваров (этот метод используется для частичной, и для полной выгрузки)
ВыгрузкаКонтрагентов;
ВыгрузкаВзаиморасчетов;
ЗагрузкаДанныхДополнительныхСправочников;
ВыгрузкаЗаказовИз1СНаСайт;
ЗагрузкаЗаказовССайтаВ1С.

Все эти методы вызывают API на стороне сайта. Сама логика обмена такая же как в стандартном модуле – инициатива на стороне учетной системы. Технически ничего не мешает поднять веб-сервис в 1С, но практически это нужно относительно редко, и по соображениям безопасности так стараются не делать.

Отдельные хитрые задачи (кстати, хорошо решенные в стандартном модуле) – Настройка дерева групп для сопоставления в двух системах и Синхронизация справочников между системами.

Потребовалось создание регламентных процедур, объектов данных, логов, мониторингов и прочего «обвеса».

Структура систем и потоки данных

У каждого сайта свой каталог товаров, свои способы доставок и оплат, свои интеграционные фиды, свои api для сторонних клиентов.

В итоге мы сделали 2 сайта (b2b и b2c), а каждая новая языковая версия это отдельный «фронт-сайт».

Каждый языковой сайт работает с своим каталогом. Т.е. сколько языковых версий сайта столько и каталогов.

интеграционная схема 1с и двух сайтов

Данные, которыми мы обмениваемся это:

Структура разделов каталогов (под каждый сайт своя).
Типы цен.
Товары.
Пользователи.
Склады.
Заказы.

Наиболее интересным выглядят обмен товарами и ценами. На стороне 1С были реализованы следующие импорты:

Полный импорт с ценам и остатками (импортируются все товары из 1С).
Полный импорт без цен с остатками (собрать цены в 1С достаточно длительный процесс, т.к. только к нам на сайт импортируется 66 типов цен, поэтому импорт цен сделали опциональным).
Импорт товаров по изменениям (без цен/с ценами). Выгружаются только товары у которых изменились данные в 1С.
Импорт только измененных цен.

Как все начиналось

Написать импорт пользователей, заказов, структуры каталогов было довольно просто. Нам присылают json в оговоренном формате, мы добавляем или обновляем данные.

Первые трудности начались с товарами.

В первом варианте импорта товаров из 1С весь процесс создания и обновления данных о товаре происходил прямо на хите обращения 1С к сайту. 1С присылала данные по товару сразу для всех сайтов, поэтому нужно было сохранить и обновить эти данные для всех языковых каталогов.

интеграция 1с через rest-обмен

По мере увеличения количества сайтов, время затрачиваемое на сохранение товаров/остатков/цен стало расти и это нас не устраивало.

Кроме того, была хитрая логика по группировке товаров в карточке, а следовательно нужно было на том же хите вычислить какие sku необходимо сгруппировать в 1 товар. Помимо этого для наполнения товаров нужно было подтянуть из контентной базы данных картинки, характеристики, описания. Обновление описаний и характеристик происходило на кроне и выглядело мягко говоря не очень оптимизировано и красиво. Первый вариант реализации обновления брал пачку товаров и обновлял, вне зависимости от того изменились данные в контентной БД или нет.

Немного усовершенствуем наш обмен

Если вы столкнулись с проблемой обработки больших объемов данных и этот процесс можно распараллелить, то вам могут в этом помочь брокеры сообщений. Если вы еще с ними не знакомы, то их можно грубо описать так: это программа, которая умеет принимать какие либо сообщения, сохранять в указанную очередь эти самые сообщения и отдавать или рассылать эти сообщения.

Какой из брокеров использовать зависит от типа и целей задачи. В нашем случае выбрали ActiveMQ, хотя у нас был опыт работы и с RabbitMQ, и c Gearman. Выбор был довольно произвольный, честно скажу.

Теперь, когда 1С присылает нам данные по товарам, мы записываем json с данными о товарах, который пришел, в ActiveMQ и говорим 1С, что “все ок, мы позже это обработаем”. Каждая запись в ActiveMQ это пачка товаров только для 1 каталога.

Также, мы на этапе передачи данных серверу очередей можем проверить, входит ли конкретный товар в языковой каталог, если нет, то он исключается из пачки.

обмен через ActiveMQ

Итоговая схема обновления данных получилась такая:

схема обновления данных с 1С

Воркер товаров. Создает/обновляет базовую информацию о товаре, а также сохраняет остатки.
Воркер цен сохраняет только цены.
В результате после обработки rest данных мы получаем некрасивый товар (есть остатки, цены, название но нет описания, картинок, названия на нужном языке)
Каждый rest воркер сообщает продюсеру sku, о том, что из 1С пришли какие то изменения на товар х. Продюсер добавляет это sku в очередь на обновление данных о sku.
Воркер обновления данных sku. Задача этого воркера наполнить sku, свойствами (для умного фильтра), найти на нужном языке название sku. Данные о свойствах и названиях хранятся в контентной БД.

После обновления мы получаем sku с картинами и свойствами, для которого осталось создать товар. Каждое sku передается двум продюсерам, продюсер обычных товаров и продюсер цветных/языковых товаров.

Создание товаров

В бизнес-логике клиента есть 2 типа товаров:

Простой товар, 1 sku к 1 товару.
Цветной/языковой или цветной и языковой одновременно, несколько sku к 1 товару.

Воркеры, которые создают товары, называются mapper’ы (потому что склеивают sku в товар).

Простой воркер: Получает на вход пачку (обычно 100) sku. И под каждое sku создает товар и привязывает sku к товару. Так же находит общую картинку (обычно это та же самая, что и у sku), детальное описание, символьный код для url, файлы привязанные к товару, обзоры и прочее.

Цветной/языковой воркер: продюсер для цветных/языковых товаров находит сгруппированные по языкам или по цветам sku и отправляет воркеру пачку sku, которые должны быть привязаны к 1 товару. Там проходят те же манипуляции, что и с обычным товаром.

Числа и трудозатраты

Размеры каталогов теоретически небольшие ~3000 sku.

Но каждый язык хранится как отдельный товар.

На текущий момент запущено 7 языковых версий. Соответственно нам нужно обновить ~21000 товаров. Благодаря возможности регулировать количество воркеров полный импорт для всех каталогов занимает не более 30 минут.

На реализацию первого варианта обмена у нас ушло ~200 ч на стороне сайта и ~100ч на стороне 1С.

Рефакторинг и перевод импорта на сервер очередей занял порядка 150 ч.

Вывод

Если вы можете обойтись без разработки обмена с нуля – обойдитесь. Не стоит увлекаться велосипедами.

Но если проект требует – смело делайте. Не бойтесь уйти от XML-формата и разработать в сумме под 50 методов обмена. Светлая голова и прямые руки позволят вам получить хорошо работающий результат.

Общая трудоемкость в 500 часов не столь страшна, а перевод на очереди и подготовка к высоким нагрузкам будут проще чем в случае стандартного обмена.

Основные принципы взаимодействия с REST API (пример работы)

Сегодня поговорим о связи баз данных 1С с RESTAPI.
Что же это такое, и какие основные принципы взаимодействия нужно знать? RESTAPI — это не более чем обычный веб интерфейс со своим набором команд. То есть мы можем взаимодействовать с ним посредством 1С http-запросов. Давайте посмотрим, как это происходит.
Главной особенностью архитектуры RESTAPI является то, что при каждом обращении сервер, принимающий запрос, думает, что принял это соединение впервые! То есть при каждом запросе передается уникальный ключ авторизации, который идентифицирует сессию.
Есть несколько основных типов запросов архитектуры REST:
— GETзапрос (получает данные);
— PUTзапрос (передает данные);
— POSTзапрос (меняет данные);
Все эти типы используются в RESTAPI.
Сервер, получая запросы RESTAPI, определяет их тип и понимает, что будет происходить с переданными ему данными. Для того чтобы взаимодействовать с определенным API необходимо зайти на его страницу и изучить документацию. В ней обычно указывается, какие методы доступны для взаимодействия, какие данные и как принимает сервер, пример ответа на функции.

2. Подключение к серверу 1С

На реальном примере это выглядит так: для начала мы создаем подключение к серверу 1С, используя параметры, хранимые, скажем, в константе (адрес сервера, ключ подключения).

Используя функцию добавления параметров к запросу, добавляем необходимые значения. Лично я всегда использую эту функцию для удобства формирования строки запроса. С ее помощью можно легко добавить большое количество разных параметров. Но строку с параметрами можно и вручную написать.

3. Формат данных json

Строка с параметрами в итоге выглядит вот так: &FactoryId=123&hashkey=0000
В строке запроса мы можем передать, например, hashkey и factoryId.
Передавая параметры на определенный сервер, мы в ответ получаем нужные данные (для get запроса) или подтверждение, что наши данные получены (когда мы, например, передаем информацию для записи на сервере). Обычно для передачи запроса/ответа в теле запроса используется формат данных json. В нашем случае так и есть.
Json – это формат текста. Мне очень напоминает xml формат онлайн. Он часто используется при взаимодействии с вебом и происходит от JavaScript, но при этом считается независимым от языка.
Пример формата данных json:

Итак, получаем ответ от сервера:

Обрабатываем json, который содержится в теле ответа. Структура предполагаемых данных хранится, конечно же, в документации к api. Поэтому при чтении json мы точно знаем, к какому полю обратится.
Ответ сервера как массив данных (прочитанный json) мы передаем в функцию, которая записывает результат в базу данных 1С:Предприятие. В нашем примере структура данных 1С (метаданные) почти полностью совпадает по именам с названием формата данных json. По имени метода определяем справочник, в который будет происходить загрузка. И по id, переданному из сервиса, по реквизиту пытаемся найти элемент справочника.

В итоге мы имеем связь, которую обеспечивает шина данных api сервера. На сервер мы передаем параметры подключения, которые идентифицируют сессию и параметры запроса, а в ответ получаем необходимые данные, которые обрабатываем в процессе синхронизации любым удобным для нас способом.

Полученные данные мы записываем в нужный объект данных. В нашем случае - «Справочник» или «Регистр сведений».
Таким образом, restapi – пример описанного набора команд на стороне архитектуры сервера с базой данных. Передавая имя метода и параметры, мы вызываем определенную функцию, которая может обработать переданные в параметрах данные (например, записать их в базу данных сервера) или вернуть нам запрошенные данные из своей базы. Вот так просто.
Специалист компании ООО «Кодерлайн» Вадим Хоменко.

Rest API от чайника для чайников

На написание статьи побудило чтение книги "Технологии интеграции "1С:Предприятия 8.3"" Хрусталевой Е.Ю. В первой главе там постоянно чередуются слова REST, REST-интерфейс, архитектура REST и т.д. Мне стало интересно, я начал копать, что это такое, и тема оказалась достаточно интересной.

Начнём с некоторых определений

Перед тем, как дать определение REST API, нужно ввести несколько общих определений. Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы API (Application programming interface) - программный интерфейс приложения для взаимодействия с другими приложениями. Вот теперь можно давать определение REST API. REST API (Representational State Transfer, передача состояния представления) - архитектурный стиль разработки API веб-приложений или компонентов распределённого приложения, используя протокол HTTP. Другими словами, REST API - это набор правил, позволяющий программисту добиться неких целевых свойств API своего приложения. Что же это за свойства?

Краткая историческая справка

Человеком, который ввёл данную аббревиатуру в оборот, является Рой Филдинг. Произошло это в в 2000 году. Далее выдержка из Википедии:

В своей диссертации «Архитектурные стили и дизайн сетевых программных архитектур» («Architectural Styles and the Design of Network-based Software Architectures») в Калифорнийском университете в Ирвайне[3] он подвёл теоретическую основу под способ взаимодействия клиентов и серверов во Всемирной паутине, абстрагировав его и назвав «передачей представительного состояния» («Representational State Transfer»)

Целевые свойства REST API

Производительность

Масштабируемость, выраженная в:

простота **унифицированного** интерфейса
лёгкость внесения изменений, т.е. способность эволюционировать, приспосабливаясь к новым требованиям
надёжность / отказоустойчивость
переносимость компонентов

Получается, что REST API потребовался, так как возникла потребность создавать производительные, надежные и легко поддающиеся изменению обмены между клиентом и сервером. За счёт чего же это достигается?

Принципы построения REST API

Существует 6 **принципов**, которым должен соответствовать REST-интерфейс:

единый интерфейс - ресурсы должны быть однозначно идентифицированы посредством одного URL-адреса

н-р: неверно чтобы для одно и того же объекта для разных HTTP-запросов были разные интерфейсы

GET . \getusers PUT . \createusers

верно - когда интерфейс один, а что делать определяется видом запроса

GET . \users PUT . \users

Всегда использовать клиент-серверное взаимодействие и разграничивать данные между ними

пользовательский интерфейс и вопросы сбора запросов — на стороне клиента.
доступ к данным, управление рабочей нагрузкой и безопасность — на стороне сервера.

Использовать Stateless protocol (протокол без сохранения состояния) - в период, между запросами никакая информация о *состоянии* клиента на сервере не хранится

Следствие: в запросе сервер должен получать всю необходимую информацию для выполнения этого запроса

Использовать кэширование - все ресурсы должны разрешать кэширование, если явно не указано, что оно невозможно, следовательно, все ответы сервера должны иметь явные или неявные обозначения кэшируемых и не кэшируемых ответов
Учитывать слои взаимодействия - система может быть многоуровневой, и как следствие клиент не может однозначно знать взаимодействует он напрямую с сервером или с промежуточным узлом
Код по требованию (необязательное условие) - REST может позволить расширить функциональность клиента за счёт загрузки кода с сервера (апплеты или скрипты)

REST и RESTful - в чём разница?

Термин RESTful был введён, чтобы различать сервисы, построенные чётко по шести указанным выше требованиям, от тех, которые соблюдают только часть требований.

RESTful - это приложение, в котором соблюдаются все требования к построению архитектуры REST API. По поводу этого см. чуть ниже в раздел "Недостатки и критика REST API"

Стандарты REST API

Надо понимать, что REST - это не протокол, поэтому у него нет чёткого и единственного стандарта разработки. Единственное, что чётко прописано - транспортом REST-запросов является HTTP. Всё остальное (формат данных, интерфейса API и т.д.) - на усмотрение разработчика.

Недостатки и критика REST API

завязка на HTTP, спецификация которого имеет свои ограничение

иногда это приводит к тому, что приходит эмитировать поведение некоторых специфических методов

чрезмерная выборка - н-р: есть сервис, которые возвращает контактные данные пользователя. Нам надо получить только имя, но сервис настроен на возврат имени, телефона и т.д.
недостаточная выборка - например сервис, упомянутый выше, возвращает только телефон по умолчанию, а нам нужны все доступные телефоны

Достаточно ли использовать код HTTP-ответа 200 при создании записи или надо использовать 201?
Достаточно ли использовать код HTTP-ответа 200 при обновлении записи или надо использовать 250?

REST API в 1С

Долго на этом останавливаться не буду, просто обзорно распишу. В 1С можно выделить следующие способы работы с REST:

создавать свой REST API (метаданные "Общие - HTTP-сервис")
обратиться к любому REST API (методы встроенного языка: HTTPСоединение, HTTPзапрос, HTTPОтвет)
взаимодействовать с автоматически генерируемый REST-интерфейсом платформы (см. Автоматический REST-интерфейс через протокол OData)

Выводы

В данной статье я постарался дать определение и описание того, что такое REST API. Недаром говорят, что если хочешь до конца понять термин или технологию - постарайся рассказать о ней другому человеку, что в данной статье и проделано ^_^.

Напоследок отмечу, что главный плюс REST - это простота, именно поэтому он долгое время являлся самым популярным стандартом для организации взаимодействия клиента и сервера. Является ли он таким на данный момент, ответить сложно, ибо есть множество интересных альтернатив: старенький, но надёжный, SOAP, передовой GraphQL, RPC, JSON-pure API и многое другое.

API для обслуживающих организаций

API службы поддержки предоставляет возможность работы через SOAP и REST веб-сервисы. Примеры использования веб-сервисов показаны в конфигурации 1C:Библиотека интеграции со службой поддержки . В ней реализована подсистема для встраивания в конфигурации партнеров. Подсистема включает в себя набор команд, форм и модулей, необходимых для встраивания пользовательского интерфейса службы поддержки в другие конфигурации. Библиотека интеграции предоставляет набор процедур и функций, облегчающих работу с API. Вызовы процедур и функций для работы с API будут рассмотрены в примерах.

Версия API	1.0.6

Содержание

REST-сервис API-XML
SOAP-сервис API-SOAP

Запросы к REST сервису
Запросы к SOAP сервису

Свойства класса
Специальные отборы при получении списка

Телефонный звонок
Комментарий пользователя сервиса
Электронное письмо входящее
Электронное письмо исходящее
Общие свойства взаимодействий

Общие свойства карточек базы знаний
Консультации
Ошибки
Пожелания

Поручение
Задача исполнителя

НСИ
Структура поддержки
Объекты обслуживания
Прочее

REST-сервис API-XML

Сервис используется для интеграции приложения 1С:Управление службой поддержки с другими приложениями. Примеры работы с веб-сервисом приведены в конфигурации 1С:Библиотека интеграции со службой поддержки. Ответы веб-сервиса формируются в формате XML. Также в формате XML нужно формировать запросы при отправке объектов на запись и изменение. Для упрощения работы, веб-сервис предоставляет модель описания фабрики объектов.
Пример использования в 1С:Предприятии:

// получим соединение с веб-сервисом Соединение = Новый HTTPСоединение(Хост, Порт, ИмяПользователя, Пароль); Запрос = Новый HTTPЗапрос("sdapi/hs/api-xml/version"); Ответ = Соединение.Получить(Запрос); Версия = Ответ.ПолучитьТелоКакСтроку(); //возвращает строку с номером версии

SOAP-сервис API-SOAP

Сервис используется для интеграции приложения 1С:Управление службой поддержки с другими приложениями. Синхронная интеграция применяется для реализации пользовательского интерфейса и онлайн взаимодействия интегрированных приложений.

Операция execute

Обрабатывает переданный запрос и возвращает результат обработки.
Возвращаемое значение: Response

Параметр	Тип	Возможно пустое	Направление передачи	Описание
request	Request		Входной	Содержит запрос на выполнение операции, например GetVersionRequest.

Пример вызова этой операции в 1С:Предприятии:

МестоположениеWSDL = АдресПубликацииВебСервиса + "ws/api-soap?wsdl"; Определение = Новый WSОпределения(МестоположениеWSDL, ИмяПользователя, Пароль); Прокси = Новый WSПрокси(Определение, "http://www.1cfresh.com/sd/api", "SDApi", "SDApiSoap"); Прокси.Пользователь = ИмяПользователя; Прокси.Пароль = Пароль; ЗапросТип = Прокси.ФабрикаXDTO.Тип("http://www.1cfresh.com/sd/api", "GetVersionRequest"); Запрос = Прокси.ФабрикаXDTO.Создать(ЗапросТип); Версия = Прокси.execute(Запрос).version;

Тот же пример с использованием средств библиотеки :

Запрос = СлужбаПоддержки.СоздатьОбъект("GetVersionRequest"); Версия = СлужбаПоддержкиПовтИсп.Прокси().execute(Запрос).version;

Запросы к сервисам

Запросы к REST сервису

Получение версии сервиса REST

GET /version

Получение модели описания для фабрики объектов REST

Модель описания может использоваться для создания, чтения и работы с объектами.

Пример запроса

GET /model.xsd

Пример ответа Развернуть

   = <> > >=   LIKE IN IN HIERARCHY  FillFromArticle  StartProcess  Consider  CompleteTask ReturnOnCompletion CancelOrder

Получение данных авторизованного пользователя REST

Возвращает данные авторизованного пользователя.

Запрос

GET /currentuser

Пример ответа Развернуть

  a14919f5-0dad-11e4-93f4-0050568b4127 e1cib/data/Справочник.Пользователи?ref=93f40050568b412711e40dada14919f5 User Иванов   70cd3c69-0e54-11e4-93f4-0050568b4127 Partner Служба поддержки    d1f2a6e2-17b4-11e4-93f4-0050568b4127 SupportLine Первая линия поддержки

Получение списка объектов REST

В качестве запроса передается имя класса.
Доступно для объектов всех классов-потомков от класса Object.
Шаблон запроса:

GET /s

GET /incidents

Для списков доступны возможности:

Определить выводимые колонки. Для этого нужно использовать параметр columns.
Установить отборы. Для этого нужно использовать параметр filter.
Установить лимит на количество получаемых записей. Для этого нужно использовать параметр limit.

Эти параметры можно использовать в одном запросе в любой комбинации. Например:

GET /incidents?columns=. &filter=. &limit=.

В запросе можно использовать большие и маленькие буквы в именах классов и свойств.

Лимит на количество получаемых записей

Указание параметра limit. позволяет установить лимит на количество получаемых записей при получении списка объектов. Например, следующий запрос выдаст сведения о не более чем 3 инцидентах .

Пример запроса

GET /incidents?&limit=3

Пример ответа Развернуть

    false false    false false    false false  true

Вывод реквизитов в списке

С помощью параметра запроса columns можно определить состава выводимых колонок при получении списка объектов. Доступно для объектов всех классов-потомков от класса Object.

Значение параметра это:

имена полей класса, перечисленные через запятую;
или * — выводить в ответе все колонки (все поля класса)

GET /incidents?columns=date,number,subject,initiator

Как уже говорилось, параметр запроса columns можно использовать одновременно с параметрами filter и/или limit.

Пример запроса

GET /incidents?limit=3&columns=date,number,subject,initiator

Пример ответа Развернуть

    false false    false false    false false  true

Отборы в списке

Возможна установка отборов на получаемый список. Для этого нужно использовать параметр filter.
Фильтр представляет собой набор условий, разделенных символом ;
Условия можно применять ко всем доступным полям класса, возможным для вывода в списке. В условиях могут использоваться операторы:

= – равно
> – больше
< – меньше
>= – больше или равно
<> – не равно
LIKE – подобно
IN – в
IN HIERARCHY – в иерархии

Для условий IN и IN HIERARCHY указывается список значений, разделенных символом |

Пример запроса
GET /incidents?filter=modifiedDate>2021-09-01;component=
Пример запроса

GET /applications?filter=code IN 9|1992|1005|10049

Для объектов, поддерживающих дополнительные реквизиты, можно осуществлять отбор, используя в качестве имени реквизита идентификатор дополнительного реквизита, например:

Пример запроса

GET /subscribers?filter=a68efcf3-015d-11e6-9575-005056c00008=12345

Получает список Абонентов с отбором по значению дополнительного реквизита.

Получение списка подчиненных объектов REST

Можно получать подчиненные объекты от основного объекта.
Шаблон получения подчиненных объектов:

Пример получения взаимодействий и файлов по обращению с идентификатором (свойством id свойства objectId) 8756ca78-551c-11e4-93f4-0050568b4127:

Примеры запросов

GET /incident/8756ca78-551c-11e4-93f4-0050568b4127/phonecalls GET /incident/8756ca78-551c-11e4-93f4-0050568b4127/files

Доступно для предметов:

Incident — обращения
Consultation — консультации
Problem — ошибка
Suggestion — пожелание

Доступно для подчиненных объектов

File — присоединенные файлы
Interaction — все типы взаимодействий по предмету
PhoneCall — телефонный звонок
ServiceUserComment — комментарий пользователя сервиса
IncomingEMail — входящее электронное письмо
OutgoingEMail — исходящее электронное письмо

Получение объекта REST

Шаблон получения объектов:

Например, запрос для получения обращения с идентификатором (свойством id свойства objectId) 8756ca78-551c-11e4-93f4-0050568b4127:

Пример запроса

GET /incident/8756ca78-551c-11e4-93f4-0050568b4127

Доступно для всех объектов классов-потомков от класса Object.

Получение экземпляра нового объекта REST

GET //new

Запрос доступен для:

Incident — обращения
Consultation — консультации
Suggestion — пожелание

Получение экземпляра нового подчиненного объекта REST

GET ////new

Пример запроса

GET /incident/8756ca78-551c-11e4-93f4-0050568b4127/phonecall/new

Доступно для предметов:

Incident — обращения
Consultation — консультации
Problem — ошибки
Suggestion — пожелание

Доступно для подчиненных объектов:

ActualWork — запись о трудозатратах
PhoneCall — телефонный звонок
OutgoingEMail — исходящее электронное письмо
Order — поручение

Добавление объекта REST

Объект передается в теле запроса в формате XML. Объект должен соответствовать описанию класса в модели.
Шаблон запроса:

POST /

Запрос доступен для:

Incident — обращения
Consultation — консультации
Suggestion — пожелание
OutgoingEMail — исходящее электронное письмо
PhoneCall — телефонный звонок
Order — поручение

Для старта процесса "Поручение" нужно указать дополнительные действия при добавлении объекта:

POST /Order?action=StartProcess

Если дополнительное действие не будет указано, то процесс будет добавлен, но не будет стартован.

Добавление подчиненного объекта REST

Данные подчиненного объекта передаются в теле запроса в формате XML.
Шаблон запроса:

POST ///

Пример добавления файлов к обращению:

Пример запроса

POST /incident/8756ca78-551c-11e4-93f4-0050568b4127/file

Доступно для предметов:

Incident — обращения
Consultation — консультации
Problem — ошибка
Suggestion — пожелание

Доступно для объектов:

IncidentComment — комментарий обращения
ArticleComment — комментарий карточки базы знаний
ActualWork — запись фактических трудозатрат
File — присоединенный файл

Обновление объекта REST

Объект передается в теле запроса.
Пример запроса:

PUT /incident

Запрос доступен для:

Incident — обращения
Consultation — консультации
Suggestion — пожелание
PhoneCall — телефонный звонок
OutgoingEMail — исходящее электронное письмо
Order — поручение
Task — задача исполнителя

Для взаимодействий этот запрос доступен с действием Consider .
При выполнении такого запроса у взаимодействий устанавливается признак Рассмотрено.
При использовании параметра action тело запроса может не устанавливаться.

Пример запроса

PUT /IncomingEmail/36c95f80-eca9-11e3-899c-bcaec5d6c3e4?action=consider

IncomingEMail — входящее электронное письмо
ServiceUserComment — комментарий пользователя
OutgoingEMail — исходящее электронное письмо
PhoneCall — телефонный звонок

Перенаправление объекта REST

Параметры перенаправления передаются в теле запроса.
Шаблон запроса:

PUT //?action=redirect

Запрос доступен для объектов:

Incident — обращения
Task — задача исполнителя

Принятие задачи к исполнению REST

Принятие задачи выполняется так же как и перенаправление.
В качестве исполнителя в теле запроса устанавливается текущий пользователь.

Пример запроса

PUT /Task/e23e968a-26c5-11e4-93f4-0050568b4127?action=redirect

Выполнение задачи REST

Для выполнения задач используется отдельный запрос.
Шаблон запроса:

PUT /Task/?action=

Комментарий выполнения задачи передается в теле запроса.
При выполнении задачи возможно указание дополнительных действий:

CompleteTask - выполнить задачу по умолчанию
ReturnOnСompletion — вернуть на доработку
CancelOrder - отменить поручение

Удаление объекта REST

Запрашивается тип объекта и уникальный идентификатор объекта.
Пример запроса:

DELETE //

Доступно для объектов:

Запросы к SOAP сервису

Получение версии сервиса SOAP

Версия сервиса помогает определить внешней системе доступную функциональность сервиса.
Для получения версии сервиса нужно отправить запрос класса GetVersionRequest . Возвращается ответ класса GetVersionResponse , содержащий номер версии сервиса. Пример использования:

Запрос = СлужбаПоддержки.СоздатьОбъект("GetVersionRequest"); Версия = СлужбаПоддержкиПовтИсп.Прокси().execute(Запрос).version;

Класс GetVersionRequest

Базовый класс: Request
Запрос для получения текущей версии веб-сервиса.

Класс GetVersionResponse

Базовый класс: Response
Ответ на запрос GetVersionResponse. Возвращает текущую версию веб-сервиса.

Свойство	Тип	Обязательное	Описание
version	string	Да	Номер версии web-сервиса. Строка вида 1.0.1.1

Получение данных авторизованного пользователя SOAP

Для получения данных авторизованного пользователя нужно отправить запрос класса GetCurrentUserRequest . Возвращается ответ класса GetCurrentUserResponse , содержащий данные текущего пользователя.
Пример использования:

Пользователь = СлужбаПоддержкиПовтИсп.ТекущийПользователь();

Результат запроса кэшируется на время сеанса.

Класс GetCurrentUserRequest

Базовый класс: Request
Запрашивает данные авторизованного пользователя.

Класс GetCurrentUserResponse

Базовый класс: Response
Возвращается в результате выполнения запроса GetCurrentUserRequest. Содержит в теле значение авторизованного пользователя.

Свойство	Тип	Обязательное	Описание
object	Object	Да	Авторизованный пользователь

Получение списка объектов SOAP

Получение списка объектов выполняется с помощью запроса класса GetListRequest . В качестве параметров запросу передаются строка с типом объекта и условия, включающие, набор колонок и отборы. При удачном выполнении запроса возвращается объект класса GetListResponse , содержащий список объектов запрошенного типа с указанными колонками. В случае ошибки возвращается Error .
С помощью этого запроса можно получить списки всех типов объектов из производных классов класса Object .
Пример использования:

Колонки = СтрРазделить("importance, subject, type, status, initiator, responsible, number, date", ", ", Ложь); СписокXDTO = СлужбаПоддержки.ПолучитьСписокОбъектов("Incident", Колонки); Для Каждого ОбъектXDTO Из СписокXDTO Цикл // ОбъектXDTO имеет тип ObjectListItem СтрокаСписка = Список.Добавить(); // Список - произвольный список для заполнения данными из Api // заполним строку из объекта в отдельной процедуре ЗаполнитьСтрокуСписка(СтрокаСписка, ОбъектXDTO.object) КонецЦикла;

Класс GetListRequest

Базовый класс: Request
Запрашивает список объектов (элементов справочника, документов, бизнес-процессов, задач или значений перечисления), удовлетворяющих указанному условию.

Свойство	Тип	Обязательное	Описание
query	ListQuery		Параметры запроса.
type	string	Да	Указывает тип объектов, список которых нужно получить. Например, Incident.

Класс GetListResponse

Базовый класс: Response
Возвращается в результате успешной обработки запроса GetListRequest.

Свойство	Тип	Обязательное	Список	Описание
items	ListItem		Да	Список объектов.
tooManyObjects	boolean			Признак того, что в выборке больше объектов, чем запрашивалось.

Свойства запроса

Класс ListQuery

Свойство	Тип	Список	Описание
columns	string	Да	Имена свойств, которые нужно заполнить у запрошенных объектов.
filter	ListFilter	Да	Набор условий отбора.
limit	integer		Предельное количество выбираемых объектов.

Класс ListFilter

Условие отбора для запроса GetListRequest.

Свойство	Тип	Описание
comparisonOperator	ComparisonOperator	Оператор сравнения. Если не заполнено, то используется значение " confluenceTd">property	string	Да	Имя поля для отбора.
value	Любой тип	Значение поля отбора. Заполняется для всех условий кроме "IN" и "IN HIERARCHY"
valueList	Любой тип	Список значений поля отбора. Заполняется только для условий "IN" и "IN HIERARCHY"

Класс ComparisonOperator

Оператор сравнения для указания сложных условий в условии ListFilter запроса GetListRequest.
Значения перечисления:

= – равно
> – больше
< – меньше
>= – больше или равно
<> – не равно
LIKE – подобно
IN – в
IN HIERARCHY – в иерархии

Свойства ответа

Каждый объект оборачивается в объект типа ListItem, содержащий сам объект, а также дополнительные свойства, для удобства отображения в списках и получения дочерних элементов.

Класс ListItem

Описывает элемент списка объектов.

Свойство	Тип	Обязательное	Описание
canHaveChildren	boolean	Да	Признак того, что данный объект может содержать дочерние (т.е. является веткой дерева).
isFolder	boolean	Да	Признак того, что данный объект является группой.
object	Object	Да	Объект УСП.
parentId	ObjectId		Указывает на объект, который является родительским для данного объекта в контексте списка объектов.

Получение списка подчиненных объектов SOAP

Получение списка подчиненных объектов, например взаимодействий, выполняется с помощью запроса класса GetSubListRequest . В качестве параметров запросу передаются ссылка на предмет взаимодействия и условия, включающие, набор колонок и отборы. При удачном выполнении запроса возвращается объект класса GetSubListResponse , содержащий список объектов запрошенного типа с указанными колонками. В случае ошибки возвращается Error .
Пример использования при получении взаимодействий:

Взаимодействия = СлужбаПоддержки.ПолучитьСписокПодчиненныхОбъектов(ВладелецТип, ВладелецID, "Interaction")

При получении взаимодействий можно использовать имена типов взаимодействий, либо имя Interaction, для получения списка взаимодействий всех типов.
Пример получения списка файлов:

Колонки = СтрРазделить("size, creationDate, modificationDateUniversal, extension, description",", ", Ложь); Файлы = СлужбаПоддержки.ПолучитьСписокПодчиненныхОбъектов("Incident", Id, "File", Колонки);

Класс GetSubListRequest

Базовый класс: Request
Запрашивает список объектов по предмету.
Доступно для предметов

Incident — обращения
Consultation — консультации
Problem — ошибка
Suggestion — пожелание

Доступно для подчиненных объектов

File — присоединенные файлы
Interaction — все типы взаимодействий по предмету
PhoneCall — телефонный звонок
ServiceUserComment — комментарий пользователя сервиса
IncomingEMail — входящее электронное письмо
OutgoingEMail — исходящее электронное письмо

Incident — обращение
Consultation — консультация
Problem — ошибка
Suggestion — пожелание

Класс GetSubListResponse

Базовый класс: Response
Возвращается в результате успешной обработки запроса GetSubListRequest.

Свойство	Тип	Обязательное	Список	Описание
records	Record		Да	Полученные записи.

Получение списка сведений по пользователям SOAP

Получение списка сведений по пользователям выполняется с помощью запроса GetServiceUserInfoListRequest . При удачном выполнении запроса возвращается объект класса GetServiceUserInfoListResponse , содержащий список сведений по пользователям сервиса. В случае ошибки возвращается Error .

Класс GetServiceUserInfoListRequest

Базовый класс: Request
Запрос для получения списка пользователей сервисов с дополнительной информацией. В параметрах можно указать частичные значения для поиска. Количество букв в строковых парамтрах не должно быть меньше 3.

Свойство	Тип	Обязательное	Список	Описание
applicationCode	int			Номер приложения
dynamicAttributes	DynamicAttribute		Да	Параметры отборов по дополнительным реквизитам
serviceId	ObjectId	Да		Ссылка на сервис
serviceUserEMail	string			Адрес электронной почты пользователя сервиса
serviceUserLogin	string			Логин пользователя сервиса
subscriberCode	int			Код абонента

Класс GetServiceUserInfoListResponse

Базовый класс: Response
Ответ на запрос получения списка пользователей с расширенной информацией. Содержит запрашиваемый список.

Свойство	Тип	Обязательное	Список	Описание
items	ServiceUserInfoItem		Да	Элементы списка с расширенной информацией по пользователям сервиса

Получение объекта SOAP

Для получения объектов используется запрос класса GetRequest . В качестве параметров в запросе передаются список ссылок на требуемые объекты и набор колонок, которые требуется получить. В случае удачного выполнения запроса возвращается ответ класса GetResponse , содержащий требуемые объекты. В случае ошибки возвращается Error .
Пример использования:

ОбъектXDTO = СлужбаПоддержки.ПолучитьОбъект("Incident", Id);

Класс GetRequest

Базовый класс: Request
Получает массив указанных объектов.

Свойство	Тип	Обязательное	Список	Описание
columns	string		Да	Массив имен свойств, которые должны быть заполнены. Если массив не указан или пустой, то заполняются все свойства.
objectIds	ObjectId		Да	Ссылки на объекты.

Класс GetResponse

Базовый класс: Response
Возвращается в результате успешной обработки запроса GetRequest.

Свойство	Тип	Обязательное	Список	Описание
records	Record	Да	Да	Массив записей.

Получение экземпляра нового объекта SOAP

Можно получить экземпляр нового объекта с предварительно заполненными по умолчанию полями. Это удобно при создании новых объектов. Для получения экземпляра объекта отправляется запрос класса GetNewRequest . В качестве параметра в запросе передается строка с именем типа требуемого объекта. При успешном выполнении запроса возвращается ответ класса GetNewResponse , который содержит новый объект, заполненные по умолчанию. При возникновении ошибки возвращается Error .
Пример использования:

ОбъектXDTO = СлужбаПоддержки.ПолучитьНовыйОбъект("Incident")

Класс GetNewRequest

Базовый класс: Request
Запрашивает новый объект указанного типа, заполненный значениями по умолчанию.
Доступно для объектов:

Incident — обращение
Consultation — консультация
Suggestion — пожелание

Свойство	Тип	Обязательное	Список	Описание
columns	string		Да	Список свойств объекта, которые должны быть заполнены. Если список пуст или не указан, то будут заполнены все свойства, для которых предусмотрены или могут быть вычислены значения по умолчанию.
type	string	Да		Имя типа XDTO объекта, который требуется получить.

Класс GetNewResponse

Базовый класс: Response
Возвращается в результате успешной обработки запроса GetNewRequest и производных от него запросов.

Свойство	Тип	Обязательное	Описание
record	Record	Да	Новая запись, заполненная по умолчанию.

Получение экземпляра нового подчиненного объекта SOAP

Для получения экземпляра нового взаимодействия отправляется запрос класса GetNewSubRequest . В качестве параметра в запросе передается ссылка на предмет и строка с именем типа требуемого объекта. При успешном выполнении запроса возвращается ответ класса GetNewSubResponse , который содержит новый объект, заполненные по умолчанию. При возникновении ошибки возвращается Error .
Пример использования:

// Получает новый телефонный эвонок по обращению СлужбаПоддержки.ПолучитьНовыйПодчиненныйОбъект("Incident", Id, "PhoneCall");

Класс GetNewSubRequest

Базовый класс: GetNewRequest
Запрашивает новый объект взаимодействия указанного типа, заполненный значениями по умолчанию.
Доступно для объектов:

PhoneCall — телефонный звонок
OutgoingEMail — исходящее электронное письмо
ActualWork — запись фактических трудозатрат
Order — поручение

Класс GetNewSubResponse

Базовый класс: GetNewResponse
Возвращается в результате успешной обработки запроса GetNewSubRequest.

Свойства запроса

Класс GetNewSubActions

Описывает возможные действия при получении нового подчиненного объекта.
Значения перечисления:

FillFromArticle – заполнить по карточке базы знаний

Добавление объекта SOAP

Для создания объекта используется запрос класса PostRequest . В качестве параметра передается список объектов с пустыми ссылками. При удачном выполнении запроса возвращается ответ класса PostResponse , содержащий созданные объекты. В случае неудачи возвращается Error .
Пример использования:

ОбъектXDTO = СлужбаПоддержки.ПолучитьНовыйОбъект("Consultation"); ЗаполнитьОбъект(ОбъектXDTO); // здесь выполняется заполнение объекта СлужбаПоддержки.ДобавитьОбъект(ОбъектXDTO);

Для добавления нескольких объектов одним запросом следует использовать функцию:

СлужбаПоддержки.ДобавитьОбъекты(МассивОбъектовXDTO);

При записи процесса можно указать, что он должен быть стартован:

СлужбаПоддержки.ДобавитьОбъект(ОбъектXDTO, "StartProcess");

Класс PostRequest

Базовый класс: Request
Добавляет новые объекты в приложение.
Запрос доступен для:

Incident — обращения
Consultation — консультации
Suggestion — пожелание
PhoneCall — телефонный звонок
OutgoingEMail — исходящее электронное письмо
Order — поручение

Свойство	Тип	Обязательное	Список	Описание
action	PostActions			Дополнительное действие при записи объекта
objects	Object		Да	Содержит объекты, который требуется создать.

Класс PostResponse

Базовый класс: Response
Возвращается в случае успешного добавления объекта вызовом PostRequest.

Свойство	Тип	Обязательное	Список	Описание
objects	Object		Да	Созданные объекы.

Свойства запроса

Класс PostActions

Описывает дополнительные действия при добавлении объектов.

StartProcess – стартовать процесс

Добавление подчиненного объекта SOAP

Добавление подчиненных объектов осуществляется с помощью запроса класса PostSubRequest .Запросом передается ссылка на предмет и информация о записываемом объекте. При удачном выполнении запроса возвращается ответ класса PostSubResponse . В случае ошибки возвращается ответ класса Error .
Пример использования при записи файла:

// ПараметрыСоздания — содержит структуру создаваемого файла. ФайлXDTO = СлужбаПоддержки.СоздатьОбъект("File"); ФайлXDTO.objectId = СлужбаПоддержки.СоздатьObjectID("File", ""); ФайлXDTO.binaryData = ПолучитьИзВременногоХранилища(ПараметрыСоздания.АдресВременногоХранилищаФайла); ФайлXDTO.extension = ПараметрыСоздания.Расширение; ФайлXDTO.modificationDateUniversal = ПараметрыСоздания.ВремяИзмененияУниверсальное; ФайлXDTO.name = ПараметрыСоздания.Имя; ФайлXDTO.size = ПараметрыСоздания.Размер; ФайлXDTO.text = ПараметрыСоздания.Текст; СлужбаПоддержки.ДобавитьПодчиненныйОбъект("Incident", ВладелецID, ФайлXDTO);

Класс PostSubRequest

Базовый класс: Request
Добавляет новый объект или запись к указанному объекту.
Доступно для предметов:

Incident — обращения
Consultation — консультации
Problem — ошибка
Suggestion — пожелание

Доступно для объектов:

IncidentComment — комментарий обращения
ArticleComment — комментарий карточки базы знаний
ActualWork — запись фактических трудозатрат
File — присоединенный файл

binaryData
text
name
extension
modificationDateUniversal
size

Класс PostSubResponse

Базовый класс: Response
Возвращается в случае успешной обработки запроса PostSubRequest.

Свойство	Тип	Обязательное	Описание
record	Record	Да	Описание записи, которая были добавлена в УСП.

Обновление объекта SOAP

Для обновления объекта используется запрос класса PutRequest . В качестве параметров запроса передаются объекты, которые требуется обновить. В случае удачного выполнения запроса возвращается ответ класса PutResponse , содержащий все измененные объекты. В случае ошибки возвращается Error .
Пример использования:

СлужбаПоддержки.ОбновитьОбъект(ОбъектXDTO);

Для обновления нескольких объектов одним запросом следует использовать функцию:

СлужбаПоддержки.ОбновитьОбъекты(МассивОбъектовXDTO);

Для установки признака Рассмотрено следует использовать функцию библиотеки :

СлужбаПоддержки.УстановитьПризнакРассмотрено(ОбъектТип, ОбъектИд);

Класс PutRequest

Базовый класс: Request
Запрос на изменение объектов (например, справочники, документы, бизнес-процессы, задачи).
Доступно для объектов:

Incident — обращение
Consultation — консультация
Suggestion — пожелание
Order — поручение
Task — задача исполнителя

Объекты, для которых можно установить признак Рассмотрено (action=Consider):

IncomingEMail — входящее письмо
OutgoingEMail — исходящее письмо
PhoneCall — телефонный звонок
ServiceUserComment — комментарий пользователя

Свойство	Тип	Обязательное	Список	Описание
action	PutActions			Дополнительное действие при изменении объекта
objects	Object	Да	Да	Список объектов, которые нужно обновить.

Класс PutResponse

Базовый класс: Response
Возвращается в результате успешной обработки запроса PutRequest.

Свойство	Тип	Обязательное	Список	Описание
objects	Object	Да	Да	Список обновленных объектов.

Класс PutActions

Описывает действия при изменении объектов.

Consider – При указании дествия для объектов типа IncomingEmail, OutgoingEmail, PhoneCall, ServiceUserComment у перечисленных объектов будет устанавливаться признак Рассмотрено.

Перенаправление объекта SOAP

В процессе работы может потребоваться назначить ответственным за обращение другого исполнителя. Перенаправление обращения можно выполнить с помощью этого запроса.
Пример перенаправления на текущего пользователя:

ТекущийПользователь = СлужбаПоддержкиПовтИсп.ТекущийПользователь().objectId; СлужбаПоддержки.ПеренаправитьОбъект("Incident", Id, ТекущийПользователь.type, ТекущийПользователь.id);

Пример перенаправления на линию поддержки:

ЛинияПоддержки = СлужбаПоддержкиПовтИсп.ТекущийПользователь().supportLine.objectId; СлужбаПоддержки.ПеренаправитьОбъект("Incident", Id, ЛинияПоддержки.type, ЛинияПоддержки.id);

Класс PutRedirectRequest

Базовый класс: Request
Выполняет перенаправление объекта. В случае удачного выполнения возвращается OK, в случае ошибки Error.
Доступно для объектов:

Incident — обращение
Task — задача исполнителя

Свойство	Тип	Обязательное	Описание
query	RedirectQuery	Да	Параметры перенаправления.
targetId	ObjectId	Да	Ссылка на перенаправляемый объект.

Свойства запроса

Класс RedirectQuery

Описывает параметры перенаправления.

SupportLine — линия поддержки
User — пользователь

Принятие задачи к исполнению SOAP

Класс PutAcceptRequest

Базовый класс: Request
Выполняет принятие задачи к исполнению. В случае удачного выполнения возвращается OK, в случае ошибки Error.

Свойство	Тип	Обязательное	Описание
targetId	ObjectId	Да	Ссылка на задачу

Выполнение задачи SOAP

Пример выполнения задачи:

СлужбаПоддержки.ВыполнитьЗадачу("Task", Ид, КомментарийВыполнения);

Пример выполнения задачи с возвратом на исполнение:

СлужбаПоддержки.ВыполнитьЗадачу("Task", Ид, КомментарийВыполнения, "ReturnOnСompletion");

Класс PutCompleteTaskRequest

Базовый класс: Request
Запрос на выполнение задачи исполнителя.

Свойство	Тип	Обязательное	Описание
action	PutСompleteTaskActions		Дополнительное действие при выполнении задачи
comment	string		Комментарий выполнения
targetId	ObjectId	Да	Ссылка на задачу

Свойства запроса

Класс PutСompleteTaskActions

Описывает дополнительные действия при выполнении задачи
Значения перечисления:

CompleteTask – выполнить здачу
ReturnOnCompletion – вернуть на исполнение
CancelOrder – отменить задачу

Удаление объекта SOAP

Пометка на удаление выполняется с помощью запроса класса DeleteRequest . В качестве параметров запроса передаются ссылки на объекты. Можно пометить на удаление несколько объектов. Пометка удаления выполняется в транзакции. В случае успешного выполнения запроса возвращается ответ класса DeleteResponse . В случае неудачи возвращается Error .
Пример использования:

СлужбаПоддержки.УдалитьОбъект("File", Id);

Для удаления нескольких объектов следует использовать функцию:

СлужбаПоддержки.УдалитьОбъектыПоСсылкам(МассивСсылокXDTO);

Класс DeleteRequest

Базовый класс: Request
Помечает объекты на удаление.
Доступно только для объектов типа:

Свойство	Тип	Обязательное	Список	Описание
objectIds	ObjectId	Да	Да	Список ссылок на объекты, которые нужно пометить на удаление.

Класс DeleteResponse

Базовый класс: Response
Возвращается в случае успешной обработки запроса DeleteRequest.

Обращения

Пример использования в библиотеке :
Обработки.СлужбаПоддержки.Формы.Обращение

Класс Incident

Базовый класс: Object
Описывает обращение в УСП.

Свойство	Тип	Список	Описание
closingDate	dateTime		Дата закрытия
comments	IncidentComment	Да	Комментарии исполнителей
component	Component		Компонент
date	dateTime		Дата
deadline	dateTime		Срок обработки
description	string		Описание
descriptionHTML	HTMLObject		Описание в формате HTML с картинками
dynamicAttributes	DynamicAttribute	Да	Дополнительные реквизиты
eMailForCorrespondence	string		Адрес для переписки
generalComment	string		Общий комментарий
hasNewInteractions	boolean		Наличие новых взаимодействий
importance	Importance		Важность
initiator	ServiceUser		Инициатор
knowledgeBaseArticle	KnowledgeBaseArticle		Карточка базы знаний
modifiedDate	dateTime		Дата изменения
number	string		Номер
objectVersion	string		Версия объекта — обязательна при записи существующего объекта
partner	Partner		Обслуживающая организация
recievingChannel	RecievingChannel		Канал получения
responsible	Object		Ответственный
section	Section		Раздел
service	Service		Сервис
status	IncidentStatus		Состояние
subscription	Subscription		Подписка на тариф
subject	string		Тема
subscriber	Subscriber		Абонент
subscriberPartner	Subscriber		Обслуживающая организация абонента
supportLine	SupportLine		Линия поддержки
type	IncidentType		Тип обращения

Свойства класса

Класс IncidentType

Базовый класс: Object
Описывает тип обращения в УСП.
Значения перечисления:

Консультация
Ошибка
Пожелание

Класс IncidentStatus

Базовый класс: Object
Описывает состояния обращения.
Значения перечисления:

Новое
Расследование
Исправление
ОжиданиеИнициатора
Закрыто
Отложено

Класс Importance

Базовый класс: Object
Описывает варианты важности.
Значения перечисления:

ВысокаяВажность — высокая важность
ОбычнаяВажность — обычная важность
НизкаяВажность — низкая важность
КритичнаяВажность — критичная важность

Класс RecievingChannel

Базовый класс: Object
Описывает каналы получения обращений.

Свойство	Тип	Описание
code	string	Код

Возможные значения свойства code перечислены в справочнике программы КаналыПолученияОбращений. Предопределенные значения:

ИнформационныйЦентр
СервисРегистрацииОшибок
ТелефонГорячейЛинии
ЭлектроннаяПочта

Класс IncidentComment

Базовый класс: Record
Описывает список комментариев исполнителей к обращению.

Свойство	Тип	Описание
author	User	Автор комментария
comment	string	Текст комментария
date	dateTime	Дата и время комментария
supportLine	SupportLine	Линия поддержки автора

Специальные отборы при получении списка

Для быстрого отбора обращений можно использовать фильтры:

onMy — отбор по текущему пользователю
onMyLine — отбор по линии поддержки текущего пользователя
onMyCollegues — отбор по сотрудникам линии текущего пользователя

Взаимодействия

Пример получения списка взаимодействий по объекту в библиотеке :
Обработки.СлужбаПоддержки.Формы.Взаимодействия.
Для работы с взаимодействиями можно использовать общие запросы:

Получение объекта
Обновление объекта
Удаление объекта

Так как взаимодействия принадлежат какому либо предмету, для получения списка взаимодействий и для получения экземпляра нового взаимодействия используются запросы:

Получение списка подчиненных объектов
Получение эклемпляра нового подчиненного объекта
Добавление подчиненного объекта

Телефонный звонок

Пример использования в библиотеке :
Обработки.СлужбаПоддержки.Формы.ТелефонныйЗвонок

Класс PhoneCall

Базовый класс: Object
Описывает телефонный звонок

Комментарий пользователя сервиса

Пример использования в библиотеке :
Обработки.СлужбаПоддержки.Формы.КомментарийПользователя

Класс ServiceUserComment

Базовый класс: Object
Описывает комментарий пользователя к обращению. Создается в случае создания сообщения пользователем из приложения.

Электронное письмо входящее

Класс IncomingEMail

Базовый класс: Object
Описывает входящее электронное письмо.

Электронное письмо исходящее

Класс OutgoingEMail

Базовый класс: Object
Описывает исходящее электронное письмо.

Свойства класса

Класс OutgoingEMailStatus

Базовый класс: Object
Описывает состояния исходящего письма.
Значения перечисления:

Черновик — письмо записано но не отправлено
Отправлено — письмо отправлено
Исходящее — письмо находится в состоянии отправки

Класс EMailAccount

Базовый класс: Object
Описывает учетную запись электронной почты.

Свойство	Тип	Описание
useForReceiving	boolean	Использовать для получения
useForSending	boolean	Использовать для отправки

Общие свойства взаимодействий

Класс InteractionImportance

Базовый класс: Object
Описывает варианты важности взаимодействий.
Значения перечисления:

Высокая — высокая важность
Обычная — обычная важность
Низкая — низкая важность

Класс EMailBodyType

Базовый класс: Object
Описывает перечисление Типы текстов электронных писем.
Значения перечисления:

HTML
HTMLСКартинками
ПростойТекст
РазмеченныйТекст

Карточки базы знаний

Класс KnowledgeBaseArticle

Абстрактный класс. Объекты этого класса не могут быть созданы.
Базовый класс: Object
Базовый класс для описания карточек базы знаний.

Свойство	Тип	Список	Описание
code	string		Код
comments	ArticleComment	Да	Комментарии
components	Component	Да	Компоненты
creationDate	dateTime		Дата регистрации
description	string		Описание
descriptionHTML	HTMLObject		Описание в формате HTML с картинками
modifiedDate	dateTime		Дата изменения
name	string		Наименование
objectVersion	string		Версия объекта — обязательна при записи существующего объекта
sections	Section	Да	Разделы
services	Service	Да	Сервисы

Общие свойства карточек базы знаний

Класс ArticleComment

Базовый класс: Record
Описывает комментарий к карточке базы знаний.

Свойство	Тип	Описание
author	User	Автор
comment	string	Текст комментария
date	dateTime	Дата
supportLine	SupportLine	Линия поддержки

Консультации

Пример использования в библиотеке :
Обработки.СлужбаПоддержки.Формы.Консультация

Класс Consultation

Базовый класс: KnowledgeBaseArticle
Описывает карточку Консультации.

Свойство	Тип	Описание
status	ConsultationStatus	Состояние консультации

Свойства класса

Класс ConsultationStatus

Базовый класс: Object
Описывает перечисление Состояния консультаций.
Значения перечисления:

Ошибки

Пример использования в библиотеке :
Обработки.СлужбаПоддержки.Формы.Ошибка

Класс Problem

Базовый класс: KnowledgeBaseArticle
Описывает карточку ошибки.

Свойство	Тип	Описание
bypass	string	Обходной путь
bypassHTML	HTMLObject	Обходной путь в формате HTML с картинками
critical	boolean	Критичная
playback	string	Воспроизведение
playbackHTML	HTMLObject	Воспроизведение в формате HTML с картинками
solution	string	Решение
solutionHTML	HTMLObject	Решение в формате HTML с картинками
status	ProblemStatus	Состояние

Свойства класса

Класс ProblemStatus

Базовый класс: Object
Описывает перечисление Состояния ошибок.
Значения перечисления:

Запланирована
Расследование
На исправлении
Исправлена

Пожелания

Пример использования в библиотеке :
Обработки.СлужбаПоддержки.Формы.Пожелание

Класс Suggestion

Базовый класс: KnowledgeBaseArticle
Описывает Пожелание.

Свойство	Тип	Описание
status	SuggestionStatus	Состояние

Свойства класса

Класс SuggestionStatus

Базовый класс: Object
Описывает перечисление Состояния пожеланий.
Значения перечисления:

Рассматривается
Дубль
НаГолосовании
Запланировано
Реализовано
Отклонено

Файлы

Пример использования в библиотеке :
Обработки.СлужбаПоддержки.Формы.ПрисоединенныеФайлы.
Для работы с файлами можно использовать общие запросы для работы с объектами, такие как:

Получение объекта
Обновление объекта
Удаление объекта

Так как файлы не существуют самостоятельно, а принадлежат какому либо объекту, для получения списка файлов и для добавления нового файла используются классы запросов для подчиненных объектов:

Получение списка подчиненных объекта.
Добавление подчиненного объекта.

Класс File

Базовый класс: Object
Описывает присоединенный файл.

Свойство	Тип	Описание
author	User	Автор файла.
binaryData	base64Binary	Двоичные данные файла.
creationDate	dateTime	Дата создания файла.
deletionMark	boolean	Пометка удаления.
description	string	Описание.
extension	string	Расширение файла.
modificationDateUniversal	dateTime	Всемирное координированное время (UTC) изменения файла.
name	string	Имя файла.
owner	Object	Владелец файла.
size	integer	Размер файла в байтах.
text	string	Текст, извлеченный из файла.

Трудозатраты

Трудозатраты могут добавляться по объектам:

Incident — обращение
Consultation — консультация
Problem — ошибка
Suggestion — пожелание

При работе с трудозатратами можно использовать запросы:

Получение списка подчиненных объектов.
Получение экземпляра нового подчиненного объекта.
Добавление подчиненного объекта.

Класс ActualWork

Базовый класс: Record
Описывает запись фактических трудозатрат.

Incident — обращение
Consultation — консультация
Problem — ошибка
Suggestion — пожелание

Процессы и задачи

Поручение

Пример использования в библиотеке :
Обработки.СлужбаПоддержки.Формы.Поручение

Класс Order

Базовый класс: Object
Описывает Поручение

Свойство	Тип	Описание
author	User	Автор
creationDate	dateTime	Дата создания
deadline	dateTime	Срок исполнения
description	string	Описание
descriptionHTML	HTMLObject	Описание в формате HTML с картинками
endDate	dateTime	Дата завершения
importance	TaskImportance	Важность
name	string	Наименование
number	string	Номер
objectVersion	string	Версия объекта — обязательна при записи существующего объекта
performer	TaskPerformer	Исполнитель
reviewer	TaskPerformer	Проверяющий
reviewPeriod	dateTime	Срок проверки
runtimeComments	string	Комментарий выполнения
status	ProcessStatus	Состояние
target	Object	Предмет

Свойства класса

Класс ProcessStatus

Базовый класс: Object
Описывает состояния процесса:

Класс OrderRoutePoint

Базовый класс: RoutePoint
Описывает точки маршрута процесса Поручение

Задача исполнителя

Пример использования в библиотеке :
Обработки.СлужбаПоддержки.Формы.Задача

Класс Task

Базовый класс: Object
Описывает задачу исполнителя

Свойство	Тип	Описание
acceptDate	dateTime	Дата принятия к исполнению
accepted	boolean	Принята к исполнению
author	User	Автор
creationDate	dateTime	Дата создания
deadline	dateTime	Срок исполнения
description	string	Описание
done	boolean	Выполнено
endDate	dateTime	Дата исполнения
importance	TaskImportance	Важность
myTask	boolean	Задача направлена текущему пользователю
name	string	Наименование
number	string	Номер
objectVersion	string	Версия объекта — обязательна при записи существующего объекта
performer	TaskPerformer	Исполнитель
performerComment	string	Комментарий исполнения
process	Order	Процесс
routePoint	RoutePoint	Точка маршрута
startDate	dateTime	Дата начала выполнения
status	ProcessStatus	Состояние
target	Object	Предмет

Свойства класса

Класс TaskImportance

Базовый класс: Object
Описывает важность задачи:

Класс TaskPerformer

Описывает исполнителя задачи

Свойство	Тип	Описание
mainAddressingObject	TaskAddressingObject	Основной объект адресации
role	TaskPerformerRole	Роль исполнителя
secondaryAddressingObject	TaskAddressingObject	Дополнительный объект адресации
user	User	Пользователь

Класс TaskPerformerRole

Базовый класс: Object
Описывает роль исполнителя задачи

Класс TaskAddressingObject

Базовый класс: Object
Описывает объект адресации задач

Общие объекты

НСИ