Ошибка передачи данных webbudget getdownloadedhash

25 июня 2023 года, воскресенье

Сахалинская область

Специализированный информационный сайт

«Государственный Заказ
Сахалинской области»

Частые вопросы

Общие вопросы

1. Каким образом необходимо осуществлять (формировать) закупку с помощью РИС (поэтапно)?

Решение: документы, последовательно формируемые в системе, зависят от способа определения поставщика. Подробная схема указана в памятке «Какие документы создаются в системе».

2. В фильтрах не отображаются документы, связанные с 2017 и последующими годами.

Решение: для корректного отображения всех документов в списках нужно установить период отбора документов с 01.01.2016г по 31.12.2017г, как указано на рисунке, и обновить список документов:

3. О видимости колонки «Номер позиции каталога (ID)»

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

4. Как отразить в документах планирования закупку, которая будет проводится в конце текущего года, а исполнение и оплату заключенного контракта планируется произвести в следующем году (за счет средств следующего года)?

Решение: Памятка. Закупки текущего года за счет средств следующего года 

План-график

Вопросы, касающиеся внесения изменений в план-график по результатам экономии:

Вариант 1. В результате проведения закупки образовалась экономия. Как внести изменение в план-график и воспользоваться образовашейся экономией для проведения другой закупки?

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

Решение:

В общем случае схема будет следующей:

1. Формируется изменение лота ПГ, где уточняются планируемые платежи (алгоритм действий подробно описан в памятке «Изменение лота плана-графика по результатам экономии»);

2. Формируется изменение связанной закупки плана закупок, где также уменьшается сумма;

3. Сумма экономии добавляется к другой закупке или формируется новая;

4. Формируется новый лот плана-графика на сумму экономии или сумма добавляется к уже имеющемуся. 

Схема является примерной и может отличаться для каждого конкретного случая.

 Заявка на закупку

1. После заполнения Заявки на закупку и нажатия кнопки «Сохранить» появляется протокол контроля данных со следующим сообщением: «Сохранение невозможно. Причина: данные были изменены в другом сеансе работы (см. Журнал событий)» 

Решение: причина возникновения ошибки в некорректном заполнении документа Заявка на закупку.

Рекомендуемая последовательность заполнения документов в РИС:

1. Заполнение всех необходимых полей документа Заявка на закупку;

2. Сохранение документа по кнопке «Сохранить»;

3. Прикрепление документации с помощью специального окна, вызываемого нажатием кнопки «Оправдательные документы»;

4. Отправка Заявки на закупку по маршруту.

Зачастую ошибка указанная выше появляеться в случае, когда выполняется 1 и 3 действие, а потом 2.

* Кнопка «Сохранить» сохраняет только данные, заполненные на полях формы Заявки на закупку, и никак не влияет на сохранение прикрепеленых файлов к Заявке на закупку!!!

** Прикрепеление файлов к документу осуществляется с помощью специального окна, вызываемого нажатием кнопки «Оправдательные документы». После прикрепления файлов сохранять весь документ по кнопке «Сохранить» с целью сохранения прикрепленных файлов не имеет смысла, т.к. файлы уже прикреплены к документу.

2. Заявку на закупку вернули на доработку по причине неверного ОКПД2. Как изменить код классификации продукции.

Контракт

Ошибки, возникающие при попытке отправить Контракт в ЕИС:

1. Ошибка (обязательно устранение): Непредвиденная ошибка в ходе обработки. UE. Для закупки, указанной в информации о контракте, отсутствует действующий протокол, содержащий результаты определения поставщика, либо закупка не находится на этапах «Работа комиссии», «Определение поставщика завершено»

Решение:

1. Проверить в ЕИС в Извещении на вкладке «Результаты определения поставщика» наличие протокола определения поставщика. Если протокол отсутствует, связаться со специалистом, размещавшим закупку, и уточнить причины отсутствия протокола.

2. Если протокол в ЕИС опубликован, то проверить в ЕИС в Извещении на вкладке «Общая информация» в разделе «Общая информация о закупке» поле «Этап закупки«. Если в этом поле НЕ указан этап «Работа комиссии» или «Определение поставщика завершено», связаться со специалистом, размещавшим закупку, и, объяснив ситуацию, попросить зайти в Личный кабинет ЕИС и вручную завершить определение поставщика (так как это действие не выполняется в ЕИС в автоматическом режиме, несмотря на то, что протоколы и информация о заключенном на ЭТП контракте подгружается и размещается в ЕИС автоматически).

