‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

MonetizationLimitsCheck policy

מדיניות ניתנת להרחבה

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

המדיניות MonetizationLimitsCheck מאפשרת לכם לאכוף מגבלות על מונטיזציה.

באופן ספציפי, המדיניות מופעלת אם מפתח האפליקציה שניגש ל-API שמייצר הכנסות לא רכש מינוי למוצר ה-API המשויך, או אם היתרה שלו לא מספיקה. במקרה כזה, המדיניות MonetizationLimitsCheck תגרום לשגיאה ותחסום קריאה ל-API. מידע נוסף מופיע במאמר החלת דרישה ממפתחים להירשם למוצרי API.

כשמצרפים את מדיניות MonetizationLimitsCheck ל-proxy ל-API, משתני הזרימה mint.limitscheck.* ו-mint.subscription_* מאוכלסים, כפי שמתואר בהפניה למשתנה הזרימה mint.

המדיניות הזו היא מדיניות שניתנת להרחבה, והשימוש בה עשוי להשפיע על העלויות או על הניצול, בהתאם לרישיון שלכם ל-Apigee. למידע על סוגי מדיניות והשלכות השימוש, אפשר לעיין במאמר בנושא סוגי מדיניות.

`<MonetizationLimitsCheck>`

מגדיר את המדיניות MonetizationLimitsCheck.

ערך ברירת המחדל	לא רלוונטי
חובה?	חובה
סוג	סוג מורכב
רכיב אב	לא רלוונטי
רכיבי צאצא	`<DisplayName>` `<FaultResponse>` `<IgnoreUnresolvedVariables>`

בטבלה הבאה מפורטים רכיבי המשנה של <MonetizationLimitsCheck>:

רכיב צאצא	חובה?	תיאור
`<DisplayName>`	אופציונלי	שם מותאם אישית למדיניות.
`<FaultResponse>`	אופציונלי	הגדרת הודעת התגובה שמוחזרת ללקוח ששלח את הבקשה.
`<IgnoreUnresolvedVariables>`	אופציונלי	הפעולה מתעלמת משגיאות משתנים שלא נפתרו בתהליך.

רכיב <MonetizationLimitsCheck> משתמש בתחביר הבא:

תחביר

<?xml version="1.0" encoding="UTF-8" standalone="no"?><MonetizationLimitsCheck continueOnError="[true|false]" enabled="[true|false]" name="policy_name">
   <DisplayName>POLICY_DISPLAY_NAME</DisplayName>
   <FaultResponse>
        <AssignVariable>
          <Name/>
          <Value/>
        </AssignVariable>
        <Add>
            <Headers/>
        </Add>
        <Copy source="request">
            <Headers/>
            <StatusCode/>
       </Copy>
        <Remove>
            <Headers/>
        </Remove>
        <Set>
            <Headers/>
            <Payload/>
            <StatusCode/>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>VALUE</IgnoreUnresolvedVariables>
</MonetizationLimitsCheck>

דוגמה

בדוגמה הבאה, אם מפתח לא רכש מינוי למוצר ה-API המשויך, הגישה ל-API שמניב הכנסות נחסמת ומוחזר סטטוס 403 עם הודעה מותאמת אישית.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MonetizationLimitsCheck continueOnError="false" enabled="true" name="MonetizationLimitsCheck-1">
  <DisplayName>Monetization-Limits-Check-1</DisplayName>
  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  <FaultResponse>
    <Set>
      <Payload contentType="text/xml">
        <error>
          <messages>
            <message>Usage has been exceeded ({mint.limitscheck.isRequestBlocked}) or app developer has been suspended</message>
          </messages>
        </error>
      </Payload>
      <StatusCode>403</StatusCode>
    </Set>
  </FaultResponse>
</MonetizationLimitsCheck>

לרכיב הזה יש את המאפיינים הבאים שמשותפים לכל המדיניות:

