Есть 2 варианта, о которых я могу думать:
1) Лучшим вариантом является обеспечение того, чтобы приложения всегда имели ту переменную, на которую вы ссылаетесь для квоты, заполненной в первую очередь. Это устраняет необходимость в двух переменных, и можно использовать политику квот, как вы указали. Кроме того, при необходимости администратор может переопределить или назначить другую квоту. Dev Connect можно настроить таким образом, чтобы настраиваемый атрибут приложения назначался при создании или регистрации приложения.
2) Кроме того, вы можете проверить из 1 источника (например, пользовательской переменной приложения), а затем, если она не имеет значения, вы можете использовать другой источник (например, настройку квоты продукта API).
К сожалению, я не верю, что все это можно сделать в рамках политики квот. Вместо этого вы можете использовать политику вызова службы, чтобы установить 1 переменную квоты в зависимости от того, что доступно.
Это ... или вы можете использовать 2 разные политики квот, каждая из которых будет срабатывать в зависимости от их условий. Их условия будут ссылаться на упомянутые вами переменные, чтобы проверить, существуют ли они (или нет).
<Step>
<Condition>(app.quota_var is null)</Condition>
<Name>QuotaPolicyUsingApiProductQuotaReference</Name>
</Step>
<Step>
<!-- if the app custom variable is there, you must mean to use it -->
<Condition>(app.quota_var != null)</Condition>
<Name>QuotaPolicyUsingAppQuotaReference</Name>
</Step>
person
akoo1010
schedule
25.01.2014
