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