MuleSoft - การจัดการข้อยกเว้นล่อ

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

ข้อยกเว้นใน Mule

ก่อนที่จะดำน้ำลึกลงไปในการจัดการที่ยอดเยี่ยมเราควรทำความเข้าใจว่าข้อยกเว้นประเภทใดที่สามารถเกิดขึ้นได้พร้อมกับคำถามพื้นฐานสามข้อที่นักพัฒนาต้องมีในขณะออกแบบตัวจัดการข้อยกเว้น

ขนส่งไหนสำคัญ?

คำถามนี้มีความเกี่ยวข้องเพียงพอก่อนที่จะออกแบบตัวจัดการข้อยกเว้นเนื่องจากการขนส่งทั้งหมดไม่รองรับการข้ามชาติ

File หรือ HTTPไม่รองรับการทำธุรกรรม นั่นคือเหตุผลว่าทำไมหากมีข้อยกเว้นเกิดขึ้นในกรณีเหล่านี้เราต้องจัดการด้วยตนเอง

Databasesรองรับการทำธุรกรรม ในขณะที่ออกแบบตัวจัดการข้อยกเว้นในกรณีนี้เราต้องจำไว้ว่าธุรกรรมฐานข้อมูลสามารถย้อนกลับได้โดยอัตโนมัติ (หากจำเป็น)

ในกรณีที่ REST APIsเราควรทราบว่าควรส่งคืนรหัสสถานะ HTTP ที่ถูกต้อง ตัวอย่างเช่น 404 สำหรับทรัพยากรไม่พบ

จะใช้รูปแบบการแลกเปลี่ยนข้อความแบบใด

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

Synchronous message pattern ขึ้นอยู่กับรูปแบบการตอบกลับคำขอซึ่งหมายความว่ารูปแบบนี้จะคาดหวังการตอบกลับและจะถูกบล็อกจนกว่าจะมีการตอบกลับหรือหมดเวลา

Asynchronous message pattern ขึ้นอยู่กับรูปแบบ fire-forget ซึ่งหมายความว่ารูปแบบนี้ถือว่าคำขอจะได้รับการดำเนินการในที่สุด

เป็นข้อยกเว้นประเภทใด

กฎง่ายๆคือคุณจะจัดการกับข้อยกเว้นตามประเภท เป็นสิ่งสำคัญมากที่จะต้องทราบว่าข้อยกเว้นนั้นเกิดจากปัญหาของระบบ / ทางเทคนิคหรือปัญหาทางธุรกิจหรือไม่?

เกิดข้อยกเว้นโดย system/technical issue (เช่นเครือข่ายขัดข้อง) ควรจัดการโดยอัตโนมัติโดยกลไกการลองใหม่

ในทางกลับกันเกิดข้อยกเว้น by a business issue (เช่นข้อมูลที่ไม่ถูกต้อง) ไม่ควรแก้ไขโดยใช้กลไกการลองใหม่เนื่องจากไม่มีประโยชน์ที่จะลองใหม่โดยไม่แก้ไขสาเหตุที่แท้จริง

ทำไมต้องจัดหมวดหมู่ข้อยกเว้น?

ดังที่เราทราบดีว่าข้อยกเว้นทั้งหมดไม่เหมือนกันการจัดหมวดหมู่ข้อยกเว้นจึงเป็นเรื่องสำคัญมาก ในระดับสูงข้อยกเว้นสามารถแบ่งออกเป็นสองประเภทต่อไปนี้ -

ข้อยกเว้นทางธุรกิจ

สาเหตุหลักของการเกิดข้อยกเว้นทางธุรกิจคือข้อมูลที่ไม่ถูกต้องหรือขั้นตอนกระบวนการไม่ถูกต้อง โดยทั่วไปแล้วข้อยกเว้นประเภทนี้จะไม่สามารถดึงกลับได้ตามธรรมชาติดังนั้นการกำหนดค่าไฟล์rollback. แม้กระทั่งการสมัครretryกลไกจะไม่สมเหตุสมผลเพราะไม่มีประโยชน์ที่จะลองใหม่โดยไม่แก้ไขสาเหตุที่แท้จริง ในการจัดการกับข้อยกเว้นดังกล่าวการประมวลผลควรหยุดลงทันทีและข้อยกเว้นจะถูกส่งกลับเป็นการตอบกลับไปยังคิวจดหมายตาย ควรส่งการแจ้งเตือนไปยังฝ่ายปฏิบัติการด้วย

ข้อยกเว้นที่ไม่ใช่ธุรกิจ

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

กลยุทธ์การจัดการข้อยกเว้น

Mule มีกลยุทธ์การจัดการข้อยกเว้นห้าประการต่อไปนี้ -

กลยุทธ์การยกเว้นเริ่มต้น

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

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

กลยุทธ์การยกเว้นย้อนกลับ

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

Example

กลยุทธ์นี้สามารถนำไปใช้กับธุรกรรมธนาคารที่มีการฝากเงินเข้าบัญชีเงินฝากออมทรัพย์ เราสามารถกำหนดค่ากลยุทธ์การยกเว้นการย้อนกลับได้ที่นี่เพราะในกรณีที่เกิดข้อผิดพลาดระหว่างการทำธุรกรรมกลยุทธ์นี้จะย้อนข้อความกลับไปที่จุดเริ่มต้นของขั้นตอนเพื่อพยายามประมวลผลใหม่

จับกลยุทธ์ข้อยกเว้น

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

กลยุทธ์นี้ยังช่วยให้มั่นใจได้ว่าธุรกรรมที่ประมวลผลโดยโฟลว์จะไม่ย้อนกลับเมื่อเกิดข้อยกเว้น

Example

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

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

กลยุทธ์การยกเว้นทางเลือก

ในกรณีที่คุณต้องการจัดการข้อยกเว้นตามเนื้อหาข้อความดังนั้นกลยุทธ์การยกเว้นตัวเลือกจะเป็นทางเลือกที่ดีที่สุด การทำงานของกลยุทธ์ข้อยกเว้นนี้จะเป็นดังนี้ -

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

จะมีกลยุทธ์ยกเว้นมากกว่าหนึ่งอย่างเช่น Catch หรือ Rollback ซึ่งกำหนดไว้ในกลยุทธ์การยกเว้นตัวเลือก ในกรณีที่ไม่มีกลยุทธ์ที่กำหนดไว้ภายใต้กลยุทธ์ข้อยกเว้นนี้ระบบจะกำหนดเส้นทางข้อความไปยังกลยุทธ์ข้อยกเว้นเริ่มต้น จะไม่ดำเนินการกระทำหรือย้อนกลับหรือใช้กิจกรรมใด ๆ

กลยุทธ์การยกเว้นการอ้างอิง

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