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

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

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

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

ตัวอย่างการกำหนดค่าโฟลว์ต่อไปนี้ระบุโฟลว์ที่นโยบาย VerifyAPIKey ประมวลผลหากเส้นทางคำขอขาเข้าลงท้ายด้วย / และ HTTP ของคำขอ กริยาคือ 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 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, ขั้นตอนแบบมีเงื่อนไข, PostFlow, PostClientFlow
TargetEndpoint มีโฟลว์พร็อกซี API ที่อยู่ใกล้กับทรัพยากรแบ็กเอนด์มากที่สุด ให้สถานที่สำหรับตรรกะ เพื่อเตรียมคำขอ จากนั้นจึงจัดการการตอบสนองจากทรัพยากรแบ็กเอนด์ PreFlow, ขั้นตอนแบบมีเงื่อนไข, PostFlow

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

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

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

อันดับ ประเภทโฟลว์ คำอธิบาย
1 PreFlow

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

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

สถานที่สำหรับตรรกะตามเงื่อนไข ดำเนินการหลังจาก PreFlow และก่อน PostFlow

ระบบจะดำเนินการตามขั้นตอนแบบมีเงื่อนไขเพียงขั้นตอนเดียวต่อกลุ่ม ซึ่งเป็นขั้นตอนแรกที่มีเงื่อนไข ประเมินเป็น true ซึ่งหมายความว่าคุณจะดำเนินการตามขั้นตอนแบบมีเงื่อนไข 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 และไม่มีเงื่อนไขใดๆ (กล่าวคือ เส้นทางผ่านปลายทางมีเพียงเส้นทางเดียวเท่านั้น ที่รองรับ)

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

ในที่นี้ จะมีการบังคับใช้ข้อจำกัดโควต้าต่อเมื่อคำขอเป็นคำขอ GET ที่มีแอตทริบิวต์ รูปแบบ URI ของ /issue/** (/issue/ ที่มีอะไรก็ได้ใน URI หลังการส่งต่อครั้งสุดท้าย เครื่องหมายทับ)

<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 ทำงานหลังจากโฟลว์แบบมีเงื่อนไขและ PreFlow

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

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

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

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

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

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

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

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

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

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

วิดีโอ: ลองดูวิดีโอสั้นๆ นี้ที่แสดงวิธีสร้าง PostClientFlow โดยใช้นโยบาย MessageLนั้นๆ จากซีรีส์วิดีโอ 4 นาทีสำหรับนักพัฒนาซอฟต์แวร์ (4MV4D)

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

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

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

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

ขั้นตอนการแก้ไขข้อบกพร่อง

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับพร็อกซีการติดตาม โปรดดูการใช้เครื่องมือการติดตาม

การจัดการข้อผิดพลาดในขั้นตอน

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

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

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

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