फ़्लो के साथ प्रॉक्सी के काम करने के तरीके को नियंत्रित करना

Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

किसी भी ऐप्लिकेशन प्रोग्रामिंग मॉडल में, प्रोसेसिंग के फ़्लो को कंट्रोल करने का तरीका शामिल होता है. एपीआई प्रोक्सी में, यह फ़्लो की मदद से किया जाता है. फ़्लो के लिए, लॉजिक, शर्त की जानकारी, गड़बड़ी ठीक करना वगैरह जोड़ा जा सकता है. फ़्लो का इस्तेमाल करके, यह कंट्रोल किया जा सकता है कि कब और क्या करना है.

फ़्लो, एपीआई अनुरोध को प्रोसेस करने के पाथ के क्रमिक चरण होते हैं. किसी एपीआई पासकोड की पुष्टि करने जैसे प्रॉक्सी लॉजिक को जोड़ने पर, लॉजिक को फ़्लो के क्रम में एक चरण के तौर पर जोड़ा जाता है. लॉजिक कब और कैसे लागू होगा, यह तय करने के लिए शर्त तय की जाती है. इस शर्त को किसी फ़्लो में जोड़ा जाता है.

नीचे दिए गए फ़्लो कॉन्फ़िगरेशन के उदाहरण में ऐसे फ़्लो के बारे में बताया गया है जिसमें VerifyAPIKey नीति लागू करती है कि अगर आने वाले अनुरोध का पाथ, / पर खत्म होता है और अनुरोध की एचटीटीपी क्रिया GET है.

<Flow name="Get Food Carts">
    <Description>Get Food Carts</Description>
    <Request>
        <Step>
            <Name>Verify-API-Key</Name>
        </Step>
    </Request>
    <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>

फ़्लो के <Name> एलिमेंट में मौजूद Verify-API-Key वैल्यू का इस्तेमाल, प्रोक्सी में एक्सएमएल की मदद से कॉन्फ़िगर की गई नीति को शामिल करने के लिए किया जाता है. जैसे:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key">
    <DisplayName>Verify API Key</DisplayName>
    <Properties/>
    <APIKey ref="request.header.x-api-key"/>
</VerifyAPIKey>

फ़्लो को लागू करने का क्रम तय करना

आपका स्ट्रक्चर फ़्लो इस तरह से होता है, ताकि आप प्रोसेसिंग पाथ में, सही क्रम में लॉजिक को एक्ज़ीक्यूट कर सकें.

लॉजिक को कहां जोड़ना है, यह तय करते समय आपको पहले यह चुनना होगा कि इसे किसी प्रॉक्सी एंडपॉइंट में जोड़ना है या टारगेट एंडपॉइंट में. एपीआई प्रॉक्सी, अपने कोड को प्रॉक्सी क्लाइंट (प्रॉक्सी एंडपॉइंट) से इंटरैक्ट करने वाले कोड और प्रॉक्सी के बैकएंड टारगेट से इंटरैक्ट करने वाले वैकल्पिक कोड (टारगेट एंडपॉइंट) के साथ इंटरैक्ट करने वाले कोड के बीच बांटता है.

दोनों एंडपॉइंट में फ़्लो शामिल हैं, जैसा कि यहां बताया गया है:

एंडपॉइंट का टाइप ब्यौरा इस्तेमाल किए जा सकने वाले फ़्लो
ProxyEndpoint इसमें क्लाइंट के सबसे करीब मौजूद एपीआई प्रॉक्सी फ़्लो शामिल होते हैं. इस सेटिंग के चालू होने पर, क्लाइंट के अनुरोध पर सबसे पहले तर्क के लिए काम किया जाता है. इसके बाद, सबसे पहले क्लाइंट के अनुरोध पर कार्रवाई की जाती है. PreFlow, सशर्त फ़्लो, PostFlow, PostClientFlow
TargetEndpoint इसमें बैकएंड रिसॉर्स के सबसे करीब मौजूद एपीआई प्रॉक्सी फ़्लो शामिल हैं. बैकएंड संसाधन के लिए अनुरोध तैयार करने और उसके जवाब को मैनेज करने के लिए, लॉजिक के लिए जगहें उपलब्ध कराता है. प्रीफ़्लो, कंडिशनल फ़्लो, पोस्टफ़्लो

