Генерация реквестеров API с использованием инструментария сборки z / OS Connect - PullRequest
0 голосов
/ 06 апреля 2020

Хотя мы генерируем артефакты запрашивающего API с помощью инструмента командной строки zconbt и файла спецификации API, zconbt не генерирует тетради для множественных ответов об ошибках. Предположим, что в файле API swagger мы определили схему ответа для HTTP-кодов 200, 400, 500, где определение схемы ответа отличается для каждого из этих ответов. Теперь, если мы сгенерируем тетради с использованием zconbt, zconbt игнорирует схему ответа для 400 и 500 и генерирует структуру тетради ответа только для кода 200. Теперь, когда мы вызываем этот API из MF и получаем ответ с кодом состояния 400 и ответным сообщением, как определено в swagger для 400, zcee не может преобразовать и отправить сообщение обратно в MF в соответствующей переменной тетради. Это связано с тем, что схема ответа для 400 уже была проигнорирована zconbt. Поэтому мой вопрос заключается в том, есть ли у нас обходной путь для обработки сценариев такого типа, когда нам необходимо иметь всю схему ответов об ошибках, доступную через тетради cobol, для обработки ответов об ошибках.

1 Ответ

0 голосов
/ 01 мая 2020

Как вы уже сказали, функциональность реквестера API в z / OS Connect EE обеспечивает только преобразование JSON в COBOL для успешного случая вызова API.

Если вызов API завершается чем-то отличным от в случае успеха информация об ответе возвращается как есть в структуре BAQ-RESPONSE-API.

На основе примера в Центре знаний вы можете обработать эти ответы следующим образом:

WHEN BAQ-ERROR-IN-API 
    EVALUATE BAQ-STATUS-CODE 
        WHEN 400
            DISPLAY "Invalid Pet ID"
        WHEN 500
            DISPLAY "No pet found with ID "
        WHEN OTHER
            DISPLAY "API returned error " 
                BAQ-STATUS-CODE
    END-EVALUATE

Ответ JSON доступен в поле BAQ-STATUS-MESSAGE и может быть проанализирован с использованием поддержки JSON в COBOL или PL / I, если требуется.

...