Схема получения данных
- Получатель запрашивает для себя изменения
- Получатель проверяет готовность запрошенных данных
- Получатель загружает данные к себе
- Получатель обрабатывает данные и подтверждает, что изменения загружены и обработаны.
Процесс получения данных
Ввод информации об внешних сервисах выполняется в в разделенном режиме в приложении пользователя. Предполагается, что данные будут загружены в справочник обслуживающей организацией при начале ведения учета, либо введены пользователем вручную.
В самой учетной системе определены правила регистрации к выгрузке. Например, при записи и проведении, документы по определенным правилам регистрируются к выгрузке.
После регистрации к выгрузке документы могут быть получены внешним сервисом через программный интерфейс передачи данных.
Запрос на формирование данных
Запрос: POST {{baseURL}}/integration/get
В ответ возвращается информация о созданном задании на формирование данных.
Поля ответа:
- result - результат
- storage - идентификатор объектного хранилища (в данном случае - jobs)
- id - идентификатор объекта хранилища (в данном случае - идентификатор задания)
Пример ответа
{
"general": {
"response": 10200,
"error": false,
"message": ""
},
"result": {
"storage": "jobs",
"id": "47e7efd6-ddb6-11e7-819b-0050568925e0"
}
}
Если к отправке нет данных, то при запросе на получение данных система вернет ответ с кодом 10404
Пример ответа
{
"general": {
"response": 10404,
"error": false,
"message": ""
}
}
По идентификатору задания выполняется дальнейшее отслеживание подготовки данных с помощью запроса GET {{baseURL}}/jobs/{id}
Получение данных с помощью запросов GET выполняется в соответствие с описанием операции Download, т.е. выполняется 2 последовательных запроса GET.
Первый GET запрос должен отправляться с авторизацией, т.к. в предыдущем запросе произведено закрытие сессии. Теперь будет открыта новая сессия для получения данных.
Второй GET запрос с сессионными cookie авторизации не требует.
На первый запрос будет получен 302 редирект с адресом Location. Большинство библиотек обрабатывают 302-редирект как браузер, таким образом сразу будет получен результат второго GET запроса.
При запросе данных, в приложении выполняются следующие действия:
- Формируется список объектов к выгрузке
- Формируются файлы для каждого объекта с именем равным идентификатору объекта.
- Формируется файл описания данных manifest.json
- Файлы упаковываются в архив zip
- Ссылка на архив возвращается в ответе.
Пример ответа, если данные еще не сформированы
{
"general": {
"response": 10202,
"error": false,
"message": ""
}
}
После формирования данных будет получен ответ с идентификатором файла собранных данных.
Поля ответа:
- result - результат
- storage - идентификатор объектного хранилища (в данном случае - files)
- id - идентификатор объекта хранилища (в данном случае - идентификатор файла)
Пример ответа после формирования файла данных
{
"general": {
"response": 10200,
"error": false,
"message": ""
},
"result": {
"storage": "files",
"id": "0cdf3084-90e4-49aa-8a57-735514cf5670"
}
}
Получение файла данных
Запрос: GET {{baseURL}}/files/{id}
Данные возвращаются в виде zip-архива. В составе архива обязательно содержится файл manifest.json, описывающий файлы данных в этом архиве.
Структура файла manifest.json:
- upload - список файлов данных
- file – имя файла (идентификатор данных)
- version – версия
- handler - обработчик
Пример manifest.json
{
"upload": [
{
"file": "75a49f73-15ba-11e8-b5bd-0050568908e4.json",
"handler": "example-sync",
"version": "426900129"
},
{
"file": "8ee44925-160d-11e8-b5bd-0050568908e4.json",
"handler": "example-sync",
"version": "2117101459"
}
]
}
Подтверждение получения данных
Запрос: POST {{baseURL}}/integration/confirm
В теле запроса передаются подтверждение в формате JSON
Поля подтверждения:
- result - результат обработки
- file - имя файла (идентификатор данных)
- version - версия подтверждаемого файла (передается в манифесте), нужна для проверки необходимости повторной отправки данных.
- handler - обработчик данных
- response - код ответа (коды определяются в учетной системе)
- error - признак ошибки обработки
- message - описание в случае ошибки.
Пример подтверждения получения данных
{
"result": [
{
"file": "75a49f73-15ba-11e8-b5bd-0050568908e4.json",
"version": "426900129",
"handler": "example-sync",
"response": 10200,
"error": false,
"message": ""
},
{
"file": "8ee44925-160d-11e8-b5bd-0050568908e4.json",
"version": "2117101459",
"handler": "example-sync",
"response": 10200,
"error": false,
"message": ""
}
]
}
Обработка подтверждения выполняется синхронно.
Ответ приложения после обработки подтверждения
{
"general": {
"response": 10200,
"error": false,
"message": ""
}
}
После получения данных синхронизируемые документы будут исключены из списка к отправке.
Данные также могут быть отклонены получателем.
Пример отклонения данных
{
"result": [
{
"file": "54ff1341-d9c5-11e7-819b-0050568925e0.json",
"version": "2015273148",
"handler": "example",
"response": 10400,
"error": true,
"message": "Не корректные данные."
}
]
}
Коды возврата должны быть определены во внешней учетной системе и согласованы с разработчиком прикладного решения.
Рекомендуемые коды возврата учетной системы при отправке подтверждений
Рекомендуется использовать такие-же коды возврата, что используются при подтверждении обработки полученных от учетной системы данных приложением.
№ | Код возврата | Это ошибка | Описание |
|---|---|---|---|
| 1 | 10200 | Выполнено | |
| 2 | 10240 | Выполнено с предупреждениями. Предупреждения в сообщении. | |
| 3 | 10400 | Да | Ошибка данных. Описание ошибок в сообщении. |
| 4 | 10404 | Данные не найдены | |
| 5 | 10500 | Да | Внутренняя ошибка. Описание ошибки в сообщении. |