מאפיין	ברירת מחדל	חובה?	תיאור
`name`	לא רלוונטי	חובה	השם הפנימי של המדיניות. הערך של מאפיין `name` יכול להכיל אותיות, מספרים, רווחים, מקפים, קווים תחתונים ונקודות. הערך הזה לא יכול להיות ארוך מ-255 תווים. אפשר להשתמש ברכיב `<DisplayName>` כדי לתת למדיניות תווית בשם אחר בשפה טבעית בכלי לעריכת פרוקסי בממשק המשתמש לניהול.
`continueOnError`	FALSE	אופציונלי	מגדירים את הערך `false` כדי להחזיר שגיאה אם המדיניות נכשלת. זו התנהגות צפויה ברוב המקרים. הגדרה ל-`true` מאפשרת להמשיך את הביצוע של התהליך גם אחרי שמדיניות נכשלת. מאמרים קשורים: הפעלת כללי תקלות מתבצעת רק במצב שגיאה (מידע על continueOnError) טיפול בתקלות בתהליך הנוכחי
`enabled`	TRUE	אופציונלי	מגדירים את הערך `true` כדי לאכוף את המדיניות, או את הערך `false` כדי להשבית את המדיניות. המדיניות לא נאכפת גם אם היא עדיין משויכת לזרימה.
`async`	FALSE	הוצא משימוש	המאפיין הזה הוצא משימוש.

הפניה לרכיב צאצא

בקטע הזה מתוארים רכיבי הבן של <MonetizationLimitsCheck>.

`<DisplayName>`

אפשר להשתמש במאפיין הזה בנוסף למאפיין name כדי לתת למדיניות שם אחר, שנשמע יותר טבעי, ב-UI של עורך ה-proxy לניהול.

הרכיב <DisplayName> משותף לכל סוגי המדיניות.

ערך ברירת המחדל	לא רלוונטי
חובה?	זה שינוי אופציונלי. אם לא מציינים את `<DisplayName>`, המערכת משתמשת בערך של מאפיין `name` של המדיניות.
סוג	String
רכיב אב	<`PolicyElement`>
רכיבי צאצא	ללא

רכיב <DisplayName> משתמש בתחביר הבא:

תחביר

<PolicyElement>
  <DisplayName>POLICY_DISPLAY_NAME</DisplayName>
  ...
</PolicyElement>

דוגמה

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

לרכיב <DisplayName> אין מאפיינים או רכיבי צאצא.

`<FaultResponse>`

הגדרת הודעת התגובה שמוחזרת ללקוח ששלח את הבקשה. האלמנט FaultResponse משתמש באותן הגדרות כמו האלמנט <FaultResponse> במדיניות RaiseFault.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	סוג מורכב
רכיב אב	`<MonetizationLimitsCheck>`
רכיבי צאצא	`<AssignVariable>` `<Add>` `<Copy>` `<Remove>` `<Set>`

`<AssignVariable>`

מקצה ערך למשתנה של יעד בתהליך. אם משתנה הזרימה לא קיים, הפונקציה AssignVariable יוצרת אותו.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	סוג מורכב
רכיב אב	`<FaultResponse>`
רכיבי צאצא	`<Name>` `<Value>`

לדוגמה, אפשר להשתמש בקוד הבא כדי להגדיר את המשתנה בשם myFaultVar במדיניות MonetizationLimitsCheck:

<FaultResponse>
<AssignVariable>
  <Name>myFaultVar</Name>
  <Value>42</Value>
</AssignVariable>
</FaultResponse>

לאחר מכן, מדיניות בכלל שגיאה יכולה לגשת למשתנה. לדוגמה, מדיניות AssignMessage הבאה משתמשת במשתנה כדי להגדיר כותרת בתגובה לשגיאה:

<AssignMessage enabled="true" name="Assign-Message-1">
<Add>
  <Headers>
    <Header name="newvar">{myFaultVar}</Header>
  </Headers>
</Add>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

‫<AssignVariable> במדיניות MonetizationLimitsCheck משתמש באותו תחביר כמו רכיב <AssignVariable> במדיניות AssignMessage.

`<Name>`

שם המשתנה. מידע נוסף זמין ברכיב Name במדיניות AssignMessage.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	String
רכיב אב	`<AssignVariable>`
רכיבי צאצא	ללא

`<Value>`

ערך המשתנה. מידע נוסף מופיע ברכיב Value במדיניות AssignMessage.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	String
רכיב אב	`<AssignVariable>`
רכיבי צאצא	ללא

`<Add>`

הוספת כותרות HTTP להודעת השגיאה.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	סוג מורכב
רכיב אב	`<FaultResponse>`
רכיבי צאצא	`<Headers>`

`<Headers>`

מציינת את כותרת ה-HTTP שרוצים להוסיף, להגדיר, להעתיק או להסיר.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	סוג מורכב
רכיב אב	`<Add>` `<Copy>` `<Remove>` `<Set>`
רכיבי צאצא	ללא

