Post запросы из 1С

При длительной работе с программой 1С пользователи быстро учатся устранять большинство ошибок, которые появляются в процессе. Однако с выходом новых, более усовершенствованных версий появляются и новые типы неполадок. В этой статье вы узнаете, как устранить ошибку при выполнении запроса GET к ресурсу e1cib/cmi/commands.

Причины ошибки в 1С

Подобное сообщение часто дополняется другими строками, которые могут пояснять причины сбоя в программе или программном коде. Встречается такая строка — недостаточно свободной памяти для выполнения операций. Она помогает пользователю быстро сориентироваться и предпринять нужные действия — выделить программе больше оперативной памяти (если это возможно).

Есть и другой тип подобного сообщения — неспецифированная ошибка работы с ресурсом e1cib/logform. Все эти случаи мы рассмотрим далее в программе и определим, как их решить. Как и при появлении многих других сообщений о сбое, единой инструкции просто не существует. Связано это с тем, что пользователи или операторы могут работать не только с разными версиями ОС Windows, но и в разных версиях 1С.

Читайте также: ошибка при выполнении запроса POST к ресурсу /e1cib/logForm.

Изменяем режим запуска для пользователей

Часто ошибку можно решить довольно просто. Для этого вам необходимо войти с правами администратора и изменить настройки учетной записи пользователя. Нужно выбрать редактирование информационной базы и в поле «Основной режим запуска» поставить галочку на «Выбирать автоматически». Сохраните эти изменения, и ошибка должна пропасть.

Режим запуска для пользователя

Устранение сбоя при выполнении запроса GET к ресурсу

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

1. Чтобы очистить кэш, вам нужно в 1С найти к нему путь. Он находится в той же папке, что и программа;
2. Выберите кнопку «Настройки»;
3. Найдите путь в этом окне. Вы можете скопировать путь и вставить его в проводнике, чтобы быстро попасть в нужную папку;
   Путь к папке с кэшем в 1С
4. В ней будут файлы с длинными случайными наборами символов в качестве имен. Их все нужно удалить. Это и есть кэш 1С.

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

1. Запустить программу;
2. Откройте настройки информационной базы;
3. В строке «Дополнительные параметры…» введите в строку: «/ClearCache» и сохраните изменения.
   Настройка очистки кэша при запуске

Запуск утилит для исправления ошибок 1С

В программном комплексе 1С включены специальные утилиты, которые могут помочь пользователю решить проблемы при работе. Если вам еще не удалось устранить дисфункцию при выполнении запроса GET к ресурсу e1c/ibc/micommands:

1. Откройте «Администрирование»;
2. Найдите и выберите пункт «Тестирование и исправление»;
   Утилита «Тестирование и исправление»
3. Выберите нужные параметры галочкой и запустите утилиту.

Каждый из параметров позволяет выполнять дополнительные проверки над теми или иными данными программы:

• Реиндексация таблиц — ревизия индексов таблиц. В ходе тестирования будет произведена реиндексация. Не убирайте с него галочку. Эта процедура пойдет программе на пользу;
• Проверка целостности базы — база данных будет перепроверена. Если будут найдены неполадки, утилита исправит их. Также полезная функция, которая не будет лишней при запуске;
• Проверка базы ссылок — будут найдены неверные указатели, ссылки и действия над ними передаются пользователю;
• Реструктуризация таблиц — эта процедура занимает много времени. Поэтому применять нужно только в случае реальной необходимости. В результате её действия структура таблицы будет пересоздана;
• Сжатие таблиц — также полезный параметр, в процессе удаляются элементы данных, в которых уже нет необходимости.

Узнайте, как исправить ошибку в 1С 7.7 «Порядок сортировки, установленный для базы данных, отличается от системного».

Добавление памяти для 1С

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

Чтобы избавиться от ошибки с памятью:

1. Откройте меню «Пуск». Запишите в пустой строке поиска «Командная строка»;
2. Выберите её в результатах ПКМ и запустите от имени администратора;
3. Введите команду: CMD и нажмите клавишу ввода;
4. Курсор перейдет на другую строку, в ней запишите: bcdedit /set increaseuserva 3072 и нажмите ENTER. В цифрах выражается память в мегабайтах. Здесь вы можете указать свое значение, относительно установленной в компьютере оперативной памяти;
5. В системных настройках можно узнать, сколько памяти есть в компьютере. Для этого нажмите вместе WIN+PAUSE.

После этих действий перезагрузите компьютер и проверьте, появляется ли ошибка при выполнении запроса GET к ресурсу e1cib/cmi/commands.

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

