การควบคุมวิธีที่พร็อกซีดำเนินการกับโฟลว์

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X
info

โมเดลการเขียนโปรแกรมแอปพลิเคชันใดๆ ก็ตามจะมีวิธีควบคุมโฟลว์ของการประมวลผล ในพร็อกซี API การดำเนินการนี้จะทำด้วยโฟลว์ คุณสามารถเพิ่มตรรกะ คำสั่งเงื่อนไข การจัดการข้อผิดพลาด และอื่นๆ ลงในโฟลว์ คุณใช้โฟลว์เพื่อควบคุมสิ่งที่เกิดขึ้นและเวลาที่เกิด

โฟลว์คือขั้นตอนตามลำดับในเส้นทางการประมวลผลคำขอ API เมื่อเพิ่มตรรกะพร็อกซี เช่น เพื่อยืนยันคีย์ API คุณจะเพิ่มตรรกะเป็นขั้นตอนในลำดับที่ระบุโดยโฟลว์ เมื่อกำหนดเงื่อนไขเพื่อระบุว่าตรรกะจะทำงานหรือไม่และเมื่อใด คุณจะเพิ่มเงื่อนไขลงในโฟลว์

ตัวอย่างการกำหนดค่าโฟลว์ต่อไปนี้กำหนดโฟลว์ที่นโยบาย VerifyAPIKey จะดำเนินการหากเส้นทางคำขอขาเข้าสิ้นสุดด้วย / และคำขอมี HTTP verb เป็น 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>

ค่า Verify-API-Key ในองค์ประกอบ <Name> ของโฟลว์มีไว้ เพื่อรวมนโยบายที่กำหนดค่าไว้ที่อื่นในพร็อกซีด้วย XML เช่น XML ต่อไปนี้

<?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>

การออกแบบลำดับการดำเนินการตามโฟลว์

คุณจัดโครงสร้างโฟลว์เพื่อให้ตรรกะทำงานตามลำดับที่ถูกต้องตามเส้นทางการประมวลผล

เมื่อตัดสินใจว่าจะเพิ่มตรรกะที่ใด คุณจะต้องเลือกว่าจะเพิ่มตรรกะไปยังปลายทางพร็อกซีหรือ ปลายทางเป้าหมายก่อน พร็อกซี API จะแบ่งโค้ดระหว่างโค้ดที่โต้ตอบกับไคลเอ็นต์ของพร็อกซี (ปลายทางพร็อกซี) กับโค้ดที่ไม่บังคับซึ่งโต้ตอบกับเป้าหมายแบ็กเอนด์ของพร็อกซี (หากมี) (ปลายทางเป้าหมาย)

ทั้ง 2 จุดสิ้นสุดมีโฟลว์ตามที่อธิบายไว้ที่นี่

ประเภทปลายทาง คำอธิบาย โฟลว์ที่รองรับ
ProxyEndpoint มีโฟลว์พร็อกซี API ที่ใกล้กับไคลเอ็นต์มากที่สุด จัดเตรียมตําแหน่งให้ตรรกะทํางาน ก่อนในคําขอจากไคลเอ็นต์ แล้วทํางานสุดท้ายในการตอบกลับไปยังไคลเอ็นต์ PreFlow, Conditional Flow, PostFlow, PostClientFlow
TargetEndpoint มีโฟลว์พร็อกซี API ที่อยู่ใกล้กับทรัพยากรแบ็กเอนด์มากที่สุด จัดเตรียมตำแหน่งสำหรับตรรกะ เพื่อเตรียมคำขอ จากนั้นจัดการการตอบกลับจากทรัพยากรแบ็กเอนด์ PreFlow, โฟลว์แบบมีเงื่อนไข, PostFlow

คุณกำหนดค่าโฟลว์ด้วย XML ที่ระบุสิ่งที่ควรเกิดขึ้นและลำดับการเกิด ภาพต่อไปนี้แสดงลําดับของโฟลว์ภายในพร็อกซีปลายทางและปลายทางเป้าหมาย

คำขอจากไคลเอ็นต์ HTTP ที่ส่งผ่านปลายทางพร็อกซีไปยังปลายทางเป้าหมายในแบ็กเอนด์เพื่อเข้าถึงบริการ HTTP แผงคำขอและการตอบกลับแต่ละแผงจะแสดงโฟลว์ก่อนหน้า โฟลว์แบบมีเงื่อนไข และโฟลว์หลัง นอกจากนี้ ยังมีตัวอย่างของพร็อกซีปลายทางและปลายทางเป้าหมายด้วย

ทั้งปลายทางพร็อกซีและปลายทางเป้าหมายมีโฟลว์ที่คุณจัดเรียงได้ตามลำดับต่อไปนี้

ตำแหน่ง ประเภทโฟลว์ คำอธิบาย
1 PreFlow

มีประโยชน์เมื่อคุณต้องการตรวจสอบว่าโค้ดบางอย่างทำงานก่อนสิ่งอื่นใด จะเกิดขึ้น

