Вызов API GoodData Export Reports приводит к неполному файлу

Я разработал метод, который выполняет следующие шаги в следующем порядке:
1) Получить метаданные отчета через /gdc/md//obj/
2) Из этого получить определение отчета и использовать его как полезная нагрузка для вызова /gdc/xtab2/executor3
3) Использовать результат этого вызова в качестве полезной нагрузки для вызова /gdc/exporter/executor
4) Выполнить GET для возвращенного URI, чтобы загрузить сгенерированный CSV

Так что все это работает нормально, но проблема в том, что я часто получаю пустой CSV или неполный CSV. Мой обходной путь заключался в том, чтобы поместить sleep() между получением URI и фактическим вызовом GET для URI. Однако по мере роста наших данных мне приходится увеличивать задержку, и даже тогда нет гарантии, что я получил полные данные. Есть ли способ убедиться, что отчет завершил экспорт данных в файл перед вызовом URI?


person jpavs    schedule 13.06.2014    source источник


Ответы (1)


Проблема в том, что экспорт выполняется как асинхронная задача — результат по URL-адресу, возвращенному в полезной нагрузке от POST до /gdc/exporter/executor (в форме /gdc/exporter/result/{project-id}/{result-id}), доступен после того, как задача экспортера завершит свою работу.

Если задача еще не выполнена, от GET до /gdc/exporter/result/{project-id}/{result-id} должен возвращаться код состояния 202, что означает «мы все еще экспортируем, пожалуйста, подождите».

Таким образом, вы должны периодически опрашивать URL-адрес результата, пока он не вернет статус 200, который будет содержать полезную нагрузку (или 40x/50x, если что-то не так).

person akloboucnik    schedule 14.06.2014
comment
Чтобы уточнить, то, что я сделал, было POST в /gdc/exporter/executor, что возвращает URI для вызова для получения файла, который я хочу. Чтобы убедиться, что это сделано, я сделал GET против возвращенного URI, который возвращает 202 или 200 (если что-то не пошло не так). Я продолжаю опрашивать это, пока не получу 200, после чего я получаю возвращенный контент. - person jpavs; 17.06.2014