דוגמאות:

הוספת כותרת

בדוגמה הבאה, הערך של משתנה הזרימה request.user.agent מועתק לכותרת:

<Add>
    <Headers>
        <Header name="user-agent">{request.user.agent}</Header>
    </Headers>
</Add>

הגדרת כותרת

בדוגמה הבאה, הכותרת user-agent מוגדרת למשתנה ההודעה שצוין ברכיב <AssignTo>.

<Set>
    <Headers>
        <Header name="user-agent">{request.header.user-agent}</Header>
    </Headers>
</Set>

Copy header - 1

בדוגמה הבאה מועתק הערך headerA מהבקשה:

<Copy source='request'>
    <Headers>
        <Header name="headerA"/>
    </Headers>
</Copy>

העתקת כותרת – 2

בדוגמה הבאה מועתקות כמה כותרות:

<Copy source='request'>
    <Headers>
      <Header name="h1"/>
      <Header name="h2"/>
      <Header name="h3.2"/>
    </Headers>
</Copy>

בדוגמה הזו, הפונקציה מעתיקה את הערכים h1,‏ h2 ואת הערך השני של h3. אם ל-h3 יש רק ערך אחד, הוא לא מועתק.

הסרת כותרת עליונה – 1

בדוגמה הבאה מוצג איך מסירים כותרת:

<Remove>
    <Headers>
        <Header name="user-agent"/>
    </Headers>
</Remove>

הסרת כותרת עליונה – 2

בדוגמה הבאה מוסרות כמה כותרות:

<Remove>
    <Headers>
      <Header name="h1"/>
      <Header name="h2"/>
      <Header name="h3.2"/>
    </Headers>
</Remove>

בדוגמה הזו, הערכים h1,‏ h2 והערך השני של h3 מוסרים. אם ל-h3 יש רק ערך אחד, הוא לא מוסר.

`<Copy>`

מעתין מידע מהההודעה שצוינה במאפיין source אל הודעת השגיאה.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	סוג מורכב
רכיב אב	`<FaultResponse>`
רכיבי צאצא	`<Headers>` `<StatusCode>`

בטבלה הבאה מתוארים המאפיינים של <Copy>:

מאפיין	חובה?	סוג	תיאור
מקור	אופציונלי	String	מציין את אובייקט המקור של ההעתקה. אם לא מציינים מקור, ההודעה נחשבת להודעה פשוטה. לדוגמה, אם המדיניות נמצאת בתהליך הבקשה, המקור יהיה כברירת מחדל אובייקט הבקשה. אם המדיניות נמצאת בתהליך התגובה, ברירת המחדל היא אובייקט התגובה. אם לא מציינים את המקור, אפשר להשתמש בהפניה מוחלטת למשתנה של זרימת נתונים כמקור של העותק. לדוגמה, מציינים את הערך כ-{request.header.user-agent}. אם לא ניתן לפתור את משתנה המקור, או שהוא נפתר לסוג שאינו הודעה, הפעולה <Copy> לא תגיב.

מאפיין

חובה?

סוג

תיאור

מקור

אופציונלי

String

מציין את אובייקט המקור של ההעתקה.

אם לא מציינים מקור, ההודעה נחשבת להודעה פשוטה. לדוגמה, אם המדיניות נמצאת בתהליך הבקשה, המקור יהיה כברירת מחדל אובייקט הבקשה. אם המדיניות נמצאת בתהליך התגובה, ברירת המחדל היא אובייקט התגובה. אם לא מציינים את המקור, אפשר להשתמש בהפניה מוחלטת למשתנה של זרימת נתונים כמקור של העותק. לדוגמה, מציינים את הערך כ-{request.header.user-agent}.
אם לא ניתן לפתור את משתנה המקור, או שהוא נפתר לסוג שאינו הודעה, הפעולה <Copy> לא תגיב.

`<StatusCode>`

מציין את קוד סטטוס של HTTP בהודעת השגיאה. אפשר להעתיק או להגדיר את הערך מ- עבור האובייקט שצוין במאפיין source.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	סוג מורכב
רכיב אב	`<Copy>` `<Set>`
רכיבי צאצא	ללא

דוגמה:

העתקת קוד הסטטוס

<Copy source='response'>
    <StatusCode>404</StatusCode>
</Copy>

הגדרת קוד סטטוס

<Set source='request'>
    <StatusCode>404</StatusCode>
</Set>