एक्सएमएल के साथ फ़्लो को कॉन्फ़िगर किया जाता है, जो यह तय करता है कि क्या होना चाहिए और किस क्रम में होना चाहिए. यहां दिए गए इलस्ट्रेशन में दिखाया गया है कि किसी प्रॉक्सी एंडपॉइंट और टारगेट एंडपॉइंट में, फ़्लो को क्रम से कैसे लगाया जाता है:

एचटीटीपी सेवा तक पहुंचने के लिए, एचटीटीपी क्लाइंट से प्रॉक्सी एंडपॉइंट से बैकएंड पर टारगेट एंडपॉइंट तक भेजा गया अनुरोध. हर अनुरोध और जवाब पैनल में, प्रीफ़्लो, कंडीशनल फ़्लो, और पोस्ट फ़्लो दिखते हैं. इसके अलावा, प्रॉक्सी एंडपॉइंट और टारगेट एंडपॉइंट के उदाहरण भी दिए गए हैं.

प्रॉक्सी एंडपॉइंट और टारगेट एंडपॉइंट, दोनों में फ़्लो शामिल होते हैं, जिन्हें इस क्रम में लगाया जा सकता है:

स्थिति फ़्लो किस तरह का है ब्यौरा
1 PreFlow

यह तब काम आता है, जब आपको यह पक्का करना हो कि कोई दूसरा कोड लागू होने से पहले, कोई खास कोड लागू हो जाए.

अगर PreFlow किसी टारगेट एंडपॉइंट में है, तो यह प्रॉक्सी एंडपॉइंट के PostFlow के बाद काम करता है.
2 कंडिशनल फ़्लो

कंडिशनल लॉजिक के लिए जगह. PreFlow के बाद और PostFlow से पहले निष्पादित होता है.

हर सेगमेंट में सिर्फ़ एक कंडिशनल फ़्लो लागू किया जाता है--पहला फ़्लो जिसकी शर्त 'सही' का आकलन करती है. इसका मतलब है कि हर शर्त के हिसाब से, एक कंडिशनल फ़्लो को एक्ज़ीक्यूट किया जा सकता है:
  • ProxyEndpoint की अनुरोध पाइपलाइन
  • TargetEndpoint की अनुरोध पाइपलाइन
  • ProxyEndpoint की रिस्पॉन्स पाइपलाइन
  • TargetEndpoint की रिस्पॉन्स पाइपलाइन
3 PostFlow

यह डेटा लॉग करने, अनुरोध को प्रोसेस करने के दौरान होने वाली गतिविधियों की सूचना भेजने, और इसी तरह के अन्य काम करने के लिए अच्छी जगह है. यह शर्तों पर आधारित फ़्लो और PreFlow के बाद लागू होता है.

अगर PostFlow, प्रॉक्सी एंडपॉइंट में मौजूद है और टारगेट एंडपॉइंट मौजूद है, तो प्रॉक्सी एंडपॉइंट PostFlow, टारगेट एंडपॉइंट PreFlow से पहले काम करता है.
4 PostClientFlow (सिर्फ़ प्रॉक्सी फ़्लो) क्लाइंट को जवाब दिए जाने के बाद मैसेज लॉग करने का फ़्लो.

PreFlow की मदद से पहले कोड एक्ज़ीक्यूट करें

प्रीफ़्लो तब काम आता है, जब आपको यह पक्का करना हो कि कोई दूसरा काम होने से पहले, कोई कोड चालू हो जाए.

प्रॉक्सी एंडपॉइंट में, PreFlow ऐसे कोड के लिए सबसे अच्छी जगह है जो क्लाइंट की पुष्टि करता है और क्लाइंट से आने वाले ट्रैफ़िक को सीमित करता है. टारगेट एंडपॉइंट में, जहां यह बैकएंड टारगेट को अनुरोध भेजने की तैयारी शुरू करती है, वहां अनुरोध भेजने की तैयारी के लिए PreFlow, पहले चरण के तौर पर इस्तेमाल किया जा सकता है.

उदाहरण के लिए, आम तौर पर किसी ऐसे क्लाइंट को सेवा नहीं दी जाती जिसने कोटा से ज़्यादा अनुरोध किए हों. इन ज़रूरी शर्तों को पूरा करने के लिए, आपको PreFlow सेगमेंट में, सुरक्षा और कोटा से जुड़ी नीतियों को शामिल करना होगा. इस तरह, आपको बाद में कंडीशनल फ़्लो में आकलन न कर पाने की स्थिति के बारे में चिंता करने की ज़रूरत नहीं है. किसी भी दूसरी तरह की प्रोसेसिंग से पहले, इस फ़्लो में बताई गई नीतियां हमेशा लागू होंगी.

