Ошибка при вызове метода контекста send произошла исключительная ситуация - ErrorsMaster.ru

Если при получении данных с сайта возникает ошибка:

Ошибка при вызове метода контекста (Send): Произошла исключительная ситуация (WinHttp.WinHttpRequest): The certificate authority is invalid or incorrect

Это может означать, что соединение защищенное и 1С не может установить подлинность сертификата.

Чтобы обойти эту ситуацию можно включить игнорирование ошибок защищенного соединения. Ниже в листенге это «блок по отключению защищенного соединения»


WinHttp = Новый COMОбъект("WinHttp.WinHttpRequest.5.1");
WinHttp.SetProxy(2, ПроксиСервер.Адрес+":"+ПроксиСервер.Порт); // устанавливаем параметры проксисервера если нужно
WinHttp.SetCredentials(ПроксиСервер.Логин, ПроксиСервер.Пароль, 1); // логин и пароль проксисервера
// ************************** Начало блока по отключению защищенного соединения **********
Скрипт= Новый COMОбъект("MSScriptControl.ScriptControl");
Скрипт.language="javascript";
Скрипт.AddObject("WinHttp",WinHttp);
Скрипт.Eval("WinHttp.Option(2)=1251"); // установка кодировки страницы
Скрипт.Eval("WinHttp.Option(4)=13056");//intSslErrorIgnoreFlags Игноировать ошбибки при SSL соединении
Скрипт.Eval("WinHttp.Option(6)=true");//blnEnableRedirects Разрешить перенаправления
Скрипт.Eval("WinHttp.Option(12)=true");//blnEnableHttpsToHttpRedirects Разрешить перенаправления с защищенного на не защиещенное соединение
// ************************** Конец блока по отключению защищенного соединения **********
WinHttp.Open("POST",URLСайта, Ложь); // URLСайта нужно заменить на тот к которому подсоединяетесь
WinHttp.SetRequestHeader("Host", URLСайта);	// URLСайта нужно заменить на тот к которому подсоединяетесь
WinHttp.SetRequestHeader("User-Agent","Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5");
WinHttp.SetRequestHeader("Accept","text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8");
WinHttp.SetRequestHeader("Accept-Language","ru,en-us;q=0.7,en;q=0.3");
WinHttp.SetRequestHeader("Accept-Charset","windows-1251,utf-8;q=0.7,*;q=0.7");
WinHttp.SetRequestHeader("Keep-Alive","300");
WinHttp.SetRequestHeader("Connection","keep-alive");
WinHttp.SetRequestHeader("Content-Type","application/x-www-form-urlencoded");
WinHttp.Send(ДанныеPOSTЗапроса)

Ключевыми, здесь являются параметры 4 и 12

Также встречал следующий код, но он НЕ рабочий, хотя и не вызывает ошибок


WinHttp.Option(2, 1251);
WinHttp.Option(4, 13056);//intSslErrorIgnoreFlags
WinHttp.Option(6, true);//blnEnableRedirects
WinHttp.Option(12, true);//blnEnableHttpsToHttpRedirects

Источник

Добрый день.

Работаем через внешние x32/x64 com компоненты для 1С. Своя реализация работы с вашим АПИ. Сейчас используем версию АПИ 5.28.2.481.

При изучении работы с «новым» объектом CreateReplySendTask2 в плане выполнения операции подписания входящих документов, мы столкнулись со следующей проблемой – при заполнении данных подписанта так же, как ранее мы это делали, используя «старый» объект CreateReplySendTask, у нас не происходило подписание документа, а выдавались ошибки о неверном заполнении данных подписанта.

Анализ возникшей проблемы и попытки заполнить данные подписанта так, чтобы ошибок не было и документ был бы подписан, привели к очень интересному результату!

Посмотрим на то, что мы делали:

Заполнение данных подписанта:

Возникающая ошибка:
Ошибка при вызове метода контекста (Send): Произошла исключительная ситуация (ReplySendTask2.Send): ##100[Ошибка сервера Диадок]code:400, HTTP error: Invalid data UserContractData:
Line: 9, Position: 115, /UniversalTransferDocumentBuyerTitle[1]/Signers[1]/SignerDetails[1]/@SignerType: The ‘SignerType’ attribute is invalid — The value ‘LegalEntity’ is invalid according to its datatype ‘String’ — The Enumeration constraint failed.
Line: 9, Positi

Дополнительно:
Хотелось бы обратить ваше внимание на то, что текст ошибки, возвращаемый вашей системой, по какой-то причине не полон и явно обрезан где-то посредине («…Line: 9, Positi» – и что дальше?)!

Такие, не до конца сформированные тексты ошибок, постоянно возникают при работе с данной версией компоненты!

Вопрос – Почему значение «LegalEntity» считается за ошибочное?! Ведь в документации ясно указано:

