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

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

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

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

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

ดำเนินการกับโฟลว์แบบมีเงื่อนไขเพียง 1 รายการต่อกลุ่มเท่านั้น กล่าวคือโฟลว์แรกที่มีการประเมินเงื่อนไขเป็น "จริง" ซึ่งหมายความว่าคุณจะดำเนินการโฟลว์แบบมีเงื่อนไขได้ 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/ มีข้อมูลใดก็ได้ใน 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 อาจมีนโยบายต่อไปนี้

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

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

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

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

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

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

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