Ошибка при интеграции с сервисом - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

VerifySignature Ошибка проверки подписи:
0 – проверка ЭП успешна или создание ЭП успешна или проверка сертификата открытого ключа успешна;
-1 – нет поля data или signed в json;
-2 – нет тега <ds:DigestValue> или нет хеша;
-3 – нет тега <ds:SignatureValue> или нет подписи;
-4 – нет тега <ds:X509Certificate> или нет сертификата проверки;
-5 – внутренняя ошибка libgzcryptosign.so;
-6 – электронная подпись целостная, но срок действия ключа подписи истек;
-7 – электронная подпись целостная, но в сертификате отсутствует назначение — для подписи;
-8 – ошибка каноникализации или трансформации данных, полученных для проверки подписи;
-9 – ошибка вычисления хэша;
-10 – вычисленный хэш от данных и хэш в xml не совпадают;
-11 – ошибка создания каноклизированной xml для проверки подписи;
-12 – нарушена целостность электронной подписи или данных;
-13 – алгоритм формирования подписи не является ГОСТ 34.10-2001_256 или ГОСТ 34.10-2012_256;
-14 – нет данных для подписи;
-15 – ошибка создания каноклизированной xml для создания подписи;
-16 – срок действия сертификата открытого ключа менее 10 лет
-17 – В запросе отсутствует HTTP заголовок CertificateType
-18 — Отсутствуют или имеют неправильный формат атрибуты со ссылками и значениями доказательств подлинности.
-19 — В сообщении не найден действительный штамп времени на подпись.
-20 — Значения ссылок на доказательства подлинности и сами доказательства, вложенные в сообщение, не соответствуют друг другу.
-21 – Подпись на штамп времени не действительна.
-22 – XAdES содержит не поддерживаемые атрибуты.
-23 – Тип содержимого XAdES не соответствует
1 – электронная подпись целостная, но этот сертификат или один из сертификатов в цепочке сертификатов недействителен;
4 – электронная подпись целостная, но текущий сертификат или один из сертификатов в цепочке отозван;
8 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов не имеет действительной подписи;
16 – электронная подпись целостная, но сертификат или цепочка сертификатов недействительны для предполагаемого использования;
32 – электронная подпись целостная, но сертификат или цепочка сертификатов основана на не доверенном корневом сертификате;
64 – электронная подпись целостная, но статус отзыва текущего сертификата или одного из сертификатов в цепочке сертификатов неизвестен;
128 – электронная подпись целостная, но один из сертификатов в цепочке был выдан центром сертификации, который был сертифицирован исходным сертификатом;
256 – электронная подпись целостная, но один из сертификатов имеет неправильное расширение;
512 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение policy constraints, а один из выпущенных сертификатов имеет запрещенное расширение сопоставления политик или не имеет необходимого расширения политик выдачи;
1024 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение basic constraints, и либо сертификат не может быть использован для выдачи других сертификатов, либо длина пути цепочки превышена;
2048 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет недопустимое расширение name constraints;
4096 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение name constraints, которое содержит неподдерживаемые поля;
8192 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение name constraints, а name constraints отсутствует для одного из вариантов имени в конечном сертификате;
16384 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение name constraints, и нет разрешенного name constraint для одного из вариантов имени в конечном сертификате;
32768 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение name constraints, и одно из вариантов имени в конечном сертификате явно исключен;
16777216 – электронная подпись целостная, но статус отзыва сертификата или одного из сертификатов в цепочке сертификатов недоступен или устарел;
33554432 – электронная подпись целостная, но конечный сертификат не имеет каких-либо результирующих политик выдачи, а один из выдающих сертификатов центра сертификации имеет расширение policy constraints, требующее этого;
67108864 – электронная подпись целостная, но сертификат не доверенный;
134217728 – электронная подпись целостная, но сертификат не поддерживает критическое расширение;
1048576 – электронная подпись целостная, но сертификат подписан слабым алгоритмом;
65536 – электронная подпись целостная, но цепочка сертификатов не полная;
131072 – электронная подпись целостная, но список отзывов сертификатов (CTL), использованный для создания этой цепочки просрочен;
262144 – электронная подпись целостная, но список отзывов сертификатов (CTL), использованный для создания этой цепочки, не имеет действительной подписи;
524288 – электронная подпись целостная, но список отзывов сертификатов (CTL), использованный для создания этой цепочки, не имеет правильного предназначения.