3. После размещения протокола определения поставщика и завершения определения поставщика повторить отправку контракта — документ поступит в ЕИС.

2. Ошибка (обязательно устранение): Непредвиденная ошибка в ходе обработки. Непредвиденная ошибка в интеграционном адаптере РГК. Банковская гарантия с номером 099МБ-17-г должна находится в статусе «Опубликована» а также должна быть выдана в обеспечение исполнения контракта (поле «Обеспечение» в БГ имеет значение «исполнение контракта»).

Решение:

1. В карточке Контракта на закладке «Дополнительные данные» в поле «Номер реестровой записи реестра банковских гарантий» некорректно указан номер банковской гарантии. Так, в приведенном выше примере был указан обычный номер 099ЬМ-17-г вместо 20-тизначного реестрового номера. Аналогичная ошибка может появляться в случае опечатки в реестровом номере (например, вместо буквы О указана цифра 0 и т.п.).

Во избежание ошибок при заполнении карточки Контракта рекомендуем копировать реестровые номера гарантий из Реестра банковских гарантий (Единая информационная система) и вставлять их в поле «Номер реестровой записи реестра банковских гарантий«.

3. Ошибка (обязательно устранение): Непредвиденная ошибка в ходе обработки. Непредвиденная ошибка в интеграционном адаптере РГК. Прикрепление файла в блоке «Отсканированная копия контракта или электронный документ» обязательно.

Решение:

В карточке документа «Контракт» нажать кнопку «Оправдательные документы», отменить галочкой приложенный контракт и нажать кнопку «Редактировать комментарий». Откроется форма редактирования данных вложенного документа (см. рисунок ниже). В поле «Тип файла» путем выбора из справочника установить тип документа «Отсканированная копия контракта или электронный контракт» (цифра 1). Так же установить галочку в поле «Размещение файла в ЕИС» (цифра 2). Указанные изменения следует сохранить.

Если отсканированная копия контракта отсутствует — прикрепить файл, соблюдая указанные выше рекомендации (в части заполнения полей «Тип файла» и «Размещение файла в ЕИС»).

Электронно-цифровая подпись

Ошибки, возникающие при попытке подписать Заявку на закупку ЭЦП:

1. «Пользователь не включен ни в один из уровней ЭП необходимых по варианту работы с ЭП»

Решение: Для реализации возможности отправки заявок на закупку в РИС «Web-Торги-КС» необходимо настроить учетную запись подписанта по варианту работы с электронной цифровой подписью (ЭП).