यहां दिए गए उदाहरण में, शर्तों पर आधारित फ़्लो पर प्रोसेसिंग भेजे जाने से पहले, स्पाइकअरेस्ट और कोटा नीतियां लागू होती हैं.

<PreFlow name="MyPreFlow">
    <Request>
        <Step>
            <Name>Spike-Arrest</Name>
        </Step>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Response/>
</PreFlow>

कोड को कंडीशनल फ़्लो के साथ कंडीशनल तरीके से चलाना

PreFlow और PostFlow के बीच, आपके पास ऐसे फ़्लो हो सकते हैं जो शर्तों के साथ काम करते हैं. इससे आपको लॉजिक के कई क्रम कॉन्फ़िगर करने का मौका मिलता है. हालांकि, आपके पास अपनी प्रॉक्सी की स्थिति के आधार पर, सिर्फ़ एक को लागू करने का विकल्प होता है. अगर आपके पास PreFlow या PostFlow में सभी लॉजिक को लागू करने का विकल्प है और किसी शर्त की ज़रूरत नहीं है, तो शर्तों वाला फ़्लो ज़रूरी नहीं है. दूसरे शब्दों में, एंडपॉइंट के ज़रिए सिर्फ़ एक पाथ का इस्तेमाल किया जा सकता है.

हर फ़्लो में एक शर्त होती है, जो अलग-अलग स्टेटस वैल्यू की जांच करती है. इससे, शर्तों के आधार पर ब्रैंच को असरदार तरीके से एक्ज़ीक्यूट किया जा सकता है. उदाहरण के लिए, हो सकता है कि आप सिर्फ़ तब एक्सएमएल को JSON में बदलना चाहें जब अनुरोध करने वाला ऐप्लिकेशन मोबाइल डिवाइस पर चल रहा हो.