หาก PreFlow อยู่ในปลายทางเป้าหมาย ระบบจะเรียกใช้ PreFlow หลังจาก PostFlow ของพร็อกซีปลายทาง

2 โฟลว์แบบมีเงื่อนไข

ที่สำหรับตรรกะแบบมีเงื่อนไข เรียกใช้หลังจาก PreFlow และก่อน PostFlow

ระบบจะเรียกใช้โฟลว์แบบมีเงื่อนไขเพียง 1 รายการต่อกลุ่ม ซึ่งก็คือโฟลว์แรกที่มีเงื่อนไข ประเมินค่าเป็นจริง ซึ่งหมายความว่าคุณสามารถมีโฟลว์แบบมีเงื่อนไขที่ดำเนินการเป็นส่วนหนึ่งของแต่ละรายการต่อไปนี้
  • ไปป์ไลน์คำขอของ ProxyEndpoint
  • ไปป์ไลน์คำขอของ TargetEndpoint
  • ไปป์ไลน์การตอบกลับของ ProxyEndpoint
  • ไปป์ไลน์การตอบกลับของ TargetEndpoint
3 PostFlow

เป็นจุดที่เหมาะสำหรับการบันทึกข้อมูล ส่งการแจ้งเตือนว่าเกิดเหตุการณ์ขึ้นขณะ ประมวลผลคำขอ และอื่นๆ เรียกใช้หลังจากโฟลว์แบบมีเงื่อนไขและ PreFlow

หาก PostFlow อยู่ในปลายทางพร็อกซีและมีปลายทางเป้าหมาย PostFlow ของปลายทางพร็อกซีจะทำงานก่อน PreFlow ของปลายทางเป้าหมาย

4 PostClientFlow (โฟลว์พร็อกซีเท่านั้น) โฟลว์สำหรับการบันทึกข้อความหลังจากส่งการตอบกลับไปยังไคลเอ็นต์

การเรียกใช้โค้ด ก่อนด้วย PreFlow

PreFlow มีประโยชน์เมื่อคุณต้องการให้แน่ใจว่าโค้ดบางอย่างจะทํางานก่อนสิ่งอื่นใด จะเกิดขึ้น

ในปลายทางพร็อกซี PreFlow เป็นตำแหน่งที่เหมาะสำหรับโค้ดที่ตรวจสอบสิทธิ์ไคลเอ็นต์และ จำกัดการรับส่งข้อมูลจากไคลเอ็นต์ ในปลายทางเป้าหมาย ซึ่งเริ่มเตรียมส่งคำขอไปยังเป้าหมายแบ็กเอนด์ PreFlow เหมาะสำหรับขั้นตอนแรกในการเตรียมส่งคำขอ

เช่น โดยปกติแล้วคุณไม่ต้องการให้บริการแก่ลูกค้าที่ใช้โควต้าเกิน หากต้องการ รองรับข้อกำหนดเหล่านี้ คุณต้องใส่นโยบายด้านความปลอดภัยและโควต้าในส่วน PreFlow วิธีนี้จะช่วยให้คุณไม่ต้องกังวลว่าเงื่อนไขจะประเมินไม่สำเร็จในโฟลว์แบบมีเงื่อนไขในภายหลัง นโยบายในขั้นตอนการทำงานนี้จะทำงานก่อนการประมวลผลอื่นๆ เสมอ

ในตัวอย่างต่อไปนี้ นโยบาย SpikeArrest และโควต้าจะทำงานก่อนที่จะประมวลผลการส่งไปยังโฟลว์แบบมีเงื่อนไข

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

การให้โค้ดทำงานแบบมีเงื่อนไขด้วยโฟลว์แบบมีเงื่อนไข

คุณสามารถมีโฟลว์ที่ดำเนินการแบบมีเงื่อนไขระหว่าง PreFlow กับ PostFlow ได้ ซึ่งจะช่วยให้คุณกำหนดค่าลำดับตรรกะหลายลำดับได้ แต่จะให้ดำเนินการเพียงลำดับเดียวตามสถานะของพร็อกซี โฟลว์แบบมีเงื่อนไขเป็นตัวเลือกหากคุณสามารถเรียกใช้ตรรกะทั้งหมดใน PreFlow หรือ PostFlow และไม่จำเป็นต้องมีเงื่อนไข (กล่าวคือ รองรับเฉพาะเส้นทางเดียวผ่านปลายทาง)

แต่ละโฟลว์จะระบุเงื่อนไขที่ทดสอบค่าสถานะต่างๆ ซึ่งจะ แยกการดำเนินการตามเงื่อนไข เช่น คุณอาจต้องการแปลง XML เป็น JSON เฉพาะ เมื่อแอปที่ขอทำงานบนอุปกรณ์เคลื่อนที่