Для настройки работы учетной записи заказчику необходимо направить на адрес электронной почты a.susoev@sakhalin.gov.ru (предварительно позвонив по телефону (4242) 67-15-07 следующую информацию:

1. В случае необходимости подписания заявок на закупку ЭП руководителя:

— Наименование заказчика;

— ИНН заказчика;

— Ф.И.О. руководителя;

— Распорядительный документ о назначении на должность руководителя;

— Логин учетной записи, под которой зарегистрирован руководитель в ПК «Web-Торги-КС».

2. В случае необходимости подписания заявок на закупку ЭП специалиста, уполномоченного  подписывать заявки на закупку:

— Скан-копию внутреннего распорядительного документа,  уполномочивающего специалиста организации подписывать заявки на закупку;

— Наименование заказчика;

— ИНН заказчика;

— Ф.И.О. уполномоченного специалиста;

— Логин учетной записи, под которой зарегистрирован уполномоченный специалист в ПК «Web-Торги-КС».

* Подписание заявки на закупку должно осуществляться под учетной записью и ЭП одного и того же пользователя

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

2. «Не удалось открыть хранилище сертификатов. Отказано в доступе. (00000005)»

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

3. «Ошибка передачи данных (WebBudget.getdownloadedhash)»

Решение: данная ошибка возникает в случае, когда один или несколько прикрепленных файлов имеют в наименовании служебные символы (например: !, ?, &, % и т.п.). Для успешного подписания документов рекомендуется удалить файл, изменить его наименование (используя только буквы, цифры, знаки подчеркивания), прикрепить заново и снова подписать документ ЭЦП.

Отчет об исполнении контракта 

Ошибки, возникающие при попытке отправить Отчет по исполнению контракта в ЕИС:

1. Ошибка (обязательно устранение): Некорректные данные. IDE. nested exception is: javax.ejb.EJBException: See nested exception; nested exception is: org.hibernate.exception.ConstraintViolationException: could not execute statement javax.ejb.EJBTransactionRolledbackException: nested exception is: javax.ejb.EJBException

Решение: исправление проблемы приема документов, отправленных из РИС в ЕИС, ожидается в версии ЕИС 7.1. До выхода версии ЕИС 7.1 отчеты по исполнению контракта следует заполнять в ЕИС.

Финансовый контроль

Уважаемые региональные заказчики!

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

670-481, 670-482, 670-483, 670-484, 670-485, 670-486, 670-488

Источник

Общие вопросы

1. Каким образом необходимо осуществлять (формировать) закупку с помощью РИС (поэтапно)?

Решение: документы, последовательно формируемые в системе, зависят от способа определения поставщика. Подробная схема указана в памятке «Какие документы создаются в системе».

2. В фильтрах не отображаются документы, связанные с 2017 и последующими годами.

Решение: для корректного отображения всех документов в списках нужно установить период отбора документов с 01.01.2016г по 31.12.2017г, как указано на рисунке, и обновить список документов:

3. О видимости колонки «Номер позиции каталога ( ID )»

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

4. Как отразить в документах планирования закупку, которая будет проводится в конце текущего года, а исполнение и оплату заключенного контракта планируется произвести в следующем году (за счет средств следующего года)?

План-график

Вопросы, касающиеся внесения изменений в план-график по результатам экономии:

Вариант 1. В результате проведения закупки образовалась экономия. Как внести изменение в план-график и воспользоваться образовашейся экономией для проведения другой закупки?

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

1. Формируется изменение лота ПГ, где уточняются планируемые платежи (алгоритм действий подробно описан в памятке «Изменение лота плана-графика по результатам экономии» );

2. Формируется изменение связанной закупки плана закупок, где также уменьшается сумма;

3. Сумма экономии добавляется к другой закупке или формируется новая;

4. Формируется новый лот плана-графика на сумму экономии или сумма добавляется к уже имеющемуся.

Заявка на закупку

1. После заполнения Заявки на закупку и нажатия кнопки «Сохранить» появляется протокол контроля данных со следующим сообщением: » Сохранение невозможно. Причина: данные были изменены в другом сеансе работы (см. Журнал событий)»

Контракт

Ошибки, возникающие при попытке отправить Контракт в ЕИС:

1. Ошибка (обязательно устранение): Непредвиденная ошибка в ходе обработки. UE. Для закупки, указанной в информации о контракте, отсутствует действующий протокол, содержащий результаты определения поставщика, либо закупка не находится на этапах «Работа комиссии», «Определение поставщика завершено»

1. Проверить в ЕИС в Извещении на вкладке «Результаты определения поставщика» наличие протокола определения поставщика. Если протокол отсутствует, связаться со специалистом, размещавшим закупку, и уточнить причины отсутствия протокола.

2. Если протокол в ЕИС опубликован, то проверить в ЕИС в Извещении на вкладке «Общая информация» в разделе «Общая информация о закупке» поле «Этап закупки «. Если в этом поле НЕ указан этап «Работа комиссии» или «Определение поставщика завершено», связаться со специалистом, размещавшим закупку, и, объяснив ситуацию, попросить зайти в Личный кабинет ЕИС и вручную завершить определение поставщика (так как это действие не выполняется в ЕИС в автоматическом режиме, несмотря на то, что протоколы и информация о заключенном на ЭТП контракте подгружается и размещается в ЕИС автоматически).

3. После размещения протокола определения поставщика и завершения определения поставщика повторить отправку контракта — документ поступит в ЕИС.

2. Ошибка (обязательно устранение): Непредвиденная ошибка в ходе обработки. Непредвиденная ошибка в интеграционном адаптере РГК. Банковская гарантия с номером 099МБ-17-г должна находится в статусе «Опубликована» а также должна быть выдана в обеспечение исполнения контракта (поле «Обеспечение» в БГ имеет значение «исполнение контракта»).

1. В карточке Контракта на закладке «Дополнительные данные» в поле » Номер реестровой записи реестра банковских гарантий » некорректно указан номер банковской гарантии. Так, в приведенном выше примере был указан обычный номер 099ЬМ-17-г вместо 20-тизначного реестрового номера. Аналогичная ошибка может появляться в случае опечатки в реестровом номере (например, вместо буквы О указана цифра 0 и т.п.).

Во избежание ошибок при заполнении карточки Контракта рекомендуем копировать реестровые номера гарантий из Реестра банковских гарантий (Единая информационная система) и вставлять их в поле » Номер реестровой записи реестра банковских гарантий «.

3. Ошибка (обязательно устранение): Непредвиденная ошибка в ходе обработки. Непредвиденная ошибка в интеграционном адаптере РГК. Прикрепление файла в блоке «Отсканированная копия контракта или электронный документ» обязательно.

В карточке документа «Контракт» нажать кнопку «Оправдательные документы», отменить галочкой приложенный контракт и нажать кнопку «Редактировать комментарий». Откроется форма редактирования данных вложенного документа (см. рисунок ниже). В поле «Тип файла» путем выбора из справочника установить тип документа «Отсканированная копия контракта или электронный контракт» (цифра 1) . Так же установить галочку в поле «Размещение файла в ЕИС» (цифра 2). Указанные изменения следует сохранить.

Если отсканированная копия контракта отсутствует — прикрепить файл, соблюдая указанные выше рекомендации (в части заполнения полей «Тип файла» и «Размещение файла в ЕИС»).

Электронно-цифровая подпись

Ошибки, возникающие при попытке подписать Заявку на закупку ЭЦП:

1. «Пользователь не включен ни в один из уровней ЭП необходимых по варианту работы с ЭП»

Решение: Для реализации возможности отправки заявок на закупку в РИС «Web-Торги-КС» необходимо настроить учетную запись подписанта по варианту работы с электронной цифровой подписью (ЭП).

Для настройки работы учетной записи заказчику необходимо направить на адрес электронной почты a.susoev@admsakhalin.ru (предварительно позвонив по телефону (4242) 67-15-07 следующую информацию:

1. В случае необходимости подписания заявок на закупку ЭП руководителя:

— Распорядительный документ о назначении на должность руководителя;

— Логин учетной записи, под которой зарегистрирован руководитель в ПК «Web-Торги-КС».

2. В случае необходимости подписания заявок на закупку ЭП специалиста, уполномоченного подписывать заявки на закупку:

— Скан-копию внутреннего распорядительного документа, уполномочивающего специалиста организации подписывать заявки на закупку;

— Ф.И.О. уполномоченного специалиста;

— Логин учетной записи, под которой зарегистрирован уполномоченный специалист в ПК «Web-Торги-КС».

* Подписание заявки на закупку должно осуществляться под учетной записью и ЭП одного и того же пользователя

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

2. «Не удалось открыть хранилище сертификатов. Отказано в доступе. (00000005)»

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

3. «Ошибка передачи данных (WebBudget.getdownloadedhash)»

Решение: данная ошибка возникает в случае, когда один или несколько прикрепленных файлов имеют в наименовании служебные символы (например: !, ?, &, % и т.п.). Для успешного подписания документов рекомендуется удалить файл, изменить его наименование (используя только буквы, цифры, знаки подчеркивания), прикрепить заново и снова подписать документ ЭЦП.

Отчет об исполнении контракта

Ошибки, возникающие при попытке отправить Отчет по исполнению контракта в ЕИС:

1. Ошибка (обязательно устранение): Некорректные данные. IDE. nested exception is: javax.ejb.EJBException: See nested exception; nested exception is: org.hibernate.exception.ConstraintViolationException: could not execute statement javax.ejb.EJBTransactionRolledbackException: nested exception is: javax.ejb.EJBException

Решение: и справление проблемы приема документов, отправленных из РИС в ЕИС, ожидается в версии ЕИС 7.1 . До выхода версии ЕИС 7.1 отчеты по исполнению контракта следует заполнять в ЕИС.

Уважаемые региональные заказчики!

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

670-481, 670-482, 670-483, 670-484, 670-485, 670-486, 670-488

Как работать с ошибками бизнес-логики через HTTP

Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры «дергают» бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.

За 7 лет я как поддерживал множество legacy API, так и разрабатывал c нуля. И я поработал, наверное, с большинством стратегий по возвращению ошибок, но каждая из них создавала дискомфорт в той или иной мере. В последнее время я нащупал оптимальный вариант, о котором и хочу рассказать, но с начала расскажу о двух наиболее популярных вариантах.

№1: HTTP статусы

Если почитать апологетов REST, то для кодов ошибок надо использовать HTTP статусы, а текст ошибки отдавать в теле или в специальном заголовке. Например:

Если у вас примитивная бизнес-логика или API из 5 url, то в принципе это нормальный подход. Однако как-только бизнес-логика станет сложнее, то начнется ряд проблем.

Http статусы предназначались для описания ошибок при передаче данных, а про логику вашего приложения никто не думал. Статусов явно не хватает для описания всего разнообразия ошибок в вашем проекте, да они и не были для этого предназначены. И тут начинается натягивание «совы на глобус»: все начинают спорить, какой статус ошибки дать в том или ином случае. Пример: Есть API для task manager. Какой статус надо вернуть в случае, если пользователь хочет взять задачу, а ее уже взял в работу другой пользователь? Ссылка на http статусы. И таких проблемных примеров можно придумать много.

REST скорее концепция, чем формат общения из чего следует неоднозначность использования статусов. Разработчики используют статусы как им заблагорассудится. Например, некоторые API при отсутствии сущности возвращают 404 и текст ошибки, а некоторые 200 и пустое тело.

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

Когда бизнес-логика приложения усложняется, начинают делать как-то так:

Из-за ограниченности http статусов разработчики начинают вводить “свои” коды ошибок для каждого статуса и передавать их в теле ответа. Другими словами, пользователю API приходится писать нечто подобное:

Из-за этого ветвление клиентского кода начинает стремительно расти: множество http статусов и множество кодов в самом сообщении. Для каждого ошибочного http статуса необходимо проверить наличие кодов ошибок в теле сообщения. От комбинаторного взрыва начинает конкретно пухнуть башка! А значит обработку ошибок скорее всего сведут к сообщению типа “Произошла ошибка” или к молчаливому некорректному поведению.

Многие системы мониторинга сервисов привязываются к http статусам, но это не помогает в мониторинге, если статусы используются для описания ошибок бизнес логики. Например, у нас резкий всплеск ошибок 429 на графике. Это началась DDOS атака, или кто-то из разработчиков выбрал неудачный статус?

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

№2: На все 200

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

На самом деле формат зависит от вас или от выбранной библиотеки для реализации коммуникации, например JSON-API.

Звучит здорово, мы теперь отвязались от http статусов и можем спокойно ввести свои коды ошибок. У нас больше нет проблемы “впихнуть невпихуемое”. Выбор нового типа ошибки не вызывает споров, а сводится просто к введению нового числового номера (например, последовательно) или строковой константы. Например:

Клиентские разработчики просто основываясь на кодах ошибок могут создать классы/типы ошибок и притом не бояться, что сервер вернет один и тот же код для разных типов ошибок (из-за бедности http статусов).

Обработка ошибок становится менее ветвящейся, множество http статусов превратились в два: 200 и все остальные (ошибки транспорта).

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

Но неудобства тоже есть:

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

При использовании средств отладки (Chrome DevTools) или других подобных инструментов вы не сможете быстро найти ошибочные запросы бизнес логики, придется обязательно заглянуть в тело ответа (ведь всегда 200)

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

В некоторых случаях данный подход вырождается в RPC, то есть по сути вообще отказываются от использования url и шлют все на один url методом POST, а в теле сообщения передают все параметры. Мне кажется это не правильным, ведь url это прекрасный именованный namespace, зачем от этого отказываться, не понятно?! Кроме того, RPC создает проблемы:

нельзя кэшировать по http GET запросы, так как замешали чтение и запись в один метод POST

нельзя делать повторы для неудавшихся GET запросов (на backend) на реверс-прокси (например, nginx) по указанной выше причине

имеются проблемы с документированием – swagger и ApiDoc не подходят, а удобных аналогов я не нашел

Итог: Для сложной бизнес-логики с большим количеством типов ошибок такой подход лучше, чем расплывчатый REST, не зря в проектах c “разухабистой” бизнес-логикой часто именно такой подход и используют.

№3: Смешанный

Возьмем лучшее от двух миров. Мы выберем один http статус, например, 400 или 422 для всех ошибок бизнес-логики, а в теле ответа будем указывать код ошибки или строковую константу. Например:

400 – ошибка бизнес логики

остальное ошибки в транспорте

Тело ответа для удачного запроса у нас имеет произвольную структуру, а вот для ошибки есть четкая схема. Мы избавляемся от избыточности данных (поле ошибки/данных) благодаря использованию http статуса в сравнении со вторым вариантом. Клиентский код упрощается в плане обработки ошибки (в сравнении с первым вариантом). Также мы снижаем его вложенность за счет использования отдельного http статуса для ошибок бизнес логики (в сравнении со вторым вариантом).

Мы можем расширять объект ошибки для детализации проблемы, если хотим. С мониторингом все как во втором варианте, дописывать парсинг придется, но и риска “стрельбы” некорректными alert нету. Для документирования можем спокойно использовать Swagger и ApiDoc. При этом сохраняется удобство использования инструментов разработчика, таких как Chrome DevTools, Postman, Talend API.

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

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

P.S. Иногда ошибки любят передавать массивом

Но это актуально в основном в двух случаях:

Когда наш API выступает в роли сервиса без фронтенда (нет сайта/приложения). Например, сервис платежей.

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

В противном случае нет особого смысла закладываться сразу на массив ошибок, потому что базовая валидация данных должна происходить на клиенте, зато код упрощается как на сервере, так и на клиенте. А user-experience хакеров, лезущих напрямую в наше API, не должен нас волновать?HTTP

Что такое ошибка 502 Bad Gateway и как ее исправить

Загружая страницу, браузер отправляет кучу запросов другим серверам. Они обрабатывают все запросы, затем возвращают код ответа HTTP с определенным результатом. Если в процессе этого возникнет какой-то сбой, на экране браузера отобразится ошибка. И одна из таких ошибок – 502 Bad Gateway. Я расскажу, что она означает, по каким причинам выходит, а еще опишу способы ее устранения.

Что означает ошибка 502 Bad Gateway

Ошибки, принадлежащие серии 5xx, означают появление проблем на стороне сервера. Если взять конкретно ошибку 502 Bad Gateway, то ее появление будет означать получение неправильного ответа сервера. «Виновниками» в такой ситуации обычно являются прокси, DNS или хостинг-серверы.

Что делать, если вы пользователь

Ошибка 502 Bad Gateway может появиться на любом сайте. Пользователю для начала следует проверить, не является ли причиной проблемы какие-то неполадки с его стороны. Сделать это можно указанными ниже способами.

Перезагрузить страницу

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

Проверить подключение к интернету

Стоит проверить работу модема и попробовать загрузить другие страницы. Убедитесь, что подключение к интернету стабильное. Еще вариант – перезапустить маршрутизатор и попробовать снова загрузить проблемный сайт.

Очистить кэш и cookies

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

Для любого браузера актуально – зайти в историю просмотров и найти ссылку «Очистить историю». В новом окне отметить пункты с кэшем и cookies, затем подтвердить действие. Как только данные будут удалены, надо вновь попробовать загрузить страницу. Не помогло? Идем дальше!

Очистить кэш DNS

Допустимо, что в кэше установлено неправильное значение IP-адреса. Для таких случаев можно использовать сброс DNS кэша. В ОС Windows необходимо открыть инструмент «Командная строка» (вводим в поисковую строку название программы и выбираем запуск от имени администратора).

Далее следует ввести вот такую команду и активировать ее нажатием на клавишу Enter:

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

Для Linux действие примерно схоже, но команда выглядит иначе. Открываю утилиту «Терминал» и ввожу в поле вот такой запрос:

Для других дистрибутивов:

Попробовать зайти с другого браузера

Проблема 502 Bad Gateway может быть актуальна и для конкретного браузера. Если у вас на компьютере есть другой интернет-обозреватель, попробуйте открыть сайт через него.

Отключить плагины и расширения

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

Зайти на страницу позже

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

Читайте также

Что делать, если вы администратор сайта

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

Проверка журнала ошибок

Актуально в случаях, при которых ошибка 502 Bad Gateway появляется после внесения изменений или обновления. Определить это очень просто, нужно лишь проверить журнал ошибок. В CMS WordPress можно включить запись возникающих ошибок, добавив в файл wp-config.php вот такие строки:

После этого все записи начнут отображаться в файле debug.log. Храниться он будет в директории wp-content. Понадобится некоторое время, чтобы причины ошибок были записаны. Потом можно тщательно изучить записи и уже на основе их предпринимать конкретные изменения.

Проверка плагинов

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

Проверка сети CDN

Сети CDN и службы предотвращения DoS тоже могут влиять на работу сайта. Обычно виновник проблемы указывается на странице с кодом ошибки. Например, если под кодом 502 Bad Gateway есть строка cloudflare-nginx, значит, для исправления ошибки надо обратиться в службу поддержки CloudFlare. Можно отключить данный сервис, но потом придется долго ждать обновления DNS (это может занять несколько часов).

Ошибка 502 на виртуальном хостинге VPS/VDS

Ошибка 502 Bad Gateway возникает из-за превышения лимита трафика пользователей, «шалостей» бота, скачивания сайта или даже DoS‑атаки. Решение данной проблемы кроется в ограничениях памяти.

Запустить команду top

Данный запрос в терминале поможет установить наличие свободной памяти. Этим же способом можно проверить, работает ли Apache.

Посмотреть логи Apache и nginx

Обычно в этих логах отображается активность пользователей. Если есть что-то подозрительное, можно предпринять действия. К примеру, забанить определенные IP-адреса, настроить Fail2ban или подключить систему защиты от DoS-атак.

Если после этого количество запросов к серверу снизилось, необходимо перезапустить Apache.

Увеличить объем памяти

Бывает, что с логами все нормально, но памяти на обработку запросов все равно не хватает. Узнать об этом просто – при проверке командой top будет выдана ошибка OOM (out of memory). В таких случаях можно просто увеличить ее объем. Можно просто заказать другой тариф, в котором количество предоставляемой памяти больше. Подробнее об этом.

Проверить лимиты на php-cgi процессы

Если после проверки командой top показано, что свободной памяти еще достаточно, значит, на php-cgi процессы установлены лимиты. Для решения надо открыть конфигурационный файл Apache – httpd.conf, найти секцию модуля FastCGI (mod_fascgi или mod_fastcgid) и увеличить лимит.

Обратиться к службе технической поддержки

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

источники:

http://habr.com/ru/post/545524/

http://timeweb.com/ru/community/articles/chto-takoe-oshibka-502-bad-gateway-i-kak-ee-ispravit

Источник

У меня есть форма для редактирования администраторов сообщения.

В этой форме есть несколько переключателей. Каждый радиокнопка соответствует администратору aa post, поэтому идентификатор каждого переключателя является идентификатором администратора в таблице администраторов.

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

Для этого необходимо передать методу обновления идентификатор сообщения и идентификатор проверенного переключателя (администратора), а затем обновить только этот идентификатор администратора.

Я передаю идентификатор сообщения с успехом, но идентификатор администратора нет. Появляется синтаксическая ошибка, неожиданная ‘{‘.

Редактировать форму администраторов:

<form method="post" class="clearfix" action="{{route('admins.update', ['id' => $post->id], ['adminID' => $admin->id])}}" enctype="multipart/form-data">
    {{csrf_field()}}
    @foreach($administrators $admin)
          <div class="form-check">
            <input class="form-check-input" type="radio" name="radiobutton" id="{{$admin->id}}" value="">
            <label class="form-check-label" for="">
              {{$admin->first_name}}
            </label>
          </div>
    @endforeach
  <!-- below I have form fields like administrator name, email, etc -->
  </form>

//обновлять маршруты админов

Route::get('post/edit/{id}/admins',    [ 'uses' => 'AdminController@edit', 'as'=>'admins.edit']);
Route::post('post/update/{id}/admins', [ 'uses' => 'AdminController@update', 'as'=>'admins.update']);

//Контроллер администратора

class AdministratorController extends Controller
{
    public function edit($id)
    {
        $post = Post::find($id);
        $administrators = Administrator::where('post_id', $id)->get();


        return view('administrators.edit')
            ->with('post', $post)
            ->with('administrators', $administrators));
    }
    public function update(Request $request, $id, $adminID){



        $this->validate($request, [
            'name' => 'required|string',
            'email' => 'required|integer',
            '...' => '...',
        ]);
        $post = Post::find($id);
        $admin = Administrator::find($post->id);
        $administratorToUpdate = Administrator::find($adminID);



        $administratorToUpdate->name = $request->name;
        $administratorToUpdate->email = $request->email;





  



                       
  







        ....
        $administratorToUpdate->save();



}

//Модель администратора

   class Administrator extends Model
{
    protected $fillable = [
        'first_name', 'email', 'password', 'description', 'post_id'
    ];


    public function post(){
        return $this->belongsTo('AppPost');
    }
}

Источник

Ошибка при сохранении после редактирования категорий

Страницы 1

Чтобы отправить ответ, вы должны войти или зарегистрироваться

1 26.12.2018 17:15:59

  • Анна
  • Новый участник
  • Неактивен
  • Зарегистрирован: 10.12.2018
  • Сообщений: 3

Тема: Ошибка при сохранении после редактирования категорий

Доброго времени суток.

Уже несколько дней при редактировании категорий выскакивает ошибка ( Ошибка передачи данных. Повторите попытку) при попытке сохранить изменения.
Проблема только с категориями, изменения, внесенные в данные о товарах, сохраняются без проблем.
Подскажите пожалуйста в чем может быть причина? Заранее благодарю.

Повысить оценку Понизить оценку

2 Ответ от Polo Art 27.12.2018 12:58:48

  • Polo Art
  • Участник
  • Неактивен
  • Откуда: Егорьевск
  • Зарегистрирован: 13.12.2016
  • Сообщений: 368
  • Рейтинг: 30

Re: Ошибка при сохранении после редактирования категорий

Анна, здравствуйте!
Тут надо смотреть ответ сервера, что за ошибкой скрывается (скорее всего, 500), а дальше смотреть логи самого сервера, что именно вызывает ошибку.

Наверное, техподдержка поможет

3 Ответ от Анна 27.12.2018 22:17:30

  • Анна
  • Новый участник
  • Неактивен
  • Зарегистрирован: 10.12.2018
  • Сообщений: 3

Re: Ошибка при сохранении после редактирования категорий

Polo Art пишет:

Анна, здравствуйте!
Тут надо смотреть ответ сервера, что за ошибкой скрывается (скорее всего, 500), а дальше смотреть логи самого сервера, что именно вызывает ошибку.

Наверное, техподдержка поможет

Благодарю. Напишу в поддержку.

Повысить оценку Понизить оценку

4 Ответ от Закусило Александр 28.12.2018 18:08:12

  • Закусило Александр
  • Закусило Александр
  • Участник
  • Неактивен
  • Откуда: Краснодар
  • Зарегистрирован: 01.09.2014
  • Сообщений: 2,953
  • Рейтинг: 252

Re: Ошибка при сохранении после редактирования категорий

Управление->Настройки системы->Исправить структуру БД

Сообщений [ 4 ]

Страницы 1

Чтобы отправить ответ, вы должны войти или зарегистрироваться

Источник
 

Добрый день! Помогите пожалуйста с ТСД Сайфер лаб 8000. Прошила Cipher 8000/8001 — Прошивка и Генератор Приложений (G2-OG04), засунула в 1с розница 2,2 CipherLab8G2 — Компонента 1С 8.3 + SDK для подключения ТСД CipherLab к своим продуктам. Тест проходит. Но в момент выгрузки товара ошибка «При выгрузке данных в терминал сбора данных произошла ошибка: Ошибка передачи данных! Данные не переданы!»
 

Если драйвер встроенный в 1с то
При выгрузке данных в терминал сбора данных произошла ошибка: Ответ терминала NAK не соответствует ожидаемому!
 

Олег Плюснин

Администратор

Сообщений: 4455
Регистрация: 30.01.2017

#3

0

25.07.2018 13:43:56

Цитата
Наталья Бочкова написал:
засунула в 1с розница 2,2 CipherLab8G2

Однако на фото у Вас совсем старый драйвер, даже не под платформу 8, а скорее для 7.7. И естественно, что со стандартной обработкой он работать не будет.
В комплекте есть описание «Описание библиотеки ТСД для 1С.pdf». В ней пошагово как ставить. Правда, это описание для устаревшей компоненты под 8 платформу, но работать тоже будет. Новая компонента имеет в названии «G2»
 

Согласна, не тот скрин приложила. Спасибо за ответ. Скачала заново и переустановила драйвер и все ок…базу только надо создать) Вообще странно вчера 2 раза так делала…….
 

Бывает…
Взял на себя смелость изменить в Вашем посте неточность. Чипер пишется вот так — Chiper. В английском такого слова нет, а вот с французского переводится как воровать, стащить и т.д.
Название же компании, производящей ТСД, пишется несколько иначе — CipherLAB от слова Cipher (Сайфа) или по нашему — шифр, код, тайнопись. Полностью произносится как сайферлаб. Причем, Р там больше подразумевается, чем произносится.
 
 

Подскажите еще разок пожалуйста. При выгрузке номенклатуры в 1с Розница 2,2 не выгружается количество и цена. Где и что надо поправить, а то что-то научный перебор не помогает.

Прикрепленные файлы

  • 1.jpg (138.58 КБ)
  • 2.jpg (109.15 КБ)
 

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

1 тк тестю….но и с 1им, не получается…..

Прикрепленные файлы

  • 3.jpg (159.89 КБ)
 

Сергей_техподдержка

Администратор

Сообщений: 1189
Регистрация: 30.01.2017

#10

0

31.07.2018 16:07:43

На фото вижу цену, но без количества.
У Вас обработка неправильно работает.
Вызывайте 1С-программиста, пускай посмотрит и возможно подправит код. К терминалу это не имеет никакого отношения.
Источник

  • Ошибка передачи данных twain
  • Ошибка передачи данных 1102
  • Ошибка передачи 7101 kyocera
  • Ошибка передачи 4803 kyocera
  • Ошибка передачи 3101 kyocera при сканировании на почту