`<Remove>`

מסירה כותרות HTTP שצוינו מהודעת השגיאה. כדי להסיר את כל הכותרות, מציינים <Remove><Headers/></Remove>.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	סוג מורכב
רכיב אב	`<FaultResponse>`
רכיבי צאצא	`<Headers>`

`<Set>`

מגדירה את המידע בהודעת השגיאה.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	סוג מורכב
רכיב אב	`<FaultResponse>`
רכיבי צאצא	`<Headers>` `<Payload>` `<StatusCode>`

`<Payload>`

הגדרת המטען הייעודי (payload) של הודעת השגיאה.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי
סוג	String
רכיב אב	`<Set>`
רכיבי צאצא	ללא

דוגמאות:

הגדרת מטען ייעודי (payload) של טקסט

<Set>
    <Payload contentType="text/plain">test1234</Payload>
</Set>

הגדרת מטען ייעודי (payload) של JSON – 1

<Set>
    <Payload contentType="application/json">
        {"name":"foo", "type":"bar"}
    </Payload>
</Set>

הגדרת מטען ייעודי (payload) של JSON – 2

<Set>
    <Payload contentType="application/json" variablePrefix="@" variableSuffix="#">
        {"name":"foo", "type":"@variable_name#"}
    </Payload>
</Set>

בדוגמה הזו מוסיפים משתנים באמצעות המאפיינים variablePrefix ו-variableSuffix עם תווים להגדרת גבולות.

הגדרת מטען ייעודי (payload) של JSON – 3

<Set>
    <Payload contentType="application/json">
        {"name":"foo", "type":"{variable_name}"}
    </Payload>
</Set>

בדוגמה הזו מוסיפים משתנים באמצעות סוגריים מסולסלים. אפשר להשתמש בסוגריים מסולסלים החל מגרסה 16.08.17.

הגדרת מטען ייעודי (payload) של XML

<Set>
    <Payload contentType="text/xml">
        <root>
          <e1>sunday</e1>
          <e2>funday</e2>
          <e3>{var1}</e3>
    </Payload>
</Set>

בדוגמה הזו מוסיפים משתנים באמצעות סוגריים מסולסלים. אפשר להשתמש בסוגריים מסולסלים החל מגרסה 16.08.17.

`<IgnoreUnresolvedVariables>`

קובעת אם העיבוד ייפסק כשנתקלים במשתנה לא פתור.

הערך true גורם למערכת להתעלם ממשתנים שלא נפתרו ולהמשיך בעיבוד. אחרת, הערך הוא false. ערך ברירת המחדל הוא true.

ההגדרה של <IgnoreUnresolvedVariables> ל-true שונה מההגדרה של <MonetizationLimitsCheck>'s continueOnError ל-true. אם מגדירים את continueOnError ל-true, מערכת Apigee מתעלמת מכל השגיאות, ולא רק משגיאות במשתנים.

רכיב <IgnoreUnresolvedVariables> משתמש בתחביר הבא:

תחביר

<IgnoreUnresolvedVariables>[true|false]</IgnoreUnresolvedVariables>

דוגמה

בדוגמה הבאה, הערך של <IgnoreUnresolvedVariables> מוגדר ל-false:

<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>

קודי שגיאה

This section describes the fault codes and error messages that are returned and fault variables that are set by Apigee when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault code	HTTP status	Cause
`mint.service.subscription_not_found_for_developer`	`500`	This error occurs when a developer does not have a subscription to the API Product.
`mint.service.wallet_not_found_for_developer`	`500`	This error occurs when a prepaid developer attempts to consume a monetized API without maintaining a wallet for the currency specified in rate plan.
`mint.service.developer_usage_exceeds_balance`	`500`	This error occurs when a prepaid developer's usage exceeds the wallet balance.
`mint.service.wallet_blocked_due_to_inactivity`	`500`	This error occurs when a prepaid developer's wallet is not topped up in over 1.5 years and the developer attempts to consume an API.

Fault variables

Whenever there are execution errors in a policy, Apigee generates error messages. You can view these error messages in the error response. Many a time, system generated error messages might not be relevant in the context of your product. You might want to customize the error messages based on the type of error to make the messages more meaningful.