ในที่นี้ ระบบจะบังคับใช้ข้อจำกัดของโควต้าก็ต่อเมื่อคำขอเป็นคำขอ GET ที่มีรูปแบบ URI เป็น /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 เป็นตำแหน่งที่เหมาะสำหรับการดำเนินการหลังจากตรรกะหลักของปลายทาง และก่อนที่การประมวลผลปลายทางจะเสร็จสิ้น PostFlow จะทำงานหลังจาก Conditional Flow และ PreFlow

PostFlow เป็นที่ที่เหมาะสำหรับการบันทึกข้อมูลบางอย่าง ส่งการแจ้งเตือนว่ามีบางอย่างเกิดขึ้น แปลงรูปแบบข้อความตอบกลับ และอื่นๆ

ในตัวอย่างต่อไปนี้ นโยบาย AssignMessage ที่ชื่อ SetResponseHeaders จะตั้งค่าส่วนหัวของ ข้อความตอบกลับก่อนที่ Apigee Edge จะส่งการตอบกลับไปยังไคลเอ็นต์

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

การให้โค้ดทำงานหลังจากที่ไคลเอ็นต์ได้รับการตอบกลับของพร็อกซีด้วย PostClientFlow

PostClientFlow อาจมีนโยบายต่อไปนี้

* นโยบาย FlowCallout จะเรียกได้เฉพาะโฟลว์ที่แชร์ซึ่งเป็นไปตามเกณฑ์ สำหรับการอยู่ใน PostClientFlow (กล่าวคือ มีเฉพาะนโยบายที่เข้ากันได้)

หากคุณรวมไว้ด้วย PostClientFlow จะเป็นโฟลว์สุดท้ายที่จะดำเนินการ โดยจะดำเนินการหลังจากส่งการตอบกลับไปยังไคลเอ็นต์

PostClientFlow เหมาะสำหรับการบันทึกขั้นสุดท้าย นอกจากนี้ คุณยังบันทึกการประทับเวลาเริ่มต้นและสิ้นสุดสำหรับข้อความตอบกลับได้ด้วย

ต่อไปนี้คือตัวอย่าง PostClientFlow ที่มีนโยบาย MessageLogging แนบอยู่

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

วิดีโอ: ดูวิดีโอสั้นๆ นี้เพื่อดูวิธีสร้าง PostClientFlow โดยใช้นโยบาย MessageLogging จากซีรีส์ Four Minute Video For Developers (4MV4D)

ดูข้อมูลเพิ่มเติมได้ที่

เพิ่มตรรกะลงในโฟลว์

เมื่อเพิ่มตรรกะลงในพร็อกซี คุณจะเพิ่มได้โดยการเพิ่มนโยบายลงในโฟลว์ของพร็อกซี เช่นเดียวกับที่โฟลว์ทำงานตามลำดับ (PreFlow แล้ว Flow แล้ว PostFlow ตามที่อธิบายไว้ในหัวข้อนี้) เนื้อหาของโฟลว์จะทำงานตามลำดับ

การกำหนดค่าโฟลว์ตัวอย่างต่อไปนี้อ้างอิงถึงนโยบาย 3 รายการ (กำหนดค่าไว้ที่อื่นใน ไฟล์ XML ของตนเอง) นโยบายที่อ้างอิงโดย Verify-API-Key จะทำงานก่อนนโยบายที่อ้างอิงโดย Remove-API-Key และทั้ง 2 นโยบายจะตามด้วยนโยบายที่แสดงโดย 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 จะแสดงลำดับนโยบายนี้เป็นแถวของไอคอน โดยแต่ละไอคอนจะแสดงถึงนโยบาย ไอคอนที่แสดงในเส้นทางการขอ ได้แก่ ยืนยันคีย์ API, นำคีย์ API ออก และโควต้า

การแก้ไขข้อบกพร่องของโฟลว์

เครื่องมือการติดตาม Apigee Edge มีวิธีแบบกราฟิกในการดูว่าตรรกะในพร็อกซี API ทำงานตามคำขออย่างไร เครื่องมือนี้แสดงการประมวลผลระหว่างคำขอและการตอบกลับ ไม่ได้แสดงภาพการแยกส่วนระหว่าง PreFlow, Conditional Flow และ PostFlow โดยเฉพาะ

ดูข้อมูลเพิ่มเติมเกี่ยวกับพร็อกซีการติดตามได้ที่การใช้เครื่องมือติดตาม

การจัดการข้อผิดพลาดในโฟลว์

คุณสามารถยกข้อผิดพลาดจากที่ต่างๆ ในพร็อกซี API รวมถึงจากโฟลว์

ตัวอย่างต่อไปนี้คือส่วนการตอบกลับจาก PreFlow ในปลายทางเป้าหมาย กล่าวคือ เป็นโค้ดที่เรียกใช้ทันทีเมื่อได้รับการตอบกลับจากเป้าหมายแบ็กเอนด์ ในตัวอย่างนี้ ระบบจะแจ้งข้อผิดพลาดหากการตอบกลับจากเป้าหมายไม่ใช่ 200 (สำเร็จ)

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับการจัดการข้อผิดพลาดได้ที่การจัดการข้อบกพร่อง