ИнтернетПрокси = Новый ИнтернетПрокси(Ложь); ИнтернетПрокси.Установить(Прокси.Протокол, Прокси.Сервер, Прокси.Порт, Прокси.Пользователь, Прокси.Пароль, Ложь); Соединение = Новый HTTPСоединение(«api.telegram.org»,443,,,ИнтернетПрокси,,Новый ЗащищенноеСоединениеOpenSSL()); ПолучениеЗапрос = «bot»+ТокенБота+»/sendMessage?chat_id=»+Адресат+»&text=»+ Сообщение; Запрос = Новый HTTPЗапрос(ПолучениеЗапрос); Ответ = Соединение.Получить(Запрос);

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

В благодатные времена, когда Телеграм не блокировался, описанная выше функциональность реализовывалась буквально в несколько строк кода:

Соединение = Новый HTTPСоединение(«api.telegram.org»,443,,,,,Новый ЗащищенноеСоединениеOpenSSL()); ПолучениеЗапрос = «bot»+ТокенБота+»/sendMessage?chat_id=»+Адресат+»&text=»+ Сообщение; Запрос = Новый HTTPЗапрос(ПолучениеЗапрос); Ответ = Соединение.Получить(Запрос);

После блокировки приходится добавить прокси:

Казалось бы, код практически не усложнился. Но это на первый взгляд. А где взять прокси? Логично, что в Интернете есть множество сайтов, на которых приведены актуальные списки прокси-серверов. И в самом начале мы воспользовались одним из таких сайтов, где и взяли параметры для подключения к прокси-серверу. Естественно, что сами параметры подключения к прокси оставлять в исходном коде просто не спортивно, ведь может возникнуть и возникнет необходимость изменить их. Поэтому вполне логично завести справочник прокси-серверов. Сам справочник приведен на рисунке ниже:

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

ВыборкаПрокси = Справочники.Прокси.Выбрать(); Пока ВыборкаПрокси.Следующий() Цикл Попытка ИнтернетПрокси = Новый ИнтернетПрокси(Ложь); ИнтернетПрокси.Установить(ВыборкаПрокси.Протокол, ВыборкаПрокси.Сервер, ВыборкаПрокси.Порт, ВыборкаПрокси.Пользователь, ВыборкаПрокси.Пароль, Ложь); Соединение = Новый HTTPСоединение(«api.telegram.org»,443,,,ИнтернетПрокси,,Новый ЗащищенноеСоединениеOpenSSL()); ПолучениеЗапрос = «bot»+ТокенБота+»/sendMessage?chat_id=»+Адресат+»&text=»+ Сообщение; Запрос = Новый HTTPЗапрос(ПолучениеЗапрос); Ответ = Соединение.Получить(Запрос); Прервать; Исключение КонецПопытки; КонецЦикла;

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

• Часть прокси-серверов оказалась заблокированной
• Другая часть прокси периодически становилась недоступной

Для решения этих проблем в справочнике были введены реквизиты «ИспользоватьПоУмолчанию» и «Порядок», которые были призваны обеспечить попытку отправки сообщений через наиболее надежные прокси-сервера. Очевидно, что надежность определялась на глазок. Кроме того изменять эти реквизиты приходилось вручную, что не особо радовало.

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

Что же делать? С одной стороны можно было забросить Телеграм и переехать на Slack или Viber или даже вернуться к использованию собственного XMPP-сервера. С другой стороны не хотелось отказываться от всех наработок, да и трудозатраты на переезд представлялись вполне ощутимыми. В связи с этим в голову пришла простая и логичная мысль — вести историю отправки и уже на основании этой истории строить своеобразный рейтинг прокси-серверов. Такой подход позволил бы автоматически определять прокси, который в настоящее время наиболее надежен (то есть стабильно отправляет сообщения).

Для ведения истории был создан простой регистр:

В этот регистр записывался факт отправки или неотправки сообщения через прокси-сервер, если сообщение было отправлено, то записывалась 1, иначе -1.

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

