Deeptown12

Информация для тех кто хочет выгружать через API пригодится При передачи данных через ФГИС API Аршина, далее "API" мы столкнулись со следующими проблемами, решение который предложено ниже. Техническая часть формирования XML пакетов и отправки их на сервер. 1. Название нод в xml файле регистрозависимы. Это значит, название ноды (узла) OBJ не идентично Obj. Хотя стандарт XML допускает, что ноды OBJ=Obj=OBj, но API к этому относится очень нехорошо, поэтому названия нод должны быть полностью идентичны, как описаны в руководстве. 2. При формировании файла закодированного по стандарту Base64 из сформированного файла важно что бы этот файл не содержал символы CLRF (#$a#$D). Многие библиотеки кодирования в формат Base64 да и сам стандарт допускают использовать CLRF для переноса строк, но API нет. Если CLRF там присутствует API выдает ошибку связанную с неверным форматом Base64. Хотя по стандарту кодирования он верен и декодируется успешно многими сторонними утилитами. На этом факте мы потеряли очень много времени на разбирательстве. 3. Секретный ключ полученный для передачи данных тоже регистрозависим. Проблемы с записями на отправку, методы их решения. Сразу оговоримся, что мы посылаем завершенные работы, (калибровку в отправку не включаем). 1. Проверка № госреестра на соответствие в справочнике Утвержденных типов СИ. Проблему с неверно введеными номерами мы решили созданием справочника утвержденных типов и загрузкой через сервис api туда информации и сверкой № при отправке 2. Не соответсвие вида деятельности в справочниках (в том числе и исторических) с требованиями api. Решение частично приведены справочнике видов деятельности к тестовке api. Для проблемных записей (исторических и не сопоставленных) мы решили принудительно выставлять "Выполнение работпо обеспечению безопасных условий и охраны труда" иначе нужно переделывать множество старых поверочных работ. 3. Так как api проверяет записи на дублипрование целиком, мы столкнулись с проблемой отправки однотипных приборов с одним серийным номером (обычно б/н). Хороший пример 10 манометров без с/номеров, так вот при передаче 1 примется, другие 9 нет - api скажет что запись уже принята. Наше решение, т.к. api проверяет всю запись целиком, мы решили использовать необязательное поле PrimPOV, для передачи туда нашего уникального номера в БД, после этого api считает такие поверки разными и успешно принимает их. Маленький бонус - мы можем сопоставить запись в Аршине с нашей БД. 4. Не указана методика поверки, в этом случае мы передаем строку "МП согласно ОТ" 5. Ошибка, но которая не перехватывается api бывает в БД дата след.поверки < даты поверки. Хоть api и принимает такие записи, мы их решили в формируемый пакет не передовать. Вернее мы пытаемся расчитать дату следующей поверки по указанному межповерочному интервалу, и если не может то и не передаем. Контроль отправки и статистика обмена. Т.к. штатными средствами Аршина не возможно сопоставить поверочную запись с запись для передачи нам пришлось вносить изменения в БД для контроля и сопоставления. Дополнительно мы видим что и когда отправлено и как обработано.

Добрый день! Мы решили проблему с однотипными записями проще. Так как мы формируем пакеты для загрузки автоматически с БД и передаем их в Аршин автоматически через API то проблемы записей в одном пакете мы решили так: Так как у каждой поверочной работы в БД у нас есть уникальный идентификатор, то в поле PrimPOV мы пишем уникальную запись в нашей БД. Так решается уникальность записи в пакете, и появляется бонус обратной связи - по этому номеру мы всегда можем найти данные в нашей БД.