Источник

Статья обновлена: 19 октября 2022
ID: 14614

Статья относится к:

Kaspersky Security для виртуальных сред 5.2 Легкий агент;
Kaspersky Security для виртуальных сред 5.1 Легкий агент.

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

Причина

Адрес Сервера интеграции должен быть указан в формате IP или FQDN и адресом не может быть localhost или 127.0.0.0.

В большинстве инфраструктур Сервер интеграции и Сервер администрирования устанавливаются на один компьютер. Поэтому Kaspersky Security для виртуальных сред Легкий агент по умолчанию заполняет поля в интерфейсе данными для подключения к Серверу интеграции из настроек Сервера администрирования. Они могут не соответствовать корректному формату для подключения, например, при установке Сервера администрирования на компьютер вне домена.

Решение

Убедитесь, что адрес Сервера интеграции указан в формате IP или FQDN. Чтобы ошибка подключения не повторялась, настройте адрес Сервера администрирования, который будет соответствовать корректному формату адреса Сервера интеграции:

Откройте Kaspersky Security Center.
Перейдите в Дополнительно → Удаленная установка.
В контекстном меню Инсталляционные пакеты выберите Свойства.
В разделе Общие задайте адрес Сервера администрирования в формате IP или FQDN.

Ошибка из-за неправильного адреса не будет появляться при подключении к Серверу интеграции.

Спасибо за ваш отзыв, вы помогаете нам становиться лучше!

Источник

Как минимизировать ошибки при интеграции с внешними сервисами: опыт онлайн-брокера

Время на прочтение
6 мин

Количество просмотров 5.4K

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

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

Чтобы вы лучше понимали специфику наших интеграций, вкратце расскажем, чем мы занимаемся. Мы развиваем онлайн-брокера. Принцип работы: на сайт приходит пользователь, заполняет анкету, мы передаем ее микрофинансовым организациям (МФО) и получаем от них одобрение или отказ по займу. Пользователь выбирает подходящее предложение и получает деньги. Чтобы всё это работало онлайн, мы интегрируемся с МФО по API.

Оценка готовности партнера к интеграции с помощью чек-листа и спецификации

Разберем два сценария: когда у потенциального партнера уже есть API для приема заявок, и когда нет. Оба сценария предполагают, что партнер хочет с нами интегрироваться и готов потратить на это время.

У партнера нет API — отправляем спецификацию

Раньше мы объясняли партнеру устно или в переписке, что нам нужно для интеграции, а партнер на основе этих объяснений делал API для приема заявок с Finspin. Мы не согласовывали требования к моделям, объектам, полям анкеты и правилам их валидации. Бегло описывали назначения методов и возможные ответы. Результат оказывался бесконечно далеким от ожидаемого, потому что наше понимание API сильно расходилось с партнерским. Приходилось все переделывать.

Сейчас. Мы написали свою спецификацию — YAML-файл, который можно открыть в Swagger. В спецификации мы описали самое подходящее API для интеграции Finspin с МФО: поля анкеты и правила их валидации, форматы и типы запросов c ответами, названия методов, возможные ошибки и статусы. Зафиксировали статусы состояния заявки, которые планируем получать, например: «принято в обработку», «идет скоринг», «отказано в займе», «одобрение» и т. д.

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

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

У партнера есть API — прогоняем по чек-листу

Раньше мы получали спецификацию партнера и задавали по ней вопросы на ходу. Часто забывали уточнить что-нибудь важное, а потом это важное всплывало на финальных этапах разработки и тестирования, когда исправлять и переписывать становилось особенно затратно. Как-то под конец интеграции с одним партнером выяснилось, что он будет передавать статусы займов по API с задержкой в несколько дней. Для нас это недопустимо. От партнерства пришлось отказаться.