Функция ПолучитьHTTPСоединениеСПрокси(Прокси) Экспорт Если Прокси = Неопределено Тогда Соединение = Новый HTTPСоединение(«api.telegram.org»,443,,,,,Новый ЗащищенноеСоединениеOpenSSL()); Иначе ИнтернетПрокси = Новый ИнтернетПрокси(Ложь); ИнтернетПрокси.Установить(Прокси.Протокол, Прокси.Сервер, Прокси.Порт, Прокси.Пользователь, Прокси.Пароль, Ложь); Соединение = Новый HTTPСоединение(«api.telegram.org»,443,,,ИнтернетПрокси,,Новый ЗащищенноеСоединениеOpenSSL()); КонецЕсли; Возврат Соединение; КонецФункции Процедура ДобавитьВНаборСтатистикиОтправкиСообщенийВМессенджер(Набор, Прокси, Отправлено) НСтр = Набор.Добавить(); НСтр.Период = ТекущаяДата(); НСтр.Прокси = Прокси; НСтр.Отправлено = Отправлено; КонецПроцедуры Функция ОтправитьСообщение(Сообщение, Адресат, ТокенБота) Экспорт ВыборкаПрокси = ПолучитьАктивныеПрокси(); Ответ = Неопределено; Ок = «»; Набор = РегистрыСведений.СтатистикаОтправкиСообщенийВМессенджер.СоздатьНаборЗаписей(); Пока ВыборкаПрокси.Следующий() Цикл Попытка Соединение = ПолучитьHTTPСоединениеСПрокси(ВыборкаПрокси.Ссылка); ПолучениеЗапрос = «bot»+ТокенБота+»/sendMessage?chat_id=»+Адресат+»&text=»+ Сообщение; Запрос = Новый HTTPЗапрос(ПолучениеЗапрос); Ответ = Соединение.Получить(Запрос); ДобавитьВНаборСтатистикиОтправкиСообщенийВМессенджер(Набор, ВыборкаПрокси.Ссылка, 1); Прервать; Исключение ДобавитьВНаборСтатистикиОтправкиСообщенийВМессенджер(Набор, ВыборкаПрокси.Ссылка, -1); КонецПопытки; КонецЦикла; Набор.Записать(Ложь); Если ЗначениеЗаполнено(Ответ) = Истина Тогда Чтение = Новый ЧтениеJSON; Чтение.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку()); ОтветСоотв = ПрочитатьJSON(Чтение,Истина); Ок = ОтветСоотв ; КонецЕсли; Возврат Ок КонецФункции

В приведенном фрагменте кода присутствует вызов функции ПолучитьАктивныеПрокси(), однако нет ее объявления. Поэтому хочется остановиться на данной функции подробнее. Само по себе хранение истории отправки сообщений дает совсем не много. Ну что интересного в, например, таких данных:

Видно, что через какие-то прокси сообщения не уходят, через какие-то уходят, а иногда отправка работает через раз. Очевидно, что необходим какой-то критерий для составления того самого рейтинга прокси, о котором говорилось выше. Долго думать над таким критерием не пришлось — за аналог был взят метод оценки по трем точкам. То есть прокси ранжировались исходя из суммы трех показателей:

• сумма успешных и неуспешных отправлений за месяц;
• успешность последней отправки;
• сумма успешных и неуспешных отправлений за текущий день

Каждый из указанных показателей имеет свой коэффициент — 7/12, 3/12 и 2/12 соответственно, коэффициенты подобраны эвристически. При этом неуспешное отправление при суммировании за день засчитывается не за -1 а за -0,8. Такую оценку словами можно описать примерно так: «если прокси хорошо отправлял в течении предыдущего месяца (читай 30 предшествующих дней, то скорее всего будет выбран он, однако если в течении дня прокси работал нестабильно и последняя отправка была неудачной, то возможно его рейтинг снизится) «. Теперь приведу код ранжирования:

