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

आपको 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, conditional flows, PostFlow, PostClientFlow
TargetEndpoint इसमें बैकएंड रिसोर्स के सबसे करीब मौजूद एपीआई प्रॉक्सी फ़्लो शामिल होते हैं. यह लॉजिक के लिए जगहें उपलब्ध कराता है, ताकि बैकएंड रिसॉर्स के लिए अनुरोध तैयार किया जा सके. इसके बाद, उससे मिले जवाब को मैनेज किया जा सके. PreFlow, कंडिशनल फ़्लो, PostFlow

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

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

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

स्थिति फ़्लो का टाइप ब्यौरा
1 PreFlow

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

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

2 कंडीशनल फ़्लो

यहां शर्त वाला फ़ॉर्मूला लागू किया जाता है. यह PreFlow के बाद और PostFlow से पहले लागू होता है.

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

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

अगर PostFlow किसी प्रॉक्सी एंडपॉइंट में है और कोई टारगेट एंडपॉइंट मौजूद है, तो प्रॉक्सी एंडपॉइंट का PostFlow, टारगेट एंडपॉइंट के PreFlow से पहले काम करता है.

4 PostClientFlow (सिर्फ़ प्रॉक्सी फ़्लो) क्लाइंट को जवाब मिलने के बाद, मैसेज लॉग करने का फ़्लो.

PreFlow की मदद से, कोड को सबसे पहले चलाने की सुविधा

प्रीफ़्लो तब काम आता है, जब आपको यह पक्का करना होता है कि कुछ कोड, किसी भी अन्य कार्रवाई से पहले ही एक्ज़ीक्यूट हो जाएं.

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

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

यहां दिए गए उदाहरण में, SpikeArrest और Quota नीतियां, शर्तों के साथ काम करने वाले फ़्लो को पास करने से पहले लागू होती हैं.

<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/ with anything in the URI after the last forward slash) हो.

<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, कंडीशनल फ़्लो और PreFlow के बाद लागू होता है.

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

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

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

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

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

* FlowCallout नीति, सिर्फ़ उन शेयर किए गए फ़्लो को कॉल कर सकती है जो PostClientFlow में शामिल होने की ज़रूरी शर्तें पूरी करते हैं. इसका मतलब है कि उनमें सिर्फ़ काम करने वाली नीतियां शामिल होनी चाहिए.

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

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

यहां MessageLogging नीति से जुड़ा PostClientFlow का उदाहरण दिया गया है.

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

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

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

फ़्लो में लॉजिक जोड़ना

अपनी प्रॉक्सी में लॉजिक जोड़ने के लिए, प्रॉक्सी के फ़्लो में नीतियां जोड़ें. जिस तरह फ़्लो एक क्रम में काम करते हैं (इस विषय में बताए गए तरीके के मुताबिक, PreFlow, Flow, और फिर 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 Trace टूल, ग्राफ़ के ज़रिए यह दिखाता है कि अनुरोध के बाद, आपकी एपीआई प्रॉक्सी में मौजूद लॉजिक कैसे काम करता है. यह टूल, अनुरोध और जवाब के बीच की प्रोसेसिंग को दिखाता है. इसमें PreFlow, शर्त के साथ लागू होने वाले फ़्लो, और PostFlow के बीच के अंतर को साफ़ तौर पर नहीं दिखाया गया है.

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

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

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

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

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

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