Сейчас. Мы написали чек-лист для оценки API и процессов, которые оно обслуживает. В чек-листе собрали вопросы, на которые нужно обязательно получить ответы. Сначала наш менеджер ищет ответы в спецификации. Если не находит, адресует вопросы партнеру.

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

Мы постоянно пополняем чек-лист, когда сталкиваемся с новыми ситуациями. Чем детальнее чек-лист, тем ниже риск пропустить ошибки в разработку.

Фрагмент чек-листа для оценки API

Словарик терминов

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

Например, с одним МФО мы по-разному трактовали первичных и повторных клиентов. Для нас первичный клиент — это клиент, анкета которого впервые попала в базу МФО через Finspin, а повторный клиент уже был в базе. Партнер считал повторными клиентов по количеству выданных займов: повторные получили два займа и пришли за третьим. Такая терминологическая путаница могла привести к нестыковкам при финансовых сверках.

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

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

Уточняем термин “Одобрение”

Сначала бизнес, потом разработка

Раньше были случаи, когда мы начинали работу с потенциальным партнером со спецификации. Наш менеджер получал спецификацию, внимательно ее штудировал, уточнял у партнера детали для интеграции, обсуждали спорные моменты с разработчиками. А потом от руководства прилетало сообщение: «Отбой, интеграция отменяется, не договорились по условиям». Сотрудники впустую потратили время.

Когда передумали, а работа сделана

Сейчас действует железное правило: менеджер приступает к изучению спецификации только тогда, когда получает от руководства однозначное решение об интеграции.

Готовность к интеграции: урлы, реквизиты, окружение

Раньше первое обращение к API партнера происходило во время тестирования нашего приложения, с dev серверов. Часто первые запросы получали ошибки на этапе установки соединения: can not connect to server или просто таймаут. Самые популярные причины:

неправильные названия методов (опечатались или перепутали),
неверный домен,
ошибочные реквизиты подключения,
не добавили в white-лист IP наших серверов.

На исправление таких мелких ошибок уходили часы, потому что они шли друг за другом: пока не исправишь одну, не увидишь следующую.

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

ограничения по нагрузке на сервис,
количество запросов в единицу времени,
реквизиты подключения,
white-list по ip-адресам,
валидация SSL-сертификата,
требования к шифрованию трафика,
наличие особых заголовков в запросах,
наличие тестового сервера с API или возможности отправлять тестовые запросы на боевой сервер

Если есть тестовое API, мы обязательно узнаем, в чем разница при обращении к боевому серверу и тестовому. Мы учитываем различия при построении запросов от нашего приложения к партнерам в dev и prod окружении. Такие меры помогают нам понять, готова ли системы к нашим запросам или нужны донастройки.

Отправка запросов в API вручную

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

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

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

На этапе ручного прогона вскрывается 80% неточностей в документации. Мы описываем ошибки и передаем партнеру. Партнер либо устраняет неточности у себя, либо дорабатывает спецификацию. В результате к моменту старта работы над кодом разработчики получают рабочую документацию.

Самые популярные расхождения:

неверный формат запросов, обещают принимать json, оказалась нужна form-data;
ошибки в названиях полей, которые надо передать в запросе;
ошибки в форматах полей;
не указаны или указаны ошибочно правила валидации полей;
могут быть вообще забыты некоторые поля;
отсутствуют или отличаются от фактических описания формата ответа метода;
ошибочные отметки об обязательности полей — “звездочки” могут стоять там, где поле по факту не обязательное, и наоборот;
часто не задокументированы все состояния и статусы, в которых может находиться объект;
расхождения между ожидаемыми и получаемыми состояниями объектов. Например, в какой-то момент ждем, что заявка должна находиться в состоянии X — а по API по факту получаем Y.

Рецепт счастья: как избежать ошибок при интеграции по API

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

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

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

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