Функция ПолучитьАктивныеПрокси() Экспорт Запрос = Новый Запрос; Запрос.Текст = «ВЫБРАТЬ | СтатистикаОтправкиСообщенийВМессенджерСрезПоследних.Прокси, | СтатистикаОтправкиСообщенийВМессенджерСрезПоследних.Отправлено |ПОМЕСТИТЬ ВтПоследние |ИЗ | РегистрСведений.СтатистикаОтправкиСообщенийВМессенджер.СрезПоследних КАК СтатистикаОтправкиСообщенийВМессенджерСрезПоследних |ГДЕ | СтатистикаОтправкиСообщенийВМессенджерСрезПоследних.Отправлено = 1 |; | |//////////////////////////////////////////////////////////////////////////////// |ВЫБРАТЬ | СтатистикаОтправкиСообщенийВМессенджер.Прокси, | СУММА(ВЫБОР | КОГДА СтатистикаОтправкиСообщенийВМессенджер.Отправлено < 0 | ТОГДА -0.8 | ИНАЧЕ СтатистикаОтправкиСообщенийВМессенджер.Отправлено | КОНЕЦ) КАК Отправлено |ПОМЕСТИТЬ ВтДень |ИЗ | РегистрСведений.СтатистикаОтправкиСообщенийВМессенджер КАК СтатистикаОтправкиСообщенийВМессенджер |ГДЕ | СтатистикаОтправкиСообщенийВМессенджер.Период МЕЖДУ &ДатаНачала И &ДатаКонец | |СГРУППИРОВАТЬ ПО | СтатистикаОтправкиСообщенийВМессенджер.Прокси |; | |//////////////////////////////////////////////////////////////////////////////// |ВЫБРАТЬ | СтатистикаОтправкиСообщенийВМессенджер.Прокси, | СУММА(СтатистикаОтправкиСообщенийВМессенджер.Отправлено) КАК Отправлено |ПОМЕСТИТЬ ВтМесяц |ИЗ | РегистрСведений.СтатистикаОтправкиСообщенийВМессенджер КАК СтатистикаОтправкиСообщенийВМессенджер |ГДЕ | СтатистикаОтправкиСообщенийВМессенджер.Период МЕЖДУ &ДатаНачала1 И &ДатаКонец1 | |СГРУППИРОВАТЬ ПО | СтатистикаОтправкиСообщенийВМессенджер.Прокси |; | |//////////////////////////////////////////////////////////////////////////////// |ВЫБРАТЬ | ВтМесяц.Прокси, | ВтМесяц.Отправлено КАК ОтправленоМесяц, | ВтПоследние.Отправлено КАК ОтправленоПоследнее, | ВтДень.Отправлено КАК ОтправленоДень, | ЕСТЬNULL(ВтМесяц.Отправлено, 0) * (7 / 12) + ЕСТЬNULL(ВтПоследние.Отправлено, 0) * (3 / 12) + ЕСТЬNULL(ВтДень.Отправлено, 0) * (2 / 12) КАК ОтправленоУсред |ПОМЕСТИТЬ ВтСтат |ИЗ | ВтМесяц КАК ВтМесяц | ЛЕВОЕ СОЕДИНЕНИЕ ВтПоследние КАК ВтПоследние | ПО ВтМесяц.Прокси = ВтПоследние.Прокси | ЛЕВОЕ СОЕДИНЕНИЕ ВтДень КАК ВтДень | ПО ВтМесяц.Прокси = ВтДень.Прокси |; | |//////////////////////////////////////////////////////////////////////////////// |ВЫБРАТЬ | ЕСТЬNULL(ВтСтат.ОтправленоУсред, 0) КАК ОтправленоУсред, | ВложенныйЗапрос.Ссылка КАК Ссылка |ИЗ | (ВЫБРАТЬ | Прокси.Ссылка КАК Ссылка, | Прокси.Порядок КАК Порядок | ИЗ | Справочник.Прокси КАК Прокси | ГДЕ | Прокси.Активно = ИСТИНА) КАК ВложенныйЗапрос | ЛЕВОЕ СОЕДИНЕНИЕ ВтСтат КАК ВтСтат | ПО ВложенныйЗапрос.Ссылка = ВтСтат.Прокси | |УПОРЯДОЧИТЬ ПО | ОтправленоУсред УБЫВ»; Запрос.УстановитьПараметр(«ДатаНачала», НачалоДня(ТекущаяДата()) ); Запрос.УстановитьПараметр(«ДатаКонец», ТекущаяДата()); Запрос.УстановитьПараметр(«ДатаНачала1», ДобавитьМесяц(ТекущаяДата(), -1)); Запрос.УстановитьПараметр(«ДатаКонец1», ТекущаяДата()); Результат = Запрос.Выполнить(); Выборка = Результат.Выбрать(); Возврат Выборка; КонецФункции

Функция оказалась совсем незатейливой. Однако результаты выбранного подхода порадовали. В течении недели собиралась статистика и время отправки сообщений так и оставалось на уровне 5-30 минут, перебор прокси все еще был почти случайным. Но через несколько дней время отправки стабилизировалось и в среднем перестало превышать 1 минуту с редкими задержками до 5 минут. Казалось бы, просто на основании истории были определены 1-2 наиболее стабильных прокси сервера, которые и обеспечивали стабильную отправку сообщений. Однако на деле происходит так, что если эти стабильные прокси вдруг почему-то перестают работать, то их заменяют другие прокси-сервера, которые может быть, не так стабильны, но в текущий момент работают. При этом, например, на следующий день отправка может пойти снова через тот прокси, который вчера почему-то «захандрил».

Для подтверждения сказанного приведу простенькую статистику.