यहां कोटा की पाबंदियां सिर्फ़ तब लागू होती हैं, जब अनुरोध GET अनुरोध हो और उसका यूआरआई पैटर्न /issue/** हो (/issue/, जिसमें आखिरी फ़ॉरवर्ड स्लैश के बाद यूआरआई में कुछ भी हो).

<Flow name="MyFlow">
    <Description/>
    <Request>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/issue/**") and (request.verb = "GET")</Condition>
</Flow>

शर्तों के बारे में बताने के लिए, फ़्लो वैरिएबल का इस्तेमाल किया जाता है. शर्तों में वैरिएबल इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, फ़्लो वैरिएबल के साथ शर्तें देखें.

शर्तों में पैटर्न मैचिंग का इस्तेमाल करने के उदाहरणों के लिए, पैटर्न मैचिंग देखें.

PostFlow की मदद से कोड को मुख्य लॉजिक के बाद चलाना

PostFlow, आपके एंडपॉइंट के कोर लॉजिक के बाद और एंडपॉइंट की प्रोसेसिंग खत्म होने से पहले कार्रवाइयां करने के लिए एक बेहतरीन जगह है. पोस्टफ़्लो, शर्तों पर आधारित फ़्लो और प्रीफ़्लो के बाद लागू होता है.

PostFlow कुछ डेटा लॉग करने, किसी गड़बड़ी की सूचना भेजने, जवाब वाले मैसेज का फ़ॉर्मैट बदलने वगैरह के लिए एक अच्छी जगह है.

नीचे दिए गए उदाहरण में, Apigee Edge के क्लाइंट को जवाब वापस भेजने से पहले, SetResponseHeaders नाम की PendingMessage नीति जवाब वाले मैसेज के हेडर सेट करती है.

<PostFlow>
    <Response>
        <Step>
            <Name>SetResponseHeaders</Name>
        </Step>
    </Response>
 </PostFlow>

PostClientFlow की मदद से क्लाइंट को आपका प्रॉक्सी जवाब मिलने के बाद कोड एक्ज़ीक्यूट करना

PostClientFlow में ये नीतियां शामिल की जा सकती हैं:

* फ़्लोकॉलआउट नीति सिर्फ़ 'शेयर किए गए फ़्लो' को कॉल कर सकती है, जो PostClientFlow में होने की शर्तों को पूरा करती हैं (यानी, सिर्फ़ उन नीतियों के साथ काम करती हैं जो इसके साथ काम करती हैं).

अगर आपने कोई फ़्लो शामिल किया है, तो PostClientFlow आखिरी फ़्लो होगा. यह क्लाइंट को जवाब भेजने के बाद,

PostClientFlow आखिरी लॉग करने के लिए अच्छा है. साथ ही, जवाब वाले मैसेज के शुरू और खत्म होने के टाइमस्टैंप को भी लॉग किया जा सकता है.

यहां PostClientFlow का एक उदाहरण दिया गया है, जिसमें MessageLogging नीति अटैच की गई है.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

वीडियो: यह छोटा सा वीडियो देखें. इसमें बताया गया है कि MessageLogging नीति का इस्तेमाल करके, डेवलपर के लिए चार मिनट के वीडियो (4MV4D) वाली सीरीज़ में, PostClientFlow कैसे बनाया जाता है.

ज़्यादा जानकारी के लिए, देखें:

फ़्लो में लॉजिक जोड़ा जा रहा है

अपनी प्रॉक्सी में लॉजिक जोड़ने के लिए, प्रॉक्सी के फ़्लो में नीतियां जोड़ें. जिस तरह फ़्लो किसी क्रम में एक्ज़ीक्यूट होता है (PreFlow के बाद फ़्लो और फिर PostFlow जैसा कि इस विषय में बताया गया है), फ़्लो का कॉन्टेंट किसी क्रम में लागू होता है.

नीचे दिए गए फ़्लो कॉन्फ़िगरेशन के उदाहरण में तीन नीतियों के बारे में बताया गया है (इन्हें अपनी एक्सएमएल फ़ाइलों में कहीं और कॉन्फ़िगर किया गया है). Verify-API-Key में बताई गई नीति, Remove-API-Key में बताई गई नीति से पहले काम करती है. इसके बाद, दोनों नीति Quota में बताई गई नीति का पालन करती है.

<Flow name="Get Food Cart Menus">
    <Description>Get Food Cart Menus</Description>
    <Request>
        <Step>
            <Name>Verify-API-Key</Name>
        </Step>
        <Step>
            <Name>Remove-API-Key</Name>
        </Step>
        <Step>
            <Name>Quota</Name>
        </Step>
    </Request>
    <Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>

Apigee Edge कंसोल, नीतियों के इस क्रम को आइकॉन की एक पंक्ति के तौर पर दिखाता है. इसमें हर आइकॉन, नीति को दिखाता है.

Apigee Edge कंसोल, नीतियों के इस क्रम को आइकॉन की एक लाइन के तौर पर दिखाता है, जहां हर आइकॉन नीति को दिखाता है. अनुरोध के पाथ पर दिखाए जाने वाले आइकॉन में ये शामिल हैं: एपीआई पासकोड की पुष्टि करना, एपीआई पासकोड हटाना, और कोटा

फ़्लो डीबग करना

Apigee Edge ट्रेस टूल, एक ग्राफ़िक के तौर पर यह जानकारी देता है कि आपके एपीआई प्रॉक्सी में लॉजिक, अनुरोध के बाद कैसे काम करता है. यह टूल, अनुरोध और जवाब के बीच की प्रोसेस को दिखाता है. इस इमेज में खास तौर पर PreFlow, कंडिशनल फ़्लो, और PostFlow के बीच के अंतर को नहीं दिखाया गया है.

प्रॉक्सी ट्रैक करने के बारे में ज़्यादा जानने के लिए, ट्रैक टूल का इस्तेमाल करना लेख पढ़ें.

फ़्लो में गड़बड़ियों को मैनेज करना

एपीआई प्रॉक्सी में, अलग-अलग जगहों से गड़बड़ियां बताई जा सकती हैं. इनमें फ़्लो भी शामिल हैं.

यहां दिया गया उदाहरण, टारगेट एंडपॉइंट में मौजूद PreFlow का रिस्पॉन्स स्टैंश है. दूसरे शब्दों में, यह वह कोड है जो बैकएंड टारगेट से रिस्पॉन्स मिलने के तुरंत बाद लागू होता है. इस उदाहरण में, अगर टारगेट से मिला रिस्पॉन्स 200 (सफल) नहीं है, तो गड़बड़ी की जानकारी दी जाती है.

<PreFlow name="PreFlow">
    <Response>
        <Step>
            <Name>RaiseFault</Name>
            <Condition>(response.status.code GreaterThan "200")</Condition>
        </Step>
    </Response>
</PreFlow>

गड़बड़ी ठीक करने के बारे में ज़्यादा जानने के लिए, गड़बड़ियां ठीक करना देखें.