Заведите чек-лист для уточнения особенностей обращения к API партнера: реквизиты подключения, white-list, валидация SSL-сертификата, требования к шифрованию трафика и т. д. Сверьтесь по чек-листу как можно раньше, чтобы избежать пробуксовок на финальных этапах.

Получили спецификацию — не спешите сразу писать код. Сперва вручную прогоните процесс через API-клиент, например через Postman. Так вы на раннем этапе и небольшими ресурсами найдете ошибки в спецификации. А они будут.

Источник

После обновления типовой конфигурации 1С:ЗУП на релиз Зарплата и управление персоналом КОРП, редакция 3.1 (3.1.18.337) при очередном обменен в рамках типой интеграции с 1С:Документооборот вылезла следующая ошибка:

DMGetChangesRequest

{ОбщийМодуль.ИнтеграцияС1СДокументооборотОбмен.Модуль(428)}: Поле объекта не обнаружено (skipMessages)

Фрагмент чек-листа для оценки API

Словарик терминов

Уточняем термин “Одобрение”

Сначала бизнес, потом разработка

Когда передумали, а работа сделана

Готовность к интеграции: урлы, реквизиты, окружение

неправильные названия методов (опечатались или перепутали),
неверный домен,
ошибочные реквизиты подключения,
не добавили в white-лист IP наших серверов.

ограничения по нагрузке на сервис,
количество запросов в единицу времени,
реквизиты подключения,
white-list по ip-адресам,
валидация SSL-сертификата,
требования к шифрованию трафика,
наличие особых заголовков в запросах,
наличие тестового сервера с API или возможности отправлять тестовые запросы на боевой сервер

Отправка запросов в API вручную

Самые популярные расхождения:

неверный формат запросов, обещают принимать json, оказалась нужна form-data;
ошибки в названиях полей, которые надо передать в запросе;
ошибки в форматах полей;
не указаны или указаны ошибочно правила валидации полей;
могут быть вообще забыты некоторые поля;
отсутствуют или отличаются от фактических описания формата ответа метода;
ошибочные отметки об обязательности полей — “звездочки” могут стоять там, где поле по факту не обязательное, и наоборот;
часто не задокументированы все состояния и статусы, в которых может находиться объект;
расхождения между ожидаемыми и получаемыми состояниями объектов. Например, в какой-то момент ждем, что заявка должна находиться в состоянии X — а по API по факту получаем Y.

Рецепт счастья: как избежать ошибок при интеграции по API

Источник

DMGetChangesRequest

{ОбщийМодуль.ИнтеграцияС1СДокументооборотОбмен.Модуль(428)}: Поле объекта не обнаружено (skipMessages)

Окно записи журнала 1С с ошибкой

Поиск в тексте модуля по указанной в сообщении об ошибке строке привел к следующей конструкции:

ПропускаемыеСообщения = Запрос.skipMessages; // СписокXDTO

Чуть выше была так же обнаружена новая вставка по сравнению с предыдущими релизами:

ПоддерживаетсяПропускСообщенийСОшибкой = ИнтеграцияС1СДокументооборот.ДоступенФункционалВерсииСервиса(«2.1.28.12.CORP»);

То есть фирма 1С обновила программный интерфейс web-сервиса интеграции с 1С:Документооборт и в номом релизе 1С:ЗУП решила его использовать. Однако похоже забыла поставить проверку на то используется ли в конкретном случае новая версия 1С:Документооборт. В нашем случае как раз используется конфигурация 1С:Документооборт релиза 2.1.10.2 и поэтому при обращении к новой фиче происходит ошибка, так как ее просто нет в старой версии сервиса.

Приступаем к исправлению

Добавляем общий модуль ИнтеграцияС1СДокументооборотОбмен в расширение. Делаем вызов исправленной процедуры ПолучитьДанные.

В ней перенесем обращение к новому свойству объекта сервиса в условие с проверкой а доступен ли новый функционал:

&Вместо(«ПолучитьДанные»)

Процедура маг_ПолучитьДанные()

Попытка