Из рисунка видно, что в период с 16 по 22 июня количество ошибок (когда прокси не отвечал) при отправке сообщений было крайне велико. При этом каждая ошибка увеличивала время отправки сообщений. Однако позднее количество ошибок при отправке снижается и выходит на достаточно стабильный уровень, что обусловлено, как уже говорилось выше, с одной стороны отсутствием необоснованного перебора прокси-серверов и с другой стороны возможностью автоматически производить отправку через прокси с «рейтингом чуть ниже», если «самый хороший сервер» почему-то не отвечает.

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

Если же посмотреть на свежие данные, то очевидно, что:

• При небольшом числе сообщений за день отправка происходит с использованием одного-двух прокси-«лидеров рейтинга» (например 31.07.2018, 01.08.2018);
• При чуть большем количестве сообщений иногда используются прокси с чуть меньшим рейтингом (например 30.07.2018);
• При еще большем количестве сообщений и наличии проблем у прокси-«лидеров» используется еще большее количество серверов (например 27.07.2018), но при этом в отличии от ситуации на предыдущем рисунке ( 16.06.2018) доля обращений к серверам, которые не отвечают, совсем мала; если говорить по-другому то аутсайдеру давался шанс, в условиях, когда лидеры рейтинга сплоховали, но если шанс использован не был, то второго шанса точно не будет.

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

Этой мой первый пост, буду признателен за конструктивную обратную связь!

(0) Сервис работает точно так же, как как и при GET. Просто параметры надо брать из тела запроса

&nbsp// В зависимости от типа запроса извлечем его параметры Если ТипЗнч(Запрос.ПараметрыЗапроса) = Тип(«ФиксированноеСоответствие») И Запрос.ПараметрыЗапроса.Количество() > 0 Тогда &nbsp// !!!!! Здесь возникают ошибки при передаче в параметрах значений с запрешенными знаками (например, кавычкой) &nbsp// Это GET-запрос, параметры хранятся в Запрос.ПараметрыЗапроса Для Каждого КлючИЗначение Из Запрос.ПараметрыЗапроса Цикл ПараметрыЗапроса.Вставить(КлючИЗначение.Ключ, КлючИЗначение.Значение); КонецЦикла; Иначе &nbsp// Это POST-запрос, параметры содержатся в теле запроса в виде строки ПараметрыЗапроса = Новый Соответствие; ПараметрыСтрокой = СтрЗаменить(РаскодироватьСтроку(Запрос.ПолучитьТелоКакСтроку(), СпособКодированияСтроки.КодировкаURL), «&», Символы.ПС); Для Счетчик = 1 По СтрЧислоСтрок(ПараметрыСтрокой) Цикл ТекущийПараметр = СтрЗаменить(СокрЛП(СтрПолучитьСтроку(ПараметрыСтрокой, Счетчик)), «=», Символы.ПС); Если ЗначениеЗаполнено(ТекущийПараметр) Тогда ПараметрыЗапроса.Вставить(СтрПолучитьСтроку(ТекущийПараметр, 1), СтрПолучитьСтроку(ТекущийПараметр, 2)); КонецЕсли; КонецЦикла; КонецЕсли;

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

Для кодирования используются функции ПолучитьBase64СтрокуИзДвоичныхДанных и ПолучитьДвоичныеДанныеИзСтроки, строка с данными авторизации это имя и пароль через двоеточие «:”.

Непосредственно POST запрос выполняется методом ОтправитьДляОбработки.

Ниже пример кода.

АдресСервера = «www.server.com»; Ресурс = «/api/endpoint»; ИмяПользователя = «user»; Пароль = «password»; СтрокаАвторизации = ПолучитьBase64СтрокуИзДвоичныхДанных( ПолучитьДвоичныеДанныеИзСтроки( «»+ИмяПользователя+»:»+Пароль,КодировкаТекста.UTF8,Ложь)); SSL = Новый ЗащищенноеСоединениеOpenSSL; Соединение = Новый HTTPСоединение(АдресСервера,443,,,,,SSL); Заголовки = Новый Соответствие; Заголовки.Вставить(«Content-Type», «application/json; charset=utf-8»); Заголовки.Вставить(«Authorization», «Basic «+СтрокаАвторизации); Запрос = Новый HTTPЗапрос(Ресурс,Заголовки); Запрос.УстановитьТелоИзСтроки(СтрокаJSON); ИмяФайлаОтвета = ПолучитьИмяВременногоФайла(); Ответ = Соединение.ОтправитьДляОбработки(Запрос,ИмяФайлаОтвета);

Статус ответа веб-сервера можно прочитать в свойстве Ответ.КодСтатуса, если сервер возвращает какие-то данные, их можно прочитать из временного файла, его имя в переменной ИмяФайлаОтвета.