To customize the error messages, you can use either fault rules or the RaiseFault policy. For information about differences between fault rules and the RaiseFault policy, see FaultRules vs. the RaiseFault policy. You must check for conditions using the Condition element in both the fault rules and the RaiseFault policy. Apigee provides fault variables unique to each policy and the values of the fault variables are set when a policy triggers runtime errors. By using these variables, you can check for specific error conditions and take appropriate actions. For more information about checking error conditions, see Building conditions.

Variables	Where	Example
`fault.name`	The `fault.name` can match to any of the faults listed in the Runtime errors table. The fault name is the last part of the fault code.	`fault.name Matches "UnresolvedVariable"`
`MonetizationLimitsCheck.POLICY_NAME.failed`	`POLICY_NAME` is the user-specified name of the policy that threw the fault.	`MonetizationLimitsCheck.monetization-limits-check-1.failed = true`

For more information about policy errors, see What you need to know about policy errors

משתנים בתהליך

משתני הזרימה המוגדרים מראש הבאים מאוכלסים באופן אוטומטי כשמדיניות MonetizationLimitsCheck מופעלת. מידע נוסף זמין במאמר בנושא משתני זרימת העבודה של mint.

משתנה בתהליך	תיאור
`mint.limitscheck.is_request_blocked`	‫`true` לבקשות חסומות.
`mint.limitscheck.is_subscription_found`	‫`true` אם נמצא מינוי ל-API.
`mint.limitscheck.purchased_product_name`	שם מוצר ה-API שנרכש. לדוגמה: `MyProduct`.
`mint.limitscheck.status_message`	הודעת סטטוס. אלה הערכים שמוחזרים: ‫`limits_check_success` - בדיקת המגבלות בוצעה בהצלחה. ‫`apiproduct_name_and_developer_email_not_available` - לא ניתן לקבוע את מפתח ה-API או את שם מוצר ה-API כדי לבצע בדיקת מגבלות. ‫`apiproduct_name_not_available` - אי אפשר לקבוע את השם של מוצר ה-API כדי לבצע בדיקת מגבלות. `developer_email_not_available` - לא הצלחנו לקבוע את כתובת האימייל של מפתח ה-API כדי לבצע בדיקת מגבלות. ‫`developer_usage_exceeds_balance` - היתרה של המפתח ששולמה מראש נמוכה מדי. ‫`rateplan_not_available` – מוצר API ללא תוכנית תמחור, ללא תקלה. ‫`subscription_not_available` – למפתח ה-API שהוא הבעלים של האפליקציה אין מינוי. ‫`wallet_disabled_due_to_inactivity` – המפתח לא השתמש בארנק שלו במשך יותר משנה. כדי להפעיל אותו מחדש, צריך להוסיף לו לפחות יחידה אחת (בדולרים, זה יהיה 0.01$). ‫`wallet_not_found` – למפתח אין ארנק. זה יכול לקרות אם המפתח לא ביצע טעינה של היתרה.
`mint.subscription_end_time_ms`	שעת הסיום של המינוי למוצר ה-API.
`mint.subscription_start_time_ms`	שעת ההתחלה של המינוי למוצר ה-API. לדוגמה: `1618433956209`.

MonetizationLimitsCheck policy קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

<MonetizationLimitsCheck>

תחביר

דוגמה

הפניה לרכיב צאצא

<DisplayName>

תחביר

דוגמה

<FaultResponse>

<AssignVariable>

<Name>

<Value>

<Add>

<Headers>

הוספת כותרת

הגדרת כותרת

Copy header - 1

העתקת כותרת – 2

הסרת כותרת עליונה – 1

הסרת כותרת עליונה – 2

<Copy>

<StatusCode>

העתקת קוד הסטטוס

הגדרת קוד סטטוס

<Remove>

<Set>

<Payload>

הגדרת מטען ייעודי (payload) של טקסט

הגדרת מטען ייעודי (payload) של JSON – 1

הגדרת מטען ייעודי (payload) של JSON – 2

הגדרת מטען ייעודי (payload) של JSON – 3

הגדרת מטען ייעודי (payload) של XML

<IgnoreUnresolvedVariables>

תחביר

דוגמה

קודי שגיאה

Runtime errors

Fault variables

משתנים בתהליך

MonetizationLimitsCheck policy

`<MonetizationLimitsCheck>`

`<DisplayName>`

`<FaultResponse>`

`<AssignVariable>`

`<Name>`

`<Value>`

`<Add>`

`<Headers>`

`<Copy>`

`<StatusCode>`

`<Remove>`

`<Set>`

`<Payload>`

`<IgnoreUnresolvedVariables>`