Пока Не ПрочитаныВсеСообщения Цикл

Запрос = ИнтеграцияС1СДокументооборот.СоздатьОбъект(Прокси, «DMGetChangesRequest»);

Запрос.lastMessageID = НомерПоследнегоСообщения;

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

//ПропускаемыеСообщения = Запрос.skipMessages; // СписокXDTO

Если ПоддерживаетсяПропускСообщенийСОшибкой Тогда

//++Наша вставка

ПропускаемыеСообщения = Запрос.skipMessages; // СписокXDTO

//—Наша вставка

Запрос.lastMessageWasReceived = СообщениеБылоПринято;

После этого исправления все заработало как надо. Обмен с интегрированной системой стал проходить без ошибок.

Источник

Настройка интеграции магазина и портала Битрикс24

Интегрируем магазин с Битрикс24

Если у вас уже есть CRM от «1С-Битрикс», то вы можете сразу настроить интеграцию на специально для этого созданной странице административного режима Магазин > CRM:

Внимание! Если у вас нет CRM, то вы можете создать аккаунт в «Битрикс24», нажав на этой же странице кнопку Получить CRM в Битрикс24 (бесплатно).

Настройка интеграции

Нажмите кнопку Настроить интеграцию с CRM. В полях

формы настройки

укажите адрес корпоративного портала или «Битрикс24», а также логин и пароль администратора CRM. Уточните

тип протокола

.

В процессе настройки интеграции автоматически создается специальный пользователь (с особыми правами), из-под которого CRM обращается к интернет магазину. Снимите галочку в

опции

Автоматически создать пользователя и настроить права доступа (рекомендуется), чтобы самостоятельно ввести логин и пароль этого пользователя.

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

Нажмите кнопку Настроить параметры и импортировать данные. Перейдем к интеграции со стороны CRM, где Мастер настройки автоматически возьмет все

основные данные

. Переходим к

третьему шагу

настройки.

Внимание! Если система выдает ошибку соединения, в поле Адрес интернет-магазина укажите его ip-адрес и не забудьте про порт.

Укажите параметры

первичного импорта

Внимание! Данные параметры будут применены для первого импорта, для регулярного импорта настройки будут производиться на пятом шаге Мастера.

из интернет-магазина:

Выбрать данные за последние (дней) — промежуток времени, за который следует импортировать данные в CRM;
Вероятность сделок (%) — вероятность успешного завершения

сделок

Сделки являются конечной целью и желаемым результатом работы с контактами и фирмами.
Подробнее в курсе Пользователь корпоративного портала (дизайн Lite)

из первичного импорта;
Ответственный для новых сделок — укажите сотрудника в структуре компании, ответственного за сделки, импортированные из магазина;
Сделки доступны для всех — оставьте галочку, если хотите, чтобы сделки по умолчанию были

открытыми

О том, как влияет, открыта сделка или нет, на доступ к ней, читайте в курсе Пользователь корпоративного портала (дизайн Lite).

.

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

статистика

по первому импорту.

Примечание: если заказ в интернет-магазине был оформлен на физическое лицо, то в CRM автоматически создастся контакт, если на юридическое — компания.

Переходим к настройкам параметров

регулярной синхронизации CRM

с интернет-магазином. Отметим те поля, которые еще не рассматривались выше:

Частота синхронизации — укажите в минутах промежуток между синхронизациями;
Направлять уведомления в группу — выберите группу, в которую направятся сообщения об импорте новых сделок.

Нажмите Далее, появится окно с информацией

об успешной синхронизации

.

Вы можете посмотреть список интеграций и

статистику

по каждой из них на странице административной части Магазин > CRM:

Важно! Интеграция будет невозможна без наличия

английского языка в административном интерфейсе

Управление языками интерфейса системы выполняется на странице Языки интерфейса (Настройки > Настройки продукта > Языковые параметры > Языки интерфейса).
Подробнее…

интернет-магазина и CRM. Это замечание не касается CRM облачного «Битрикс24».

Назад в раздел

Источник