Как обработать ошибку Apigee при проверке параметров запроса в прокси

У меня есть следующее. Параметр "g" может быть "включен" или "выключен", в противном случае перейдите к политике ошибок. Однако исключительный случай никогда не вызывается. Вместо этого вызывается случай "включено", если что-то, что не "включено" или "выключено", передается как "g". Это почему? Или есть лучший способ выразить это?

<PreFlow name="PreFlow">
    <Request>
        <Step>
            <Condition>message.queryparam.g := "on"</Condition>
            <Name>GOn</Name>
        </Step>
        <Step>
            <Condition>message.queryparam.g := "off"</Condition>
            <Name>GOff</Name>
        </Step>
        <Step>
            <Condition>!((message.queryparam.g := "off") || (message.queryparam.g := "on"))</Condition>
            <Name>GError</Name>
        </Step>
    </Request>
Источник

3 ответа

Решение

Я только что проверил ваши условия, и они работают должным образом. Если запрос имеет следующие значения параметров запроса:

g=on или же g=ON, политика GOn будет выполнена.

g=off или же g=OFF, политика GOff будет выполнена.

g={anythingelse}, политика GError будет выполнена.

:= оператор равен оператору без учета регистра. Как вы определяете, что условия не работают? Используя ваш пример, я сделал каждую из политик RaiseFault с разной полезной нагрузкой реакции на ошибку. Это позволило мне проверить, какая политика была выполнена в зависимости от значения g,

Источник

Я согласен с Майклом, код, как показано, является правильным.

Думая о возможных проблемах, которые могут привести к тому, что этот код не будет работать должным образом:

  1. Убедитесь, что имена указаны правильно в ваших политиках GOn, GOff и GError. (Если вы работаете в автономном режиме, имя файла не имеет отношения к тому, какая политика вызывается.) Например, внешний элемент политики GOn должен выглядеть примерно так:

  2. Если GOn использует AssignMessage для изменения сообщения, вы можете удалить параметр запроса g во время шага, и ваши последующие проверки могут завершиться неудачей. Если вы изменяете сообщение, сохраните файл message.query param.g в другой переменной, прежде чем выполнять проверки.

  3. Я бы использовал инструмент трассировки и такой инструмент, как Postman, чтобы увидеть, что происходит для каждого запроса. Трассировка должна указывать вам проверенные переменные и их значения, и вы сможете увидеть, где вы идете не так.

Источник

Если у вас есть несколько условных проверок, попробуйте использовать javascritp. В сценарии java проверьте различные условия и установите флаг. И в потоке, основанном на значении флага, выполните требуемую политику. Но для приведенного выше примера, как указал Майкл, условия должен работать как положено.

Источник
Другие вопросы по тегам