Сперва мы предположили, что у нас все-таки как-то неверно задано сочетание параметров SignerType, Powers и Status в данных подписанта. Но дальнейшая проверка показала, что:

Старый объект CreateReplySendTask с точно таким же заполнением данных подписанта прекрасно подписывает документ без каких-либо ошибок.
Какие бы сочетания возможных значений при заполнении вышеуказанных реквизитов SignerType, Powers и Status мы не делали (а мы просто тупо перепробовали все варианты!) – все равно при попытке подписания документа с использованием объекта CreateReplySendTask2 возникает ошибка вышеуказанного вида, поясняющая, что любое возможное значение SignerType (из указанных в документации!) является ошибочным!

В этот момент мы решили, что в компоненте просто какая-то ошибка в подписании документов через использование объекта CreateReplySendTask2. И решили написать вам письмо именно об этом. Но случайно вспомнили, что у вас есть сайт с документацией к вашему АПИ не только для 1С. И нашли вот эту страницу:

http://api-docs.diadoc.ru/ru/latest/proto/utd/ExtendedSigner.html

На которой увидели следующее:

И у нас появилась очень странная мысль – а вдруг у вас ошиблись с обработкой данных подписанта при работе с CreateReplySendTask2, и поэтому не срабатывают, как это работало раньше, указанные в документации к АПИ для 1С строковые значения для SignerType, Powers и Status, но при этом возьмут и сработают числовые значения с вышеуказанного скрина?!

Мы попробовали для SignerType установить значение «1» (строкой, т.к. у вас в объекте тип этого поля — строка). И вот что получилось:

Заполнение данных подписанта:

Возникающая ошибка:

Ошибка при вызове метода контекста (Send): Произошла исключительная ситуация (ReplySendTask2.Send): ##100[Ошибка сервера Диадок]code:400, HTTP error: Invalid data UserContractData:
Line: 9, Position: 200, /UniversalTransferDocumentBuyerTitle[1]/Signers[1]/SignerDetails[1]/@SignerStatus: The ‘SignerStatus’ attribute is invalid — The value ‘SellerEmployee’ is invalid according to its datatype ‘Integer’ — The string ‘SellerEmployee’ is not a valid

И оказалось, что наше, казалось бы, совершенно странное предположение было верным! Теперь ошибка была найдена уже в другом поле – Status! А с полем SignerType проблем обнаружено не было.

При этом хотелось бы дополнительно обратить ваше внимание на два обстоятельства:

Во второй ошибке по полю статус почему-то написано про тип Integer, хотя поле имеет тип «строка». И в первой показанной ошибке по SignerType как раз написано – String. Откуда здесь вообще взялся Integer?
И в первой, и во второй ошибках при указании проблемы используются названия полей не из документации к компоненте для 1С, а из документации со страницы http://api-docs.diadoc.ru/ru/latest/proto/utd/ExtendedSigner.html, что немного странно.

Мы поняли, что случайно оказались на правильном пути и попробовали подписать документ, указав для всех полей SignerType, Powers и Status строковые значения чисел со значениями со скрина с enum’ами со страницы http://api-docs.diadoc.ru/ru/latest/proto/utd/ExtendedSigner.html.

Заполнение данных подписанта:

При попытке подписания документа с использованием объекта CreateReplySendTask2 и вышеуказанным заполнением данных подписанта, документ подписывается без ошибок!

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

При получении данных контента покупателя «старым» способом:

Т.е. это именно указанные в документации для 1С значения полей, и они полностью соответствуют элементам enum’ов со страницы http://api-docs.diadoc.ru/ru/latest/proto/utd/ExtendedSigner.html!

При получении данных контента покупателя «новым» способом:

А вот при «новом» получении данных происходит очень странная штука – возвращаются именно числа в строковом представлении! Что, во-первых, очень странно, а, во-вторых, абсолютно не информативно. Особенно учитывая, что в документации к компоненте для 1С никакого упоминания числовых значений для значений полей SignerType, Powers и Status вообще нет!

В итоге получается следующее:

У вас явно присутствует какая-то неоднозначность в данных, возвращаемых в старой и новой версиях контентов. По идее – это ошибка и такого быть не должно.
У вас явно есть либо ошибка при передаче и обработке значений полей данных подписанта при работе с CreateReplySendTask2, либо ошибка в документации, объясняющей заполнение данных подписанта. Скорее ошибка все-таки в передаче и обработке значений полей данных подписанта, т.к. документация как минимум соответствует тому, что передается с использованием «старого» объекта CreateReplySendTask и принимается в «старом» контенте, получаемом через GetBuyerContent().

Очень хотелось бы, чтобы это было исправлено и как-то приведено в соответствие с документацией и, как бы сказать – к одному знаменателю, т.е. чтобы не было различий в данных возвращаемых в «старых» и «новых» контентах, т.к. это ну очень странно!

