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 מאפשרת להמשיך את הביצוע של התהליך גם אחרי שמדיניות נכשלת. מאמרים קשורים:
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> לא תגיב.
<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>

קודי שגיאה

בקטע הזה מתוארים קודי התקלה והודעות השגיאה שמוחזרים, ומשתני התקלה שמוגדרים על ידי Apigee כשמדיניות כזו מפעילה שגיאה. חשוב לדעת את המידע הזה אם אתם מפתחים כללי תקלות לטיפול בתקלות. מידע נוסף על שגיאות שקשורות למדיניות ועל טיפול בשגיאות

שגיאות זמן ריצה

השגיאות האלה יכולות להתרחש כשהמדיניות מופעלת.

קוד תקלה סטטוס HTTP מטרה
mint.service.subscription_not_found_for_developer 500 השגיאה הזו מתרחשת כשמפתח לא מנוי למוצר ה-API.
mint.service.wallet_not_found_for_developer 500 השגיאה הזו מתרחשת כשמפתח עם מינוי בתשלום מראש מנסה להשתמש ב-API עם מונטיזציה בלי להחזיק ארנק במטבע שצוין בתוכנית התמחור.
mint.service.developer_usage_exceeds_balance 500 השגיאה הזו מתרחשת כשהשימוש של מפתח עם תשלום מראש חורג מהיתרה בארנק.
mint.service.wallet_blocked_due_to_inactivity 500 השגיאה הזו מתרחשת כשמפתח עם תשלום מראש מנסה להשתמש ב-API, אבל לא טען כסף לארנק שלו במשך יותר משנה וחצי.

משתני תקלות

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

כדי להתאים אישית את הודעות השגיאה, אפשר להשתמש בכללי תקלות או במדיניות RaiseFault. מידע על ההבדלים בין כללי תקלות לבין מדיניות RaiseFault זמין במאמר FaultRules לעומת מדיניות RaiseFault. צריך לבדוק את התנאים באמצעות הרכיב Condition גם בכללי השגיאה וגם במדיניות RaiseFault. ‫Apigee מספק משתני שגיאה שייחודיים לכל מדיניות, והערכים של משתני השגיאה מוגדרים כשמדיניות מפעילה שגיאות בזמן ריצה. באמצעות המשתנים האלה, אפשר לבדוק תנאי שגיאה ספציפיים ולנקוט פעולות מתאימות. מידע נוסף על בדיקת תנאי שגיאה זמין במאמר יצירת תנאים.

משתנים כאשר: דוגמה
fault.name הערך fault.name יכול להתאים לכל אחת מהתקלות שמופיעות בטבלה שגיאות בזמן ריצה. שם התקלה הוא החלק האחרון של קוד התקלה. fault.name Matches "UnresolvedVariable"
MonetizationLimitsCheck.POLICY_NAME.failed ‫POLICY_NAME הוא השם שהמשתמש הגדיר למדיניות שגרמה לשגיאה. MonetizationLimitsCheck.monetization-limits-check-1.failed = true
מידע נוסף על שגיאות שקשורות למדיניות זמין במאמר מה צריך לדעת על שגיאות שקשורות למדיניות

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

משתני הזרימה המוגדרים מראש הבאים מאוכלסים באופן אוטומטי כשמדיניות 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.