Создание реквестера API с помощью инструментария сборки z/OS Connect

Хотя мы генерируем артефакты инициатора запросов 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 ответ

Как вы уже сказали, функциональность API Requester в 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 при необходимости.

Другие вопросы по тегам