Спасибо.

Источник

Ошибка при вызове метода контекста (send): Отказано в доступе

Ошибка произошла при использовании сервиса геокодирования Яндекса (в рамках задачи получения ближайших станций метро по адресу)

Быстрый переход

Полный текст
Анализ вариантов
Решение:
- Пример кода

Полный текст

Ошибка при вызове метода контекста (send): Произошла исключительная ситуация (msxml3.dll): Отказано в доступе

Анализ вариантов

1. Найденное на просторах интернета решение добавить «www.» в строку, привело к другой ошибке (отсутствию ресурса, да и как выяснилось там Ошибка происходила на Open).

2. Изменился адрес или формат запроса.

Зайдя на страницу описания сервиса, в глаза бросилось, что Яндекс перешел https. (На этапе проверки в браузере, не обратил внимание на redirect c http).

Решение:

Перешел к уже отлаженному на https «Winhttp», возможно свойства Option применимы и XMLHTTP, т.к. остальные, используемые методы и свойства, совместимы.

Пример кода

XMLHttp = Новый COMОбъект("WinHttp.WinHttpRequest.5.1");
XMLHttp.Option(2,"UTF-8");
XMLHttp.Option(4, 13056); //intSslErrorIgnoreFlags
Попытка
	XMLHttp.Open("GET", Запрос, Ложь,login,Password);
Исключение
	Ошибка = ОписаниеОшибки();
	Сообщение = Новый СообщениеПользователю;
	Сообщение.Текст = "Ошибочный OPEN "+Ошибка+"("+Запрос+")";
	Сообщение.Сообщить();
        Возврат Ложь;
КонецПопытки;	
//Отправка запроса      
Попытка
	XMLHttp.Send();	
Исключение
КонецПопытки;

Кодак продает фотопленку, но рекламируют они не фотопленку. Они рекламируют память.

Источник

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

ввожу в Internet Explorer https://api.telegram.org/bot<Мой токен>/getUpdates выводит:
Internet Explorer не может отобразить эту веб-страницу.

ввожу в люб другом браузере тоже самое ответ приходит корректный.

в самом 1с в exception попадает :

{ОбщийМодуль.skdTelegram.Модуль(629)}: Ошибка при вызове метода контекста (Send): Произошла исключительная ситуация
(WinHttp.WinHttpRequest): Ошибка поддержки безопасных каналов

Код

WinHttp = Новый COMОбъект("WinHttp.WinHttpRequest.5.1");    
    WinHttp.Option(2, "utf-8");     
    WinHttp.Open("GET","https://api.telegram.org/bot<МойТОкен>/getUpdates?offset=119801317&", 0);

    WinHttp.SetRequestHeader("Accept-Language", "ru");
    WinHttp.SetRequestHeader("Accept-Charset", "Windows-1251");
    WinHttp.setRequestHeader("Content-Language", "ru");
    WinHttp.setRequestHeader("Content-Charset", "Windows-1251");
    WinHttp.setRequestHeader("Content-Type", "application / x-www-form-urlencoded; charset = Windows-1251");        

    WinHttp.Send();

PS (IE Версия 8 ) может изза этого?

Источник

Ошибка при вызове метода контекста (send) по причине: Произошла исключительная ситуация (msxml6.dll): Отказано в доступе.

Описание ошибки:
При парсинге страницы сайта, точнее при попытке получения файла-изображения:
Ошибка при вызове метода контекста (send)
ХМЛХТТП.Send();
по причине:
Произошла исключительная ситуация (msxml6.dll): Отказано в доступе.

Найденные решения:

Все найденные в поисковике по данном запросу результаты оказались не эффективными в преодолении ошибки, но все-таки приведу ссылки с форума сайта infostart.ru здесь, может помогут в других смежных аспектах приведенной ошибки:

Ошибка при вызове метода контекста (send) — о доступности на клиенте и сервере файла msxml3.dll

Ошибка при вызове метода контекста (send) — о сбое скачивания с ресурса по причине msxml6.dll

Вот участок кода, в котором возникала ошибка:

Оказалось, что ранее, при получении ссылки картинки, не учитывался факт, что на сайте используется https, а ссылка формировалась с http:\. После учета наличия защищенного соедения на сайте и использования https:\ ошибка не проявлялась:

ХМЛХТТП = Новый COMОбъект(«MSXML2.XMLHttp.6.0»);

ХМЛХТТП.Open(«GET», СсылкаНаКартинку, Ложь);

ХМЛХТТП.Send();

Оцените, помогло ли Вам предоставленное описание решения ошибки?

© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

20-06-2019

Журавлев А.С.
(Сайт azhur-c.ru)

Источник